PPK2 and Power Profiler desktop: time scale way off

[TheBronx]

Did a quick search and it seems I am not the only one experiencing this issue  But can't find a solution.

I just got a PPK2 and started testing some devices (ESP8266). I quickly noticed that the time in the graphs was completely off.
Have a look at this screenshot:

Without even activating the power supply, just starting measuring and stopping 5 seconds later. You can see down in the log:

19:17:20.698	Sampling started
19:17:25.735	Sampling stopped

But if I click on SELECT ALL it says 1.606 seconds
So basically it reports around 1 second for every 3 actual seconds.

It doesn't matter how many samples per second I take, it does it all the time.
Zooming doesn't change anything, it is still wrong.
Tried with 3 different USB ports already both USB2 and USB3, different cables too.
And the DUT I don't think it matters, tried a few already but same problem regardless.

Should I return the unit? Or is it a software error? Any workaround?

System:
Manjaro/KDE
Linux Kernel 6.0.15
AMD Ryzen 5 5600X
16GB RAM
MSI B450 Tomahawk Max II on latest BIOS: 7C02vH9 2022-08-15 (it was happening with a previous BIOS too)

Power Profiler v3.5.3

Edit: tried on windows, same problem.

Edit2: tried on an ancient Intel laptop, with windows, and it works fine. So it is not the hardware, it is the software that is broken. And has been broken for 2 years according to the reports: github.com/.../141

# nRFConnect System Report - 2023-01-20T21-32-39.794Z

- System:     Micro-Star International Co., Ltd MS-7C02
- BIOS:       American Megatrends International, LLC. H.90
- CPU:        1 x AMD Ryzen 5 5600X 6-Core Processor 3.7 GHz 12 cores (6 physical)
- Memory:     10.2 GB free of 15.5 GB total
- Filesystem: S.ficheros (Tipo) 0 Bytes NaN% used

- OS:         ManjaroLinux (22.0.0) linux x64

- Versions
    - kernel: 6.0.15-1-MANJARO
    - git: 2.39.0
    - node: 14.16.0
    - python: 3.10.8
    - python3: 3.10.8
    - nrf-device-lib-js: 0.4.13
    - nrf-device-lib: 0.12.8
    - nrfjprog DLL: Unknown
    - JLink: Unknown

- Connected devices:
    - C455D71461C9 : /dev/ttyACM0

- Current device:
    - name:          
    - serialNumber:  C455D71461C9
    - cores:         Unknown
    - website:       Unknown

[Joakim Jakobsen]

Thank you for your feedback. 

I will continue to investigate the issue. Will confer with our PPK and SW developers. 

Br, 
Joakim

[Joakim Jakobsen]

Hi. 

We don't know what is causing the issue as of now. 

TheBronx said:

I connected it to a USB3 hub and it works fine on my AMD machine.

I have been experimenting with the python PPK2 API and discovered that just reading a fixed amount of bytes from the serial port takes longer when connected directly compared to the USB hub.

Like previously commented, a possible workaround could be to connect the PPK through a USB hub. 

Br, 
Joakim

[RenanSP]

I have the very same issue: the recorded time is only 32% of real time. I tried multiple USB ports (2.0 / 3.1), cables, OS (Windows 10 and Linux Pop!_OS 22.04) and a USB hub. The best combination still didn't go over 34%.
This is really messing with my calculations.

My motherboard is an "MSI - AMD AM4 mATX B350M gaming pro" (chipset = B350M).
I will see if there are BIOS updates available and report back.

Reporting back: I updated to the latest BIOS (2023-05-23-beta) and the problem persists.

[RenanSP]

But after tweaking many options on BIOS (most of which I don't understand) it improved from 32% to 48% of real time being captured. That also improved a bit the ringing that the PPK2 was displaying on both the current graph and the LA graph (the signal was fine as I probed it with an oscilloscope right at the PPK2 PCB).

But still, the LA was drawing the wrong duty cycle, and the ammeter losing samples and hallucinating about ringing. Finally, I tried a live Linux USB drive ( Pop!_OS 22.04 ) on a borrowed INTEL laptop and connected PPK2 to it without disturbing the test circuit. All the problems disappeared.

 

As the two pictures show, apparently the only thing PPK2 seems to get right on AMD systems currently is the average current. Everything else is dependent on chipset's luck.