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-22) - 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?

[Socalix]

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 )

Awesome. We're just trying to figure out what is the optimal configuration - with or without Boosted Gain, so having 2 nodes next to each other and comparing RX like you did sounds great.
By the way, not sure if you know - these antennas usually work best if you keep them up straight, not bent at the connector.

[Socalix]

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!

I just checked on it. It seems that the Powersaving PR was merged to the dev branch a month ago, so it was not in the v1.11.0 firmware, but it's included here because PRs are branched from dev.

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?

Both build have the register patch. The "PR1398-packetlog" also has the "RX_BOOSTED_GAIN" flag turned off. I am not sure if/how this is changing the LNA. My understanding is that it's SX1262 flag only. This is from Semtech documentation:
The SX1261 and SX1262 can operate in Rx Boosted gain setup or in a Rx power saving gain setup. In the Rx power saving gain, the radio will consume less power at a small cost in sensitivity. In Rx Boosted gain, the radio will consume more power to improve the sensitivity

[spiralshapeturtle]

Just for reference, we all have read this post right? https://wiki.heltec.org/news/v4-receive-sensitivity/v4-receive-sensitivity

@Socalix I think we have a winner: boost-packetlog

Today with stock firmware, check the score drops!

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

does the V4 got different hardware revisions? My board got the text: HTIT-WB32LAF V4.2.

With this regular letsmesh stock firmware without any RX optimizations, without cavity the results of processes packets are the same as with the boosted-packetlog from yesterday? The focus should be on the packets with SNR and RSSI.

1.11.0-letsmesh.net-6d32193 (Build: 30-Nov-2025) (with the better antenna) Still the normal 25% datapackets.

Complete Test Data - All Measurements

Test 1: (Initial Baseline)

V4_2 - boost-packetlog-4575800 + Better Antenna

Utrecht (13.69 km)

Time Ago	SNR	RSSI	Score
1h ago	0dB	-74dBm	579
2h ago	4dB	-75dBm	795
3h ago	5dB	-74dBm	822

Radome West (4.06 km)

Time Ago	SNR	RSSI	Score
3h ago	3dB	-71dBm	719

Zeist Sanatoriumbos (2.66 km)

Time Ago	SNR	RSSI	Score
7h ago	-4dB	-94dBm	270

---

V4 - packetlog-4575800 + Standard Antenna

Utrecht (13.64 km)

Time Ago	SNR	RSSI	Score
1h ago	3dB	-79dBm	741
2h ago	6dB	-78dBm	902
3h ago	6dB	-77dBm	902

Repeater PA5B Houten (7.25 km)

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

Radome West (3.93 km)

Time Ago	SNR	RSSI	Score
4h ago	6dB	-73dBm	837

Zeist Sanatoriumbos (2.62 km)

Time Ago	SNR	RSSI	Score
8h ago	-9dB	-97dBm	36

---

Test 2: After Antenna Swap

V4_2 - boost-packetlog-4575800 + Standard Antenna

Utrecht (13.69 km)

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

Radome West (4.06 km)

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

Zeist Slot (0.91 km)

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

loramesh.nl (8.02 km)

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

Zeist Sanatoriumbos (2.66 km)

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

---

V4 - packetlog-4575800 + Better Antenna

Utrecht (13.64 km)

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

Repeater PA5B Houten (7.25 km)

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

Radome West (3.93 km)

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

Zeist Sanatoriumbos (2.62 km)

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

---

Test 3: Stock Firmware Test

V4_3 - Stock v1.11.0 + Better Antenna

Utrecht (13.69 km)

Time Ago	SNR	RSSI	Score
1h ago	2dB	-78dBm	612
2h ago	4dB	-79dBm	672
3h ago	1dB	-79dBm	528

Repeater PA5B Houten (7.27 km)

Time Ago	SNR	RSSI	Score
55m ago	-2dB	-88dBm	366
59m ago	-9dB	-88dBm	24
8h ago	-8dB	-88dBm	97

loramesh.nl (8.02 km)

Time Ago	SNR	RSSI	Score
8h ago	0dB	-84dBm	523
20h ago	-9dB	-85dBm	26

Radome West (4.06 km)

