Code Limitter

[PatrickAPT]

Hi
I am working for a research group in Norway with the aim of developing an artificial pancreas.
We are currently us the Freestyle Libre to monitor some of our experiments.
To improve this monitoring and to simplify our set-up, we are intersted in using the LimiTTer to read the Libres.
However, to be able to do so, we have to fully understand the code executed by the LimiTTer. Unfortunately I am struggling with the function Read_Memory(), where the LimiTTer reads the Libre.
I know that the LimiTTer gets a string of trends from the Libre.
The big question is now how does the LimiTTer decide which is the "right" value to forward to the xDrip?
This is very important to us, as we have to know if and to what extent we can trust the data submitted by the LimiTTer.

Furthermore i built already a LimiTTer and ran a few tests. We are currently sampling every 30s and at a distance of up to 2cm between the Libre and the LimiTTer. It is working quite well, but i am getting outliers every so often (ex. constant values of 6.5mmol/l and suddenly one measurement at 12mmol/l).
I have a few ideas about those outliers:

1. Faulty bit in either NFC or Bluetooth communication
2. Oversampling of Libre (no data ready to be transmitted by the time of reading)
3. Wrong decision by the LimiTTer algorithm
   What's your opinion? Any suggestion from your side for those outliers?

Please contact me under patrick.c.bosch@ntnu.no
And if you're interested in our project: www.apt-norway.com

Thank you very much for a swift reply and have a nice day.

Patrick

[JoernL]

Hi Patrick,

The outliers issue sounds strange to me, because i have never noticed such fake readings from my sensor or have not heard from another one about such a problem. So i guess it must be the 30s scan interval. In the Read_Memory() you see the "invalid trend check" comments. I have built in that check to avoid such outliers. To answer your big question: The LimiTTer fills an array (trend[j]) with all scanned trend values and compares lastGlucose variable to currentGlucose variable (trend-pointer -1). If the lastGlucose is higher than currentGlucose it knows, that glucose is falling and fetching the smallest trend value from the array. Conversely glucose is rising. An exeption is the apex case. I have find out that the libre reader sometimes displays a rising value even when the lastGlucose is higher than currentGlucose. Then the structure of the trend values are a bit different and the LimiTTer is also taking the highest trend value to emulate the original libre reader as effectively as possible. For your APS project - if you need smoother and slower acting sensor values just take the glucosePointer value. But if you need faster acting sensor readings, don't touch the Read_Memory() function. Please let me know if a change of the scan interval solve your problem.

[PatrickAPT]

Hi Joern

Thank you for your swift reply and sorry that it took me so long to reply.
As for the outliers, I am currently very busy, but i'll check if it's due to the short sampling interval and let you know once i know more.
And thank you again for the detailed explanation.

Have a nice day

Patrick

[JoernL]

Another reason for your outliers could be that the antenna is a little bit away from the sensor. I had determined this for myself and had some outliers, too. Check it out ...

[trixing]

I think the error checking in Read_Memory should actually be done per packet which should give a more robust model. My proposed fixes for this would be

trixing@5cb9caf
trixing@5b54b0b

Let me know if you want these as pull request...

[PatrickAPT]

Hi

Thank you for the Software-Update.
I will load it onto my Limitters first thing on Monday and run some tests during the week.
And once I had a look at the data I’ll give you some feedback.

Regarding the pull request, I ‘m not very experienced with GitHub, but if it makes things easier, please do so.

Have a nice weekend

Patrick

From: trixing [mailto:notifications@github.com]
Sent: Saturday, October 15, 2016 2:29 PM
To: JoernL/LimiTTer
Cc: Patrick Christian Bösch; Author
Subject: Re: [JoernL/LimiTTer] Code Limitter (#6)

I think the error checking in Read_Memory should actually be done per packet which should give a more robust model. My proposed fixes for this would be

trixing@5cb9cafhttps://github.com/trixing/LimiTTer/commit/5cb9caf37c167098ec83bd5d51a693a61d57de51
trixing@5b54b0bhttps://github.com/trixing/LimiTTer/commit/5b54b0b063502964f575c4c9f02a2f7c18278726

Let me know if you want these as pull request...

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/6#issuecomment-253981412, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AR0A-u46SDOaPsRZn1hfcHW2Xw9-IO-uks5q0McngaJpZM4J1Af3.