stephenblackwasalreadytaken / xdrip-experimental Goto Github PK

Currently running/using;
Dex G4 platinum
Android 5.0
XDRIP Beta v2.0.5_1 update 1

There seems to be some issues with the widgets data plotting. Screen grabs attached.

Also, I've been wondering if we will ever include raw data in the widget as well.

Thanks in advance for any help/ideas!
-Adam

When the phone's screen is off (still running/connected), quite often NightWatch/Wear updates late.
This does not happen, when the phone's screen is on or it is connected to Android Studio. Turning it on (pressing button) leads to a quick update.

Logcat shows, that a delay seems to happen between receiving the data from the wixel and reaching it through to BgReading and BGSendQueue to finally send it.

The first marked 2 lines (around 00:12 ) show, that there is a delay of more than a minute between the calls of BgReading and BgSendQueue.

The second marked 2 lines show that BgReading is reached about a minute later than the reading usually arrives there following the 5-minute-pattern.

I believe this is to be much worse when not logging to local file. But without logs I cannot prove it 😉

--------- beginning of /dev/log/main
--------- beginning of /dev/log/system
...
06-11 00:08:48.273 3391 3402 D BgReading: Calibrations, so doing everything
06-11 00:08:49.553 3391 3402 D BGSendQueue: New value added to queue!
06-11 00:12:56.701 3391 3402 D BgReading: Calibrations, so doing everything
06-11 00:14:13.514 3391 3402 D BGSendQueue: New value added to queue!
06-11 00:17:33.476 3391 3402 D BgReading: Calibrations, so doing everything
06-11 00:17:35.136 3391 3402 D BGSendQueue: New value added to queue!
...
06-11 02:52:34.167 3190 3204 D BgReading: Calibrations, so doing everything
06-11 02:52:34.897 3190 3204 D BGSendQueue: New value added to queue!
06-11 02:57:54.483 3190 3204 D BgReading: Calibrations, so doing everything
06-11 02:57:57.123 3190 3204 D BGSendQueue: New value added to queue!
06-11 03:03:00.236 3190 3204 D BgReading: Calibrations, so doing everything
06-11 03:03:01.186 3190 3204 D BGSendQueue: New value added to queue!
06-11 03:08:04.549 3190 11365 D BgReading: Calibrations, so doing everything
06-11 03:08:05.759 3190 11365 D BGSendQueue: New value added to queue!
06-11 03:13:59.580 3190 3203 D BgReading: Calibrations, so doing everything
06-11 03:14:01.060 3190 3203 D BGSendQueue: New value added to queue!

edit: Here an example where the watch showed a 10 minute old value, a 5 minute old value and the new value - all within seconds:
06-11 03:37:40.307 3190 3203 D BgReading: Calibrations, so doing everything
06-11 03:37:41.457 3190 3203 D BGSendQueue: New value added to queue!
06-11 03:45:14.011 3190 11540 D BgReading: Calibrations, so doing everything
06-11 03:47:33.918 3190 11540 D BGSendQueue: New value added to queue!
06-11 03:47:35.818 3190 11485 D BgReading: Calibrations, so doing everything
06-11 03:47:37.258 3190 11485 D BGSendQueue: New value added to queue!

I would prefer if the notification used a lower priority. I think this makes sense since xDrip is a long-running app, opposed to a notification that requires user attention. Along with that, the icon does not need to be displayed constantly in the status bar.

The functionality to create a priority notification for alarms already exists, so currently it results in two icons in the status bar. Since the goal of showing a notification icon is to get your attention, it would not be good to desensitize the user to it.

I believe that setting a low priority pinned notification will not display the icon in the status bar, but will still show the notification in the notification drawer.

Hey guys,
So you have been doing some super awesome stuff but I feel like Im bottle necking progress and we need some more flexibility in our development path. I also feel like together we can make things better than working on things separately , so now we have our Experimental repo, I added a few branches for some of the currently existing works in progress, I feel like if we keep master clean then we can use this for setting up releases and making sure they are well tested before they hit the main repo.

Standard practices, Please review each others PRs if you have a few spare cycles, if you get the thumbs up from at least one other person feel free to merge into its respective branch.

• Do not merge anything you didn't write
• Wait for the thumbs up from someone else before merging your own work
• Only merge into feature branches until things are steady tested and people are happy with it
• When things are complete then put up a pr for that branch against master

