PANDA doesn’t play a role with that. Your radio connection to the base station remains connected to the RX2 pin. The TX of the SkyTraq sends GGA and VTG to the Teensy, just like an F9P would.
so I just need to receive the signal correction from RX2 by the lora radio.
Thank you guys.
1 Like
The rover radio receiver, get a rtk signal from base, and send it to rxd2 on rover px1125
You should search for skytraq px1122 specifications.
It is almost the same except for the antenna connections.
Is anyone driving with an Ardufruit BNO055 IMU? is this working for Panda or only a BNO08x
1 Like
Now I get it. is that it is the first time that I assemble an RTK system. So I don’t really know how it works. That’s why I chose to buy the ESPRTK license and make the board. Here in Brazil we don’t have a 4G signal in the whole area, so I need an OFFLINE network.
This way I configure it through the web, and send the data through the lora network to the ROVER.
look:
Maybe look into this thread from post 55 and down.
1 Like
I’m working on setting up Panda with V 5.6.16.
From everything above seems to be the go to?
There are 2 config files BasicDualPosition and BasicDualHeading. Which one for single f9 and BNO085?
Hello everyone,
I read here that it takes the F9P about 10ms to calculate a fix. Where is that number from?
I measured the time between the F9P Timepulse rising and the reception of the ‘\n’ character when only GGA output is enabled at 115200 baud (Firmware 1.32). It turns out to be about 70ms with RTK fix and GPS+GLO+GAL+BeiDou enabled. I measured this with an Arduino as well as using a logic analyzer. Disabling BeiDou or RTK or using a higher baudrate does make it a little faster, however nowhere nearly to around 10ms.
This is what the logic analyzer data looks like:
Where D0 is the timepulse set to 10Hz and 10% duty cycle and D1 is the TX line from the F9P.
This raises the question if we should adjust the timing of getting IMU data? Or is my F9P just very slow?
10ms is the time to transmit the whole messages at 115000. It’s 3ms at 460000.
Does it show that in your graphic from -10 to 0?
I don’t know how the timepulse pin work or waths F9P fix calculation time.
As far as I know this has never been discussed. The IMU/GPS timming is based on the messages.
If this 70ms is true, we could reconsider how timing should be done.
The reason for the change to 460800, is you have data coming every 10ms that takes roughly 10ms to transfer at the slower baud rate.
Speeding up ensures that no stale data is ever being used from the buffer. There is guaranteed time with no data between nmea messages.
Did you fund some data about the timepulse?
It’s probably have to trigger a little time before the fix to account for the delay if used to synchronize with cameras.
The timestamps are a bit misleading, I’m sorry and the one on the falling edge of the timepulse is just wrong but yes, the -10 to 0 is what it takes to transmit a GGA sentence at 115200.
This from the ZED-F9P Integration manual Page 65:
This means it takes around 50-60ms (depending on number of sats, RTK, etc.) to calculate the fix plus 3-10 ms (depending on baudrate) for transferring.
1 Like
At 10Hz we’re talking about 100ms between fixes. So there should not be any problem with that if we’re only transmitting GGA and maybe VTG.
But I agree that, as long as it works, faster is always better.
So if I read that right, PANDA really should be catching that timepulse signal on an interrupt and read the IMU which will correspond to the fix? Or maybe the bit of latency between the pulse and the IMU read transaction is still too much. At the very least the PANDA sketch could use an interrupt to time delay between the fix and the data coming over the serial to calculate how far in advance to read the IMU.
2 Likes
Yes faster is better, for single I run at the max board speed for the f9p 921600 without issue. The time difference between GGA being sent over UDP and PANDA being created is 0.001s. That is pretty cool for how much info is getting copied and crammed together every message.
1 Like
Well even then there is the reality to get data from imu in a timely fashion. One of the “limitations” of the imu is the ridiculously complex protocol structure and amount of data that must be transferred to get a reading when you want.
If you set the imu to read for example at 100 HZ, you must also read the thing via the painfully slow I2C and remove all data backlogged in the message stream being sent. This is a problem for a time sensitive mcu program. The teensy is fast yes, but everything around it moves very slow like serial, udp and especially I2C. Reading the ADS1115 takes time. I had written a method that restarted the sample clock every time gga was received and 80 msec a new sample arrived and it was read. I thought it worked really well, but wasn’t used. Current version runs at 50 hz and keeps reading the sample and when time is up uses that reading. Trouble is it could be ±20 msec from when it should due to independent timing.
There is a mode in the BNO085 called uart-rvc that is used in those little vacs like the Rhoomba. It spits out Roll, Pitch, Yaw every 100msec out a serial port continuously. So every 10 msec you get new data. when you want the imu reading, you just grab it from the values that are being updated every 10 msec via the bno serial port. Pretty simple.
The CMPS is even worse for problems. It only reads every 50 msec and even then the reading via I2C takes time as well so could be waaaay out. The CMPS is the imu talking to another controller doing that ridiculous protocol in the background that then sends the “result” eventually via I2C to the user. I have made a prototype board that uses the serial mode of the BNO, a special library that does 16x oversampled 12 bit A/D directly with the teensy. This results in no use of the glacially slow i2c at all on the board.
Tony has done a lot of swing the antenna on a pole and the result is that at about 90 msec before the fix arrives is a good time to grab the imu and fuse that together. Since it could be 20 to 30 msec late of the actual reading, it does coincide with your timing @Tom_S findings - something i have long thought, that it takes a long time to actually calculate a fix.
@torriem using the interrupt would work, but then you need some fancy footwork coding to process all the messages fast enough while having the imu generate data fast enough to achieve any sort of stable timing. Or just use the serial mode. I2C makes a request to the device which depending on its schedule begins to send data back 1 or even 2 msec later which in Teensy time is a lifetime of waiting as all I2C blocks the processor from doing anything else. Which is why the serial is pretty effective at eliminating most of the problems to within 10 msec for new data.
Don’t know if this helps the discussion or not, but is more information.
1 Like
At the very least if the IMU reading is timed from the pulse, rather than from when the GGA is parsed, that would allow consistent timing no matter what the baud rate is. I think I’ll explore that a bit.
Well the parsed GGA is very consistent and also easy to set a delay for the next arrival of the fix to align with the imu reading. The timing is consistent within microseconds - the timing of the imu however is sometime give or take10 msec. With the pole test swinging the antenna back and forth is probably the only sure fire way to align the imu with the fix arrival.
But fully open to new ideas.
Sure but if the baud rate is changed the timing of the gga parse also changes. Not that panda needs the baud rate to be higher than it is.
Time pulse was created as a sync for old poor slow comms between multiple devices. Or devices like a camera that could not decode nmea
Time servers for computers reading gps do not even use time pulse they just read GGA, or the special time message ZDA directly.
Over UDP the variance of Panda after GGA @921600 is 0.001s. GGA is hard to find meaningful variance, its always synced to the atomic clocks on the satellites.