Closed alfmck closed 2 months ago
I need a repeatable list of steps that showcase the error.
Did you try connecting to your counter with a serial terminal like, for instance, https://www.putty.org/ ?
Try the following command:
GET datalog
Putty reads all the data successfully. Geigerlog also reads all history data. But when I try to read new history data, FS-5000 immediately restarts and Geigerlog gives "Could not download history". I'm going to repeat flashing firmware. Could it help if I send firmware 256 KB .bin copy, that is in my device now?
Please do so.
And the result or reading new history after 5 minutes when I flashed firmware and switched on Data logging for every 1 second (In graph we see the data for 20 minutes timeslot.)
It's a great thing you made a flash memory snapshot that allows reproducing the error. Unfortunately I haven't been able to reproduce the error in my simulator.
I'm going to ask you to confirm a couple of events, just to make sure there is no fault in datalog recording. I'm going to assume your device's clock is correctly set. I'll also provide dates and times in UTC time.
Question 1: Is all of this correct? If it is, it would mean that datalog recording is working correctly.
Question 2: When sending the GET datalog
request through PuTTY in the flash memory snapshot state, do you get to see some response? How much time passes between submitting the request and the device restarting? The exact timing would be greatly helpful.
I've found the answer of first part of my question. When connecting FS-5000 to Geigerlog, time synchronizing process starts and Geigerlog sends date and time from PC to device. Time zone is not sending. So, in order to have correct new history data from the early beginning you have to:
For second part of my question. I tried to repeat the situation to convince if it wasn't sporadic. So, I:
flashed firmware using radpro-flashtool-2.0. I sent 4.zip file from backup directory in my comment before.
Connected to Geigerlog and in 5 minutes red new history data. v.hisdb.csv z.hisdb.csv c.hisdb.csv jjj.hisdb.csv jjj.hisdb.csv.zip
In 3 hours, I connected to Geigerlog and red new history data.
In 10 hours, I connected to Geigerlog and red new history data.
In 5 minutes, I tried to read new history data. But then FS-5000 immediately restarts and Geigerlog gives message "Could not download history". Data logging became off and time shift eq.0 in device settings
It seems that after reading some big amount of new history data, FS-5000 doesn't enable to read new history anymore.
It's a great thing you made a flash memory snapshot that allows reproducing the error. Unfortunately I haven't been able to reproduce the error in my simulator. I didn't make a flash memory snapshot - I reload firmware with radpro-flashtool-2.0 and took the previous firmware from backup directory
I'm going to ask you to confirm a couple of events, just to make sure there is no fault in datalog recording. I'm going to assume your device's clock is correctly set. I'll also provide dates and times in UTC time.
Between 2024-06-09 10:48 and 2024-06-09 11:17 you restarted your device several times without the ok/power button. Likewise at 2024-06-09 20:16:47. - I tried to read new history data, every time FS-5000 restarts and Geigerlog gives message "could not download history" At 2024-06-10 08:09:22 you turned your device off with the ok/power button, and turned it back on at 2024-06-10 13:48:20. -Yes
At 2024-06-11 05:14:33 you changed the clock back for a few seconds, and at 2024-06-11 05:14:41 you changed it forward, also for some seconds. - It could be that I connected device to Geigerlog and was the time synchronizing. At 2024-06-11 05:32:03 you disabled datalogging without turning the device off, and at 2024-06-11 05:38:22 you enabled it again. -At that time, I likely was reading data with PUTTY and all data history with Geigerlog. At 2024-06-11 13:10:02 you turned off the device. YES Question 1: Is all of this correct? If it is, it would mean that datalog recording is working correctly.
Question 2: When sending the GET datalog request through PuTTY in the flash memory snapshot state, do you get to see some response? How much time passes between submitting the request and the device restarting? The exact timing would be greatly helpful.
Question 2: When sending the GET datalog request through PuTTY in the flash memory snapshot state, do you get to see some response? How much time passes between submitting the request and the device restarting? The exact timing would be greatly helpful.
I insist on this.
in the flash memory snapshot state, - please comment more what is it?
I mean this: open PuTTY, type GET datalog
and tell me what happens.
After typing GET datalog and pressing Enter, immediately I see receiving data on putty screen. Get datalog.txt The common situation is when I getting ALL HISTORY DATA FROM DEVICE: on Geigerlog all history from the device.hisdb.csv (2).zip The problem is when I'm trying to get NEW HISTORY DATA FROM DEVICE: on Geigerlog
That video was tremendously useful! Now I know where to look for the error.
I am not able to reproduce this issue. I'll be gathering more history data and see then.
I also reflashed firmware and started accumulating history data
No need for that, the problem has been identified.
I am not able to reproduce this issue. I'll be gathering more history data and see then.
Yup, I can reproduce this. I gathered about 13h of data -> loaded all history in geigerlog
-> waited a couple of seconds then Get New History from Device
-> action fails and the device reboots.
Apparently the Get New History from Device
action fails every time with device rebooting even if I don't load all history from device first. Only when there's little data gathered I am able to Get New History from Device
Could you test https://github.com/Gissio/radpro/releases/tag/2.0.1beta3?
The issue was that downloading partial data logs didn’t trigger the watchdog timer frequently enough, causing the device to reboot.
Could you test https://github.com/Gissio/radpro/releases/tag/2.0.1beta3?
I've also added data log reset (with little flash memory wear).
Tested. Everything works. Data logging reset too. Thank You, Gissio very much!
Would someone be so kind to test #96 on the FNIRSI GC-01?
HV values: Factory default is not stabile and changes from 800V to 900V. Common voltage I also was getting with all earlier radpro versions and with original software too. Energy saving - stabile 430V. Would be nice for my GC-01 if this setting be default. 10kHz@2.5% - stabile 440V Measured with digital oscilloscope and 2.2GOm resistor. Will do more tests tomorrow in the morning.
After 13 hours I've red successfully new history data. And then after 0.5 hours a couple of times I tried to read new history data - the FS-5000 restarts, and I was getting the message "Could not download history" on Geigerlog. Didn't help neither restarting Geigerlog nor manually restarting FS-5000.