These are chat archives for nightscout/intend-to-bolus

6th
May 2019
Martin Haeberli
@mhaeberli
May 06 00:22
Recent Edison Explorer boards arrived without external antennas. At the recommendation of someone here, I ordered XF-Race antennas instead. They are bigger and bulkier. Looking for a recommendation for the ‘original’ antennas. Thx in advance.
Eric
@ecc1
May 06 01:07
Look for Anaren 1/4 wave dipole with U.FL connector on mouser or digikey
Martin Haeberli
@mhaeberli
May 06 03:27
@ecc1 thx
torhne
@torhne
May 06 03:36
So excited to have found this
I have a 712 that I have had in a box for years, now I need to get a CGM of some sort
Scott Leibrand
@scottleibrand
May 06 03:57
@mhaeberli there is also an antenna link in the OpenAPS docs. I think it’s from Mouser.
TranceCake
@TranceCake
May 06 10:03
So I'm noticing that sometimes when I have gone out of range the loop has trouble updating the pump history. This sometimes takes quite some time to resolve itself (30 mins just now) When the connection loss was a couple of hours it sometimes never recovers. I have found a fix for the latter: Deleting meal.json in monitor. I was wondering why that would work? does the loop handle getting the history differently when it has a meal history v.s. when it does not? Maybe there is a bug there in the code for the flow were it has a history?
if it's not a bug would the project benefit from a functionality that automatically deletes meal.json after a few tries? If so I would of course do the research and implementation, I was just wondering if I'm onto something.
samueldemers2
@samueldemers2
May 06 11:52
Hi to all. I've had a trouble with an edison rig. It happened twice on 3 night. When I go to bed, I plug my rig to charge it back (my 4400 mha battery last all day easily). When it finally get to 100%, the rig just power off. In the morning I unplugged the battery and plug it back in and it started back. Does anybody have an idea how to track down the problem?
When I power back the rig, I took a look at the log and it only seemed to have stop at the end of a loop.
renegadeandy
@renegadeandy
May 06 15:00
@samueldemers2 I have had something like this happen too - when charging sometimes it just randomely turns off - no idea why.
samueldemers2
@samueldemers2
May 06 15:04
@renegadeandy was it recurrent? Im considering getting my pi setup close by at night just in case.
Scott Leibrand
@scottleibrand
May 06 15:35
@TranceCake does pump-loop.log show it having any problem with meal.json during that 30m timeframe?
renegadeandy
@renegadeandy
May 06 17:52
@samueldemers2 yes it happened many times over, and still happens.
How do multiple rigs work in the same home? Does it work out of the box, with no problems?
Is that a docced scenario?
samueldemers2
@samueldemers2
May 06 17:58
@renegadeandy they should'nt interfere, but if one stop il the other one should take over. Ill give it a try without knowing when it will come handy.
Scott Leibrand
@scottleibrand
May 06 17:59
we have oref0-pump-loop good southern manners: they should politely take turns without issues
renegadeandy
@renegadeandy
May 06 17:59
i think they may interfere though, wouldn't they both run autotune etc?
Scott Leibrand
@scottleibrand
May 06 17:59
specifically, wait-for-silence allows rigs to listen to see if anyone else is speaking before they try to talk
each rig can run autotune independently
they'll both eventually converge on the same answers, if they both run against the same NS data every night
renegadeandy
@renegadeandy
May 06 18:00
So whilst one loop is running, how does the other rig know the pump is communicating, does MDT say "Pump radio busy, cancel this loop attempt?"
yeah i thought so actually
Scott Leibrand
@scottleibrand
May 06 18:01
take a look at your pump-loop.log: you'll see lots of Listening for 27s: ................................. or similar if you have two rigs
if you only have one rig running, it'll always be a single . and then immediately proceed
the No interfering pump comms detected from other rigs (this is a good thing!) message is the one that indicates that all the other rigs are now silent and it's safe to proceed.
samueldemers2
@samueldemers2
May 06 18:03
@scottleibrand so keeping 2 rig running in the bedroom could be a good solution?
Denis Shevchenko
@denisshevchenko
May 06 18:06
/var/log/openaps/cgm-loop.log said:
...
2019/05/06 14:03:47 connected to CC111x radio on /dev/spidev0.0
2019/05/06 14:03:47 setting frequency to 868.400
2019/05/06 14:03:47 model 722 pump
2019/05/06 14:03:48 CGM clock difference = 7h59m21.909667278s
2019/05/06 14:03:48 CGM clock difference is greater than 5m0s
cgm full refresh failed.
and l returns:
...
Attempting to retrieve MDT CGM data from pump
Retry 1 of mdt_get_bg
Listening for 9s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon  6 May 14:03:24 -04 2019
Retry 2 of mdt_get_bg
Listening for 14s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon  6 May 14:03:43 -04 2019
Retry 3 of mdt_get_bg
Couldn't mdt_get_bg
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 40 s silence before mmtuning
It looks like it connects to pump, so why loop failed?
We use Enlite CGM
Eric
@ecc1
May 06 18:11
@denisshevchenko cgmupdate fails if your rig and your CGM (pump) clocks differ by more than 5 minutes
Denis Shevchenko
@denisshevchenko
May 06 18:12
ops
fixed
@ecc1 Should I restart a rig after reset of date?
Eric
@ecc1
May 06 18:17
someone else will have to answer that; my impression is that it should (eventually?) recover by itself though
Denis Shevchenko
@denisshevchenko
May 06 18:17
I did it anyway
Attempting to retrieve MDT CGM data from pump
MDT CGM data retrieved
Profile less than 60m old; Profile valid. touch: failed to get attributes of 'monitor/glucose.json': No such file or directory
Couldn't touch /tmp/pump_loop_enacted -r monitor/glucose.json
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 45 s silence before mmtuning
Okay, MDT CGM data retrieved means it works, right?
I mean it can get a BG data.
TranceCake
@TranceCake
May 06 18:25
@scottleibrand yes, it repeatedly fails after 3 times trying to get pump_history_and_meal
viq
@viq
May 06 18:43

