Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 13 10:26
  • Nov 13 10:26
  • Oct 20 13:02
    peterlynton commented #160
  • Oct 20 13:02
    peterlynton commented #160
  • Oct 20 13:00
    peterlynton commented #160
  • Oct 10 08:28
    peterlynton opened #160
  • Oct 09 21:25
    andyrozman commented #159
  • Oct 09 21:13
    andyrozman commented #159
  • Oct 09 21:06
    andyrozman commented #159
  • Oct 09 16:16
    peterlynton commented #159
  • Oct 09 16:15
    peterlynton commented #159
  • Sep 29 19:54
    ElyeM commented #159
  • Sep 27 20:50
    ElyeM opened #159
  • Sep 24 21:00
    Emma-Black closed #91
  • Sep 24 02:07
    rkresha commented #158
  • Sep 24 01:41
    rkresha commented #158
  • Sep 24 01:29
    rkresha edited #158
  • Sep 23 21:43
    jroth-haj commented #158
  • Sep 23 20:18
    rkresha opened #158
  • Sep 18 10:11
    andyrozman updated the wiki
Andy Rozman
@andyrozman

We had this bug where time was taken when we started communication with pump, instead of taking it after pump has already finished:

  1. take time (1:00)
  2. start talking to pump (1:00, pump finishes with success at 1:03)
  3. write treatment (time=1:00)

So on pump event would be at 1:03, locally 1:00, when history runs it looks for event +/- 2 min, since Treatment is 1:00 its not found...

I fixed this so now when we write treatment time of treatment would be 1:03 (few seconds behind the pump timestamp, but that is ok)
It was just weird bug that I wouldn't have noticed, especially since when code was written, we were checking +/- 5 min, and if you have no problems communicating with pump you wouldn't have noticed either...
Andy Rozman
@andyrozman
I don't know how Loop or OpenAPS does this, because this is my implementation, that was not ported from anywhere... And since I wanted to support all pumps (also 512) we are relaying on pump history a lot.
jroth-haj
@jroth-haj
I think: Take time, start Pump communication, get time of pump, set new time to pump. Now you have the time diff of pump since last pump communication. read history and calculate time of pump history entry. Now this History entry time must be very near of real time of this Event and should match time of event in AAPS Database +/- 1 sec.
Andy Rozman
@andyrozman
This has nothing to do with time change... When time of pump and phone drifts to more than 40s (I think) we set time on pump... Yes entry on pump and local should be less and now it is...
jroth-haj
@jroth-haj
How often so you Set Pump time?
Instead of fixed checking +/- 2 min, you can dynamic check +/- time diff.
Andy Rozman
@andyrozman
I think time is checked every hour, so if you would have difference more than x seconds, time would be set...
jroth-haj
@jroth-haj
Are you able to get Pump time? Or are you anly able to set Pump time?
... only
Andy Rozman
@andyrozman
I can do both...
and I do both...
jroth-haj
@jroth-haj
Im unable to understand Java Code. :-(
So I can't so a recommendation. I try to find a logical answer for the problem.
-so + do
Andy Rozman
@andyrozman
There is no problem... Problem was fixed... You just have to use fixed branch...
Elye Mittelman
@ElyeM
I'm on fixed branch, no problem since
Andy Rozman
@andyrozman
I think there is new release planned soon, that will have this fixes...
jroth-haj
@jroth-haj
@andyrozman do you know any connection issues with MDT and jelly pro phone (Android7)?
Andy Rozman
@andyrozman
@jroth-haj No. There is a list of phones used floating around, but its not used globally just for testers... I will probably change that soon-ish... If I can find it...
jroth-haj
@jroth-haj
BTW: I tested dusabling BT. AAPS didn't recognised this. The MDT driver was running "his program" and the BT staus was still connected. Should this not be tested when the driver actions are not succesfull?
... disabling BT...
Andy Rozman
@andyrozman
You need to have BT disabled for about 10-15s (so that system settles, but that should work). When you disable BT, AAPS should take note of that and notify RL... This is the message that you should see after you renable BT (in logs): "RileyLinkBluetoothStateReceiver: Bluetooth back on. Sending broadcast to RileyLink Framework"
I am not sure what happens if BT is communicating at the moment...
jroth-haj
@jroth-haj
Just try it! Disable BT in a running system and watch the status in MDT Tab.
Andy Rozman
@andyrozman
What is your definition of running system? When system is retrieving data?
RGRT1
@RGRT1
Can anyone update on the latest situation re Rileylink/AApps/Medtronic Pump please? Ive seen a few different bits of info but not sure what is the most up to date. Also, anyone know when the update might be available to eliminate the need for a Rileylink or similar? Cheers
Andy Rozman
@andyrozman
@RGRT1 Driver is fully implemented and people are already using it. When RL will be eliminated? Never. Old pumps don't have BT access we need to talk to them, so we need to use RileyLink to convert our BT commands to RF commands that pump understands.
RGRT1
@RGRT1
Thats great, thanks for the help.
Elye Mittelman
@ElyeM
@andyrozman is the double bolus fix in the current dev? I wanna test the latest dev
Milos Kozak
@MilosKozak
yes
josevicns
@josevicns
Buenos días, necesito aclarar alguna duda... utilizo 723c de medtronic con explorer para openaps y enlite3 con transmisor de 723; estoy intentando configurar androiraps utilizando también mi rileylink. la pregunta es, cual sería la mejor manera de que todo funcione, como subo a NS los datos del sensor?
Andy Rozman
@andyrozman
english?
josevicns
@josevicns
723 no 723c *
Good morning, I need to clarify some doubt ... I use 723 of medtronic with explorer for openaps and enlite3 with 723 transmitter; I am trying to configure androiraps using my rileylink too. The question is, what would be the best way for everything to work, how do I upload the sensor data to NS?
Andy Rozman
@andyrozman
If you have CGMS on same pump that you use, then there is no way at the moment. Since most of people use something else (Dexcom Gx or Libre), this functionality was never implemented. You are actually the first person to ask about this.
josevicns
@josevicns
@andyrozmanyou see, the reason for using enlite is that my insurance finances it. Is it possible, although impractical, to keep openaps to go up to NS, but use androidapp to manage the pump? It is for testing the system.
Andy Rozman
@andyrozman
Not really. AAPS requires full access... It might work, but AAPS might fail on calls (if pump is already communicating at that point).
Andy Rozman
@andyrozman
AAPS driver calls pump every 5 minutes (same as CGMS uploader does), and reads history, so there is lot communication going on.
josevicns
@josevicns
ok, th @andyrozman
lydiaengler
@lydiaengler
where / how are issues with the Patched Dexcom App reported? I raised an issue a while back about AAPS restarting every 5 mins #2196 I closed it again as the issue went away when I reinstalled on a new phone. It just recurred, and someone on FB told me they were familiar with this and the solution was to clear the data cache for the Dexcom app and re-enter. I did this and it works, So this seems to be a bug but not sure if it is to be raised in AAPS github...or somewhere else?
Mario
@Alamo04
@lydiaengler if you want to report issues, you can do it here: https://github.com/MilosKozak/AndroidAPS/issues
yiyoMX
@yiyoMX
Hi all, which is the latest branch?
Andy Rozman
@andyrozman
I would imagine 2.6.0-RC01
yiyoMX
@yiyoMX
From AndroidAPS repo?
Andy Rozman
@andyrozman
yes. Medtronic driver was released, so everything is now in main repository...
yiyoMX
@yiyoMX
Ok, thanks, 1 more thing, is it required to use the engineering_mode file?
Andy Rozman
@andyrozman
Not anymore...
Please read instructions and follow them...