Potential PR: Add option to change esp init data byte 107 in lua

[dnc40085]

Would it be useful to have the ability to change byte 107 of esp_init_data after firmware is burnt?
If so, where should it go, in adc module or node module?

It doesn't have to be limited to just byte 107, other bytes could be changed as well.

[ABonner]

I'm assuming this is to assist with the ADC setting per the discussion in #911?

[dnc40085]

Yes, that and other issues involving byte 107.

[dnc40085]

@jmattsson I was looking around for issues having to do with the adc module/byte 107 and I ran across your post in issue #1007 suggesting the same PR.
I was thinking that since there are a few more parameters in the init data here is a spreadsheet including an option to adjust the max tx power for the different MCS data rates and a low power mode which allows further attenuation of tx power.

What are your thoughts on which direction this should go?

[jmattsson]

As I mentioned in that post, I'm not overly keen on having to expose the init data bytes into Lua in this manner in the first place. They're (very) advanced settings which shouldn't be twiddled under normal circumstances, and for the advanced use cases there is already the option of flashing a custom init data block. Documentation for the various bytes being in short supply doesn't further endear me to opening up this can of worms.

I think the ADC control byte is probably warranted to expose, and I'd say it should be a function on the adc module. Internally, the (re)writing of the init block should of course use a common API (extend the flash_api as/if needed, I think).

If, and it's a substantial if, we want to also expose WiFi tx power modes, I think they could sit well in an optional wifi.powerctl sub-module. It would need to be really well documented though for it to actually be useful. That would be the hardest part I'd say - radio performance is a tricky topic at the best of days, and looking at the spreadsheet does not make things very clear to me.

[dnc40085]

I agree, this is not something to be taken lightly as there is very little documentation concerning the init data.

If it is decided that this should be implemented, I was planning to use Espressif's Flash download tool to figure out how the byes affected one another so it could be correctly implemented.

On a side note, when I was messing with the Espressif flash download tool I found that the current version of the init data included in flash_api.c has byte 94 incorrectly set to 0x00 when it should be set to 0x0f.

[jmattsson]

Espressif keeps tweaking the init data between SDK releases. Could you double-check that byte against the init data that ships with 1.5.1, please? And if it does differ, could you raise a PR with that change? Thanks!

[dnc40085]

I guess the Espressif flash download tool is dated because byte 94 is as it should be, however bytes 112 and 114 are different.
I'll submit a PR to fix these in a bit.

[dnc40085]

here's the fix #1079

[TerryE]

Thanks @dnc40085 . IOU a review 😄

[dnc40085]

@TerryE was it decided that the functionality is not needed to change byte 107 after firmware is burnt?

[jmattsson]

Nope, I think Terry got things mixed up because we side-tracked into bytes 94/112/114 and you fixed that. I'm still leaning towards having a way of changing 107 from Lua.

[TerryE]

Yup my mindfart. Sorry!!