search

StephenBlackWasAlreadyTaken / xDrip-Experimental

Experimental Branches for Collaboration on DexDrip
GNU General Public License v3.0
25 stars 62 forks source link

WIP: add support for xBridge 2 with queue #363

Open savek-cc opened 8 years ago

savek-cc commented 8 years ago

@tzachi-dar

tzachi-dar commented 8 years ago

This part seems fine. We will not have duplicate packets.

As was discussed off line, There is still a lot to do (actually the more I look at it, the more to do...)

Looking more deeply at code: BgReading create() is working on current-sensor(). Current sensor might not be relevant.

Current calibration might not be the correct calibration.

Than bgReading.perform_calculations() might be called. In this function we call find_new_curve(). find_new_curve() is looking at List last_3 = BgReading.latest(3); which has nothing to do with the bg just created.

More than that: find_new_raw_curve() is also called and is also working on latest 3 points. find_slope() is working on more points.

Back to BgReading create() - there is code that is being executed after: if(calibration.check_in) { this is not relevant any more here. } else { code that is dealing with last bg reading. }

From there, code is calling BgSendQueue.handleNewBgReading() This opens call to many other services that also don't seem to handle random packets(). For example see wear_sync: looks at latest data. (List graph_bgs = BgReading.latestForGraph(60, startTime);)

My bottom line: I don't think that issues can be fixed in a reasonable time, I also don't think that there is a good reason to do that. In other words here is something that will work and solve 90% of issues: 1) Only accept packets on the order that they were captured. 2) Only accept packets for the latest calibration.

This is what wifi-wixel is doing to solve gaps, and is 100% fine for anyone that has only one xBridge in their system (99.9% of xDrip users, at least from what I know).

savek-cc commented 8 years ago

Will work as long as no one tampers with the system time - but since that would already be the case with the existing code (tampering with the clock to get values out of order) it should be fine. So basically the dupe check could be modified to make sure that the timestamp reading from a "fresh" transmission it greater than that of the last reading and the last bg. And since you should not be able to enter a calibration if you don't have a current bg value/transmitterdata, doing the check for transmitterdata should be sufficient.

tzachi-dar commented 8 years ago

This seems fine to me.