I'd like to do some low bandwidth realtime* streaming to a Raspberry Pi Zero W. Since the required bandwidth is much lower than even the lowest WiFi speeds, but dropped packets and jitter will cause problems, I'd like to configure the WiFi link to use a fixed, low bitrate.

Is this possible, and if so, how?

* For those not familiar, "realtime" means a late packet is a useless packet. Think of something like a phone call: a re-transmitted packet that arrives late is worthless because the audio has already played past that point. For this reason, reacting to failures isn't a very good option: more important is to avoid the failures in the first place, even if that means sacrificing maximum attainable throughput.


You can use the iw command to set the bitrate. With calling its help you will find:

dev <devname> set bitrates [legacy-<2.4|5> <legacy rate in Mbps>*] [ht-mcs-<2.4|5> <MCS index>*] [vht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4] [sgi-5|lgi-5]

For example to limit the bitrate to 12 Mbps on the 2.4 MHz band you can use:

rpi ~$ sudo iw wlan0 set bitrates legacy-2.4 12

Some more examples you can find at Linux Wireless.

I have learned that the WiFi device on the Raspberry Pi obviously does not support setting the bitrate. I only read the help and available documentation but doesn't tried it. Using the command you get:

command failed: Operation not supported (-95)

But it doesn't matter because wpa_supplicant optimizes the connection by falling back to lower speeds on bad connections. There is no need to set lower bitrates manual because it will not increase stability.

| improve this answer | |
  • Did you actually try this? I get command failed: Operation not supported (-95). – Phil Frost Aug 25 '19 at 18:51
  • Hi Ingo, do you know if and to what extend this increases robustness of the connection? – Ghanima Aug 25 '19 at 19:10
  • @PhilFrost Sorry, I only read the help and the linked documentation but don't actually tried it. I get the same error. I will update my answer. – Ingo Aug 25 '19 at 19:18
  • @Ghanima I know what you mean (automatic speed reduction). But it was asked for a fixed speed. But it seems Raspberry Pi doesn't support it; will mention it in the answer. – Ingo Aug 25 '19 at 19:23
  • You say it doesn't matter, but it really does. The speed can't be automatically adjusted until after the link is determined to be "bad", which is a problem for a realtime application. – Phil Frost Aug 25 '19 at 21:14

This question is predicated on the false premise that lower rates are more reliable

Lowering baud rate can only be achieved by selecting a mode (b, g, n) supported by the router and most do not even support the legacy modes by default.

Spread-spectrum systems transmit at a constant bit rate (usually 20/40MHz for 2.4GHz WiFi). The spreading function spreads the bits across the bandwidth - allowing bandwidth/speed tradeoff (the CDMA systems I used to work on were reliable with a signal 10dB below the noise floor).

Higher baud rates are achieved by mapping more code points onto each bit, and modern modulation schemes are actually more reliable than the older schemes.

If the connection is unreliable the normal practice is to use smaller packets, but again this requires mutual support.

TCP retry protocols should compensate for corrupt packets.

If retry is not feasible (e.g. CDMA voice) the data is encoded with forward error correcting protocols to permit error recovery, or the packets are discarded.

| improve this answer | |
  • It's not a false premise. Lower bitrates mean more energy per bit, which increases the probability the packet will be correctly demodulated on the first try. Why else do you think speeds decrease as signal quality degrades? TCP retries don't help in a realtime application. – Phil Frost Aug 25 '19 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.