fix agc reset on SX126x, SX1276 & LR11x0 chips

[weebl2000]

• tried to simply explicitly call sleep briefly to reset AGC -> not sufficient it seems
• do more thorough reset using Calibrate (0x7F) -> success
• reset noise_floor so firmware shows accurate values
• so far it seems to work great on a Heltec v4
• should work on all SX126x based chips by using Calibrate(0x7F)
• shoudl work on all LR11x0 based chips by using Calibrate(0x3F)
• should work on SX1276 chips too, calling sleep there should be sufficient - SX1276's AGC is simpler — just LNA gain stepping. Sleep mode powers down the entire analog frontend, and re-entering RX restarts the AGC from G1 (max gain).
• default calibration is in 902-928 MHz range, made sure to follow up with actual configured frequency
• build firmware for yourself here: https://mcimages.weebl.me/?commitId=fixagcreset

fixes #1716- see discussion there for initial test results
fixes #1209

I've referenced SX1262 datasheet to implement the calibration reset.

• p25 4.3 ,64-65 table 12-1 listing ΣΔ ADC architecture
• p55 table 9-1 sleep enable vs stdby_rc enable
• p55 9.2 states which blocks can be calibrated
• p61 9.2.1 calibrate specific freq
• p66 warm sleep restores register state confirms we need more aggressive Calibrate(0x7F) reset
• p73 total calibration time is 3.5 ms and must be launched in STDBY_RC mode

For LR1110 similar implementation, the 'AGC' is completely black boxed behind firmware so you can only reset it by resetting registers.

LR1110 datasheet page 9 section 1.2.1 states:
•Air interface fully compatible with the SX1261/2/8 family

Also see LR1110 user docs

So reset is very similar.

[towerviewcams]

what boards do you think the AGC doesn't work on? On a V4, I've been watching closely at a terrible site I have with 945Mhz STL microwave and turned off agc.reset.interval and then back on. I think it "might" be working but not sold on that.

[terminalvelocity23]

what boards do you think the AGC doesn't work on? On a V4, I've been watching closely at a terrible site I have with 945Mhz STL microwave and turned off agc.reset.interval and then back on. I think it "might" be working but not sold on that.

I have reports that it gets stuck on V3 and T114, as well. My DIY node based on ESP32-S3 and E22 900M30S gets affected, too.

[towerviewcams]

I figured out why I'm not seeing this AGC problem. Its had me stumped on and off for a couple days. I set my repeaters to Zero on the int.thresh 0

Once I changes this back to default, yep, I can watch my noise floor eventually hit -120 on my V4 and be of course very desensitized.

I tried @weebl2000 test firm builder and in fact it is fixed. also, no current spike on AGC rest every 12 seconds that mine is set for the test.

[towerviewcams]

@weebl2000 Your test firm still has the 22 second powersaving delay. Can you update your base 1.13 firm with that fix? I'm testing your AGC fix now but since I'm in a busy area, I'm never sleeping and its draining battery pretty good in our rain for days weather.

[weebl2000]

@weebl2000 Your test firm still has the 22 second powersaving delay. Can you update your base 1.13 firm with that fix? I'm testing your AGC fix now but since I'm in a busy area, I'm never sleeping and its draining battery pretty good in our rain for days weather.

the fixagcreset is up-to-date with the meshcore/dev branch. Are you building fixagcreset branch? https://mcimages.weebl.me/?commitId=fixagcreset what branch is the 22 second powersaving delay branch? I can merge that one with this one for you so you can test the combination.

[towerviewcams]

@weebl2000 the 22 second delay showed up in 1.13 and @IoTThinks Kevin made a hotfix on his github. They also also have powersaving13 as well. I've been testing it on 2, V4 boards and its awesome. It is not merged into the dev branch at this time.

If you could do something temporary with ether the hot fix, that would allow me to test at 3 tower sites tomorrow for work that I'm taking an insurance agent to. All easy access repeaters in town.

The hot fix on easy sky mesh is under Firmware, Testing, PR-1687, : heltec_v4_repeater-002878e.bin and I have that running in addition to stock 1.13 and its perfect. I'm guessing that would be the simplest? All 3 of these sites go numb -120 in just under 24 hrs and this AGC reset fix should be golden to find out really quick!

[IoTThinks]

@weebl2000 22-second delay in PowerSaving is likely the OLED issue on Heltec v4 in the current MC 1.13 (main and dev).

It should not be related / affected to your PR.

#1562 (comment)

@towerviewcams The fix for 22-second powersaving delay in PowerSaving 13 is included in the bellow pending PR too.
It will sleep immediately after processing LoRa packets.

#1687

[weebl2000]

