Confirm GPS is responsive before claiming GPS initialization complete

[bkwny]

1. Stratux version:
   0.7b1 + 1 commit
2. Stratux config: single/dual SDR, GPS yes/no (type?), AHRS yes/no, battery, battery cable.
   Dual SDR Nano 2. RY835AI via GPIO. AHRS no. External power.
3. EFB app and version (e.g., WingX Pro7 8.6.2). EFB platform (e.g., iOS 9.2). EFB hardware (e.g., iPad Mini 2).
   N/A for this issue.
4. Description of your issue. If possible, enable "Replay Logs", reproduce the problem, and provide a copy of the logs in http://192.168.10.1/logs/stratux/ and http://192.168.10.1/logs/stratux.log.

In ry835ai.go at line 124 we have function initGPSSerial() which attempts to initialize the GPS receiver. The function both initializes the serial port and writes initialization messages to the attached GPS receiver so as to configure it. The function then writes a console message claiming GPS initialization complete. The console message suggests to the user the GPS receiver was responsive to the initialization messages and is now ready to do work.

In wiring my HAT I inadvertently switched RXD and TXD. Thus no messages were ever flowing to the GPS receiver and in fact the R Pi never established communication with it. Stratux repeatedly printed a stanza of console messages claiming GPS initialization complete. The serial port might well have been initialized but communication with the GPS receiver clearly was never established. Once I found and repaired my wiring mistake all was well.

I suggest initGPSSerial() not claim and print GPS initialization complete until it has confirmed it really is in communication with the GPS receiver. Once configuring the serial port, make an attempt to send something, receive the response, parse the response, and confirm the parsed response is as expected. If that all works then claim GPS initialization complete. Otherwise print some kind of error message indicating which step in that sequence failed.

[skypuppy]

When reading a com port, even an empty one, random noise can show up
even if no signal is there. Problem is common across all rs-232 devices
and computers. And any signal the host sees will indicate the port is
working. Sad but true. Doesn't happen often with shielded cable but it
still does, and the little wires we use with the RPi2 have zero
shielding. Best one can do is establish a timeout function for the gps
to respond and hope for the best.

On 02/16/2016 05:58 AM, bkwny wrote:

Stratux version:
0.7b1 + 1 commit

Stratux config: single/dual SDR, GPS yes/no (type?), AHRS yes/no,
battery, battery cable.
Dual SDR Nano 2. RY835AI via GPIO. AHRS no. External power.

EFB app and version (e.g., WingX Pro7 8.6.2). EFB platform (e.g.,
iOS 9.2). EFB hardware (e.g., iPad Mini 2).
N/A for this issue.

Description of your issue. If possible, enable "Replay Logs",
reproduce the problem, and provide a copy of the logs in
http://192.168.10.1/logs/stratux/ and
http://192.168.10.1/logs/stratux.log.

In ry835ai.go at line 124 we have function initGPSSerial() which
attempts to initialize the GPS receiver. The function both initializes
the serial port and writes initialization messages to the attached GPS
receiver so as to configure it. The function then writes a console
message claiming GPS initialization complete. The console message
suggests to the user the GPS receiver was responsive to the
initialization messages and is now ready to do work.

In wiring my HAT I inadvertently switched RXD and TXD. Thus no
messages were ever flowing to the GPS and in fact the R Pi never
established communication with it. Stratux repeatedly printed a stanza
of console messages claiming GPS initialization complete. The serial
port might well have been initialized but communication with the GPS
receiver clearly was never established. Once I found and repaired my
wiring mistake all was well.

I suggest initGPSSerial() not claim and print GPS initialization
complete until it has confirmed it really is in communication with the
GPS receiver. Once configuring the serial port, make an attempt to
send something, receive the response, parse the response, and confirm
the parsed response is as expected. If that all works then claim GPS
initialization complete. Otherwise print some kind of error message
indicating which step in that sequence failed.

—
Reply to this email directly or view it on GitHub
#253.

[Ergonomicmike]

