search

baryluk / fnirsi-usb-power-data-logger

Driver / Data logger for FNIRSI FNB48, FNIRSI C1 and FNIRSI FNB58 USB Power meter
MIT License
141 stars 14 forks source link

Support for FNIRSI FNB58 is here! #4

Closed didim99 closed 1 year ago

didim99 commented 1 year ago

Fixes #2, and also probably fixes FNB48 freezes when program exiting (tested couple dozens of times but needs much more testing to be sure).

baryluk commented 1 year ago

Thank you. I tested this on C1 and FNB48, and on C1 it works perfectly, including exiting does not freeze the screen.

But on FNB48 it has some weirdness, on exit it does freeze the FNB48 screen, and running script again without resetting the FNB48, the first sample is weird:

FNB48:

user@debian:~/fnirsi-utils$ sudo ./fnirsi_logger.py
....
1667765030.189 1 0.00000 0.00000 1.404 1.191 23.699 0.000000 0.000038
1667765030.199 2 0.00000 0.00000 1.403 1.181 23.709 0.000000 0.000038
1667765030.209 3 0.00000 0.00000 1.411 1.197 23.708 0.000000 0.000038
1667765030.219 0 0.00000 0.00000 1.410 1.194 23.697 0.000000 0.000038
1667765030.229 1 0.00000 0.00000 1.404 1.185 23.698 0.000000 0.000038
1667765030.239 2 0.00000 0.00000 1.403 1.183 23.698 0.000000 0.000038
1667765030.249 3 0.00000 0.00000 1.411 1.195 23.698 0.000000 0.000038
^C....
KeyboardInterrupt

(run again while the FNB48 is still attached)

user@debian:~/fnirsi-utils$ sudo ./fnirsi_logger.py 

timestamp sample_in_packet voltage_V current_A dp_V dn_V temp_C_ema energy_Ws capacity_As
1667765050.059 0 188.74370 170.39408 51.840 0.000  0.000 321.608091 1.703941
1667765050.069 1 0.00000 0.00000 0.000 0.000  0.000 321.608091 1.703941
1667765050.079 2 0.00000 0.00000 0.000 0.000  0.000 321.608091 1.703941
1667765050.089 3 0.00000 0.00000 0.000 0.000  0.000 321.608091 1.703941
1667765050.065 0 0.00000 0.00000 1.376 1.129  2.420 321.608091 1.703941
1667765050.075 1 0.00000 0.00000 1.373 1.125  4.598 321.608091 1.703941
1667765050.085 2 0.00000 0.00000 1.376 1.130  6.558 321.608091 1.703941
1667765050.095 3 0.00000 0.00000 1.376 1.129  8.322 321.608091 1.703941

This is weird, as I remember I had a code to ignore first data sample, as it was some total random values (probably not random, but they were probably encoding something else than normal samples - you can see above that dp_V dn_V temp_C are also wrong in the first data packet in samples 1,2,3).

There is probably nothing wrong with your code, but I will also do a bit more testing, including original code.