The hot fix on easy sky mesh is under Firmware, Testing, PR-1687, : heltec_v4_repeater-002878e.bin and I have that running in addition to stock 1.13 and its perfect. I'm guessing that would be the simplest? All 3 of these sites go numb -120 in just under 24 hrs and this AGC reset fix should be golden to find out really quick!

try this one: https://mcimages.weebl.me?commitId=agc-tower it includes this PR + #1687 + #1569

[towerviewcams]

@weebl2000 Trying right now!

[towerviewcams]

@weebl2000 Wow! what a difference! I'm slamming 2 boards at the same time, with 2 different companions and 2 ios phones. So im connected at the same time.

#1 V4 has the AGC/pwr save fix. This PR and 1687 and 1569
#2 has 1.13 stock

I'm slamming them both side by side and the AGC reset works every time. back down to -104 ish......... #2 is sticking and not resetting. Sometimes its slow, and others not. I'm sure if I let this run for a day we would see.

-Field Test
I'm taking this to a major high power broadcast site now where I really need AGC to work, I bounce all over the place from -86 up to -102 on my V4 there. I have to reboot for it to come back to -100's....Then eventually drops down and up.....So, I'll report back in a couple hours once its OTA updated. This looks very promising!! Thank you @weebl2000

@IoTThinks, Keven, I know you told me on FaceBook that you haven't seen where you need to reset. Let me test this and I'll know very quickly. I'm sitting next to over 1 megawatt of power and 4 cellular companies all on my 800ft tower that I manage.

[towerviewcams]

90 mins in and holding -98 to -102 on noise floor readings. This is exciting so far!!!!

[ignisf]

The FAQ may need to be updated.

[IoTThinks]

@towerviewcams Well, 1MW interference. Then it makes sense.

So your agc reset interval is 4?

Besides the noise floor number, have you observed if the repeaters can receive more packets or better SNR...?

I would love to have lower noise floor and better RX too.

My noise floor for Heltec v3s with 3 and 5dbi is -97 to even -77 recently.

[towerviewcams]

@towerviewcams Well, 1MW interference. Then it makes sense.

So your agc reset interval is 4?

Besides the noise floor number, have you observed if the repeaters can receive more packets or better SNR...?

I would love to have lower noise floor and better RX too.

My AGC reset is 8. Everything has been working great. Prior to this reset working properly, decoding packets was very intermitant and required a very strong signal as noise floor would increase to -86 or so and remain there. Now, I'm holding -97 to -102......I do see a suddon drop to -86 and then it pops back up with the AGC reset. So far so good!

[towerviewcams]

Today, I'm going to OTA this at another location that has 600,000 watts broadcast noise and 3 cellular tenants. My noise floor here drops slowly to -91 and I was going to do the LNA bypass. Not now, lets try this! Update soon!

[IoTThinks]

@towerviewcams Great.
Let me test on my Heltec v3 too.

This symptom seems to happen to many boards including RAK4631. Not just Heltec v4.

[towerviewcams]

Now running this on another V4 in the field next to 600,000 ERP broadcast transmitter and AGC is working nicely. Taking my Wio down to power -9 and can trace now just fine! Before, my noise floor was holding -89 and could not. Let this run for rest of the day and I'll know for sure. now im at a very nice -96-98 ish. reset rate 8 seconds. If works great I'm going to set my reset timer to 16 on both tests. then more as time goes on to find the sweet spot where it starts to drop before reset

[terminalvelocity23]

I've tested this on a V3, works fine, just as well as with V4.

[IoTThinks]

@towerviewcams I have tested with my Heltec v3 with 3dbi antenna for half a day.

MC 1.13:
agc.reset.interval=0, my noise floor is jumping around -8x to -76.
If agc.reset.interval=4, 8, 300, 600, the noise floor will be stuck at -120 after a day.

This branch: (commit dbb739)
If agc.reset.interval=0 or agc.reset.interval=4, 8, 300, 600, my noise floor is jumping around -8x to -76.
So yes, it has not been stuck at -120 yet.

All values for agc.reset.interval give the same noise floor.
Should I expect the noise floor to be better at -100 to -90 instead?
Your noise source should be much stronger than my cell towers.

[towerviewcams]

@towerviewcams I have tested with my Heltec v3 with 3dbi antenna for half a day.

MC 1.13: agc.reset.interval=0, my noise floor is jumping around -8x to -76. If agc.reset.interval=4, 8, 300, 600, the noise floor will be stuck at -120 after a day.

This branch: (commit dbb739) If agc.reset.interval=0 or agc.reset.interval=4, 8, 300, 600, my noise floor is jumping around -8x to -76. So yes, it has not been stuck at -120 yet.

All values for agc.reset.interval give the same noise floor. Should I expect the noise floor to be better at -100 to -90 instead? Your noise source should be much stronger than my cell towers.

