Project Logs

Collapse

• General Updates

  Jonathan Buchanan • 12/07/2016 at 16:41 • 0 comments

  I'm not dead, though progress has been slow.

  I have done a lot of work, but not enough on any specific thing to merit its own update, so I decided to do a combined entry.

  ---

  Software

  A large portion of what I've done has been small additions and improvements to the code. The data screen now sorts entries, the delete and edit buttons now work, and a lot of background cleanup. I've also started to experiment with fixing the size of the keyboard,

  too small (and qwerty)

  just right

  and adding better selectors for dates and times.Other than these things, there is not much more to see on the software side of things.

  Hardware

  I bought and setup a real time clock (RTC).

  The RTC is a microchip that is constantly powered by a small battery. All it does is keep time for the computer even when it is off or the main battery is totally dead. Using Adafruit's libraries it was easy to set up so the pi updates its hardware clock from the RTC when it boots.

  Speaking of adding new PCBs, this protype is made up of a total of 6 individual PCBs:

  • Screen
  • Pi
  • Power Supply
  • Glucometer
  • ADC
  • RTC

  I have started preliminary work on combining the last four so into one big PCB for more compact space usage and the possibility of producing these to sell eventually. This is possible because all of Adafruit's PCB designs are open-source, but still difficult since I am unfamiliar with Eagle.

  It has also become painfully obvious that the raspberry pi zero is not capable of running opengl like kivy requires. The whole system takes 60 seconds from power to ready-to-use to boot, and there is lag while switching in between screens. I tested the Pi 3 (a much more powerful device) on my 2000mAh battery, and it ran for more than an hour of continuous use. Though that may not sound like much, I probably use my current meter for less than 5 minutes a day of continous use, and the glucometer program runs silky smooth compared to the zero.

  I believe I will have to switch to the Pi 3 to get the speed I need, and I'm going to play around with buildroot to try to optimize the boot time even better (still takes almost 20 seconds on the Pi 3). I will probably also have to put the battery underneath the pi, instead of between in and the screen, which will add 1/2" to the thickness of the device :(.
  

  Case

  The progress on the case has been proceeding slowly and simultaneously with the other projects, but I have a first draft faceplate. The model was made primarily by Samantha Maness, a classmate who is planning on studying matierals engineering.

  The model appears to be good, but I wasn't able to test fit it because the x-axis was out of alignment on the printer.

  
  

  Today I hope to re-align and print again, so expect an update on that soon.

• Software Development

  Jonathan Buchanan • 10/04/2016 at 22:00 • 0 comments

  Recently I've been working on the software side of things. Huge shoutout to my government teacher for all the work he's let me do during his class (albeit unknowingly).

  The primary part of this project that is supposed to elevate my meter over commercial ones is the quality of its programming. With that consideration, I have put a lot of thought into the design of the UI, and I would welcome anyone's suggestions on how to make it better.

  The place to start would logically be the home screen then. On my accu-chek meter, the system dumps you on a menu screen when it starts. I rejected that idea because it is a waste of space and time to go through a menu when I could display relevant information on the startup. Here is the first draft of the home screen.

  Right away, the largest items are the graph, and the averages, data that is helpful and relevant, but maybe not something that I would intentionally seek out regularly. This way, it is displayed easily for me whenever I start up the meter. The two dropdown menus near the top allow you to select the date range the graph and averages run over, and defaults to a week before the current day.

  Also there is a large button for adding new data, possibly only carb and insulin information, which will be the most common reason I'll power on the meter in the first place.

  The next screen is the BG testing screen.

  The "(insert strip)" button is for simulating the strip insertion without the actual hardware.
  

  
  

  I can get to other screens using the dropdown menu on the right side of the menu bar, and the BG test screen is at the top.

  This screen is largely unnecessary because at least currently, the meter can open the testing dialogue popup from any screen.

  I think it will be included in the final version though, because it is helpful for prompting users unfamiliar with the system. Please remember all art (or lack thereof) you see in these images is placeholder; I'm just working on the programming at the moment.

  The next screen is the data screen.

  This is the drawing I made of what I wanted the layout to look like. The dark bars represent separate days, and the rows represent individual entries which can include blood glucose reading, carbs, insulin, notes, or any combination thereof. The delete button is always off the screen regardless of the length of the entry so that you have to swipe the row over to delete it.

  This is what I have so far:

  This layout is intended to be easy to read, and intuitive to use. The shaded rows represent each day that there is a record for, and the lighter rows represent a data entry that can include time, blood sugar, carbs eaten, units of insulin taken, and some notes.

  This data storage has one feature in particular that makes it superior to commercial meters. It is possible to edit a data entry. Any entry. Accu-chek's patented function of dividing the number of carbs I entered by a ratio that I gave it is all well and good except for one problem. Any entry that includes their "bolus advice", cannot be edited. I suppose this is to prevent lawsuits, but it is rather annoying if I enter something incorrectly or discover I don't have enough insulin after I've already pressed "submit", and the records will forever be incorrect.

  The last significant screen to mention is the setting screen.

  There's not much to show here yet (though the brightness slider does work on the actual hardware), but I included it so I could discuss some of the things I will put here soon.

  It will obviously include device settings such as brightness and date and time. It will also include settings such as disabling/enabling the BG screen (some people might find it extraneous), setting default date ranges on the home screen, and turning on calibration mode, which will prompt the user for a control value after each BG test that it will use to calculate glucose concentrations next time.

  The settings screen will also be where you would set the carb ratio (the number you divide carbs by to get units of insulin required),...

  Read more »

