what I really need is to be able to program the GPS to get what I need, when I need it and nothing else. That seems to mean sending UBX commands.
Well, you might be ok sticking with NMEA if you turn off all sentences and then poll for the ones you want. You could even send some UBX binary configuration commands. Next, you could try polling for the more-compact PUBX NMEA messages instead of the typical GGA+RMC combo. If you still need more time or fewer interrupts, then I'd switch to the UBX binary protocol.
it won't build for me, throwing errors about being unable to find a serial port.
I've never built for the Teensy 3.0, but at least one other user has tried compiling NeoGPS on a 32-bit platform. I made a few changes related to its 32-bit quirks vs. the 8-bit AVRs.
The examples all try to pick a serial port, based on which Arduino you're using. I don't think it knows what to do for your build. Just delete the include of GPSport.h, and declare your own gps_port
variable for it to use... assuming you have one for testing?
If you're using I2C in a polling style at this point, you'll need to modify the polling examples' loop
to feed bytes to NeoGPS:
static void GPSloop()
{
while ( I2C_data_available() ) {
.
.
.
if (gps.decode( I2C_read_byte() ) == NMEAGPS::DECODE_COMPLETED) {
If you're using I2C in an interrupt style, you'll need to modify the NMEAfused_isr.ino example to hook it to your interrupt and pass it the byte:
static void GPSisr( uint8_t c ) // called when I2C has a byte?
{
if (gps.decode( c ) == NMEAGPS::DECODE_COMPLETED) {
.
.
.
}
are there any major obstacles (such as only having an I2c interface) controlling the NEO-6 with your library and the Teensy?
LOL, I don't know what I don't know. 32-bit vs 8-bit should be the biggest thing. If you can get the I2C bytes and pass them to NeoGPS' decode
function, it won't care where they came from.
There could be some effort in getting the UBX protocol working over I2C. I think there's some Serial-specific timing related to the ACKs that are supposed to come back when you send configuration commands. And there's a sequence of steps you have to perform before you can even use the UBX POSNAV and VELNED messages.
I'd really suggest trying an optimized NMEA approach first. You may find the increased efficiency of NeoGPS is all you need. For the typical GGA+RMC, NeoGPS uses just 1.7ms vs 2.9ms per update (on a 20MHz AVR), nearly twice as fast. If you only need lat/lon/alt (not date/time/satellites/hdop), it's even faster.
So far, its seems that the biggest problem for new users is understanding when they need a safe copy of "the current fix". Understanding how new pieces of a fix should be merged as they are received is also important. If you're using the interrupt style, then gps.fix()
could change at any time. You will have to double-buffer it.
Picking a custom configuration can also be tricky, but there is some compile-time assistance for invalid configurations.
Cheers,
/dev