Power Profiling Kit printing "Range not Detected" after running for a few minutes

[CurtisHx]

After a few minutes of running, the Power Profiling kit will start printing out "Range not detected" messages in the console. It appears to be related with the "Average" window length. Increasing the average window length (I had it set to 20 seconds) makes the "Range not detected" message start sooner after application start. Measurements start getting wonky (timing is off, measured current is definitely off, etc) when the message shows up.

Also, the frequency of the messages increases the longer the application has been running.

Restarting the application is the only way to make the messages go away temporarily.

[wlgrd]

This message only appears when there is an error in the data set from the PPK (which I have never seen happen during quite some time in development). Can you explain more about the setup? Also, do you mean you set the average window to longer than 20 seconds?

Which debugger/DK interface? Python version? Print out at init? Few minutes, is that two or twenty?

If the frequency increases, that means that more and more packages are corrupt. Are you sure you have the latest segger drivers installed? What system is the software running on?

EDIT: I see that if I have my average window at above 20s (like 40 seconds) data starts to get corrupted. I guess that most probably have to do with the buffer sizes not adapting correctly. The longer average window is kind of experimental; we do not officially support it, the slider does not support it, but it is there for adventurous people ;) There are some shortcomings in the RTT for this type of usage, but we will look into supporting longer average windows.

[Werner Johansson]

If you're open to trying a different PC software to drive the PPK to see if that resolves the wonky measurements may I suggest giving Otii from Qoitech a spin?

Software and more information can be found here: https://qoitech.com/#/nordic

[CurtisHx]

Gotchya. I haven't seen any corrupted data with the average at or below 20 seconds. If I understood you correctly, this a problem with data transfer RTT. So I could potentially do some PC-side caching of the data coming back over RTT to get a longer window.

[wlgrd]

I haven't pin pointed exactly where, but as the window size changes, so does the buffers. There might be some buffer calculation errors when it crosses a given time window (type overflow maybe), but the code is there so it's awesome if you wanna play around with it. Also, the answer from @WernerJohansson might be worth looking into. That application has an "infinite" time window by default.