After my promising start last week in reading data from a blood glucose meter using the IEEE 11073 standard, I've come across my first hurdle. I can read the Medical Device System (MDS) attributes just fine, as well as details of the PM (Persistent Metric) store. Basically, when data is stored on the device to be retrieved at a later date, it is placed in the PM store. I'm now trying to read data form the PM store, but it's not going as planned.
It took me a while to realize that I should be reading from the PM store's segment ID 0 instead of 1. You know, the classic off-by-one issue. Now it's telling me that the meter data is being sent, but I'm not receiving it as expected. My current guess is that the issue may be with WebUSB itself after looking at this Stack Overflow thread. Basically I'm thinking that I should use an event listener to read data from a bulk endpoint, rather than polling it as I'm doing at the moment. The thing is, I'm not sure if WebUSB supports using event listeners for reading data, so now I'm reimplementing everything in regular node-usb.
This year Spotify's summary of the music you listened to over the year is called Spotify Wrapped. By far my favourite feature is them creating a playlist called “Your Top Songs of 2018” as part of it. When you've listened to thousands of songs, having an automated way of surfacing the songs that you enjoyed the most, is pretty sweet!
One thing that is a bit funny is that the “artist” that comes in third in terms of how much I listened to them, is Sleep Baby Sleep. Yes, in the first half of the year there has been a lot of music played to get the baby (now toddler) to sleep.
I have been having a fun couple of days trawling through the IEEE 11073 specs (no, really!) to implement a new USB driver for a Roche blood glucose meter. This is the first meter I've worked with that fully adheres to the standards on all the protocol layers, from using the USB Personal Healthcare Device Class specification on the transport layer, to using the ISO/IEEE 11073-20601 and 11073-10417 standards that describe the data model.
So far I'm quite impressed with the IEEE 11073 standard. Instead of forcing a manufacturer to use a specific format to describe blood glucose readings, it allows for the device to specify an extended configuration. Such a configuration, sent by the device, describes the format in which to expect the readings, for example a timestamps of eight bytes followed by an observation value of two bytes and measurement status of two bytes.
I've just parsed the Roche meter's extended configuration by hand and it goes into a lot of detail, even describing if a measurement is measured (e.g. blood glucose) or manual (e.g. meal context).
On the transport layer, there was a small hiccup as I realised two different Roche glucose meters use different USB endpoints. I then discovered that you can actually find out what the endpoint numbers are for the device you're connected to by looking at the configuration descriptor. The trick is that you needs to look in alternates:
Earlier this week I mentioned that I'm printing toys for my son's advent calendar. The Flexi Rex and bathtub boat looked great, but I'm still using the original grey PLA filament that my 3D printer shipped with.
I thought the low-poly Pikachu would be a nice next print, and wanted to switch to green ABS to do that. Changing filaments was so smooth I could hardly believe it! First you select the Unload filament option. The printer will notify you to first pre-heat the nozzle if you haven't done it yet. A couple of seconds later and you can just pull the filament out. To load new filament, you just select the Auto-load filament option. Again it check if pre-heating is required, after which you can just insert the tip of the new filament when you're ready. It feeds through automatically, and even asks you if the colour if the filament looks correct, so that you can feed through more if necessary. Man, I like it when they make things so easy!
I wear a pair of jeans for most of the year, and only owning two pairs keeps things nice and simple. That's one in the wash and one to wear. I used to love Hiut jeans that are made right here in Wales, but after I had to send them in for repairs twice, I started looking for something more durable.
I found that in Swrve cycling jeans. They're super durable and comfortable, as they're made with a cordura blend. I would have preferred something that is 100% cotton, but it turns out cotton just doesn't last that long. Most of my wear and tear happens in the crotch area, as I walk a lot, and the Swrve jeans solve this with a seamless diamond gusset. It's brilliant. Having a higher waist in the back also helps. Two pen pockets and reflective strips on the inside legs are just a bonus.
My first pair is almost two years old now, and the only area that needs to be repaired is a hole in my pocket worn out by my keys. I just received my second pair.
It's my son's second Christmas, so now that he is starting to get excited about the whole experience, we decided to make him an advent calendar. We bought a series of bags on a string that we can later re-use to hang some photos, and want to fill the bags with alternating toys and treats. The toys will be 3D-printed, and I'm basically just selecting popular designs from the Toys category on Thingiverse.
Yesterday he got Flexi Rex and tomorrow, if the print goes well, he'll get a bathtub boat.
I watched the documentary The Bleeding Edge last night, and I cannot stop thinking about it. It deals with the regulation of medical devices in the USA, and how the FDA is failing in some instances because of big pharma. It sounds like it may have a bit of a conspiracy theory vibe, but a lot of the people they speak to used to work for the FDA themselves. I do believe the FDA is a force for good and that it has a lot of people there doing good work, but I can't stop the nagging feeling that something is not right with the whole system. Not that I think the European system is any better. But it does make me wonder if there is a better, more decentralised way of ensuring that medical devices are safe and effective.
Yesterday I mentioned having Windows permission issues with a blood glucose meter that mounts as a mass storage device. After reading that someone else experienced the exact same issue while building a disk image write for Windows using Node.js/Electron, I don't feel so alone anymore.
I think I finally figured out what's going on. To make a long story short, Windows allows you to open a physical drive (e.g. \\.\PhysicalDrive1) with an exclusive lock even if there's a mounted volume, but then doesn't permit you to write to it. If you try to open using the logical name or mounted volume (e.g. \\.\E:) with an exclusive lock flag (O_EXLOCK), it fails with the error “Resource busy or locked”, but if you use FSCTL_LOCK_VOLUME to lock the volume after you opened it, it works!
It looks like one reason for this confusion is because of how Windows handles removable media differently, based on this comment from Jonas Hermsmeier:
Just remembered that the \\.\PhysicalDriveN only works for (things that act like) hard drives, not removable media. If something acts like a removable disk (or floppy, CD-ROM, etc.), \\.\X: opens the raw drive. This is due to the SD Card reader (for example) being the actual physical device, I believe. So it depends heavily on the device type.
I'm having some trouble reading data from a Verio Flex glucose meter on Windows. It seems to be some kind of permission issue, because it works just fine on macOS. On Linux we're accessing the device directly as a USB device and communicate with it using SCSI commands. This won't work on Windows, however, as it means installing a WinUSB driver for the device, which will break software that depends on the meter to be available as a mass storage device.
On Windows, the Verio & Verio Flex meters mount as mass storage devices, like a USB drive. However, you don't actually see the data as a file if you look at it in File Explorer. You have to set special permissions when opening the device and write data to it as commands in order to receive data. When I try sending commands to the device, I get a EPERM: operation not permitted, write error. It doesn't matter how I set the permissions, I just can't get it to succeed.
Strangely enough, using the same permissions, I also cannot write data to a regular USB drive. It's possible that there's just something wrong with the permissions on my computer, but I've tested it on two other machines too. It's also possible that Node.js is just not capable of setting the permissions correctly on Windows, but I would like to figure out why that is.
I'm looking at implementing a driver for some blood glucose meters that actually adhere to official standards. The Continua Design Guidelines act as a type of framework for medical device interoperability. Basically they require devices to adhere to specific standards for USB and Bluetooth LE operation.
While the Bluetooth LE specification is publicly available, including the Glucose Service descriptions required to read data from blood glucose meters, the story for the USB specifications are a little bit more complex. While the USB transport layer protocol, called USB Personal Healthcare Device Class (PHDC) is available publicly, what happens above that layer is described in ISO/IEEE standards that are hidden behind paywalls. Specifically, the .pdf file that describes the glucose meter specific parts is $94 from the IEEE store, $178 if you buy it from the ISO store, $323 from the British Standards store and $194 from the American Standards store. Standards are funded by public money, so it only makes sense that they're publicly available.
