Support downchirp frames dev

[leoposc]

Hello @tapparelj,

first of all, thank you for this great project!

As others have had this issue (#123) before me, I require to receive downlink as well as uplink messages. I do not want to compromise receiving uplink frames, so adding a conjugate block before the Frame Sync block is not sufficient for me.

Instead I modified your code inside the Frame Sync block - basically copying the input signal and repeat all necessary computations for the conjugated input signal. Incrementing two separate symbol_counters and lastly using the "normal" or conjugate input for the further computations, depending on which symbol_counter is larger.

I tested my code with a dragino temperature and humidity sensor, which initially sends 2 packets with SF7 and 1 packet with SF12.

I successfully received the complete communication between the dragino sensor and my LoRaWAN gateway. So when sniffing for LoRaWAN packets with SF7, I get:

• join request (Sensor → GW)
• join accept (GW → Sensor)
• unconfirmed data up (Sensor → GW)
• unconfirmed data down (GW → Sensor)

--------Header--------
Payload length: 23
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x41, 0x40, 0xa8, 0x58, 0x7f, 0x87, 0x41, 0x3c, 0x41, 0x40, 0xa8, 0x42, 0xe, 0xd0, 0xbc, 0x15, 0x10
CRC valid!


--------Header--------
Payload length: 33
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x20, 0x71, 0x22, 0x3a, 0x36, 0xb9, 0x40, 0xf7, 0x98, 0xf3, 0x52, 0x28, 0x8c, 0x1e, 0x24, 0x33, 0xda, 0xc7, 0x11, 0x6e, 0xf4, 0xf5, 0x47, 0xfd, 0xa5, 0xfc, 0x6b, 0x99, 0x12, 0x94, 0xe6, 0x74, 0xbc
CRC valid!


--------Header--------
Payload length: 29
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x40, 0xdd, 0x2d, 0x39, 0x1, 0x85, 0x1, 0x0, 0x3, 0x7, 0x6, 0x64, 0x6, 0x2, 0x4a, 0x13, 0x82, 0xe7, 0xc6, 0x44, 0x80, 0x86, 0xee, 0xc6, 0x94, 0xc0, 0xa2, 0x57, 0xa7
CRC valid!


--------Header--------
Payload length: 17
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x60, 0xdd, 0x2d, 0x39, 0x1, 0x85, 0x1, 0x0, 0x3, 0x55, 0xff, 0x0, 0x1, 0xe0, 0xb8, 0x24, 0xb9
CRC valid!


======================================
  LORAWAN COMMUNICATION WAS RECORED 
      RECORDING  REPEATS HERE
======================================


--------Header--------
Payload length: 23
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x41, 0x40, 0xa8, 0x58, 0x7f, 0x87, 0x41, 0x3c, 0x41, 0x40, 0xa8, 0x42, 0xe, 0xd0, 0xbc, 0x15, 0x10
CRC valid!


--------Header--------
Payload length: 29
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x40, 0xdd, 0x2d, 0x39, 0x1, 0x85, 0x1, 0x0, 0x3, 0x7, 0x6, 0x64, 0x6, 0x2, 0x4a, 0x13, 0x82, 0xe7, 0xc6, 0x44, 0x80, 0x86, 0xee, 0xc6, 0x94, 0xc0, 0xa2, 0x57, 0xa7
CRC valid!


--------Header--------
Payload length: 17
CRC presence:   1
Coding rate:    1
Header checksum valid!

rx msg: 0x60, 0xdd, 0x2d, 0x39, 0x1, 0x85, 0x1, 0x0, 0x3, 0x55, 0xff, 0x0, 0x1, 0xe0, 0xb8, 0x24, 0xb9
CRC valid!

Wireshark is able to successfully dissect the packets, which proves to me that it works, but apparently my code extension is not stable. I recorded the communication between the GW and Sensor, so the input stays constant, however not all packets are constantly recognised by my flow graph. I used the File Source block and set repeat=True. As you can see above, the second time only 3 out of 4 packets were received.

To summarise, the code works, but still has some bugs/ is unstable.

With my limited knowledge in DSP, I am not able to figure out the last missing part, but I thought I leave this here. Maybe this partly solution helps somebody else as well, you or anybody else is motivated to look over it and spot the bug. I happily contribute, but am definitely not offended if you just decline this pull request.

Thanks again for all your work! Cheers!

[tapparelj]

It's nice to see that you managed to decode some downlink messages!
As it's not in a stable state currently, I won't directly merge it, but I will keep this pull request open as a good starting point for fully adding downlink support.