I’ve been working on the issue of BT GPS connection for the past few days, ever since Antonio’s NXC code demonstrated that this is a possibility. In the LabView diagram above (click here for full resolution image) I show a preliminary step toward this goal. I’ve made VIs (i.e. the LabView term for blocks) that read an ASCII stream, and some prelimiary string parsing VIs. Since I have no BT GPS, I had my PC connect as the slave device, and wrote another LabView code that sends the NMEA-0183 formated string:
$GPGGA,023346.028,3604.1654,N,08655.7973,W,0,00,50.0,198.2,M,-31.6,M,0.0,0000*76\r\n
at specified intervals (e.g. each 1000 milisecond).
The resulting file stored on the NXT contains a long list of this message:
GPGGA,023346.028,3604.1654,N,08655.7973,W,0,00,50.0,198.2,M,-31.6,M,0.0,0000
GPGGA,023346.028,3604.1654,N,08655.7973,W,0,00,50.0,198.2,M,-31.6,M,0.0,0000
GPGGA,023346.028,3604.1654,N,08655.7973,W,0,00,50.0,198.2,M,-31.6,M,0.0,0000
GPGGA,023346.028,3604.1654,N,08655.7973,W,0,00,50.0,198.2,M,-31.6,M,0.0,0000
.
.
.
without any errors so far. From another test is seems that as I suspected the NXT ‘catch’ the GPS data correctly every 2-3 cycles of my “GPS” data stream.
What’s next? Parsing the GPGGA data, and making the NXT-G block around all this… Keep watching for it!

In the meantime, Antonio posted me an improved version of the code. He claims this code loses only 20% of the messages (compared to ~60% in mine, and his old code). You can download the new code here. I still need to figure out what makes the difference, and see how I can implement it in LabView…

Questions/comments - use this forum topic.

Guy Ziv