Usb To Serial Converter Baud Rate

[Roxine Denison]

You can't buy a baud rate converter, it is a job for a micro controller.
If you use an Arduino Mega you have four hardware serial ports to do this. Note however that having an input rate faster than an output rate will cause what ever buffer you have to overflow eventually.

Yes but this is extremely unlikely to happen. I used to set exam questions along these lines, asking how long would it take a specific size buffer to overflow. It is just like the classic primary school problem of a bath tub overflowing.

You are now asking us more questions without supplying any more details.
For example what is this mystery source of RS232 data?
What do you want to do with it?
Why do you think you need to use two processors?

All these things are important if you want specific informed help. Otherwise we can only help with general comments which might not apply in your particular case. In other words we only know what you tell us.

Wait until you have received a complete message from UART1 Port at Bd = 38400. After that send that message to your desired destinations using UART2 and UART3 Ports at Bd = 9600. In the meantime, you might have missed many messages from UART1 Port. After that collect another message from UART1.

In computer science, a circular buffer, circular queue, cyclic buffer or ring buffer is a data structure that uses a single, fixed-size buffer as if it were connected end-to-end. This structure lends itself easily to buffering data streams. There were early circular buffer implementations in hardware. A circular buffer first starts out empty and has a set length. In the diagram below is a 7-element buffer: Assume that 1 is written in the center of a circular buffer (the exact starting location ...

Don't forget to take into account that your conversion from binary to ASCII representation of the data will almost certainly increase the volume of data being sent through output2. That will further limit how much input data can be handled before overflowing the memory available for buffering.

Yes but that will skip information every time the buffer overflows. You will loose a buffers worth of data, and if the whole data is not confined to a single byte you will also loose the order the data is sent in.

When implementing any sort of FIFI buffer, it will be implemented as a circular buffer. It would be crazy to do anything else. So your distinction between a buffer and a circular buffer is a fallacy.

Nope. IF the buffer overflows. Look, you guys are "diddling the pig". Until the OP gives up some info about the source of this data stream, it's so many wasted electrons. The source could be a smart sensor that barfs a 6-byte measurement once a second, or it might be a continuous stream of single byte values, no break whatsoever. No one but the OP knows enough to give a decent answer. Unless, of course, you figure you're just providing indigestible gravel for an AI bot to chew on - if so, continue!

That is why I asked for more information in post #11 we are now at post #19 and still no sign of the OP answering. I suspect he might not know the answer, which is why he has not replied. But it would be great if he acknowledged this point and we could all stop wasting time.

Guys, i would really appreciate any help - is there any open sourced baud rate converter implemented in arduino for several com ports? I really need something like 115200 ttl com in, and 38400 + 9600 + 115200 out on several com ports. Anybody done this type of thing before?

Well I don't think you have defined your requirements well enough to say it can be done or not on a arduino. However a arduino mega board does have four serial ports available so under certain conditions serial conversion is certainly possible. But again requirements have to be more clear, such as:

Is the one input stream the slowest of the baud rates relative to the output streams? If not then possible additional buffering might be required in your sketch, above what the arduino hardware serial library makes available.

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? )))))

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.

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?

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?

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

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.

The application is RC plane OSD and telemetry. It's really weird using 2-3-4 GPS recievers, instead of just one, but with a splitter, that can split the protocol to the required baudrate(requirment of the end device) and the update rate(also a requirment of the end device)

When using MTK utility for setting the GPS, it gives an overhead in procentage, when you set the baud rate. And it doesent allow to set any update rates higher than 2HZ for 9600baud... I'am not sure that the sentence is 72bytes, i do believe it's much, much larger.

olaf
You will probably need to filter your GPS input. You do this by sending messages to your GPS module. This way you reduce the input on your arduino.
For my gps module the code looks like this

I'm looking for a VI that will give me the 64 bit custom code for CAN and CAN FD baud rates given a set of inputs. By that I mean I want to give a VI a desired baud rate, and sample point, and it returns the custom hex code that is valid for the custom Baud Rate property:

Yes I know you can just type in the baud rate and sample point into the dialog in the XNet Database Editor, or Bus Monitor in MAX. But I work with a variety of hardware and don't want the user of my software to have to calculate the hex code, I just want them to give a baud rate and sample point and have the software figure it out.

I found a VI posted here which does generate a 32 bit valid custom hex for the interface, which appears to work in the 64 bit property too. But I'm also looking to do this with the CAN FD baud. I'll try editing that VI to support my needs but if that doesn't work out does someone have code, or know of code buried in the vi.lib or something that does this calculation? Thanks.

I feel a little silly because again I think I came up with my own solution. I looked at the VI I linked to and I think I made all the needed changes for it to be applied to the 32 bit CAN FD custom baud settings. My quick test with my hardware appears to work. If anyone has another solution or a similar set of code for the 64 bit settings feel free to reply here.

DISCLAIMER: The attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at:

I'm looking for a vi to convert 64-bits baudrate and sample point into a custom baudrate, exactly like the screenshots of xnet bus monitor. Do you know if this king of tool exists? I've tested all the vis of this discussion without success...

c80f0f1006