drivers/at86rf215: implement MR-FSK

[benpicco]

Contribution description

This adds the MR-FSK modulation to the at86rf215 driver.
You can configure all possible combinations of settings, grouping those settings to "FSK Modes" as per 802.15.4 is out of scope of the driver and should become part of the new 802.15.4 sub-MAC so it can be shared with other drivers implementing MR-FSK.

The same goes for channel spacing. @tinstructor added the option to toggle between 200 kHz and 400 kHz channel spacing (600 kHz is omitted for now), but again this is hardly useful isolation and should not be specific to MR-FSK.

Again, sorting this out properly would have to be done in common code (and deriving the number of channels from frequency band with / channel spacing if possible).

@jeandudey do those settings also make sense for cc26x2_cc13x2_rf?

Testing procedure

You should now be able to configure the mr-fsk phy mode on boards with the at86rf215 driver.

2020-09-07 00:37:02,866 #  ifconfig 6 set phy mr-fsk
2020-09-07 00:37:05,846 # Iface  6  HWaddr: 04:8F  Channel: 0  NID: 0x23  PHY: MR-FSK 
2020-09-07 00:37:05,854 #            modulation index: 1  2-FSK  symbol rate: 50 kHz  FEC: none  BW: 400kHz 
2020-09-07 00:37:05,858 #           Long HWaddr: 1A:F9:8F:5F:30:5D:04:8F 
2020-09-07 00:37:05,865 #            TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4 
2020-09-07 00:37:05,871 #           AUTOACK  ACK_REQ  CSMA  L2-PDU:2022  MTU:1280  HL:64  RTR  
2020-09-07 00:37:05,873 #           6LO  IPHC  
2020-09-07 00:37:05,876 #           Source address length: 8
2020-09-07 00:37:05,879 #           Link type: wireless
2020-09-07 00:37:05,884 #           inet6 addr: fe80::18f9:8f5f:305d:48f  scope: link  VAL
2020-09-07 00:37:05,887 #           inet6 group: ff02::2
2020-09-07 00:37:05,890 #           inet6 group: ff02::1
2020-09-07 00:37:05,893 #           inet6 group: ff02::1:ff5d:48f

You should be able to set modulation order, symbol rate, forward error correction and modulation index.

2020-09-07 00:39:25,712 #  ifconfig 6 set srate 200
2020-09-07 00:39:39,103 #  ifconfig 6 set mord 4
2020-09-07 00:39:56,624 #  ifconfig 6 set fec rsc
2020-09-07 00:40:21,936 #  ifconfig 6 set modulation_index 3/4

2020-09-07 00:40:25,611 # Iface  6  HWaddr: 04:8F  Channel: 0  NID: 0x23  PHY: MR-FSK 
2020-09-07 00:40:25,619 #            modulation index: 3/4  4-FSK  symbol rate: 200 kHz  FEC: RSC  BW: 400kHz 
2020-09-07 00:40:25,623 #           Long HWaddr: 1A:F9:8F:5F:30:5D:04:8F 
2020-09-07 00:40:25,630 #            TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4 
2020-09-07 00:40:25,636 #           AUTOACK  ACK_REQ  CSMA  L2-PDU:2022  MTU:1280  HL:64  RTR  
2020-09-07 00:40:25,638 #           6LO  IPHC  
2020-09-07 00:40:25,641 #           Source address length: 8
2020-09-07 00:40:25,644 #           Link type: wireless
2020-09-07 00:40:25,649 #           inet6 addr: fe80::18f9:8f5f:305d:48f  scope: link  VAL
2020-09-07 00:40:25,652 #           inet6 group: ff02::2
2020-09-07 00:40:25,655 #           inet6 group: ff02::1
2020-09-07 00:40:25,658 #           inet6 group: ff02::1:ff5d:48f

Communication should still work.

2020-09-07 00:43:25,820 #  ping6 ff02::1%6
2020-09-07 00:43:25,837 # 12 bytes from fe80::18f9:8f5f:305d:48f%6: icmp_seq=0 ttl=64 rssi=-30 dBm time=11.322 ms
2020-09-07 00:43:26,829 # 12 bytes from fe80::18f9:8f5f:305d:48f%6: icmp_seq=1 ttl=64 rssi=-30 dBm time=11.319 ms
2020-09-07 00:43:27,853 # 12 bytes from fe80::18f9:8f5f:305d:48f%6: icmp_seq=2 ttl=64 rssi=-30 dBm time=28.797 ms
2020-09-07 00:43:27,853 # 
2020-09-07 00:43:27,854 # --- ff02::1 PING statistics ---
2020-09-07 00:43:27,856 # 3 packets transmitted, 3 packets received, 0% packet loss
2020-09-07 00:43:27,868 # round-trip min/avg/max = 11.319/17.146/28.797 ms

However, not all combinations will produce valid results.

Issues/PRs references

split off #12128
#13295 implements a driver for a different MR-FSK radio

[fjmolinas]

@jeandudey do those settings also make sense for cc26x2_cc13x2_rf?

@jeandudey if you can give the common mr-fsk code a look it would be much appreciated!

[benpicco]

Rebased to re-add RPC

[jeandudey]

Hi! Sorry for the late response. Yesterday I took a look on the code and it seems very well written and everything here applies on the other driver as much on the netdev driver configuration.

Another options I saw on the AT86RF215 datasheet that are configurable too on the cc26x2_cc13x2_rf driver was the Data Whitening option (phyFSKScramblePSDU) which is enabled by default for 802.15.4g and it's fixed by TI :-( and could affect interoperability between the two transceivers, the Preamble Length (phyFSKPreambleLength) which is not mandatory to have as a configuration option but could be good to have the same value on both radios as default, the FCS type e.g. for 16-bit or 32-bit CRC which in theory both modes are supported on cc26x2_cc13x2_rf although I have only used the 32-bit CRC.

