MON-VER failing to retrieve software information -- NEO-M8N

0 votes

Background information: ublox NEO-M8N-0-01 and no MS OS, so please don't refer me to the uCenter software.

I am attempting to retrieve the software version information as described in the M-8 Receiver Description manual (section "27.16.11.1 Poll Receiver/Software Version") using the following command (code is being executed in a python script): 

com.write('\xb5b\n\x04\x0e\x18')

The only output returned to the console is '6' -- followed by NMEA strings. I have attempted to hard reset the module first (using the command com.write('\xb5b\x06\x04\xff\xff\x00\x08')to make sure the code is capturing the version info on a restart, however (while watching a streaming screen of the serial connection) there is no discernible difference in the stream of data - that is, the module does not appear to be restarting at all. The only output returned to the console is '8'.

1) How does the module indicate it is in the process of restarting? Is there any way to tell?

2) What is wrong with the command(s) I am sending?

by sneakyb asked Apr 13, 2016
1,493 views
0 votes
-----------------------------------------------------------------------------
0000 : B5 62 0A 04 00 00 0E 34-                        .b.....4

0A 04 MON-VER    - 0E 34 : 0E 34 8 (REQ)
-----------------------------------------------------------------------------
0000 : B5 62 0A 04 DC 00 45 58-54 20 43 4F 52 45 20 33 .b....EXT CORE 3
0010 : 2E 30 31 20 28 31 30 37-39 30 30 29 00 00 00 00 .01 (107900)....
0020 : 00 00 00 00 30 30 30 38-30 30 30 30 00 00 52 4F ....00080000..RO
0030 : 4D 20 42 41 53 45 20 32-2E 30 31 20 28 37 35 33 M BASE 2.01 (753
0040 : 33 31 29 00 00 00 00 00-00 00 00 00 46 57 56 45 31).........FWVE
0050 : 52 3D 53 50 47 20 33 2E-30 31 00 00 00 00 00 00 R=SPG 3.01......
0060 : 00 00 00 00 00 00 00 00-00 00 50 52 4F 54 56 45 ..........PROTVE
0070 : 52 3D 31 38 2E 30 30 00-00 00 00 00 00 00 00 00 R=18.00.........
0080 : 00 00 00 00 00 00 00 00-46 49 53 3D 30 78 45 46 ........FIS=0xEF
0090 : 34 30 31 35 20 28 31 30-30 31 31 31 29 00 00 00 4015 (100111)...
00A0 : 00 00 00 00 00 00 47 50-53 3B 47 4C 4F 3B 47 41 ......GPS;GLO;GA
00B0 : 4C 3B 42 44 53 00 00 00-00 00 00 00 00 00 00 00 L;BDS...........
00C0 : 00 00 00 00 53 42 41 53-3B 49 4D 45 53 3B 51 5A ....SBAS;IMES;QZ
00D0 : 53 53 00 00 00 00 00 00-00 00 00 00 00 00 00 00 SS..............
00E0 : 00 00 A0 C4                                     ....

0A 04 MON-VER    - A0 C4 : A0 C4 228

EXT CORE 3.01 (107900)
00080000
ROM BASE 2.01 (75331)
FWVER=SPG 3.01
PROTVER=18.00
FIS=0xEF4015 (100111)
GPS;GLO;GAL;BDS
SBAS;IMES;QZSS

-----------------------------------------------------------------------------

 

by clive1 answered Apr 13, 2016
by sneakyb selected Apr 13, 2016
Flag
Best answer
clive1:
Thank you very much for your response. Your hex byte sequence did indeed produce successful output for me. I have a new (related) question, however.

In the documentation, the section (27.16.11.1 Poll Receiver/Software Version) explicitly states that the payload is of 0 bytes. As such, my original hex sequence looked like the following:
0xb5 0x62 0x0A 0x04 + chk_a
[0] header
[1] header
[2] class
[3] id
[4] [nothing for the payload of 0 bytes]
[5] checksum

Can you please explain where the 00 00 0E portion of your byte sequence comes from?
B5 62 Header
0A 04 UBX-MON-VER Opcodes
00 00 Is the 16-bit length of the payload, ie nothing follows
0E 34 Is the 16-bit checksum composed of chk_a and chk_b
From the Protocol Specification, you want to review
21 UBX Protocol
21.2 UBX Packet Structure
0 votes
May be you can write this out as hex bytes so I don't have to translate the glyphs? Right now it doesn't look like you have the required checksums.
by clive1 answered Apr 13, 2016
by clive1 edited Apr 13, 2016
Sending this sequence of hex bytes should elicit the desired response
B5 62 0A 04 00 00 0E 34
website banner