Time Ago	SNR	RSSI	Score
9h ago	4dB	-73dBm	732
21h ago	3dB	-73dBm	680

Zeist Slot (0.90 km)

Time Ago	SNR	RSSI	Score
5h ago	-2dB	-85dBm	382

---

V4 - packetlog-4575800 + Standard Antenna (Same as Yesterday)

Utrecht (13.64 km)

Time Ago	SNR	RSSI	Score
1h ago	0dB	-76dBm	492
2h ago	2dB	-74dBm	588
3h ago	0dB	-75dBm	492

Repeater PA5B Houten (7.25 km)

Time Ago	SNR	RSSI	Score
14h ago	-5dB	-85dBm	219
1d ago	-1dB	-86dBm	415
1d ago	-1dB	-86dBm	415

Radome West (3.93 km)

Time Ago	SNR	RSSI	Score
9h ago	0dB	-73dBm	549
21h ago	-3dB	-75dBm	353
1d ago	4dB	-74dBm	758

Zeist Sanatoriumbos (2.62 km)

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

---

Configuration Summary

Test	Device	Firmware	Antenna
1	V4_2	boost-packetlog-4575800	Better
1	V4	packetlog-4575800	Standard
2	V4_2	boost-packetlog-4575800	Standard
2	V4	packetlog-4575800	Better
3	V4_3	Stock v1.11.0	Better
3	V4	packetlog-4575800	Standard

If I summarize this:

Firmware Performance Comparison Summary

Firmware	Avg. SNR	Avg. RSSI	Avg. Score	Performance Notes
boost-packetlog	+2.0 dB	-77.9 dBm	640	Best. Consistently highest SNR and scores even with standard antennas.
packetlog	-0.3 dB	-80.9 dBm	492	Good. Balanced performance, significantly better than stock.
Stock v1.11.0	-1.5 dB	-81.8 dBm	422	Weakest. Struggles with SNR at distance; frequent low-score packets.

Key Findings

• Firmware Impact: Moving from Stock to boost-packetlog resulted in a 50%+ increase in average signal score.
• Sensitivity: boost-packetlog maintained a positive Signal-to-Noise Ratio (SNR) at distances where other firmwares dropped into negative values.
• Stability: Stock firmware showed significant instability at range (13km+), with scores occasionally dropping as low as 24-26.

[spiralshapeturtle]

@Quency-D goodmorning, what is your opinion for the results? And we know that this PR works, how do we get this into v 1.12.0? What is Heltecs advice regarding the boost on / off ? In my results it seems that the boost version is performing better?

[tpp-at-idx]

Awesome. We're just trying to figure out what is the optimal configuration - with or without Boosted Gain, so having 2 nodes next to each other and comparing RX like you did sounds great.
By the way, not sure if you know - these antennas usually work best if you keep them up straight, not bent at the connector.

As per your comment here: #1398 (comment)

Soo, I have run the tests, same antenna, altough bent in the elbow in both nodes ( not sure it it matters on this model, the active elements seem to be in the antenna body and there is a coax visible in the elbow ). Both Heltec v4, Both in a client role.
Both on the same place a few cm apart, and located in my "rf hellhole" ( both of them this time )

The NORXGAIN v4 reported a noise floor of about -65 to -69
the WITHRXGAIN v4 has a noise floor of -80 to -82

I have also shuffeled the v4's to be sure that there is no" with a better reception hw" ( i.e different batch, diferent revision, whatever ) but I can conclude that the results are software dependent as now the "better" node from my previous tests performed worse and vice versa.

the results are

WITHRXGAIN : 548 msg
NORXGAIN : 561 msg
So a difference of about 2.3 percent

Soo, well. I guess this is somewhat a wrench thrown in the finding of you guys, but yeah. My use case is radically different than yours ( client vs repeater ), and my environment is also radically different from yours ( guess your repeaters live in a nice open space whereas mine is in a deliberate poor rf environment )
But yeah, all in all it seems that the semtech patch does it's job. On the matter of RXGAIN your mileage may vary and it is really dependent on conditions. Even the Meshtastic guys have no clean answer on the matter of RXGAIN ( afaik ) so i guess the they have concluded the same thing and made RXGAIN a on/off parameter configurable with the app. And maybe this is the way to go.

