Очень часто ESP32 пропускает прием рекламных пакетов!

pvvx · 28 Фев 2021

Очень часто ESP32 пропускает прием рекламных пакетов.
Что нужно сделать чтобы этого не происходило?
Для примера - устройство дает рекламу на 3 стандартных канала каждые 2.5 сек.
Сниффер на TLSR8266 принимает все пакеты, даже если от значительно дальше по расстоянию от ESP32 и устройства транслирующего рекламу. Можно и вместе сложить - смысл и поведение ESP32 не меняет.
Такие дыры в приеме, постоянный перезапуск сканирования 5 сек:

Код:

06:29:09.377 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:09.650 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:09.650 -> Found device, MAC: a4:c1:38:05:4e:0a
06:29:09.784 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:09.967 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:11.369 -> Found device, MAC: c8:f1:3b:3d:3f:ac
06:29:11.733 -> Found device, MAC: a4:c1:38:21:87:88
06:29:14.355 -> Time since boot: 517. New scan.
06:29:14.400 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:14.625 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:15.125 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:16.345 -> Found device, MAC: a4:c1:38:05:4e:0a
06:29:16.884 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:19.330 -> Time since boot: 522. New scan.
06:29:19.464 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:19.464 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:19.464 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:19.509 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:19.734 -> Found device, MAC: a4:c1:38:05:4e:0a
06:29:20.185 -> Found device, MAC: a4:c1:38:21:87:88
06:29:24.354 -> Time since boot: 527. New scan.
06:29:24.445 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:24.582 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:24.764 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:24.945 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:25.351 -> Found device, MAC: a4:c1:38:21:87:88
06:29:26.436 -> Found device, MAC: c8:f1:3b:3d:3f:ac
06:29:26.796 -> Found device, MAC: 78:11:dc:6d:41:38
06:29:26.886 -> Found device, MAC: c8:d5:41:38:ea:0f
06:29:29.374 -> Time since boot: 532. New scan.
06:29:29.421 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:29.556 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:29.917 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:30.052 -> Found device, MAC: a4:c1:38:05:4e:0a
06:29:30.279 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:34.396 -> Time since boot: 537. New scan.
06:29:34.441 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:34.530 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:34.803 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:35.032 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:36.790 -> Found device, MAC: 78:11:dc:6d:41:38
06:29:36.926 -> Found device, MAC: c8:d5:41:38:ea:0f
06:29:39.409 -> Time since boot: 542. New scan.
06:29:39.453 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:39.544 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:39.816 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:41.129 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:41.943 -> Found device, MAC: c8:d5:41:38:ea:0f
06:29:41.943 -> Found device, MAC: a4:c1:38:05:4e:0a
06:29:42.350 -> Found device, MAC: a4:c1:38:21:87:88
06:29:44.428 -> Time since boot: 547. New scan.
06:29:44.473 -> Found device, MAC: 40:16:3b:0c:3d:da
06:29:44.594 -> Found device, MAC: 33:72:99:ea:c5:e9
06:29:44.594 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:29:44.968 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:29:45.238 -> Found device, MAC: c8:f1:3b:3d:3f:ac
06:29:45.688 -> Found device, MAC: a4:c1:38:21:87:88
06:29:46.813 -> Found device, MAC: 78:11:dc:6d:41:38
06:29:48.717 -> Found device, MAC: a4:c1:38:05:4e:0a
06:31:06.369 -> Time since boot: 552. New scan.
06:31:06.369 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:31:06.369 -> Found device, MAC: 33:72:99:ea:c5:e9
06:31:06.369 -> Found device, MAC: a4:c1:38:05:4e:0a
06:31:06.369 -> Found device, MAC: 40:16:3b:0c:3d:da
06:31:06.369 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:31:06.369 -> Time since boot: 557. New scan.
06:31:06.369 -> Found device, MAC: 33:72:99:ea:c5:e9
06:31:06.369 -> Found device, MAC: 40:16:3b:0c:3d:da
06:31:06.369 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:31:06.369 -> Found device, MAC: a4:c1:38:05:4e:0a
06:31:06.369 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:31:06.369 -> Found device, MAC: a4:c1:38:21:87:88
06:31:06.369 -> Time since boot: 562. New scan.
06:31:06.369 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:31:06.369 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:31:06.369 -> Found device, MAC: 40:16:3b:0c:3d:da
06:31:06.369 -> Found device, MAC: 33:72:99:ea:c5:e9
06:31:06.369 -> Found service '181a' data len: 17, 10161a18a4c1380b5eed00a229550b9b1f
06:31:06.369 -> MAC: a4c1380b5eed
06:31:06.369 -> Temp: 16.2°, Humidity: 41%, Vbatt: 2971, Battery: 85%, cout: 31
06:31:06.369 -> Found device, MAC: a4:c1:38:21:87:88
06:31:06.369 -> Found device, MAC: 40:16:3b:0c:3d:da
06:31:06.369 -> Found device, MAC: 33:72:99:ea:c5:e9
06:31:06.369 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:31:06.369 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:31:06.369 -> Found device, MAC: a4:c1:38:05:4e:0a
06:31:06.369 -> New Data to LCD: Temp: 16.2°, Humidity: 41% : 22a20029003ca0
06:31:06.369 -> Time since boot: 567. New scan.
06:31:06.369 -> Found device, MAC: 40:16:3b:0c:3d:da
06:31:06.369 -> Found device, MAC: 90:dd:5d:a4:c2:b1
06:31:06.369 -> Found device, MAC: 48:4d:1e:a8:0b:57
06:31:06.369 -> Found device, MAC: 33:72:99:ea:c5:e9
06:31:06.369 -> Found device, MAC: a4:c1:38:05:4e:0a
06:31:06.369 -> Found service 'fe95' data len: 22, 151695fe50305b051fed5e0b38c1a40a100155029b0b
06:31:06.369 -> CTRL: 3050 DEVID: 055b MAC: a4c1380b5eed
06:31:06.369 -> Battery: 85%, 2971 mV
06:31:06.369 -> count: 31
...

