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

---

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.

---

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.

---

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.

---

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

---