T096 no power output 1.17 & fem force on

[towerviewcams]

There is no transmit power on T096 with new 1.17 firmware. confirmed on 3 boards. also, fem will force on when flashed

[ellisgl]

I'm also seeing this issue. Even when I'm a couple feet from each other, nothing is see from it.

[HighVoltage73]

I also observed this behavior. Companion node works fine on 1.17. I flashed the repeater back to 1.16 and all is well. I also notice you can set the tx power pretty much arbitrarily and it doesn't make a difference. I could log into the repeater with the companion beside the repeater but move it away say 30-40' and couldn't even ping it.

[CincyRon]

Having the same issue here. 2 different T096 boards and pretty much zero output power with this latest firmware. Flashed back to 1.16 and showing 28.8 dBm output power on the current board I have hooked up.

[dg1tal]

I know this is cumbersome with repeaters deployed in the field, but a useful next step would be to test what happens if you factory-reset your known-bad v1.17.0 T096 and then restore its config line-by-line.

So if anyone got a lab spare that already showed this issue, please try that.

[CincyRon]

I know this is cumbersome with repeaters deployed in the field, but a useful next step would be to test what happens if you factory-reset your known-bad v1.17.0 T096 and then restore its config line-by-line.

So if anyone got a lab spare that already showed this issue, please try that.

I did this multiple times last night with 2 different boards. Erase flash, flash with 1.17, reconfig line by line. No xmit power. Erase flash, flash with 1.16, reconfig line by line. Full xmit power. Erase flash, flash with 1.17 bluetooth companion, reconfigure. Full Xmit power. It's definitely something with 1.17 repeater firmware. I just put my repeater back up with v1.16, but I have my second T096 sitting here on the bench if you have any other ideas to try.

[oltaco]

I'm looking into this, confirmed no power on my T096 running v1.17 main.

[oltaco]

Small update, when MESH_DEBUG is enabled T096 repeater works properly on v1.17. My first thought was that the 5 second delay at startup on MESH_DEBUG builds is what allows it to work but forcing the 5 second delay also doesn't fix it.

Will keep digging.

[dg1tal]

I ran automated tests on a freshly flashed T096 with default settings, alternating FEM RX gain on and off in different patterns, rebooting in between etc. and could not reproduce the issue.

Sadly, I have only a single T096 at hand. Will do some more testing overnight.

[alustenberg]

i've got a tinySA and a few 096s floating around.

was running nightly from 47154f0, which i had thought was running properly. fresh flash reproduces the .17 behavior with 47154f0; its not 0 output, its just really low. a companion next to the node in question is able to remote over to it, barely. tinySA has a slight tickle around -20dbm.

pulled a v4.3, flashed to 1.17, confirmed +28dbm with tx set 18
reflashed bench t096 to 1.16, confirmed +28dbm with tx set 18

poked around the 1.16 to 1.17 git commits for t096 and v4.3; only thing that stand out is the display driver change in t096 from the adafruit to bodmer tft_espi drivers.

pulled down repo, unset DISPLAY_CLASS in platform.io for t096, rebuilt and flashed. confirmed +28dbm at tx set 18.

seems like the TFT_eSPI driver is fighting over the FEM's power pin? saw mention the FEM and the TFT share a common switched power while digging around.

[edit] also can confirm that radio.fem.rxgain resets to on after reboot even after 'set radio.fem.rxgain off'

[alustenberg]

seems that disabling the display define also bricks the GPS. shows as on,active,no fix, 0 sat 5 minutes after boot.

[edit] this may be a red herring, got a 1.16 node not syncing up with gps either. might be conditions.

[oltaco]

poked around the 1.16 to 1.17 git commits for t096 and v4.3; only thing that stand out is the display driver change in t096 from the adafruit to bodmer tft_espi drivers.

Nice work! I thought I tried disabling the display but I obviously got it wrong. So the problem is SPI timing issues which is why very small changes in timing can mask the issue.

[alustenberg]

Nice work! I thought I tried disabling the display but I obviously got it wrong.

ty. simple patch from testing

diff --git a/variants/heltec_t096/platformio.ini b/variants/heltec_t096/platformio.ini
index 02e88328..364e4ecf 100644
--- a/variants/heltec_t096/platformio.ini
+++ b/variants/heltec_t096/platformio.ini
@@ -40,18 +40,15 @@ build_flags = ${nrf52_base.build_flags}
   -D GPS_BAUD_RATE=115200
   -D PIN_VBAT_READ=BATTERY_PIN
   -D PIN_BAT_CTL=47
-  -D DISPLAY_CLASS=ST7735Display
   -D DISPLAY_ROTATION=1
 build_src_filter = ${nrf52_base.build_src_filter}
   +<helpers/*.cpp>
   +<helpers/sensors>
   +<../variants/heltec_t096>
-  +<helpers/ui/ST7735Display.cpp>
   +<helpers/ui/MomentaryButton.cpp>
 lib_deps =
   ${nrf52_base.lib_deps}
   ${sensor_base.lib_deps}
-  bodmer/TFT_eSPI @ ^2.4.31
 debug_tool = jlink
 upload_protocol = nrfutil

attempted a local revert of #2951 but ended up with a bunch of conflicts. tried some shotgun debugging over in the 7735 helper lib, but have not made any progress.

SPI and embedded stuff is well outside my wheelhouse, but can build off tree and provide testing as needed.

[oltaco]

It's also worth mentioning that the new ST7735 wrapper was working with Tx prior to #2982 being merged, and I just tested main with just that that PR reverted and it works correctly again.

I'm still leaning towards SPI timing, because that would explain why enabling MESH_DEBUG or reverting #2982 allows Tx to function again.

I'm still at a loss to explain how the new wrapper interferes with the FEM though. It's not periph_power claims, and sprinkling in extra delay around the place doesn't make any difference.