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

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List Spell Checker
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

   Insert an Image File
Check here to include your profile signature.
    

T O P I C    R E V I E W
hmw Posted - 01/16/2017 : 23:07:37
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
3   L A T E S T    R E P L I E S    (Newest First)
ullix Posted - 02/07/2017 : 04:49:18
see my comment on http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4445 for more insight into the bug
ullix Posted - 02/05/2017 : 05:51:38
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.
ZLM Posted - 01/19/2017 : 23:33:30
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.

GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.07 sec. Snitz's Forums 2000