Improve Heltec v4 RX reception with undocumented register patch

[Socalix]

Following several rounds of testing Heltec v4 RX reception as part of PR #1249 I found out that the best solution was using the original v1.11.0 code, with undocumented register 0x8B5 patch (setting LSB=1) as desribed by @Quency-D (Heltec engineer) here: #1249 (comment) and without the RX Boosted Gain feature.

This PR is doing just that: turning on the 0x8B5 LSB and turning off RX Boosted Gain flag.

UPDATE: After several rounds of testing here we determined that Boosted Gain flag should be turned on/off on a case-by-case basis, so this PR is now updated to only set the register value that has proven to consistently improve RX.

=== Additional Details ===

Test Process:
I put RAK4631 and Heltec v4, both with Alfa 915 antenna and repeater v1.11.0 firmware in the same location (attic, about 7 inches apart). I then took Heltec T114 with companion v1.11.0 about 1.25km (0.75mile) away and did ping every 3 seconds to the same repeater about 20-30 times. I then flashed the v4 with different firmwares and pinged again.

Test Sample:

RAK4631 v1.11.0	Heltec v4 PR1249 w/o RegPatch	Heltec v4 PR1249 w/RegPatch	Heltec v4 PR1398 w/RegPatch and no Boosted Gain
-4.25	err	4.75	5.5
err	err	err	6.25
-2.75	err	2.75	err
3.75	3.5	err	4.25
1.75	5.5	2.0	5.5
3.0	err	6.0	4.75
err	err	err	1.25
1.75	4.75	err	7.75
4.0	3.25	-0.25	err
4.75	3.0	1.75	2.5
-7.5	4.25	5.0	2.0
6.75	4.25	2.25	err
err	err	err	5.5
6.25	err	4.0	0.25
3.75	err	-0.75	err
20% err	55% err	33% err	25% err

[Socalix]

UPDATE (2026-01-31) - v1.12.0 Repeater builds with Display Off:
Same builds as before, but with the display turned off as a quick solution to lower power consumption.

heltec_v4_repeater-1.12.0-pr1398-no_display-builds.zip

UPDATE (2026-01-29) - v1.12.0 Repeater builds:

heltec_v4_repeater-1.12.0-pr1398-builds.zip

pr1398-boost_on - Standard build without any extra flags (Boosted Gain on)
pr1398-boost_off - Standard build and Boosted Gain off
pr1398-boost_on-packetlog - Build with MESH_PACKET_LOGGING on and Boosted Gain on
pr1398-boost_off-packetlog - Build with MESH_PACKET_LOGGING on and Boosted Gain off

---

[OLD UPDATE] (2026-01-22) - v1.11.0 Repeater builds:
heltec_v4_repeater-1.11.0-pr1398-builds2.zip

pr1398-boost_on - Standard build without any extra flags (Boosted Gain on)
pr1398-boost_off - Standard build and Boosted Gain off
pr1398-boost_on-packetlog - Build with MESH_PACKET_LOGGING on and Boosted Gain on
pr1398-boost_off-packetlog - Build with MESH_PACKET_LOGGING on and Boosted Gain off

[OLD BUILDS] Repeater builds for testing:
pr1398 - Standard build - without any extra flags
pr1398-debug - Debug build - with USB_MODE, USB_CDC, MESH_DEBUG, MESH_PACKET_LOGGING flags
pr1398-packetlog - Standard build with MESH_PACKET_LOGGING flag only
pr1398-boost-packetlog - Standard build with RX_BOOSTED_GAIN and MESH_PACKET_LOGGING flags

[spiralshapeturtle]

@Socalix thanks for this spinoff. It would get more traction if you embed the table from your last post in the other PR with the results.

Would you do me a favor for the letsmesh MQTT output the debugging should be off to keep my RS232 stable.

Could you build a set with this flag only?

I love to test the files.

Build firmware with the -D MESH_PACKET_LOGGING=1 flag enabled using PLATFORMIO_BUILD_FLAGS.

PS: I have a cavity I could test with the RX boosted gain also. But not want to mesh up your PR. Let me know.

[olanwe]

I guess that this patch can also be applied to the Heltec Tracker v2.

[weebl2000]

I guess that this patch can also be applied to the Heltec Tracker v2.

See also this branch: https://github.com/weebl2000/MeshCore/tree/semtech_patch - I've added it for Heltec Tracker v2 there.

I'm not sure about the boosted gain=0. For me it seems boosted gain still improves reception.

[Socalix]

@Socalix thanks for this spinoff. It would get more traction if you embed the table from your last post in the other PR with the results.

Good idea. PR summary updated with testing information.

Would you do me a favor for the letsmesh MQTT output the debugging should be off to keep my RS232 stable.
Build firmware with the -D MESH_PACKET_LOGGING=1 flag enabled using PLATFORMIO_BUILD_FLAGS.
PS: I have a cavity I could test with the RX boosted gain also. But not want to mesh up your PR. Let me know.

Updated the zip file above with a new "pr1398-packetlog" and "pr1398-boost-packetlog" builds.

[Socalix]

I guess that this patch can also be applied to the Heltec Tracker v2.

Yes, you can simply add -D SX126X_REGISTER_PATCH=1 flag and comment out SX126X_RX_BOOSTED_GAIN in the heltec_tracket_v2/platformio.ini file to turn it on.
I don't have Tracker v2, so I cannot test it myself.

[spiralshapeturtle]

@Socalix thanks for this spinoff. It would get more traction if you embed the table from your last post in the other PR with the results.

Good idea. PR summary updated with testing information.

Would you do me a favor for the letsmesh MQTT output the debugging should be off to keep my RS232 stable.
Build firmware with the -D MESH_PACKET_LOGGING=1 flag enabled using PLATFORMIO_BUILD_FLAGS.
PS: I have a cavity I could test with the RX boosted gain also. But not want to mesh up your PR. Let me know.

Updated the zip file above with a new "pr1398-packetlog" and "pr1398-boost-packetlog" builds.

Thanks my second V4 arrived today going to test on the similar antennas.

[excalq]

Thanks for this fix! I've been tying to get my v4 node connected to the area mesh, and though I could TX fine (packets seen on analyze.letsmesh.net), I rarely was getting responses. Tried 5 different antennas. This branches firmware seemed to have solved all the issues for me.

