at86rf2xx: Add netdev get/set for modulation settings

[jnohlgard]

... in order to allow choosing modulation modes BPSK, O-QPSK, and sub-modes (speed), without recompiling.

See: RF212B data sheet p. 117

[thomaseichinger]

While I think this is a good idea to provide this in general, I ask myself how this would be used? By the MAC? Or the application?

For the at86rf2xx we could use the upper byte of the uint16_t and change the implementation of at86rf2xx_(get|set)_chan in respect.

[jnohlgard]

The main usage would be to be able to choose between 20 kbit/s, 100 kbit/s and 250 kbit/s (for the 868 MHz band) during application design, and not having to resort to modifying upstream OS code. Currently RIOT always uses BPSK, which is the slowest mode.

[PeterKietzmann]

I can't answer how such feature would be used; also I assume that most people want BPSK because it has the lower error probability. But I think that I'd find it confusing to put this switch in the upper byte of the channel option. @thomaseichinger what do you fear by adding a new option to netdev? Dead code? Complexity?

[thomaseichinger]

I'm just thinking loud how to do this best or better said, how to abstract properly as these are highly device dependent settings and different manufacturers may call it differently. Even on the rf231 these are called "High Data Rate Mode". But maybe this already the direction to go. NETOPT_DATA_RATE?

[PeterKietzmann]

@thomaseichinger I agree that it might be too specific to add single modulation options to netdev. I could imagine to add NETOPT_DATA_RATE and document the behaviour properly in the netdev interface and in the driver. Before doing so it might be good to (i) compare other transceivers and (ii) check what the 802.15.4 standard says regarding modulation techniques (honestly I don't know out of my head). What should be avoided (IMO) is to provide an easy way to change the modulation technique, if we break the "standard" with that.

[jnohlgard]

The IEEE 802.15.4 standard has a concept of channel "page" where each page is a different radio encoding. How about adding another getter/setter in the driver to change the 802.15.4 page?

ifconfig 7 set page 2
ifconfig 7 set channel 0

would switch to O-QPSK 100 kbit/s on 868.3 MHz

ifconfig 7 set page 2
ifconfig 7 set channel 5

would switch to O-QPSK 250 kbit/s on 914 MHz

There are also a bunch of proprietary PHY modes which are not part of the 802.15.4 standard (at least on AT86RF212B), I think for the time being it is best to focus on the standard modes only.

edit: The page setter would only be relevant for transceivers with support for more than one page

Below is a summary of what I have gathered from the standard document IEEE-Std-802.15.4-2011

page number	valid frequency bands	description
0	868, 915, 2400 MHz	Binary phase-shift keying (BPSK)
1	868, 915 MHz	Amplitude-shift keying (ASK)
2	868, 915 MHz	Offset quadrature phase-shift keying (O-QPSK)
3	2400 MHz	CSS (same channels as 802.11bgn?)
4	UWB	Ultra-wideband
5	780 MHz	channels 0-3: Offset quadrature phase-shift keying (O-QPSK), channels: 4-7: M-ary phase-shift keying (MPSK)
6	950 MHz	channels 0-9: Binary phase shift keying (BPSK), channels 10-21: Gaussian frequency-shift keying (GFSK)

Excerpt from the standard:

8.1.1 Operating frequency range

A compliant device shall operate in one or several frequency bands using the modulation and spreading formats summarized in Table 66.
Devices shall start in the PHY mode in which they are instructed to start. If the device is capable of operating in the 868 MHz or 915 MHz bands using one of the optional PHYs described in Clause 10 and Clause 12, it shall be able to switch dynamically between the optional PHY and the mandatory BPSK PHY in that band when instructed to do so.
If the 950 MHz band is supported, then at least one of the 950 MHz band PHYs shall be implemented.
Operation of the MPSK PHY in the 780 MHz band is described in Annex G. The CWPAN specification also defines operation in the 314–316 MHz and 430–434 MHz bands, which is not described in this standard.

[jnohlgard]

I am working on a PR for this issue

[jnohlgard]

I need to get xtimer working properly again on mulle before I can finish the PR I talked about.

[jnohlgard]

Is there any interest in adding simultaneous support for 2.4 GHz and sub-GHz transceivers in the same binary?
I noticed a few places where there will be symbol conflicts if both MODULE_AT86RF233 and MODULE_AT86RF212B is enabled.

[OlegHahm]

Is there any interest in adding simultaneous support for 2.4 GHz and sub-GHz transceivers in the same binary?

Sorry for the high latency. I think in general this should be possible, yes.

[thomaseichinger]

@gebart @OlegHahm I think this is solved by #4412? Should we take the simultaneous use of the driver for two different base bands to a new issue?

[OlegHahm]

Makes sense for me.

[jnohlgard]

closing since this was resolved by #4412 (see comments above)