Replies to This Discussion

Permalink Reply by Michal B on January 18, 2009 at 10:21am

There's one significant problem with forwarding GPS data back to serial out. And this is speed.

I profiled the GPS parser code (measured time spent in the function), and it is very fast: 2-3 milliseconds when actual NMEA sentence is parsed, and 0 when no data are available. This is thanks to Serial IN being processed by interrupt and buffered. However, this is not the case when sending to Serial OUT, CPU stalls while data are being sent. Since Serial port works on 4800 baud speed (default speed of GPS device?), CPU can send ~480 bytes/second. Forwarding GPS data takes about 240ms each second (assuming 1Hz GPS device, expect CPU overkill for 5Hz GPS). Quite enough time consumption which should be used for actual flight code.
So regarding GPS data used by 2 devices, some other way should be chosen.

@Chris: seeing the nice speed of NMEA parser, I think there's no need for GPS binary mode parser, what do you think?

• ▶ Reply

Permalink Reply by Reto on January 19, 2009 at 2:35am

Thanks for those profile tests, Michael B.
I see there's a problem with CPU sending speed to serial OUT. Since the goal is to just to feed NMEA sentences to the OSD so the pilot remains at least approximately informed about current GPS route, wouldn't it be a solution to decrease the parsing frequency of ArduPilot, let's say to 0.5 Hz or any minimal frequency? Diluting the parsing over time would probably leave enough com out capacity to the CPU to execute its flight code safely.
I am currently listing what NMEA sequences and information from the LS20031 GPS chip are necessary to build up the Garmin Geko emulator sequences to feed the OSD serial IN.
I hope there is some way to get that parsing done from the ArduPilot serial OUT.

• ▶ Reply

Permalink Reply by Reto on January 19, 2009 at 2:54am

Here's a short paper about a state machine NMEA parser. It's probably not of interest for many of you, but maybe for other newbies like me:
NMEA Parser Design, by Monte Variakojis, 2002

• ▶ Reply

Permalink Reply by Michal B on January 19, 2009 at 3:30am

There're more possibilities:
1) Increase serial port baud speed (but I don't know if we can configure EM406 device).
2) Send out just some NMEA sentences, and not very often (e.g. one update every 4 seconds).
3) Redesign Serial Out to be buffered and sent asynchronously (I trust is could be possible). Then sending would not halt CPU. Code would output NMEA sentence when previous one was fully sent, or when there's enough space in out buffer.

• ▶ Reply

Permalink Reply by Reto on January 19, 2009 at 4:14am

The LS20031 GPS chip I intend to implement is configured for sending 9600 bps by default.
Your other options are ways to investigate, but I feel 1 update every 4 seconds is in the lowest range of what I'd expected. A solution mixing your points 1) and 3) is most appealing to my mind.

• ▶ Reply

Permalink Reply by Reto on January 28, 2009 at 5:18pm

Hi Michal. You said one possibility would be to increase baud speed. The LS20031 GPS chip (which arrived today, by the way, actually replacing my GPS emulator) tranfers at 57600 baud. Would this help solve the problem together with a buffered output to the OSD board? Another question is: do you know at which rate ArduPilot is reading the NMEA sentences?

• ▶ Reply

Permalink Reply by Michal B on January 29, 2009 at 1:08am

Hi Redo,
actually reading NMEA sentences doesn't have "rate", it reads everything that is available at serial port. It's called in main loop, and when there're new data on serial, it consumes them.

I also posted this tutorial how to configure EM406 for higher baudrate.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on January 19, 2009 at 9:21am

@Michal: (RE: choosing not to use the binary mode) Yes, that was our thinking. The binary mode parser only works with specific GPS modules, which makes the code non-portable. It's only other advantage is slightly smaller code size, which wasn't important enough for us to keep it. We like our NMEA parser ;-)

• ▶ Reply

Permalink Reply by Reto on February 2, 2009 at 1:37pm

I have a question concerning the serial OUT of ArduPilot. Is it a "real" serial level or a TTL signal.
I ask because to feed the Inspire OSD serial in I need RS-232 level. So if ArduPilot serial OUT is TTL, I need to convert signal level (DIY converter with MAX232 IC from Maxim and 4 x 100nF (0.1uF) capacitors as described here.
I noticed this when I tried to connect RS-232 serial of Inspire OSD to my FTDI TTL breakout... (FTDI survived).
If anybody has any information about ArduPilot serial OUT levels, I'll be glad to get them. Thanks.

• ▶ Reply

Permalink Reply by Reto on February 9, 2009 at 3:33pm

A week ago or so, I inquired if serial Out of ArduPilot is at TTL level (or regular RS-232 level).
Since nobody answered, I suspect it is a too basic question to ask and I suspect the answer is TTL.
Unfortunately, I cannot check it out on the board itself, since it is still traveling! But in the meantime, I could prepare eventual RS232-TTL conversion if needed (though I hope not).
Thanks if someone could confirm what I suspect.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on February 9, 2009 at 5:25pm

It's TTL level

• ▶ Reply

Permalink Reply by Reto on February 9, 2009 at 11:24pm

Thanks for this Chris. That makes it easier then.

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page