search

Gissio / radpro

Custom firmware for Geiger counters/radiation meters (FS2011, Bosean FS-600, FS-1000, FS-5000, FNIRSI GC-01)
MIT License
154 stars 20 forks source link

Bosean FS-5000: History not downloading correctly #97

Closed alfmck closed 2 months ago

alfmck commented 2 months ago

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

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 commented 2 months ago

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

Gissio commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Please do so.

alfmck commented 2 months ago

That's it 4.zip

alfmck commented 2 months ago

image 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 commented 2 months ago

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.

alfmck commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

Gissio commented 2 months ago

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

alfmck commented 2 months ago

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 commented 2 months ago

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

ihrapsa commented 2 months ago

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

alfmck commented 2 months ago

I also reflashed firmware and started accumulating history data

Gissio commented 2 months ago

No need for that, the problem has been identified.

ihrapsa commented 2 months ago

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 commented 2 months ago

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

Gissio commented 2 months ago

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 commented 2 months ago

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

Gissio commented 2 months ago

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

alfmck commented 2 months ago

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. 10kHz@2.5% - stabile 440V Measured with digital oscilloscope and 2.2GOm resistor. Will do more tests tomorrow in the morning.