Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 04 2017 03:25
    @scottleibrand banned @Prosulpump
Dave Acklam
@dcacklam
@jimrandomh I charge mine (and my watch, phone, etc) while I sleep.... I have found that trying to use USB batteries with rigs results in broken rig USB ports, personally....
But in any case, the power reboot thing is an issue for other reasons.... If you have a fixed rig with no battery, for example.....
James Babcock
@jimrandomh
Fixed in openaps/oref0#1411, which adds a config setting for the battery-shutdown threshold, which I can set to -1 (and which is easy to spot if you're carefully going through all the config settings like you should be).
I have broken one USB port on an Explorer Hat, but that was before I got a nice 3D printed case which protects the connector. The trick is that the connector on the rig side of the cable should be enclosed and never unplugged, while the connector on the battery side gets all the plug-unplug cycles.
James Babcock
@jimrandomh
Remaining significant issues, which I hope to tackle but which might have to wait a few weeks since this is competing for programming time with my dayjob:
  • Install fails on the latest version of RaspiOS, because it got rid of python2, and there's some legacy stuff hanging on that doesn't work with python3
  • Install fails if you use the installer from the master branch (as the instructions tells you), even if you're using that installer to install the dev branch, because the parsedatetime==2.5 workaround is only present on dev and it's needed before it gets to the point where the selected branch matters
Jon Cluck
@cluckj
I upgraded my old install and openaps worked fine, putting a zero 2 in was mostly drop-in replacement
James Babcock
@jimrandomh
Nice
Jon Cluck
@cluckj
I haven't had a chance to do a full install yet
James Babcock
@jimrandomh
How's the nodejs interpreter startup performance?
node --version
time node -e true
Jon Cluck
@cluckj
I won't have time to fool around with it for a while, sorry. we're moving this week
it's very fast though, like a pi 3
Jon Cluck
@cluckj
v8.10.0
and like .3s
Jon Cluck
@cluckj
we can also turn off cores to lower power consumption
Jon Cluck
@cluckj
and the extra CPU should be able to handle xdrip-js with no issue, but I haven't had time to test it :)
Jon Cluck
@cluckj
lol. the cpu is so much more powerful that even with two cores disabled it's only hitting 100% load on the other two cores for about 3 seconds during a loop
Jon Cluck
@cluckj
loads are a little higher on just one core, but maybe manageable
disabling two cores may be the sweet spot; whenever I find my usb amp meter I'll test them again
Jon Cluck
@cluckj
still under 2 minutes for non-SMB loops on one cpu
tzachi-dar
@tzachi-dar
@cluckj does this contain the sleeping (waiting for silence)? Otherwise I think that a pi 3 is much faster.
Jon Cluck
@cluckj
yeah it does
tzachi-dar
@tzachi-dar
Thanks @cluckj
Jason Curry
@mccgm
Trying a new Pi-Hat install and this is what I see about a minute into the install script:
The following NEW packages will be installed: acpi-support-base acpid gir1.2-glib-2.0 gir1.2-packagekitglib-1.0 git git-man javascript-common libappstream4 libblas3 libcurl3-gnutls liberror-perl libexpat1-dev libgfortran5 libgirepository-1.0-1 libglib2.0-bin libgstreamer1.0-0 libjs-jquery libjs-sphinxdoc libjs-underscore liblapack3 libpackagekit-glib2-18 libpcap0.8 libpython-all-dev libpython-dev libpython2-dev libpython2.7 libpython2.7-dev libsensors-config libsensors5 libstemmer0d libutempter0 libyaml-0-2 lm-sensors locate packagekit packagekit-tools python-all python-all-dev python-asn1crypto python-cffi-backend python-configparser python-crypto python-cryptography python-dbus python-dev python-entrypoints python-enum34 python-gi python-ipaddress python-keyring python-keyrings.alt python-numpy python-pip python-pip-whl python-pkg-resources python-secretstorage python-setuptools python-six python-wheel python-xdg python2-dev python2.7-dev python3-dbus python3-distro-info python3-gi python3-pycurl python3-software-properties screen software-properties-common tcpdump unattended-upgrades vim vim-runtime watchdog 0 upgraded, 74 newly installed, 0 to remove and 0 not upgraded. Need to get 723 kB/58.2 MB of archives. After this operation, 161 MB of additional disk space will be used. Err:1 http://raspbian.raspberrypi.org/raspbian buster/main armhf libcurl3-gnutls armhf 7.64.0-4+deb10u1 404 Not Found [IP: 93.93.128.193 80] Err:2 http://raspbian.raspberrypi.org/raspbian buster/main armhf libjs-jquery all 3.3.1~dfsg-3 404 Not Found [IP: 93.93.128.193 80] Err:3 http://raspbian.raspberrypi.org/raspbian buster/main armhf libjs-underscore all 1.9.1~dfsg-1 404 Not Found [IP: 93.93.128.193 80] E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/c/curl/libcurl3-gnutls_7.64.0-4+deb10u1_armhf.deb 404 Not Found [IP: 93.93.128.193 80] E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/j/jquery/libjs-jquery_3.3.1~dfsg-3_all.deb 404 Not Found [IP: 93.93.128.193 80] E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/u/underscore/libjs-underscore_1.9.1~dfsg-1_all.deb 404 Not Found [IP: 93.93.128.193 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Couldn't install packages
Any clues as to what's going on there?
tzachi-dar
@tzachi-dar
@mccgm did you try running:
sudo apt-get update --fix-missing
Jason Curry
@mccgm
Yes, I did and neither is a recognized command
Correction, the commands are recognized, but did not update or fix.
Dave Acklam
@dcacklam
@mccgm
apt-get update merely updates the package repo databases.
The command to actually download and install packages is apt-get upgrade (or full-upgrade, as it may be)
I'm also running a Pi Zero 2...
I've ordered a larger battery pack (10000mah 3x18650 vs 6,000 MAH in the same physical size), but disabling some cores might be next-up.
Also, if we are going to do significant changes to the install script, we should really get away from the oref0-net scripts & just configure/use nmcli/NetworkManager (which allows for things such as metric-based routing, so you can have BT & WiFi up at the same time and the kernel will automatically switch between them).
TranceCake
@TranceCake

