Teensy3.6 with TinyGPS, Interrupts

Status
Not open for further replies.
I'm not aware of any Arduino library or ready-to-use code that does quite what you want. Maybe it's out there? But my guess is you're going to have to do some substantial programming work to build this.

At least you *can* get the micros() count pretty easily, and you can (with some not-very Arduino-like syntax) raise your interrupt to top priority (if that's even necessary) to really get a PPS capture timestamped to within 1 us.

Maybe you'll just subtract each one from the previous, to get the number of microseconds of "Teensy time" which actually elapsed using 1 GPS second? Or maybe you'll average the last several of those, or maybe run them through a low-pass filter or other algorithm to give you finer resolution and reject the likely +/- 1us measurement jitter?

How you're going to actually use that info to process your MPU9250 data is a good question. If you're already doing some sort of filter based on the assumed sample rate (especially of the gyro data), maybe the difference in actual versus assumed/nominal sample rate can be applied as merely a minor (ideally linear) correction factor if the difference between Teensy's crystal and the GPS true PPS time is very small?

You might also consider whether any of this is even meaningful. MEMS-based motion measurement typically has analog bandwidth in the dozens to (maybe) hundreds of Hz. Some chips allow you to select different filters. But internally, they all work on the same principle, where a tuning fork oscillators in the dozens to hundreds of kHz and motion modulates it. The changes are demodulated to a pulsing signal and then filtered. The final result necessarily has fairly low bandwidth to give you high resolution, or more noise if you want higher speed.

We've actually had several other people ask here about doing all sorts of elaborate things with MEMS motion sensors. I recall one recent thread involved trying to sample hundreds of (unspecified) on/off sensors (of unspecified bandwidth) at some extremely high speed and then trying to correlate that data with an IMU chip. It's easy to imagine building such incredibly high speed signal acquisition, without really considering whether the analog signal sources even has high enough speed/bandwidth and reproducible enough timing characteristics to make all that effort worthwhile.

Most of these sensors also have offsets & drift. That's why the filters are used, especially for accelerometers and magnetometers to correct for gyroscope drift. I'm having a hard time imagining how very minor timing corrections could end up being anywhere on the scale of the pretty substantial drift in these measurements.

Anyway, this question does come up from time to time. If you do find a want to use this data and somehow eek out a tiny bit extra performance that actually matters with real IMU data, I hope you'll consider sharing anything you learn along the way?
 
I appreciate the thoughts, thx! This project does have several challenging parts. But I'm thinking it's definitely doable, if I can get the accel measurements from the IMU accurate enough (timing, correct coordinate system, and not too noisy).

My approach is to start relatively simple, i.e. 1Hz GPS and 5Hz accel measurements into my Kalman filter. I already have some pieces implemented
- MPU9250 with Mahony filter outputting accel and PRY at very fast rate
- Ultimate GPS producing very accurate lat/long/alt at 1Hz
- Tested that I could create PPS interrupt with the Ultimate GPS board

Still to go stuff includes:
- Figure out how to time-tag accel measurements accurately
- Figure out how to get GPS reading at 1HZ without tying up processor time (i.e., no polling)
- Port my coordinate transformation routines over from Python
- Modify my MPU6050 Kalman filter routine or create new one
- SD logging of data

If I'm successful, this will be a nice INS/GPS testbed that I can use for a variety of things, including some of the drone technology work I do!
 
I have the Ultimate GPS board successfully running on a Teensy3.6 using the tinyGPS (and tinyGPSPlus) library. I'd like to be able to read and parse the lat/long/alt when the PPS signal occurs. Is there a way to do this? The tinyGPS example sketches seem to be polling the chip nearly continuously with this block of code:

start = millis();
do
{
while (ss.available())
gps.encode(ss.read());
} while (millis()-start<1000);

I'd like the PPS to tell me when the start of a new GPS second is, then I'll read the GPS chip to get lat/long/alt, then I can go off and do other things (like use a Kalman to integrate accel measurements) until the next PPS signal.

Any suggestions or thoughts? Thanks!

I've looked at this a bit now and thought I'd follow up:

That snippet doesn't show that #define ss Serial2 is behind it. So this code just reads any incoming bytes and parses them on the fly until the GPS output stream completes. So given that the Teensy likely loop()'s faster than serial data arrives it will only be in that 'while( Serial2.available() )' for the byte or bytes accumulated.

The other note is that this GPS when powered just starts streaming out updates on its schedule ( according to Adafruit ) - even in the case that the GPS doesn't have a satellite lock. So keeping the incoming data cleared has to be done one way or another - otherwise the data pulled will be stale or corrupted/lost by overrun.

And in some fashion indeed the PPS clock will tick independent of data ready - will see when I power one up if the PPS maintains from internal clock even when satellites are lost.
 
Status
Not open for further replies.
Back
Top