• PCB Working!

  Jonathan Buchanan • 09/20/2016 at 01:20 • 0 comments

  So, I got the right sized components for the board. I soldered them all up, and it looked like a perfect, elegant, professionally designed PCB.

  I actually delayed the testing for a few days because I was so scared it wouldn't work, but eventually I turned on the ADC, plugged in a strip, and inserted a blood sample. Here's the first graph from the PCB.

  Well. Not exactly what I'd hoped for. Don't panic yet though, this looks like a familiar problem. The very first time I tested the breadboard, I got extremely similar graphs, and, sure enough, I had left the ground off pin #11, just like I did on the breadboard.

  On the circuit designer, I saw this blue wire (actually on the underside of the board) running directly through the middle of pin #11 and assumed it was already connected.

  So I soldered a jumper to the nearest ground, and tested it again.

  Still not what I'd hoped for, though still familiar. This time though, the familiarity was a red herring, so I won't include the graph of trial 13 on the breadboard which had a similar look.

  I'll spare you too many details, but suffice to say the reason this post took so long is that it took me three weeks to find the problem.

  Here is a picture of part of the debugging process.

  Note the breadboard capacitors soldered to the top of the PCB.
  

  During this time, I learned several valuable things, including:

  • the rules of electronics are definitely random, no matter what anybody says
  • touching wires with your hands connected to sensitive instruments generates noise (even through insulation)
  • it's always a connection problem
  • I hate debugging things with random rules

  Eventually, after replacing components, checking solder joints, testing voltages and resistances, simulating circuits, and reading ADCs, I discovered the problem lay in the connection between the strip connector and its sockets when I soldered it up externally.

  Here, actually both the breadboard meter (bottom) and the PCB meter (top right) are connected to the ADC (bottom right) on separate channels so I could compare the ADC's readings.
  

  
  

  After noticing that the noise read by the ADC was many times lower with the strip connector connected differently, I decided to test it again.

  This graph, produced from the PCB meter, shows a curve much more similar to that which the breadboard generated earlier.
  

  I haven't finished calibrating to make sure the PCB is satisfactorily accurate yet, but I'm optimistic based on the smoothness of that curve.
  

  I've been working on the software side of things, and I will probably post either an update about that, or my process in designing a case for all this next.
  

• PCB Arrived

  Jonathan Buchanan • 08/20/2016 at 16:40 • 0 comments

  After a 3-week wait, the PCBs have finally arrived. They look really good, though I don't know if they do anything else

  On a related note, as a follow-up on my lesson about surface mount chips, today I learned the difference between metric and imperial case codes.

  This confusion led to what some people might call a small problem.
  

  
  

  Anyway, I have to order more, larger components before I can test the PCB. At least I can look at how nice and sophisticated it is while I wait for yet another shipment.
  

