Thanks for the clarification.
I knew, that the IMU latency also plays a big role to time the fusion correctly.
What I was just confused about was the statement that it would take the F9P 10ms to calculate a Fix, wich is just not true as I’ve shown.
I saw @CommonRail’s pole swinging experiment and I agree to use whatever timing value works best in the field. One thing I noticed altough was, that the fix calculation time can vary quite a bit depending on how many sats you’re using and wether RTK is enabled or not.
So for most users, Tony’s findings should apply very well but in some use cases it might make sense to take the timepulse into account. E.g. if we know the IMU reading is about 25ms too late, take the reading 75ms after the timepulse and make the PANDA sentence when receiving GGA.
Just a suggestion, I guess not the highest priority as it seems to work well for most.
Time pulse is for syncing devices very accurately as it represents the receivers internal clock which is, as you said, synced to the satellites clocks.
NMEA /UBX, etc. will always have a delay to the timpulse that might not always be the same. This is because it takes the receiver time to calculate the position, make the sentences, etc. And this time can vary depening on sats in view, etc.
From how I understand you, you’re making the assumption that the transmission of a NMEA sentece starts right after the actual point in time the satellite data is taken (which is when the timepulse happens). And this is not true as I’ve shown above.
Using NMEA for a time server can work, but it surely won’t be as accurate as using timepulse.
Thank you for the clarification, you guys are awesome.
Why not use SPI which is epically faster?
I have an antique Trimble that has time pulse
Trying hard not to build the same unit.
You think using a time pulse to get a perfect timing is somehow antiquated? Strange. If the time pulse triggered and interrupt, and then the handler set a one-shot timer for a certain delay (to trigger reading the IMU in advance of the next cycle) which would also fire an interrupt, that would seem to be pretty darn advanced to me. And it would be dead on every time.
General question… Brian and other posts recently talked about abandoning the gyro integrated mode on the BNO085 and using RVC? Has there been any code to implement that? I can’t seem to find the PANDA code anymore.
The new rvc code is in its own version, with the ads delete, using the teensys onboard adc directly. It does not work with any previous boards 
. I will send you a link on the telegram when get to a real computer.
Is the time pulse only on a separate pin or can it be accessed some other way?
It’s a pin. Most breakout boards bring it out. On the Ardusimple RTK, it’s brought out to a a plated hole, but it’s not tied into one of the Arduino pins.
Whether it’s actually useful or not I don’t know! Panda does work as it is now.
The time pulse occurs as the data begins to send?
No, see Tom’s post above with the diagram. It marks the time at which the fix calculation begins. In my mind this means it marks the point at which the GPS satellites were actually observed, ideally you’d want to get an IMU reading at the same time, but the IMU has its own latency still.
At least it would get the two closer to being in sync.
I think so? Also it makes the timing independent of any NMEA parsing. Parsing NMEA time is pretty consistent, but if you change the baud rate that can change the time it takes to parse the GGA. And if you drive an interrupt handler with this signal, then theoretically the IMU timing and reading can be completely on its own and in the background as it were. Dunno.
Since we take the imu reading before the next GGA with Panda its pretty easy to get close.
Once GGA is read it triggers the timer for next imu reading.
Then the imu and gga are put together by the teensy to make PANDA.
The biggest delays in the system are reading and sending on the uarts.
But any change in position fix processing time due to firmware changes, message output configuration, baud rates, constellations, RTK etc will create some variation. Shouldn’t the pulse output be consistent regardless of the above mentioned variations? That being said, it sounds like there’s some fudge factor due to the cheap (?) IMU that adds some leeway.
Yes that’s my feeling too.
However I guess one reason to keep it as it is now is that not all the low-cost RTK boards that we could use with AOG implement the timepulse in the same way. For example, the Skytraq PX1122R has a pulse pin but it is once per second, not once per fix. With the current system, even though there’s variations that would have to be adjusted for, it works with any RTK system that provides GGA and VTG.
Interesting stuff either way.
But when designing the system adding in stacked communication delays by running everything at idle speeds seems silly. By just increasing com speed to max on existing hardware you have about 1ms of added delay from GGA sent to PANDA fully sent.
Running uarts at slow speeds are like buying a Ferrari, but then being behind it the whole time pushing.
Its having the speed but, just waiting on data to wait on data.
As I mentioned above, surely running the IMU through a faster interface would help here?
Less overall delay is great, but that’s a separate issue from running the IMU with position fixes.
RVC mode I think will help a lot, no request needed, one way data stream, much less data to parse.