Forming the correct "rxpk" and "txpk", Lora-Semtech-Bridge or LoraServer and the "rfch" to go for

[Mehradzie]

At the moment When LoraServer forms a packet and sends it over MQTT, we see something like the message below before it hits the Lora-Semtech-Bridge.

{"txInfo":{"mac":"008000000000aaaa","immediately":false,"timestamp":1886440700,"frequency":925700000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5"},"phyPayload":"FFoo="}

Late on the bridge receives this and makes it like how LoRaWAN package should look like,

{"txpk":{"imme":false,"tmst":1886440700,"freq":925.7,"rfch":1,"powe":20,"modu":"LORA","datr":"SF10BW500","codr":"4/5","ipol":true,"size":17,"data":"ffOO"}}

One idea could be that in the long run, just to map the values to the correct format on the LoraServer dependent on the chip we are sending it to (in this case Semtech).

And also some information such as the rfch value is never been assigned through the code so it gets defaulted to zero on txpk. This limits the gateways e.g. with only Radio 1 enabled (set in the packet forwarder) cuz the txpks sent over rfch 1 will be replied on rfch 0 rather than 1.

So I was thinking in the normal situation which the hybrid gateway is using it's both rfchs (both SX1257 s), why not to actually alternate the rfch on the txpk at the LoraServer to share the load between two SX1257s rather than hammering one all the time.

This also could potentially prevent the packages to be overwritten on SX1301 until they move the experimental-Just-in-Time-Queue implementation of Semtech Packet Forwarder to the master branch and release it.

(Meanwhile, the easy solution) would to read the rfch value from rxpk and assign it to the same key on rxpk rather than letting it getting defaulted. :raised_hands:

[nestorayuso]

I think rfch parameter is to distinguish between several RX paths (aka physical antennas) rather than SX1257 chips. Imaging a high performance gateway with three sectorial antennas and three SX1301 chips. rfch indicates which sector received from.

typical gateway implementations use two SX1257 chips and both share the same antenna, both are RX capable but only one is TX capable. In this case I think rfch should be always 0. But maybe there is some gateway with two SX1257, both RX and TX capable and each one use different antenna, in this case rfch can be 0 or 1.

As a resume, if the network server want to send a message to a node, it must use the same rfch than the one through previously received a message.

[brocaar]

I did some testing with this, if I remember correctly I was unable to send using rfch=1. Will do some more testing tonight.

[brocaar]

Just did some testing again. The join-request was received on rfch: 1. The join-accept was sent with the same rfch: 1 to the gateway. This resulted in the following error (packet_forwarder):

ERROR: SELECTED RF_CHAIN IS DISABLED FOR TX ON SELECTED BOARD
WARNING: [down] lgw_send failed

Snippet from my radio config:

       "radio_0": {
            "enable": true,
            "type": "SX1257",
            "freq": 867500000,
            "rssi_offset": -166.0,
            "tx_enable": true
        },
        "radio_1": {
            "enable": true,
            "type": "SX1257",
            "freq": 868500000,
            "rssi_offset": -166.0,
            "tx_enable": false
        },

[Mehradzie]

To be honest I just recently got to know that radio tag has those extra keys from an IM880 datasheet (which I don't own). Mine is very simple

    "radio_0": {
        "enable": true,
        "freq": 915500000
    },
    "radio_1": {
        "enable": true,
        "freq": 916300000
    }

Have you tried setting tx_enable to true? (I mean for testing purposes)

@nestorayuso

typical gateway implementations use two SX1257 chips and both share the same antenna, both are RX capable but only one is TX capable.

By "TX Capable" you mean the actual physical capability? If so, I wasn't aware of SX1257 have two edition. And if software enables (capable) what stops us from enabling them both? And also, as I mentioned before most of my knowledge in this part is based on guesswork. I would wonder where did you learn these information from such as,

rfch parameter is to distinguish between several RX paths (aka physical antennas) rather than SX1257 chips

Cheers guys

[nestorayuso]

there is only one implementation of sx1257. with capable or not capable I mean enabled in the json file and physically routed tx pins in a pcb to a balun, PA, antenna.

my knowledge is based on guesswork too and maybe i am wrong on rfch or other assumptions

[Mehradzie]

Let guess our way to success :smile: The downside of any new tech. No docs and lots of potential.

So you reckon what would be the problems if we enable both radios to TX as well.

Thanks for the reply

[nestorayuso]

As your gateway's pcb does not route physically TX pins to a balun... If you enable it in json, the TX range will be zero or few centimeters.