I will move things from here into the main repo once we are good to go!

If you need anything please let me know, if you have any questions please let me know!!

Situation: 170 double down.

2 programmed alarms: 120 and 170

• Trending/smart snooze didn't work: double arrow down and still alarm went off. I didn't check which one it was when dismissing it, but snoozed is the 170mg/dl one.

Built: 7702ec0 (current master + 1 wakelock added)

Hi,
I am using xDrip App (Beta5 v2.0.5_1 update 1) on a Moto G with Android 5.0.2.
After installing the version App (Beta5 v2.0.5_1 update 1) two days ago it worked fine for about 24 h. Then no data was received by Azure any more. I tried to restart the Azure service and the phone. But both did not help.
If I try to open Recent Errors/Warnings in the preferences the phone screen freezes black and no information is displayed. I have to shut down xDrip app manually and restart it. Other apps can be used during the xDrip app freeze.
Unfortunately I am a user, so I cannot check were the problem is and would by happy of any assistance. Thanks.
xJoe

Some kind of message instructing a user to forget the previously-paired device would be helpful.

After one missed Reading, the Widget shows the delta for the last 10 minutes.

The watch seems to divides the delta by two to represent a 5 minute period again.

... like in NightWatch.
I think the TextView that shows "signal missed" could be used. (No problem IMHO if "signal missed" and "x Minutes ago" are mutual exclusive).

I had a low battery warning (finally reached 204), replace the transmitter, but the low level battery warning stays.
The only way to remove it was to disable the battery warning in the settings, stop the application and relaunch it.
I notice in https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/blob/master/app/src/main/java/com/eveningoutpost/dexdrip/Models/Sensor.java#L98
as long as sensor.latest_battery_level is not set to 0, the alarm will stay.
So I think while installating a new transmitter (ie while changing the transmitter id) the sensor.latest_battery_level is not set to 0.
Note that I use as hardware source "Bluetooth Wixel" because I have an xdrip without resistors. But the change the transmitter id on the xdrip, i switch it to xBridge Wixel, change the id, then back to bluetooth wixel.

I'd prefer to use xdrip as a silent bridge from my receiver to my watch. The non-configurable low alarm is loud and difficult to quiet when compared to the dexcom. Please allow turning it off, even if just for users of the official receiver.

The low alarm also seems to fire spurriously, i've not been able to correlate how/why that occurs.

I was wondering if there were any plans to update/match the GUI's of xDrip and Nightwatch.

As an example, the statistics page in Nightwatch is better than the statistics page in xDrip. (Button interface)

There is also a center weighted 4x1 widget available in Nightwatch that is not available in xDrip.

My dream/wish is that visually, other than the app name, and the various settings required by xDrip, that the two apps look/feel/function equally.

Thanks for the time/cconsideration!

We have had an issue where a hypo was not alerted.

Here is the situation:

1. intercept is a very big negative number (for example -60).
2. due to noisy sensor, there is no alert, (or actually alert is on the wrong time, when bg is still high).
3. when snoozing is over, bg is already on 9, which means that there are no alerts for it.

It seems that the main issue starts from the code:

public static BgReading create(double raw_data, double filtered_data, Context context, Long timestamp) {

        if(calibration.check_in) {
            double firstAdjSlope = calibration.first_slope + (calibration.first_decay * (Math.ceil(new Date().getTime() - calibration.timestamp)/(1000 * 60 * 10)));
            double calSlope = (calibration.first_scale / firstAdjSlope)*1000;
            double calIntercept = ((calibration.first_scale * calibration.first_intercept) / firstAdjSlope)*-1;
            bgReading.calculated_value = (((calSlope * bgReading.raw_data) + calIntercept) - 5);

        } else {
            BgReading lastBgReading = BgReading.last();
            if (lastBgReading != null && lastBgReading.calibration != null) {
                if (lastBgReading.calibration_flag == true && ((lastBgReading.timestamp + (60000 * 20)) > bgReading.timestamp) && ((lastBgReading.calibration.timestamp + (60000 * 20)) > bgReading.timestamp)) {
                    lastBgReading.calibration.rawValueOverride(BgReading.weightedAverageRaw(lastBgReading.timestamp, bgReading.timestamp, lastBgReading.calibration.timestamp, lastBgReading.age_adjusted_raw_value, bgReading.age_adjusted_raw_value), context);
                }
            }
            bgReading.calculated_value = ((calibration.slope * bgReading.age_adjusted_raw_value) + calibration.intercept);
        }
        if (bgReading.calculated_value < 10) {
            bgReading.calculated_value = 9;
            bgReading.hide_slope = true;
        } else {
            bgReading.calculated_value = Math.min(400, Math.max(39, bgReading.calculated_value));
        }

}