[logiczny]

Repeater builds for testing: heltec_v4_repeater-1.11.0-pr1398-builds.zip

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

EDIT:
I think I figured this out:

1. go to DFU mode
2. flash regular 1.11.0 repeater using stock firmware @ webflasher
3. setup repeater and test it if it works, reboot
4. go to DFU mode
5. flash custom firmware (do NOT erase device, data should be keeped), in my case heltec_v4_repeater-1.11.0-pr1398-boost-packetlog-4575800.bin
6. reboot using button, it won't reboot itself

Original comment:
Hi,
Noob question, but I've tried to flash any of these bin's using webflasher (custom firmware mode), Heltec v4 won't boot into anything after that. Is this normal? After reflashing to BT companion (official 1.11.0) it works OK as a companion, so the device is OK. I wanted to try out my Heltec v4 with a better RX parameters, as a repeater.

Serial port WebSerial VendorID 0x303a ProductID 0x1001
Connecting...

Detecting chip type... ESP32-S3
Chip is ESP32-S3 (QFN56) (revision v0.2)
Features: Wi-Fi,BLE,Embedded PSRAM 2MB (AP_3v3)
Crystal is 40MHz
MAC: 88:56:a6:96:10:70
Uploading stub...
Running stub...
Stub running...
Manufacturer: 68
Device: 4018
Detected flash size: 16MB
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.111s
Compressed 1155200 bytes to 772577...
Writing at 0x10000... (2%)
Writing at 0x16ba1... (4%)
Writing at 0x1ab36... (6%)
Writing at 0x1eb31... (8%)
Writing at 0x22b28... (10%)
Writing at 0x27154... (12%)
Writing at 0x2d988... (14%)
Writing at 0x393d7... (16%)
Writing at 0x4362c... (18%)
Writing at 0x56425... (20%)
Writing at 0x5bd94... (22%)
Writing at 0x61b9d... (25%)
Writing at 0x67419... (27%)
Writing at 0x6d10b... (29%)
Writing at 0x72856... (31%)
Writing at 0x78822... (33%)
Writing at 0x7e1fe... (35%)
Writing at 0x83c56... (37%)
Writing at 0x894e7... (39%)
Writing at 0x8ea51... (41%)
Writing at 0x94748... (43%)
Writing at 0x9a193... (45%)
Writing at 0x9fa1b... (47%)
Writing at 0xa574c... (50%)
Writing at 0xaa678... (52%)
Writing at 0xaf700... (54%)
Writing at 0xb4696... (56%)
Writing at 0xb95a8... (58%)
Writing at 0xbe3ce... (60%)
Writing at 0xc3539... (62%)
Writing at 0xc8730... (64%)
Writing at 0xcd975... (66%)
Writing at 0xd2a38... (68%)
Writing at 0xd862e... (70%)
Writing at 0xdd64d... (72%)
Writing at 0xe2594... (75%)
Writing at 0xe765e... (77%)
Writing at 0xec840... (79%)
Writing at 0xf1cbf... (81%)
Writing at 0xf7044... (83%)
Writing at 0xfcfbe... (85%)
Writing at 0x1023db... (87%)
Writing at 0x107d83... (89%)
Writing at 0x10dec3... (91%)
Writing at 0x11815a... (93%)
Writing at 0x11e101... (95%)
Writing at 0x1232c7... (97%)
Writing at 0x128f57... (100%)
Wrote 1155200 bytes (772577 compressed) at 0x10000 in 6.946 seconds.
Leaving...
Hard resetting via RTS pin...

[towerviewcams]

So I'm testing the packetlog-boost pr1398 firm now at a very noisy commercial tower site that has cellular and lots of high power broadcast. Long distance (backbone) pings/traces are now GREAT. the non boost does not disable the LNA as we all know in a V4, but, after @spiralshapeturtle testing this is what I went with. We have a very busy mesh in the pacific north west now and so far, this is working much better then stock firm. Later this afternoon, I will have this firm on the other end of the link (60 miles LOS) and will be able to give detailed feed back then and compare.

