|
|
| Author |
Message |
GTBecker
Joined: 18 Jan 2006
Posts: 457
Location: Cape Coral
|
|
Posted: 28 January 2009, 5:00 AM Post subject: NMEA mux/combiner? |
|
|
Has anyone done an NMEA multiplexer/combiner that they can discuss?
I need to merge three NMEA sentence streams. Each is 4800 baud, maybe 10 roughly-60-byte sentences, like from a GPS, typically in groups every two seconds, merged into a single 4800-baud output.
There is normally enough time between groups of sentences from each source to merge them but there might be the occasion where a sentence will need to be discarded for lack of sufficient output time.
A four-input commercial device is available for $169 so it can't be much of a project to compete with that - but, on the surface, it seems pretty easy. Any suggestions?
Tom |
|
| Back to top |
|
 |
stevech
Joined: 23 Feb 2006
Posts: 657
|
|
Posted: 28 January 2009, 7:02 AM Post subject: |
|
|
| just four RS232 or equiv. discretes to convert to logic levels. Software UARTs and input buffering code. |
|
| Back to top |
|
 |
GTBecker
Joined: 18 Jan 2006
Posts: 457
Location: Cape Coral
|
|
Posted: 28 January 2009, 12:43 PM Post subject: |
|
|
After sleeping on it, it is a little more involved.
Some sentences cannot be sacrificed - an MOB position waypoint is vital data, for example, as is a DSC distress call position waypoint - and routes, a series of waypoints, need to be complete. Maybe all waypoints need to take priority over periodic data. A prioritized selection process seems necessary when output bandwidth is short.
I've found that some radio tuning data is binary, not in NMEA form, but is conveyed over the NMEA path, so those packets need to be kept intact.
Then I started thinking about handy perks, like automatic GPS switching if one fails. |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
|
|
Posted: 28 January 2009, 14:53 PM Post subject: |
|
|
4 simultaneous serial communications implies 4 tasks. You can reduce the burden by using 2 hardware UARTs and 2 software USARTs e.g. choose a device like the ZX-24ne which provides accessibility to COM1 and COM2. You could use a ZX-1280n that has 4 UARTs but I think that is unnecessary. A ZVM device will probably work but native will be faster and leave more time for input processing.
Correct buffering is important as Steve says but it is also important to avoid using strings and manage everything as byte arrays.
My experience in this area is taking a customer's application that didn't work and couldn't keep up with 2 software serial ports and rewrite it to use tasks, byte array manipulation of buffers and eliminate string processing. |
|
| Back to top |
|
 |
|