@IoTThinks My noise is broadcast at 580Mhz so its far away from 910Mhz but a HUGE signal source for sure. I'm glad your seeing good results. Cellular is much closer to 910mhz and will get through your filter easier. So it doesn't surprise me.

[towerviewcams]

More then 32 hours and running perfectly on V4 still using the "agc-tower" firm build. Fantastic @weebl2000

Just as a thought, @IoTThinks Keven, will you please please put this into a test Powersaving13.1 beta test? Lets consider putting this together?

[towerviewcams]

@weebl2000 @IoTThinks BIG UPDATE

So the AGC-Powersave that has the three merged PR and the quick sleep does have serious login responsiveness issues. @beachmiles is totally correct. So I have pulled that from my tests that ran for 24hrs. -done there

The dev_plus has a 16 second delay before power saving kicks in. current is 47mA and then will drop down to 11mA after the delay. I've done allot of testing ALLOT after it goes to sleep and it responds every single time, quickly! So, how can we get this delay down and still have it respond? That would then be perfect. In busy areas we may never sleep.

-The dev-plus also has the hardware delay, and I have 3 repeaters LOS to my house that are high level, and I must say this is just fantastic. It checks briefly to see if there is on air traffic before it transmits. very good.

[IoTThinks]

@towerviewcams

1. Why there is 16s delay?
   Dev_plus changed from 2 mins to 16s to activate the first sleep?

Then later, the repeater should sleep instantly, right?

2. The first part, you mention there is login responseness.

What is your agc setting and how many hops to do remote login?

3. Second part you mentioned the repeater responsed fine instantly every time.

Via ping or repeat, right?

[IoTThinks]

@weebl2000 I remember you have LBT in dev_plus, right?

If the repeater postpones a repeat or CLI response and they are counted in hasPendingWorks(), powersaving will wait and skip sleeping until hasPendingWorks() is false.

By right it should be ok.

Or may be CLI response is not counted in hasPendingWork()?

[towerviewcams]

@towerviewcams

1. Why there is 16s delay?
   Dev_plus changed from 2 mins to 16s to activate the first sleep?

Then later, the repeater should sleep instantly, right?

2. The first part, you mention there is login responseness.

What is your agc setting and how many hops to do remote login?

3. Second part you mentioned the repeater responsed fine instantly every time.

Via ping or repeat, right?

@IoTThinks

1. Not sure why. but the delay is there in both logging in to the repeater, or, a cli comand. or even a packet repeat. testing in front of me here at my desk.

2. my AGC reset interval was tested at 8,16, 60 still the same....very difficult to log in. This is on my desk testing in front of me.

3. I changed firmware to dev_plus, then it responds fine everytime but that firm now has the 16s delay powersaving

[IoTThinks]

Let me check the source code of agc powersaving and dev-plus.

For PowerSaving 13, I still can remote manage via 5 nearby hops.

I guess int.thresh and LBT has some impacts when delaying the response due to air activity.

Do you set int.thresh?

[towerviewcams]

Let me check the source code of agc powersaving and dev-plus.

For PowerSaving 13, I still can remote manage via 5 nearby hops.

I guess int.thresh and LBT has some impacts when delaying the response due to air activity.

Do you set int.thresh?

@IoTThinks
thanks for checking this, I have 2 sites that I would love to update today to test further.

int.thresh 10

power saving 13 does not have the AGC reset bug fix. it will clamp down to -120 within 24 hrs

[IoTThinks]

3. I changed firmware to dev_plus, then it responds fine everytime but that firm now has the 16s delay powersaving

@towerviewcams
dev_plus inherits a bug from dev.
So dev_plus uses old PowerSaving version not PR 1687.
https://github.com/weebl2000/meshcore/blob/dev_plus/examples/simple_repeater/main.cpp#L141

NRF52 PowerSaving broke my ESP32 PowerSaving. That's why the repeater needs more time to sleep.
#1562 (comment)

This has been fixed in PR #1687
The repeater sleeps instantly.

[weebl2000]

@towerviewcams you can try this one, perhaps it works - I haven't tested yet: https://mcimages.weebl.me/?commitId=agc-powersave2 it contains this PR, #1600, #1569, #1653 and #1687 with a fix hopefully.

[IoTThinks]

@towerviewcams I have tested just now the agc-powersave vs. PowerSaving 13.
For Heltec v4, I confirmed agc-powersave had very long-wait response in Remote management.
PowerSaving 13 (MC 1.13 + PR 1687) responses instantly even with int.thresh=10 and agc.reset.internval 8 (in MC 1.13 of course)
dev...weebl2000:meshcore:agc-powersave

I will check the AGC source code tomorrow.
And will test agc-powersaving against heltec v3 too.

