In this other post, I wrote I intended to use the interrupt based NewSoftSerial llibrary for Arduino. Many of us know that the standard SoftSerial library comming with Arduino is not usable as is. Some tried out interrupt based serial to gain an additional serial IO on ArduPilot, but there are negative feedback about usability. As usual, I wanted to discover by myself!My intention was similar and is determined by my airframe setup. As the diagram shows, I load two ArduPilot boards into my plane, one (apA) as autopilot and the second (apB) for some additional tasks. One such task is parsing NMEA GPS sentences to my video OSD, an Inspire OSD, which requests 4 different NMEA sentences to fully exploit all its functions (GPGGA, GPRMC, GPRTE, and GPRMB). With the route information, the OSD can show distance and direction to next waypoint (left/right arrow and associated angle). This OSD was specifically made to be linked to the Garmin Geko handheld GPS which spits the necessary NMEA sentences out of the box. An EM-406 can also be used as is, but then, there is no waypoint functionality available.I use a LS20031 GPS running at 57600bds, spitting two NMEA sentences necessary for ArduPilot (GGA and RMC). It is connected to ArduPilot board apA and this direct connection is utterly important for autopilot navigation. So how to share the GPS running at 57600 with the OSD reading "only" at 38400bds?My goal is to connect my GPS to apA AND to my second ArduPilot board (apB). apB will read the GPS at 57600 and write GGA and RMC sentences as is to the OSD at 38400. For this function, apB is just a bauds rate adapter. Additionally, apB will also use processed data received from apA (next waypoint, etc) to assemble/emulate RMB and RTE NMEA sentences which will also be sent to the OSD.For developing and testing purpose, I replaced the apB with my Duemilanove Arduino board. For a start, I connected the GPS data output to Arduino. I set up a new sketch instantiating two software serial IO ports:- gpsRx(12, 98): Rx on pin 12 et Tx on non-existing pin 98, used only to receive from GPS; speed 57600bds;- osdTx(99, 13): Rx on non-existing pin 99 and Tx on pin 13, used only to send to OSD; speed 38400bds.I replaced the OSD with my FTDI breackout board to monitor the result on the laptop. For the sake of educating myself, I also implemented an 2x16 characters backlit LCD I wanted to try out (it is displaying the number of GPS readings; not useful but nice to make work for a first time).After many trials and error, I managed to get a decent result in the output. I'll write more on my experimenting later. For now, here's just an illustration of the test setup.Added 2009_05_02:After more evening work, I made some progress. My current setting is:- ArduPilot A board: autopilot functions, ArduPilot ver. 1 code, reading GPS uart serial input at 38400 at 2Hz, parsing fix_position, current destination waypoint, waypoint distance and bearing all together in a special NMEA-like format ($APDAT, 1, 1, 1324, 244*) to uart serial out at 2Hz.- ArduPilot B board: other functions, custom code, reading GPS over uart serial input at 38400 at 2Hz, reading ArduPilot A $APDAT sentences over NewSoftSerial input at 38400 at 2Hz, parsing GPS NMEA sentences (GGA, RMC) to video on screen display at 38400 uart serial out at 2Hz, adding an emulated waypoint navigation sentence ($GPRMB) with the data received from ArduPilot A, together with the GPS sentences to OSD.- Inspire OSD- XbeeCurrently, I am adding the reading of Xbee 868 headtracking data over NewSoftSerial at 38400, which is not so easy. the decoding code works as a stand alone, but not yet integrated as I want it in my ArduPilot B code. The difficulty is to have the Xbee headtracker data read as they arrive (ie only when updates are necessary to respect limited duty cycle of xbee 868) while reading other data from GPS or navigation ArduPilot which are sent at 2Hz frequency. In fact, when implementing NewSoftSerial, one has to take care of doing a full reading and buffering of data on one soft serial input before being able to read and buffer another data stream on a second soft serial input. Whenever you call a begin on a NewSoftSerial input instance, it flushes the buffer of the other instance. Being able to do that tricky back and forth from one input to the other without loosing data is not easy, but not impossible.I try to keep the loop free for new headtracker data for as long as possible within a 500 millisecond cycle. But in that cycle, a full reading (and processing) of the 2 GPS NMEA sentences and of the short APDAT sentence must be achieved too.For now, I continue tweaking to see where the different function calls are to be placed best to achieve a smooth cycle with all necessary tasks done. It's a bit of a struggle with trial and error, with a lot and a lot of code uploading to see if it behaves better or not (or if it behaves at all!).I hope to reach a solution in the coming days, because my iron-on shrink cover for my Kadet arrived a few days ago and I'd like to cover that plane now. My UAV will receive a nice color scheme with metallic dark red, some transparent dark red, some clear, some light grey, some metallic anthracit grey, some cub yellow and finally some chrome strips! Or maybe some less...IN PROGRESS
I've been testing my Locosys LS20031+ ArduPilot V1 at 38,400 baud. I noticed in Realterm several days ago that the actual data stream of characters is only 1140 characters/ sec, (see following screen cap) which would be ~12,000 baud. I'm wondering if there is any benefit with a serial baud rate faster than maybe 28,800?
Reto: Absolutely! Really delighted and impressed with your work on software serial here. We'll be supporting basic ArduPilot for years, thanks to smart software upgrades like this.
@Chris: yes I know about the mega and added serials. But you know, in the meantime, I think it is quite interesting exploring for a solution that could be useful for continue using the "old" 168 and 326 ArduPilot boards (I've just ordered the less older from Sparkfun 10 minutes ago with some other stuff!).
By the way, buying electronics is easier to conceal from one's wife than big model plane kits =(¦-}) ...
I did not test with the ArduPilot, but only with Arduino Duemilanove for now.
The parsing update rate is 2Hz at 38400 for the GPS spitting at 2Hz at 57600 bds. So there's almost no latency at all. I do not do checksum because the OSD is doing at reception. And there's no data extraction from the NMEA sentences, so it's fast.
I suspect I'll have to restart my tweaking of the NewSoftSerial library when I'm going to transpose this on ArduPilot (I empirically searched for the best parameters for 38400 for my test setup). I noticed that each board probably has it's own optimal library settings. For example, good results obtained when Arduino is powered through USB are completely lost when the board is powered with a 9V battery! I wonder if slight clock rate variations with to different power sources could be the cause of these differences.
@ hilitron: you say the MAX3100 SPI-UART is a "relative simple method". Could you explain how simple this would be for an elevtronic newbie? Thanks much for any information abut such implemenation, maybe it could be a better way with results that are more predictable?
That's very similar setup as I got on RC toy car. What's the update rate you are getting after parsing in Arduino board (apB)?
(I am running defaults GPS at 4800 boud (soft serial) and "main" serial at 9600, and am able to obtain GPS from "main" serial at about 1 sec or slightly worse, which is fine for toy rc car. I am only looking at RMC data (although RMC + GGA produces just about same rate..)
Comments
I've been testing my Locosys LS20031+ ArduPilot V1 at 38,400 baud. I noticed in Realterm several days ago that the actual data stream of characters is only 1140 characters/ sec, (see following screen cap) which would be ~12,000 baud. I'm wondering if there is any benefit with a serial baud rate faster than maybe 28,800?
ooo so true :))))))
By the way, buying electronics is easier to conceal from one's wife than big model plane kits =(¦-}) ...
The parsing update rate is 2Hz at 38400 for the GPS spitting at 2Hz at 57600 bds. So there's almost no latency at all. I do not do checksum because the OSD is doing at reception. And there's no data extraction from the NMEA sentences, so it's fast.
I suspect I'll have to restart my tweaking of the NewSoftSerial library when I'm going to transpose this on ArduPilot (I empirically searched for the best parameters for 38400 for my test setup). I noticed that each board probably has it's own optimal library settings. For example, good results obtained when Arduino is powered through USB are completely lost when the board is powered with a 9V battery! I wonder if slight clock rate variations with to different power sources could be the cause of these differences.
@ hilitron: you say the MAX3100 SPI-UART is a "relative simple method". Could you explain how simple this would be for an elevtronic newbie? Thanks much for any information abut such implemenation, maybe it could be a better way with results that are more predictable?
(I am running defaults GPS at 4800 boud (soft serial) and "main" serial at 9600, and am able to obtain GPS from "main" serial at about 1 sec or slightly worse, which is fine for toy rc car. I am only looking at RMC data (although RMC + GGA produces just about same rate..)
By the way, there is a relatively simple method to add a "real" additional UART to the Ardu: connecting a MAX3100 SPI-UART http://pdfserv.maxim-ic.com/en/ds/MAX3100.pdf
Erwin