Go Down

Topic: UART(COM port) baud rate converter? Help anyone? (Read 4 times) previous topic - next topic

olafnew

I'll try to be more thorough

Data IN:
One UART TTL input, GPS, 115200, 10HZ updates, NMEA, the data is sent to the arduino at a rate 10 times per second so the average baud rate is 32000bps.

Data OUT:
Will need(arduino mega will do): 2/3/4/(the more the better) outputs. The data communication is unidirectional (recieve at RX and transmit to those 2/3/4 TX ports)

1) Must have an option to strip the NMEA 10HZ data stream to, lets say 2HZ, or even 1HZ, so that the average baud rate would be sufficient for selected baud rate (lets say in this scenario it's 9600)
2) If the baud rate allows it - no "stripping" neccesary, and all 10HZ data updates can be pushed to those other COM ports..

So that such a config could exist:
Data IN: 115200, NMEA, 10HZ
Data OUT1: 38400, NMEA, 10HZ
DATA OUT2: 14400, NMEA, 5HZ
DATA OUT3: 9600, NMEA, 2HZ

.. I'm a crappy programmer at arduino

So if i am screwed - It seems that the only way is to parse the NMEA data, and discard some of the NMEA "sentences" in case i need to put this data to the port with lower available bandwidth. Ok - is there a library and a parcer for NMEA? )))))

retrolefty

#6
Sep 01, 2012, 04:09 pm Last Edit: Sep 01, 2012, 04:39 pm by retrolefty Reason: 1
Quote
One UART TTL input, GPS, 115200, 10HZ updates, NMEA, the data is sent to the arduino at a rate 10 times per second so the average baud rate is 32000bps.


A little confusing as you are using baudrate to define something other then what it measures. A baud rate is a fixed clocking speed that both sides of a comm link agree to use to clock individual bits onto the com link and does not change. Character rate is a variable rate that can be any value up to a maximum rate possible that can be supported by the baudrate being used. So at a 115200 baud rate, a link can support a character rate to a maximum of 11,520 characters a second (divide by 10 because, 8 bit character + one stop bit + one start bit). However that same 1152000 baud rate link can certainly be used to send a one character message only every one second, so the link would be working at an effective rate of one character a second, even though the bits in that single character are clocking at 1152000 bits per second rate.

So when you say a device like a GPS will be sending a message at a 10hz rate, it doesn't give us a complete picture of the character rate as you don't state how many characters are going to be sent every 10hz, so an effective character rate per second can't be determined. If the GPS message can be of variable character lengths then it's even more difficult to state the effective character rate, only a possible maximum character rate based on the longest possible message.

Baud rate is essential to know as it is used to configure the AVR serial hardware to run at the correct speed you require to support the comm link. Effective character rate is important to know so that one can determine what software support will be required to handle the message traffic from the link, such as possible arrays of a specific length to use to 'buffer' a complete message, and the amount of time your program will have to possibly parse the messages and take action based on the content in the messages.

So your table:

Quote
So that such a config could exist:
Data IN: 115200, NMEA, 10HZ
Data OUT1: 38400, NMEA, 10HZ
DATA OUT2: 14400, NMEA, 5HZ
DATA OUT3: 9600, NMEA, 2HZ


Needs at least one other data value added to each link, what is the maximum number of characters that can happen every xxHz message cycle?

Also do you see a possible fatal problem with your defined links? If you can receive new messages into the arduino at up to 10 messages per second but have to limit sending them out as slow as 2 messages per second then your input stream will certainly be coming in faster then you can output the messages, so input stream will have to be buffered and there is limited SRAM memory to support that and I think that sooner or later you will 'overflow' the input buffered stream and lose information?


Lefty

wildbill

Stepping back a little, what are you actually trying to do? Presumably, you have several devices that consume NMEA sentences; is their baud rate limited? Does each need all sentences or a subset? Does it matter if not all sentences are delivered?

Having some more detail about the requirement might get you some more insightful advice; as is, it's hard to see the why.

Bainesbunch


You just read from one port and write to another, probably 20 lines of code

Code: [Select]
setup () {
   Serial1.begin (115200);
   Serial2.begin (9600);
}

loop () {
   if (Serial1.available())
       Serial2.write(Serial1.read());
}


Make that 8 lines :)

______
Rob




You may want to add the lines that define the pins used in the softserial library too :)
EmbeddedAT .. From Concept to Prototype to Production

Electronics and firmware design and project mentoring

Bainesbunch

OK .... so ...

We have two frequencies going on here, and some confusion as to the requirements of the "baud" rate.

The interface speed of the GPS is the baud rate, the rate at which it sends messages is the message rate, the two are not really inter dependent unless you are expecting to be transmitting data at 32 baud :)

So even if the messages are coming in at 10Hz unless there is a VERY good reason why not then they can also go out at 10 Hz independently of the baud rates.

The very simple serial repeater posted by Rob will do what you want, all you have to do is extend it to have the number of ports you are expecting to repeat to and specify the pins you are intending to use for the soft serial library. Most NMEA sentences are quite short and will not require buffering but can just be squirted directly out.

If you need more guidance with the coding just shout, I am sure there are plenty of people including myself who can knock this up in 5 minutes for you.

If my understanding is too simplistic and you do need to be throttling the NEMA message rate then it all gets much more complicated.

Cheers Pete.
EmbeddedAT .. From Concept to Prototype to Production

Electronics and firmware design and project mentoring

Go Up