How to recive data every 200 us by SerialPort

[apc22]

Hello,

I need to desing a DAQ with high resolution and with high sampling ratio. So I am using a Arduino DUE for read 25 Sensors and for send this information via SerialUSB. I need 5ksps of sampling rate on each sensor so I am sending every 200us a data package of 75bytes (3bytes per sensor), but LabView doesn't read the buffer with this rate, that's generate the Serial port buffer fill.

I am using VISA library, I tried with and without interruption on serial port and anything works. I did some test and the sending data ratio that don't fill the SerialBuffer is more tha 10ms, but this is too much for what I need.

I don't know if exist any way to use USB interrup raw or another way to improve this. Or maybe the loop that I'm using to organizate the data is using the procesr power (I recive data in two's complement).

Thanks for help or coments, I am learning Labview and I could make roockie mistakes.
The principal VI is FourTry.

[RTSLVU]

Watch this video, I think it might help.

VIWeek 2020/Proper way to communicate over serial

[Kyle97330]

It sounds like you're using serial via USB, and I've had USB-serial adapters before that have had driver settings that you could change to get better response times.  Go to device manager, find the device, and see if you can find any settings for the device in question.  On mine, I got a lot better response times when I changed the latency timer from its default 16 ms down to 1 ms

This isn't a guarantee you will have similar settings that you can change, but it's something to check.

[LLindenbauer]

The Arduino DUE has a native USB peripheral on the chip that is used by the SerialUSB library. This makes the issue a bit more interesing - I'd recommend reviewing this article and accompanying video if this is news to you (and if you can abide the non-standard pronunciation of 'due'): https://hackaday.com/2021/03/20/arduino-serial-vs-serialusb/

[crossrulz]

Let's also do some math here:

(75 Bytes*10bits/Byte)/200us = 3.75Mb/s.  So your Baud Rate needs to be 3750000.  That is way more than a normal serial port.  Are you sure your interface can handle that?  I honestly don't know what the Arduino Virtual Serial Port can do, so that is a serious question.

Note: The 10bits/Byte is from 8 data bits + 1 start bit + 1 stop bit in the UART protocol.

[LLindenbauer]

---

@crossrulz wrote:

Let's also do some math here:

(75 Bytes*10bits/Byte)/200us = 3.75Mb/s.  So your Baud Rate needs to be 3750000.  That is way more than a normal serial port.  Are you sure your interface can handle that?  I honestly don't know what the Arduino Virtual Serial Port can do, so that is a serious question.

Note: The 10bits/Byte is from 8 data bits + 1 start bit + 1 stop bit in the UART protocol.

---

With native Serial-USB implementations, all UART parameters may be purely virtual and may or may not be handled at all. Start, Stop and Parity are almost certainly ignored, as their function in the Data Link layer is no longer needed. The same reasoning applies to the Baud Rate.

It seems that timing itself is a critical part of the question. With serial converters, the device is polled regularly to keep the buffers happy, the data moving and the physical lines busy. In native USB, the device just sends a chunk when it feels like it, including the packet overhead of roughly 20 Bytes.

The question here seems to involve some requirements on the timing. The latency setting, if present, might be used to set an upper limit on the time between flushes, but is 1ms fast enough here? That would be 5 samples arriving at the same time. Manually flushing the buffer on the DUE might do the trick but incurs the packet overhead each time.

Maybe the time critical part of data handling could be done on the DUE first? If this is just about timing information and not latency, maybe a timestamp could be added to the data set before sending it?

[billko]

---

@LLindenbauer wrote:

---

@crossrulz wrote:

Let's also do some math here:

(75 Bytes*10bits/Byte)/200us = 3.75Mb/s.  So your Baud Rate needs to be 3750000.  That is way more than a normal serial port.  Are you sure your interface can handle that?  I honestly don't know what the Arduino Virtual Serial Port can do, so that is a serious question.

Note: The 10bits/Byte is from 8 data bits + 1 start bit + 1 stop bit in the UART protocol.

---

With native Serial-USB implementations, all UART parameters may be purely virtual and may or may not be handled at all. Start, Stop and Parity are almost certainly ignored, as their function in the Data Link layer is no longer needed. The same reasoning applies to the Baud Rate.

It seems that timing itself is a critical part of the question. With serial converters, the device is polled regularly to keep the buffers happy, the data moving and the physical lines busy. In native USB, the device just sends a chunk when it feels like it, including the packet overhead of roughly 20 Bytes.

The question here seems to involve some requirements on the timing. The latency setting, if present, might be used to set an upper limit on the time between flushes, but is 1ms fast enough here? That would be 5 samples arriving at the same time. Manually flushing the buffer on the DUE might do the trick but incurs the packet overhead each time.

Maybe the time critical part of data handling could be done on the DUE first? If this is just about timing information and not latency, maybe a timestamp could be added to the data set before sending it?

---

You can't ignore things like parity and start/stop bits.  Baud rate certainly cannot be ignored.  How are you supposed to sync?  Just because a chip may be implemented virtually doesn't mean it can make up its own rules.

[LLindenbauer]

---

@billko wrote:

You can't ignore things like parity and start/stop bits.  Baud rate certainly cannot be ignored.  How are you supposed to sync?  Just because a chip may be implemented virtually doesn't mean it can make up its own rules.

---

It is precisely the virtualization that allows that. That's the whole point. There are no physical RS-232 signals anywhere, so there is no need to negotiate their shape or timing.

This is the second time here on the forum that this comes up, so please allow me to elaborate. There are just two pieces of USB hardware that both talk  USB to each other and inform each other, using USB, about the state of their own UART. It just so happens that neither UART exists in physical reality. There are certainly are no native RS-232 signals, no DTR or RI anywhere on my machine. But I can still have my computer pretend to a USB device that there are, in fact, bauds and parities and CTSes and the whole works. Why should the device on the other end of the USB cable be unable to do the same in return?

It's just like dialing a number on the cell phone: Back in the days, when you dialed a number, your phone would send a pulse train or tones down a landline to let the switch know where it should route the call. You had to manually finish dialling in a timely manner before the switch would time out and hang up on you. Now, this is all done virtually. We still use numbers, but the dial timeout is gone and you don't concern yourself with the state of the signal line - the advantage of there not being one in the first place.

PS: You can check for yourself - the Arduino DUE firmware and SerialUSB library are open source. You can open it up and check for yourself if you don't believe me.

[JÞB]

---

@LLindenbauer wrote:

---

@billko wrote:

You can't ignore things like parity and start/stop bits.  Baud rate certainly cannot be ignored.  How are you supposed to sync?  Just because a chip may be implemented virtually doesn't mean it can make up its own rules.

---

It is precisely the virtualization that allows that. That's the whole point. There are no physical RS-232 signals anywhere, so there is no need to negotiate their shape or timing.

This is the second time here on the forum that this comes up, so please allow me to elaborate. There are just two pieces of USB hardware that both talk  USB to each other and inform each other, using USB, about the state of their own UART. It just so happens that neither UART exists in physical reality. There are certainly are no native RS-232 signals, no DTR or RI anywhere on my machine. But I can still have my computer pretend to a USB device that there are, in fact, bauds and parities and CTSes and the whole works. Why should the device on the other end of the USB cable be unable to do the same in return?

It's just like dialing a number on the cell phone: Back in the days, when you dialed a number, your phone would send a pulse train or tones down a landline to let the switch know where it should route the call. You had to manually finish dialling in a timely manner before the switch would time out and hang up on you. Now, this is all done virtually. We still use numbers, but the dial timeout is gone and you don't concern yourself with the state of the signal line - the advantage of there not being one in the first place.

PS: You can check for yourself - the Arduino DUE firmware and SerialUSB library are open source. You can open it up and check for yourself if you don't believe me.

---

You are confusing the physical layer (which may have hardware handshakes) with the packaging layer.  Oh yeah,  each byte still gets sync and error bits.  Or, it would not be a "Serial" port... it would be a parallel or perhaps a multidimensional quantum port.

Your phone still needs to transmit each number tone pair digit by digit IN ORDER or you "dialed" the wrong number.

[LLindenbauer]

I will grant that I have not been explicit about wraping up the Physical and Link Layer up as one in my examples. This changes little, since both are handled over USB and simulated on both ends. This can be seen in the article I linked above from the wireshark traces. There are no Start, Stop, or Parity bits transmitted.

The Serial Line is a character device. It promises you that if you put bytes in you get the same bytes out, as long as everything is aligned. As it turns out, when you don't have a physical line, you can just assume that the non-existant line was correctly aligned and don't worry about it.

The Start/Stop 'Bits' are not part of the application data. You would be very lucky to be able to mangle and bit-bang your application data just so that it might correctly move over a misaligned physical UART pair and come out at the other end as intended.

In the end, all this is of little consequence for most users. The virtual UARTs I have seen didn't care if you messed up the settings and worked fine either way. It might be of consequence for the thread opener, though, given that they have some tight timing requirements to fulfill. Maybe they would be better served to post the question on an Arduino hardware forum instead?