I have a dream: standardization for GPS trackers

[FredA]

Last I looked - and it's been a few years - the MEMS couldn't match the stability (normal G) and output purity of true XTALs.

 

[rocket_troy]

Fred,
I'm increasingly coming to the conclusion that the acceleration constraints of GNSS receivers is primarily caused from doppler issues and less so from crystal timing/shifting. I can't say that with a high level of certainty, but joining all the dots I can manage to find from here and other discussions, that seems to be the way things are pointing.
Has anyone whacked a/some GNSS receiver(s) to a spin table (centrifuge) to expose them to some artificial acceleration to gauge the behaviour? Has anyone here had access to a GPS simulator to gauge the effect heavy doppler rate change has on the signal processing?

TP

 

[jderimig]

John, can you provide anymore specifics or reasoning on that? Is this assuming a UBLOX M9N? I recall last year you mentioned the acceleration limitations can be improved with using satellites on the oblique (non overhead) to reduce the doppler freq change rate the module has to deal with - so is it safe to assume a better antenna opens out a wider angle of available sats? Also, with a "proper" antenna, are we looking for better gain or better filtering or both?

TP

The reasoning was based on an actual flight this summer.

You need many many satellites in lock on the pad. I had 28 or so, multi-constellation receiver. You got to be able to get good reception with a good quiet hemispherical quiet antenna which is impedance matched to your board then to the chip. You need an extremely quiet PS and other electronics that are not throwing hash near L1 that is going to degrade your S/N. Off the shelf plug and play may not work all the time. This is a system.

When you launch the high acceleration and doppler shift means you are going to lose lock on the most of the satellites you are accelerating towards. But you will be able to still maintain lock on the ones low near the horizon or above. You will need alot to start with and good system S/N is required. On my flight I went from 28 to about 5 or 6 at burnout. Altitude accuracy suffered but I had lock all the way.

 

[rocket_troy]

Very interesting John. Did you capture all the GNSS data or enough to post process to determine the position of the satellites that remained in lock? ie. were/are you able to verify the ones that stayed in lock were low or close to the horizon? This feedback/advice is priceless - thanks!

TP

 

[jderimig]

Very interesting John. Did you capture all the GNSS data or enough to post process to determine the position of the satellites that remained in lock? ie. were/are you able to verify the ones that stayed in lock were low or close to the horizon? This feedback/advice is priceless - thanks!

TP

I still have the log file but I haven't done the analysis you suggested, which is a good one. Often I forget the step to analyze the data to figure out why something worked.... ;-).

 

[plugger]

Very interesting John. Did you capture all the GNSS data or enough to post process to determine the position of the satellites that remained in lock? ie. were/are you able to verify the ones that stayed in lock were low or close to the horizon? This feedback/advice is priceless - thanks!

TP

Hey Troy, not sure how much it'll help but this post got me to dig up my TeleGPS eeprom file from my MD L flight at the last Thunda and export it to CSV. You can see the results below. I took the liberty of deleting columns and rows that weren't very valuable imo.



As you can see I went from 13 to 4 satellites during boost and it took ~10 seconds from liftoff to get near the same number of satellites locked as I did on the pad. Also, you can see that I lost lock for 5 seconds during boost which also coincides with the big swing in DOP. Speaking of which, I'm not sure what to make of the DOP figures, but I'm sure someone more versed in this stuff could explain it.

This was all off a uBlox 7 chipset (Max 7Q) from a TeleGPS v1.0 board. And here's the Raven summary from the same flight.



Given the 'on paper' characteristics of the uBlox 9 chipset I'm really looking forward to having it ride along in a really aggressive flight. Back of the envelope math seems to indicate those chips have enough internal space to log ~36 hours of position data at a 1 Hz interval.

drew

 

[rocket_troy]

Drew, that's also very interesting and quite helpful. That's one heck of an aggressive fight profile! Very interesting that you maintained lock with 4 sats through the eyeball-pulling phase. You don't by any chance have the NMEA GPGSV data for that flight? That would be really interesting to see what satellites held lock. Any special antenna used?

Thanks,

TP

 

[plugger]

Drew, that's also very interesting and quite helpful. That's one heck of an aggressive fight profile! Very interesting that you maintained lock with 4 sats through the eyeball-pulling phase. You don't by any chance have the NMEA GPGSV data for that flight? That would be really interesting to see what satellites held lock. Any special antenna used?

Thanks Troy. And no, I don't have the NMEA GPGSV data, AltOS only allows for export to csv or kml. It might be buried in the eeprom file somewhere but all the data is in Hex and I've not attempted to decode it. I'll throw it into CyberChef and see if I can get anything useful out of it when I get the chance.

As for antennas, it was a stock TeleGPS v1.0, so the standard patch antenna for GPS and a 1/4 wave whip for down link.

 

[rocket_troy]

Very useful info nevertheless. Cheers Drew.

TP