При этом подбор методом тыка периодов, окна, времени сканирования не сильно это дело меняет.
Немного помогает опустошение буфера сканирования, но оно и понятно - за период сканирования после очистки буфера заново набираются новые по MAC, т.к. фильтрация по MAC начинается снова.
Скетч примерно такой (ESP32 при сканировании ищет нужный MAC и разбирает рекламу только от него):

ATC_MiThermometer/esp32/BLE_term_lcd/BLE_term_lcd.ino at master · pvvx/ATC_MiThermometer

Custom firmware for the Xiaomi Thermometers and Telink Flasher - pvvx/ATC_MiThermometer

github.com

pvvx · 28 Фев 2021

Явно что-то кривое во всех ESP32. Проверил на разных модулях, производства именно Espressif, чтобы не нарваться на брак от халтурщиков с али. История одинакова - постоянные пропуски приема.
Очень походит, что в чипе RF сделано криво - если уже принимает слабый пакет, то срывающий его громкий от ближнего устройства не дает новой синхронизации, а чип продолжает тянуть тот сбитый пакет...
Если это так - значит все чипы ESP32 = брак.

Для сравнения намалевал примерно то-же самое на RTL872xDx, в Ameba Arduino.
Вот лог:

Код:

15:04:59.224 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2503 ms
15:05:00.672 ->
[BLE Device] GAP scan stop
15:05:00.712 ->
[BLE Device] GAP scan start
15:05:01.708 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2499 ms
15:05:03.184 ->
[BLE Device] GAP scan stop
15:05:03.224 ->
[BLE Device] GAP scan start
15:05:04.224 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2507 ms
15:05:05.668 ->
[BLE Device] GAP scan stop
15:05:05.708 ->
[BLE Device] GAP scan start
15:05:06.708 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2515 ms
15:05:08.193 ->
[BLE Device] GAP scan stop
15:05:08.234 ->
[BLE Device] GAP scan start
15:05:09.236 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2526 ms
15:05:10.718 ->
[BLE Device] GAP scan stop
15:05:10.758 ->
[BLE Device] GAP scan start
15:05:11.759 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2499 ms
15:05:13.239 ->
[BLE Device] GAP scan stop
15:05:13.279 ->
[BLE Device] GAP scan start
15:05:14.279 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2514 ms
15:05:15.724 ->
[BLE Device] GAP scan stop
15:05:15.764 ->
[BLE Device] GAP scan start
15:05:16.761 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2523 ms
15:05:18.281 ->
[BLE Device] GAP scan stop
15:05:18.281 ->
[BLE Device] GAP scan start
15:05:19.281 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2515 ms
15:05:20.801 ->
[BLE Device] GAP scan stop
15:05:20.841 ->
[BLE Device] GAP scan start
15:05:21.847 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2507 ms
15:05:23.291 ->
[BLE Device] GAP scan stop
15:05:23.331 ->
[BLE Device] GAP scan start
15:05:24.331 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2522 ms
15:05:25.816 ->
[BLE Device] GAP scan stop
15:05:25.816 ->
[BLE Device] GAP scan start
15:05:26.853 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2497 ms
15:05:28.293 ->
[BLE Device] GAP scan stop
15:05:28.333 ->
[BLE Device] GAP scan start
15:05:29.333 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2506 ms
15:05:30.814 ->
[BLE Device] GAP scan stop
15:05:30.814 ->
[BLE Device] GAP scan start
15:05:31.861 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2504 ms
15:05:33.341 ->
[BLE Device] GAP scan stop
15:05:33.341 ->
[BLE Device] GAP scan start
15:05:34.341 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2522 ms
15:05:35.861 ->
[BLE Device] GAP scan stop
15:05:35.901 ->
[BLE Device] GAP scan start
15:05:36.901 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2503 ms
15:05:38.342 ->
[BLE Device] GAP scan stop
15:05:38.382 ->
[BLE Device] GAP scan start
15:05:39.379 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2498 ms
15:05:40.837 ->
[BLE Device] GAP scan stop
15:05:40.877 ->
[BLE Device] GAP scan start
15:05:41.877 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2513 ms
15:05:43.357 ->
[BLE Device] GAP scan stop
15:05:43.397 ->
[BLE Device] GAP scan start
15:05:44.397 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2521 ms
15:05:45.874 ->
[BLE Device] GAP scan stop
15:05:45.954 ->
[BLE Device] GAP scan start
15:05:46.954 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2522 ms
15:05:48.438 ->
[BLE Device] GAP scan stop
15:05:48.438 ->
[BLE Device] GAP scan start
15:05:49.438 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2523 ms
15:05:50.958 ->
[BLE Device] GAP scan stop
15:05:50.958 ->
[BLE Device] GAP scan start
15:05:51.918 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2505 ms
15:05:53.438 ->
[BLE Device] GAP scan stop
15:05:53.478 ->
[BLE Device] GAP scan start
15:05:54.478 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2519 ms
15:05:55.960 ->
[BLE Device] GAP scan stop
15:05:56.009 ->
[BLE Device] GAP scan start
15:05:57.010 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2503 ms
15:05:58.451 ->
[BLE Device] GAP scan stop
15:05:58.499 ->
[BLE Device] GAP scan start
15:05:59.484 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2502 ms
15:06:00.995 ->
[BLE Device] GAP scan stop
15:06:00.995 ->
[BLE Device] GAP scan start
15:06:01.993 ->
MAC: A4:C1:38:0B:5E:ED ------ delta: 2525 ms

