8

I'm making a project using an Arduino and an ESP8266 module running the esp-link firmware - which gives me the ability to use MQTT for controlling the Arduino. I'd looked at something like an XBee module instead - but they're so damn expensive compared to the ESP8266! (If you don't know what ESP8266 or MQTT is, don't worry - it's enough to know that it's using TCP over Wi-Fi).

The MQTT packets are tiny, so the throughput of the Wi-Fi network is never going to be an issue. But, latency and reliability are large factors. The MQTT system is using TCP, so it should be reliable enough - but I'm not so sure about latency.

I have the choice of using an 802.11b, .11g or .11n connection for the network the ESP8266 uses. Is there anything in any of these standards that makes one have lower latency than any other? Which would I expect to have the best performance with for very small and infrequent packets?

seanlano
  • 183
  • 7
  • 1
    In latency considerations there is also the other side involved, plus its a quality of implementation issue. I don't think theoretical numbers will get you very far. – PlasmaHH Jan 17 '17 at 10:44
  • google for a LWN article named "making wifi fast". – user3528438 Jan 17 '17 at 11:25

1 Answers1

10

First of all, you're doing something VERY right that a lot of IoT designers and users don't: You consider the fact that operation needs to be reliable and latency-bounded. Not everyone does that, and that's why many IoT devices really are bad.

The choice of standard between 802.11 b/g/n won't really influence your latency much. I assume we're bounding latencies < 10ms, because everything about that will "just work in 99.5% of cases using good WiFi hardware".

If you're in a latency-bound scenario, you certainly won't

  • use TCP (and thus, MQTT, which builds atop of that)
  • use a device that emulates a slow serial link – if your packets have let's say 4 characters, and you have 9600 baud, then you'll spend a millisecond just to get data from the µC to the WiFi device
  • use WiFi, since there's no guarantee your station will be able to send within a finite time window, at all (only a likelihood)

If you need reliability, on the other hand, you mustn't

  • use pure UDP (since there's no guarantee or feedback that the packets reach their destination)
  • use a pure one-way radio protocol (same reason)
  • use a ESP8266, which takes it price advantage for a lack of testing, design and certification for high-reliability operation (and thus, no large electronics manufacturer will use that without doing that testing themselves, in which case ready-made modules from trustworthy manufacturers usually become cheaper)

So, first of all, define what your latency requirements, and your reliability requirements are. You must have a piece of paper that says

The latency for {one|two}-way communication needs to be < {max latency} in {tolerable percentage}% of cases. There must not be a probability of more than {tolerable percentage}% of losing a packet.

Then, you can look at the theoretical limits of systems, and then look at the practical limits of implementations of those who fit that.

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
  • _First of all, you're doing something VERY right..._ Thanks! :) It's just a toy example for now, more-so than something I plan to make available as a real product. _The choice of standard between 802.11 b/g/n won't really influence your latency much._ I didn't think it would make too much difference, but thought I'd ask. I will still also do some of my own testing, but obviously I don't have the equipment to do it as thoroughly as a lab would. As for the EPS8266 and Wi-Fi - I figured, since it was cheaper, I'd give that a go first - and try something else if it wasn't acceptable. – seanlano Jan 18 '17 at 07:12
  • I definitely will define a statement of my acceptable latency and probability of packet loss - and use that as my criteria for continuing to use the ESP8266 or not. – seanlano Jan 18 '17 at 07:14