[towerviewcams]

@towerviewcams you can try this one, perhaps it works - I haven't tested yet: https://mcimages.weebl.me/?commitId=agc-powersave2 it contains this PR, #1600, #1569, #1653 and #1687 with a fix hopefully.

@weebl2000 @IoTThinks
No this AGC-powersave2 does not work. Remote login does not work the first time. Second or third time it does. Powersaving works most of the time fast, BUT, I just had it hang at 19.4 mA and never went back to 11ma as it should

something still wrong with wake up to receive first packet or something to that effect.

[txkbaldlaw]

@towerviewcams you can try this one, perhaps it works - I haven't tested yet: https://mcimages.weebl.me/?commitId=agc-powersave2 it contains this PR, #1600, #1569, #1653 and #1687 with a fix hopefully.

@weebl2000 @IoTThinks No this AGC-powersave2 does not work. Remote login does not work the first time. Second or third time it does. Powersaving works most of the time fast, BUT, I just had it hang at 19.4 mA and never went back to 11ma as it should

something still wrong with wake up to receive first packet or something to that effect.

I have that issue on pretty much all of my remote repeaters, even using the standard release firmwares. The only ones that ever connect first try are direct connects. Anything that is flood requires at least two tries.

[towerviewcams]

@towerviewcams you can try this one, perhaps it works - I haven't tested yet: https://mcimages.weebl.me/?commitId=agc-powersave2 it contains this PR, #1600, #1569, #1653 and #1687 with a fix hopefully.

@weebl2000 @IoTThinks No this AGC-powersave2 does not work. Remote login does not work the first time. Second or third time it does. Powersaving works most of the time fast, BUT, I just had it hang at 19.4 mA and never went back to 11ma as it should
something still wrong with wake up to receive first packet or something to that effect.

I have that issue on pretty much all of my remote repeaters, even using the standard release firmwares. The only ones that ever connect first try are direct connects. Anything that is flood requires at least two tries.

This is sitting here in my work bench. I rolled back to previous devs and also stock 1.13 and all back to normal. So i know its new and confirmed

[beachmiles]

Logging in and the "Request status" button works ~90% of the time on AGC-Powersave with powersaving on or off.
The problem is trying to do any other function in the CLI or the clickable functions in the 3rd tab that only work like ~5% or the time.
Seems like every ~20-90 seconds there is a short window where these functions start working again.
To find this window I would spam the refresh radio settings button on the 3rd tab until items populated and then quickly would enter in the CLI command or reboot, etc and that command would work ~90% of the time.

The issue seems to not be related to powersaving on or off, not sure if something under the hood is keeping powersaving on even if I have it off, etc.

[IoTThinks]

Let me merge the AGC of this PR to PowerSaving 13.1 (Based on MC 1.13 main branch) today.
PowerSaving 13: https://github.com/IoTThinks/MeshCore/tree/PowerSaving-v13

[IoTThinks]

@towerviewcams @terminalvelocity23 This PowerSaving 13.1 based on MC 1.13 MAIN + this PR.
I have tested on Heltec v4, very responsive with CLI with the below commands

powersaving on
set agc.reset.interval 8
set int.thresh 10

The bin files and source code are at https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving13.1

I'm testing too. If fine, I will deploy PS 13.1 to all newly repeaters too.

[towerviewcams]

@towerviewcams @terminalvelocity23 This PowerSaving 13.1 based on MC 1.13 MAIN + this PR.

I have tested on Heltec v4, very responsive with CLI with the below commands

powersaving on

set agc.reset.interval 8

set int.thresh 10

The bin files and source code are at https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving13.1

I'm testing too. If fine, I will deploy PS 13.1 to all newly repeaters too.

This is great news Kevin! I'll get this programmed up now just before bed and check in the morning after it runs all night.

Thanks friend!

[IoTThinks]

A friend discovered a bug affecting PR1687 PowerSaving in dev branch.
#1687 (comment)

This is the PR to fix.
Let me test. :)
#1877

Well, it is good as we can use both PowerSaving and AGC reset.

[towerviewcams]

A friend discovered a bug affecting PR1687 PowerSaving in dev branch. #1687 (comment)

This is the PR to fix. Let me test. :) #1877

Well, it is good as we can use both PowerSaving and AGC reset.

@IoTThinks Are you saying that that firm above that you tagged me in that I started testing has the bug? or just the dev branch that is NOT part of the above link with Powersaving 13.1 ??

UPDATE-
so far, 13 hours in this BETA 13.1 is working great on my V4 boards

Update2-
Just deployed on a very bad noisy site. Just over 2 megawatt ERP site and AGC is fantastic!!!!

[weebl2000]

I think this PR is good to be merged.