Ни одного потерянного пакета. (вывод других принятых пакетов от ненужных MAC отключил чтобы было нагляднее)

pvvx · 28 Фев 2021

Слепил максимальную синхронизацию приемника для ESP32. Всё равно теряет больше чем другие чипы.
Для сравнения накалякал по возможности максимально одинаковый "скетч" для RTL8272DM и ESP32-WROWER-B.
У обоих объемы RAM/PSRAM сравнимы. Но ESP32 - два ядра на 240 MHz, а RTL8272DM всего на 200 MHz, но RAM у него быстрее и много других встроенных контроллеров...

C++:

/*
   Test Advertisements Scanning
*/

#include "BLEDevice.h"

#define AD_PERIOD_MS 2500
BLEAddr inMacAddress = BLEAddr("a4:c1:38:0b:5e:ed"); // The remote data device MAC
uint32_t tik_scan, rx_all_count = 0, rx_err_count = 0;
boolean flag_restart = false;
BLEAdvertData foundDevice;

void scanFunction(T_LE_CB_DATA *p_data)
{
  foundDevice.parseScanInfo(p_data);
  if (inMacAddress == foundDevice.getAddr()) {
    uint32_t tt = millis();
    uint32_t delta = tt - tik_scan;
    tik_scan = tt;
    if (rx_all_count++) {
      if (delta > AD_PERIOD_MS + AD_PERIOD_MS / 10) {
        rx_err_count++;
      }
    }
    printf("MAC: %s ------ delta: %d ms, lost: %d, total: %d\n", foundDevice.getAddr().str(), delta, rx_err_count, rx_all_count);
    flag_restart = true;
  }
}

