M7E Hecto — Identical Read Behavior With and Without Antenna Connected

Community
1

I’m running a SparkFun M7E Hecto (ThingMagic M7E) on a Raspberry Pi via USB-C, communicating over /dev/ttyUSB0 at 115200 baud. The board was previously reading Alien H3 UHF key fobs at approximately 16 inches using an external antenna connected via U.FL pigtail.

I recently swapped the coaxial cable in my antenna chain. Since then I have had zero reads.

I’ve done the following diagnostic work:

  1. All five setup commands return status 0x0000 (OK): GEN2 protocol (0x93), Region NA (0x97), Power 27 dBm (0x92), Antenna Port 1 (0x91), Disable filter (0x9A).
  2. The 0x2F continuous read command fires correctly and returns approximately 34,816 bytes over 3 seconds.
  3. Every tag frame returns status 0x0100 — no tags detected.
  4. Critically: the byte count and frame content are identical whether the external antenna is connected or disconnected.

My question: Does identical read behavior with and without the external antenna connected indicate that the RF stage is not routing signal through the U.FL port — specifically, could this indicate that the R3/R4 routing resistor is on R3 (internal PCB antenna) rather than R4 (U.FL external antenna)?

The R3→R4 mod was performed previously and the board was confirmed working. However given the identical antenna-connected vs antenna-disconnected behavior, I want to confirm whether this symptom is consistent with the resistor being on R3.

IMG_7865
IMG_78651920×3413 1010 KB

2

You’re on the right track, except the relevant areas are R4 (on-board) and R5 (u.FL)…it’s not reading with the on-board antenna either though, so it doesn’t indicate the default position(R4) but rather that neither the R4 nor R5 paths are working

image
image652×688 32 KB

The resistor in your photo is roughly in the correct spot, but it does look like a cold solder joint that might benefit from de-soldering and re-soldering. The resistor is just a 0-ohm unit, you can replace it with plain wire & solder if need be

The other thing it could be is if your new coax isn’t Reverse Polarity (RP)…is it? It should also be a 50-0hm cable/antenna route. Also check the new cable for continuity (both inner and outer) to ensure it isn’t the problem

3

Hello, had AI summerize where I’m at:

TODAY'S ACTIONS (June 30):

1. Replaced capacitor (between antenna and wire bridge) with identical value — no change in behavior

2. De-soldered and re-soldered R4 resistor per SparkFun guidance — no change in behavior

3. Verified cable is correct RP spec (Times-7 CA240-PE, RP-TNC connectors)

4. Confirmed DC continuity end-to-end: antenna → cable → pigtail → board

``

---

``

CURRENT BEHAVIOR (after re-solder):

- M7E responds to serial commands at 9600 baud

- All five setup commands (0x93, 0x97, 0x92, 0x91, 0x9A) return status 0x0000 (OK)

- 0x2F continuous read command fires correctly

- Returns 11,000+ bytes per 3-second scan

- **Every frame returns status 0x0100 (no tags found)**

- **Behavior identical whether external antenna is connected or disconnected**

- Internal PCB antenna: cannot read any fobs

- External antenna: zero reads despite correct hardware and connections

``

---

``

DIAGNOSTICS COMPLETED:

✅ Serial port functional (responds to commands)

✅ CRC algorithm correct (ThingMagic nibble CRC verified)

✅ Frame structure correct (FF [LEN] [OPCODE] [data] [CRC])

✅ All setup opcodes accepted by reader

✅ 0x2F read command fires and returns data frames

✅ DC continuity end-to-end (antenna chain to board)

✅ Hardware components correct specs (verified against documentation)

✅ Antenna physically undamaged

✅ Cable RP spec verified

✅ Solder joint re-done (R4)

✅ Capacitor replaced

``

---

``

INTERPRETATION:

The board is responding to serial commands, but RF transmit stage is not generating energy. All frames show 0x0100 status (no tags detected) regardless of antenna connection, indicating RF is either:

1. Not being generated at all

2. Not reaching the antenna paths (per SparkFun: "neither R4 nor R5 paths are working")

``

After hardware corrections (re-solder, capacitor replacement) and verification of correct cable specs and continuity, the issue appears to be at the RF generation stage within the M7E module itself.

``

---

``

REQUEST:

Given that neither R4 nor R5 antenna paths are functional per your previous response, and that all diagnostic steps have been completed:

- Is the M7E module defective (RF stage failure)?

- Is there a firmware setting or initialization command that could restore RF generation? I'd appreciate any direction you can give me. Thanks

4

Weird that it has Dc continuity but no output…Share an updated photo of the 0-ohm resistor at R5

5

photo attached

(attachments)

board.jpg
board.jpg2268×4032 1.76 MB

6

I’d try using some IPA and a nylon brush or cotton swabs to clean the blackened areas (especially clean the u.FL port, it seems to have some debris in there that may be causing issues)

7

There is one more aspect where I wonder about.

One the continuous reading (0x2f) has been sent you mention

- **Every frame returns status 0x0100 (no tags found)**

That is NOT the error I get nor would expect. In my tests I get 0x400

/**Reader was asked to find tags, but none were detected. */
#define TMR_ERROR_NO_TAGS_FOUND TMR_ERROR_CODE(0x400)

The 0x100 is defined as :

/**Invalid number of arguments */
#define TMR_ERROR_MSG_WRONG_NUMBER_OF_DATA TMR_ERROR_CODE(0x100)

Can you enable creating a trace file in your example and share?

