As it's Sunday and we've been having really great weather here in Wales lately, I spent most of the day in the garden and on the beach and not in front of the computer. This means there's no new code today, but I did want to jot down a few notes on why I decided to use a USB host controller chip (and not a Raspberry Pi) for connecting to USB devices.
I think it would be pretty easy to connect to USB devices from the Raspberry Pi's USB On-The-Go (OTG) port, and there are existing USB drivers for most serial port chips in the Linux kernel. The Pi Zero W also has Bluetooth LE and WiFi, so you can transmit data read from the USB device to a server or to a phone.
I guess I am looking for a bit more of a challenge and want to answer the question: Can a bare-metal approach to connecting USB devices work more reliably than building something on top of an operating system? Since the USB controller chip lets me develop both my own USB stack and USB drivers without having to mess around with an operating system, I'm hoping that it will result in something more reliable than the sometimes flaky USB support on desktop computers.
Modern computers are optimised for USB 3, with USB 2 support usually quite buggy, especially on new MacBooks. Many diabetes devices are still USB 2, due to the long product life cycles of medical devices, so not having good USB 2 support can be a problem.
Of course, there is power consumption as well. A Raspberry Pi consumes a significant amount of power compared to a little microcontroller with a USB controller chip. I want to see if I can build something that runs off a small LiPo battery, or maybe even a couple of coin cell batteries, that can eventually fit into a small dongle form factor. Let's see what happens.
In a previous post I started playing around with Bluetooth LE on blood glucose meters. This post is a quick look at Bluetooth LE's diabetes device profiles.
Bluetooth LE is an open specification, meaning anyone can download it from the website and read it, compared to most ISO standards where you have to pay and arm and a leg just to read the spec[1]. So I started by looking through the list of Bluetooth profiles to see which ones are specific to diabetes.
There is a Glucose Profile (GLP) for blood glucose meters and a Continuous Glucose Monitoring Profile (CGMP) for continuous glucose monitors. However, it looks like the Insulin Delivery Profile (IDP) is still under development, as the only public mention I can find on it is in their list of acronyms. I did however, find a medication field in the Glucose Profile, so if you want to record the insulin dose as part of a blood glucose measurement, that should work without having to wait for the Insulin Delivery Profile to be released.
I tried to see if I could find out what the progress of the Insulin Delivery Profile was. However, to do that it looks like you have to join the Medical Devices working group, and to do that you need to be an “Associate or Promoter” member. That costs $7.5k/year if your annual revenue is less than $100 million. Probably worth it if you want to influence what the standard looks like, but not worth it if you're just looking for some info. Hey, if you know the current status of the Insulin Delivery Profile, please get in touch! ;)
or proprietary specs, where you usually have to set up a partnership and sign an NDA to read it ↩︎
Bluetooth Low Energy (LE), also known as Bluetooth 4 and formerly known as Bluetooth Smart, is supported by most mobile and desktop operating system and can be found in many wireless devices. It was developed by Nokia in the early 2000s and first marketed as Wibree, a competitor to the Zigbee low-power wireless standard.
While Zigbee is used in many smart home devices, like smart meters and light bulbs, the rebranding of Wibree as Bluetooth LE helped it to take over the smart phone market, with around 90% of new mobile devices now supporting Bluetooth LE.
Bluetooth LE has open specifications (called profiles) for various types of devices, including blood glucose meters (BGMs) and continuous glucose monitors (CGMs). At Tidepool we've had to work very hard to get communication specifications from device manufacturers in order to communicate with their devices over USB. These are all proprietary protocols which have to be developed for and supported separately, and apart from Ascensia (previously Bayer), not a single company have published their protocols in the open. Now with Bluetooth LE, having a common standard specifying how these devices should communicate that is supported by device manufacturers is great!
I downloaded an app from the App Store called nRF Toolbox by one of the Bluetooth LE chip manufacturers, Nordic Semiconductor. It has support for various BLE profiles, including the BGM and CGM profiles. I was able to successfully connect to and read data from a Bluetooth LE-enabled BGM called the True Metrix Air, after entering the device serial number to pair:
Have you seen the Remote Only manifesto written by Gitlab that has been doing the rounds on the internets lately? This is basically how we work at Tidepool.
We currently have a team of 14 people based in the US, Canada, Australia and the UK. We used to have a main office in San Francisco, but now that our team is not mainly concentrated in the Bay Area anymore, we are now truly remote only.
Slack works well for us in terms of asynchronous communication. When I start work in the morning, I can quickly reply to questions people in other timezones left me overnight. For group video calls we still use the old Google Hangouts, as the new Google Hangouts Meet is very much a downgrade at the moment. For one-on-one meetings Slack's video call feature works quite well – I especially like the feature to draw on the other person's screen during screen sharing.
We use Trello for tracking tasks and prioritizing work, falling back to Google Docs if something needs more than a card to describe it. GitHub has been invaluable for remote collaboration, which is why I consider their acquisition by Microsoft earlier this week to be a cause for concern.
Having a fast, reliable internet connection is essential for remote-only. A good microphone helps too. And having a separate room that you use for your office helps to separate work and family life.
We try to get together at least twice a year in the same location (usually Santa Cruz), as it's true that remote work is not a substitute for human interaction. These offsites are usually reserved for prioritising tasks and overall company strategy. I also try to work from a co-working space in town at least once a week, to stave off loneliness and interact with people working on other software-related projects.
From my experience working remote for almost three years now, the benefits outweigh the disadvantages by far. If you have the opportunity to work for a remote-only company, or if you can transition your existing organisation to a remote-only one, I would highly recommend it.
