ESP32 seems RX is ok but not TX

[Maigre]

Hi,
i am trying to wire the RFID module to an ESP32 devkit.
I use a BSS138 level shifter (and also tried with a 4050 level shifter)

I can receive communication from the RFID module, but any attempt to send seems to fail.

Code:
`#include <Arduino.h>
#include <SparkFun_UHF_RFID_Reader.h>

RFID nano;

void setup()
{
Serial.begin(115200);
nano.enableDebugging(Serial);

Serial1.begin(115200);
nano.begin(Serial1);
}

void loop()
{
nano.getVersion();
}`

The log says:
sendCommand: [FF] [00] [03] [1D] [0C]
Time out 1: No response from module

If i reset the RFID module by grounding enable pin i can see:
sendCommand: [FF] [00] [03] [1D] [0C]
response: [FF] [14] [04] [00] [00] [14] [12] [08] [00] [30] [00] [00] [02] [20] [22] [08] [04] [01] [0B] [01] [25] [00] [00] [00] [10]
Wrong opcode response

which i guess is the firmware version sent at boot (as mentioned in examples).
The "wrong opcode response" is logical since it was asking for getVersion and got something else instead.
It shows that RFID -> ESP32 serial is working.

So it seems that my ESP32 can receive data from the module,
but any command sent does timeout without answer...

Any clue ?
Thanks !

[sfe-SparkFro]

Hi there!

It looks to me that both TX and RX are actually working fine. In this example, the ESP32 first sends a command to the module, and the module sends back a response. Since that response is printed out, that implies both TX and RX are working fine.

However, the warning you're getting is that the opcode is wrong for some reason. I'm not super familiar with the communication protocol, but at least looking at the source, opcode 3 corresponds to a command to get the version number:

SparkFun_Simultaneous_RFID_Tag_Reader_Library/src/SparkFun_UHF_RFID_Reader.h

Line 22 in 0f33516

#define TMR_SR_OPCODE_VERSION 0x03

This is reflected in sendCommand: [FF] [00] [03] [1D] [0C] where [03] is the opcode that's sent. In the response, you're getting response: [FF] [14] [04] [00] [00] ... where [04] is the opcode that's being sent back. It should be the same as the opcode that was sent, but it's different for some reason. I don't know why that would be, I've not seen that before.

For what it's worth, running the same code on my end with an ESP32 works fine without any warning:

sendCommand:  [FF] [00] [03] [1D] [0C]
response:  [FF] [14] [03] [00] [00] [14] [12] [08] [00] [30] [00] [00] [02] [20] [21] [01] [17] [01] [0B] [00] [16] [00] [00] [00] [10]

The opcode sent back is 3, as expected. The bytes at the end are different from yours, but that's just because my module is different from yours. Digging a bit deeper, I believe both our modules have the same hardware version (30.0.0.2), but the firmware versions are different; mine is 1.B.0.16, yours is 1.B.1.25. It's possible that the wrong opcode sent is just a bug in that version of the firmware, and might be resolved with a firmware update.

Can you try running Example1_HardwareSerial_Constant_Read? It's under the Advanced folder of the examples. It's written for a Teensy, but it should work on your ESP32 by changing every instance of Serial5 with Serial1. If that example works correctly without any problems, then I'd be inclined to believe the wrong opcode is an issue with the module firmware, and not this library.