working but error msg on poor GPS data

[dillonbuhl]

Basically got server.py working

• In virtual machine's settings, enabled a single serial port assigned to COM2 in "Host Device" mode
• Note: the default port for navcoldex gui is 4063. A dialog box pops up with localhost as default host and that as default port number. Changing the port number to 2020 and hitting continue brings up an "Invalid input" GUI message.
• But works seemingly ok when specifying 4063 to server.py.
• Did not have wp's loaded; didn't do a walking test or anything. Only indication of proper data in navcoldex GUI was that the time was correct and no error messages.

when I tried running it in the office with incomplete GPS data (ie, Garmin has no sv's, no position, etc but still spitting out messages), server.py gives the error

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "./server.py", line 166, in nmea_serial_handler
    ns2.update_nmea(line)
  File "/home/igadmin/Downloads/navcoldex_data/navcoldex_gnss_server/nav_nmea.py", line 40, in update_nmea
    method(msg)
  File "/home/igadmin/Downloads/navcoldex_data/navcoldex_gnss_server/nav_nmea.py", line 66, in update_RMC
    fields['hor_spd'] = convert_speed(msg.spd_over_grnd, units_in='N', units_out='M')
  File "/home/igadmin/Downloads/navcoldex_data/navcoldex_gnss_server/nav_nmea.py", line 19, in convert_speed
    speed_m = speed / 1.94384
TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'

But was still sending out data that looks like:

igadmin@qcvm20a:~/Downloads/navcoldex_data$ nc localhost 4063
11,19800101,000000.0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
11,19800101,000000.0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
11,19800101,000000.0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
11,19800101,000000.0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000
11,19800101,000000.0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000

I don't know if you/we care... Just mentioning since it might behave similarly with momentary interrupts in data quality or something...

Note: it's also sending out occasional Parse Errors, seeing messages it thinks are ' ', but that's probably ok... didn't happen more than once or twice in a minute or so.

[gregoryng]

Yeah I guess the parse errors are simple enough that they are worth fixing. I think What you're seeing is typical for having never gotten a position fix that it can parse. Once you get a fix, the zeroes will be something valid.

Can you tell if the parse errors seem like they're coming from pynmea or my code?

[dillonbuhl]

parse errors look like

WARNING:root:Parse error: ('could not parse data', '22,3.8,E,A*0F\n')

your code?...

[dillonbuhl]

that one in particular was probably on instantiation; it throws an error on the first, partially-received nmea msg

[gregoryng]

Ok no that one's not me, that's pynmea so you'll have to live with that message coming out. The exception I'll have to do something to deal with.

[dillonbuhl]

that's totally fine. good to have visibility if it's having trouble parsing messages. like I said above, your code seems to still be sending out data after throwing that exception related to the speed calculation. Do you think it's still "working correctly" at that point?...

[gregoryng]

No, it's probably stopped parsing at that point. But I'll have it not throw the exception so it can continue and not stop unnecessarily.

If there is an unhandled exception, I guess I can try to figure out how to signal to the other thread in the server to stop, so the whole server stops. I may or may not get to this, since it'll be obvious to you if this happens (your gui will stop "flying"), and your response to it happening is the same either way -- restart the server and report to me the unhandled exception.

I'll also change the default listen port to 4063

[gregoryng]

Things should be better now. Feel free to reopen if new git revision doesn't help NMEA messages. Open a new issue if it's related to parsing of Javad/Topcon binary data (they are compatible formats) or Novatel data.