void setup()
{
  Serial.begin(115200);
  BLE.init();
  BLE.configScan()->setScanMode(GAP_SCAN_MODE_PASSIVE); // Active mode requests for scan response packets GAP_SCAN_MODE_PASSIVE
  BLE.configScan()->setScanInterval(420);               // Start a scan every 420ms
  BLE.configScan()->setScanWindow(420);                 // Each scan lasts for 420ms
  BLE.configScan()->updateScanParams();
  BLE.setScanCallback(scanFunction);
  BLE.beginCentral(0);
  tik_scan = millis();
  BLE.configScan()->startScan(420 * 3);
}

void loop() {
  if (flag_restart) {
    flag_restart = false;
    BLE.configScan()->stopScan();
    vTaskDelay((AD_PERIOD_MS / 4) / portTICK_RATE_MS);
  } else if (!BLE.configScan()->scanInProgress()) {
    BLE.configScan()->setScanMode(GAP_SCAN_MODE_PASSIVE); // Passive mode scan response packets
    BLE.configScan()->setScanInterval(2100);               // Start a scan every 2100ms
    BLE.configScan()->setScanWindow(2100);                 // Each scan lasts for 2100ms
    BLE.configScan()->updateScanParams();
    BLE.configScan()->startScan();
    vTaskDelay((AD_PERIOD_MS / 5) / portTICK_RATE_MS);
  } else {
    vTaskDelay(10 / portTICK_RATE_MS);
  }
}

C++:

/*
 * Test Advertisements Scanning
 */

#include <Arduino.h>

#include <BLEDevice.h>
#include <BLEScan.h>

#define AD_PERIOD_MS 2500
#include "BLEDevice.h"


BLEAddress inMacAddress = BLEAddress("a4:c1:38:0b:5e:ed"); // The remote data device MAC
uint32_t tik_scan, rx_all_count = 0, rx_err_count = 0;
boolean flag_restart = false;
BLEScan* pBLEScan;

class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks {
    void onResult(BLEAdvertisedDevice advertisedDevice) {
      if (inMacAddress.equals(advertisedDevice.getAddress())) {
    uint32_t tt = millis();
    uint32_t delta = tt - tik_scan;
    tik_scan = tt;
    if(rx_all_count++) {
      if(delta > AD_PERIOD_MS + AD_PERIOD_MS/10) {
        rx_err_count++;
      }
    }
    printf("MAC: %s ------ delta: %d ms, lost: %d, total: %d\n", advertisedDevice.getAddress().toString().c_str(), delta, rx_err_count, rx_all_count);
    flag_restart = true;
        
      }
    }

};

void setup()
{
  Serial.begin(115200);
  Serial.println("Starting Arduino BLE Client application...");
  BLEDevice::init("");
  pBLEScan = BLEDevice::getScan();
  pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks());
  pBLEScan->setInterval(420);
  pBLEScan->setWindow(420);
  pBLEScan->setActiveScan(false);
  Serial.println("Start scan (15 sec).");
  tik_scan = millis();
  pBLEScan->start(0, true);
}