@ecc1 Should I restart a rig after reset of date?

changing timezone may require restarting services to pick that up, but "just" changing "oh, you thought it was 12:34 where in fact it's 13:57" shouldn't require restarting anything. Also, having a daemon that sets system time, for example chrony, may be a good idea.

Denis Shevchenko
@denisshevchenko
May 06 18:45
Ok, now I have this problem:
...
Profile less than 60m old; Profile valid. touch: failed to get attributes of 'monitor/glucose.json': No such file or directory
Couldn't touch /tmp/pump_loop_enacted -r monitor/glucose.json
viq
@viq
May 06 18:46
@denisshevchenko what directory are you running this in / what is the command you're running?
Denis Shevchenko
@denisshevchenko
May 06 18:48

/root/myopenaps

what is the command you're running?

Just l..

Scott Leibrand
@scottleibrand
May 06 18:48
oref0 dev or master?
Denis Shevchenko
@denisshevchenko
May 06 18:48
dev
~/src/oref0# git branch
* dev
  master
viq
@viq
May 06 18:49
ls -l monitor ?
Scott Leibrand
@scottleibrand
May 06 18:49
might be worth doing a manual run with oref0 debug enabled
@viq he means just tailing pump-loop.log
the l alias tails the log
viq
@viq
May 06 18:50
ACK, trying to figure out the system-y things, I'll let people who actually know the application take over :)
Denis Shevchenko
@denisshevchenko
May 06 18:50
ls -l monitor ?
~/myopenaps# ls -l monitor/
total 28
-rw-r--r-- 1 root root   3 May  6 14:48 carbhistory.json.new
-rw-r--r-- 1 root root 154 May  6  2019 cgm-mm-glucosedirty.json
-rw-r--r-- 1 root root  36 May  6 14:49 edison-battery.json
-rw-r--r-- 1 root root  75 May  6 14:49 meal.json
-rw-r--r-- 1 root root  75 May  6 14:49 meal.json.new
-rw-r--r-- 1 root root  10 May  6 14:49 medtronic_frequency.ini
-rw-r--r-- 1 root root 717 May  6 14:49 mmtune.json

