shell_commands: gnrc_netif: add support for getting/setting PHY modes & options

[benpicco]

Contribution description

I'm getting afraid that if #12128 gets too big, nobody will review it, so I factored out the part that makes changes to common code.

This patch adds support for setting PHY modes as specified in 802.15.4 as well as those added in IEEE 802.15.4g-2012.

If the driver implements support for it, this adds commands to configure

• Chip/s & rate mode for O-QPSK
• Modulation / Coding Scheme and Option for OFDM
• Modulation Index, Modulation Order, Symbol Rate and Forward Error Correction for FSK

Modulation Index is represented as fractions of 64 to ease implementations.

Some options are also applicable for at86rf2xx and mrf24j40 (probably others too, I just didn't look), they could also add more configurable for e.g. BPSK options.
I will add try to add implementations for some existing drivers to this PR.

Testing procedure

ifconfig 7 set phy_mode FSK
ifconfig 7 set modulation_index 1/2
ifconfig 7 set symbol_rate 150
ifconfig 7 set forward_error_correction NRNSC

Should do nothing unless the driver supports it.

Or on samr30-xpro you should now be able to to the following:

ifconfig 7 set rate_mode 2
ifconfig 7 set chip_rate 400

You should get

 Iface  7  HWaddr: 34:82  Channel: 0  Page: 2  NID: 0x23 PHY: O-QPSK 
            chip rate: 600 rate mode: 2 (legacy) 
           Long HWaddr: 79:7A:34:2F:9D:73:B4:82

Issues/PRs references

#12128 is the first driver to make use of this interface
#12185 implements the interface for at86rf2xx

[benpicco]

no reviews yet, so I guess it's OK to force-push

Just querying & displaying the PHY mode grows ROM on samr21-xpro by 152 bytes.

[benpicco]

With gnrc_netif_phy_oqpsk enabled on samr21-xpro, an additional 868 bytes of ROM are used compared to master.

[jcarrano]

I don't know much about the network stuff, but looking at this PR I can tell it should be split into the AT86RF2XX driver changes and the network ones because:

1. They are unrelated changes.
2. The AT86RF2XX is quite messy- it will be cleaner for it to have its own PR.

[benpicco]

I agree, I wanted to provide it as an example outside of at86rf215, but better make a separate PR for this then.

[benpicco]

rebased to #12295

[tinstructor]

As I mentioned in #12128 :

@benpicco By now I've read the IEEE802.15.4-2015 spec about a zillion times and I'm still discovering things that previously weren't clear to me. Seriously, it's become a hot mess the past 10 years.

If it's up to me, for now, I'd just do the same for FSK as you did for OFDM, i.e., an FSK phy_mode + 3 operating modes with different properties. You could just configure all parameters manually according to a user specified operating mode and the frequency band in which the radio is currently operating. Also, I'd just leave out every band but the 2.4GHz and 868MHz bands (and maybe 915MHz). I do agree that there should be a more standardized way but I can't seem to find any usefull reference to channel pages in the current spec.

EDIT
The reason why it probably doesn't work like that anymore is because you can't just go and randomly assign a range of channels to a specific modulation scheme. Previously all communications occured in a single channel but with the addition of 802.15.4e (TSCH specifically) it would now be a waste of perfectly good channels. But that's just my guess.

For example, this would reduce the FSK config steps (through the shell) to:

ifconfig 7 set phy_mode fsk
ifconfig 7 set operating_mode 1

Internally (similar to how you did it for OFDM), this would then result in a number of spi commands that configure the AT86RF215 radio according to the frequency band and operating mode. The proper config parameters (i.e., data rate, modulation index, modulation order, channel spacing) depend on the frequency band and operating mode and can be found in table 20-6 and table 10-10. I agree that this doesn't use the FSK capabilities to its full potential but then at least it's according to spec because as of now, e.g., the sub ghz channel spacing is hardcoded as 200 kHz and setting a modulation index of 0.33 with a data rate of 200 kHz and a modulation order of 4 would cause adjacent channels to overlap significantly.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[fjmolinas]

Should we close this one @benpicco I think it got in your last at876rf215 PR, right?

[benpicco]

Yes this is already partially in and will now be added as part of the new modulations.