I'm communicating with my Arduino via Serial, using this program called X-Sim.
I'm sending car gauge data to the arduino and displaying it on 7-segment displays.
Suggestions for bps and data send rate? I can probably use a more optimal bps instead of 9600.
The program/device works upto 256000 I believe.
I want to have the fastest data refresh rate possible on my screens.
I'm thinking a high bps will will have too much overhead, and a low bps will require too fast of a data send rate.
Am I way off here? I've only played with the settings for a few hours. Please school me in serial communication.
I'm thinking a high bps will will have too much overhead, and a low bps will require too fast of a data send rate.
Why are you thinking this?
You have a certain amount of data to send. Whether it takes one millisecond or one week, the "overhead" is exactly the same.
The refresh rate of your display will tell you how often you have to have data available, to show the latest data. That time, and the amount of data, will tell you the minimum baud rate required to send the required data in the required time. Any higher rate is good, too.
The drawback to very high speeds is that the time required to read a bit is very, very short. At 300 baud, you have 1/300th of a second with a pin HIGH or LOW to detect that bit. At 115200, you have 1/115200 seconds (about 8 microseconds) of HIGH or LOW.
Since the data is received by a hardware serial port, using interrupts, the speed of the data has little impact on the Arduino application.
I'm thinking a high bps will will have too much overhead, and a low bps will require too fast of a data send rate.
Why are you thinking this?
You have a certain amount of data to send. Whether it takes one millisecond or one week, the "overhead" is exactly the same.
The refresh rate of your display will tell you how often you have to have data available, to show the latest data. That time, and the amount of data, will tell you the minimum baud rate required to send the required data in the required time. Any higher rate is good, too.
The drawback to very high speeds is that the time required to read a bit is very, very short. At 300 baud, you have 1/300th of a second with a pin HIGH or LOW to detect that bit. At 115200, you have 1/115200 seconds (about 8 microseconds) of HIGH or LOW.
Since the data is received by a hardware serial port, using interrupts, the speed of the data has little impact on the Arduino application.
Thanks! Cleared some things up for me
I've done limited testing, but I did notice at 9600bps and a pause of 1ms in X-Sim the arduino would lag, IE the rev counter wouldn't update quick enough and the LEDs for shiftlights weren't triggered at the right time.
When I turned the send rate down to 5ms, the display seemed to lag a lot less. Is there a way to calculate the optimal serial pause and data rate?
Another question if you don't mind.
What form does serial data come over the COM port? Is it binary? Or something else? What's the most optimal way to send numeric data that has to be quickly refreshed?
Examples are, live laptimes down to 1/1000 of a second, digital Tachometer.
What form does serial data come over the COM port? Is it binary? Or something else?
It's all binary, in that it is a pattern of 0s and 1s. Some of those patterns of 0s and 1s correspond to letters and digits. Some do not.
The governing factor is how the sending application sent the data. It might be a series of bytes that need to be reassembled to form an int or a float, or it might be a string representation of the value ("27.3").
There is no way to know by looking at the bit pattern.
What's the most optimal way to send numeric data that has to be quickly refreshed?
In binary - a series of bytes, rather than as a string.
Examples are, live laptimes down to 1/1000 of a second, digital Tachometer.
You have a high power computer. Make it determine, and send, RPM, rather than making the Arduino compute the RPM based on elapsed time.
Here's a shot/some info of the X-Sim serial interface, so that i'm making a little more sense.
Good grief. Looks like a cheap-assed ad-supported web site.