hey I have a question about UAM and sensitivity detection in Oref1. I hope this is the right place.
I notice that sometimes when I have stress I get really resistant. it almost is like I ignore insulin. In this case I get hours after hours of UAM but my sensitivity almost never goes above 100%. My question is what the algorithm uses to decide if it is dealing with UAM or resistance. Or is UAM a sort of replacement for sensitivity? (would sound weird to me). I checked what the weighted average sensitivity detection algorithm (in AAPS) thought and it instantly put me at 120% sens when I switched it over.

My issue is that the AAPS docs tell you to always use oref1 sensitivity detection when you use SMB's (which I do) since the UAM has a sort of dampening effect (I read in one of both docs that it is recommended to use UAM whenever you have SMB's on, cannot find it anymore though..)
However UAM seems to do more harm than good for me. Is there a possibility for an experienced looper (2+ years) to have SMB's without UAM?

TranceCake
@TranceCake
@Foxy7 if I want UAM to be more aggressive then I'd need to set it higher though right?
Dave Acklam
@dcacklam
@mccgm Did you test connectivity. Usually when a debian system does that, it's because it can't reach the mirrors
Foxy7
@Foxy7
@TranceCake the answer to your last question is both yes and no. If you increase UAM minutes then the system will does the insulin more quickly, but will only does as much as your ISF allows, so won't be any more aggressive, but will get insulin in sooner.
Sorry misunderstood your original question, but you aren't the first person to say they are more resistant at higher bgs.
Foxy7
@Foxy7
*only dose...
What does autotune suggest vs your current settings?
2 replies
James Babcock
@jimrandomh
Is there any prior work on using OpenAPS with multiple CGMs simultaneously? (Ie two G6s on a staggered replacement schedule, cross-checking each other's readings and averaging.) I'm considering maybe giving it a shot, but I expect it to involve lots of work all over the stack, and it'd be nice to know in advance where the various software components sit on the use-as-is to moderate-refactor to full-rewrite spectrum.
Dana Lewis
@danamlewis
I’ve had it pulling from NS with two CGM, but not locally
And it just uses whatever BG points it’s getting so it oscillates a bit if the two lines are off from each other. Didn’t do any work on averaging.
James Babcock
@jimrandomh
Makes sense, and I definitely don't want it seeing the oscillation and trying to infer rates of change from that
Dana Lewis
@danamlewis
It essentially averages itself out. Not too bad and still better than not looping at all.
Foxy7
@Foxy7
Happy new year!
@jimrandomh if its just the two hour sensor warm up you want to avoid, how about running two versions of xdrip and starting the new sensor early then switching over once its working. Would mean updating Logger/Lookout for G6 serial number, but you'd have to do that anyway. And you might need to stop xdrip pushing to NS (small change to api secret?).
James Babcock
@jimrandomh
@Foxy7 It's not just the sensor warmup, it's mainly about having a safeguard against the one in ten or so sensors that underperforms. I also want to get data on how well sensors are performing in the first place; I'm particularly interested in watching the same postbrandial rise on an abdomen sensor and an arm sensor at the same time, to see if I can detect a latency difference.
Scott Leibrand
@scottleibrand
In oref0 we make sure that it only uses historical data from the same sensor to calculate deltas etc. Whichever is the most recent data point at the time it runs the loop is the one whose data is used. If you have SMB disabled, that effectively averages out the treatments based on the two sensors, in proportion to the exact timing of new data points. If you have SMB enabled, the one reading higher tends to drive the SMBs, while the other just delays them slightly.
Jon
@jonprogers
@jimrandomh I'm really interested to hear what you find about latency differences as I have a belief that I get faster G6 response from my arm than from my abdomen but have never had the cash or equipment to run two parallel setups.
In me, I believe the latency is lowest when I site on the front of my arm rather than the approved back of the arm but the flip side is that the lower latency areas also tend to show apparently noisier readings and a greater propensity for bleeders both on insertion or during the 10 day duration...
I hope you'll post what you find...
Foxy7
@Foxy7
@jimrandomh understood and it sounds very interesting. My observations are similar to @jonprogers back of upper arm appear to be best.
James Babcock
@jimrandomh
I've used abdomen and back of upper arm (not simultaneously so far), and back of upper arm seems much better; abdomen locations get compressed and sheared in common sitting and sleeping positions for me.
Jens Heuschkel
@juehv
@scottleibrand I've implemented a modified autotune binary (which is heavily based on the existing autotune binaries) to operate in the cloud (e.g. AWS Lambda or similar). Is there any interest to push it into the oref0 repsoitory? I think it may be interesting to some people