Have you tried the Universal Reader Assistant (URA) on Windows ?

8

Hi,

Thanks for catching that — you were right, and it turned out to matter a lot.

``

I dug into the actual command bytes being sent for the continuous-read (0x2F) call and found the bug. My "no tags found" claim (0x0100) was wrong because the continuous-read command itself was malformed — one byte in the sub-command blob was incorrect. Comparing against your own SparkFun_UHF_RFID_Reader library (startReading() in SparkFun_UHF_RFID_Reader.cpp), the reference blob is:

``

00 00 01 22 00 00 05 07 22 10 00 1B 03 E8 01 FF

My code had byte 9 wrong — 0x1B instead of 0x10:

00 00 01 22 00 00 05 07 22 1B 00 1B 03 E8 01 FF

``

Once corrected, the reader immediately started returning proper status codes: 0x0 (success) on the 0x2F start command, and 0x400 (genuinely no tag found) on 0x22 sub-frames when no tag was in range — exactly matching your correction. So the "RF stage isn't generating energy" conclusion in my last email was based on a false signal. The protocol layer is now working correctly.

``

Separately, I also found the module was responding at 115200 baud, not the 9600 my script was configured for (it must have reverted to default after the earlier unresponsive/hung episode). Fixed that too.

``

CURRENT STATE (with both bugs fixed):

With the external antenna connected and 12 test tags placed throughout the cabinet — one in each extreme corner, halfway points, and center — only ONE tag reads, consistently, across repeated scans:

``

EPC 30340476F44600D61E81D922 — reads at -63 to -66 dBm across multiple 15-second scans, 100% reproducible.

``

The other 11 tags, spread across the rest of the cabinet, never read at all, in any run.

``

Trace file from a full 15-second scan (all setup commands, start command, raw RX bytes, and parsed tag reads) is attached below.

``

1. Given clean protocol behavior now (correct status codes, no framing errors), does a single consistent -63 to -66 dBm read with everything else silent look like an antenna/RF gain or positioning issue rather than a module problem?

2. Any recommended power/gain settings beyond max (27.00 dBm, which we're already using) worth trying?

``

Re: Universal Reader Assistant — I don't have Windows access (Mac only), so I'm not able to run URA. Happy to provide any additional serial traces you need instead.

``

=== TRACE FILE ===

=== M7E Trace — 2026-07-02 06:38:19 ===

Baud: 115200

TX [Set Gen2 protocol] 0x93: FF02930005517D

RX [Set Gen2 protocol]: FF00930000371A

TX [Set region NA] 0x97: FF0197014BBC

RX [Set region NA]: FF00970000779E

TX [Set power 27.00dBm] 0x92: FF02920A8C4BD5

RX [Set power 27.00dBm]: FF00920000273B

TX [Set antenna port 1] 0x91: FF02910101703B

RX [Set antenna port 1]: FF009100001758

TX [Set filter/config] 0x9A: FF039A010C00A35D

RX [Set filter/config]: FF009A0000A633

TX [Start continuous read]: FF102F00000122000005072210001B03E801FFDD2B

--- Scanning 15 seconds, 12 tags placed at all cabinet extremes + center ---

RX total bytes: 250

RX raw hex: FF042F0000012200006DC3FF0022040084E0FF0022040084E0FF0022040084E0FF2822000010001B01FF0101C0110E2612000000790034050000000080300030340476F44600D61E81D9227C7D11ABFF0022040084E0FF2822000010001B01FF0101BF110E241E000002970004050000000080300030340476F44600D61E81D9227C7DBE47FF0022040084E0FF0022040084E0FF0022040084E0FF0022040084E0FF0022040084E0FF0022040084E0FF0022040084E0FF0022040084E0FF2822000010001B01FF0101C0110E2612000002490022050000000080300030340476F44600D61E81D9227C7D7D8CFF0022040084E0FF0022040084E0

Parsed tag reads: 3

EPC 30340476F44600D61E81D922: -64 dBm

EPC 30340476F44600D61E81D922: -65 dBm

EPC 30340476F44600D61E81D922: -64 dBm

``

Thanks again for the correction — it pointed us straight at the real bug.

9

First of all great to hear the progress. Indeed the read options that were enabled with setting 0x1B instead of 0x10 do not make sense:

Select options: 0x1b
TMR_SR_GEN2_SINGULATION_OPTION_FLAG_METADATA
TMR_SR_GEN2_SINGULATION_OPTION_INVERSE_SELECT_BIT
TMR_SR_GEN2_SINGULATION_OPTION_SELECT_ON_EPC
TMR_SR_GEN2_SINGULATION_OPTION_SELECT_ON_TID
Start location (bits) 1770472, (bytes) 221309
Maskbit length (bits) 1, (bytes) 0

The M7E will read the first TAG that responds strongest. Hence you get the same EPC. To help on that issue there are GEN2 option to instruct the TAG to either not to respond (if already responded during the current read cycle) and/or instruct the reader to perform a different inventory selection.

These GEN2 options are part of the larger Mercury API, (which can be downloaded and used on a Raspberry PI) but not implemented by Sparkfun in their library. I have spend a lot of time on the Sparkfun library have added many calls/options. You can find that on ThingMagic/Arduino_lib_special at master · paulvha/ThingMagic · GitHub . This also includes the calls for GEN2 options like setGen2Session(), setGen2RFmode(), setGen2RFTarget(), setGen2Encoding(), setGen2Q()