does this piece of code look ok?

[NavMicroSystems]

Richardco,

Even two USARTS on the same PIC will NOT solve the problem.

Why not use one PIC per talker?

A 12Fxxx would do, so it is less than $2 for every talker you want to add.

[Richardco]

Ralph
it is Because i am not cleaver enough to do it, with all the coding on the other chip, i know it comes natural to you, but me well it took me long enough to get my program working on one chip, never mind two, for the 12f chip i just wouldnt know where to satrt and polling well again over my head. i know all the information is available but it just looks like too bigger job for me to do... at my stage in the learning curve. Like one reply said it hurts the chaps head to read my code when it jumps in and out although i couldnt see that myself (it looped sent some data looped while sending more data then went on to the next pin) it must just be because i dont have that sort of brain although a HND in software engineering would suggest otherwise.

[Squibcakes]

Richardco,

I've been down this path before. Its pretty tough to multiplex NMEA data with a pic and not loose data from at least one source.

You would be better off learning the basics before tackling this project!

Trust me, I've waisted hours trying to do this


The only thing I can suggest to you is rather than use the pic to serial receive / send the data, use the pic to control a digital switch (isolated).

The switch would then cycle and pass through each talker's NMEA data. You could also use the PIC to detect the CR/LF at end of each string to trigger the digital switch to cycle to the next talker.

Cheers
J

[Richardco]

Thanks Squibcakes, i will bear that in mind, i am reading like a lunatic at the moment so i dont keep making myself look stupid and because i want to learn, this is not the last you will hear from me on this subject i am not willing to give up on it i just need to fill in a few more gaps in my knowlege. I am going to give the multiple pics a try in the mean time more as a learning tool.

[NavMicroSystems]

The only thing I can suggest to you is rather than use the pic to serial receive / send the data, use the pic to control a digital switch (isolated).

The switch would then cycle and pass through each talker's NMEA data. You could also use the PIC to detect the CR/LF at end of each string to trigger the digital switch to cycle to the next talker.

Squib,

I totally agree,
MUXing NMEA Data without loosing too much data and not adding too much delay is not one of the easiest tasks.

With the switch approach you'll need a MCU to control the switch.
And you have got to do a bit more than just triggering on "$" and "CRLF"
many talkers send out telegrams consisting of more than one sentence.
(I have actually not seen any talker sending out just a single sentence)
Every single sentence within that telegram starts with "$" and ends with "CRLF"
(Think of a GPS Unit)

By simply triggering on "$" and "CRLF" you will randomly get one sentences out of the telegram,
but this is most likely not the one you really need.

And due to undefined timing between different talkers transmissions will most likely be overlapping and you will still miss data.

So switching in a pure electrical sense does not really help.
What you need is some smart "store and forward" mechanism.

Sure,
if there aren't too many talkers to be MUXed and you can afford to miss one or the other sentence
a simple switch controlled by a simple timer (no MCU at all) would do.
But bear in mind that this solution will create some garbage on the MUXed bus (incomplete sentences).
I have seen Listeners being locked up by garbage on the bus.

[NavMicroSystems]

Having thought about the switching method...

With a limited number of talkers there is an option to avoid garbage on the bus.
(You will still miss some sentences, but if there are not too many talkers it may be acceptable if you don't need a realtime display.)

PSEUDO

MAIN:
Listen 1st talker
wait for the talker to become idle (time between two transmissions)
switch 1st talker to the bus
wait for talker to become active (or timeout if talker doesn't "talk" within a defined time)
wait for talker to become idle again
disconnect talker from bus

Listen to 2nd talker
wait for the talker to become idle (time between two transmissions)
switch 2nd talker to the bus
wait for talker to become active (or timeout if talker doesn't "talk" within a defined time)
wait for talker to become idle again
disconnect talker from bus

.
.
.
GOTO MAIN

[Richardco]

Ok im not good a wording what im thinking which may be why my coding is so bad but i will give it a go: i need a break from all this reading anyhow

would a pic be fast enough to do it like this, memory allowing:

memory locations from A01-A99 & B01- B99

read byte from pin 1 into memory location A01
is byte "crlf"
if yes move from memory location A** to tx & clear memory reset memory location to A01
if no increment memory location A01

read byte from pin 2 into memory location B01
is byte "crlf"
if yes move from memory location B** to tx & clear memory reset memory location to B01
if no increment memory location B01

start again

[Squibcakes]

Nav,

As you know, many talkers can send out different strings, and different versions of nmea... just to add to the complexity of NMEA.

My understanding was that Richard wanted to display two items on his echo sounder:

1. Windspeed/Direction ($--MWV) and
2. Position ($--GLL) or ($--GGA)

To keep things easy, he needs to turn off all other sentances coming out of both the GPS.

Instead of detecting the $ (start of string) and LF (end of string) he could just let the MCU just toggle every couple of seconds, say three.

That way, if a sentance does get chopped off, the echo sounder should just ignore the bad string.

The other thing to consider is the time it takes the echo sounder to bring up an alarm when an string input is missing.

This is how I would do it.

PS
(Thinking more about it, you could do this using a JK Flip Flop, and couple of Gates)