[spiralshapeturtle]

@Socalix

It's quite difficult to test here because the mesh network is so busy that the ping test you performed isn't possible at my location. There are too many transmissions which could interfere with pings from other locations. Both units are running quite stable, though one of them has a 2% higher RX (receive) level. I'll swap the antennas tonight (by changing the pigtail cables) to see if the 2% increase is related to the unit itself or the antenna.

Any other tips for testing are welcome.
1.11.0-pr1398-boost-packetlog-4575800 (Build: 15-Jan-2026)

1.11.0-pr1398-packetlog-4575800 (Build: 15-Jan-2026)

[Socalix]

It's quite difficult to test here because the mesh network is so busy that the ping test you performed isn't possible at my location. There are too many transmissions which could interfere with pings from other locations.

@spiralshapeturtle Thank you for testing! Yep, I'm "lucky" to be the only one running Meshcore around me.. :)
You may try a different frequency that may be less busy in your area. It's a bit tough in EU because there's not much bandwidth available, but if you're on 869.618 Mhz right now, maybe try 869.432 Mhz ?

Both units are running quite stable, though one of them has a 2% higher RX (receive) level. I'll swap the antennas tonight (by changing the pigtail cables) to see if the 2% increase is related to the unit itself or the antenna.

Looks like the one without the RX Boosted Gain has around 3db lower noise floor, which could translate to 2% more lower-signal packets getting picked up. Of course can also be antenna and location related, so switching things around will be interesting.

Since you have 6% TX, I wonder if having both repeaters running next to each other at the same time means that we're seeing them helping each other get more packets? i.e. only one repeater hears the original packet and the other repeater hears the packet from the first one repeating it, so the RX % will be similar.
It'd be interesting to see the RX % if you disable the repeaters "repeat mode" settings.

[spiralshapeturtle]

@Socalix test without TX mode.
Firmware: 1.11.0-pr1398-packetlog-4575800 (Build: 15-Jan-2026)

Firmware: 1.11.0-pr1398-boost-packetlog-4575800 (Build: 15-Jan-2026)

Well I have run them without TX for a while and I put the SNR/RSSI values into claude.ai. Below the summary which I can reuse upcoming week after swapping the pigtails today. Im only swapping the IPX connector on the boards and keep everything the same. As stated earlier I have to different antennas so that could still be a factor to mitigate by swapping the connectors.

WARNING below is an AI generated summary.

# MeshCore Transceiver Comparison

## Utrecht Node
**Distance:** boost-packetlog: 13.69 km | packetlog: 13.64 km

| Firmware | Time Ago | SNR  | RSSI    | Score |
|----------|----------|------|---------|-------|
| boost-packetlog | 1h ago | 0dB | -74dBm | 579 |
| boost-packetlog | 2h ago | 4dB | -75dBm | 795 |
| boost-packetlog | 3h ago | 5dB | -74dBm | 822 |
| packetlog | 1h ago | 3dB | -79dBm | 741 |
| packetlog | 2h ago | 6dB | -78dBm | 902 |
| packetlog | 3h ago | 6dB | -77dBm | 902 |

**Winner: packetlog** - Higher SNR (6dB vs 5dB best), better scores (902 vs 822 peak)

---

## Repeater PA5B Houten
**Distance:** 7.25 km (Only visible on packetlog)

| Firmware | Time Ago | SNR   | RSSI    | Score |
|----------|----------|-------|---------|-------|
| boost-packetlog | - | - | - | - |
| packetlog | 1h ago | -1dB | -90dBm | 439 |
| packetlog | 3h ago | -3dB | -89dBm | 317 |
| packetlog | 4h ago | -4dB | -89dBm | 256 |

**Winner: packetlog** - Only firmware that can reach this node

---

## Radome West
**Distance:** boost-packetlog: 4.06 km | packetlog: 3.93 km

| Firmware | Time Ago | SNR  | RSSI    | Score |
|----------|----------|------|---------|-------|
| boost-packetlog | 3h ago | 3dB | -71dBm | 719 |
| packetlog | 4h ago | 6dB | -73dBm | 837 |

**Winner: packetlog** - Better SNR (6dB vs 3dB), higher score (837 vs 719)

---

## Zeist Sanatoriumbos
**Distance:** boost-packetlog: 2.66 km | packetlog: 2.62 km

| Firmware | Time Ago | SNR   | RSSI    | Score |
|----------|----------|-------|---------|-------|
| boost-packetlog | 7h ago | -4dB | -94dBm | 270 |
| packetlog | 8h ago | -9dB | -97dBm | 36 |

**Winner: boost-packetlog** - Much better SNR (-4dB vs -9dB), significantly higher score (270 vs 36)

---

## Overall Performance Summary

| Metric | boost-packetlog | packetlog |
|--------|-----------------|-----------|
| **Nodes Reached** | 3 | 4 |
| **Best SNR** | 5dB (Utrecht) | 6dB (Utrecht, Radome West) |
| **Best Score** | 822 (Utrecht) | 902 (Utrecht) |
| **Worst Score** | 270 (Zeist) | 36 (Zeist) |
| **Average Score** | 648 | 597 |

## Key Observations

- **packetlog firmware** has better reach (4 nodes vs 3) and can connect to the PA5B Houten repeater
- **packetlog firmware** performs significantly better on distant nodes (Utrecht, Radome West) with superior SNR
- **boost-packetlog firmware** handles the closest node (Zeist Sanatoriumbos) much better - 7.5x higher score
- **packetlog firmware** shows more consistent high scores on medium-to-long range links
- **boost-packetlog firmware** may have better near-field rejection or less sensitivity to local interference
- Both firmwares struggle with Zeist Sanatoriumbos despite it being the closest node (possible obstruction or antenna issue)

## Recommendation

**Use packetlog firmware for general meshing** - Superior long-range performance (better SNR on distant nodes) and reaches more nodes including the PA5B Houten repeater. The "boost" variant doesn't appear to provide range advantages and actually performs worse on most metrics except the problematic nearest node.

**Note:** The "boost" in boost-packetlog firmware doesn't translate to better range or scores. Consider investigating if boost settings are causing near-field saturation or gain compression.