might be worth doing a manual run with oref0 debug enabled

How can I preform it? Or where can I read about it?

viq
@viq
May 06 19:02
The latter has Manually run oref0-pump-loop with debug enabled. cd ~/myopenaps; killall -g oref0-pump-loop; OREF0_DEBUG=1 oref0-pump-loop
So cd ~/myopenaps; killall -g oref0-pump-loop; OREF0_DEBUG=1 oref0-pump-loop
Denis Shevchenko
@denisshevchenko
May 06 19:07
oref0-pump-loop: no process found

Starting oref0-pump-loop at Mon May  6 15:04:37 -04 2019 with 12 second wait_for_silence:
MDT CGM configured; not waiting
Listening for 12s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon May  6 15:04:50 -04 2019
Preflight 2019/05/06 15:04:52 connected to CC111x radio on /dev/spidev0.0
2019/05/06 15:04:52 setting frequency to 868.350
2019/05/06 15:04:53 waking pump
2019/05/06 15:05:04 model 722 pump
2019/05/06 15:05:04 disconnecting CC111x radio on /dev/spidev0.0
OK. 
Attempting to retrieve MDT CGM data from pump

Starting oref0-mdt-update at Mon May 6 15:05:04 -04 2019:
Most recent cgm record: {"sgv":null,"dateString":"2019-05-06T21:59:00-04:00"}
cgm data < 2.5m old
Completed oref0-mdt-update at Mon May 6 15:05:04 -04 2019
MDT CGM data retrieved
Profile less than 60m old; "mmol/L"
"exchanges"
"mmol/L"
"00:00:00"
8
Profile valid. touch: failed to get attributes of 'monitor/glucose.json': No such file or directory
Couldn't touch /tmp/pump_loop_enacted -r monitor/glucose.json
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 37 s silence before mmtuning
"HAT Display Updated"
Listening for 37s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon May  6 15:05:43 -04 2019
Listening for 37 s silence before mmtuning: Listening for 37s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon May  6 15:06:21 -04 2019
mmtune: 2019/05/06 15:06:22 connected to CC111x radio on /dev/spidev0.0
2019/05/06 15:06:22 setting frequency to 868.350
2019/05/06 15:06:23 model 722 pump
2019/05/06 15:06:23 frequency set to 868.150
2019/05/06 15:06:24 frequency set to 868.200
2019/05/06 15:06:26 frequency set to 868.250
2019/05/06 15:06:27 frequency set to 868.300
2019/05/06 15:06:28 frequency set to 868.350
2019/05/06 15:06:29 frequency set to 868.400
2019/05/06 15:06:29 frequency set to 868.450
2019/05/06 15:06:31 frequency set to 868.500
2019/05/06 15:06:32 frequency set to 868.550
2019/05/06 15:06:34 frequency set to 868.600
2019/05/06 15:06:35 frequency set to 868.650
2019/05/06 15:06:37 frequency set to 868.700
2019/05/06 15:06:38 frequency set to 868.750
{
  "scanDetails": [
    [
      "868.150",
      0,
      -128
    ],
    [
      "868.200",
      0,
      -128
    ],
    [
      "868.250",
      0,
      -128
    ],
    [
      "868.300",
      3,
      -74
    ],
    [
      "868.350",
      3,
      -65
    ],
    [
      "868.400",
      3,
      -65
    ],
    [
      "868.450",
      0,
      -128
    ],
    [
      "868.500",
      0,
      -128
    ],
    [
      "868.550",
      0,
      -128
    ],
    [
      "868.600",
      0,
      -128
    ],
    [
      "868.650",
      0,
      -128
    ],
    [
      "868.700",
      0,
      -128
    ],
    [
      "868.750",
      0,
      -128
    ]
  ],
  "setFreq": 868.35,
  "usedDefault": false
}
2019/05/06 15:06:39 disconnecting CC111x radio on /dev/spidev0.0
"868.350", 3, -65 
waiting for 10 second silence before continuing
Listening for 10s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon May  6 15:06:58 -04 2019
Done waiting for rigs with better signal.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Mon May 6 15:06:58 -04 2019
grep: monitor/temp_basal.json: No such file or directory
"HAT Display Updated"
Done
Alfredo kachy
@kachytronico
May 06 19:27
Hello again. I'm re-assembling a rig with edison, jubilinux 0.3 and when I hit the Bootstrap script ... it gives me several different errors. I have reinstalled from the beginning and it gets stuck in "apt-get update"
sudo apt-get update && sudo apt-get install yarn