• PCB Design

  Jonathan Buchanan • 08/09/2016 at 21:36 • 2 comments

  Now that the breadboard prototype appears to be working, it's time to make a more permanent (and smaller) version. With a few minutes of googling, I found a website called EasyEDA, that allows you to design PCBs using their online tool. It was fairly intuitive to learn and, even better, it included a massive user library of part dimensions, and an automatic conductor router (in other words, it generated the hard part for me).

  When considering the design, I wanted it to be small and concise. To that end, I made a few adjustments to Bindhammer's schematic. Here is my modified version.

  The primaries differences are the quad switch is gone and with it the op-amp integrator between pins 13 and 14 it controlled. The function of an op-amp integrator is to output a voltage proportional to the integral of the input. In a glucose meter, the graph it produces is in some circumstances more linear than the the direct op-amp output.

  In my tests, it was not, so I took it out, along with the physically largest chip. This is the graph it made. X-axis is time, Y-axis is ADC voltage.

  Top: integrator active; Bottom: no integrator

  One other notable change is that capacitor 6 and 7 are no longer polarized. I believe these capacitors are to filter out AC voltage and noise, and I think they can do that when they're not polarized. I am certain, however, that non polarized capacitors are much, much smaller.

  With the new design, I confidently connected up some virtual wires and told the auto router to route me some conductors.

  Here is the virtual estimation of the result. Here is the gerber file.

  EasyEDA also offers milling, and since I got it down to about one square inch, it only cost $10 for 5 boards! I went ahead and got 10 cause 5 was the minimum and 10 was the same price as 5. I also ordered another set of resistors and capacitors (checking to make sure they were surface mount) from Mouser.