[towerviewcams]

Here is a big question and I'm hoping someone can help. How can we use this running Powersaving10 firmware so that we can turn off the LNA pre-amp at noisy tower sites. This would be a game changer. But we cant use the standard 1.11 firm as it draws to much power. suggestions ?

1/19/2026 update - its there already...... "powersaving on" and your set

[Socalix]

Well I have run them without TX for a while and I put the SNR/RSSI values into claude.ai. Below the summary which I can reuse upcoming week after swapping the pigtails today. Im only swapping the IPX connector on the boards and keep everything the same. As stated earlier I have to different antennas so that could still be a factor to mitigate by swapping the connectors.

WARNING below is an AI generated summary.
Use packetlog firmware for general meshing - Superior long-range performance (better SNR on distant nodes) and reaches more nodes including the PA5B Houten repeater. The "boost" variant doesn't appear to provide range advantages and actually performs worse on most metrics except the problematic nearest node.

These tests are great! The difference of 20% RX with Boosted Gain and 25% without boost I believe confirms that TX enabled in the prior test let the repeaters "help" each other hear packets, so definitely TX disabled is the right way to test. Also 5% difference by itself may not sound much, but it's 25% better RX over the one with boosted gain.

I also agree with the AI summary as it matches my previous tests - boosted gain is reducing the node's ability to hear some packets and causes the SNR overall to be lower.

After you complete the test with flipped antennas, it would be great if you don't mind running one more test - pr1398-packetlog vs standard v1.11.0 so that we can see the RX difference there.

[Socalix]

Here is a big question and I'm hoping someone can help. How can we use this running Powersaving10 firmware so that we can turn off the LNA pre-amp at noisy tower sites. This would be a game changer. But we cant use the standard 1.11 firm as it draws to much power. suggestions ?

This PR fix includes 2 things:

1. Register patch - which I do not expect to change power consumption.
2. Turning off Boosted Gain feature - which I would expect to lower power consumption a little.
   Unfortunately, I do not have the means to test and measure this right now. You could apply the same fix to the Power-saving version and test.

[towerviewcams]

Here is a big question and I'm hoping someone can help. How can we use this running Powersaving10 firmware so that we can turn off the LNA pre-amp at noisy tower sites. This would be a game changer. But we cant use the standard 1.11 firm as it draws to much power. suggestions ?

This PR fix includes 2 things:

1. Register patch - which I do not expect to change power consumption.
2. Turning off Boosted Gain feature - which I would expect to lower power consumption a little.
   Unfortunately, I do not have the means to test and measure this right now. You could apply the same fix to the Power-saving version and test.

I have the test equipment to test this but my knowledge on how to modify the code is where Iack. Is this a command line entry? what do i download and how how do I bring it up and I'll find the rest.

So I have the powersaving10 file and what to do from there?

[spiralshapeturtle]

Here is a big question and I'm hoping someone can help. How can we use this running Powersaving10 firmware so that we can turn off the LNA pre-amp at noisy tower sites. This would be a game changer. But we cant use the standard 1.11 firm as it draws to much power. suggestions ?

I don't know how it works with the file and coding, but I can tell you that on my V4 I can use the "powersaving on|off" command. So it might come with the nightly builds where the power saving is already included for the v1.12.0 release.

Just type "powersaving on"

For the record my tests are done without powersaving enabled.

[tpp-at-idx]

Hello guys, I was doing some tests on #1249 and while i was on it I also tried this PR. Here is a crosspost from the findings

