Hypoglycemic Prevention Syste m

1. Hypoglycemic Prevention System David Deutsch Jake Roby Senior Design, Fall 2011

2. Introduction • Extreme hypoglycemia causes 6% of diabetes related deaths • Fatalities typically occur during sleep • Prevention systems are not yet standard

3. Motivation • Continuous Glucose Monitors are becoming more reliable devices • CGM’s typically transmit new readings every five minutes • Non-invasive methods of continuous monitoring will likely become available in the future

4. Objective • Our overall goal was to design a system capable of receiving wireless data from a CGM, analyzing this data for threatening trends, and triggering an alarm if a threat is detected CGM Simulator Main Board Transmitter Transmitter Receiver Receiver Receiver Alarm

5. Ethical Implications • Medical devices require exceptionally high ethical standards • Considerations made: • Cross talk to reduce risk of inaccurate message transfer • Linear regression algorithm to predict dangerous readings before they occur. • Accessibility and foresight against user created problems

6. System Overview Transmitter/Simulator • Continuous function is generated via a PIC microcontroller and transmitted via a LINX HP3 transmitter • Function consists of eight bit words representing glucose readings from 0-255 mg/dL • Function is designed to test the threshold condition and can be amended by the user CGM Simulator Transmitter Receiver

7. Simulator/Transmitter

8. System Overview Receiver/Analyzer LINX HP3 receiver relays transmitted function to a second PIC microcontroller This microcontroller stores the function in a buffer and analyzes it to detect a threat Microcontroller can display the function on either a PC monitor or IC display Main Board Transmitter Receiver

9. Receiver/Analyzer

10. Hardware Overview • PIC16F887 Microcontrollers (2) • LINX HP3 Receivers (3) • LINX HP3 Transmitters (2) • MAX232 Converter (2) • NHD-12864WG-CTFH-V#N Graphical Display (1) • Piezo Buzzer (1)

11. Wireless Communication • Microcontrollers feature built in UART for transmitting and receiving eight bit words (0-255 mg/dL) • Programmable transmission rate • LINX HP3 receivers/transmitters feature eight parallel channels spanning a range of 903-930 MHz

12. Wireless Communication

13. LINX Debugging • PIC BAUD rate initially disabled LINX from transmitting and receiving • Swept through frequencies on the function generator and observed transmitter response • Reduced BAUD rate from 9600 to 1200 in order to compensate

14. Cross Talk • The data processing PIC will echo back received bytes to the simulator • If the simulator receives the correct information, it will send a confirmation “0” • In the event of an error, the simulator will transmit a “1” and then re-transmit the intended byte

15. Cross Talk Verification • Used oscilloscope to verify presence of confirmation “0” • For several iterations of cross talk loop, intentionally loaded in wrong byte to buffer • Receiver only loaded in the correct byte to the buffer after a pronounced time delay

16. Cross Talk PseudoCode Simulator Data Analyzer Receive Byte Transmit Byte Receive Byte If confirm byte received, jump out of loop If deny byte received, stay in loop • Transmit Byte • Receive Byte • Is transmit equal to receive? • If yes, send confirm byte, jump out of loop • If no, send deny byte, stay in loop

17. Linear Regression • Microcontroller stores a buffer of past ten transmitted values • Linear regression function programmed onto the PIC projects what the next value will be

18. Accuracy Correction • Assume each received byte could be one mg/dL lower • Call linear regression function with each permutation of buffer • Iteratively seek lowest projected value • Function calls for length ten buffer increase to 1024 • When tested, worked satisfactorily for length three buffer (<10 seconds) but far too long for larger

19. Timing Issues • Linear Regression function uses 26 int32 multiplies and 2 float divisions per iteration • Each iteration should take no more than 10 ms • Even with 1024 iterations, algorithm should only take an acceptable ten seconds • Mystery Errors?

20. IC Display • NHD-12864WG-CTFH-V#N Graphical Display • Instruction set programmed into microcontroller • IC pins linked to PIC pins, microcontroller used as display driver • Robust code, undiagnosed hardware malfunction

21. Threshold Detection • Alarm is triggered under the following circumstances • The projected value predicted by the least squares fit dips below threshold • The most recent buffer value dips below threshold • The PIC receives more than 20 bytes of incorrect information in a row (communication error)

22. Serial Port User Interface • D9 Serial Port Connection to PC • Accepts parameters from computer terminal: • Threshold • Data Generation • Receives readings from PIC Data Processor

23. Serial Port User Interface • Sending Data: • The user interface sends and receives 16 bit words • On a single press of the “send” button, 5 words are sent to the PIC • Upon receiving data, the PIC responds to the User Interface, and confirmation is displayed.

24. Serial Port User Interface • Receiving Data • Automatically outputs all readings to the display. • Upon an alarm trigger, the interface disconnects from the device and awaits renewed calibration.

25. Serial Port User Interface • Accessibility: • Made for easy use without technical knowledge • Converts base 10 to HEX to be transmitted • Illegal characters produce error messages • Grayed out controls when connection is inactive • Confirmation when calibration has been received

26. Testing • Three main testing cases to be considered: • Alarm triggered by threshold breach • Alarm triggered by linear regression breach • No alarm triggered

27. Testing • Case 1: Alarm triggered by threshold breach • Data generation set to avoid linear regression • Offset set below threshold value • Alarm triggers as the current reading dips below the threshold.

28. Testing • Case 2: Alarm triggered by linear regression • Data generation set with longer period • Offset set near threshold, but does not need to be below • Alarm triggers before the current reading breaches the threshold

29. Testing • Case 3: Alarm is not triggered • Offset – Slope > Threshold to guarantee out of range • The periodic signal is repeated indefinitely with no alarm triggers

30. Future Hardware Development • Improved antennae for greater signal strength and reliable distance • Compacted design of Glucometer attachment • Corrected PCB capable of housing display unit • Establish links with actual CGM’s

31. Future Software development • Data testing of linear regression algorithm against real world glucometer readings • Must cover both safe and unsafe data sets • Expand PC interface code to display threshold and projected value graphically

32. Learning Process • First time working with components, fabricating PCB • Would have allotted time to refabricate PCB’s • Separation of hardware tasks

33. Summary • Functional Processes • Wireless Communication, Cross Talk • PC Interface • Linear Regression • Threshold Breach, alarm Trigger Thank You