The cc111x package provides a driver for the higher level medtronic code to talk to a pump via a cc111x radio, by default over SPI (for Explorer modules or hand-wired TI sticks etc.). It also supports a UART sub-layer, for users who hand wired TI sticks via the UART lines. What was missing (until now :-) was support for talking to a RileyLink (or GNARL device) via BLE. I'm almost ready to push that code now; it's retrieving pump history etc., but waking the pump up is still problematic.
This lets you run medtronic commands like mdt and pumphistory from any Linux machine with a Bluetooth LE adapter; I'm debugging it from my desktop machine. Presumably you could run a whole openaps loop on desktop or laptop that way too.
I've only tested it with GNARL, so if anyone with a genuine RileyLink could help me test it, please PM me.
Another crazy possibility would be to run a Debian chroot on an Android phone (probably has to be rooted) and run openaps there.
Another crazy possibility would be to run a Debian chroot on an Android phone (probably has to be rooted) and run openaps there.
I've tried that before - had no end of issues with the Debian stack interacting with the phone's bluetooth stack. Would be willing to try it again though with updated drivers in OpenAPS.
And unfortunately the BLE library I'm using is not turning out to be as robust as I'd hoped, so it may be a while ...
This looks like a nice option for building a Pi Zero based rig, along with an Adafruit radio bonnet. But I haven't checked that the GPIO usages of the two are compatible. https://www.crowdsupply.com/pi-supply/pijuice-zero
Details are here in case anyone else wants to figure it out: https://github.com/PiSupply/PiJuice/tree/master/Hardware#pinout
Hello everyone ! ... I have a question regarding G6 battery life. Im using transmitter 8Jxxx and Xdrip+ on nightly. For the last 3 sensors, the connection keeps dropping with no BGs reported sometimes for hours. A restart of the phone usually restores the connection and backfill. Does this mean my transmitter battery is dying ?! Its on day 69, Voltage A 307/B 281 Resistance 8260. There are no sensor error messages
Is this one good for GNARL? I see there is a warning not to buy v2? https://www.banggood.com/no/LILYGO-TTGO-LORA32-V1_3-868Mhz-ESP32-0_96-Inch-OLED-Wireless-WiFi-bluetooth-Module-with-Antenna-p-1676698.html?gmcCountry=NO¤cy=NOK&createTmp=1&utm_source=googleshopping&utm_medium=cpc_bgs&utm_content=xibei&utm_campaign=xibei-ssc-no-no-all-1121-19bf&gclid=Cj0KCQjw9b_4BRCMARIsADMUIyr9nPtrU5Eb8tU-CS6pbVca19sh2HrmO5Aa5GXWGDAnmytiUATzW_kaAmc5EALw_wcB&cur_warehouse=CN
Hi @ecc1! Is it possible ways to build and run GNARL with custom ESP32 (ex. WROOM32) and custom radiomodule (ex. RFM95). I tried to make mmtune, but it failed, console says "No pump during scan". Pins in 'include/module.h' and 'lib/radio/rfm95.h' are correct, two ESP's can communicate to each other, but mmtune or gnarl can't work. Any work I should do more to make magic happens? Thanks
@d3xr first make sure the low-level
regtest application can read all the radio registers correctly, to verify that it's hooked up correctly. Paste the console output from that program if you're not sure of the results. If that works correctly, I'd try the sniffer application next (also console output) to receive packets from your rig or pump (to make sure you've got the right frequency, working antenna, etc.)
I'm trying to replace an old HDD with a new SSD, but the windows install won't recognize the new SSD. I've been told that maybe the older motherboard can't work with the new SSD. An online search indicates most SSD's will work even with older motherboards. Can anyone direct me to more info?
Don't need a screen. Might be usefult to be able to transfer it to a Zero if I ever need to go portable
Had a read of the docs but I think they might be a bit dated
Has a screen but the price (NZD) is OK
Doesn't seem to come with pogo pins
@old-square-eyes yes, that bonnet will work well for communicating with loopable Medtronic pumps. It has a female 2x20 header on the bottom (see the pix at https://www.adafruit.com/product/4072)
But I can't speak to how well the openaps code for the Explorer HAT display and buttons works on the bonnet, if at all
I see it now :)
I'll prepare some documentation when I find time at the weekend or so
This may be useful for anyone - Turn your pc to lightening speed in 7 steps - https://www.youtube.com/watch?v=n0odMfF2yWQ&feature=youtu.be
@old-square-eyes can't find a good place to put it in read the docs :/ ... I'll qickly write it here: You have to go to src/openaps-menu and pull the dev branch (
git chekout dev). That's it for installation. User Guide is here: https://github.com/openaps/openaps-menu/tree/dev
hope you'll like it ;)
If anybody ever thought of making their own insulin pump, here is a prototype I did (the final wearable version would be 2 Medtronic 3ml pump stacked together) :
https://drive.google.com/drive/folders/1rWr33t4Sv3KvijsWiVv9HmFOkwVrZwyU?usp=sharing
https://drive.google.com/drive/folders/1rWr33t4Sv3KvijsWiVv9HmFOkwVrZwyU?usp=sharing
I know it's a prototype, but 3d printed parts are never going to be accurate or durable enough. Some idiot out there will knock this up and decide to hook it up to themselves, and wonder why they end up in hospital when it gets a bump and delivers a huge bolus.
I'm interested in building a new rig and need to decide on the battery configuration.
Specifically I'm interested in if higher capacity 18650 batteries (pair of 3100 mAh) can be charged by the circuit. Do they go in parallel or series?
@old-square-eyes Thanks a lot for your comments. I understand your concerns but if the people that started openaps had that thinking, we would not have today the benefit of it. Approved hardware driven by “unapproved” software result in an “unapproved” system, which we are on with OpenAps. My prototype is far from a usable product, but I think a safe pump could eventually be done.
@AndreChampy thanks for emailing on this topic as well. My apologies for the delayed response. I'm including my email here for everyone else's benefit.
My main concern with an approach like this isn't security, it's safety. We simply can't guarantee that such a pump could reliably dose only the requested amount of insulin, 100% of the time. Insulin is delivered in extremely tiny (microliter) doses, and those doses have to be extremely accurate with extremely high reliability to avoid a dangerous overdose. The pump needs to be able to survive getting bumped and jostled, dropped, heated, cooled, and any number of other things, all with a 0% chance of delivering more insulin than is safe.
The FDA approval and EMA CE mark processes are designed to ensure that any manufacturer of devices intended to deliver life-saving but lethal-if-overdosed drugs follow an extremely rigorous process of design, testing, and manufacturing to make certain that overdose situations simply can't happen except in extremely rare cases. This is the kind of reliability that airlines achieve, and is simply not something that a DIY project can aspire to.
Instead, the approach that we've found to be safest is to make off-label use of FDA-approved and/or CE-marked medical devices that can be remote-controlled to deliver exactly the amount of insulin required and requested. By ensuring that we're simply interfacing with existing approved medical devices (CGMs and pumps) and asking them to do what they've been engineered and approved to do (read blood glucose and dose insulin, respectively) our open-source DIY APS's can actually improve the safety of those using them, rather than presenting lethal long-tail risks.
I would encourage you to avoid doing anything that could result in anyone using a non-medical-grade pump to dose insulin. That is a very dangerous game and simply isn't necessary: secondhand insulin pumps are still widely available, for about the same cost as building an unsafe DIY pump. And if you're worried about future pump availability, keep in mind that there are lots of new pumps still being produced that are loopable, including from SOOIL, Roche, and Omnipod.
Thanks again for your efforts to make things better and safer for everyone with T1D.
-Scott
My main concern with an approach like this isn't security, it's safety. We simply can't guarantee that such a pump could reliably dose only the requested amount of insulin, 100% of the time. Insulin is delivered in extremely tiny (microliter) doses, and those doses have to be extremely accurate with extremely high reliability to avoid a dangerous overdose. The pump needs to be able to survive getting bumped and jostled, dropped, heated, cooled, and any number of other things, all with a 0% chance of delivering more insulin than is safe.
The FDA approval and EMA CE mark processes are designed to ensure that any manufacturer of devices intended to deliver life-saving but lethal-if-overdosed drugs follow an extremely rigorous process of design, testing, and manufacturing to make certain that overdose situations simply can't happen except in extremely rare cases. This is the kind of reliability that airlines achieve, and is simply not something that a DIY project can aspire to.
Instead, the approach that we've found to be safest is to make off-label use of FDA-approved and/or CE-marked medical devices that can be remote-controlled to deliver exactly the amount of insulin required and requested. By ensuring that we're simply interfacing with existing approved medical devices (CGMs and pumps) and asking them to do what they've been engineered and approved to do (read blood glucose and dose insulin, respectively) our open-source DIY APS's can actually improve the safety of those using them, rather than presenting lethal long-tail risks.
I would encourage you to avoid doing anything that could result in anyone using a non-medical-grade pump to dose insulin. That is a very dangerous game and simply isn't necessary: secondhand insulin pumps are still widely available, for about the same cost as building an unsafe DIY pump. And if you're worried about future pump availability, keep in mind that there are lots of new pumps still being produced that are loopable, including from SOOIL, Roche, and Omnipod.
Thanks again for your efforts to make things better and safer for everyone with T1D.
-Scott
Hi all. This is probably a bit benign for hardware dev. But I need some advice from an electrical engineer. I acquired my first Pi Hat, and sourced a ZeroW. I'm disappointed to see the board won't boot with the hat positioned. In fact the C30 and C29 and/or V1 03 on the radio board get extremely hot when powered. The Pi doesn't boot at all with the hat.
Once the hat is removed the Pi boots and I can SSH to it (clean install)