GQ Electronics Technical Support Forum


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
 GQ Geiger Muller Counter
 Struggling with the SPIR command
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

ullix

Germany
89 Posts

Posted - 01/31/2017 :  08:56:02  Show Profile  Reply with Quote
My device is "GQ GMC-300E plus" with firmware "GMC-300Re 4.20". I access the device with my Python script under Linux Ubuntu and try to read histroical data with the SPIR command.

The GQ-RFC1201, Geiger Counter Communication Protocol document says:

quote:
The length normally not exceed 4096 bytes in each request.


When I ask for 4095 (1 less) bytes beginning at the address 0x00 I get them all (from #0 to #4094) in under 1 second. But when I ask for 4096 the device stalls. When opening the serial port with a 10sec timeout I get a single byte only. Same failure when I try to read anything exceeding 4096 bytes.

When I use an address of 256 (instead of zero) and again read only 4095 bytes it again works, demonstrating that I can read beyond 4096 bytes (though last 600 or so bytes are all 0xff), and fails when trying 4096 bytes.

So, can I actually read 4096 (0x10 0x00) bytes or is 4095 (0x0f 0xff) the maximum chunk?

Reply #1

phgphd

USA
12 Posts

Posted - 02/02/2017 :  17:06:11  Show Profile  Reply with Quote
The history buffer on the GMC is 64K bytes deep. So reading starting at address 256 reads bytes from 256 to 256+4095 and will be successful. As to why only 4095 can be read successfully, I can only speculate that the GMC firmware has a bug. A work around would be to read 2k bytes at a time which only doubles the amount of reads necessary to get the whole 64K bytes.
Go to Top of Page
Reply #2

ZLM

1066 Posts

Posted - 02/02/2017 :  19:39:34  Show Profile  Reply with Quote
The address start from 0. So, your 4096 address is 4097 bytes long. This will cause the firmware into a dead loop.

The protocol said not exceed the 4096 bytes which is the address from 0 to 4095.

See below commands:

SPIR 00 00 00 0F FF read first 4K history data.

SPIR 00 10 00 0F FF read second 4K history data.
SPIR 00 20 00 0F FF read third 4K history data.
.....
SPIR 00 F0 00 0F FF read last 4K history data from GMC-300.

....
SPIR 0F 00 00 0F FF read last 4K history data from GMC-320.
Go to Top of Page
Reply #3

ullix

Germany
89 Posts

Posted - 02/05/2017 :  05:22:25  Show Profile  Reply with Quote
I ended using 2048 bytes as a chunk for a single SPIR command, and this works and works fast enough.

However, it is not true that I am reading 4097 bytes when requesting 4096. See this outcome from the code pasted below:
The device is: 			GQ GMC-300E plus
SPIR datalength requested:	4095 , hex chars in SPIR command: 0f ff
SPIR data received length:	4095 <type 'str'>
SPIR history data are:   	(Format: dec byte_number:hex value)
				   0:55      1:aa      2:00      3:11      4:01 (and so on...)

The device is: 			GQ GMC-300E plus
SPIR datalength requested:	4096 , hex chars in SPIR command: 10 00
SPIR data received length:	1 <type 'str'>
SPIR history data are:   	(Format: dec byte_number:hex value)
				   0:55  

The first lines show that a request for 4095 bytes returns 4095 bytes.
The next lines show that a request for 4096 bytes returns only 1 byte (and the serial port runs into a timeout).

If this was meant to return 4096 bytes then I'd say it is a bug?

The test program:

#!/usr/bin/python
# -*- coding: UTF-8 -*-

import serial       # the communication with the serial port


def getSPIR(ser, address = 0, datalength = 4096):

    ad    = chr(0x00) * 3   # for testing address fixed at 0x000000
        
    dlmsb = chr((datalength & 0xff00) >> 8)
    dllsb = chr((datalength & 0xff) )    
    dl    = dlmsb + dllsb
    print "SPIR datalength requested:\t", datalength, ", hex chars in SPIR command: {:02x} {:02x}".format(ord(dlmsb), ord(dllsb))
  
    ser.write(b'<SPIR'+ad+dl+'>>')
    rec   = ser.read(datalength)

    print "SPIR data received length:\t", len(rec), type(rec)
    
    return rec


def main(argv=None):
   
    print "The device is: \t\t\tGQ GMC-300E plus"

    # open the serial port !!! NOTE: baud rate must be set at device first, default is 57600 !!!
    ser  = serial.Serial('/dev/ttyUSB0', 115200, timeout= 6) 

    spir = getSPIR(ser, 0 , 4096 - 0)
    
    print "SPIR history data are:   \t(Format: dec byte_number:hex value)"    
    for i in range(0, 16):            # limit printout to first 256 bytes
        print "\t\t\t\t",
        for j in range(0,16):
            k  = i*16 + j            
            print "%4d:%02x  " % (k, ord(spir[k])),
        print                             
        
    ser.close()                          # close port

########################################################################
if __name__ == "__main__":
    main()
        
Go to Top of Page
Reply #4

ullix

Germany
89 Posts

Posted - 02/07/2017 :  04:47:50  Show Profile  Reply with Quote
I believe to have figured out what the problem is. Looks like a bug in the firmware.

Upon a SPIR command requesting datalength bytes the device - in my case a "GQ GMC-300E plus" with firmware "GMC-300Re 4.20" - delivers:

[(datalength modulo 4096) + 1]

bytes. So when asking for:

- 0 (zero) bytes, it delivers 1 byte
- 32 bytes, it delivers 33 bytes
- 4096 bytes, it delivers 1 byte (because (4096 modulo 4096) = zero, plus 1 byte = 1 byte; same as first case)
- 4128 bytes, it delivers 33 bytes (because (4128 modulo 4096) + 1 = 32 + 1 = 33 bytes )

Note that 4128 = 4096 + 32 = 0x0fff + 0x0020. The firmware probably ANDs the datalength with 0x000fff and then the bug delivers an extra byte. So, while you can request datalength > 4096, only the moduloed portion will be used.

You can test this yourself easily with my geiger_SPIRtest.py code downloaded from https://sourceforge.net/projects/geigerlog/files/

Remains to be verified with other devices.
Go to Top of Page
Reply #5

ZLM

1066 Posts

Posted - 02/07/2017 :  19:38:07  Show Profile  Reply with Quote
The firmware limited the length to 4096+1 bytes.

Before read the data, the requested length does a AND binary operation with 0xFFF in hex value.

Go to Top of Page
Reply #6

ullix

Germany
89 Posts

Posted - 02/08/2017 :  07:21:53  Show Profile  Reply with Quote
Actually, the limit is not 4096+1 = 4097 bytes, but 4096. However, you have to ask for 4095 bytes, in order to get 4096!

This bug makes further problems under certain conditions:

E.g., when you ask for 5 bytes from address 0, you send:
<SPIR00005>>
Reading 5 bytes gives you the bytes from addresses 0, 1, 2, 3, and 4. However, the device readies a 6th byte, which you haven't read yet.

Sending another command
<SPIR00005>>
does not result in dumping that extra byte from the first command, but instead this byte is being delivered now with the 2nd read:
Reading again 5 bytes gives you the bytes from addresses 5, 0, 1, 2, 3. Now 2 additional bytes are waiting for being read, and so on.

If this happens within a data sequence, you get spurious readings. If it happens within a tag, your history likely becomes a complete mess.

So, you cannot ignore that extra byte, you MUST make sure that it is read (and handled or discarded). My history data have already suffered from this.

Clearly, this is a bug and needs to be fixed! Will GQ be fixing it?
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.09 sec. Snitz Forums 2000