Hit:1 http://security.debian.org stretch/updates InRelease
Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease              
Hit:3 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch-backports InRelease
Hit:5 http://cdn-fastly.deb.debian.org/debian stretch Release
Hit:6 https://deb.nodesource.com/node_8.x stretch InRelease
Reading package lists... Done
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
viq
@viq
May 06 19:28
Try what it tells you, dpkg --configure -a
Alfredo kachy
@kachytronico
May 06 19:28
The disc has been ejected. This rig took months running without problem.
Help please.
and then from where I continue?
viq
@viq
May 06 19:29
@kachytronico try what it tells you, dpkg --configure -a, and then re-run the install script again, it should be able to continue, at least past this error
Alfredo kachy
@kachytronico
May 06 19:30
ok @viq
is what I did before and then gave another error. cross our fingers!
Alfredo kachy
@kachytronico
May 06 19:57
finished, Gracias
Alfredo kachy
@kachytronico
May 06 22:50
A different question.
A different question Can I change the pump simply by editing the serial number here?
cd ~/myopenaps && nano oref0-runagain.sh
What is the best way to switch between two rigs working?
Scott Leibrand
@scottleibrand
May 06 22:58
two rigs with the same pump?
you can edit the serial number and re-run oref0-runagain.sh, yes
Alfredo kachy
@kachytronico
May 06 22:59
I have two rigs and two pumps.
I want to know what to do if something fails
Scott Leibrand
@scottleibrand
May 06 23:00
then yeah, you can reconfigure one or both rigs with the other pump serial number at that point
Alfredo kachy
@kachytronico
May 06 23:00
I did it a while ago and it does not connect.
Starting oref0-pump-loop at Tue May  7 00:59:02 CEST 2019 with 27 second wait_for_silence:
Waiting up to 4 minutes for new BG: ls: cannot access '/tmp/pump_loop_completed': No such file or directory
Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Preflight OK. Profile less than 60m old; Profile valid. Refresh
I try to connect the pump that I have running with me to a new rig that I just configured with Logger.
I had it working with the other pump and when editing I have restarted but I think it is giving some problem.
Scott Leibrand
@scottleibrand
May 06 23:05
did you re-run oref0-runagain? or just edit it?
that re-runs the entire oref0-setup process
Alfredo kachy
@kachytronico
May 06 23:05
I just edited to keep all the other configurations
Scott Leibrand
@scottleibrand
May 06 23:07
sounds like you're trying to do something different than what the software expects, then
either you need to keep using the same pump, you need to edit oref0-runagain and actually run it again, or you'd need to find all the instances of the pump serial number and edit those in place (preferences.json is one I think, but may not be the only one, depending on what version of oref0 you're running, and how good my memory is)
Alfredo kachy
@kachytronico
May 06 23:11
I installed it today, it must be the last one of the master branch.
I think it's something with the temp file. But I do not have much idea. I will let you advise for you.
root@edisonhost:~# npm list -g oref0
/usr/lib
└── oref0@0.6.3 
`
Scott Leibrand
@scottleibrand
May 06 23:13
if you're using master, I would advise just re-running oref0-runagain if you want to go ahead with changing the pump serial number
unless you're already familiar with grep -r and crontab
Alfredo kachy
@kachytronico
May 06 23:15
I do not, sorry and thanks.
I'll go back to the other one. When I have a tested logger I will try other things.
thank you.