Kupiłem kilka Tuya IRC03, które służą zarówno jako odbiornik, jak i nadajnik podczerwieni.
Moją intencją było wysłanie sygnałów do zestawu stereo Denon, aby można go było obudzić i przełączyć na właściwe wejście z innego pomieszczenia.
Dane przychodzące z pilota wyglądają następująco:
Przycisk ZAWIESZ:
Przycisk WŁ.:
Kiedy próbuję opublikować, tj. Używając cmnd/IRDevice/IRSend, ładunek:
Dzienniki urządzenia:
OK, więc nie lubi Kaseikyo_Denon (czy jest gdzieś lista protokołów?), ale Denon w pewnym sensie współpracuje z cmnd/IRDevice/IRSend przy użyciu ładunku:
Przetwornik pokazuje w logu:
Ale rzeczywiste otrzymane dane (testowane przez inny IRC03) docierają do odbiornika jako:
Próbowałem następnie porównać to z kodami Denona z IRDB (https://github.com/probonopd/irdb) i wydaje się, że te również usuwają adresy z przodu dowolnego adresu (więc 0x144 staje się po prostu 0x4).
Korzystanie z protokołu NEC itp. jest odbierane zgodnie z oczekiwaniami, ale oczywiście nie działa na moim urządzeniu:
Wydaje mi się, że mogłem to wyśledzić. Ten fragment znajduje się pod sterownikiem/drv_ir.cpp
Teraz, jeśli args_in jest oddzielany od bufora poleceń, na przykład z httpsserver/http_fns.c, wygląda na to, że ma około 128 znaków (łącznie z samym poleceniem)
Jeśli więc naszym poleceniem jest „IRSend”, będzie to około 120 kolejnych znaków (plus terminator) potencjalnego wejścia
Teraz, jeśli spojrzymy na miejsca, w których wszystko zostaje odcięte
IRSend Kaseikyo_Sharp 1 1 0
To polecenie (6 znaków), spacja, następnie „Kaseikyo_Sharp” (14 znaków) - i to pozostawia tylko około 5 znaków na resztę args_in. Wszystko więcej zostanie posiekane
Co więcej, jednym z identyfikatorów dostawców jest „Kaseikyo_Mitsubishi”, który sam w sobie składa się z 19 znaków.
Powinno to zostać naprawione poprzez zwiększenie tego
do czegoś takiego
Pozwoliłoby to na wprowadzenie większego łańcucha dostawcy plus 5-znakowy adres arg, 4-znakowy CMD arg, i trochę więcej dla powtórzeń/zastąpienia (bity, jak sądzę, są faktycznie ustawione w kodzie w folderze „Arduino-IRremote-mod”, tj.
To powiedziawszy, jeśli OBK potencjalnie pozwoli kiedyś na wyjście w formacie RAW, tablica znaków args z pewnością musiałaby być jeszcze większa.
Moją intencją było wysłanie sygnałów do zestawu stereo Denon, aby można go było obudzić i przełączyć na właściwe wejście z innego pomieszczenia.
Dane przychodzące z pilota wyglądają następująco:
Przycisk ZAWIESZ:
Cytat:Informacje:IR:IR IR_Kaseikyo_Denon 0x314 0x0 0 (48 bitów)
Przycisk WŁ.:
Cytat:Informacje:IR:IR IR_Kaseikyo_Denon 0x214 0x0 0 (48 bitów)
Kiedy próbuję opublikować, tj. Używając cmnd/IRDevice/IRSend, ładunek:
Kaseikyo_Denon 0x314 0x0Dzienniki urządzenia:
Cytat:Błąd: IR: IRSend cmnd jest nieprawidłowy [kaseikyo_denon 0x31], a nie jak [NEC-0-1A] lub [NEC 0 1A 1].
OK, więc nie lubi Kaseikyo_Denon (czy jest gdzieś lista protokołów?), ale Denon w pewnym sensie współpracuje z cmnd/IRDevice/IRSend przy użyciu ładunku:
denon 0x314 0x0Przetwornik pokazuje w logu:
Cytat:Info:IR:IR wyślij denon 0x314 0x0 protokół 3 adres 0x314 cmd 0x0 powtórzeń 0 nadpisanie bitów 0
Ale rzeczywiste otrzymane dane (testowane przez inny IRC03) docierają do odbiornika jako:
Cytat:Informacje:IR:IR IR_Denon 0x14 0x0 0
Próbowałem następnie porównać to z kodami Denona z IRDB (https://github.com/probonopd/irdb) i wydaje się, że te również usuwają adresy z przodu dowolnego adresu (więc 0x144 staje się po prostu 0x4).
Korzystanie z protokołu NEC itp. jest odbierane zgodnie z oczekiwaniami, ale oczywiście nie działa na moim urządzeniu:
Cytat:cmnd/IRDevice/IRSend gdzie indziej 0x314 0x0
Nadajnik: Info:IR:IR wyślij nec 0x314 0x0 protokół 7 adres 0x314 cmd 0x0 powtórzeń 0 nadpisanie bitów 0
Odbiornik: Info:IR:IR IR_NEC 0x314 0x0 0
Wydaje mi się, że mogłem to wyśledzić. Ten fragment znajduje się pod sterownikiem/drv_ir.cpp
extern "C" commandResult_t IR_Send_Cmd(const void *context, const char *cmd, const char *args_in, int cmdFlags) {
int numProtocols = sizeof(ProtocolNames)/sizeof(*ProtocolNames);
if (!args_in) return CMD_RES_NOT_ENOUGH_ARGUMENTS;
char args[20];
strncpy(args, args_in, 19);
args[19] = 0;
// split arg at hyphen;
char *p = args;
while (*p && (*p != '-') && (*p != ' ')){
p++;
}
etc etcTeraz, jeśli args_in jest oddzielany od bufora poleceń, na przykład z httpsserver/http_fns.c, wygląda na to, że ma około 128 znaków (łącznie z samym poleceniem)
char tmpA[128];
...
commandLen = http_getArg(request->url, "cmd", tmpA, sizeof(tmpA));
Jeśli więc naszym poleceniem jest „IRSend”, będzie to około 120 kolejnych znaków (plus terminator) potencjalnego wejścia
Teraz, jeśli spojrzymy na miejsca, w których wszystko zostaje odcięte
IRSend Kaseikyo_Sharp 1 1 0
To polecenie (6 znaków), spacja, następnie „Kaseikyo_Sharp” (14 znaków) - i to pozostawia tylko około 5 znaków na resztę args_in. Wszystko więcej zostanie posiekane
Co więcej, jednym z identyfikatorów dostawców jest „Kaseikyo_Mitsubishi”, który sam w sobie składa się z 19 znaków.
Powinno to zostać naprawione poprzez zwiększenie tego
char args[20];do czegoś takiego
char args[40];Pozwoliłoby to na wprowadzenie większego łańcucha dostawcy plus 5-znakowy adres arg, 4-znakowy CMD arg, i trochę więcej dla powtórzeń/zastąpienia (bity, jak sądzę, są faktycznie ustawione w kodzie w folderze „Arduino-IRremote-mod”, tj.
#define KASEIKYO_BITS (KASEIKYO_VENDOR_ID_BITS + KASEIKYO_VENDOR_ID_PARITY_BITS + KASEIKYO_ADDRESS_BITS + KASEIKYO_COMMAND_BITS + KASEIKYO_PARITY_BITS)To powiedziawszy, jeśli OBK potencjalnie pozwoli kiedyś na wyjście w formacie RAW, tablica znaków args z pewnością musiałaby być jeszcze większa.
