GQ Electronics Technical Support Forum Active Users: / Visits Today:
Highest Active Users:
GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 2.GQ Geiger Muller Counter
 Bad data read from GMC-600+ in SPIR command
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

kumar

USA
7 Posts

Posted - 10/31/2021 :  06:00:55  Show Profile  Reply with Quote
I've been reading the output of the SPIR command from my GMC-600+ and I frequently get what appear to be malformed timestamps.

Here are some examples (from hexdump).

00004c20 00 00 00 00 00 03 00 01 00 00 00 00 00 01 00 01 |................|
00004c30 00 03 00 00 00 00 02 00 02 01 00 00 01 02 01 00 |................|
00004c40 00 01 00 02 02 00 00 55 aa 00 15 0a 1f 02 00 55 |.......U.......U|
00004c50 aa 01 00 00 00 02 01 02 01 00 00 02 00 00 00 02 |................|
00004c60 00 01 01 01 03 01 00 02 00 00 03 01 00 00 00 01 |................|

Observe the timestamp starting at 0x4c47, it reads 0x55 0xaa 0x00 0x15 0x0a 0x1f 0x02 0x00 0x55 0xaa. It is one byte short, the timestamp here is 2021-10-31 02:00:??

Here is another (starting at 0x5b47)

00005b30 00 03 00 00 01 01 00 01 00 01 00 00 00 00 00 00 |................|
00005b40 00 00 01 00 00 00 03 55 aa 00 15 0a 1f 03 06 55 |.......U.......U|
00005b50 aa 01 03 00 02 01 00 00 00 01 01 00 00 00 00 00 |................|
00005b60 00 00 00 00 00 01 00 00 03 01 00 00 00 00 00 00 |................|
00005b70 00 00 00 00 02 01 00 00 00 01 02 00 00 00 01 00 |................|

0x55 0xaa 0x00 0x15 0x0a 0x1f 0x03 0x06 0x55 0xaa which is 2021-10-31 03:06:??.

Another (starting at 0x7885)

00007870 00 00 00 00 00 00 00 00 02 00 00 00 01 02 00 00 |................|
00007880 00 00 00 01 00 55 aa 00 15 0a 1f 05 10 55 aa 01 |.....U.......U..|
00007890 01 02 00 03 00 00 01 01 02 00 00 00 00 00 04 00 |................|
000078a0 00 00 00 00 01 00 00 00 00 00 01 00 01 00 01 00 |................|
000078b0 00 01 00 02 00 00 00 01 01 00 00 00 04 01 00 01 |................|
000078c0 00 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00 |................|

0x55 0xaa 0x00 0x15 0x0a 0x1f 0x05 0x10 0x55 0xaa, again 05:16:??

In other cases, I see this pattern (see starting at 0xefc6)

0000efa0 00 01 02 00 00 00 02 00 00 01 00 01 00 00 02 00 |................|
0000efb0 00 01 01 00 00 01 00 00 00 00 00 00 02 00 01 00 |................|
0000efc0 00 00 03 01 01 02 55 aa 00 15 0a 1f 1f 0a 0e 02 |......U.........|
0000efd0 55 aa 01 00 00 00 00 00 01 01 00 02 00 00 00 00 |U...............|
0000efe0 00 01 00 01 00 00 00 00 00 00 00 01 00 00 00 00 |................|

0x55 0xaa 0x00 0x15 0x0a 0x1f 0x1f 0x0a 0x0e 0x02 0x55 0xaa.
<preamble> 00. 2021 10. 31. 31. 10. 14. 02. <terminator>

Here there seems to be one extra byte, the date is 2021-10-31-31 10-14-02.

I am running GMC-600+ with firmware version 2.24.

Is this something that has been observed before, is there a known solution?

Thanks.

-amrith

--
Amrith Kumar
Reply #1

ullix

Germany
1107 Posts

Posted - 11/01/2021 :  02:28:07  Show Profile  Reply with Quote
The effect reminds me strongly of the bug in the SPIR command in the 300 series. This was overcome in the 500 series, but maybe it resurfaced now.

Back then it was the result of an overflow of a 12 bit value (4096) and inadequate handling of the download in firmware. It could be overcome by limiting the download to 2048 and not 4096!

If that does not help, you can try GeigerLog and tinker with the SPIR settings in GeigerLog's configuration file.
Go to Top of Page
Reply #2

kumar

USA
7 Posts

Posted - 11/01/2021 :  07:01:47  Show Profile  Reply with Quote
A little more information - hopefully someone else is able to recognize a pattern.

At each of the locations where I have trouble, the SPIR command returns less data than requested.

For example, at 0x4c40, a request for 16 bytes returns 15 (consistently).