Overall the only options that may affect interop are Data Whitening and the FCS, the SFD is another factor that could affect but I may assume that AT86RF215 uses the default values the IEEE 802.15.4g standard provides (see 85423bd) when using FEC or not, although it could be nice if could be selected between phyMRFSKSFD=0 and phyMRFSKSFD=1.

[benpicco]

Another options I saw on the AT86RF215 datasheet that are configurable too on the cc26x2_cc13x2_rf driver was the Data Whitening option (phyFSKScramblePSDU) which is enabled by default for 802.15.4g and it's fixed by TI

That can be enabled / disabled by toggling the DW bit the FSKPHRTX register.
It's enabled by default and I didn't touch it, but I can make it configurable via ifconfig if that's useful.

the Preamble Length (phyFSKPreambleLength) which is not mandatory to have as a configuration option but could be good to have the same value on both radios as default,

I got the minimum preamble length for a symbol rate from Table 6-64 of the at86rf215 data sheet.
That is the minimal preamble length on RX to recognize the start of a frame.
On TX it will send 8x that length. It has to send more preamble than the minimal length to allow for robust recognition, but I don't remember how I arrived at the 8x figure.

the FCS type e.g. for 16-bit or 32-bit CRC which in theory both modes are supported on cc26x2_cc13x2_rf although I have only used the 32-bit CRC.

Yea I only ever used 16-bit FCS like the old modes did.
IIUC it should be possible to receive frames of both types and the transceiver will tell them apart by a bit in the header.

Again, I can add a config option for that. That would apply to all 802.15.4g modes.

it could be nice if could be selected between phyMRFSKSFD=0 and phyMRFSKSFD=1.

Do you also want to set the content of the start of frame delimiter? :D
But I see that they have different defaults, probably as per standard.
What is the meaning of the two SFDs? When would you chose one over the other?

[jeandudey]

That can be enabled / disabled by toggling the DW bit the FSKPHRTX register.
It's enabled by default and I didn't touch it, but I can make it configurable via ifconfig if that's useful.

If enabled by default it could then be leaved as is, it could only make sense to disable DW for testing purposes.

Do you also want to set the content of the start of frame delimiter? :D
But I see that they have different defaults, probably as per standard.

Right now it isn't needed until some rare 802.15.4g transceiver appears with rare configurations :P so I wouldn't bother with it.

What is the meaning of the two SFDs? When would you chose one over the other?

The SFD changes between 2-FSK and 4-FSK (2 octets vs 4 octets), and when using FEC or not. Selecting between one group or another it's just a matter of taste, and only mandatory for Common Signaling Mode to use a phyMRFSKSFD=0, but so far I haven't seen CSM out there.

IIUC it should be possible to receive frames of both types and the transceiver will tell them apart by a bit in the header.

My bad, revisited the configurations for cc26x2_cc13x2_rf and it should receive both types of packets depending on the bit in the PHR and uses a 16-bit CRC for FCS so it should be fine as is.

[benpicco]

Ok, I'll keep the amount of ifconfig tunables at a minimum then :)
They take up considerable amount of space and we don't have a good way to make them optional yet.
And ideally the user wouldn't have to deal with those settings anyway.

What is the meaning of the two SFDs? When would you chose one over the other?

The SFD changes between 2-FSK and 4-FSK (2 octets vs 4 octets), and when using FEC or not.

Hm both config registers for SFD0 and SFD1 are 2 octets - do you suggest both are used for 4-FSK and FEC?

revisited the configurations for cc26x2_cc13x2_rf and it should receive both types of packets depending on the bit in the PHR and uses a 16-bit CRC for FCS

Ah I reckon cc26x2_cc13x2_rf doesn't do the CRC verification in hardware then?

[jeandudey]

Ah I reckon cc26x2_cc13x2_rf doesn't do the CRC verification in hardware then?

It was me 😅 that didn't verified how it handled the FCS bit on the PHR, it will work with both and has to be specified on TX manually by setting/clearing the FCS bit on the PHR which now defaults to 16-bit CRC. It indeed handles CRC verification on hardware.

[fjmolinas]

Some nitpicks, otherwise looks good.

[fjmolinas]

there is one in frac.c can't you use that?

[benpicco]

yea that just looked so complex and I didn't need speed here 😅
I could make it public and use it, or move the frac_short()/frac_extend() code there.

But realistically those parameters are not supposed to be set by the user to begin with.
Ok, it's still nice having them displayed in ifconfig, but ideally we will have a database with settings combinations for different FSK modes for different regions and frequency bands.

[fjmolinas]

You lost me a bit a here, where would this database/table be used?

[benpicco]

As with WiFi different world regions have varying regulations as to what portions of the spectrum you may use and how you may use it. And while the 2.4 GHz ISM band can be used everywhere, for sub-GHz different countries use different frequencies for ISM and the standard prescribes different modulation parameters for those frequencies.

So in the end you would really want to be able to "set region EU, set fsk_mode 3" and not worry about the details.

But that should be handled outside the driver so other MRSUN-FSK like cc26x2_cc13x2_rf can also benefit from it.

[fjmolinas]

I played around changing configurations and pinging everything seems OK.

[fjmolinas]

@jeandudey are you fine with the general FSK stuff?

[jeandudey]

@jeandudey are you fine with the general FSK stuff?

Yes, everything seems very well to me in regards with the netopt options and will map 1to1 to the cc26x2_cc13x2_rf driver.

[fjmolinas]

Please squash @benpicco !

[fjmolinas]

ACK!