NetBurner Community Forum

Hi,

For some reason our serial speeds are really slow, and I am out of ideas. I stuck the StopWatch code around it to see how fast it is, and it seems to alternate between 13ms and 55ms, those two values, over and over; more regularly to be random.
The code:
https://gist.github.com/c2e4ddd4f76281316a31

The serial port is running at 115200 baud, and this task has the highest priority of all my tasks.

Any ideas on how to speed this up? All the other lines in the code above take about 4-6ms, which is not too fast, but acceptable if I can get the serial read faster.

Thanks!

As a side note, I've found the support and community on here to be very helpful! Thanks a lot!


Christoph

I have a serial application that runs at 115,200 baud. Using HyperTerm sending a text file I get about 5,000 characters/second (about half the expected baud rate). I suspect that HyperTerm is having problems sending data at 10,000 characters per second.

bb

1 char at 115200 should be about .86 msec.
I suspect your issue is with the transmitter, not with the receiver.

Most PC based serial drivers will not keep a 11500 K serial link full.
USB serial ports are usually worse.


Paul

Yeah I am not sure how to test the speed of the transmitter, but settings-wise it's set to 115200 baud, which is something like 14.4kB/s, right (according to a Google search)?
I need about 15 bytes of data at a time, which should only take 1ms. That's what I would like to see. 5ms would be okay, too.


This is going from a commercial device over serial directly into the board, so there's no PC or USB adapter in the middle. I will try and test for faulty cable and see what happens.
I know it's possible to get higher speeds out of the device because it came with a test application which is able to read the data from the device much faster than I see on the board, measured just by inspection. This leads me to conclude that either my code is sub-optimal, or the cable is bad, or the board can't handle it, in that order.

Thanks for the help so far!

Christoph

The other possibility is that the test app setups the device to output faster.
Try connecting the device to a PC serial port and see how fast its sending.
What device are you trying to read from?

How are you measuring receive speed?

To test your app connect a PC serial port to the NetBurner and see what happens when you send it a whole file via MTTTY or Hyperterm?

Hi,

pbreed wrote:The other possibility is that the test app setups the device to output faster.

The device is set to 115200 baud, which is the max it supports, so the speed should be the same.

pbreed wrote:Try connecting the device to a PC serial port and see how fast its sending.

Doing just that with a USB adaptor, and the data I am interested in comes in pretty quickly.

pbreed wrote:What device are you trying to read from?

It's a radar pedestal from which I am reading the current position. The app that came with it gets and displays that data pretty quickly, just by looking at it. For 20 deg/s rotation speed I get updates on the position for fractions of a degree granularity. On the board, I only get about 2 whole degrees between readings, so it's much slower.

pbreed wrote:How are you measuring receive speed?

Just by the time it takes to do the read call, measured with the StopWatch code. That, and inspecting it and seeing the data update so slowly compared to the test app we have.

pbreed wrote:To test your app connect a PC serial port to the NetBurner and see what happens when you send it a whole file via MTTTY or Hyperterm?

Yeah good point, I will have to play with that.

I checked the code for reading the data in the test app they provided, and it is very similar to mine. The only difference is I use a much smaller buffer and read in less bytes; I will see if that makes a difference.

Thanks for the pointers!

Christoph

How are you reporting your incoming messages?
Can you open a support ticket and post your code set.

If you take the example application and only connect receive and gnd, does it still go as fast?
This would indicate that the PC app is not sending rate change commands to the monitored device.


Is it possible you have the parity or number of pits wrong?

"how is the hardware conencted do you have the proper level shifters?


Does the data look correct even though slow?

pbreed wrote:How are you reporting your incoming messages?

I write them to a RingBuffer and read it out in another task, and write that out to a network socket. When I do that, I get tons and tons of 0.0 (meaning the RingBuffer is empty), with a real data value mixed in every once in a while, so it seems plenty fast to write it out.

pbreed wrote:Can you open a support ticket and post your code set.

I don't think I still have support for that. I will check again once I test my code changes later this afternoon.

pbreed wrote:If you take the example application and only connect receive and gnd, does it still go as fast?
This would indicate that the PC app is not sending rate change commands to the monitored device.

I will give that a shot and see how quick the read is.

pbreed wrote:Is it possible you have the parity or number of pits wrong?

Hm, I don't think so, but will double check.

pbreed wrote:"how is the hardware conencted do you have the proper level shifters?

It's just a serial connection, so not sure what you mean.

pbreed wrote:Does the data look correct even though slow?

Yes, it looks good.

Thanks!


Christoph

but settings-wise it's set to 115200 baud, which is something like 14.4kB/s, right (according to a Google search)?

Baud is bits per second. So 115200baud is 115.2k bits per second and assuming you are using settings of 8 data bits no parity 1 start and 1 stop bit (ie 10 bits transmitted per byte of data) you'll get 11.52k bytes per second of data - at the absolute theoretical maximum.

Your figure of 14.4k Bytes per second is a meaningless measure of the 10 bits, per bytes of your data, datastream calculated into byte sized chunks (including the necessary start / stop bits that the serial UARTs at each end of the transmission add and remove.

If your settings use parity with 8 data bits or 2 stop bits your theoretical throughput will be lower. Often parity is used with 7 data bits and ASCII transmission only (not binary).

These data rates are also assuming the your transmitting device can buffer up the message block to send the data as a continuous data stream.

I think you should follow Paul's suggestion and first check on the performance of the transmitting device. If the data is a periodic burst of 15 characters (bytes) you may be able to tell if there are inter-character gaps or if it is continuous by capturing a data packet on a storage oscilloscope. But asynchronous serial data transmissions are quite difficult to capture on a 'scope because they are asynchronous and not regular! So be careful how you interpret what you see!

Gavin

Gavin,

Thanks for explaining, that makes sense. It's 8 bit data, 1 start 1 stop bit, no parity.
I know the device can handle it because its own program gets the data fast over serial, through a USB adaptor no less.

I think I may be making some headway though, but nothing sure yet.

Christoph