void loop() {
  if (flag_restart) {
    flag_restart = false;
    pBLEScan->stop();
    pBLEScan->clearResults();
    delay(AD_PERIOD_MS/4);
//  } else if (!scanInProgress()) { ???
    pBLEScan->setInterval(2100);    // Start a scan every 2100ms
    pBLEScan->setWindow(2100);      // Each scan lasts for 2100ms
    pBLEScan->setActiveScan(false); // Passive mode scan response packets
    pBLEScan->start(0, true);
    delay(AD_PERIOD_MS/5);
  } else {
    delay(10);
  }
}

Тест вышел такой:
В качестве посылающего BLE рекламу передатчика используется Xiaomi Mijia (LYWSD03MMC)
Антенна ESP32-WROWER-B находится в 2-х см от антенны передатчика.
Антенна RTL8272DM находится в 7-ми см от антенны передатчика.

Итог:

Все сбои от приема у RTL8272DM обязательно происходят и у ESP32-WROWER-B (и у сниффера так-же = реальные помехи).
ESP32-WROWER-B стартует дольше на время более чем одна секунда.
ESP32-WROWER-B размер кода прошивки - 960472 байт, RTL8272DM - 676256 байт.
Потребление даже сравнивать нет смысла, т.к. выиграет RTL.

Куски логов:
RTL:

Код:

16:50:11.536 -> #calibration_ok:[2:19:11]
---
16:50:18.356 -> MAC: A4:C1:38:0B:5E:ED ------ delta: 1490 ms, lost: 0, total: 1
….---------….
17:06:01.495 -> MAC: A4:C1:38:0B:5E:ED ------ delta: 2507 ms, lost: 6, total: 370
17:06:04.022 -> MAC: A4:C1:38:0B:5E:ED ------ delta: 2508 ms, lost: 6, total: 371
17:06:06.543 -> MAC: A4:C1:38:0B:5E:ED ------ delta: 2497 ms, lost: 6, total: 372

ESP32:

Код:

16:50:16.596 -> ets Jun  8 2016 00:22:57
---
16:50:18.466 -> MAC: a4:c1:38:0b:5e:ed ------ delta: 838 ms, lost: 0, total: 1
….---------….
17:06:00.902 -> MAC: a4:c1:38:0b:5e:ed ------ delta: 2559 ms, lost: 23, total: 352
17:06:03.382 -> MAC: a4:c1:38:0b:5e:ed ------ delta: 2480 ms, lost: 23, total: 353
17:06:05.906 -> MAC: a4:c1:38:0b:5e:ed ------ delta: 2519 ms, lost: 23, total: 354

В общем не ясно почему ESP32 так запросто теряет пакеты - в 4 раза больше, чем сбитых реальными помехами у обоих (и у сниффера).

PS: Пока так, а желающие могут сами всё перепроверить, улучшить, или посоветовать что там докрутить у ESP32.

pvvx · 4 Мар 2021

Попытался провести тест для определения кол-ва выпадений принятых рекламных пакетов в обстановке, где устройств BLE и WiFi достаточно много.
Один тест залил в ESP32-WROWER-B и вставил в него новый АКБ 18650:

Второй в RTL8722DM:

Пошел к знакомому в магазин у метро и там их подключили к ноутбуку, а источник, Xiaomi LYWSD03MMC отнесли на 10 метров.
Проверили обстановку - принимаются сотни устройств BLE и от 50 до сотни WiFi AP (эти наверно в основном от ближайших домов).
По BLE, в основном на sniffer принимаются рекламы от телевизоров и разных Apple устройств, с периодами от каждого 10..20 мс. Ну ещё куча каких-то других... По прикидкам это гам примерно в 3 тысячи пакетов BLE рекламы в сек...
После включения, через примерно 8 часов снял логи, последние сообщения в них:
ESP32: delta: 2520 ms, lost: 1941, rx total: 9884
RTL8722DM: delta: 2510 ms, lost: 853, rx total: 11601

