Is the Uart limitation of 115200 truly hardware on the M2, or can some higher speeds be added?
Ive been running GGA and VTG at max speed 921600 on some comparable test hardware, and have found clearing the data much faster has many benefits. Especially if numbers need to get processed afterwords like on a drone or machine. Also makes the rtcm3 be usable faster to the gps.
Even being able to go to 460800 drops the GGA transmit time 7.5ms to 2.5ms, compared to the 10ms transmit time of 115200.
921600 drops GGA transmit time to 1ms. The more NMEA messages you need the better going faster is.
The baud rates up to 115200 give accurate results, and they are just enough for many applications. So, it’d be great if you can share more details on how the higher rates would help you. How do you work with the NMEA stream in real-time and post-process the data?
The GGA and VTG data are being sent to a Teensy4.1 micro controller. The main task of the controller is to sync the imu reading of a Bno085 with the GGA and VTG information into one message. When sent the new message greatly improves the stability of the moving platform.
The issue is delay, the less delay between the gps fix and the imu data the more stable the control over rough ground. This effect should also work for drones in flight.
You have to wait for the GGA to finish to trigger the imu reading, longer wait times reduces the stability of the data noticeably.
Here is a video of AgOpenGPS $PANDA imu synchronization in action
Currently I can use the M2 with ethernet to TTL adapter with this system, but its slow and does not perform as well.
The trimble with native ethernet 100mbps, and Spark fun board at 921600 work much better for rover due to less lag. <=1ms including processor time.
Hi, your machins are getting heavily advanced Mr
The gnss or its output is not the issue here, its the software or controller that fuses GNSS/IMU into a 3D oriented position in space. I`m not sure how capable Teensy is but the way things work (at least with drones and precision instruments) is to rely more on the IMU and dead reckoning method.
In another way you could have gnss postion every 5 second and the IMU would compute the rest just fine. the Bno085 is good for 100Hz and should keep the orientation for at least 5 second with good enough accuracy.
I would start looking into the software and what kind of option there is.
What program are you runing?
I think the M2 will have to stay in a slower support role of base position.
There is a reason even commercial machine control currently all run at a base rate of 10hz, Even a slow moving tractor is moving too fast for 5hz and you end up with wavy steering control. With faster equipment like sprayers 20km/h 5hz really had obviously poor control. Even at 10km/h every 10ms of delay puts your measurement off by 2.78cm (2.78m/s *100cm/m / 1000ms/s *10ms = 2.78cm), to clear a 82 character GGA message at 9600 would delay you 85ms from gps uart to final read at the processing devices uart, so you have travelled unknowingly 24cm into the neighbours fence at 10km/h. 9600 really throws a wrench into things, if you add VTG it takes longer to transmit the data, than the time you have to available transmit the data at 10hz. Going fast with data has nothing but benefits.
Ive tried multiple Bno IMU already, but you do not gain much. Bno085 is really the leader currently in affordable IMU technology its very stable on its own.
Much like the internet speeds moving to 1GBps, because of the obvious benefits. 9600bps is almost like printing off sheets of paper and entering it by hand at the next device, meanwhile what you wanted to measure has passed you by a long time ago.
Increasing NMEA speed has very tangible control benefits, data cannot begin to be processed until its transferred.
RTK with external imu.
Well, there is a major difference in your setup and the commercial ones. I reckon they have the imu built in or hard wired to the core, (like the built in imu M2 has). This way it process the raw data from both gnss and imu at a much higher rate taking into account psudorange and tightly coupled integration strategy.
When both raw data from imu and gnss is processed like this, then yes, faster rate is better and more accurate for moving estimates.
With external imu and rtk solution from serial, it can not utilize and process fast raw data from either components. Even though a solution can be output at 5/10 or 14 hz, it has already been introduces with several delays, we are talking many ms. With moving objects you are computing a position based on many milliseconds old data and trying to fuse this with an imu with ditto data, you`re in for a real mess. Faster gnss would just chock the system and do no good. Its better of to rely more on the imu as it also computes the attitude when dealing with external imu and FIXed solutions.
This is also somewhat why they dont do RTK mapping. With PPK you process all raw data with higher accuracy and resolution.
Are you certain that the transmission speed is the issue here? At 115200 baud a 140 byte message can be transmitted in 10 ms which would be just enough for a rate of 100 Hz.
The GPS won’t give you a precise position at 100 Hz though (unless we are talking about much more expensive setups). So at these data rates you have to perform dead reckoning anyway and that would cut the theoretical offset of a few centimeters down to millimeters.
I’ve looked into your question with our devs. Supporting higher baud rates is a complicated task that depends on both the software and hardware abilities of the unit. So, we can hardly do it in a short time. Still, we’ll research the options further. If there’s any news about it, we’ll let you know.