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
 Downloading data
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

hmw

8 Posts

Posted - 01/16/2017 :  23:07:37  Show Profile  Reply with Quote
Hi,

I try to download the saved data from the GMC-320+, revision 4.11. The good news is, that it works, but there are some questions.

The protocol specification for the SPIR command states:

"The length normally not exceed 4096 bytes in each request."

What does that mean? Is that a hard limit? Does that mean, I can't request, let's say, 8k of data in one go? Is there a connection between performance and the size of the requested data chunk?

One problem I encountered is, that the device is slow. It takes several minutes to download the entire 1MB from the device. The freely downloadable software seems to have the same problem. It looks like one have to introduce lots of delays when reading data back from the device (after sending the SPIR command). Sometimes the device stops to deliver data after a random amount of delivered bytes. That seems to occur more often, if I make the delays smaller, let's say from 100ms down to 1ms. I'm not sure yet, if that is a problem with my environment or with the device. I observed that using a C programme, as well as with Python's serial module.

So the question is, can I speed up the process?

Another problem I encountered is this: I send

'<SPIR\x00\x00\x00\x00\x20>>'

to the device. That means I request 0x20 bytes from address 0x0. But the device delivers more than 0x20 bytes, usually 1 byte more. What happens if I request 10 bytes from the upper end of the memory? Does the device deliver 11 bytes? What is the 11th byte, that is 'beyond' the memory? Is it a ring buffer and the byte comes from address 0 then?

Regards
hmw

Edited by - hmw on 01/17/2017 01:35:29
Reply #1

ZLM

1261 Posts

Posted - 01/19/2017 :  23:33:30  Show Profile  Reply with Quote
It seems you are right. It is a software bug. You can ignore the last byte.

I think you need to use Data Viewer s software menu Terminal to test it first.

If the command works good in that software, then most likely the problem came from your software.
Go to Top of Page
Reply #2

ullix

Germany
1107 Posts

Posted - 02/05/2017 :  05:51:38  Show Profile  Reply with Quote
hmw: I have some different struggles with the SPIR command. see http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4445

My device is GQ GMC-300E plus with firmware GMC-300Re 4.20. In my Python script, requesting 0x20 bytes allows me to read 0x21 bytes, but not more than that (then a serial port timeout results). This 33rd byte is the correct one for that position.

Applying this observation to my issue of reading 4096 bytes: if the firmware does indeed try to deliver an additional byte to the number requested, then it would try to read a 4097th byte.

However, it still should not fail, because the statement "The length normally not exceed 4096 bytes in each request." does suggest that a reading greater than 4096 is possible, though perhaps not recommended for whatever reason.
Go to Top of Page
Reply #3

ullix

Germany
1107 Posts

Posted - 02/07/2017 :  04:49:18  Show Profile  Reply with Quote
see my comment on http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4445 for more insight into the bug
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.06 sec. Snitz's Forums 2000