Skip netid2 check if requested

[mskvortsov]

It seems that a complete decoding of SX1272/62 sync words would require an additional reverse engineering effort of how exactly these chips generate the frame sync portion of a packet. According to this research, there are some opaque intricacies indeed, and there are rumors that no other values except 0x3444/0x1424 are recommended for use.

This change (partially) works around the issue by skipping the check of the second sync word if requested. To skip, set the second part of the Frame Sync block parameter to zero, e.g. [16, 0]. According to the link above, zero word is invalid anyway so it presumably can be used for this purpose.

A bit more of details are in #91 (comment).

[miweber67]

Perhaps an option to skip all syncword checks, a 'promiscuous mode' if you will, would be useful as well. If either syncword is zero, don't enforce it.

This is an interesting read in case you haven't seen it yet:

https://blog.classycode.com/lora-sync-word-compatibility-between-sx127x-and-sx126x-460324d1787a

EDIT: I see now that that was the very article you liked behind 'this research.' :-\ sorry!

[tapparelj]

Hello,
the first network ID is used to identify a misalignment by one entire symbol at some stage of the synchronization.
So ignoring the second network Id and printing the value found is entirely fine for me. For ignoring the first network ID as well, we should also ignore the synchronization by one symbol which will not cause issue at high SNRs, but will sometime miss frames at low SNRs.
Let me know if you want to update to pull request to allow both values to be put to 0 before I merge it or leave it as it is now.

[mskvortsov]

@tapparelj Hi! Added a bypass for netid1 too. And yes, I see some additional crc failures on a weak signal with this turned on, but it's just an optional feature, so let it be.