This project is read-only.

Unable to read underlying stream when device is turned off and back on

Apr 22, 2010 at 4:23 PM

We're using GPS.NET 3.0.1 in the development of a Windows Forms application. The device we're using is connected to the machine via Bluetooth.

As part of our testing we wanted to verify that we could turn the GPS device off and back on again and continue reading the NMEA stream from the device. This was meant to simulate a loss of battery power. Unfortunately, once the device is turned back on, the GPS.NET library is unable to reconnect to the device to read the NMEA data stream.

Can anyone provide any insight?

May 3, 2010 at 4:41 PM

I actually devoted a significant amount of time and effort a few months ago (just before the 3.0.1 release) specifically to addressing the problem of re-detection after a lost connection.  Unfortunately, I only have a small number of devices to test with, so it's entirely possible that you're encountering an issue that I wasn't able to produce.  For starters, I was only able to test with COM and USB devices, not Bluetooth.

Try this:  Build and run the diagnostics utility (under the Examples folder) and click the "Start" button.  It should detect your GPS device and start processing its signals.  If it doesn't find your GPS, then try checking the "Exhaustive Scan" checkbox and try again.  Once your device has been detected and the diagnostic utility has started processing its signals (switch to the "Raw Data" tab to verify this), disconnect the GPS from the PC, wait a few seconds, then reconnect it.  The diagnostic utility should automatically re-detect the GPS within a few seconds (10 or so) and resume processing its signals.  You should be able to repeat this process of disconnecting and reconnecting the device repeatedly, and it should always be re-detected.

If the above test does not work (i.e. the diagnostic utility fails to re-detect the device), then there is probably a bug in the re-detection and re-connection logic in GPS.Net.  This logic is controlled by the ParsingThreadProc method of the Interpreter class.  Try putting a few breakpoints in that method and then run the diagnostic utility again in debug mode to find out what's going wrong.  If you find a bug (or even better, a bug fix), then feel free to post it here.