M6e-nano on Raspberry Pi via GPIO pins

[Headforthehills]

Gday,

I am hoping to use the Sparkfun SRTR on a Pi via the GPIO pins and would also love some support on how this could be achieved as my searches have tuned up nothing. I have been searching for an appropriate URI to use in the reader object mercury.Reader(uri, baudrate=115200, antenna, protocol) as I assume this would be how it is achieved.

Thanks in Advance!

[Headforthehills]

I have just nutted this out and will give some detail for anybody else like me who is probably working above their pay grade!

Physical Connections: SRTR Pi (3b+) VCC +5V pin GND GND pin TX0 RXD0 (pin 10) RX1 TXD0 (pin 08)

Run sudo raspi-config and go to the Interfaces (5) and Serial (6) option You'll want to turn the console OFF and serial device ON when it asks. Then reboot.

I got this hint from https://www.raspberrypi.org/forums/viewtopic.php?t=190443

Then use tmr:///dev/ttyS0 as the URI for the reader object. I got the hit for this from https://www.raspberrypi.org/forums/viewtopic.php?t=170214

If you use a Pi older than the 3b, is sounds like you should use tmr:///dev/ttyAMA0 as the URI for the reader object.

Hope that helps someone.

Cheers.

[clickworkorange]

Beware that the Sparkfun Simultaneous RFID Tag Reader has a 5V TTL serial port, and the Raspberry Pi is not 5V tolerant! It might work, but for how long? Ironically, the M6e Nano hybrid module comes with a 3.3V TTL serial port, but Sparkfun's board packs a TXB0104 level shifter which ups this to an Arduino compatible 5V. Note also that the M6e Nano can get its firmware in an irrecoverable twist if any of its GPIO or serial RX lines are held high at shut down or start up (see M6e Nano Design Guide p.56). In other words, the M6e Nano serial port requires a buffer which is controlled by its internal power supply, so you cannot simply bypass the TXB0104. To work around this you can either use a USB <> TTL interface, or a bidirectional 5V <> 3.3V level shifter - or, if you're feeling brave, you can mod the TXB0104 to deliver 3.3V on both sides.

Edit: Being brave reckless I opted for the latter, and lifted the TXB0104's VCCB pin and jumpered it to OE (which gets 3.3V from the M6e Nano):

This way the TXB0104 behaves like a plain 3.3V buffer and the serial port is now Pi safe. Works perfectly!

[zaphodbe]

When using this board I ran into a lot of issues with the TXB0104 so completely removed it and replaced it with wires. The TXB0104 parts are supposed to auto detect direction and change accordingly, however they often get it wrong and with the mix of pull-ups etc didn't work when connected to a 5V FTDI cable although did work when connected to an Arduino UNO. The jumper wires are only 3.3V compliant but now it works with a 3.3V FTDI cable, other 3.3V Arduino compatibles and PI no issue.

[clickworkorange]

When using this board I ran into a lot of issues with the TXB0104 so completely removed it and replaced it with wires.

That may be fine, but they do warn against connecting straight to the serial RX pin:

YMMV. It's worth noting that the reference carrier board design also includes a buffer, at 3.3V in that case:

This allows the M6e Nano to enable/disable the serial port connection via V3R3.

[Headforthehills]

Thanks for the tip. I was 100% unaware. Steep learning curve for me.

I'm happy to mod my board so that the converter acts as a buffer. Saves trying to add another pcb into the project box!

I was also unaware of the need to ensure the serial & gpio pins were low. I assume the sparkfun board does this naturally so long as I don't remove the TXB0104 all together? I'm not using the sparkfun gpio, only the Pi's.

Cheers!

[clickworkorange]

I had no idea either; I only stumbled upon the warning while researching a method for making the serial port Pi compatible. It sounds as if ThingMagic themselves didn't know about it either until the module had gone into production - firmware corruption is likely not an intentional "feature" :) I have no idea how common a problem it is - probably quite rare since it wasn't detected pre-production - but I figured it was best to follow manufacturer recommendations.

Modding the board as I did has the benefit of being relatively easy to reverse if needed. Just be really careful not to break pin 14 when you lift it! I used a bent needle while heating with a soldering iron. Also double check that you haven't created any solder bridges before applying power, and ensure that pin 14 is kept isolated from its pad (I used a piece of very thin heat-shrink tubing) - shorting the Nano's V3R3 to the 5V rail may well lead to disaster...

Edit: Anyone who wants to use the M6e Nano with a Pi or other 3.3V device might be interested to know that you can buy an "official" SkyeTek carrier board with a 3.3V serial port for a similar-ish cost ($300) to the Sparkfun board ($225). It also comes with an integrated heatsink (you do need one), a sturdier external antenna connector, and what looks like a USB connection. I would have preferred this route if I didn't already have the Sparkfun board...

[clickworkorange]

I assume the sparkfun board does this naturally so long as I don't remove the TXB0104 all together?

Yes, but the only lines which go through the TXB0104 level converter/buffer are

• TXO
• RXI
• Enable
• GPIO1

Not sure what that means for GPIO2-GPIO4; these go straight to J7 at the top right of the board (marked as LV2-LV4; with "LV" no doubt meaning "low voltage"). These pins will not be 5V tolerant, and if the warning in the M6e Design Guide is to be taken seriously I would avoid using them as inputs.

[Headforthehills]

I have disconnected Vccb on the TXB0104 and connected it to the OE pin... Not such great results on my end! Nothing horrific, just getting various errors at runtime including:

  File "test.py", line 6, in <module>
    reader = mercury.Reader("tmr:///dev/ttyS0", baudrate=115200)
TypeError: Timeout

  File "test.py", line 6, in <module>
    reader = mercury.Reader("tmr:///dev/ttyS0", baudrate=115200)
TypeError: CRC Error

If I connect Vccb to the 3.3V pin on the Pi however, works perfectly. It also works with no connection at all...

Not sure what is going on here - I dont know how stable the Sparkfun SRTR board's 3.3V supply is... perhaps not stable enough?

EDIT: My issue has now resolved itself... Vccb is connected to OE and working well. May have been my soldering skills!?

[clickworkorange]

Pretty sure the V3R3 output from the M6e Nano module is rock stable; it's there specifically for the purpose of driving external chips such as a buffer (see schematic in official design guide p.58). FWIW I've not had any issues with the serial comms after ~100 hours of usage. It is a fiddly bodge to implement though!

[Headforthehills]

Yes - I now think it was a poor bodge-job on my behalf and I was reluctant to fiddle with it too much. A quick clean up and I haven't had an issue since. Cheers!