Shorting CTS / RTS lines is meaningless, you should rather leave them unconnected if you don't use flow control. Note that CTS / RTS signals are available on Pi side (pins 11 and 36, respectively), but they are rarely needed and not enabled by default.
I'd say, you have two ways of debugging:
Get a USB to serial converter (and perhaps connect it to a laptop ...
First restore your cmdline.txt to the original.
Run sudo raspi-config and configure serial (and disable serial console).
You then communicate to dev/serial0 NOT /dev/ttyUSB1.
I assume the device (whatever it is) supports 3.3V logic levels (and has nothing to do with RS232) and is connected to some other computer (which needs to be appropriately configured).
Find out what the actual Garmin baudrate is (using a logic analyzer, e.g. piscope) and configure your cable to use that. Then check that the cable accepts the baudrate you're setting by running your loopback script and checking the baudrate with a logic analyzer. UART converters have limits on min/max baudrate, and some of them will simply use their min ...
Yes, there is a way to reset the serial port, by closing it and opening it again. This will also reset the Arduino.
However, I would rather try to understand what's wrong with the communication. You already have a timeout which should apply to all read/write operations.
Print raw strings (make sure you can distinguish strings with and without \n) which you ...
I finally managed to somehow figure out the solution for it.
it was because of this serial-getty@ttyS0.service which was blocking any other data from ttyS0.
Just do the following:
sudo systemctl stop serial-getty@ttyS0.service
sudo systemctl disable serial-getty@ttyS0.service
and you are good to go.
NOTE: This is only tested for serial port(/dev/ttyS0) in ...
Are you really using pins 15 and 16? The standard UART uses 14 and 15, I use a basic buster install, use raspi-config to disable serial console and enable serial IO then it all works as expected on pins 14 and 15.
I found this useful reference on the net:
You can not connect multiple serial devices to an interface (although it may be possible with additional circuitry to multiplex devices - only one can work at a time).
You can of course SEND to multiple devices but only receive from one.
I figured it out, if all you want in the end is audio information in whatever format (which is my use case), you can use follow the steps here and here, make sure you change the files according to your OS and rasp Pi model.
After making the default card number change in the config file, you should be able to save a recording in whatever format and duration ...
Here's the instruction for everyone who wants to make Bluetooth Serial communication to work without dealing with Python or other piggybacked programs running inside Raspberry Pi Model 3 B+ or 4 and Pi Zero easily.
This configuration (below) works well with Android (old Android with BT 4.0 or later) and iPhone (8 or newer) with Bluetooth 4.0 or higher, ...
What you may need is one if these boards
They connect to the usb on the pi and then to serial on your custom board
I have used these in the past, and they work great
As far as I understand you want to connect to the serial debug console with using a USB to TTL (RS232) serial cable. This usually works without any problems if using the right terminal software. I haven't tried minicom for this. I know that screen and tio works, where I prefer tio. It is a nice tiny program just made for a serial console without any overhead....
I do not know something about your UV light projector. But the Raspberry Pi recognizes it, when it is connected by USB. That doesn't mean that it can also handle it. You need a driver. For popular device classes the kernel has drivers built-in so these will work out of the box. But that seems not to be the case with your projector. The error message suggests ...
If you want all of the sensors to be read in one script/window then the three recv statements need to be in the same while loop.
However if you want them to run in three different terminals, I would make your script take a parameter so you could specify on the command line which server that script will connect to. e.g:
python read_spp_server.py 11:27:EB:D1:...
hci0 refers to the physical Bluetooth adapter/radio in your system. If you connect a Bluetooth USB dongle to your RPi, then you would see hci1. e.g.
pi@raspberrypi:~ $ bluetoothctl list
Controller 00:02:5B:33:44:07 RPi_UART [default]
Controller B8:27:EB:33:57:E0 SeeMe
pi@raspberrypi:~ $ busctl tree 'org.bluez'
I'm pretty sure that the serial switch you have found will work. After all, from the master side it's just a serial device replying to AT commands.
If the target serial devices you plan to connect are themselves using AT commands, you'll have to be careful about escaping such commands so that the switch doesn't try to process commands you send to target ...
It looks like your code file is named serial.py. Change it to something else!
If you name a file in the current working directory after a module, then Python will use that file in your current working directory than the modules installed.
This seems to be a very old problem for which there is no proper solution, only workarounds.
One workaround consists in avoiding framing errors on the serial line. Make sure the RX line has a solid connection, if you hot-plug devices into it, use pull-ups to guarantee a defined level. Avoid switch baudrates, try using the same baudrate for the bootloader and ...
I see you already solved the problem, but for the reference, I use the following script to debug problems on USB bus:
for sysdevpath in $(find /sys/bus/usb/devices/usb*/ -name dev); do
devname="$(udevadm info -q name -p $syspath)"
[[ "$devname" == "bus/"* ]] &...
I had a similar issue. My script calls the serial ports ttyACM* and I use .config/lxsession/LXDE-pi/autostart to launch it at startup. As I
was having problems with this approach, I checked the .cache/lxsesion/LXDE-pi/rpi.log and I found out my script was not able to open the serial port only at startup, right after boot. It was not a matter of permissions ...