search

helium / miner

Miner for the helium blockchain
Apache License 2.0
609 stars 266 forks source link

TX Power still too high in EU with high-gain antennas and this leads PoC invalids #1363

Open bilalhp opened 2 years ago

bilalhp commented 2 years ago

Hello,

According to the code here:

https://github.com/helium/sx1302_hal/blob/75b911a6aa0957ab3f3258e083772af7155f27f4/packet_forwarder/src/lora_pkt_fwd.c#L2893

...and the config file:

https://github.com/helium/sx1302_hal/blob/75b911a6aa0957ab3f3258e083772af7155f27f4/packet_forwarder/global_conf.json.sx1250.EU868#L22

(which is exactly the same as my stock Sensecap uses) even though I asset 8 dbi antenna gain because I am using an 8 dbi antenna, I see the "powe" sent to the semtec as "8" but due to the lack of range it falls back to the lowest setting, which is

            {"rf_power": 12, "pa_gain": 1, "pwr_idx": 4},

I see this in the radio logs which also proves my point:

WARNING: Requested TX power is not supported (8dBm), actual power used: 12dBm

Thus,

1) Even with Pocv11 the current design is not fully regulatory compliant 2) This leads to invalids with high gain antennas although I have asserted the correct antenna gain - seems not fair

Can you confirm this is the case, and is there a way to fix this?

Regards.

Domain4dmin commented 2 years ago

That is my observation too. Extending the LuT of the packet forwarder should help. This issue should probably be raised in the paket forwarder repo.

bilalhp commented 2 years ago

This is a serious problem for PoC11. I experience a lot of invalids in my beacons due to this because I believe PoC11 FSPL calculation assumes we transmit less power but in reality it isn't. @ke6jjj is there anything we can do about this? I think all manufacturers should be notified to fix this.

ke6jjj commented 2 years ago

@bilalhp I see some issues here, yes. But let's clarify something.

"I believe PoC11 FSPL calculation assumes we transmit less power but in reality it isn't."

The validation code takes the reported power into consideration. That's entirely why the miner even bothers to receive and parse the TX_ERROR report. The code for recording the actual transmitted power is here:

https://github.com/helium/miner/blob/b845486b1fb7259438fb9b10715bc50771272049/src/poc/miner_onion_server.erl#L419

The reported transmit power is taken into account when judging the FSPL limit here:

https://github.com/helium/blockchain-core/blob/88ce54f0203c8af0c4fd6b8bafdd39ed7d9ff4d7/src/transactions/v2/blockchain_txn_poc_receipts_v2.erl#L1151

So if you are receiving invalidations due to the witness reporting an RSSI that is too high, it's not likely that they'd clear up if your transmit power was lowered. The blockchain is already taking the fact that you transmitted at +12 dBm into consideration and giving you +4 dB of headroom to account for it. If your concentrator is patched to transmit at +8 dBm, then the threshold on the receive side will be lowered by 4 dB as well.

As I see it, what you've actually done is uncovered two bugs, but neither of which is going to help you personally when solved:

  1. The packet forwarder software is supposed to choose the next lowest available power setting, but in this case it is choosing a higher power setting. Fixing this bug would mean that your hotspot should refuse to transmit the packet at all. (You probably won't like this).

  2. Your manufacturer should probably fill in the LuT for conducted powers lower than +12 dBm. I don't believe we've ever given anyone explicit guidance for this, but perhaps it is time.