We have an Edgeport/4 (301-1000-94) configured with three ports in use. One of these is running at 115,200 baud and receiving packets of data at 100Hz. Each packet is about 63 bytes long. The other two ports are doing I/O at a much lower rate. When connected to any of several desktop systems I have no problems but when connected to a laptop I occasionally see dropped data bytes about once every second or two. I believe that the buffer in the Edgeport device is getting overrun because the USB driver is not polling the device fast enough.
I cant find any way to control the polling speed and none of the device configuration flags seem to be relevant to this problem. Have you seen this problem before? Do you have any suggestions as to how I might solve it please?
Regards,
Nigel
What are the differences between the desktops and the laptop?
I have a bit more information now:
Comparing several USB-serial devices and a PCIe-serial device, it appears that the problem is that the serial device isn’t getting serviced often enough given the size of the hardware buffers. The problem has shown up on the desktop machine now - although much less frequently. I had suspected the USB stack but the PCIe-serial adapter had the same problems (but more often).
We are not using flow control because the data is a live feed and we cannot buffer it. I suspect that if I enable hardware flow control, I’ll see the CTS line de-asserted indicating the buffer is geeting full.
What is the 50xxxxxx part number AND revision of the Edgeport/4 in question?
Part number: 50000835-01 A
Serial: W84034333
That looks like a new part number, so I’m not certain what kind of chipset that is (that’s my goal here). Sorry for any inconvenience but please click the Information button at the top-right of the EP Config Util and tell me the PID. I can determine the chipset from that for sure.
Here’s the info:
VID: 1608 PID: 0242
Boot code: 1.01.0
Download code: 5.38.0
ROM: 8KB RAM: 16KB
CPU rev: 2
Board rev: 0
I am seeing similar lost data with different adpaters and I am now thinking that this happens when I have a lot of network I/O and perhaps the network NIC IRQL is higher than the serial interfaces (including USB) so occasionally the network ISR is blocking the serial ISRs from running.
Nigel
OK, that is a current model which uses the TI chipset. The different chipsets (TI vs. the older 930) handling buffering differently so that’s the reasoning behind finding out which kind of chipset(s) you’re working with.
Please give me the same information from the other Edgeports so I can see what kind of chipsets they have in comparison. PID is the best way but if you give me the 50xxxxxx part number and revision, I may be able to determine the chipset that way.
Also, if you have any Edgeports that you are NOT seeing this issue with, it would be good to know more about them too (PID and/or 50xxxxxx part number and revision).
the only other device I have is:
PID: 0201
Serial: I81302862
This device has worked very well even running two ports at 230,400 baud but I have seen the same data loss issues (very rarely) on this device.
My other testing on the laptop was with a Belkin single port USb-serial adpator and a StarTech PCIe dual port adapter. Both showed data loss issues. The Belkin was about the same loss rate as the Edgeport. the StarTech PCIe adpater was much worse - I suspect it has only a very small buffer.
I ran a test using RTS for flow control and the edgeport does de-assert RTS occasionally indicating that the buffer is getting full. I’m pretty sure this is not your problem and I’m going to have to find a way to use hardware flow control and buffer the data comming into the edgeport.
Overall I think the edgeport devices are great - easily the best install/config/features of the many USB-serial devices we’ve used over the years.
Nigel
The reason you are experiencing data loss is because of the lack of flow control in your device. Once the software buffer fills up, the Edgeport driver will stop posting reads to the USB for more data on that port. Any data that is still being streamed into the port (not flow controlled) will cause overflows and data loss.
If you cannot incorporate flow control into your final solution, you may be able to help minimize the data loss a couple of different ways. (Keep in mind, without a debug trace to tell me exactly how your application is communicating with the serial port, I cannot say for certain that this will help your particular situation, but it’s worth looking into.)
One way would be to increase the RX serial buffer via your software, when initializing (setting up) the port. How you do this and how much control you have over the serial port will depend on whether or not you are using serial API calls directly from your application or if you’re using a third party serial library (ActiveX control, etc).
The other thing which may help would be to change how often your application posts reads to the serial port. We see a lot of applications that may have a device streaming data into the port, but for some reason the application may not be servicing the port often enough to keep things moving. Increasing the number of reads to the serial port(or posting larger reads) may help out if that’s the case.
Keep in mind that with any serial port that is not flow controlled, you stand the chance of losing data. This problem, however, is only exacerbated when using a serial port behind the USB, because they will typically have more buffering than on-board serial ports. For this reason, we have certain methods which we must implement in order to provide the most efficient way of getting data in and out of the ports.
Without implementing flow control in applications like this, you’re certain to have data loss!
Let us know if you have any other questions.
Thanks,
Nathan F.
Thanks. I’d pretty much concluded that we need flow control at this point. We already set the Windows rx and tx buffer sizes and we have adedicated thread to get the data. We don;t have this issue on our real-time systems because our ISR has guaranteed latency.
thanks very much for your responses to this thread.
Nigel