На следующий день показания ESP32 стали не адекватными - она начала считать по новой, т.к. видимо перезагрузилась.
RTL8722DM продолжает считать:
delta: 2497 ms, lost: 1764, rx total: 23530

Перед описанием этого поста забрал всё это дело, а показания от плат были такие:
ESP32:

Код:

...
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.
Start new scan 5 sec.

У RTL8722DM:

Код:

MAC: A4:C1:38:0B:5E:ED ------ delta: 2499 ms, lost: 3077, rx total: 41978
MAC: A4:C1:38:0B:5E:ED ------ delta: 2517 ms, lost: 3077, rx total: 41979
MAC: A4:C1:38:0B:5E:ED ------ delta: 2515 ms, lost: 3077, rx total: 41980
MAC: A4:C1:38:0B:5E:ED ------ delta: 2520 ms, lost: 3077, rx total: 41981
MAC: A4:C1:38:0B:5E:ED ------ delta: 2516 ms, lost: 3077, rx total: 41982

Т.е. в итоге:

41982 принятых реклам с шагом около 2.5 сек и 3077 раз рекламы не было принято за период в 3 сек.

100*3077/41982 = 7.33 % выпадений при чтении рекламы от BLE в не особо благоприятной обстановке.

nikolz · 6 Мар 2021

pvvx написал(а):
Попытался провести тест для определения кол-ва выпадений принятых рекламных пакетов в обстановке, где устройств BLE и WiFi достаточно много.
Один тест залил в ESP32-WROWER-B и вставил в него новый АКБ 18650:
Посмотреть вложение 10708
Второй в RTL8722DM:
Посмотреть вложение 10709
Пошел к знакомому в магазин у метро и там их подключили к ноутбуку, а источник, Xiaomi LYWSD03MMC отнесли на 10 метров.
Проверили обстановку - принимаются сотни устройств BLE и от 50 до сотни WiFi AP (эти наверно в основном от ближайших домов).
По BLE, в основном на sniffer принимаются рекламы от телевизоров и разных Apple устройств, с периодами от каждого 10..20 мс. Ну ещё куча каких-то других... По прикидкам это гам примерно в 3 тысячи пакетов BLE рекламы в сек...
После включения, через примерно 8 часов снял логи, последние сообщения в них:
ESP32: delta: 2520 ms, lost: 1941, rx total: 9884
RTL8722DM: delta: 2510 ms, lost: 853, rx total: 11601

На следующий день показания ESP32 стали не адекватными - она начала считать по новой, т.к. видимо перезагрузилась.
RTL8722DM продолжает считать:
delta: 2497 ms, lost: 1764, rx total: 23530

Перед описанием этого поста забрал всё это дело, а показания от плат были такие:
ESP32:

Код:

... Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec. Start new scan 5 sec.

У RTL8722DM:

Код:

MAC: A4:C1:38:0B:5E:ED ------ delta: 2499 ms, lost: 3077, rx total: 41978 MAC: A4:C1:38:0B:5E:ED ------ delta: 2517 ms, lost: 3077, rx total: 41979 MAC: A4:C1:38:0B:5E:ED ------ delta: 2515 ms, lost: 3077, rx total: 41980 MAC: A4:C1:38:0B:5E:ED ------ delta: 2520 ms, lost: 3077, rx total: 41981 MAC: A4:C1:38:0B:5E:ED ------ delta: 2516 ms, lost: 3077, rx total: 41982

Т.е. в итоге:

41982 принятых реклам с шагом около 2.5 сек и 3077 раз рекламы не было принято за период в 3 сек.

100*3077/41982 = 7.33 % выпадений при чтении рекламы от BLE в не особо благоприятной обстановке.

Ну говорил же Вам, что BLE - это говно для умных устройств, так как засирают эфир.
Протокол для умных устройств и умных домов еще не сделали. все еще впереди.

pvvx · 6 Мар 2021

nikolz написал(а):
Ну говорил же Вам, что BLE - это говно для умных устройств, так как засирают эфир.
Протокол для умных устройств и умных домов еще не сделали. все еще впереди.

