Duplicate receive from radio causing witness_on_incorrect_channel

[bilalhp]

Hello,

Sometimes I receive the same packet twice from my Sensecap's radio in different frequencies. Example:

{"rxpk":[{"jver":1,"tmst":326543228,"chan":2,"rfch":1,"freq":868.5,"mid":0,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","foff":-1703,"size":52,"data":"QDDaAAF0gzmUALCCAGOmRDHo+rxtCtGTvY2e0eHbx0UvYZIZvXeaRXmaE+y6Q/kxmOTOvg==","rssi":-106,"rssis":-103,"lsnr":-5.4},{"jver":1,"tmst":326543236,"chan":5,"rfch":0,"freq":867.5,"mid":2,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","foff":-1734,"size":52,"data":"QDDaAAF0gzmUALCCAGOmRDHo+rxtCtGTvY2e0eHbx0UvYZIZvXeaRXmaE+y6Q/kxmOTOvg==","rssi":-95,"rssis":-105,"lsnr":-6.8}]}

Depending on which one my miner can submit to the challenger first, I sometimes get "witness_on_incorrect_channel".

Since this check is being done in blockchain_txn_poc_receipts_v1:tagged_witnesses() instead of miner_poc_statem:receiving(), my correct witness is being discarded. If that would have been checked before the witness is being added to the list in miner_poc_statem:receiving() this could be saved.

Can you consider doing this fix?

Regards.

[abhay]

This appears to be a misconfiguration on sensecap's packet forwarder? There should really only be one packet being presented to the miner. Could you check with Sensecap to see if they're aware of this issue? I'll close this for now but feel free to reopen or have them jump in on this thread if needed.

[bilalhp]

@abhay

This is not a misconfiguration. I believe this is not specific to Sensecap and happening on other devices as well. I identified two cases that cause this:

1) When you use high-gain antenna, the radio can hear back its own packet from another frequency (channel) -> This is not an issue (because it is a self witness that will be dropped) but just a data point 2) When the signal is very strong (TX and RX both high gain antennas and they are close), the radio can decode a reflection of the packet as from another channel when the "interference" is strong enough.

I don't believe there is anything that can be done by Sensecap or Semtec.

Your response still doesn't explain why you don't consider my proposal to fix this which I believe is a lot more logical than the current implementation. This is an improvement. Even if this is a bug in radio or hotspot side, the current implementation is not fair. If an hotspot can eventually deliver a correct packet, it should be rewarded (or at least a candidate to be rewarded) and it should not be punished because it delivered a wrong packet a split second ago.

Let me know what concerns you about my proposal.

[abhay]

I'll reopen since it's not particular to SenseCAP. As far as doing witness validation before entering the Challenger's buffer, it's important to get invalid and valid witnesses that have been submitted to Challengers on chain as it improves data gathering.

We'll have to look a little more about whether or not it makes sense for a potentially invalid witness to be replaced by a valid one if it arrives later, what specific cases we'd want to support, and what level of effort it would take to refactor the code to include the validation path into miner_poc_statem:receiving(), etc.

cc: @vihu @Vagabond

[KT053374]

This is also happening to bobcat gateways. "ota_version": "1.0.2.79", "region": "region_us915", "frequency_plan": "us915",

"Image": "quay.io/team-helium/miner:miner-arm64_2022.01.29.0_GA",

[Vagabond]

This usually only happens when you are extremely close to the transmitter and see a side lobe. It doesn't look like you'd earn anything from this witness anyway because of the proximity?

[KT053374]

I have always earned on witnesses for this station. He's not the only station this has happened with either.

This one is even further away and should qualify as a valid witness.

Seems to be consistently off by 1-Mhz on the freq.

[ke6jjj]

@bilalhp since you have firmware access, can you get at the packet forwarder configuration being used? It would be great to see it here, as an attachment. I've started seeing this very behavior on a new RAK 5146 unit (using the sx1303) and I'm starting to wonder if we might have an issue with the packet forwarder configuration that vendors are using. One possible way you could get conflicting channel information like this is if there's an unintended overlap in the modem assignments in the forwarder. I say so because I notice that your duplicated packets come from different modem identifiers (mid in the JSON). This is just a hypothesis at the moment.

[bilalhp]

See attached.

global_conf.json.sx1250.EU868.txt