How to plot USART data on a graph

[Adam329]

The microcontroller was sending an array which elements were numbers from 1 to 7.

The sequence seems to be correct in the buffer window yet it keeps jittering on the graph.

Also, the graph seems to act like the chart, it's not static.

It scrolls from right to left and connects the first and last element making a sawtooth, however, I expect to see something like a linear function when I'm sending it an array containing increasing numbers.

[Adam329]

Here's the error message.

[BalazsNagy]

Hi!

Thanks for the screenshots.

I think you shoul set a the size of the I/O buffer in bytes, on the serial settings tab. Set size slightly higher than the amount of data you expect to transmit or receive. This could fix the overrun error.

To set the buffer size in labview, use VISA Set I/O Buffer Size Function. 

If this error still occurs, flow control / handshankign is needed. 

A serial port may use signals in the interface to pause and resume the transmission of data. For example, a slow printer might need to handshake with the serial port to indicate that data should be paused while the mechanism advances a line.

Common hardware handshake signals (hardware flow control) use the RS-232 RTS/CTS or DTR/DSR signal circuits. Generally, the RTS and CTS are turned off and on from alternate ends to control data flow, for instance when a buffer is almost full. DTR and DSR are usually on all the time and, per the RS-232 standard and its successors, are used to signal from each end that the other equipment is actually present and powered-up. However, manufacturers have over the years built many devices that implemented non-standard variations on the standard, for example, printers that use DTR as flow control.

Another method of flow control (software flow control) uses special characters such as XON/XOFF to control the flow of data. The XON/XOFF characters are sent by the receiver to the sender to control when the sender will send data, that is, these characters go in the opposite direction to the data being sent. So during sw handshaking your receiver (the PC) transmits data to the uC.

I think if increasing the buffer size still not helps, you should try out some setting on the Flow Control Settings tab. Of course you have to use the same settings on your uC.

More info about serial communication: http://en.wikipedia.org/wiki/Serial_port

More info about RS-232: http://en.wikipedia.org/wiki/Rs232

Please try out my suggestions, and don't hesitate to post the results,

Best Regards, 

[BalazsNagy]

Hi Adam!

Did you manage to try out my suggestions?

Did it solved your problem?

Please post if not. If your quesiton is anserwed, please mark it.

Best Regards,

[Adam329]

Unfortunately none of these solved my problem.

I tried increasing the buffer to 32768, it did not help.

The ATmega2560 is on an STK600 development board, it supports RTS/CTS flow control so I tried that as well but it did not help.

Otherwise I can't find any registers to set other types of flow controls you mentioned.

[Adam329]

I made more screenshots. This time I fed the ADC with a sine wave and immediaetly transmitted it to my PC through USART.

Peaks appear quite often, I was unable to figure out why. Since no peaks appear on hyperterminal programs it is definite that the problem is caused by VISA.

It looks like it multiplies singular bytes at random which causes these peaks to appear.

[BalazsNagy]

Hi Adam!

Sorry for my late reply.

It seems that these spikes are quite asychronous, and their value is always significantly bigger than the amplitude of your signal. 

Because of this, I think you should use a case structure, that would select, if the incoming values valid (no peaks) are, or not.

You have to put this part of code of course before you begin to process and indicate the data. 

An other option is to try to communicate with your uC (dev. board) from an other computer. After this you could try to use your original computer with an other serial communicating device. (I you have the opportunity of course.)

Please use  your serail communication VI in both cases. Maybe with this method you could narrow the source of the problem.

If you did not see any peaks on other hyperterminal programs, than noise can be eliminated as the reason of this issue.

Are the paeks apperaing always with the same frequency and amplitude? (Did you try to send some other signals?)

Best Regards,

[Adam329]

The peaks appear on a different computer, I tried other signals as well.

Unfortunately they show up at random and their amplitude is inconsistent.

At the moment I'm using a US/RS232 cable.

[BalazsNagy]

Hi Adam!

Were you able to remove the peaks with the case structure, as I suggested?

Maybe the only solution is to "filter" your incoming signal with this method before you process or indicate it.

Best Regards,

[Adam329]

Unfortuantely the case structure is not a good solution because the amplitude of the peaks are random and they always in the range of useful data.