I am using the exodriver on Ubuntu 14.04 LTS with a U6. I am doing streaming with 6 values per sample. Asynchronously I am sending bitset-commands to set relays or reset an external watchdog.
Now it happens that the stream is getting out of sync by losing data. The frequency this happens depends on the performance of the machine my code is running on. But I think this is not the root of the problem. I think that the explanation under 4. could be part of the problem and that on low performance machines this just happens more often.
Following things I found out using gdb-debugger and wireshark monitoring the usbmon-devices:
1. I am losing data.
2. The amount of data varies. Partially this is only one value. But I already lost more values(up to 3).
3. This seems not to be a problem of the exodriver. I already see that there are some values missing when looking into monitoring of the usb interface with wireshark.
4. This seems to happen, when I send two bitset-commands without a pause between.
5. A similar software running under windows with the ud-driver also seemed to lose streaming data. But this is two years ago and my workaround was resetting the U6. As this did not happen that often I have seen no reason for further investigations. But it comes back to my mind now.
With all that information in mind I assume that this is a problem within the U6-firmware and not the driver itself.
Could you please have a look at that problem? Thanks in advance.
Regards
I see in your wireshark capture that we are not missing a couple values but rather an entire packet or stream data. Packet number 87 is missing entirely. Packets 19022 and 19024 appear to be empty USB packets, where I would expect a response to the feedback commands 19021 and 19023. I believe the packet is being lost by the USB hardware when the extra commands come in.
If this only happens when you send two commands then the best solution is to put both IO updates in a single feedback packet.
Good hint with packet 0x87. Til now I did not check that. You are right. One complete packet is missing, not only some values.
And as you say it is also little bit mysterious that there is no response in the response packets 19022 and 19024. But if you have a look at the other response packets in the capture you see that the responses are also missing. What is going on there? How can this happen? I did not recognize that because I am not evaluating the responses of these commands.
What do you mean with "lost by the USB hardware"? Do you mean the USB controller with the libusb attached on the machine or do you mean the LabJack U6?
Packing the two commands into one feedback command is not an option because of two things:
1. I am not able to define when two commands are sent at the same time because this is done by the program code. Ok, sure, I could use a queue with timeout. But I think this should not be necessary.
2. And the following is much more important : I cross-checked that on a machine with a little bit more performance. There this problem appeared less often than on the low-performance machines, but it happend too. And it happend with only one command being sent to the LabJack U6.
I think it is important to verify on which side of the connection the problem exists. At the moment I would say it is the U6 that is dropping a complete packet. Do you see it the same way or am I completely wrong?
It sounds like the problem is related to unread packets. We need to read the proper size from the USB pipe or a lot of problems can occur.
Hmm, I do not get exactly what you mean. Could you explain that a little bit more detailed? Thanks.
It looks like the responses to the feedback packet (DIO updates) are not being read from the USB pipe. That tends to cause USB issues.
It took a while before I could check that as I also had to deal with other problems.
Now a short feedback:
You are right. That seems to be the problem. When I read the feedback to the DIO updates the problem seems to be gone.
In spite of everything I would have expected that the firmware of the U6 is able to deal with that. Especially as these are completely separate USB pipes.
But problems seem to be solved now.
Thank you for your help.