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