Raspberry Pi и ESP32 — быстрое подключение Wi-Fi в режиме реального времени

#raspberry-pi #wifi #protocols #esp32

#raspberry-pi #Wi-Fi #протоколы #esp32

Вопрос:

Какой протокол я должен использовать для наилучшего обмена данными в реальном времени с Raspberry pi на ESP32.

Я выполняю некоторые вычисления для R pi (БПФ по сигналам), и результат должен отправляться каждые 10 мс в ESP32. Esp32 выводит результат на светодиодный дисплей и шаговый двигатель. Raspberry pi работает по Ethernet, а ESP32 — по wifi (локальная сеть, домашняя сеть) Мне нужно передавать 10 байт данных каждые 10 мс, но временная задержка и частотная характеристика должны быть очень маленькими. Какой протокол я должен использовать? Я думаю, что MQTT замедляется? Есть еще идеи?

Ответ №1:

Все, что связано с беспроводной связью, нельзя доверять с точки зрения последовательной доставки пакетов с низкой задержкой. Я не думаю, что вы сможете достичь своей цели в 10 мс для каждого пакета с Wi-Fi. Слишком много внешних факторов.

Сказав это, из вашего вопроса я понимаю, что вы производите измерения / вычисления на ESP32 и хотите использовать его где-то еще с низкой задержкой. Поскольку устаревшее измерение / вычисление является избыточным, вам необходимо реализовать дейтаграмму. Если ваше определение проблемы подходит для того, чтобы время от времени пропускать пакет, я бы использовал UDP-пакеты. Если он поступает через 10 мс без каких-либо осложнений, нет никаких проблем ни с UDP, ни с TCP. Но когда этого не произойдет, UDP просто проигнорирует ошибку и отправит следующий пакет данных, в то время как TCP попытается доставить его даже через 10 мс.

Также, пожалуйста, имейте в виду, что даже в TCP у вас может быть некоторое количество недоставленных пакетов. (потеря пакетов)

Ответ №2:

Вы раздвигаете границы возможностей Wi-Fi-соединения. Передача данных с низкой задержкой и низким дрожанием, конечно, не гарантируется. Если канал Wi-Fi используется даже незначительно, столкновения приведут к задержкам в несколько десятков или сотен миллисекунд. Частота этих задержек напрямую зависит от использования канала. Как сказал Бора, необработанные UDP-дейтаграммы — ваш лучший выбор. Вы должны встроить в протокол механизм восстановления из образцов, которые были утеряны или поступили с опозданием, чтобы быть полезными. В целом, это не тривиальная задача, так что удачи 🙂