At 0x5b40, a request for 16 bytes returns 15 (consistently).

I changed the comport from 115200 to 9600, and tried again. It gets stuck in the same place.


--
Amrith Kumar
Go to Top of Page
Reply #3

kumar

USA
7 Posts

Posted - 11/01/2021 :  09:48:22  Show Profile  Reply with Quote
No, I'm connecting to the device from Linux. If the parity, and stop bits are wrong, I wouldn't see a single byte of data. I appreciate your trying to help :)

Please do recognize that I'm (a) able to read almost a megabyte of data quite fine, and (b) I'm having issues at the exact same spot over and over again. When reading at 115200, 500ms is an eternity, just saying. The read timeout is 2ms (and in 2ms I can read 4000 bytes most of the time, when I have a problem I read 3,999 :(

FYI, at 500ms latency on reads, and 1mb to read in 4000 byte chunks, it would take about 1300 seconds to get all the data. If that's what you are using, maybe you need to reduce it a lot.

quote:
Originally posted by Damien68

you are using Windows framework? like .NET? (I don't think that could be the cause of the problem).

Check the port setup in particular 1 stop bit, but I don't think it could come from there either.

Serial_port.BaudRate = 115200
Serial_port.DataBits = 8
Serial_port.Parity = 0
Serial_port.StopBits = System.IO.Ports.StopBits.One
Serial_port.DiscardNull = False
Serial_port.Handshake = System.IO.Ports.Handshake.None
Serial_port.ReadTimeout = 500
Serial_port.WriteTimeout = 500

When a 16 Bytes response is requested,
Do you exit the usart read routine with 15 Bytes readed and a timeout triggered?
if it check that timeout is sufficient, there may be a little latency (500mS is a good value).



--
Amrith Kumar
Go to Top of Page
Reply #4

kumar

USA
7 Posts

Posted - 11/01/2021 :  09:48:58  Show Profile  Reply with Quote
Hi Ullix,

Do you have any pointers to that issue, I'd like to chase this lead down if possible.

-amrith

quote:
Originally posted by ullix

The effect reminds me strongly of the bug in the SPIR command in the 300 series. This was overcome in the 500 series, but maybe it resurfaced now.

Back then it was the result of an overflow of a 12 bit value (4096) and inadequate handling of the download in firmware. It could be overcome by limiting the download to 2048 and not 4096!

If that does not help, you can try GeigerLog and tinker with the SPIR settings in GeigerLog's configuration file.



--
Amrith Kumar
Go to Top of Page
Reply #5

EmfDev

2131 Posts

Posted - 11/01/2021 :  12:04:08  Show Profile  Reply with Quote
Hi kumar,

I saw your email that says you did a factory rest and now it seems it is reading okay. I will check the code and see if there is something that caused the corrupted data.
Go to Top of Page
Reply #6

EmfDev

2131 Posts

Posted - 11/01/2021 :  14:17:45  Show Profile  Reply with Quote
@Amrith, @Damien might be right about the timing. I checked the code and SPIR and save data to spi commands are OK. Unless it is a specific spi chip problem. Please let me know if it happens again. Also try to use ullix software geigerlog and see if the problem also exists. If possible, you can also use a pc to test the data with the GMC data viewer.
Go to Top of Page
Reply #7

kumar

USA
7 Posts

Posted - 11/01/2021 :  17:35:45  Show Profile  Reply with Quote
@emfdev .. Thanks for your email. @damien is wrong.

When you call tcsetattr() and specify both c_cc[VTIME], and c_cc[VMIN] which is what I specify when I want to perform a read, the timeout is the inter-byte timeout. The actual read() call takes about 19ms to 26ms when I try to read 4,000 bytes.

Please see https://man7.org/linux/man-pages/man3/termios.3.html

Specifically read the section on MIN > 0, and TIME > 0 (read with interbyte timeout).

But, be that as it might, I believe you, and @damien are on the wrong tree because:

1. if I do a factory reset, the read works just fine on the 'problematic addresses'.
2. the problems (when they occur) are only at specific addresses, at other addresses 4k is read just fine.

And furthermore, I've retested with the timeout set to 10 seconds. (not milli seconds, 10s).

Issue SPIR command, and attempt to read for 10s at the problematic addresses. I am a byte short, at other places a byte long. But in most cases, exactly 4000 bytes in no more than 26ms.

At the problematic addresses, I get 1 byte too few, or in some cases one byte too many!

-amrith

quote:
Originally posted by EmfDev

@Amrith, @Damien might be right about the timing. I checked the code and SPIR and save data to spi commands are OK. Unless it is a specific spi chip problem. Please let me know if it happens again. Also try to use ullix software geigerlog and see if the problem also exists. If possible, you can also use a pc to test the data with the GMC data viewer.


--
Amrith Kumar
Go to Top of Page
Reply #8

ullix

Germany
1107 Posts

Posted - 11/02/2021 :  01:15:31  Show Profile  Reply with Quote
@Kumar: In the GeigerLog manual in chapter Appendix F – Firmware Differences, History Download issues, you'll find an explanation of the (former) problems.

Additionally, if you know Python you can read the comments to function getGMC_SPIR in file gdev_gmc.py.

The GeigerLog configuration file geigerlog.cfg has some options to manually correct those problems. See segment [GMCDevice] and look for GMC_SPIRbugfix and GMC_SPIRpage.

If that doesn't help, there may be a new, as yet unknown problem. The fact that sometimes you get one byte more makes me wonder. Strange that you are the first to report it?

I suggest 3 trials. Issue SPIR command ...:
- 1. ... with a download size of 2048, and check for bytes still in the serial pipeline
- 2. ... with a download size of 4095, and check for bytes still in the serial pipeline
- 3. ... with a download size of 4096, and check for bytes still in the serial pipeline

If your current program does not support this, play with GeigerLog.

Downloading 1 MB at only 115200 baud is no fun. Due to the overhead, the smaller the chunk the longer it takes. On a GMC-500+Re 2.28 I managed to download SPIR in chunks of 16k(!) not just 4k. It worked but I can't say anything about long term stability. There is a gain, but unfortunately it is marginal.

Today's USB-to-Serial chips can run at 30 times the speed (not to mentions that USB2.0 can go to >1000 times the speed).

Go to Top of Page
Reply #9

kumar

USA
7 Posts

Posted - 11/02/2021 :  05:39:23  Show Profile  Reply with Quote
Thank you - no. That's not how you deal with serial devices (in general), especially streaming devices.

But, I appreciate your answer(s). They at least tell me that I'm seeing something that you have not.

-amrith

quote:
Originally posted by Damien68

to avoid confusion, each time before sending a command, flush the Tx and Rx buffers with the TCIOFLUSH command.

do you assume:
ICANON =false
ISIG =false
IEXTEN =false

PS:
quote:
Originally posted by kumar

@damien is wrong.

The actual read() call takes about 19ms to 26ms when I try to read 4,000 bytes.


if it true, this means that when you call read() you already have a minimum of 90% of the data that is already received and present in the usart reception buffer of your PC, which is equivalent to saying that you have a minimum latency of 300mS between the moment the SPIR command was sent and the read() call. I have a doubt, or it's because your are in debug mode with breakpoints on read(), in this case when you resume the app, the data is already all received and in the buffer before executing the read () function.
4000 Bytes over 28mS <=> 1.2Mb/s effective bandwith which is impossible because we go through a physical uart between the microcontroller of the GMC-600 and the USB bridge <-> serial com port integrated in the device, and this uart is seted to max 115200 bits/s.



--
Amrith Kumar
Go to Top of Page
Reply #10

kumar

USA
7 Posts

Posted - 11/02/2021 :  05:41:18  Show Profile  Reply with Quote
Thank you so much ullix, I will read those two references.

Much appreciated.

-amrith

quote:
Originally posted by ullix

@Kumar: In the GeigerLog manual in chapter Appendix F – Firmware Differences, History Download issues, you'll find an explanation of the (former) problems.

Additionally, if you know Python you can read the comments to function getGMC_SPIR in file gdev_gmc.py.

The GeigerLog configuration file geigerlog.cfg has some options to manually correct those problems. See segment [GMCDevice] and look for GMC_SPIRbugfix and GMC_SPIRpage.

If that doesn't help, there may be a new, as yet unknown problem. The fact that sometimes you get one byte more makes me wonder. Strange that you are the first to report it?

I suggest 3 trials. Issue SPIR command ...:
- 1. ... with a download size of 2048, and check for bytes still in the serial pipeline
- 2. ... with a download size of 4095, and check for bytes still in the serial pipeline
- 3. ... with a download size of 4096, and check for bytes still in the serial pipeline

If your current program does not support this, play with GeigerLog.

Downloading 1 MB at only 115200 baud is no fun. Due to the overhead, the smaller the chunk the longer it takes. On a GMC-500+Re 2.28 I managed to download SPIR in chunks of 16k(!) not just 4k. It worked but I can't say anything about long term stability. There is a gain, but unfortunately it is marginal.

Today's USB-to-Serial chips can run at 30 times the speed (not to mentions that USB2.0 can go to >1000 times the speed).




--
Amrith Kumar
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.08 sec. Snitz's Forums 2000