Fix Station G2 Lora Power Settings

[fifieldt]

In #8107 we introduced the ability to specify gain values for non-linear power amplifiers.

This patch adds appropriate values for the Station G2, based on the table at https://wiki.uniteng.com/en/meshtastic/station-g2#summary-for-lora-power-amplifier-conduction-test

Fixes #7239

[karman85]

The implemented table seems right for the US_915 domain. This needs a second table to fit EU_868 domain.

[rkneeshaw]

I have a fairly lossy coax and filter setup and I need to be able to use the extra power the G2 has to compensate and get back up to legal limits. Can you confirm these values do not neuter the power capability of the G2? Or does it merely set a default value when firmware is first installed?

[flipty]

There are a lot of Station G2's around the world running long coax runs on towers. Are we just going to tell everyone relying on them as infrastructure that they're going to need to learn to code and use a custom firmware? Tell them to put the G2 next to the antenna and climb the tower if there are issues?

[Marx1]

I have a maor issue with this. The g2 do not have tight quality control and ive had to run a gain for 13 or 14 to get 1w out.

The chart clearly says there is variance in the values and each unit should be tested.

This change assumes 11 gain =1w and it does nt. It also doesnt accout for ham mode, or situations where there are filters or other loss factors needing compensation.

This change should be reverted.

[fifieldt]

@Marx1 , thanks for the report about Ham Mode. That was unintentional, have sent in a patch to fix that: #8322

[rkneeshaw]

@Marx1 , thanks for the report about Ham Mode. That was unintentional, have sent in a patch to fix that: #8322

I think you're missing the point. The issue applies to anyone with an coax/filter/antenna configuration with loss greater than 0db. Its not a ham-mode-only problem.

This isn't the way to solve this.

Just set a default value. Then people that dont' know better are always under the legal limit. But those of us that need the extra power to compensate for losses can still use the hardware we paid for.

[flipty]

This issue could probably be solved with a checkbox with a disclaimer next to it. "Settings above X value may result in transmitting above legal power limit in your location. You are responsible for the repercussions. Are you sure?"

[fifieldt]

This discussion is mainly taking place in discord. Bits of copy/paste from there for those who aren't there but are following along here:

We have set values for all devices so they stay within legal limits out of the box for some time now. The G2 was a kinda leftover that needed to be brought into line with our existing practice.

For those that know enough to run 100ft of LMR400 and calculate cable loss:
What we're fighting for here is to keep everyone's ability to flash firmware on these devices, at all. Those who've been around long enough will remember what happened to Wifi APs, with firmware like openwrt/dd-wrt and the manufacturer "lockdowns". We're at that point in our lifecycle, and we need your help to ensure we get a better outcome this time around.

We have to balance being able to support the masses having a great time, and advanced users like you having the features you need. Both types of people are crucial for the mesh. The assumption is, as advanced users, you are more skilled than the masses and you can tolerate jumping through a hoop to get what you need sometimes rather than having every dial available in a dinky smartphone app :) It's less convenient, sure, but we kinda need to make sure breaking regulations is not convenient 🙂 User groups start spreading the word "you can get better reception if you put 10 in the 'tx_path_compensation' box" (if we had one) and it's game over for us.

For today, I suspect for anyone who managed to find this thread and comment here, editing a number in a text file and pushing a button in vscode won't be a big challenge 🙂 Myself and others are generally happy to have a screen-share session with anyone to educate on how to build firmware. No coding skills are required: install app, edit one value in one text file, select your device from dropdown, press build. For tomorrow, there are people in the community already working on additional ways to support you that will be slightly more convenient.

Additional creative ideas are most welcome :)

[Marx1]

Following this logic, you're now forcing people to be developers. Setting up a dev environment is NOT a trivial matter. For someone who does this day in/day out, it may seem trivial. For others this is akin a non-tech person trying to learn how to build a pc from scratch.

This is NOT an acceptable path. There has to be a middle ground here. This mentality is what drive people away. It's not inclusive, it's exclusive. -

