I wondered if it might make sense to support both text (as it does now) and a "raw" TX method for the ArduPilot. With the "raw" mode you could save a few (possibly a lot as a %) bytes per transmission which could mean a faster rate of messages and less work for the chip to do (even if Serial TX is handled in the background).

Tags: serial

Views: 15

Reply to This

Replies to This Discussion

You mean data telemetry for the groundstation?
I do
It's not clear to me that you'd get any performance improvement. The serial TX is handled by the hardware (UART) and we're well below the Xbee transmission capacity. It's also just not that much data--approx 1/5h as much as is coming in on the Rx side from the GPS.

I generally fall into the "if it ain't broke don't fix it" camp, and unless we can see some bottlenecking on the Tx side I wouldn't want to establish a new data standard and have to write new parsers for the onboard and ground sides.
It only sprang to mind when I read a comment somewhere here within the community (I can't find it for love nor money now) that they'd experienced better performance by disabling the serial output.

From a quick look at the atmega datasheets I think that the transmission of each byte is done in the background by the USART system but that the buffer for USART transmission is just one byte. As soon as it empties this buffer the USART system triggers an interrupt which is caught by the arduino Serial library and submits the next byte into the buffer for transmission. It's could well be the case that the time the Serial library interrupt work takes up (it's just a few ops here and there) is negligible though it could all add up.

RSS

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The third round was a reliablilty/aerial photography round for both planes and copters, which is now closed. Stay tuned for the next round, beginning soon.

A list of all T3 contests is here

 

© 2012   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service