In this case, at least when things are not coming from share, we should not have values under 39 even if the calculation gives <10.

More than that, it seems to me (needs some more checking) that this function will never be called from share, only from wifi, or bt code, so fix should be easy.

Thoughts?

Can this be called from the share?

Depending on the configuration when the watchface was selected it will still show the mg/dl-value as delta or simply "--- mg/dl".

@tzachi-dar made some timing improvements half a year ago - se old closed issue "Unstable Wifi Wixel #162"'

Setup: 2 RPis with Wixels in house + Samsung S3 with wixel and hm11. xDrip with BT+Wifi setup. Wifi + mobile data always on.

We have been running rock solid with Wifi and BT on my daughters phone with Tzachi-dars code, but last week we updated to xDrip Experimental 2 Beta 5_1. Started getting the same gaps in captured values with BT. All fine inside house when the phone gets values from RPIs.

When she leaves house for kindergarten we get 1-3 missed packets an hour. The packets are captured by the Wixel (quite sure since it stops blinking) - but they are not in xDrip (also tested this at home when I entered fake IPs for RPIs).

Previously we used Dexterity - in issue #162 the values were hidden somewhere in the database (an export and re-import showed the missing values).

I'm not quite sure if Tzachi-dars improvements were actually merged into the new Beta 5? Guess this only is relevant for those running BT+Wifi (few?)

Last few days we've been running xDrip+ from @jamorham, same error there, but syncs nice to the xDrip+ app on my phone (I can now do calibrations from my phone).

These are the things I found:

1) setupCharts() is called multiple times during startup
Possible solution is simple:
Just call setupCharts() once for each update

• displayCurrentInfo() -> set private.
• setupCharts() -> just called at beginning of updateCurrentBGInfo() and not from anywhere else;

2) Home.onCreate() calls collectionServiceStarter.start().
So every time we open the App (Home), at least the onStartCommand() function of the corresponding service is called.
Do we need that? We have failover timers and to intentionally restart the service you can go to the SystemInformation. And xDrip already works without opening Home as uploader or for hours just with a watch as display.
With xBridgeWixel and btWixel this also has the sideffect, that lastdata will get set to null (thus deactivating duplicate package detection). And at least we are pushing the failover timer. Also, if "Send to Pebble" is activated, it will start the Pebble sync.

3) Having "Send to Pebble" activated (without having a pebble for this test) reproducibly will call PebbleSync.onStartCommand() TWICE when starting the Home activity (by click on the widget or icon/launcher).

• this happens shortly after Home.onResume() ends
• The data on the home screen does not show until these calls finish. (time consuming as it creates BGGraph-Builder instances that query the database for all values for the chart). Here a Stacktrace:

            at com.eveningoutpost.dexdrip.UtilityModels.PebbleSync.onStartCommand(PebbleSync.java:64)
            at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:2711)
            at android.app.ActivityThread.access$2100(ActivityThread.java:139)
            at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1297)
            at android.os.Handler.dispatchMessage(Handler.java:102)
            at android.os.Looper.loop(Looper.java:136)
            at android.app.ActivityThread.main(ActivityThread.java:5103)
            at java.lang.reflect.Method.invokeNative(Native Method)
            at java.lang.reflect.Method.invoke(Method.java:515)
            at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:790)
            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:606)
            at dalvik.system.NativeStart.main(Native Method)

At the moment I don't know why this happens TWICE. Once it is because of 2) This is one for @jstevensog?

4) BgGraphBuilder is used in multiple places for things like getting the unitizedDeltaString.
Every time, a new instance is created. A new instance always automatically sets up all the data for the chart.
Possible solutions:

• Make the needed functionality static
• Or: generate a separate Utility class
• Or: both of the above

5) Home.onCreate() calls IdemPotententMigrations every time Home is started. This will only take 10 to 20ms so not much of a problem regarding the time, but I still think it would be better placed at the start of the xdrip-Application (xdrip.java - where Crashlytics are started also)