WiFi и "засирает" эфир. Потерь пакетов в нем больше.
По вашему выходит что беспроводные датчики на сегодня это только мечта и надо ждать пару столетий?
На чем ещё тогда делать беспроводные датчики, если у народу на руках уже есть средства коммуникации и отладки только для BLE?

Пока беда только с ESP. С остальными решениями для DIY в вопросе "вумный дом" всё хорошо. На nRF и прочем есть "народные" шлюзы и успешно работают.
Обращаются только любители c "ESPHome".

pvvx · 6 Мар 2021

ESPHome — ESPHome

ESPHome Homepage - Reimagining DIY Home Automation. ESPHome is a framework that tries to provide the best possible use experience for using IoT microcontrollers for Home Automation. Just write a simple YAML configuration file and get your own customized firmware.

esphome.io

pvvx · 6 Мар 2021

В режиме рекламы без подтверждений (тупой маяк) датчик дает не менее 4-х дублей по 3-м каналам. Это означает возможность потери более 91% пакетов при полном приеме без выпадений передаваемых измерений.

Беда с ESP кроется в её ПО, а не в битых пакетах.

nikolz · 7 Мар 2021

pvvx написал(а):
WiFi и "засирает" эфир. Потерь пакетов в нем больше.
По вашему выходит что беспроводные датчики на сегодня это только мечта и надо ждать пару столетий?
На чем ещё тогда делать беспроводные датчики, если у народу на руках уже есть средства коммуникации и отладки только для BLE?

Пока беда только с ESP. С остальными решениями для DIY в вопросе "вумный дом" всё хорошо. На nRF и прочем есть "народные" шлюзы и успешно работают.
Обращаются только любители c "ESPHome".

я про протокол вообще-то сказал.
Это надо же было додуматься , чтобы рекламу дублировать на 3-х каналах , при этом каналы жестко заданы.
Типа все ходим по бревну через речку.
----------------------------------------------------------
У так не любимого Вами NORDIC есть библиотека для работы с радио на физ уровне и простейший протокол для которого не требуется стека.
На этом протоколе можно делать датчики с минимальным потреблением и минимальными затратами RAM.
к сожалению TLSR не скопировало эту библиотеку.
--------------------------
но проблема не только в протоколе
КПД передатчика и особенно приемника ниже плинтуса, как у паровоза.
Поэтому потери энергии именно в аналоговой части чипов.
Когда решат эту проблему, тогда и энергопотребление уменьшится сразу на порядки.

pvvx · 9 Мар 2021

nikolz написал(а):
я про протокол вообще-то сказал.
Это надо же было додуматься , чтобы рекламу дублировать на 3-х каналах , при этом каналы жестко заданы.
Типа все ходим по бревну через речку.

Отсебятина она хороша только для тех, кому не требуется объединение датчиков в систему и для выпуска несовместимых с другими устройств. Чтобы вы не могли купить что-то другой фирмы или производителя, кроме вашего любимого.

У так не любимого Вами NORDIC есть библиотека для работы с радио на физ уровне и простейший протокол для которого не требуется стека.
На этом протоколе можно делать датчики с минимальным потреблением и минимальными затратами RAM.
к сожалению TLSR не скопировало эту библиотеку.

Какая ещё библиотека для передачи и приема сырых пакетов?
Это типа теста RF? Оно есть и описывается пару строчками в примерах от Telink.

но проблема не только в протоколе
КПД передатчика и особенно приемника ниже плинтуса, как у паровоза.
Поэтому потери энергии именно в аналоговой части чипов.
Когда решат эту проблему, тогда и энергопотребление уменьшится сразу на порядки.

Ждите когда решат.
А нам пока достаточно работы датчиков в пару лет от CR2032 по стандартным протоколам.
Ещё поругайтесь что частота выбрана равной микроволновке...
И прочитайте стандарт BT5.0, где указано как работа рекламы происходит не только на 3-х каналах...

Junkie · 6 Апр 2021

Тут сравниваются протоколы esp-now и ble? а то в esp32 тоже есть блютус, уточните пожалуйста.

Junkie · 6 Апр 2021