[Quency-D]

@Quency-D goodmorning, what is your opinion for the results? And we know that this PR works, how do we get this into v 1.12.0? What is Heltecs advice regarding the boost on / off ? In my results it seems that the boost version is performing better?

Theoretically, adding RXGAIN should yield better results when noise levels are low, but may have adverse effects when noise levels are high. Therefore, it's best to add this variable to the app so that it becomes controllable.

[Socalix]

@spiralshapeturtle
does the V4 got different hardware revisions? My board got the text: HTIT-WB32LAF V4.2.

My understanding is that Heltec v4.1 was an internal version for testing and v4.2 is the first public version.

With this regular letsmesh stock firmware without any RX optimizations, without cavity the results of processes packets are the same as with the boosted-packetlog from yesterday?

One thing I learned from all the tests I did the past few weeks is that it's very difficult to compare tests between different days. Best is to compare between 2 nodes on the same day. I'm not sure if it's because of environmental noise, weather patterns or star alignment, but I kept getting very different results between different days.

@tpp-at-idx the results are WITHRXGAIN : 548 msg NORXGAIN : 561 msg So a difference of about 2.3 percent
Soo, well. I guess this is somewhat a wrench thrown in the finding of you guys, but yeah. My use case is radically different than yours ( client vs repeater ), and my environment is also radically different from yours ( guess your repeaters live in a nice open space whereas mine is in a deliberate poor rf environment )

In my tests the No Boosted Gain was better as well, that's why I started this PR with it boosted gain turned off.

But yeah, all in all it seems that the semtech patch does it's job. On the matter of RXGAIN your mileage may vary and it is really dependent on conditions. Even the Meshtastic guys have no clean answer on the matter of RXGAIN ( afaik ) so i guess the they have concluded the same thing and made RXGAIN a on/off parameter configurable with the app. And maybe this is the way to go.

@Quency-D Theoretically, adding RXGAIN should yield better results when noise levels are low, but may have adverse effects when noise levels are high. Therefore, it's best to add this variable to the app so that it becomes controllable.

At this point I think all of our tests have proven that the register patch provided by @Quency-D is significantly improving RX in all cases and should be merged into the firmware.

As for the Booted Gain, we see that this seems to be more of a case-by-case basis, depending on environment, antenna, noise level, etc. Considering this is controlled by an existing build flag already, and there's an open PR #1164 to make it configurable at runtime too, I'm going to revert the boosted gain part of the PR and keep the register patch only.

[Socalix]

@logiczny I think I figured this out:
2. flash regular 1.11.0 repeater using stock firmware @ webflasher
5. flash custom firmware (do NOT erase device, data should be keeped),

Yes, this is the important part - flash the stock firmware with erase, and from that point on flash other build without erase.

[Socalix]

Boosted gain flag reverted, hopefully will be added as a runtime config soon.

This PR is now fully tested ready to merge!

[spiralshapeturtle]

@Quency-D Theoretically, adding RXGAIN should yield better results when noise levels are low, but may have adverse effects when noise levels are high. Therefore, it's best to add this variable to the app so that it becomes controllable.

At this point I think all of our tests have proven that the register patch provided by @Quency-D is significantly improving RX in all cases and should be merged into the firmware.

As for the Booted Gain, we see that this seems to be more of a case-by-case basis, depending on environment, antenna, noise level, etc. Considering this is controlled by an existing build flag already, and there's an open PR #1164 to make it configurable at runtime too, I'm going to revert the boosted gain part of the PR and keep the register patch only.

Totally agree on that, thanks for your time invested. And for the record I put my V4 out in the field now:

heltec_v4_repeater-1.11.0-pr1398-4575800.bin this file from your links is the normal file without, debugs, packetlogs etc? Which I could load into my repeaters. This file is good to go until @Quency-D / Heltec managed to get this PR merged into the new builds.

Again thanks!

[Socalix]

@spiralshapeturtle I updated the builds zip up here #1398 (comment) with better names:

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

[towerviewcams]

@spiralshapeturtle & @Socalix
The boost on and off does not apply to a V4 right? I don't see any receive gain difference flashing ether file. My understanding is thats for the older SX chip. correct?