USB-Serial Reading frequency goes wrong every 2 minutes


I have a TX1 (R24.2.1) with ASG003, and I want to use Range Sensor named ‘SF11
( Product manual : )

That sensor can communicate with UART serial.

So I connected range sensor with ‘CP210x uart to usb converter’. I built the cp210x driver with reference to

SF11 range sensor sends encoded ASCII characters which meaning range information (7byte) every 0.05sec (20Hz) through serial communication.

The serial setting is : baud 115200, no parity, 8 data bits, 1 stop bits, no handshaking.

And this is the test code made with Python 3. Recording the time when data has received.

import serial
import time

class RANGE():
		self.ser = serial.Serial(adr, 115200)
	def processdata(self):
		if readbyte>0:                                                    #When data received   #Time tagging on data

if __name__ == '__main__' :

	f = open('sf11.txt', 'w')
	print("Laser Range Finder DAQ Start")

		while True:

			#do something
				d.append(   #Storing data
	except KeyboardInterrupt:
		for i in range(len(d)):                #Saving data before exiting script

And this is the plot of the Reading frequency. Calculated with 1/(current timetag - previous timetag). Testing time is 800s.

Most of the values stay near 20Hz, but you can see these 4 lines down to 10Hz. The spacing between each line is exactly 120 seconds. This happens not always, but often.

I tested the same code on Windows and Linux Desktop, but this issue happens only on TX1.

And the similar problems also come up not only cp210x but FTDI serial converter.

So I think that every reading performance drops every 2 minutes.

To solve this problem, what should I check? Have any similar symptoms been reported?

Thanks in advance.

I cannot explain why, but some problems with USB serial communication have disappeared after disabling usbcore autosuspend at boot time. For doing so, add this line to file /boot/extlinux/extlinux.conf :


and reboot.

You might also make sure performance is maximized, try “sudo /home/ubuntu/” (use --show option before and after if you want to see what changes).


Thanks for reply, but I have already tried that with reference to this :

However, whether usbcore autosuspend is working or not, the result is same.


Thank you for your help, but it does not seem to be related to cpu performance.

The result is also same when the performance is maximized.

Thanks you all for your help.

My guess (and it is only conjecture) is that during a spike CPU0 is servicing another hardware driver (thus starving the measured device). One example might be that gigabit networking or hard drive are processing. What other devices are connected (testing results after disconnecting WiFi, ethernet, and USB devices which might be useful…I wouldn’t expect a keyboard or mouse to be significant, but anything like hard drive or even an active WiFi should be removed and/or disabled while testing)?

Note: If you have a specific PID you might want to also test renicing to a higher priority (default user priority is 0, a renice to -2 would give the process significant advantage over almost any other non-critical process). If you have a custom driver of your own running it might be rearranged or changed to play nicer with other hardware drivers (e.g., dividing it into a hardware IRQ top half and software IRQ bottom half)…but I suspect you aren’t writing your own driver since you are just using USB.

Please check if there is any difference in ‘cat /sys/kernel/debug/clock/clock_tree’ when the issue happens.

Useful command:

sudo watch -n 1 cat /sys/kernel/debug/clock/clock_tree