RX two serial inputs at the same time?

I need to collect data from two serial sources and the data can arrive at the same time or multi byte offset from each source. These are GPS receivers at 4800 baud with little intercharacter byte spacing.
If I use the USART for one of the sources, I can detect one of the inputs and capture it. If the other source happens to come at the same or close in time, I will miss the start or miss characters using the serin2 command
Is the only way to service two random serial inputs with two PIC’s…. where one is just dedicated to servicing the second serial source?
Would an external USART or two to handle the data even be economical considering the low expense of another USART capable PIC.
Regards,
tcbcats

tcbcats,

have you had a look at:

http://www.picbasic.co.uk/forum/show...highlight=nmea

I have 6 different NMEA-Talkers connected as described there.

regards

NavMicroSystems,
Did you keep the RX PIC's output at the same 4800 baud or did you speed them up for sending the data to the combiner 16F or 18F PIC?

I was thinking of bumping it up to 9600 just so the receivers would occupy less time transfering their data.
Did you also run all the PIC's from the same clock to save parts?
Regards,
tcbcats

The Multiplexer sends out NMEA 0183 V2.0 Sentences at 4800 Baud.

This allows standard NMEA Listeners to be connected to this "One-Wire" NMEA Data Bus.

regards

My question was about the 4800 baud receivers.
Did you speed up the PIC to PIC serial com path in order to have more time for processing the data from each listener?
I understand that the final result is still output at 4800 or whatever is needed.
tcbcats

The PIC to PIC link is @ 4800 due to the fact that the 12F629s
are running on the INTRC OSC.

regards

tcbcats,

I've been down this route before.... its not easy using a single pic to capture dual serial inputs at the same time. I found it damn impossible.

As you know with NMEA talkers, they transmit data at different time intervals. I found some of the more up market GPS receivers allow you to define the transmit intervals of each string.

If you had two such GPS receivers, you could set the time intervals with a big enough delay so that they never transmitted at the same time.. but this could quicky change especially if some one else changed the timing, or added more strings to transmit.

Or you could do the opposite... decrease the transmit
delay and focus on alternating the reception of each input. Then you can be sure that if you miss a string.. you'll capture it again next time it gets transmitted.

Back to your original question about speed....

I found that the main limiting factor wasn't speed... but memory.

Some NMEA strings are very long and you have to work on the NMEA data one string at a time. (and this between reception of the next string!)

It all comes down to which NMEA stings you are wanting to capture and how many.

I don't recommend using the USART.

Good luck.

Hi tcbcats,

You want to receive NMEA- Data with a pic with only one serial port from two GPS- Receivers? I think there are some ways to do this with but I need to know which chipset is built in your Receiver. Sirfstar, Antaris (u-blox), or fastrax?

Or did you solve your problem yet?

I think you have to use a PIC with 2 integrated UARTs and do some handcoded lines into your programm in order to access the receivers. I think, the buildin-commands from PBP will not help you.

I don't think that PIC with 2 USART will do the job since they are on the same processor. PIC are not really *multitask*. For sure you'll lost bytes. The 1 pic 1 receiver is the safe solution. If you want to expand why not using one PIC as main and others only to get from receivers.

regards

I disagree. Quote from a previous thread...

"Actually PICs do genuinely multitask quite well. They're able to sample an ADC channel, perform multiple Timer functions, execute PWM trains, catch data in the USART and perform Analogue Comparisons all genuinely simultaneously whilst your program is doing something completely different. It's called using the features provided within your PIC and the secrets of exploiting these multitasking features are... in the Datasheet."

Whilst PBP with the HSERIN command is unsuitable, a single PIC is more than capable of catching, caching and acting on data from multiple USARTS by reading the USART registers directly (and you can simply achieve that with PBC or PBP). And because the USARTs have a buffer, you have to be a total klutz to actually miss any incomming data even if your program has the reaction time of a tetraplegic tortoise on valium.

The big problem is that SERIN and HSERIN give the unexperienced or novice programmer powerful string handling features, which otherwise they would find difficult to impliment if faced with a simple RAM buffer with a heap of data in it which now has to be parsed.

Melanie

OK, i'm a perfect *klutz*, let's back to my datasheet, let's do some study now. I really apoplogize for my previous thread.

Thanks Melanie for that. One day i'll be good

"tetraplegic tortoise on valium" i like that one :)