Resolving 1) and deactivating send-to-pebble (3) and parts of 2)) gave me a speedup from 3.0 +-0.3 seconds to 1.4 +-0.3 seconds. That's something I can live with.
Please comment and discuss the above points and how we should proceed. I will definitely resolve 1) but what about 2) to 5)?

I see this is already in progress, but might as well track it

There is a small difference in the devicestatus format between Rest API and Direct Mongolab upload.

1. If you use direct Mongolab upload from within xDrip your battery status will not show up in yoursite.azurewebsites.net
2. If you use Rest API upload from within xDrip your battery status will show up in yoursite.azurewebsites.net

The battery status is the uploader phones battery status when the wixel is inside the phone.

The image below shows the difference.

This error is with cgm-remote-monitor version 8.4. When I use cgm-remote-monitor version 8.2 both cased above will actually show the battery status! I guess there must have been changes in cgm-remote-monitor.

I have a Oneplus One and recently updated my phone to CM13 and cannot get the dexcom share to sync via bluetooth to any of the Xdrip builds, including the latest experimental branches. Every time I connect it seems to pair for a few minutes then I get a error 133 or "no bluetooth device to try and connect to". In addition, while the app seems to think that the share device paired successfully I never get a notification in the actual settings showing a successful pairing completed (ie no smart lock notification).

I have noticed when running xDrip on an Xperia Z3 that there is an excessive amout of BTLowPower (Sony stock firmwares) or bluesleep (AOSP-derivative firmwares) kernel wakelocks reducing device deep-sleep percentages significantly.

I enabled the Bluetooth HCI Snoop Log (Settings->Developer Options) and then paired my Dexcom Share receiver, let it collect data for 30-40 minutes and then loaded the results in Wireshark. (Note: A lot of data will be missing/uninterpreted in the snoop log if you do not reboot the device after turning it on, and also Wireshark won't parse some data if you don't monitor the pairing sequence.)

It appears that xDrip is fully resyncing the entire device database every 5 minutes? There's a LOT of data being transferred for just one reading. Also, is the heartbeat necessary/can this be disabled?

How was the protocol for Share2 reverse engineered? It appears from what I can figure out in the xDrip source code there's a lot of commonality between the Share2 protocol and the Dexcom receiver's USB protocol? Is there any readable documentation on what is known about the Share2 protocol anywhere? The use of the rxjava library makes attemptRead() at https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/blob/master/app/src/main/java/com/eveningoutpost/dexdrip/Services/DexShareCollectionService.java#L260 almost impossible to follow ( http://reactivex.io/RxJava/javadoc/rx/functions/Action1.html is completely and totally uninformative... ) - it looks like it's receiving data in this subroutine but what commands the receiver to send it?

