Homemade NMEA multiplexer

AngusMcDoon

Well-Known Member
Joined
20 Oct 2004
Messages
9,045
Location
Up some Hebridean loch
Visit site
Dark winter's evenings in my tent, so faffing around with electronics for cheap entertainment again. And the latest is an NMEA multiplexer (combine two NMEA signals from separate sources on separate wires onto 1) for not a lot of wonga. Here's the prototype...

piccy.jpg


...still on a development board, but fully working. Next step will be to make it up on a Veroboard and stick it in a box.

Total cost of components - £4.62.

Uses a PIC 16F88 and a MAX232 line driver and a few other odds and sods. That PIC only has one USART, so knocked up another in software. All interrupt driven and sleeps when nothing to do, so minimal power consumption. Programmed in C using a freebie compiler.

Ho hum. Only another 4 months until the clocks change. Next project will be a Seatalk to NMEA converter for under a fiver.
 
Dark winter's evenings in my tent, so faffing around with electronics for cheap entertainment again. And the latest is an NMEA multiplexer (combine two NMEA signals from separate sources on separate wires onto 1) for not a lot of wonga. Here's the prototype...

piccy.jpg


...still on a development board, but fully working. Next step will be to make it up on a Veroboard and stick it in a box.

Total cost of components - £4.62.

Uses a PIC 16F88 and a MAX232 line driver and a few other odds and sods. That PIC only has one USART, so knocked up another in software. All interrupt driven and sleeps when nothing to do, so minimal power consumption. Programmed in C using a freebie compiler.

Ho hum. Only another 4 months until the clocks change. Next project will be a Seatalk to NMEA converter for under a fiver.
going boating this weekend?
its nice and warm in Llan so going for a day ride to winterise!
Stu
 
Nice! How many lines of code? How easy/difficult was it to debug?

About 260.

Not easy because I am too tight to buy an ICSP debugger. I can simulate to a certain extent in MPLAB, and on HW wiggle an LED or write out debug messages via the HW UART.

I want to try to get it to work in a PIC 16F628A because that will save 70p from the cost. Less data memory though. I am running at max speed (20MHz) with an external clock. If it still works slower at 4MHz than I can save another 36p on the oscillator and its caps. Then it will cost just over £3.50.
 
Last edited:
C whats C

Have a Pascal Compiler for Windows 95 . Can simulate working on 16f628 and 16f84 . I used to make a sailingtimer that had two clocks running so you got the 6 3 0 or the 5 4 1 0 start sequence repeating and a stop watch that went from the first trip to 0 . Used to sound the air horns etc . Sold some 40 odd to places as far as Alaska and Canada . One on the East Coast can be started by phoning its mobile number from a dingy at sea :D . Really enjoyed it . They changed the compiler when they realised that it worked ok on XP but you didn't need a licence ... :rolleyes:

Also have a copy of pc board design software that works out all the routes for data lines . You could change the board design and leave it running to sort it out . Last revision took my PC about 2.5 hours to work out the track design .

Brings back happy memories ..
 
Use a MAX233 - even smaller BOM

Which compiler? Presumably as you're muxing two 4800 bps streams you're output is at 9600 or higher. Does this work with most receiving kit?
 
Use a MAX233 - even smaller BOM

Which compiler? Presumably as you're muxing two 4800 bps streams you're output is at 9600 or higher. Does this work with most receiving kit?

The 233 is a lot more expensive than a 232+4 caps. Probably why most users seem to stick with the 232.

HI-TECH C® for PIC10/12/16.

My multiplexer is 4.8k in and 4.8k out. If there's too much coming in to send out everything, it drops excess messages, sharing the output bandwidth equally between the inputs.

I guess I could analyse the types of messages coming in to ensure that all message types get equal priority rather than each input channel getting equal feedthrough in the event of too much input.
 
Why use a 232 at all? NMEA is not RS232 level anyhow. So rather than saving 70p by changing to a less capable pic you could just skip the 232. If you want to save on the pic, you could just change the socket as DIL usually is the most expensive these days. You could also change to a MORE CAPABLE pic instead as they are cheaper (like the 16f886 if you are not tight on space).
 
