Timeout error - M6e Nano and Raspberry Pi Zero W

[TheAdoxBox]

To start off, I do believe the issue is with the hardware, and not the software (as seen in other posts regarding the 'Timeout'). I have also confirmed that the Pi's UART (GPIO 14 and 15) are working (tested with an oscilloscope). I have been using the M6e Nano board from SparkFun (https://www.sparkfun.com/products/14066) as well as the Raspberry Pi Zero W. I have also been using an external antenna (which I confirmed has been setup correctly). I have the following setup (both supplied with sufficient power at 5V): Pi Reader Tx -> Rx Rx <- Tx Gnd <-> Gnd

The reader outputs 5V, but the Pi is not 5V tolerant. Therefore, I setup a voltage divider to step down the reader voltage from 5V to 3.3V for the Rx pin on the Pi. Everything seemed to work after confirming the voltages with a multimeter. Fast forward to the following day, the exact same setup is configured, but now, the 5V from the Tx on the reader dropped down to around 4V and the Rx on the Pi (after voltage divider), dropped down to around 2.11V. Nothing was changed from the previous setup (including the software), but the values changed somehow. The correct voltages are read if no connections are made between the two devices as well. I am led to believe that the logic level shifter needs a certain amount of current to be drawn to receive the desired voltages and that somehow, enough current is not being drawn by the Pi. I don't know how that would change when the setup is the same, but that is the only thing I can think of. We have done more testing, but this has been the most recent findings. Any help would greatly be appreciated.

[Timatgithub1]

I have the same issue. Using this api with the SparkFun M6e Nano breakout board and a RPi 3b.

Error as shown below:

pi@raspberrypi:~/code/python/mercury-rfid $ python
Python 3.7.3 (default, Jan 22 2021, 20:04:44) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mercury
>>> reader = mercury.Reader("tmr:///dev/ttyS0", baudrate=115200)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Timeout
>>> 

System:

• Raspberry Pi 3B
• Sparkfun RFID reader, using M6 nano https://www.sparkfun.com/products/14066
• Debian buster based Raspberrian
• Python 3.7.3
• API installed by using: pip install python-mercuryapi -b $HOME/tmp

Checks:

• Board and api work, I have successfully scanned tags using an FTDI LC231X USB to serial adapter
• The Pi’s UART works, I have successfully communicated between the RPi and an Arduino using UART*
• I have changed the RPi config settings for enabling UART and disabling the Unix serial console as described here
• The Pi user is part of the dialout group
• As described in in this link, I have modified the TXB0104 by soldering a wire from the VCCB to OE in order to disable the 5V - 3.3V separation and use 3.3V. The new setup works, since I have successfully used it with the FTDI adapter in 3.3V mode (has an 3.3V / 5V jumper). But it dit not solve the timeout error.

By now I exhausted all options I can think of to solve this issue.

Some guesses:

• I am quite confident the hardware and the api part of the software work.
• I assume it must have something to do with the link between the library and the UART connection. So I guess either an installation or configuration issue.
  When I used the UART for communicating with the Arduino I used the Python Serial library, this may not be the same as what the gotthardp’s python-mercury api uses under the hood (I don’t know how this is addressed under the hood, since I have no experience in C). In other words, I tested the UART in a Python way, but this may not mean much in regards to the Python-mercury api.

Any suggestion will be much appreciated.

*UART between RPi and Arduino as described here Using this LLC Using the following code:

import time
import serial
              
ser = serial.Serial(            
     port='/dev/serial0',
     baudrate = 9600,
     parity=serial.PARITY_NONE,
     stopbits=serial.STOPBITS_ONE,
     bytesize=serial.EIGHTBITS,
     timeout=1
)
        
while 1:
     ser.write('Hello\n')
     time.sleep(1)

[TheAdoxBox]

It has been a while since I have used my setup, but I will tried to provide insight wherever possible. My issue turned out to be that my GPIO pin (Rx on the RPi I believe), despite working intermittently, was busted because of the onboard level shifter, though you have already addressed that. I would recommend confirming the output voltages of the Reader, ensure there is a common ground between all your components, and probe the UART connections with an oscilloscope. Ensure that the Tx on the RPi is even transmitting (again, by monitoring the signals with an oscilloscope). If it is, what is the Reader returning (probe again)? Does the reader have enough power (do not power the Reader from the RPi)? Another helpful tip is that everything may work individually, but when you integrate everything together, stuff starts to break. I would recommend building the system together piece by piece, testing at every step along the way to see where the system breaks.

If you haven't already, I would read/understand the datasheets of the M6e Nano and the documentation provided along with the Reader on the Sparkfun website. You may have to look at the schematics of the Reader and see what pins they connect to on the M6e Nano. Additionally, you may have to look up the individual components on the Reader itself (this information can be found on the Sparkfun website in the documents).

Hopefully this link can provide some more useful information: https://www.mstriegel.de/Engineering/Interfacing_the_M6E_Nano_UHF-RFID_Reader_With_a_Raspberry_Pi.html

Best of luck and I hope this was helpful!

[Timatgithub1]

@TheAdoxBox Thanks a lot for the quick and elaborate reply. All though it took me a long time to get back, your response made me return my focus to the hardware again.

I don't have a oscilloscope at my disposable. However, I was able to buy a new RPi 3b+ and did the same tests, like so:

• RPi 3b+ out of the box
• Swapped SDcard from previous RPi to the new one. No changes in software.
• Successfully communicated through UART with an Arduino (including the use of an LLC of course). So UART hardware works.
• Received time-out error when using the reader and the python-mercury api. Time-out issue still there.

I have been using the reader module without problems with the use of the previously mentioned FTDI USB-serial adapter.
Both in conjunction with the RPi, and with a laptop. Which confirms that the reader works.

The only conclusion I can draw is that the hardware is fine and the issue is within the software, to my own dismay.

I don't know how the python-mercury api addresses the UART under the hood (I have experience with C) but I guess it won't be the default Python serial package (i.e. 'import serial' - which I used for the RPi - Arduino setup). Therefore, I assume that's where I should look. But I will need some help to do this.

[TheAdoxBox]

@Timatgithub1 My pleasure! I'm sorry to hear that you are still running into issues!

It's very unlikely for two RPi's to not work so I don't think that's the issue. I still have a feeling that it's not the underlying software though. Same tests and same issues makes me think it could be the Reader possibly? Are you able to use a continuity checker for your modifications on the Reader (ensure there are no shorts)? I know you don't have an oscilloscope at your disposal, but I do think borrowing one or going somewhere that has one would really help with debugging (even if you are able to buy one and return it - granted there is a full refund policy). I don't think getting another Reader is an option either as they are quite expensive. Maybe you can undo your Reader modifications and buy a bi-directional logic level shifter to go between the RPi and Reader ( 5V <-> 3.3V). Ensure your Reader is getting enough power as well. There is a chart in the datasheet I believe that shows power consumption depending on your reading power. Just want to make sure the Reader isn't being starved and acting up due to power issues. Keep at it, I know you will get it!