Was Share2 REd by assuming commonality with the USB protocol, or did someone use a Bluetooth sniffing setup such as the Ubertooth One ( https://github.com/greatscottgadgets/ubertooth ) and crackle ( https://lacklustre.net/projects/crackle/ )?

Edit: Is there an IRC channel somewhere that the xDrip developers use to communicate/coordinate? #xdrip and #nightscout on Freenode are 100% empty, so obviously not there. :)

In the EditAlert there should be "use vibration" checkbox. Sometimes vibrations are louder than chosen alarm sound.

I had removed an older beta and installed the newest version and now the alarm icon in my notification bar will not turn off.I am not even sure that Xdrip is causing it.I was previously using Xdrip with nightscout and now I am just using the Xdrip beta.

@swissalpine contacted me, that the widget does not show numbers when switching to or from lock screen.

I have the suspicion, that my "open app when tapping on widget" might be the reason....

Many german users love to use "speak readings" very often per day.
Unfortunately the swich on/off under Settings is not so comfortable.

I would like to request a new feature:

Create a shortcut from main navigation to "bg speak readings".

Would be happy if this could be realized

• BgGraphBuilder - make many methods static or refactor them to a separate class (no need to load all data for the graph to unitize one value e.g.)
• Play-Service versions for wear integration are pretty old and versions for "app" and "wear" do not match.
• Integrate raw values - remove redundency to calculate "Nightscout-raw" and NS/DexCom calibraion format for:
  • local broadcast
  • wear integration
  • upload to Share
  • upload to NightScout
• Integrate charging mode that turns the screen by 90° when watch is in the night-stand charger.
• NightWatch has Activities of module "mobile" in the "wear" manifest. (delete them)
• better wakelocks when sending data to the watch (not just a 15 seconds timeout wakelock)
• Make timestamps of type long not double (especially in former NightWatch parts but xDrip still is not free from that)
• Maybe: triggering a resend to wear from the gui could start a background thread "earlier" (not just for sending like now, but also for preparing the data).
• Helper Methods fragmented over 'WatchUpdaterService.java' and 'BgGraphBuilder.java'.
• Quite a few utility methods are of type: (already marked some)

if(booleanExpression){
    return true;
else {
    return false;
}

• PebbleSync has no wakelocks
• Pebble has a "resend to watch" function on NightWatch but not on xDrip.

Running on a Moto 360 Sport. I noticed after the recent Marshmallow push to the watch last week, the Android Wear watch face no longer works. I get a note: "Unfortunately, XDrips Prefs has stopped.", and the watch face goes black. Android wear buld MEC23G. The app on the phone works just fine. Any thoughts?

I'll just list what I find that stops xDrip from working on a small watch:

Missing vertical scrolling:
activity_start_new_sensor.xml
activity_stop_sensor.xml
activity_double_calibration.xml
....

Missing horizontal scrolling:
activity_system_status.xml
...

I miss an alarm setting. In the stable xDrip I get a message in the status line for each measurement, ie every 5 minutes, even if I do not touch the smartphone.
In the xDrip-Experimental I couldn't realise that. Here the message appears much more frequently, unless I confirm every alarm.
Background of my request is that I could read the alarm messages on my clock (Garmin VivoActive) and I don't like to take the smartphone out of my pocket. If I don't confirm the message appears about every minute, which is too often for me.
My xDrip configuration is this:

I hope I will find that on xDrip-Experimental too.
Thank you!

Hi all,
Just putting this information here so it is not lost. This is regarding the change in the Pebble xDrip watch face UUID. Users who have already installed the watch face need to be advised of the following:

1. Once you install Beta 2.0.1, your pebble watch face will no longer function until you install the new watch face.
2. Remove the old watch face prior to installing the new one. Do this from your Pebble or Pebble Time app on xDrip mobile phone.
3. Install the new watch face by browsing to this link on your mobile phone. https://apps.getpebble.com/applications/55b97282a06a0eb253000094.

Cheers

Version: Beta5, 2.0.5_1

Hi,
I observed a behaviour about sounds and alerting of xDrip-App.

To reproduce the observation:

1. Settings / Bg Alerts Settings / Bg alerts profile : „Ascending“
2. Settings / Speak Readings: activated
3. Plug earphones into mobile, respectively your ears, switch on the radio (or play mp3-file).
4. Do something that lets your BG fall below your alerting value. (Such like riding a bicycle.)

What I observed:

1. First, xDrip will tell the BG values. (What is fantastic and as expected.)
2. In case of BG falls below the first value for alerting, the radio will suddenly be switched of, or better: the volume will be switched to minimum.
3. If you do nothing, it will take some time, until the volume will come up with the next interval of BG alerting.
4. I had this experience with "xDrip default sound" as well as with a manually selected "System sound/Alarm".

If I had a free wish:

1. It is correct and expected that the first alert interval would be with minimum volume.
2. I would prefer, if xDrip could detect the current volume setting, before changing it to minimum, “play” the alert sound and then change back to originally defined volume.
3. This would allow me to ride the bike (and listen to the radio/mp3-file) until there is a situation, that allows to stop and take care about the alert. Because the mobile is well stored in a pocket, I cannot acknowledge the alarm while riding the bike. But I would prefer to listen to radio (or e.g. an audiobook) until I decide to stop.

What would you say - is this a behaviour that could be changed?
Best regards, fezulin

I really like the raw data in NS, an option to show raw data on the xDrip main graph for all data sources that provide it would be great (at least for xBridge Wixel).

since update of my os android to version 5 I can not identify where to add the value of my glucose...
the background is greywhite and the letters are white...seems a problem of the updated os version?
maybe it can changed in xdrip progr. to another color???
thanks for help..i can not write one line of progr.sorry

Bug report via chat with @KeesaKat / Marybeth:

1. xDrip doesn't broadcast to NightWatch (and HAPP), if the value is not calculated ("???").
   That would be good to have as NightWatch in recent versions can show raw values as well.
2. The local broadcast does not broadcast raw but copies the value if used with a share receiver.

From the screenshot from newer phones you can see, that there is no icon:

I don't know if it is due to the higher screen resolution / pixel density or the new version per se.

Hello.. I installed the latest beta version at the same time as I changed the transmitter.. Running an xDrip (not share), and everything works except it keeps saying Transmitter battery very low on the phone.. If I go into the status menu it says Transmitter battery - OK

Any ideas on how to get rid of the message?

/Samuel

This happens with the version before the Commits from the 27th and 28th of May today's master branch:

I have two high-Alerts during the day (7 to 22 o'clock): One non-annoying (short SMS notification sound) at 120mg% and another at 175mg% with real alarm sound.

When after a snoozing period ran out, the bg is between those two levels, the annoying alarm goes off even though the BG is just above the notification level.

Please drop a line or close the if this was already changed in the mean time. I'll test again with the current version, but it might need some time to actually reproduce this situation in real life. edit: I reproduced it with today's master branch.

PS: I really like the new alarm system! Thanks a lot.

It appears that Xdrip sets an upcoming alarm every 5 min or so that is displayed/overrides any real alarm clock times shown on the lock screen/status bar. Is this side effect necessary for Xdrip to work on Marshmallow (CM13) devices? It is a bit annoying not being able to quickly verify that a morning alarm is set correctly without entering the actual clock app but I understand if this is the only way to ensure that bg values get transmitted to the phone.

After I upgraded from v2.0.0 experimental to Beta 3 and Beta 4(never used Beta2) xDrip has missed a lot of readings from Dexterity. Dexterity collects them as normal, but xDrip does not pick them up from 127.0.0.1:5005.

The strange thing is that xDrip collects all values from to other Wifi Wixels connected to Raspberry

The system was very stable on v2.0 experimental for months, no change in Dexterity or phone. xDrip now picks up maybe 1 in 3 packets from Dexterity, might be less.

I dont have logs enabled - seems like the error is that "could not read anything from 127.0.0.1:5005" when this happens (there was new data in Dexterity continuosly every 5th minute) - the app seems slower after the upgrade, will turn logging on (but read somewhere that this will increase workload on the phone)

To point your existing forks here you can
open your existing DexDrip forks and do:
git remote add experimental https://github.com/StephenBlackWasAlreadyTaken/DexDrip-Experimental.git
then
git fetch experimental
checkout a new branch if you are currently doing work on master (Please dont push up your master!!!)
git checkout -b DexcomShareSupport << (obviously put in what you are actually working on)
git push experimental DexcomShareSupport << (again, dont push to master, push to experimental yourbranch)

Dexcom is in the process of replacing G4 Platinum transmitters with the new Bluetooth LE-enabled G5 Mobile transmitters.

While I have not yet updated my Share receiver to support the new G5 Mobile system, the documentation implies that Share functionality will be removed from the receiver as part of the process of updating it to work with the new BLE transmitters. To some degree this makes sense, as the official Share app is only available on platforms (iOS) which have the new G5 Mobile display app which can communicate directly with the transmitter.

It appears from the documentation (indicating that calibrations should only be entered into one display device) that the G5 transmitter is indeed performing the processing of raw data onboard. Perhaps the protocol is similar to the existing Share protocol, but now there needs to be support for sending calibration data to the transmitter.

Unfortunately my understanding of the xDrip codebase is severely limited because rxjava makes it nearly impossible to understand what's actually going on. I have been considering investing in a Bluetooth sniffer such as the Ubertooth One so I'm willing to collect some data traces of the protocol, but I'll need some assistance from someone who knows how the current BT protocol implementations in xDrip operate in terms of how to integrate those discoveries into xDrip.

ArmTimer is based on activeBgAlert.next_alert_at;

on ClockTick()
There is a test checking next_alert_at by the function:
if(activeBgAlert.ready_to_alarm()) {
...
...
long nextAlertTime = alert.getNextAlertTime(ctx);
activeBgAlert.updateNextAlertAt(nextAlertTime);
}

But the code on ClockTick might not reach that part (for example if trendingToAlertEnd). and in that case the timer will be fired immediately.

In previous versions there was a default text shown : https://yourpassphrase@{YOUR-SITE}.azurewebsites.net/api/v1/

commit 882ef1e
It's not shown anymore
See attached screenshot.

I recently upgraded to the latest BETA but I have used a few versions/upload methods over the last couple of weeks and not sure what introduced which problem.

Anyway, previously I would have had dateString fields that would look like this:
"2015-09-27 00:00:38.623+0100"
but now there seems to be a letter "T" there instead of the space:
"2015-10-04T00:15:19.381+0100"

Maybe this is intentional and something to do with date formats and timezones that I missed but it looks incorrect to me. This is happening with two separate uploaders running BETA 4 with different upload methods.

Also, the filtered/unfiltered field formats have changed. Maybe this is a purposeful thing but I have one uploader (using a "xDripWifiWixel" setting and the mongo uri upload method) and that is getting different values for filtered and unfiltered as you would expect. However, the other "normal xDrip" (xDrip-BluetoothWixel) device which uses the REST API is now showing filtered and unfiltered both as containing the SAME value - which is actually the UNFILTERED value in both cases!

Finally, the filtered/unfiltered no longer seem to have any decimal places. This only appears to happen with the uploader using the Bluetooth collector/REST. The Wifi/uri collector does have decimal places.

I'll modify the upload method on the WifiWixel to confirm that it is the REST API that is potentially causing the issues and post back my results later/tomorrow. However, I was just browsing the mongo entries this morning and discovered these issues so thought I would log them now. If anyone can check out their entries collection and see if they are having similar issues then that would be great.

Device = Samsung galaxy tab 4.8.0 (sm-t335)
Android 5.1.1
Tested on commit with sha 882ef1e but I also noticed in previous versions.

When scanning, and then clicking the xDrip following exception is logged :
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: FATAL EXCEPTION: main
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: Process: com.eveningoutpost.dexdrip, PID: 28766
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: java.lang.RuntimeException: Unable to stop service com.eveningoutpost.dexdrip.Services.DexCollectionService@2f3d66e8: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.speech.tts.TextToSpeech.shutdown()' on a null object reference
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread.handleStopService(ActivityThread.java:3979)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread.access$2400(ActivityThread.java:197)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1784)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.os.Looper.loop(Looper.java:145)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6862)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at java.lang.reflect.Method.invoke(Method.java:372)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1404)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.speech.tts.TextToSpeech.shutdown()' on a null object reference
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.eveningoutpost.dexdrip.utils.BgToSpeech.tearDown(BgToSpeech.java:56)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.eveningoutpost.dexdrip.utils.BgToSpeech.tearDownTTS(BgToSpeech.java:39)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.eveningoutpost.dexdrip.Services.DexCollectionService.onDestroy(DexCollectionService.java:121)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread.handleStopService(ActivityThread.java:3960)
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread.access$2400(ActivityThread.java:197) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1784) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.os.Looper.loop(Looper.java:145) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6862) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at java.lang.reflect.Method.invoke(Method.java:372) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1404) 
12-02 21:14:31.765 28766-28766/com.eveningoutpost.dexdrip E/AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199) 
12-02 21:14:31.765 28766-28944/com.eveningoutpost.dexdrip I/System.out: (HTTPLog)-Static: isSBSettingEnabled false

