Replies: 2 comments 14 replies
-
|
I don't think this covers your full requirement although I display the 'Packet capture percentage' and 'Realtime packet capture percentage' from the 'Settings>Less Common Settings>Extra Status Line' settings to give me something to watch to indicate how well my sensor session is holding up. I'm still on G6 and find that pretty reliable and normally see 100% for both those stats so if anything drops off I know to be wary of what the graph shows... |
Beta Was this translation helpful? Give feedback.
-
|
That's strange, mine wraps onto multiple lines in portrait and has enough space on one line in landscape. I can't see a setting to control that although I've had those display options set for so long and on multiple phones that there may something I've forgotten, sorry... |
Beta Was this translation helpful? Give feedback.
-
|
@jonprogers what channel (and/or version) are your running? Stable on my end, so I know I'm lacking the latest/greatest. As to looking for settings- yep, I've dug through all of that and nothing obvious has leaped out. I've actually had this problem across my last phone and the current (pixel8 pro). The relevant status line settings are "sliding window", "show on widget", and "calibration data". The rest are just sources I've checked off: Average, A1c dCCT, TIR, standard deviation, packet capture percent + realtime, accuracy evaluation (which so far has no data). |
Beta Was this translation helpful? Give feedback.
-
|
I'm running the 19/9/24 nightly on a pixel 7 (xDrip master) and 27/3/24 nightly on a very old nexus 5 (xDrip follower) and both these wrap the status line. I also used to have an LG G5 and this wrapped too. I think I have been running this setup since I was on G4 so for well over 6 years and the wrapping has always happened. |
Beta Was this translation helpful? Give feedback.
-
|
@jonprogers no worries, and thanks. Confirming that it works for someone else points the direction for where I should go digging. As to the G4- If I didn't start w/ G4, it was definitely early G5. I recall having to rebuild the config once during that time frame- it wasn't import/export issues, there just seemed to be something fucky in it that went away when I forced a reset and rebuilt. That's incredibly minor; no other vendor app allows me the sort of data fusion I get with xdrip+, let alone automatic uploads into tidepool. I just wish there was a undirectional sync from tandem into xdrip+; the only thing I know of is https://github.com/jwoglom/tconnectsync , and that's tconnect -> nightscout. That said, someone hacked out the code for this, so translating it into xdrip+ as a data source was something I kind of want to try. |
Beta Was this translation helpful? Give feedback.
-
|
Oh that's just fucking weird. Knowing it works, meant screwing around with it. My rough repro is this:
The kicker here is that the above is the exact sequence I did, and now I can't trigger it again via resetting back to previous data items that don't require a line break. IE, trying to trigger the behavior via "no need" into "need" in portrait mode. I can make guesses about stale configs (which I doubt- xdrip+ devs are good that way), or delayed updates (unlikely since the status line is immediately updated for new items), but I have NFC for the underlying behavior. If the config angle is a potential- I started w/ xdrip+ late G4 or early G5, and I'm pretty much positive I had a config rebuild somewhere in late G5 era. The last settings import/export was nov/2023 using stable from that era. Unless others have reported something similar, I'm fine chalking this one up to "cosmic rays". ;) |
Beta Was this translation helpful? Give feedback.
-
|
I've never seen a G7, or G6, that caused missed readings on and off. I have seen a device die and show this behavior for a few last read cycles before permanently dying. But, nothing constantly having missed readings and then recovering on and off. I have seen plenty of devices set up incorrectly causing this behavior. What is the phone brand and model? |
Beta Was this translation helpful? Give feedback.
-
|
Apologies, but can we stick to talking about the feature request I made? Yes, my setup has unrestricted. I have some notions about potential differences in your anecdotal experience vs mine- one large variable is my vendor being shitty and sending me near expired hardware constantly (IE, battery issues), but that is not the discussion I wish to have. I'm here to ask for a feature and ask what the way forward is- code implementation, UI, and confirming that this is something acceptable to the maintainers of xdrip+ :) I've not looked into the battery or voltage A/B values; I assume the G7 gives out an enumeration for the battery state ("good", "dieing soon", "dead"), and I view the A/B as safety comparisons. When I've spotted sensor errors, the A/B are usually in strong disagreement. I kind of want to see a graph of the variance in A/B just for geek reasons, but I understand if it's not worth the maintenance. If either of those are are useful for bug reports, state so please. I mentioned it earlier, but 1) I think the best UI placement is to extend the statistics section- make it possible to select different data sources, and 2) I'd appreciate if someone can point me exactly where to start making a mess in the code and trying to figure this out. A tentative 3) is how to fully validate this (unit-tests are good, but what else?) before I try running this on my live hardware. I've been deeply reliant on xdrip for the better of the >10y; while I dogfood a shitton of software I work with (or just flat out originated/wrote), I'm twitchy about screwing with my xdrip setup without strong guardrails. What's the advice for the way forward? Is there consensus that this makes sense to add as a feature, and if so, what's the process for consensus on the design/UI aspects? I'm not asking about code review- I'm asking about who owns or decides the UI/UX side of it. I can't say that I'll produce a usable PR, but considering the 10+ years I've used xdrip+, I should try and get over my java bias and contribute. Knowing exactly what I'm getting myself into- and having a pointer where to start- would be deeply appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
You can always open a PR. If it solves a major problem that many suffer from, it will have to be merged. Because if it is not, it will appear in another repository and users can always switch repositories. I only provide my opinion as a member of the community. And I will not provide any more unsolicited input in this thread. |
Beta Was this translation helpful? Give feedback.
-
I stick to this repository mainly for the stabilizing aspect you mentioned; it's effectively the torvalds branch in how I think of it. I'm a complete newb when it comes to this ecosystem, and I explicitly do not want to maintain my own fork, nor cut a PR that no one will pay attention to. What's your advice on that front? For context, this is why I was focusing on asking about consensus; if this has no chance in hell- folks think it's a stupid idea- I'd rather find out now before putting the time in. ;)
Online commenting sucks for not sounding like a raging asshole, which I probably did. No offense was taken, and having maintained a lot of communities, I grok your intent- and I've absolutely done the same thing. I just was trying to skip you forward to giving me advice from the developmental side of this so I could contribute. Any advice you've got there- solicited/unsolicited, whichever- I'd appreciate. Also, I'm aparently incompetent at writing proper github comments. Apologies for the quoting mistake. ;) |
Beta Was this translation helpful? Give feedback.
-
|
I hope we can first convince both of us that you are getting the best you can get from xDrip as is now. I believe that you already believe that. If you give me a chance to convince myself in that respect as well, we can then talk about what you are thinking of with regards to changing xDrip so that it would provide more details about capture rate and the best way in doing that. And you are not the only one who wants improvements there. I don't want to brag. But, my capture rate is 100%. If you had a garbage Samsung, I wouldn't have much to say. But, you are using a Pixel and your capture rate is less than 99%? That makes no sense. Something is definitely wrong there and I would like to find it. Now, you say why can we not talk just about adding a feature and have to talk about troubleshooting? |
Beta Was this translation helpful? Give feedback.
-
|
This is an existing PR that adds capture rate to statistics: I would like to clean up the statistics before we add this. I will. Every time Google changes something, lots of things fall apart and we have to fix them. None of this is visible to everyone. Every new feature makes this even more complicated. There is a request for offering audio focus for spoken readings. We need to add that. All of these take time and we prioritize them and address them all. |
Beta Was this translation helpful? Give feedback.
-
Note: I'm using version 2124041914 ; if some of these capabilities are in later versions, please let me know. Additionally, I have xdrip+ talking directly to the G7- no intermediate dexcom app.
When you've got a semi-bad G7 it's not uncommon to have sensors errors thrown and have significant gaps in the data. The feature request is straightforward- I think some form of configurable statistics ranges would be useful.
See
for an example of why I'm asking. That sensor reporting is ~25% sensor errors, repeated random +50mg/dl drops, error, then bounce back to the correct value, etc. My typical control is a stable 80-120mg/dl- but this session is obviously borked, and I'm waiting for it to throw a duration of error so I can make dexcom replace the !@#*ing thing.
Xdrip+ has the data, but AFAICT I'd have to pull logs out of it and do my own external tooling to extract this error rate. My suggestions are thus:
I don't have time to even try hacking out this feature, and to be frank, I'm extremely reliant on my xdrip+ setup so I'm wary of experimenting with myself without some serious guard rails. For anyone versed in the codebase, sketching out a rough 'how' for what needs to be modified, and 'how' for testing this rather than doing it 'live', that would be useful.
Beta Was this translation helpful? Give feedback.
All reactions