stratux
stratux copied to clipboard
cyoung
Confirm GPS is responsive before claiming GPS initialization complete
- 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 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.
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 https://github.com/cyoung/stratux/issues/253.
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?
"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.
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 https://github.com/cyoung/stratux/issues/253#issuecomment-184748647.
"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.
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 https://github.com/cyoung/stratux/issues/253#issuecomment-185236409.
Improved GPS detection (including device identification and post-configuration validation) is in my development branch. Targeting later this week for a pull request.