when fixing that needs to take care of timers as well.

When I try to export my data into CSV, it still exports in unit "mg" instead of "mmol". But I configured "mmol" as default unit.

I have a Galaxy S6 (5.1.1), and I just updated to xdrip beta 2.0.5_2. Before this, I was using last August's release. In the August release, if I chose a system sound, such as a beep, for an alert, the alert would keep beeping until I dismissed or snoozed it. In the 2.0.5_2 release, the alert only beeps once. When I select the sound from the list of available system sounds, it previews with a repetitive beep. However, the alert test and alert itself only beeps once. Is this a known issue with this new release? Any chance of an update to correct it? I normally would have no problem uninstalling the new release and reinstalling the old, but I prefer the newer user interface. Additionally, a beep is less conspicuous than a song in a work environment

Sometimes it is necessary to remove the transmitter for cleaning or sensor tuning.
After re-inserting it on the same sensor, it would be nice to restore the saved calibration
data.

I have installed the G5 experimental on a HTC One M9, running Android 5.1. Everything is working as it shoud, the only problem I am having is missed readings. On average I'd say it misses about 50%. Range isn't an issue, it's been with me the whole time.

Chris

It is impossible to have a low alarm for one time segment that is higher than a high alarm at another time segment, even if these segments don't overlap.

Common usecase for me: Wanting to set a low alarm for 2 hour of sports during the day (18:00 to 20:00) that is higher than my high-alarm from 22:00 to 7:00.