Average current measured is 91% more in Linux/ Ubuntu as compared to that of Windows PC

[karthik-gunturi]

I'm checking a continuous transmit test where we expect output current of 120mA in Ampere meter mode but observing 212mA instead. The same measurement taken in Windows PC gives expected value 120mA. Please let me know if there's a bug that's leading to this issue.

[karthik-gunturi]

Can anyone help me on this issue?

[NejcKle]

@karthik-gunturi could you please verify this using the nRF Connect Power Profiler tool?

[karthik-gunturi]

I used Raspberry PI. So this script is the only way to check. However I can try the same in Linux PC.

[NejcKle]

@karthik-gunturi please do, try it on Windows PC and Linux PC and share screenshots of the Power Profiler output if possible.

[karthik-gunturi]

Issue is not seen on Windows and linux PC. Average Current readings from app and script are matching. However there are missed samples from the script which is probably expected. Issue is seen only on Raspberry PI.

[wlgrd]

Are you using any other USB devices in the Pi while using the PPK2? The PPK2 uses bulk transfers, so for instance an external hard drive will most probably mess up the readings. What about power source to the Pi? Please also tail dmesg while sampling, that might give you some indications if we have any USB issues going on,.

[karthik-gunturi]

This issue is caused due to abrupt exit from the python console which left the device in ampere meter mode. Once we go back into the console (re-running the script or issue commands manually in python console), we need to issue RESET command that is not available in the example.py script.

[karthik-gunturi]

Can anyone provide a fix for this without implementing RESET command ?

[NejcKle]

@karthik-gunturi can you provide more information about the RESET command? How do you issue the command to the PPK? Do you need to replug the PPK for it to start working?

I think the best way to handle this would be to gracefully exit your Python script.

[wlgrd]

The fix is to properly close the "serial" connection as @NejcKle mentions. When this happens, the kit will reset itself.

[karthik-gunturi]

class PPK2_Command(): """Serial command opcodes""" NO_OP = 0x00 TRIGGER_SET = 0x01 AVG_NUM_SET = 0x02 # no-firmware TRIGGER_WINDOW_SET = 0x03 TRIGGER_INTERVAL_SET = 0x04 TRIGGER_SINGLE_SET = 0x05 AVERAGE_START = 0x06 AVERAGE_STOP = 0x07 RANGE_SET = 0x08 LCD_SET = 0x09 TRIGGER_STOP = 0x0a DEVICE_RUNNING_SET = 0x0c REGULATOR_SET = 0x0d SWITCH_POINT_DOWN = 0x0e SWITCH_POINT_UP = 0x0f TRIGGER_EXT_TOGGLE = 0x11 SET_POWER_MODE = 0x11 RES_USER_SET = 0x12 SPIKE_FILTERING_ON = 0x15 SPIKE_FILTERING_OFF = 0x16 GET_META_DATA = 0x19 RESET = 0x20 SET_USER_GAINS = 0x25

I've issued the below "RESET" command from example.py command : ppk2_test._write_serial({0x20})

[wlgrd]

The fix is still to properly disconnect from the serial, if you don't want to implement the RESET command.

PS: This command set is not completely valid for the PPK2, and is from the implementation of PPK1. For instance, the SWITCH_POINT_UP was something that PPK1 used. Some overlap is expected, but please don't trust this blindly.