Hello guys
I've run some tests as promised
Thease are all based on the BLE companion firmware. With one reference node in a good RF environment, out of the window, which is persumed to receive all messages, and with the testing node being a V4 placed in my "rf hellhole" ( noisy monitors, PC's, noise floor about -70 to -75 ).
The test was to receive ~ 300 messages on the reference node and then compare how many messages were lost on the tested node. Take this with a grain of salt, I've tried to make it as scientific as possible but the methodology may be flawed upon factors i can not really control and it is all i could do with my limited resources

Stock firmware: Reference: 296 messages, V4 received: 284, loss: 4 %
TXRX lna patch: Reference: 239 messages, V4 received: 229, loss: 4,1 %
Semtech only patch : Reference: 307 messages, V4 received: 302, loss: 1,6 %
RXgain off +semtech patch ( #1398 ) : Reference: 266, V4 received: 252, loss: 5,2 %

[spiralshapeturtle]

@Socalix I only swapped the antenna IPX connector and now 24 hours later the result is as follow. AI summarized the data.

Firmware: 1.11.0-pr1398-boost-packetlog-4575800 (Build: 15-Jan-2026) Firmware: 1.11.0-pr1398-packetlog-4575800 (Build: 15-Jan-2026)

PA5B Houten repeater is quite far away from me and that seems to be the differentiator, more on that at the bottom.

# MeshCore Firmware Comparison: boost-packetlog vs packetlog

## Test Setup

**Hardware:** Two identical transceivers with same coax length, roof-mounted 2 types of antennas  
**Test Method:** Antenna swap to isolate firmware differences from antenna performance

| Device | Firmware Version | Current Antenna |
|--------|-----------------|-----------------|
| V4_2 | 1.11.0-pr1398-boost-packetlog-4575800 | Without tape |
| V4 | 1.11.0-pr1398-packetlog-4575800 | With tape |

---

## Node Statistics - V4_2 (boost-packetlog)

### Utrecht
**Distance:** 13.69 km (8.50 mi)

| Time Ago | SNR  | RSSI    | Score |
|----------|------|---------|-------|
| 1h ago   | 4dB  | -77dBm  | 696   |
| 3h ago   | 2dB  | -80dBm  | 612   |
| 5h ago   | 3dB  | -78dBm  | 636   |

### Radome West
**Distance:** 4.06 km (2.52 mi)

| Time Ago | SNR  | RSSI    | Score |
|----------|------|---------|-------|
| 4h ago   | 8dB  | -73dBm  | 955   |
| 16h ago  | 5dB  | -74dBm  | 824   |
| 1d ago   | 3dB  | -71dBm  | 719   |

### Zeist Slot
**Distance:** 0.91 km (0.56 mi)

| Time Ago | SNR  | RSSI    | Score |
|----------|------|---------|-------|
| 35m ago  | 1dB  | -73dBm  | 593   |
| 12h ago  | 2dB  | -78dBm  | 672   |

### loramesh.nl
**Distance:** 8.02 km (4.98 mi)

| Time Ago | SNR   | RSSI    | Score |
|----------|-------|---------|-------|
| 3h ago   | -1dB  | -85dBm  | 458   |

### Zeist Sanatoriumbos
**Distance:** 2.66 km (1.65 mi)

| Time Ago | SNR   | RSSI    | Score |
|----------|-------|---------|-------|
| 1d ago   | -4dB  | -94dBm  | 270   |

---

## Node Statistics - V4 (packetlog)

### Utrecht
**Distance:** 13.64 km (8.48 mi)

| Time Ago | SNR  | RSSI    | Score |
|----------|------|---------|-------|
| 3h ago   | 0dB  | -75dBm  | 516   |
| 5h ago   | 1dB  | -74dBm  | 540   |
| 7h ago   | 2dB  | -74dBm  | 600   |

### Repeater PA5B Houten
**Distance:** 7.25 km (4.51 mi)

| Time Ago | SNR   | RSSI    | Score |
|----------|-------|---------|-------|
| 8h ago   | -1dB  | -86dBm  | 415   |
| 12h ago  | -1dB  | -86dBm  | 415   |
| 1d ago   | -1dB  | -90dBm  | 439   |

### Radome West
**Distance:** 3.93 km (2.44 mi)

| Time Ago | SNR   | RSSI    | Score |
|----------|-------|---------|-------|
| 4h ago   | 4dB   | -74dBm  | 758   |
| 16h ago  | -2dB  | -72dBm  | 418   |
| 1d ago   | 6dB   | -73dBm  | 837   |

### Zeist Sanatoriumbos
**Distance:** 2.62 km (1.63 mi)

| Time Ago | SNR   | RSSI    | Score |
|----------|-------|---------|-------|
| 1d ago   | -9dB  | -97dBm  | 36    |

---
`



`
## Firmware Comparison (Recent 8-Hour Window)

| Node | Distance | boost-packetlog | packetlog | Winner |
|------|----------|-----------------|-----------|--------|
| **Utrecht** | ~13.6 km | 4dB / -77dBm / **696** | 0dB / -75dBm / 516 | boost (+35%) |
| **Radome West** | ~4.0 km | 8dB / -73dBm / **955** | 4dB / -74dBm / 758 | boost (+26%) |
| **PA5B Houten** | 7.25 km | ❌ Not seen | -1dB / -86dBm / 415 | packetlog (only) |
| **loramesh.nl** | 8.02 km | -1dB / -85dBm / 458 | ❌ Not seen | boost (only) |
| **Zeist Slot** | 0.91 km | 1dB / -73dBm / 593 | ❌ Not seen | boost (only) |

---

## Performance Metrics Summary

| Metric | boost-packetlog (V4_2) | packetlog (V4) |
|--------|------------------------|----------------|
| **Peak Score** | 955 (Radome West) | 758 (Radome West) |
| **Best SNR** | 8dB (Radome West) | 6dB (Radome West, old data) |
| **Nodes Reached** | 5 unique nodes | 4 unique nodes |
| **Best RSSI** | -71dBm | -72dBm |
| **Average Score (top 3)** | 749 | 631 |

---

## Key Observations

### 1. **Score Performance**
- boost-packetlog consistently achieves **20-35% higher scores** on shared nodes
- Utrecht: 696 vs 516 (+35%)
- Radome West: 955 vs 758 (+26%)

### 2. **SNR Quality**
- boost-packetlog shows **superior noise rejection**
- Peak SNR: 8dB vs 6dB (+2dB improvement)
- Better SNR even at similar RSSI levels (-77dBm vs -75dBm on Utrecht)

### 3. **Node Discovery**
- **boost-packetlog** sees more local nodes (Zeist Slot, loramesh.nl)
- **packetlog** sees the PA5B Houten repeater (boost does not)
- Different packet filtering/decoding strategies

### 4. **Range Performance**
- Both reach Utrecht at ~13.6 km
- boost-packetlog maintains better link quality at distance
- Similar sensitivity (-77dBm vs -75dBm best RSSI)

### 5. **Repeater Compatibility**
- **Critical difference:** Only packetlog firmware can decode the PA5B Houten repeater
- Repeater has marginal SNR (-1dB) which boost firmware may reject
- Suggests more permissive decoding in packetlog

---

## Technical Analysis

### boost-packetlog Characteristics:
- ✅ Superior noise floor management (higher SNR)
- ✅ Better score calculation algorithm
- ✅ Excellent near-field performance (0.91 km node)
- ✅ More aggressive gain settings
- ❌ Stricter packet filtering (misses marginal repeater)
- ❌ May reject valid but noisy packets

### packetlog Characteristics:
- ✅ More permissive packet decoding
- ✅ Better repeater compatibility
- ✅ Decodes packets with negative SNR (-1dB)
- ✅ Maximum mesh connectivity
- ❌ Lower overall scores
- ❌ Misses some local nodes

---

## Antenna vs Firmware - Critical Finding

**After antenna swap, performance patterns remained identical:**
- boost-packetlog still achieves higher scores on same nodes
- packetlog still sees PA5B Houten repeater
- Same node visibility patterns persist

**Conclusion:** Performance differences are **firmware-based, not antenna-based**. The antenna swap test confirms that the "boost" and standard firmware builds have fundamentally different radio characteristics.

---

## Conclusion

The firmware comparison reveals **significant algorithmic differences** between boost-packetlog and standard packetlog builds:

1. **boost-packetlog** delivers 20-35% higher scores and 2dB better SNR on shared nodes
2. **packetlog** provides better mesh network compatibility by accepting marginal packets
3. The "boost" variant is **not just a power adjustment** - it implements different signal processing
4. Neither firmware is strictly "better" - they serve different network architectures

**Final Verdict:** For standalone/gateway use, boost-packetlog is superior. For mesh networks with repeaters, standard packetlog is essential. The optimal solution is running both firmwares on separate devices to leverage the strengths of each.

**Hardware confirmation:** Antenna swap test proves these differences are purely firmware-based, not hardware-dependent.

I asked AI again about the far away repeater, arround 2 PM I changed the antenna cable where you can see the load rising and lowering, so the antenna with the tape label is better.

Yesterday the (better) antenna with the tape label was on this node:
Firmware: 1.11.0-pr1398-packetlog-4575800 (Build: 15-Jan-2026)
V4 antenne met tape

This 24hours I swaped the (better) tape labeled antenna to this node
Firmware: 1.11.0-pr1398-boost-packetlog-4575800 (Build: 15-Jan-2026)
V4_2

# PA5B Houten Repeater - Detection Analysis

## Detection History

| Date | Firmware | Device | Detected? | Best Stats |
|------|----------|--------|-----------|------------|
| **Yesterday** | packetlog | V4 | ✅ YES | -1dB / -90dBm / 439 |
| **Yesterday** | boost-packetlog | V4_2 | ❌ NO | - |
| **Today** | packetlog | V4 | ✅ YES | -1dB / -86dBm / 415 |
| **Today** | boost-packetlog | V4_2 | ❌ NO | - |

---

## Key Finding

**PA5B Houten repeater (7.25 km) is ONLY visible on packetlog firmware**

### Yesterday's Configuration:
- **V4_2** (boost-packetlog) had antenna **with tape** → Did NOT see repeater
- **V4** (packetlog) had antenna **without tape** → SAW repeater

### Today's Configuration (after antenna swap):
- **V4_2** (boost-packetlog) now has antenna **without tape** → Still does NOT see repeater
- **V4** (packetlog) now has antenna **with tape** → Still SEES repeater

---

## Conclusion

🎯 **The PA5B Houten repeater detection is 100% firmware-dependent, NOT antenna-dependent**

### Evidence:
1. **Consistent across antenna swap** - packetlog sees it regardless of which antenna
2. **Never seen by boost-packetlog** - even with the "better" antenna (without tape)
3. **Marginal signal quality** - Repeater operates at -1dB SNR, which boost firmware likely rejects
4. **RSSI improvement** - Today's measurement shows -86dBm vs yesterday's -90dBm (4dB better with "worse" antenna), proving firmware decoding difference

### Technical Explanation:
- PA5B Houten has **marginal SNR (-1dB)** 
- **boost-packetlog** firmware has stricter packet acceptance threshold
- **packetlog** firmware accepts packets with negative SNR
- This is a **decoding strategy difference**, not a sensitivity difference

**Answer:** Only **packetlog firmware** saw the PA5B Houten repeater, both yesterday AND today, regardless of antenna configuration.

[weebl2000]

@spiralshapeturtle Can you also clarify which changes the boost-packetlog and packetlog firmwares contain?

boost-packetlog -> is this boosted_gain=0 and the register fix?

[spiralshapeturtle]

@spiralshapeturtle Can you also clarify which changes the boost-packetlog and packetlog firmwares contain?

boost-packetlog -> is this boosted_gain=0 and the register fix?

#1398 (comment) i just copied this, the only thing I know.

[Socalix]

@spiralshapeturtle Can you also clarify which changes the boost-packetlog and packetlog firmwares contain?

boost-packetlog -> is this boosted_gain=0 and the register fix?

packetlog = this PR which means register patch and NO boosted gain flag turned on.
boost-packetlog = register patch WITH boosted gain flag turned on.

[Socalix]

Hello guys I've run some tests as promised Thease are all based on the BLE companion firmware. With one reference node in a good RF environment, out of the window, which is persumed to receive all messages, and with the testing node being a V4 placed in my "rf hellhole" ( noisy monitors, PC's, noise floor about -70 to -75 ). The test was to receive ~ 300 messages on the reference node and then compare how many messages were lost on the tested node. Take this with a grain of salt, I've tried to make it as scientific as possible but the methodology may be flawed upon factors i can not really control and it is all i could do with my limited resources

Thanks for testing! This is an interesting test and results. What antennas are you using on these nodes?
I'm also wondering if it's possible for you to test with both antennas in the same area (in/out window) several inches apart? Also, if you could put on one node Boosted gain off and one Boosted gain on for comparison?

[Socalix]

@Socalix I only swapped the antenna IPX connector and now 24 hours later the result is as follow. AI summarized the data.
I asked AI again about the far away repeater, arround 2 PM I changed the antenna cable where you can see the load rising and lowering, so the antenna with the tape label is better.

I think the AI summary is a bit confusing today, but if I understand the letsmesh graphs correctly - what we see today is that antenna choice has a bigger impact on RX % than boosted gain flag. We still see the same 20% RX vs 25% RX on the same antennas regardless of the boosted gain. Correct?

[tpp-at-idx]

Thanks for testing! This is an interesting test and results. What antennas are you using on these nodes? I'm also wondering if it's possible for you to test with both antennas in the same area (in/out window) several inches apart? Also, if you could put on one node Boosted gain off and one Boosted gain on for comparison?

Antenna is: https://www.laskakit.cz/nicerf-sw868-zd210-antena-3dbi-21cm-868mhz/ ( on both nodes )

Also for the additional tests:
I will try to whip up a testcase for that ( both nodes side by side, one with rx_gain off, one with rx_gain on ) Will report in a few days. But I must note that the message count discrepancy is mostly visible in my "rf hellhole" that has a noise floor of -70 to -75, I live in a nicely covered area in the vincity of 5 superb repeaters who beam a constant +10 db my way, so, yeah. It really does not make any sence to put both tested nodes in the window ( and in that location the v4 sees a noise floor of -95 to -105 )

[spiralshapeturtle]

@Socalix I only swapped the antenna IPX connector and now 24 hours later the result is as follow. AI summarized the data.

I asked AI again about the far away repeater, arround 2 PM I changed the antenna cable where you can see the load rising and lowering, so the antenna with the tape label is better.

I think the AI summary is a bit confusing today, but if I understand the letsmesh graphs correctly - what we see today is that antenna choice has a bigger impact on RX % than boosted gain flag. We still see the same 20% RX vs 25% RX on the same antennas regardless of the boosted gain. Correct?

Correct! The packet increase is related to the better antenna.

But the interesting part is this see the distance table.

Edit: can copy it on mobile will do tonight.

Antenna Swap Test Results - Yesterday vs Today

Test Configuration

Day	V4_2 (boost-packetlog)	V4 (packetlog)
Yesterday	Better antenna	Standard antenna
Today	Standard antenna	Better antenna

Better antenna = Original antenna without tape
Standard antenna = Antenna with tape label

---

Complete Node Detection & Performance Comparison

Utrecht Node (~13.6 km)

Day	Firmware	Antenna	SNR	RSSI	Score	Change
Yesterday	boost-packetlog	Better	5dB	-74dBm	822	-
Today	boost-packetlog	Standard	4dB	-77dBm	696	⬇️ -15% score
Yesterday	packetlog	Standard	6dB	-77dBm	902	-
Today	packetlog	Better	0dB	-75dBm	516	⬇️ -43% score

Key Finding: Both firmwares show significant performance degradation with standard antenna

---

Radome West Node (~4.0 km)

Day	Firmware	Antenna	SNR	RSSI	Score	Change
Yesterday	boost-packetlog	Better	3dB	-71dBm	719	-
Today	boost-packetlog	Standard	8dB	-73dBm	955	⬆️ +33% score
Yesterday	packetlog	Standard	6dB	-73dBm	837	-
Today	packetlog	Better	4dB	-74dBm	758	⬇️ -9% score

Key Finding: Anomaly - boost-packetlog improved with standard antenna (likely temporal variation)

---

PA5B Houten Repeater (7.25 km)

Day	Firmware	Antenna	SNR	RSSI	Score	Detection
Yesterday	boost-packetlog	Better	-	-	-	❌ Not detected
Today	boost-packetlog	Standard	-	-	-	❌ Not detected
Yesterday	packetlog	Standard	-1dB	-90dBm	439	✅ Detected
Today	packetlog	Better	-1dB	-86dBm	415	✅ Detected

Key Finding: Only packetlog firmware detects this repeater, regardless of antenna

---

Zeist Slot (0.91 km) - Local Node

Day	Firmware	Antenna	SNR	RSSI	Score	Detection
Yesterday	boost-packetlog	Better	-	-	-	❓ No data
Today	boost-packetlog	Standard	1dB	-73dBm	593	✅ Detected
Yesterday	packetlog	Standard	-	-	-	❌ Not detected
Today	packetlog	Better	-	-	-	❌ Not detected

Key Finding: Only boost-packetlog detects this local node

---

loramesh.nl (8.02 km)

Day	Firmware	Antenna	SNR	RSSI	Score	Detection
Yesterday	boost-packetlog	Better	-	-	-	❓ No data
Today	boost-packetlog	Standard	-1dB	-85dBm	458	✅ Detected
Yesterday	packetlog	Standard	-	-	-	❌ Not detected
Today	packetlog	Better	-	-	-	❌ Not detected

Key Finding: Only boost-packetlog detects this node

---

Zeist Sanatoriumbos (2.66 km) - Problem Node

Day	Firmware	Antenna	SNR	RSSI	Score	Detection
Yesterday	boost-packetlog	Better	-4dB	-94dBm	270	✅ Detected
Today	boost-packetlog	Standard	-	-	-	❌ Not detected (1d old)
Yesterday	packetlog	Standard	-9dB	-97dBm	36	✅ Poor detection
Today	packetlog	Better	-	-	-	❌ Not detected (1d old)

Key Finding: Node has become unreachable for both setups today

---

Summary Statistics

Node Reach Comparison

Configuration	Nodes Detected	Unique Nodes	Total Observations
Yesterday - boost + Better antenna	3	Utrecht, Radome, Zeist Sanat	5 measurements
Today - boost + Standard antenna	4	Utrecht, Radome, Zeist Slot, loramesh	7 measurements
Yesterday - packetlog + Standard antenna	4	Utrecht, PA5B, Radome, Zeist Sanat	7 measurements
Today - packetlog + Better antenna	3	Utrecht, PA5B, Radome	6 measurements

---

Performance Changes After Antenna Swap

V4_2 (boost-packetlog): Better → Standard Antenna

Node	Yesterday Score	Today Score	Change
Utrecht	822	696	⬇️ -15%
Radome West	719	955	⬆️ +33% (anomaly)
Zeist Sanatoriumbos	270	-	Lost contact
Zeist Slot	-	593	🆕 New detection
loramesh.nl	-	458	🆕 New detection

Net Result: +2 nodes, -1 node, mixed performance

---

V4 (packetlog): Standard → Better Antenna

Node	Yesterday Score	Today Score	Change
Utrecht	902	516	⬇️ -43%
Radome West	837	758	⬇️ -9%
PA5B Houten	439	415	⬇️ -5%
Zeist Sanatoriumbos	36	-	Lost contact

Net Result: No new nodes, significant score decreases

---

Critical Observations

1. Antenna Performance is Complex

The "better antenna" shows:

• ✅ Higher peak scores on some nodes (Utrecht: 902 vs 516)
• ✅ Better RSSI on PA5B Houten (-86dBm vs -90dBm)
• ❌ Lower scores when swapped to boost firmware
• ❌ Lost Zeist Sanatoriumbos contact

2. Firmware Dominates Results

Finding	Evidence
PA5B Houten detection	Only packetlog, both antennas
Zeist Slot detection	Only boost-packetlog, both antennas
loramesh.nl detection	Only boost-packetlog, both antennas
Score patterns	Firmware-specific, persist across swap

3. Temporal Variations Matter

• Radome West improved 33% despite "worse" antenna (likely weather/propagation)
• Zeist Sanatoriumbos went offline on both setups (node issue, not antenna)
• Time of day affects measurements significantly

---

V4 (packetlog) with Better antenna achieved the highest single score (902) and best SNR (6dB), making it the optimal choice for long-range mesh networking.

boost-packetlog excels at discovering local nodes but benefits less from the better antenna, suggesting its signal processing is optimized differently.

[spiralshapeturtle]

@Socalix which one should I flash with the regular firmware?

[spiralshapeturtle]

After you complete the test with flipped antennas, it would be great if you don't mind running one more test - pr1398-packetlog vs standard v1.11.0 so that we can see the RX difference there.

Yes did that! So packetlog v.s. standard is running now, where standard is on the better antenna and should get the same percentage RX.

[towerviewcams]

Just tested both the PR1398 packetlog and the PR1398 Boost Packetlog and both support Powersaving! This is amazing - I did not see this mentioned! it works!

To confirm, the PR1398-packetlog has the LNA (17db pre amp) DISABLED. Is this correct?
both firms have the Register Patch for the LSB=1.....Is this correct?

[1337Reaper]

@Socalix @spiralshapeturtle There is a BIG problem with the new 1.12 with the ESP32 powersaving that they say is there. I've tested 3, V4 boards and with powersaving on it draws 32.7mA. Something is wrong with the firmware code. I changed to powersaving 11.2 from OITthinks and it works correctly at 11.2mA

We need to get the word out that its not right.

Did you measure it from the USB port or the battery port?

[beachmiles]

Yep the new build uses a lot more power than the last with the "powersave on" enabled at least when powering from USB. Will try to test using the battery input next week.

In the previous build while powering the v4 over usb roughly,
.0348 watts in standby
.0355 maybe while receiving?
.210 when transmitting?
3 watt short blips randomly

In today's build 1/29/2026 that was synced with 1.12 also powered from USB I saw
.1877 watts in standby
.373 while transmitting?
3.56 watt short random blips that seem to happen more often than previous version

The 3+ watt blips may be the transmitting and the .21-.373W may be the receiving. Either way the previous version used way less power.

[1337Reaper]

Yep the new build uses a lot more power than the last with the "powersave on" enabled at least when powering from USB. Will try to test using the battery input next week.

In the previous build while powering the v4 over usb roughly,

.0348w in standby

.0355w maybe while receiving?

.210 watts when transmitting?

Short blip occasional up to 3 watts randomly

In today's build 1/29/2026 that was synced with 1.12 also powered from USB I saw

.1877 in standby

.373 while transmitting

3.56 watt random blips that seem to happen more often than previous version

One of the things IOTThinks has mentioned is that you have to measure power draw from the battery terminals and not the USB because using the USB means you're powering extra components.

[beachmiles]

One of the things IOTThinks has mentioned is that you have to measure power draw from the battery terminals and not the USB because using the USB means you're powering extra components.

I was powering via the same USB on the previous firrmware version and was seeing much lower lower levels.

[spiralshapeturtle]

@Socalix @spiralshapeturtle There is a BIG problem with the new 1.12 with the ESP32 powersaving that they say is there. I've tested 3, V4 boards and with powersaving on it draws 32.7mA. Something is wrong with the firmware code. I changed to powersaving 11.2 from OITthinks and it works correctly at 11.2mA

We need to get the word out that its not right.

Good catch. It's a bit unclear for me which of the plenty power enhancement releases has made it to 1.12.0, but I assume one of the first releases? Nevertheless, this topic focuses on RF issues with the V4. Could you chime in on the power-saving GitHub topics and post a referral link to this topic to not overload this topic with distracting content?

Reminder: we still haven't made it to dev/GA with this pull, so we need focus in this topic on RF. And we are all convinced it's mandatory to get this register patch into the code, it really works fine.

[spiralshapeturtle]

After adding a Acasom cavity filter to my stock heltec v4 running this firmware fix with the boosted gain enabled my noise floor went from around -90db to -99db. I think I may be receiving a tad better with the filter. My T114 companion is reporting a noise floor of -109db very close to my heltec.

But even with a stock v4 with no filter and this firmware fix with boost enabled I was seeing way better RX performance here in LA, and initial testing showed better RX performance with the boosted gain enabled than the disabled version.

I was reading that these heltec v4's are reporting a higher noise floor than reality, may be a bug in the db floor calculation somewhere in the hardware or in the firmware?

From the tests I have done this week, I assume the V4+register patch (boosted gain default = on as the standard in this PR) plus my cavity receives better than the RAK4631 with the cavity. As stated by Socalix, it's very hard to compare days over time. At least I can tell that the SNR (the quality of the signal) is a few dB higher on the V4+PR1398+cavity, and also the score results on letsmesh.net (meshcore). Of course, the RSSI also increased due to the LNA, but we can't take that as a valid value to compare.

Regarding your last point. Every device with an amplifier in RX has a higher NF, and the owner needs to do the math to remove 17dB from the NF when comparing to none LNA enabled devices. It's not a bug in hardware or in software; it's how RF works.

[mrlmuk]

The weird thing is, v4 + patch + rxbg on + cavity is now getting closer than 17dB to other devices nf, so its not as simple as removing the number.
I'm convinced the nf is a wild guess and the code is not optimised for the v4 behaviour. Also don't measure it in Home Assistant, it is averaging.

[Torcado]

EDIT: Thanks, it's been taken care of.

Thanks so much for your excellent work! Would somebody please be so kind and create a ble companion firmware based on 1.12.0 including this pr? Thanks in advance!

[beachmiles]

Here is the prev version that was posted here with the date 2026-01-22 with this RX fix and a newer 1.11 nightly that has the much lower power usage.
heltec_v4_repeater-1.11.0-pr1398-builds2.zip

[Torcado]

Here is the prev version that was posted here with the date 2026-01-22 with this RX fix and a newer 1.11 nightly that has the much lower power usage. heltec_v4_repeater-1.11.0-pr1398-builds2.zip

Thank you so much! Do you know if this newer 1.11.0 also includes the feature to overwrite contacts (like in 1.12.0)?

[beachmiles]

@Torcado I don't know about that feature, but it did have the change private key remotely fix included.
Here is a version of the fix for the companion that someone posted to this thread.
I haven't done too much testing with this except wardriving and Im pretty sure I'm getting way more hits now.
#1398 (comment)

[Torcado]

@Torcado I don't know about that feature, but it did have the change private key remotely fix included. Here is a version of the fix for the companion that someone posted to this thread. I haven't done too much testing with this except wardriving and Im pretty sure I'm getting way more hits now. #1398 (comment)

@beachmiles Yeah, that's exactly the one I am running now. It's doing wonders for the v4. Sadly it does not include the contacts overwriting feature of 1.12.0.

[towerviewcams]

@spiralshapeturtle Sorry to anyone who didn't think I should post the power issue here, but, its a major issue and needed to be said quickly. I also posted it in several FB groups and discord. Several peeps where going to deploy this weekend and would have been so disappointed. So, we saved them.

@beachmiles You did it right, I went back to the 1.11 that was posted on 1/22 and that works great.

this will all get dialed in.

[Old-Dave573]

The CLI command powersaving either on or off seems to work, but at this time I haven't tested the current draw

…

On Fri, 30 Jan 2026 at 15:11, towerviewcams ***@***.***> wrote: *towerviewcams* left a comment (meshcore-dev/MeshCore#1398) <#1398 (comment)> @spiralshapeturtle <https://github.com/spiralshapeturtle> Sorry to anyone who didn't think I should post the power issue here, but, its a major issue and needed to be said quickly. I also posted it in several FB groups and discord. Several peeps where going to deploy this weekend and would have been so disappointed. So, we saved them. @beachmiles <https://github.com/beachmiles> You did it right, I went back to the 1.11 that was posted on 1/22 and that works great. this will all get dialed in. — Reply to this email directly, view it on GitHub <#1398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUNJMXPPBNB6D3FZJ6GEZYT4JNYB5AVCNFSM6AAAAACRXNJN4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMRUGI2DIMRTHA> . You are receiving this because you commented.Message ID: ***@***.***>

[towerviewcams]

@Old-Dave573 correct it does work and drops the current down to about 32mA.

@1337Reaper forgot to answer.....all tests are at the batt connector.

If you flash the previous version that @beachmiles put back up, then, your back to 11mA

ok, enough of this, back to RX issues. We all want to get this in the next update!

[Socalix]

A quick clarification about what's included in the builds - PR builds are based off of dev branch, which is always firmware release + additional stuff that's in progress. That's how my prior v1.11.0 builds in this PR had the powersaving cli already in.
Due to regression in power consumption I now put the previous v1.11.0 builds back in the 1st comment of this PR, in addition to the new v1.12.0.

I looked through the changes that were committed between Jan 14 (when this PR branch was created) and yesterday (when it got updated) and I see one change that I'm suspecting could be impacting power consumption.
Since we all do not want to drag this current PR in the wrong direction and prevent it from getting merged, I'll tag @towerviewcams on the other PR so we can continue power consumption discussion there.

Again, this PR for improving Heltec v4 RX is complete, fully tested and ready to be merged.

[jhuebert]

I did some trace testing before and after upgrading my v4 firmware with RX fix patch (boost on and packet log off). I'm seeing about a 3dB increase in SNR for receive. It wasn't a super scientific test as I did the before testing yesterday and the after testing this morning. I've attached my results for your perusal - https://docs.google.com/spreadsheets/d/1Ea-OlRJqY9TSWgVZXqYa9vFH9_Ut44FpyHqMTLuSDUE/edit?usp=drivesdk

[beachmiles]

I did some trace testing before and after upgrading my v4 firmware with RX fix patch (boost on and packet log off). I'm seeing about a 3dB increase in SNR for receive. It wasn't a super scientific test as I did the before testing yesterday and the after testing this morning. I've attached my results for your perusal - https://docs.google.com/spreadsheets/d/1Ea-OlRJqY9TSWgVZXqYa9vFH9_Ut44FpyHqMTLuSDUE/edit?usp=drivesdk

Nice job! The boost version worked better for me as well with a stock v4 and no cavity filter.
For your failed % change summary it's actually way better if you sum up all the fails and make a new % instead of averaging the 3 runs since you got so many more failures for the last 2 nodes.
Without the fix you had 24 total fails and with the fix you only had 14 fails. So 58% less fails with the fix!!

[Socalix]

We confirmed that the v4 display PR that was merged to v1.12.0 is causing higher power consumption. Thanks @towerviewcams for helping with the testing!

As a quick solution for now, I added another builds zip up here #1398 (comment) with no_display builds, where the display is completely turned off and power consumption is back to 11mA.

[mikecarper]

With powersaving on it makes sense to turn off the display at the same time. Easy pull request to get accepted?

[Socalix]

With powersaving on it makes sense to turn off the display at the same time. Easy pull request to get accepted?

A permanent fix for the display power is being worked on in a different PR. The build provided here was just a quick solution for now.

[LanWolf]

@Socalix is it possible to add rx patched no oled esp now bridge and rs232bridge builds to your builds ? (I suppose they still base on nightlies)

[spiralshapeturtle]

@Socalix is it possible to add rx patched no oled esp now bridge and rs232bridge builds to your builds ? (I suppose they still base on nightlies)

Do you have the PR numbers thats way easier to confirm? I have created this based on v.1.12.0 + the PR's mentioned. Is the where you are looking for?

heltec_v4_companion_ble_v1.12.0-pr1398-pr1335-pr1569.bin more files in the link

[LanWolf]

@Socalix is it possible to add rx patched no oled esp now bridge and rs232bridge builds to your builds ? (I suppose they still base on nightlies)

Do you have the PR numbers thats way easier to confirm? I have created this based on v.1.12.0 + the PR's mentioned. Is the where you are looking for?

[heltec_v4_companion_ble_v1.12.0-pr1398-pr1335-pr1569.bin more files in the link]

looking for bridge builds with the 1398. (not the std repeater/companion).

[Socalix]

looking for bridge builds with the 1398. (not the std repeater/companion).

@LanWolf Here's a zip with repeater_bridge builds. I did not see rs232 bridge in heltec_v4 config, so I copied it over from v3. Is that what you needed?

heltec_v4_repeater_bridge-1.12.0-pr1398-no_display-builds.zip

[oltaco]

What is the current status of this PR? I see there's been a huge amount of work and testing put in by a huge number of people here and it looks like things might be working properly now?

Am I right in thinking the consensus is that the register patch that was suggested by @Quency-D is looking like the correct way to approach this, and it means we don't have to fight RadioLib for control of the RfSwitch?

Are we waiting for confirmation from Heltec on some testing?

[Socalix]

What is the current status of this PR? I see there's been a huge amount of work and testing put in by a huge number of people here and it looks like things might be working properly now?

This PR for improving Heltec v4 RX is complete, fully tested by several people here and ready to be merged.
@Quency-D Can you please ask to get this merged before the next release?