Stelo is essentially a binned, feature-restricted version of the G7 that’s available OTC without a prescription. If you qualify for getting a G7, need readings more frequently than every 15 minutes, or have any need for high/low glucose alerts, then you shouldn’t consider Stelo at all, IMO —- it’s strictly an inferior version of the G7.
I think this might be the video you're talking about, in case anyone is also interested in a brief history of quick boot operating systems and UEFI: https://www.youtube.com/watch?v=ssob-7sGVWs
There is an entire open-source ecosystem around having direct access to your diabetes data, which predates the commercial availability of things like sharing glucose data live with others. The Nightscout Foundation (https://en.wikipedia.org/wiki/Nightscout) and Tidepool (https://www.tidepool.org/about) are two nonprofit organizations who lead development on open-source products (Nightscout and Tidepool, respectively) which help with this.
While the manufacturer-provided ecosystems function okay, they give you limited data mobility in case you switched to a different diabetes-related product like a CGM or insulin pump. They also introduce a dependency on on a cloud SaaS platform managed by said manufacturer, which can impose limitations, such as not allowing for real-time access to your data (Dexcom requires an approval process to get real-time data from their API: https://www.dexcom.com/webapi) and can have uncertain reliability (Dexcom had a notable outage in 2019, for instance: https://www.wsj.com/articles/diabetes-blood-sugar-data-outag...).
Conversely, you can run a Nightscout server on a Raspberry Pi in your home, or on a cloud server, for yourself and have full access to your data.
I’m familiar with tidepool and nightscout etc., I’m asking about using that functionality with a modern Dexcom device and app.
It is categorically untrue that you have to enable the cloud option to store/create logs and reports with the G6/G7. The app creates fantastic and easily digestible logs/reports on your phone, without any cloud processing.
Are you familiar with Loop? I believe they are currently just intercepting the Dexcom notifications rather than connecting directly over BLE by default for the G6/G7. However the xDrip + xDrip4iOS projects have gotten the G5/G6 BLE protocol to a state of being fairly well understood.
Loop, an artificial pancreas system for diabetics, has a long history in terms of its development, but for a brief summary which might be of interest to the HN audience: It began as a home-brew system, built by diabetics who reverse-engineered insulin pump firmware and control software in order to gain control of the devices which keep them alive. If you've heard of OpenAPS or the Nightscout projects, this was born out of the same community. Insulin pumps, until several years ago, could only be configured statically to adjust the insulin dosing amount which keeps a patient's blood sugar values in range. But when paired with a continuous glucose monitor, a "closed-loop" system can be created to attempt to keep sugars in range algorithmically. A group of engineers launched Tidepool, a non-profit, in an attempt to get full regulatory approval for the software which thousands were running on their devices to expand it to a wider audience, and along they way they have been able to get buy-in from insulin pump manufacturers to develop an open and interoperable ecosystem. Now, 4 or so years later, the system has received FDA clearance -- the first of its kind, not created by one specific insulin pump manufacturer or corporation but instead by a group of developers with backing from this non-profit.
Like some other commenters mentioned, this is a cool idea, however by storing JSON data inside base64, the length of the URL blows up very quickly as you start storing more state.
While technically URLs have no formal length limit, various sources suggest that URLs with more than around 2,048 characters start causing issues in browsers, and around 8,196 start causing issues in CDNs (https://stackoverflow.com/a/417184). You can work around this partially by not storing this state information in the query string (path/to?<state>) and instead using a hash string (path/to#<state>), and then extract that data in JavaScript such that it's not sent to the server at all.
IMO, the canonical way to solve this problem is using protocol buffers, which you can then serialize into a much smaller number of bytes, which is then base64 encoded. For example, as mentioned in another comment in this thread (https://news.ycombinator.com/item?id=34314578), Yahoo Finance has a 1,616 character-long URL with 1,572 characters of base64-encoded JSON state:
The un-base64'd JSON dictionary is 1,162 characters long, 569 of which is composed of just the key names (48 percent!), and most of the remaining fields likely contain their default value. If this was instead encoded in protobuf, the key names wouldn't need to be included, since fields are referenced by their field ID, and default field values would take up little-to-no space since when the default value is present it isn't encoded into the structure. I presume that, if done efficiently, you could likely make an equivalent representation in protobuf that is 1/4th or even 1/8th the size. You also get, for better or for worse, what is essentially obfuscation for free (yes, you can read out the packed format, but without an equivalent protobuf struct definition it's still hard to tell what field is which, and the entire operation becomes much more labor-intensive).
While I’m not a certified security professional, I have looked pretty closely at Tandem’s mobile pairing and remote bolus implementation and it seems to have been designed in the right way. After initializing a Bluetooth connection, the phone and pump complete a handshake wherein a 16 character alphanumeric key appears on the pump screen and you need to enter it on your phone, which then uses it as a shared HMAC symmetric key. Status information and responses then occur in cleartext once authenticated, while bolus operations require messages to be signed with the initial key.
That being said, on the chance that there is a security flaw here I’m willing to eat my words…
My partner uses a Tandem pump, and is annoyed that she can't actually use most of the features of the Tandem app because she uses an unapproved (Pixel 6 Pro) device.
Take a look at https://github.com/jwoglom/pumpx2, I’m working with the AndroidAPS folks currently to make it more broadly available. xDrip integration would happen via AAPS.
The whole setup is only secure if the phone is secure. One malicious keyboard app and the key is leaked, and now there is no security left at all.
I think such a design is only safe to human-life standards if all possible signed messages (ie. All possible messages the app could send) would be safe for the user.
My concern is that the phone could be compromised. Having a phone hacked would be bad enough without giving the attacker the option to easily hospitalize/kill you.
I mean, companies like Twitter have already been bitten (and fined!) for using phone numbers collected for 2FA purposes for advertising and monitoring purposes, which is more or less exactly your concern: https://arstechnica.com/tech-policy/2022/05/twitter-pays-150...
Definitely seems a bit disappointing that 5-6 years after the original Pi Zero there's still only 512MB of RAM. Regardless, I'm excited to see what new projects will become feasible with the extra CPU performance.
I just finished watching your YouTube video, so thanks for providing all of this insight. A new Pi Zero will certainly make small handheld emulators a lot more promising...
I don't feel like I needed more memory or the cpu boost in the pi zero 2. I'd rather they stayed at the old $5 price, decreased power consumption, and added some analog and realtime capabilities. I had thought that was the idea of the RP2440 chip used in the pi pico. It would be great if they added that chip to a pi zero board (maybe in the same SOC as the main processor) so they would have some analog inputs and a somewhat realtime coprocessor.
I've done some fairly fancy Python app development under Linux on a 300mhz embedded ARMv6 board with 64MB of ram, so for lots of things the Pi Zero is already overkill. But an actual OS (i.e. Linux) does make programming a lot easier than an MCU board with an RTOS. So how about a "Pi -1" (minus one) with 1/4 of the resources and power consumption of the Pi 0?
Power savings is complicated. A Pi board is going to have a minimum power usage with the CPU only being a portion. A lower clocked CPU on a Pi -1 might reduce peak power usage but might not get much savings at idle vs a comparably configured Zero. The Zero would also have the option of underclocking for peak power savings with the ability to spin back up to work faster to return to idle faster. Don't forget disabling board components can yield baseline power savings on Pis [0].
According to the launch post, they also couldn't find a single-die 1 GB RAM module, so they couldn't physically install more unless they upped the complexity of the design significantly.
reply