Bosean FS-5000: History not downloading correctly

[alfmck]

The data from FS-5000 are on the beginning of graph and there are some data on the end of graph. On GC-01 everything OK.
It seems that on FS-5000 after 1 hour of datalogging we get a normal graph.

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.

[Gissio]

I need a repeatable list of steps that showcase the error.

[Gissio]

Did you try connecting to your counter with a serial terminal like, for instance, https://www.putty.org/ ?

Try the following command:

GET datalog

[alfmck]

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?

[Gissio]

Please do so.

[alfmck]

That's it
4.zip

[alfmck]

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.)

[Gissio]

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.

• 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.
• 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.
• 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.
• 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 2024-06-11 13:10:02 you turned off the device.

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.

[alfmck]

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:

1. Connect FS-5000 to Geigerlog and then data and time synchronizes.
2. Manually set time zone on FS-5000.
3. Set data logging to ON.
4. Read correct new history data.

For second part of my question. I tried to repeat the situation to convince if it wasn't sporadic.
So, I:

1. flashed firmware using radpro-flashtool-2.0. I sent 4.zip file from backup directory in my comment before.

2. 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

3. In 3 hours, I connected to Geigerlog and red new history data.

4. In 10 hours, I connected to Geigerlog and red new history data.

5. 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.

[alfmck]

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.

[Gissio]

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.

[alfmck]

in the flash memory snapshot state, - please comment more what is it?

[Gissio]

I mean this: open PuTTY, type GET datalog and tell me what happens.

[alfmck]

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

https://filebin.net/62hn61j77iggbdof

[Gissio]

That video was tremendously useful! Now I know where to look for the error.

[ihrapsa]

I am not able to reproduce this issue. I'll be gathering more history data and see then.

[alfmck]

I also reflashed firmware and started accumulating history data

[Gissio]

No need for that, the problem has been identified.

[ihrapsa]

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

[Gissio]

Could you test https://github.com/Gissio/radpro/releases/tag/2.0.1beta3?

[Gissio]

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).

[alfmck]

Tested. Everything works. Data logging reset too. Thank You, Gissio very much!

[Gissio]

Would someone be so kind to test #96 on the FNIRSI GC-01?

[alfmck]

#96 testing: I flashed test3 firmware made from src to GC-01 with Geeky Ch32 MPU, without R38-51mOm load resistor.
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.
[email protected]% - stabile 440V
Measured with digital oscilloscope and 2.2GOm resistor.
Will do more tests tomorrow in the morning.