pvvx написал(а):
А нам пока достаточно работы датчиков в пару лет от CR2032 по стандартным протоколам.

или все таки в есп 32 тоже был использован блютус?

pvvx · 7 Апр 2021

Junkie написал(а):
Тут сравниваются протоколы esp-now и ble? а то в esp32 тоже есть блютус, уточните пожалуйста.

BLE.
Esp-now нигде, кроме как в лесу, где нет другого оборудования не применим.

pvvx · 7 Апр 2021

Junkie написал(а):
или все таки в есп 32 тоже был использован блютус?

ESP-NOW не годится для автономных датчиков из-за большого потребления и самого протокола.

По энергозатратам на сегодня он сравним с WiFi6. WiFi6 более экономичен при правильном подходе, но чипы от Espressif не могут обеспечить необходимый уровень при стандартном соединения с типовыми современными роутерами.

В итоге ESP-NOW – никчемная ветка протокола с отсебятиной Espressif на базе RF части WiFi чипов 2.4ГГц.

Типовое среднее потребление у других двух-диапазонных SoC с WiFi при постоянном соединении в шумной среде и стандартных установках составляет 1..1.5 mA:

Realtek RTL872x (WiFi+BLE5.0)

В общем надоело ковыряться там. Мешает пресловутая VS - на случайные нажатия на asm и прочее грузит с SSD своё толстое тело и всё тормозит глухо на все десятки потоков CPU... А переназначать счас лень... Ей чё в 64ГБ DDR не закешироваться? :eek:

esp8266.ru

Модуль BW16 (RTL8720DN)

AI-Thinker RTL8720DN Dual-band WiFi + Bluetooth Low Energy BLE 5.0 BW16 Module Board (JTAG-SWD PA27 - SWDIO, PB3 - SWCLK, EN - RST) Модули пришли с древней глючной версией AT: Но кое как работают - соединяется с AP на 2.4 и 5 ГГц. В старой версии AT BLE отсутствует.

esp8266.ru

С BLE средний уровень потребления для применений с датчиками с передачей отсчетов каждые 1 сек давно ниже 40 мкА при аналогичной дальности соединения.

pvvx · 7 Апр 2021

Junkie написал(а):
Тут сравниваются протоколы esp-now и ble? а то в esp32 тоже есть блютус, уточните пожалуйста.

У BLE в стандарте давно уже есть режимы выхода в эфир только по событиям, аналогично ZigBee и вариантам BLE-MESH. В BLE5.2 есть и автоматическая подстройка уровня TX, что позволяет снизить потребление при малых дистанциях. Но версия 5.2 – это новая и не у всех ещё поддерживается.

В городской шумной среде по уровню выпадений и сбоев пакетов BLE выходит лучше ZigBee за счет более короткой длительности посылки и Мбит/c. За время посылки ZigBee вероятность появления помехи с большим уровнем от окружающих бытовых WiFi или BLE значительно больше, т.к. битовая скорость ZigBee в 8 раз ниже и стандартный фрейм длинный.

А здесь, в этой теме, разбирается другое – что ESP32 теряет и не принимает пакеты BLE по каким-то своим внутренним причинам, совершенно не зависимым от внешних условий радио-эфира.

Очень часто ESP32 пропускает прием рекламных пакетов!

pvvx

Активный участник сообщества

ATC_MiThermometer/esp32/BLE_term_lcd/BLE_term_lcd.ino at master · pvvx/ATC_MiThermometer

pvvx

Активный участник сообщества

pvvx

Активный участник сообщества

pvvx

Активный участник сообщества

nikolz

Well-known member

pvvx

Активный участник сообщества

pvvx

Активный участник сообщества

ESPHome — ESPHome

pvvx

Активный участник сообщества

nikolz

Well-known member

pvvx

Активный участник сообщества

Junkie

Member

Junkie

Member

pvvx

Активный участник сообщества

pvvx

Активный участник сообщества

Realtek RTL872x (WiFi+BLE5.0)

Модуль BW16 (RTL8720DN)

pvvx

Активный участник сообщества