does this piece of code look ok?

[NavMicroSystems]

Richardco,

I guess you have already searched the forum for "NMEA" and read the matching threads.

A standard NMEA Talker sends out 1-3 sentences per second
(depending on the type of talker and length of the sentence)
The standard baudrate is 4800

To make sure you catch the "SYNC" string ($xxxxx) of a talker you have to sit there and wait (worst case) for about two seconds before your receiving routine times out.

This has to happen for every single talker.

Say you have "only" four talkers it takes (worst case) about 8 seconds before you get a full update.
(It gets even worse with an increasing number of talkers)

Especially for a sounder reading I feel this is unaccceptable.
(You will have hit the bank before your display is updated!)

On a sailracer all other readings should be more or less "realtime" as well to be of any use for trim.


Decreasing the timout value for the talkers does not really help as there is no defined timing.
Most likely you will (most of the time) have more than one talker "talking" at the same time.
So which one to listen to?

With a timeout too short you will worst case never get in sync with a particular talker.

[Richardco]

Hi NavMicroSystems

you said:-
A standard NMEA Talker sends out 1-3 sentences per second
(depending on the type of talker and length of the sentence)
The standard baudrate is 4800

if that is in a thread somwhere else i must have missed it because i was under the impresion that the data stream from a talker was continuous at 4800 baud, Again my mistake, but there has been a lot said about it,

I can see why for a sailracer nipping along at 30 knots or more why realtime would have to be the case, for trim and distance travlled and i can now see how all the data from 4 talkers would be collected, and sent out at 4800baud.

I have an 18ft hastings rye clinker with a single pot 10hp Diesel yanmar and if it goes faster than 5 knots without thrashing the engine it must have a tail wind and be running with the tide.

My equipment consists of a garmin gps 120 and a simrad EQ30 echosounder i have used the nmea output from the garmin and sent the data to the EQ30 as the display on the garmin is small and the backlight is poor, the EQ30 on the other have is Large and bright, with the vision problems sorted i discover that the EQ30 has the ability to display information from several different nmea devices however there is only one nmea input so you must just choose one external device or go down this route of buying or building some sort of multiplexor, at the moment i could probably make do with just 2 inputs to the EQ30, the garmin and a weather instrument to give wind speed and direction, which can be done on just one pic with two hardware usarts with no problems so i understand, so i came on here and looked at the threads on 'NMEA' and from what i read i saw that maybe in the future i would need more than two nmea devices connected to the system and so decided to go down that track for my boat system but to try and keep it on one chip if i could and if this meant losing data then that didnt seem to bad. Your last post above answers all my questions i do thankyou very much for that, with all that you have said maybe i will just keep to two nmea inputs to hardware usarts on one chip, that will take into consideration all the knowlege you have emparted to me and allow me to keep it all on one chip as well Assuming that the pic will be fast enough to collect all information from the two inputs Thanks again. with all that in mind i think a re-write of my code would be in order lol
Now all i have to do is remember where i saw the post on two hardware usarts on one pic (i hpoe it wasnt an atmel) so i can see what pic they were refering to.

[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