Zakupiłem na ali taką antene. Ta dołączona do xiaoseed raz na jakiś czas miała problem z odbiorem ramek.
Wersja 3dbi
Dwa tygodnie już śmiga bez zająkniecia.
2 polubienia
Ponieważ nie mam GAM-y i jej ramki o długości 326 bajtów RAW, musiałem taki przypadek odtworzyć sztucznie w eterze.
Kuriozalnie, gotowe moduły SX1262/LoRa świetnie nadają się do odbioru takich ramek, ale kiepsko nadają się do ich generowania jako testowy nadajnik wM-Bus T1. Normalna ścieżka TX GFSK kończy się praktycznie na granicy 255 bajtów, a właściwy tryb long-packet TX wymaga DIO2/DIO3, które na takich płytkach są zwykle zajęte przez RF switch/TCXO.
Dlatego testowo użyłem starszego SX1276 w FSK Direct Mode, który paradoksalnie świetnie się do tego nadał i wysłał poprawną syntetyczną ramkę T1 A odpowiadającą 326 bajtom RAW.
Układ testowy:
- TX: LilyGO T3-S3 / SX1276 w trybie FSK Direct Mode
- RX: odbiornik SX1262 z włączonym long_gfsk_packets
- Tryb: wM-Bus T1 A
- Częstotliwość: 868.950 MHz
- Bitrate: 100 kbps
- Odchyłka częstotliwości: 50 kHz
- Sync: 0x54 0x3D
- Producent testowy: TST
- ID testowe: 12345678
Logi ESP : ( po przetworzeniu )
L_FIELD=40:
[20:37:16.240][I][wmbus_user:2457]: ★ Have data / odebrano dane (41 bytes) [RSSI: -107dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
L_FIELD=149:
[20:38:46.986][I][wmbus_user:2457]: ★ Have data / odebrano dane (150 bytes) [RSSI: -106dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
L_FIELD=150:
[20:40:06.599][I][wmbus_user:2457]: ★ Have data / odebrano dane (151 bytes) [RSSI: -106dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
L_FIELD=190:
[20:41:26.273][I][wmbus_user:2457]: ★ Have data / odebrano dane (191 bytes) [RSSI: -115dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
W logu ESPHome długość w nawiasie pokazuje ramkę już po dekodowaniu 3-of-6 i po usunięciu blokowych CRC DLL. Dlatego np. Have data (191 bytes) nie oznacza 191 bajtów odebranych fizycznie z radia.
Dla realnych logów z testu:
Have data (41 bytes)oznacza 49 bajtów z CRC DLL, czyli 74 bajty RAW po radiu.Have data (150 bytes)oznacza 170 bajtów z CRC DLL, czyli 255 bajtów RAW po radiu.Have data (151 bytes)oznacza 171 bajtów z CRC DLL, czyli 257 bajtów RAW po radiu.Have data (191 bytes)oznacza 217 bajtów z CRC DLL, czyli 326 bajtów RAW po radiu.
Kluczowy test to Have data (191 bytes), bo odpowiada ramce 326 RAW bajtów, czyli przekracza granicę 255 bajtów RAW.
Reasumując: sprawdziłem tor radiowy i logikę komponentu, a nie dekodowanie ramki do dalszej obróbki.
Celem testu było potwierdzenie, że SX1262 poprawnie odbiera prawidłowe ramki wM-Bus T1 przekraczające standardową granicę 255 bajtów RAW — i ten cel został spełniony.
EDIT:
Naniosłem kosmetyczną poprawkę do kodu i teraz w logu będzie widać obie wartości:
[I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=143 bytes, raw=245 bytes) [RSSI: -127dBm, mode: T1 A, mfr:NES id:24681357 ver:3 type:2 ci:7A]
Dla testowej ramki:
[I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=191 bytes, raw=326 bytes) [RSSI: -115dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
Na końcu test maksymalnej długości ramki jaki komponent może przyjąć czyli 435 bajtów :
[I][wmbus_user:2457]: ★ Have data / odebrano dane (decoded=256 bytes, raw=435 bytes) [RSSI: -117dBm, mode: T1 A, mfr:TST id:12345678 ver:255 type:0 ci:7A]
Zostawiłem to na 15 minut i po tym czasie dostałem summary dla licznika testowego ( log skrócony) :
interval_s=900
listen_mode=T1 only
total=63
ok=63
truncated=0
dropped=0
crc_failed=0
drop_pct=0
trunc_pct=0
crc_fail_pct=0
sym_invalid=0
sym_invalid_pct=0
hint=GOOD
W teście użyto maksymalnych syntetycznych ramek T1 A o długości 435 bajtów RAW nadawanych co 30s.
Pole “total=63” to suma wszystkich zebranych odczytów w ciągu 15 minut a nie wyłącznie z licznika testowego.
Jak widać SX1262 odebrał długie ramki T1 bez ucięć, dropów i błędów DLL CRC.
Test wykonałem po godzinie 2 w nocy gdzie u mnie panuje cisza radiowa, więc traktuję go jako walidację funkcjonalną toru RX, a nie jako benchmark odporności na zatłoczony kanał.
1 polubienie
Szukam ochotnika do testów eksperymentalnej obsługi CC1101 w moim komponencie RAW-only.
Nie posiadam fizycznie takowej płytki.
Założenie jest inne niż w komponentach all-in-one: ESP ma odebrać i zwalidować telegram wM-Bus, a następnie wysłać go jako HEX do MQTT. Dekodowanie robi dalej wmbusmeters po stronie Home Assistant / hosta.
Wymagania do testu:
- CC1101 z wyprowadzonymi pinami GDO0 i GDO2,
- oba piny muszą być podłączone do ESP,
- brak konfiguracji typu „jeden IRQ i reszta n/c”,
- krótkie przewody i pewne zasilanie 3.3 V,
- możliwość zebrania logów z ESPHome,
- najlepiej licznik, który już nadaje i był wcześniej potwierdzony innym odbiornikiem.
To jest backend eksperymentalny, więc nie obiecuję gotowego rozwiązania ani encji po wgraniu YAML-a. Na tym etapie celem jest sprawdzenie, czy CC1101 poprawnie łapie pełny telegram i czy po walidacji pojawia się on na topicu MQTT.
Jeśli ktoś ma taki zestaw i chce potestować, mogę przygotować przykładowy YAML oraz powiedzieć, jakie logi są potrzebne.
Aby nie generować OFF-Topic prosze pisać do mnie na PW.
Mały update w temacie testów CC1101.
Ponieważ nadal nie mam u siebie fizycznego modułu CC1101, a chciałem ruszyć temat bez czekania na ochotnika z hardware, zrobiłem stanowisko testowe do sprawdzenia samej logiki odbioru.
Układ testowy wygląda tak:
SX1276 jako nadajnik testowy
↓ RF
SX1262 jako rzeczywisty odbiornik z eteru
↓
ukryty RAW topic MQTT: wmbus_bridge/raw
↓
Home Assistant add-on: CC1101 RX Testbench
↓
symulacja FIFO / threshold / ogona ramki
↓
ta sama logika dekodowania T1
↓
wmbusmeters jako walidator
Czyli nie emuluję całego układu CC1101. Nie testuję jeszcze SPI, GDO, rejestrów, prawdziwego FIFO ani fizycznego zachowania radia.
Testuję natomiast to, co można sprawdzić bez hardware:
surowy pakiet radiowy
→ buforowanie
→ porcjowanie jak przy FIFO/threshold
→ doczytanie ogona poniżej progu
→ dekodowanie T1 / 3of6
→ kontrola długości ramki
→ finalny telegram dla wmbusmeters
Do odsiania normalnego zapchanego eteru użyłem fake meter ID:
12345678
Add-on filtruje ramki po tym ID, więc normalne liczniki z otoczenia są ignorowane.
Przetestowane przypadki:
RAW 71 B → chunks=32+32+7 → OK, final frame len=41
RAW 111 B → chunks=32+32+32+15 → OK, final frame len=64
RAW 435 B → chunks=32+...+32+19 → OK, final frame len=256
Najważniejszy test to maksymalna ramka:
input_len=435
tail=19
delivered_len=435
tail_dropped=false
OUT len=256 meter=12345678
Zrobiłem też test negatywny, czyli celowe zgubienie ogona poniżej threshold:
input_len=435
tail=19
delivered_len=416
tail_dropped=true
DROP stage=t1_length_check reason=truncated
decoded_len=277 need_total=290 l_field=255
Wniosek jest prosty:
ogon FIFO doczytany → ramka przechodzi
ogon FIFO zgubiony → ramka jest ucięta i dekoder to wykrywa
Czyli sama logika odbioru/buforowania/dekodowania T1 została przetestowana na realnym torze MQTT i realnie odebranych pakietach z eteru, ale bez fizycznego CC1101.
To nie zamyka tematu testów sprzętowych. Nadal potrzebny jest test na prawdziwym CC1101, bo dopiero on sprawdzi SPI, GDO, konfigurację rejestrów, rzeczywiste FIFO i zachowanie układu radiowego.
Ale na tym etapie mam już mocny argument, że problem nie leży w samej logice dekodowania/bufora po mojej stronie. Jeżeli na prawdziwym CC1101 coś się wyłoży, to będzie trzeba patrzeć przede wszystkim w stronę hardware/SPI/GDO/FIFO timing, a nie zaczynać od założenia, że sam tor T1 jest napisany w ciemno.
Poniżej licznik testowy w moim addonie wmbusmeters:
Received telegram from: 12345678
manufacturer: (TST) Unknown (0x5274)
type: Other (0x00) encrypted
ver: 0xff
driver: unknown!
[wmbus-bridge][WARN] === NEW METER CANDIDATE DETECTED ===
[wmbus-bridge][WARN] Received telegram from: 12345678
[wmbus-bridge][WARN] Suggested driver: unknown
[wmbus-bridge][WARN] Add to options.json meters[] (example):
[wmbus-bridge][WARN] {"id":"meter_12345678","meter_id":"12345678","type":"auto","type_other":"","key":"NOKEY"}
[wmbus-bridge][WARN] ==================================
Received telegram from: 12345678
manufacturer: (TST) Unknown (0x5274)
type: Other (0x00) encrypted
ver: 0xff
driver: unknown!
Received telegram from: 12345678
manufacturer: (TST) Unknown (0x5274)
type: Other (0x00) encrypted
ver: 0xff
driver: unknown!
Pokazuje jak to działa:
Nadajnik SX1262 który czyta normalnie ( bez fake licznika ) :
[12:24:28.507][I][wmbus:949]: DIAG hint: OK | looks good / wygląda dobrze
[12:24:33.892][I][wmbus:2478]: Have data / odebrano dane (77 bytes) [RSSI: -59dBm, mode: T1 A, mfr:BMT id:03534167 ver:23 type:7 ci:7A]
[12:24:35.808][I][wmbus:2478]: Have data / odebrano dane (77 bytes) [RSSI: -59dBm, mode: T1 A, mfr:BMT id:03534157 ver:23 type:7 ci:7A]
[12:24:37.731][I][wmbus:2478]: Have data / odebrano dane (77 bytes) [RSSI: -59dBm, mode: T1 A, mfr:BMT id:03528107 ver:23 type:6 ci:7A]
Addon w HA który udaje CC1101 :
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03528302
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03528297
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03551593
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03534249
[I] [STAT] rx=85 ok=71 drop=14 ignored=0 parse_fail=0 hex_fail=0 decode_fail=13 crc_fail=1 truncated=0 tail_dropped=0 invalid_symbols=56 in_bytes=12096 delivered_bytes=12096 out_bytes=5949 ok_pct=83.5%
[I] [IN ] origin=mqtt topic=wmbus_bridge/raw chip=SX1262 mode=T1 rssi=-59 input_len=134 delivered_len=134
[I] [SIM] fifo=on size=64 threshold=32 chunks=32+32+32+32+6 tail=6 delivered_len=134 tail_dropped=false
[I] [OUT] topic=wmbus_bridge/telegram_cc1101_sim mode=T1 format=A len=77 meter=03536902
Addon wmbusmeters który to czyta :
No meters configured. Printing id:s of all telegrams heard!
Received telegram from: 03534249
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03536902
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03528221
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Warm Water (30°C-90°C) meter (0x06)
ver: 0x17
driver: hydrodigit
Received telegram from: 03534237
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03533991
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03551587
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 00089907
manufacturer: (NES) NORA ELK MALZ SAN ve TIC, Turkey (0x38b3)
type: Electricity meter (0x02) encrypted
ver: 0x03
driver: amiplus
Received telegram from: 03575413
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03534167
manufacturer: (BMT) BMETERS, Italy (0x9b4)
type: Water meter (0x07)
ver: 0x17
driver: hydrodigit
Received telegram from: 03534157
Sorry za tak długi post.