That device was an embedded device, for which it did not make sense to even consider installing a window manager on it. Recently we needed to process the results of a tcpdump command using the GUI version of WireShark on machine that did not have a window manager installed. The serial port is opened with O_RDWR | O_NOCTTY | O_NDELAY pointed at /dev/ttyUSBx (usually 0 or 1) and configured with the following: tio.30 November 2017 in Applications tagged execute over ssh / local / mkfifo / named pipe / pipe / pipe over ssh / remote / ssh / tcpdump / wireshark by Tux
Please let me know if I can provide anything else to claify it further.Īll code for this project is written in C++. Here's some extra information to help clairfy the problem. Really, any information on how TTY might be working differently than usbmon would be appreciated. My goal here is to find a way to receive the data at a consistent 128Hz, so I am open to any solution that allows me to do that on my current platform within raspbian. I have not seen any correlation between the NTP updates (including jumps) and this problem. I think it is also worth noting that the system clock is being trained by NTPsec using a GPS, and that I have ruled out any NTP updating or slewing as part of the issue. I am not sure if they are related but this is the only other thing I have found to be consistently similar to my problem. I have also done some stress testing using stress-ng on the system, and found that when the I/O is saturated that this issue also comes up. I am aware that there is a difference between the TTY layer and the general USB layer in the Linux kernel, but I am not sure why usbmon is able to see things that TTY does not. I am not experienced enough with how Linux handles USB to solve this issue, so I’m not sure how to move from here (although not for lack of trying). These logs appear to show the frames being received without any stalling. Then after the “stall” ends all of the data I expected during the last 0.05 seconds shows up very quickly (faster than 128Hz) and then the data is received as expected.Īs part of my debugging efforts, I used wireshark with usbmon to monitor the frames being received from the ADC. For about 0.05 seconds, I don’t see any data received. For example: Data is received at 128Hz, and then a “stall” happens. I have found an issue where the data seems to stall and then rush in at a later point. I am using ttyUSBx to interact with the ADC. For my purposes this data is time sensitive, so having reasonably accurate timestamps on the 128Hz data is important. The ADC should be providing data at 128Hz, and does so fairly reliably. I am working on developing a sensor platform based on a raspberry pi running raspbian and an analog/digital converter (ADC) connected via USB.
0 kommentar(er)