Why use a 232 at all? NMEA is not RS232 level anyhow. So rather than saving 70p by changing to a less capable pic you could just skip the 232. If you want to save on the pic, you could just change the socket as DIL usually is the most expensive these days. You could also change to a MORE CAPABLE pic instead as they are cheaper (like the 16f886 if you are not tight on space).

Well in true tightwad manner, I didn't actually spend anything at all - I used what I found in the bottom of a box. The 16F886 is the same price as a 16F684A, but too many legs to fit on my dev board.

From the spec...

The NMEA-0180 and 0182 standards say that the talker output may
be RS-232...NMEA-0183 accepts this, but recommends that the talker output
comply with EIA-422...

So RS232 levels is allowed in the spec. The differential part is only a recommendation. How can I drive RS422 for less than 60p that the MAX232+caps cost?

My total cost reducing exercise is just a bit of theoretical fun. I'm not planning to start production.
 
You can drive rs422 directly from the pic. Most devices would work just fine with a ground and then you use one of the I/O-pins for data. If you want to inverse the current (instead of zero it), you need two I/O-pins, one data and one data-. There should be no problem with free pins (even with the f88).

How are you joining the NMEA data from the two ports? Are you storing sentences from each input and then sending them on the output, or are you TDMA-ing the output (giving each input a certain time frame to send its contents to the output)?
 
You can drive rs422 directly from the pic. Most devices would work just fine with a ground and then you use one of the I/O-pins for data. If you want to inverse the current (instead of zero it), you need two I/O-pins, one data and one data-. There should be no problem with free pins (even with the f88).

Driving from a PIC pin and ground is not NMEA though, as NMEA spec says EIA-232 or EIA-422. That's half and half. A PIC pin can be used for EIA-422 +, but as you say, I then need EIA-422 -, a voltage I don't have on my board, so extra components. Also this 2-pin data out wouldn't work with the HW UART of the PIC, so I'd need 2 SW UARTS.

How are you joining the NMEA data from the two ports? Are you storing sentences from each input and then sending them on the output, or are you TDMA-ing the output (giving each input a certain time frame to send its contents to the output)?

Buffering each input and then transferring to an output buffer. I have a whopping 368 bytes of RAM to play with. :D
 
Driving from a PIC pin and ground is not NMEA though, as NMEA spec says EIA-232 or EIA-422. That's half and half.
On the contrary. Driving it directly from a PIC is very NMEA/RS422. For RS422 the voltage is not very important, but they specify 5V. The PIC is easily driven from 5V, so you can use this to power the PIC and the PIC will also output this on the I/O-pins. If you want to conform to the RS422 you should use two I/O-pins on the PIC that complement (XOR) each other. This is much more NMEA than a max232. But it is not necessary, for most equipment using only 1 pin and ground is sufficient as the commonly used NMEA input is driven through an opto coupler which will be driving with the +5V pulse and will not drive when there is no voltage difference (with data+ and data- the opto couplier would get negative voltage over the LED part which would make no difference to 0V).

Also this 2-pin data out wouldn't work with the HW UART of the PIC, so I'd need 2 SW UARTS.
If you have one pin free (which should be no problem) you easily work around this by just feeding the Tx pin from the USART back to an interrupt-driven input pin and then just put an NOT value of this input pin on another pin.

386 bytes is a lot... My last project used a pic10f200 with 16 bytes of ram and program memory for 256 instructions.

But if you buffer each input, how are you handling if both channels output too much data to fit into 1 output?
 
Last edited:
On the contrary. Driving it directly from a PIC is very NMEA/RS422. For RS422 the voltage is not very important, but they specify 5V. The PIC is easily driven from 5V, so you can use this to power the PIC and the PIC will also output this on the I/O-pins. If you want to conform to the RS422 you should use two I/O-pins on the PIC that complement (XOR) each other. This is much more NMEA than a max232. But it is not necessary, for most equipment using only 1 pin and ground is sufficient as the commonly used NMEA input is driven through an opto coupler which will be driving with the +5V pulse and will not drive when there is no voltage difference (with data+ and data- the opto couplier would get negative voltage over the LED part which would make no difference to 0V).


If you have one pin free (which should be no problem) you easily work around this by just feeding the Tx pin from the USART back to an interrupt-driven input pin and then just put an NOT value of this input pin on another pin.

