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

pvvx

Активный участник сообщества
Очень часто 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 и разбирает рекламу только от него):
 

pvvx

Активный участник сообщества
Явно что-то кривое во всех 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

Активный участник сообщества
Слепил максимальную синхронизацию приемника для 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

Активный участник сообщества
Попытался провести тест для определения кол-ва выпадений принятых рекламных пакетов в обстановке, где устройств BLE и WiFi достаточно много.
Один тест залил в ESP32-WROWER-B и вставил в него новый АКБ 18650:
1614839640301.png
Второй в RTL8722DM:
1614839746384.png
Пошел к знакомому в магазин у метро и там их подключили к ноутбуку, а источник, 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

Well-known member
Попытался провести тест для определения кол-ва выпадений принятых рекламных пакетов в обстановке, где устройств 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

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

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

pvvx

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

pvvx

Активный участник сообщества
В режиме рекламы без подтверждений (тупой маяк) датчик дает не менее 4-х дублей по 3-м каналам. Это означает возможность потери более 91% пакетов при полном приеме без выпадений передаваемых измерений. :p
Беда с ESP кроется в её ПО, а не в битых пакетах.
 

nikolz

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

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

pvvx

Активный участник сообщества
я про протокол вообще-то сказал.
Это надо же было додуматься , чтобы рекламу дублировать на 3-х каналах , при этом каналы жестко заданы.
Типа все ходим по бревну через речку.
Отсебятина она хороша только для тех, кому не требуется объединение датчиков в систему и для выпуска несовместимых с другими устройств. Чтобы вы не могли купить что-то другой фирмы или производителя, кроме вашего любимого.
У так не любимого Вами NORDIC есть библиотека для работы с радио на физ уровне и простейший протокол для которого не требуется стека.
На этом протоколе можно делать датчики с минимальным потреблением и минимальными затратами RAM.
к сожалению TLSR не скопировало эту библиотеку.
Какая ещё библиотека для передачи и приема сырых пакетов?
Это типа теста RF? Оно есть и описывается пару строчками в примерах от Telink.
но проблема не только в протоколе
КПД передатчика и особенно приемника ниже плинтуса, как у паровоза.
Поэтому потери энергии именно в аналоговой части чипов.
Когда решат эту проблему, тогда и энергопотребление уменьшится сразу на порядки.
Ждите когда решат.
А нам пока достаточно работы датчиков в пару лет от CR2032 по стандартным протоколам.
Ещё поругайтесь что частота выбрана равной микроволновке...
И прочитайте стандарт BT5.0, где указано как работа рекламы происходит не только на 3-х каналах...
 

Junkie

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

pvvx

Активный участник сообщества
или все таки в есп 32 тоже был использован блютус?
ESP-NOW не годится для автономных датчиков из-за большого потребления и самого протокола.

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

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

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

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

pvvx

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

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

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