• Testing!

  Jonathan Buchanan • 08/02/2016 at 21:50 • 0 comments

  So now that I've built the breadboard prototype, it's time to test the thing. I considered getting some meter test solution to aid in the testing, but since I am diabetic and accustomed to punching holes in myself, I figured I'd just record one or two data points a day using real blood by testing on my new meter and my reliable commercial one and comparing.

  Here is the code I used to record test data (based on the Adafruit ADC example code

  import time
  import Adafruit_ADS1x15
  
  # Create an ADS1115 ADC (16-bit) instance.
  adc = Adafruit_ADS1x15.ADS1115()
  
  GAIN = 4
  
  print('#Press Ctrl-C to quit...')
  print('#channel 0 minus channel 1')
  
  count = 0
  
  while True:
      value = adc.read_adc_difference(0, gain=GAIN)
  
      print(str(count) + ' {0}'.format(value))
      count = count + 0.1
      # Pause for half a second.
      time.sleep(0.1)

  So I plugged in a strip and fired up the program, piping the output to a log file. Here are some of my first results:

  The X axis is time in seconds and the Y axis is the voltage at the point in the circuit labeled "ADC 0" minus the voltage at the point "ADC 1" in arbitrary units determined by the gain of the amps and the ADC.
  

  I, in my infinite knowledge of electronics, decided it was ridiculous to connect the ground to the negative input on the opamp (Since it is sometimes used with negative voltage). After re-consulting the schematic and making the appropriate modifications to my setup, I tried again.

  These graphs look too perfect to not be the right thing, so I looked into calibrating. Based on different papers I've read, and observing commercial meters, the reaction is more proportional a few seconds after the initial spike rather than the actual maximum of the graph.

  To clarify, the measurement used to calculate the concentration of glucose should be taken a few seconds after the first reading. I may experiment with different times to see what is the best, but for now I just used 5 seconds.

  After collecting a few data points, I put the into a file and graphed them versus actual recorded glucose concentration (Bottom left graph).

  Spike in bottom right graph is the result of recording the insertion of a strip.
  

  Not a tremendous number of data points, but I found that shifting the apparatus, even delicately could actually affect the readings. As a result it was hard to collect enough points to get a good graph before the resistance in a tiny connection changed and altered the calibration of the meter.

  Regardless though, the actual data (red line) is quite close to the ideal (green line), indicating there is a strong correlation between my meter's output and actual glucose concentration. When I calculated the concentration using the green line shown, my meter differed from the commercial one by between 1 and 5 mg/dL.

  The results of the tests are very good. I believe the problems caused by moving the meter will be nullified when the meter is put in PCB form (as nothing will be able to move). I will post another log about the design of the PCB soon.
  

• Actually Building Some Stuff

  Jonathan Buchanan • 07/29/2016 at 22:02 • 0 comments

  I actually got the parts a few days ago, but I had to wait to fully assemble the thing because of an unexpected problem.

  I eagerly poured the bags out on my desk...

  but when I got to the opamps and voltage regulators...

  I discovered a slight discrepancy between the pins on the chips and the holes on my breadboard. That was the day I fully learned the difference between breadboard chips and surface mount chips. I felt a little better about myself when I discovered Mouser did not have the voltage regulators in the size I needed (so I couldn't have gotten it right), and I felt better about my project when I discovered adafruit's adapter.

  This actually wasn't the right size for the voltage regulators either, but since they had fewer pins and were spaced farther apart, I was able to make the adapters work with them without spending extra money.

  Before the adapters arrived, I actually made an attempt at fabricating an adapter by using my Grandfather's idea of finding a suitably threaded bolt to space the wires.

  The opamp chip was supposed to sit on the narrow end of the board and the wires would be trimmed down to make connection points. The spacing was good, but even after more than one hour of soldering, I couldn't be sure it was making a good connection. I ended up using the same adapter for it. It took about 5 minutes to solder.

  The capacitors and resistors were easier to deal with. Aside from having to look up with way the polarized capacitors should go, I was able to pretty much plug stuff in from the diagram.

  Here is a picture of the final product.

  The opamp is on stilts because I didn't have enough space for the wide adapter on the breadboard. To the left of it is the quad switch, then the two voltage regulators. The ADC is behind the breadboard, obscured by wires, and the pi 3 is providing power and reading the ADC.

  Now that everything was in place I could test the two voltage regulators.

  The were supposed to be 2.1v and 2.5v respectively, so that was a success.

  Testing the whole thing in the next log!

• Kivy Pie

  Jonathan Buchanan • 07/27/2016 at 23:20 • 0 comments

  The project has developed to the point where it is time to pick an operating system. Since I want more than a terminal program for my meter software, I need a GUI. Since I don't want any window manager or extra clutter, I don't want to start X every time the meter boots.

  One of the major attraction of using Kivy, one of the many python GUI toolkits, is that it can run by itself without a window manager. While doing some browsing I came across KivyPie, a custom install of pipaOS specially for developing Kivy software.
  

  On Kivy Pie's website it says this:

  "To make the installation steps simple to Kivy developers. KivyPie integrates all software needed and boots directly on the Raspberry PI, no extra configuration is needed. pipaOS is a minimalist Raspbian OS version."

  That sounded pretty good to me, so I flashed it to an sd card and booted it on one of the growing number of raspberry pi's sitting around my house.

  I have this PiTFT by adafruit. It is a simple framebuffer device and requires a custom kernel to run. Fortunately pipaOS is based on Raspbian, so I only had to follow the instructions under DIY install script to get kernel support for the screen.

  Another major problem loomed, however. Kivy is designed to use the raspberry pi's GPU, puny as it is. The PiTFT cannot by used with the GPU. The workaround is to use a program called rpi-fbcp that allows any program to output it's display to the hdmi port and then copy it to the PiTFT screen. An inelegant solution to be sure, and it does slow everything down.

  Next, I had to get the coordinates of the touchscreen to match the actual display on the screen. I followed the instructions on this question's answer and that seemed to work well.

  After that I promptly tested it out by starting up a kivy port of flappy bird

  That seemed to work well, but I wanted it rotated so the buttons would be on the bottom, and it would be more consistent with traditional meters.

  First I tried rotating the screen in /boot/config.txt, but that confused kivy. Eventually I found the appropriate settings in kivy's config file.

  After that I played around with kivy and made a mockup of the menu screen on the meter.

• ADC - Analog to Random Number Converter

  Jonathan Buchanan • 07/27/2016 at 21:59 • 0 comments

  My ADC arrived the other day. ADC stands for analog to digital converter and it converts voltage into a number readable by a computer. Basically a voltmeter. Its function in the meter is to read the voltage outputted by the amps, which are fed by a tiny current from the electro-chemical reaction in the test strip. The voltage should be proportional to the glucose concentration, though the exact number depends on the gain of all the amps in the circuit.

  Since my pi zero hasn't arrived yet, I instead unplugged the barometer from from balloon computer's i2c poins (check out my other project) and downloaded adafruit's libraries.

  Not knowing what to expect I hesitantly peeked into one of the example files.

  # Simple demo of reading each analog input from the ADS1x15 and printing it to
  # the screen.
  # Author: Tony DiCola
  # License: Public Domain
  import time
  
  import Adafruit_ADS1x15
  
  # Create an ADS1115 ADC (16-bit) instance.
  adc = Adafruit_ADS1x15.ADS1115()
  
  # Choose a gain of 1 for reading voltages from 0 to 4.09V.
  # Or pick a different gain to change the range of voltages that are read:
  #  - 2/3 = +/-6.144V
  #  -   1 = +/-4.096V
  #  -   2 = +/-2.048V
  #  -   4 = +/-1.024V
  #  -   8 = +/-0.512V
  #  -  16 = +/-0.256V
  GAIN = 1
  
  print('Reading ADS1x15 values, press Ctrl-C to quit...')
  # Print nice channel column headers.
  print('| {0:>6} | {1:>6} | {2:>6} | {3:>6} |'.format(*range(4)))
  print('-' * 37)
  # Main loop.
  while True:
      # Read all the ADC channel values in a list.
      values = [0]*4
      for i in range(4):
          # Read the specified ADC channel using the previously set gain value.
          values[i] = adc.read_adc(i, gain=GAIN)
          # Note you can also pass in an optional data_rate parameter that controls
          # the ADC conversion time (in samples/second). Each chip has a different
          # set of allowed data rate values, see datasheet Table 9 config register
          # DR bit values.
          #values[i] = adc.read_adc(i, gain=GAIN, data_rate=128)
          # Each value will be a 16 bit signed integer
      # Print the ADC values.
      print('| {0:>6} | {1:>6} | {2:>6} | {3:>6} |'.format(*values))
      # Pause for half a second.
      time.sleep(0.5)

  Looked simple enough.

  Feeling more confidant, I hooked the pi's 3.3v pin to the ADC's A0 pin.

  I then ran simpletest.py. The result was an string of numbers around 13000, give or take a few hundred. I disconnected the pin and they all went to 0, so something was definitely happening.

  I played with the gain a bit and got the numbers to change a little, but when I set it at 2/3 and hooked up the 5v pin (the code above says 2/3 reads up to 6.144) the program crashed. Still need to look into that.

  Emboldened by success, I ran another 3.3v pin to A1 and started up differential.py. In the schematic I discovered in the last post, there are two ADC inputs, which I assume means I need to find the difference between them.

  Interestingly, though not altogether surprisingly, though the pins on the raspberry pi fluctuate slightly in voltage, they always changed together so that the difference was always -1.

  Trying to hook the 5v up to either pin still crashed the program, even while subtracting.

• A Veritable Treasure Map

  Jonathan Buchanan • 07/25/2016 at 16:25 • 0 comments

  After the attempt shown in the previous log, I set the project on the back burner while I considered other possibilities.

  After a few weeks, while browsing the interwebs, I came across M. Bindhammer's open source Arduino glucometer shield project. In his project, Bindhammer provided the schematic I had been trying to piece together from papers and patents (but lacked the electronics skill to do so). Here it is in all it's glory.

  Needless to say I ordered the necessary parts and I plan to breadboard them before constructing a PCB.

View all 11 project logs