Issue with Megastek Protocol (missing field)

Thiritin3 years ago

I'm currently having an issue where my Megastek devices are not capeable of decoding the message from hex to gps. They always send GPS Data even if they don't have a fix (use last position). I can verify that the device sends data to the Server trough the server logs.

In the below protocol response I marked " No value from Hex" to rfid, could someone verify that is ineed the issue. Perhaps then creating a PR and making this field optional would solve the issue?

I tried to map the Pattern to my Protocol response (sorry for the long text)
(Left Value using the hex converter, right the Pattern code..)

0143  .number("dddd").optional()
$MGV .text("$MGV")
002, .number("ddd,")
860500036302030,  .number("(d+),") // imei replaced some numbers with 0 for privacy purposes
, .expression("[^,]*,") //name
R, .expression("([RS]),")
220621, .number("(dd)(dd)(dd),")             // date (ddmmyy)
112604, .number("(dd)(dd)(dd),")             // time (hhmmss)
V, .expression("([AV]),")               // validity
5002.00009,N, .number("(d+)(dd.d+),([NS]),")       // latitude some numbers replaced to 0 for privacy
00001.30008,E, .number("(d+)(dd.d+),([EW]),")       // longitude some numbers replaced to 0 for privacy
00, .number("dd,")
00, .number("(dd),")                     // satellites
00, .number("dd,")
99.9, .number("(d+.d+),")                  // hdop
, .number("(d+.d+)?,")                 // speed
, .number("(d+.d+)?,")                 // course
, .number("(-?d+.d+),")                // altitude
, .number("(d+.d+)?,")                 // odometer
232, .number("(d+),")                     // mcc
10, .number("(d+),")                     // mnc
A5AE, .number("(xxxx)?,")                  // lac
5A4908, .number("(x+)?,")                    // cid
16, .number("(d+)?,")                    // gsm

--  .groupBegin()
0000, .number("([01]{4})?,")               // input
0000, .number("([01]{4})?,")               // output
0, .number("(d+),")                     // input
, .number("(d+),")                     // output
, .number("(d+),")                     // adc1
, .number("(d+),")                     // adc2
, .number("(d+),")                     // adc3
.groupEnd()

.groupBegin()
, .number("(d+)?,") // rfid
00, .number("([01])(d)?").optional() // charge and belt status
.expression("[^,]*,") // missing????? <==== No value from Hex
093, .number("(d+)?,")                    // battery
Timer, .expression("([^,]*)[,;]")           // alert
, // any
;!

Here is the converted hex to ascii (imei and latlog some nums replacedto 0)

0143$MGV002,860500036302000,,R,220621,121204,V,5000.00009,N,01001.30008,E,00,00,00,99.9,,,,,232,10,A5AE,5A4908,22,0000,0000,0,,,,,,00,092,Timer,,;!

In the logs there is just the INFO HEX: no Long/lat after that or any error. So it definetly receives the message, it's also with the megastek protocol.

2021-06-22 12:13:09  INFO: [9561696c: megastek < 10.0.0.2] HEX: 30313433244d47563030322c3836373538343033363338323933 [...]

Links

Devices I'm testing with

  • M60X 2G
  • M200X 4G (This is where the response is from)
  • M65X 4G

Thanks!

Anton Tananaev3 years ago

Feel free to send a PR. Make sure to include a unit test.

Oliver3 years ago

I am currently working on a PR to fix some more stuff with the megastek protocol (such as this) as this has occured to me as well after testing the last PR with real hardware.
I did not submit it yet since I'm trying to figure out some weird protocol glitch but I hope for it to be ready in the next couple days. :)

Anton Tananaev3 years ago

We already merged the PR for this issue.