Since NMEA sentences start with the $ sign, can the code look for $ signs? (Two or three in two or three seconds (assumes worst case of 1 Hz) to make sure the first wasn't random noise?) Or, since commas are a large part of the NMEA sentence, look for 3 commas in a second to say GPS is working?

[bkwny]

"And any signal the host sees will indicate the port is working." I disagree. For us to proclaim the GPS receiver is working and therefore GPS initialization is complete, the data received from the port has to be some syntactically valid response to whatever it was we wrote to the port. I don't know the protocol well enough to prescribe what we should write and what we should look for in response, but the parsing of the response should reveal that the response is a fully formed, syntactically valid response to whatever it was we wrote. Failing that the GPS receiver is not online and so initialization is not complete.

[skypuppy]

IF one adds validation code upon initializing an RS-232 port, then yes,
your validation rules will apply. If, however, one just looks for init
without further validation, then it may pass. Further, even if the baud
rates do not match, the init will pass, without further validation on
your part. The "stuff" that came through will be garbage (not ANSI
char's) but the OS doesn't care about that.

On 02/16/2016 10:10 AM, bkwny wrote:

"And any signal the host sees will indicate the port is working." I
disagree. For us to proclaim the GPS receiver is working and therefore
GPS initialization is complete, the data received from the port has to
be some syntactically valid response to whatever it was we wrote to
the port. I don't know the protocol well enough to prescribe what we
should write and what we should look for in response, but the parsing
of the response should reveal that the response is a fully formed,
syntactically valid response to whatever it was we wrote. Failing that
the GPS receiver is not online.

—
Reply to this email directly or view it on GitHub
#253 (comment).

[ghost]

"The function then writes a console message claiming GPS initialization complete."

I added that message as a development / debug marker when I reworked the u-blox initialization code several weeks ago. Sole intent was to flag when the serial writes were done and that the port was being reopened to read.

You're right, though that these are blind writes, and that Stratux doesn't know if the GPS actually configured itself until the port is opened and we start listening for NMEA messages. In my development branch, I've updated the wording to:

Finished writing u-blox GPS config to %s. Opening port to test connection.

with similar wording for other GPS types to be added as other initialization routines are added (SIRF, Mediatek, ST Micro, etc.)

As to the other points about detecting / validating signals, the current codebase validates NMEA message checksums to determine that the port is receiving correctly. Upon verification, mySituation.LastNMEAMessage with the Stratux clock each time a valid sentences are read. Function isGPSConnected() is periodically called to then compares this against the current clock value, and if no valid messages have been received in the previous five seconds, we trigger a reconnect / reinitialize sequence.

There's future work to do for finer-grained control of the initialization process (better device detection; explicit verification that specific init messages are received, etc.) but development is already moving in that direction.

[skypuppy]

WOW!

On 02/17/2016 08:49 AM, AvSquirrel wrote:

"The function then writes a console message claiming GPS
initialization complete."

I added that message as a development / debug marker when I reworked
the u-blox initialization code several weeks ago. Sole intent was to
flag when the serial writes were done and that the port was being
reopened to read.

You're right, though that these are blind writes, and that Stratux
doesn't know if the GPS actually configured itself until the port is
opened and we start listening for NMEA messages. In my development
branch, I've updated the wording to:

|Finished writing u-blox GPS config to %s. Opening port to test
connection. |

with similar wording for other GPS types to be added as other
initialization routines are added (SIRF, Mediatek, ST Micro, etc.)

As to the other points about detecting / validating signals, the
current codebase validates NMEA message checksums to determine that
the port is receiving correctly. Upon verification,
|mySituation.LastNMEAMessage| with the Stratux clock each time a valid
sentences are read. Function |isGPSConnected()| is periodically called
to then compares this against the current clock value, and if no valid
messages have been received in the previous five seconds, we trigger a
reconnect / reinitialize sequence.

There's future work to do for finer-grained control of the
initialization process (better device detection; explicit verification
that specific init messages are received, etc.) but development is
already moving in that direction.

—
Reply to this email directly or view it on GitHub
#253 (comment).

[Ergonomicmike]

WOW +1!

[ghost]

Improved GPS detection (including device identification and post-configuration validation) is in my development branch. Targeting later this week for a pull request.