I am trying to send and receive radio signals using my Raspberry, but I am already stuck at the first step :)

My Radio module uses UART for communication but I have failed to set up my serial communication correctly. I found out Bluetooth is somehow interfering, so I disabled it. Now my program is at least able to step over read and write functions of my python script. Jippie :)

To test if UART works I connected Pin 14 and 15 (RX and TX) with each other and would now expect that when I send something, I will receive the same string?!? That should be right, shouldn't it? But on the receiving end I never get something... readline() return with no string.

I would be very very thankful if somebody could shed some light for me :) Or even a hint to a working tutorial. I already followed that tutorial: http://www.briandorey.com/post/Raspberry-Pi-3-UART-Boot-Overlay-Part-Two but it didn't get me much further... :(

Btw.: I am using Raspbian Version May 2016 (2016-05-10).

Here's my sample code:

#!/usr/bin/env python
import serial

ser = serial.Serial(
  baudrate = 9600,

print "Serial is open: " + str(ser.isOpen())

print "Now Writing"
ser.write("This is a test")

print "Did write, now read"
x = ser.readline()
print "got '" + x + "'"

  • In all seriousness Georg you should include the code you are using to do this -- it does not sound like it is very long, and it is much, much simpler for other people to make suggestions that way. If you are unsure about how to have the code formatted correctly, see here, but as a quick tip that's what the {} button is for in the compose/edit interface. – goldilocks May 15 '16 at 17:25
  • @goldilocks didn't expect my sample code to be relevant at that point :) Thought it's more of an configuration issue of my Pi :) I edited my question to add the code – Georg May 15 '16 at 17:54
  • A simpler way to test this would be to separate it into two scripts, start the reader first, and then run the writer. – goldilocks May 15 '16 at 17:58
  • Just tried that... That's not working either... So I am pretty sure it has something to do with the UART and Bluetooth interference on my Pi3. Btw. I already freed the serial from the console using raspi-config. – Georg May 15 '16 at 18:19
  • 1
    My favourite python side note: While it is not an issue wrt the question, something to consider for future coding: per PEP0008 Use 4 spaces per indentation level. – Ghanima May 15 '16 at 18:53


I believe the default device node on the Pi 3 is different. Try:


You may also need to disable the serial console. The easiest way to do this is via raspi-config under Advanced Options -> Enable/Disable shell and kernel messages on the serial connection.

If you don't have raspi-config, it doesn't work, and/or you want to double check, first look in /boot/cmdline.txt. If you see:




Or anything involving console= that isn't console=tty1, remove it. Make sure not to accidentally add a line break to that file, it should remain all one line with spaces between the options, but no spaces around any =.

The other aspect is the login started by the init system. On Raspbian jessie, check:

ls /etc/systemd/system/getty.target.wants

If you see that serial device node (ttyS0) mentioned, disable this service:

systemctl disable serial-getty@ttyS0.service

You will have to reboot for these things to take effect.


If you're using Raspberry Pi desktop you have to enable Serial in its configuration I think...

  1. Click on the small RPi icon on upper left
  2. Click on preferences
  3. Then click on Rasp. Config
  4. Go to Interface
  5. Enable Serial

/dev/ttyAMA0 is now used for Bluetooth, and the default has problems with varying clock rates. See How-do-i-make-serial-work-on-the-raspberry-pi3

NOTE This was done on previous version of Raspbian, as I haven't had a chance to test the latest but should still apply.


I had the same problem on my RPi3 (Jessie after 18th March 2016 release) and solved it by changing enable_uart=0 to enable_uart=1 and adding dtoverlay=pi3-miniuart-bt (disable the bluetooth on the UART) at the end of /boot/config.txt. I use pin 8 and 10 (TX and RX).


I don't know how Raspbian Python handles the serial timeout, but if I were coding it, I would still start out putting a delay of at least a couple of milliseconds between the transmit code and the receive code (I'd start with 5 ms). Your receiver can't flag the first received byte until the data has shifted 10 bits completely out of the transmitter and into the receiver. That is a delay of approximately 1 millisecond. Once that works, you can back out the delay to see how the timeout handles it. Of course, this may not be related to the real problem, but it removes one unknown.

protected by Community Mar 28 '18 at 10:34

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.