386 bytes is a lot... My last project used a pic10f200 with 16 bytes of ram and program memory for 256 instructions.

But if you buffer each input, how are you handling if both channels output too much data to fit into 1 output?


Can you explain the voltage levels on RS422 at mark and space levels, because I may have a misunderstanding? I thought they were both the same for one level, and went +/- for the other, hence needing a +/- voltage supply. Or is there always a voltage difference between the signal lines, but flips between mark and space?

I would like to understand RS422, but I'm leaving the MAX232 in, because it is compatible with the NMEA spec and also means I can feed the output into a computer as well. 60p well spent :)

Any excess data that cannot be sent is discarded. I should have some sort of algorithm to decide what to send and what to discard depending on what has recently been sent and discarded. Most NMEA sources (apart from GPS) that I've seen only send stuff out every now and then compared to the maximum throughput they could do, so there's usually time to multiplex everything.
 
Can you explain the voltage levels on RS422 at mark and space levels, because I may have a misunderstanding? I thought they were both the same for one level, and went +/- for the other, hence needing a +/- voltage supply. Or is there always a voltage difference between the signal lines, but flips between mark and space?
You have 2 data lines (I/O pins) and call one NMEA+ and the other NMEA-. For mark you set NMEA+ to +5V and NMEA- to 0V. For space you set NMEA+ to 0V and NMEA- to +5V (or vice versa, don't remember exactly and I am not at my computer with source code).

More simply put, if current flows in ONE direction, it is a mark and if it flows in the other direction, it is space.

Thus, it is a misunderstanding that you would need -5V. You accomplish the -5V by just "switching place" of ground and +5V.

This output works fine to input into most modern RS232 receivers as well as you just take one of the data lines and put it in relation to ground to make it RS232 (with +5V voltage level instead of +/-12V which is not necessary for 99% of the modern rs232 receivers).
 
Dark winter's evenings in my tent, so faffing around with electronics for cheap entertainment again. And the latest is an NMEA multiplexer (combine two NMEA signals from separate sources on separate wires onto 1) for not a lot of wonga. Here's the prototype...

piccy.jpg


...still on a development board, but fully working. Next step will be to make it up on a Veroboard and stick it in a box.

Total cost of components - £4.62.

Uses a PIC 16F88 and a MAX232 line driver and a few other odds and sods. That PIC only has one USART, so knocked up another in software. All interrupt driven and sleeps when nothing to do, so minimal power consumption. Programmed in C using a freebie compiler.

Ho hum. Only another 4 months until the clocks change. Next project will be a Seatalk to NMEA converter for under a fiver.


If you do the latter project, I would be really interested in a converter that allowed you to select which sentence was output. I have an excellent but old Robertson autopilot that hasnt got a big enough buffer to cope with the huge and unselectable NMEA output from the Raymarine converter.
 
If you do the latter project, I would be really interested in a converter that allowed you to select which sentence was output. I have an excellent but old Robertson autopilot that hasnt got a big enough buffer to cope with the huge and unselectable NMEA output from the Raymarine converter.
I already did that years ago. But it is a rather sleeping project... Don't fill in that order form, if you are interested I could look if I still have parts.

http://www.ridax.se/mikael/seatalk.htm
 
Last edited:
You should all be making money selling articles to Elektor magazine, rather than saving pennies.

I've been playing about with PICs myself (to extend my programming knowledge) but haven't moved onto comms yet. Is there anything available worth reading on working with NMEA?

Philip
 
another mini project - bilge pump timer

AngusMcDoon,

I have read your posts with interest and admiration and would like to suggest another useful project to keep you busy this winter...

I have been researching simple timer circuits on the net to see if I could make a circuit to operate with a conventional bilge pump switch to control how long the pump stays on for.

This would enable the bilge to be emptied completely, reduce "cycling" as water in the pipe drains back and should help conserve battery charge.

It would enable the automatic bilge switch to be mounted higher. I'm looking for a circuit that is not "always on" and not gradually draining the batteryi.e the bilge switch turns on and then latches on for a certain time.

I'm sure there are commercial options but I'd like to take the "practical Electronics" approach.

Hope that makes sense.

Graham
 
Top