BastilleResearch / gr-lora

GNU Radio OOT module implementing the LoRa PHY, based on https://github.com/matt-knight/research/tree/master/2016_05_20_jailbreak
GNU General Public License v3.0
472 stars 92 forks source link

Failure to decode messages from Multitech xDot #24

Closed jcard0na closed 6 years ago

jcard0na commented 6 years ago

I'm experimenting with gr-lora, trying to decode messages sent by a Multitech xDot (915MHz).

So far I am able to receive PDUs but the payload is incorrect.

The example is the peer_to_peer_example.c from these examples.

I zeroed the application and network keys, and also the payload, which is just { 0x00, 0x00 }.

I do not know if the xDot library sends an explicit header or not. I could not find that information. If that is the case, I understand the decoder will not be able to decode the messages.

Can someone confirm if this is what happens by inspecting the receiver output pasted below?

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd a6 cc c3 4f 32 3f 30 0a 10 
0010: 16 2d f5 38 25 14 3b 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd 97 dc c3 4f 32 1d 84 3a 49 
0010: a4 00 8b 36 a3 18 3b 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd 86 cc c3 4f 53 39 51 c9 5b 
0010: 1f c7 66 06 a3 18 3b 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 23
contents = 
0000: 0f fd 09 50 0e 4e dd b7 d8 c3 4f 63 6b 4b 93 61 
0010: 7b 9a f6 24 a1 18 3b 
***********************************

screenshot from 2017-11-24 10-00-44

Thanks!

jcard0na commented 6 years ago

I'm getting closer on this. I switched to a different driver for the xDot that exposes low level access to the radio and turn off the explicit header. I am configuring the radio as shown below, which I understand is a supported configuration:

int main()
{
    (...)
    radio.set_frf_MHz(915.5);
    lora.enable();
    lora.setBw_KHz(500);
    lora.setSf(8);
    lora.setHeaderMode(false);
    lora.setCodingRate(4);
    lora.setRxPayloadCrcOn(false);

    (...)

    /* constant payload length of four bytes */
    lora.RegPayloadLength = 1;
    radio.write_reg(REG_LR_PAYLOADLENGTH, lora.RegPayloadLength);

    for (;;) {
        radio.tx_buf[0] = 0x00;  /* set payload */
        lora.start_tx(lora.RegPayloadLength);   /* begin transmission */

        while (lora.service() != SERVICE_TX_DONE)   /* wait for transmission to complete */
            ;

        radio.set_opmode(RF_OPMODE_STANDBY);
        wait(1);  /* throttle sending rate */
        logInfo("waiting for 1s");
    }
}

As shown above, the payload is one byte (0) and now I'm receiving. If I change the payload to 0xff, the first nibble of the third byte changes from 0 to f.

***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 7
contents = 
0000: ef f6 0f c7 f2 24 22 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 7
contents = 
0000: ef f6 0f 47 72 2c 22 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 7
contents = 
0000: ef f6 0f e7 f2 2c 22 
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 7
contents = 
0000: ef f6 0f c7 f2 b4 22 
***********************************

screenshot from 2017-11-27 19-34-06

jcard0na commented 6 years ago

I was finally able to get this to work by changing

 lora.setHeaderMode(false);

with

 lora.setHeaderMode(true);

I had incorrectly assumed that setHeaderMode to true would add the explicit header, when it is the opposite.

After changing that I can send small payloads (<3 bytes) without errors. Yay!