Looking at the part 15 compliance side, It's not your job/meshtastic's job to be compliant. It's the hardware vendor's job, and/or the end user. The vendor must make a device compliant with part 15, OR part 97. If it's part 15, it has to be limited in hardware at 1w. If it's 97, it's the user (ham's) responsibility to comply with part 97 rules.

Putting the part 15 compliance aside, let's discuss real-world measurements of what the 11db setting actually produces - as I think this is a compounding issue.

I have 4 station g2s. 3 are installed at radio sites, one is on my roof As a part of testing (and after the discussions/claims of the "g2 goes deaf" that I won't get into here) I put my g2s on my IFR 1900 set to Long-slow and sent a full 160 character message. This is the exact same test

With the IFR set on peak hold, I had to adjust the 2 of the G2's to be at 12 to get ~950mw (29.7db ), my roof node had to be at 13 to get ~975mw (29.8db) and one node worked at 11. For the two at 12, When I turned it down to 11 I got 750mw out (28.75db), and the roof node I got 500mw (26.9 db). All of this is pretty much in line with the claimed "+/- 1db" per the page, But Niel clearly states they don't control batch-to-batch. And I ordered in two three different batches.

There is inherent issues with Quality control on these devices, and we need to be able to compensate for it. With this change you're preventing us from doing this.

As @rkneeshaw said, why not set a threshold and do an alert like what is done for Router role?

It removes any liability from Meshtastic, it removes it from the manufacturer for someone using the device in a way it was not initially built. It lets those who need to use a higher value to counter issues with amplifier QC to do so, and counter filters in a built package.

[madeofstown]

🌹R.I.P G2🌹

[fifieldt]

Would love to, but sadly that isn't enough for as a regulatory fix as best we know. Maybe worth keeping in mind, we're a global project.

Know this sucks, but it's what we've got until there's a better plan. @NomDeTom has some ideas.

On a personal level: volunteer here. My day job is actually non-technical and I learned all this firmware stuff for fun :) Could not code C++ at all when I started and Vscode was annoyingly elusive until someone in discord taught me the secret incantation. This wasn't a patch that was "fun" to work on, but I volunteered too many hours and the reward for that is to be yelled at for doing the "hard" ones. sigh . There are other people. also volunteers, who are trying to work on better plans as we speak. Just know from the firmware team that: we care about you, and making sure you can have a fun time with Meshtastic too is very important to us -- please believe we're not smashing stuff like this in unnecessarily. If there is a better middle ground we will find it, together.

[rkneeshaw]

The other devices that have limits on them just so happen to not be capable of transmitting over 1w. The Wisblock lets you configure power of 30, but the hardware just so happens isn't capable of going over 22. (I suppose we dont need to talk about what happens if you connect an amplifier to that device....)

You have a software option for HAM mode that does not require compiling code. So clearly software options with appropriate warnings and documentation are sufficient for assumed regulatory compliance within this project.

This change is not in alignment with the rest of the project's configuration design philosophy.

Just face it: this is a very poor, knee-jerk solution to the "problem". Several better solutions have been offered here that would keep the project out of the hot water you're afraid of without unduly penalizing owners of the G2 hardware.

Please revert this change and create a better one.

[flipty]

@fifieldt please understand that nobody is upset with you personally for implementing a software solution.

The point of contention is that there seems to have been a missing piece of the process in the steps leading up to the creation and implementation of the code: Consulting members of the community that would very obviously be impacted by a change such as this.

From my perspective as a coordinator of a regional Meshtastic network, my first thought was "well, I guess it's finally time to start looking into the other mesh software solutions". I'm 100% certain I'm not the only person for whom that sentiment emerged. That also can't be a good thing for the global reach of Meshtastic.

For as much complaining as the community at large does, we love Meshtastic and appreciate the volunteer work that goes into it. Please try not to take criticism over an implementation such as this personally.

[Marx1]

The point of contention is that there seems to have been a missing piece of the process in the steps leading up to the creation and implementation of the code: Consulting members of the community that would very obviously be impacted by a change such as this.

100% agreement here. I do appreciate the creation of the mapping. it makes things easier. My argument is it should be mapped up to the rated p1db point (the actual limit of the radio).

I have reached out to @fifieldt on discord to try and discuss this further/setup a round table to understand the reasoning to why this path was chosen.