question : sat tv Decoded G.I.Cable(9) ' is it similar to other , included on the lib ?? #447
Comments
|
i found some info here , https://github.com/cyborg5/IRLib2/blob/master/IRLibProtocols/IRLib_P09_GICable.h will check if protocols are the same . |
|
The "format" is very similar & standard. It's just a typical 16-bit space-encoded protocol by the looks. If you use the IRrecvDumpV2 program and pass its output to the AutoAnalyse script in the tools/ dir and set the option to produce code, it will almost give you a working solution, for sending at least. I'm not going to offer to do it without some raw captures. |
|
thanks , for your input, will do as you recommend and report back . |
|
trying to understand how the tools works, how to feed the data , and obtain the output , |
|
i found the remote here ! , it matches what i see from dumpV2 , |
|
HERE SOME data from the dumpV2.ino program_: code , POWER COMMAND Raw Timing[41]:
uint16_t rawData[41] = {9064, 4408, 580, 2152, 578, 4410, 580, 2150, 580, 4408, 580, 1574, 86, 488, 596, 2136, 580, 2150, 580, 2152, 578, 2152, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 4410, 578, 4410, 580, 2150, 580, 32858, 9064, 2150, 580}; // UNKNOWN 21AC1554 GUIDE BUTTON Raw Timing[39]:
uint16_t rawData[39] = {9038, 4432, 554, 2176, 554, 2176, 554, 2176, 554, 2176, 528, 4460, 554, 4434, 528, 2202, 528, 2202, 528, 2202, 528, 2202, 528, 2202, 528, 2202, 528, 4460, 528, 2202, 528, 4460, 528, 4462, 526, 30634, 9040, 2176, 552}; // UNKNOWN 1E384041 ON DEMAND Raw Timing[41]:
uint16_t rawData[41] = {9036, 4434, 734, 1998, 578, 4410, 580, 2150, 580, 4410, 580, 4408, 580, 552, 84, 1504, 590, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 4408, 580, 2150, 580, 4410, 580, 2150, 580, 30606, 9064, 2150, 580}; // UNKNOWN E9602C19 MENU Raw Timing[39]:
uint16_t rawData[39] = {9038, 4434, 528, 4460, 554, 2178, 528, 2202, 528, 4460, 552, 4436, 528, 2202, 554, 2176, 528, 2202, 528, 2202, 528, 2202, 554, 2176, 528, 2202, 528, 2204, 528, 4460, 528, 4460, 528, 2202, 526, 30638, 9012, 2200, 528}; // UNKNOWN 53B466CC OK SELECT Raw Timing[39]:
uint16_t rawData[39] = {9064, 4408, 580, 4408, 580, 2152, 578, 2150, 580, 2150, 580, 4408, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 2150, 580, 4408, 580, 4408, 580, 4408, 580, 30622, 9066, 2148, 580}; // UNKNOWN 20E64D7 LEFT Raw Timing[39]:
uint16_t rawData[39] = {9040, 4434, 554, 2176, 580, 4408, 554, 4434, 582, 2148, 554, 4434, 580, 4408, 556, 2174, 580, 2150, 580, 2150, 582, 2148, 556, 2176, 580, 2150, 580, 4408, 580, 4408, 580, 4408, 582, 2150, 580, 26078, 9066, 2148, 580}; // UNKNOWN BE244F46 |
|
Some notes & observations from a quick look at the protocol.
@gnkarn Given the data you provided, I'm fairly certain the messages are NOT at the same freq. modulation as your IR receiver. e.g. Some odd pulses of around 80 usecs in some of your signals. Don't expect to get reliable capture/detection using that setup. However, there is probably enough data here and elsewhere to work out a send/decode routine etc. I'd not trust the raw captures that are 41 long, the 39 long ones are cleaner/better. |
* sendGICable() and decodeGICable() routines. * Add example & tools support. * Basic unit tests. * Based on data/info in Issue #447 Note: Untested against real devices. 39kHz frequency modulation based on external reference, but unverified. Observations indicate that it's _not_ 38kHz.
|
I've coded up what I think will support the GI Cable protocol in the GI Cable branch. @gnkarn Can you test it please? |
|
of course , thanks , will test and report back tomorrow. ! |
|
results after test : i sent this command : cmnd/Multi-IR/irsend {"Protocol": "GICABLE","Bits":16,"data":5006} and the results from dumpv2 ino was: ncoding : UNKNOWN Raw Timing[39]:
uint16_t rawData[39] = {9058, 4358, 634, 2126, 636, 2122, 636, 2122, 636, 4322, 638, 2122, 636, 2120, 638, 4320, 638, 4320, 636, 4322, 638, 2120, 638, 2120, 638, 2120, 638, 4320, 638, 4320, 638, 4320, 640, 2122, 638, 26056, 9098, 2116, 636}; // UNKNOWN 43F90786 what seams very different from the original , but i understand that decoder form dumpv2 is not updated , so will check with the actual device and see what happens there . |
|
it is working fine , ! ncoding : GICABLE Raw Timing[39]:
uint16_t rawData[39] = {9058, 4352, 638, 4324, 638, 2120, 640, 4320, 638, 4320, 638, 2118, 640, 2118, 640, 2118, 750, 2008, 640, 2118, 640, 2120, 638, 2120, 638, 2120, 638, 4318, 640, 4318, 640, 2120, 638, 2124, 640, 30442, 9100, 2118, 638}; // GICABLE B00C Checked , against the "actual remote" will , check later with all codes , and the actual device . thankyou ! |
|
i have only problem with two keys , the watch cable key and the zero . the code for the "0" key is recognized as JVC Raw Timing[39]:
uint16_t rawData[39] = {9036, 4434, 552, 2178, 552, 2178, 552, 2180, 550, 2178, 552, 2178, 550, 2180, 552, 2178, 552, 2178, 550, 2180, 552, 2178, 526, 2204, 552, 2178, 552, 2178, 526, 2204, 526, 2204, 526, 2204, 526, 41932, 9036, 2176, 552}; // JVC FFFF The "watch cable" key , send 2 consecutive codes , and are doceded ok, but , see is marked by the SAMSUNG decoder imestamp : 004094.004 Raw Timing[39]:
uint16_t rawData[39] = {9064, 4408, 580, 2150, 580, 4408, 606, 2126, 578, 4410, 606, 2124, 606, 2124, 606, 2126, 578, 2150, 606, 2124, 606, 2124, 604, 2124, 580, 2152, 630, 2100, 630, 4358, 578, 4410, 604, 2126, 580, 32846, 9088, 2124, 604}; // GICABLE 5006 Timestamp : 004094.101 Raw Timing[3]:
uint16_t rawData[3] = {9040, 2174, 606}; // NEC (Repeat) FFFFFFFFFFFFFFFF Timestamp : 004095.186 Raw Timing[203]:
uint16_t rawData[203] = {4572, 4408, 684, 1548, 658, 1572, 656, 1574, 660, 468, 658, 472, 682, 446, 658, 470, 658, 472, 632, 1600, 682, 1548, 684, 1548, 684, 444, 658, 470, 658, 470, 684, 444, 684, 444, 658, 470, 658, 1574, 656, 472, 658, 470, 684, 444, 658, 470, 656, 472, 656, 472, 684, 1548, 658, 470, 658, 1574, 632, 1598, 658, 1574, 684, 1548, 658, 1574, 658, 1572, 658, 46206, 4572, 4410, 684, 1548, 684, 1548, 658, 1572, 658, 470, 684, 444, 684, 444, 658, 472, 656, 472, 684, 1546, 658, 1572, 684, 1548, 658, 472, 658, 470, 684, 444, 658, 470, 658, 472, 656, 472, 658, 1574, 658, 470, 684, 444, 684, 444, 658, 470, 656, 472, 682, 446, 658, 1572, 682, 446, 684, 1548, 658, 1574, 684, 1548, 684, 1548, 656, 1574, 684, 1548, 658, 46194, 4600, 4382, 658, 1574, 658, 1574, 684, 1546, 658, 470, 656, 474, 684, 442, 658, 470, 658, 470, 684, 1546, 658, 1574, 658, 1572, 684, 444, 658, 470, 658, 470, 658, 472, 684, 444, 658, 470, 684, 1548, 658, 470, 656, 472, 656, 472, 684, 444, 660, 470, 658, 470, 684, 1548, 660, 470, 656, 1574, 682, 1548, 658, 1572, 658, 1574, 684, 1546, 658, 1572, 658}; // SAMSUNG E0E040BF so it seams i can match it bu sending first a GIcable 5006 samsung E0E040BF . will see if it works on the device... |
|
For some reason , de IRsend, is not able to code and send either a ZERO .0 |
|
The "Timestamp : 004094.101" message is just a GICable repeat. They look almost identical to an NEC repeat. Not much we can do to tell the difference reliably. As the GICable protocol already has a repeat builtin so it needs an additional one, I'd try Re: "Timestamp : 004095.186". That's about 1 second after the GI code. I'm guessing the remote is configured to send a Samsung TV code to turn on/adjust a TV etc. I think that's a function of the remote, Not the protocol. So to duplicate that sequence, try: |
|
FYI, 0xE0E040BF is Samsung Power "Toggle". |
|
perfect, will test it tomorrow , and thanks for the samsung info ! . |
|
Have you had a chance to test the update https://github.com/markszabo/IRremoteESP8266/tree/gicable branch yet? |
|
Another reminder to test that branch please. :-) |
|
I have tested , Samsung TV and the new gicable9 , it works perfect .
Will upload some evidence of my installation as soon as I can.
What I found in the Samsung case , is that as don't have specific codes for
input source selection , have to use cursor and select, it is very hard to
do a reliable automation .
Thankyou
El vie., 11 de may. de 2018 11:26 PM, David Conran <[email protected]>
escribió:
… Another reminder to test that branch please. :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#447 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRVElULYpQY5Y-3t-PHmx1oA_ONa0Zks5txkhygaJpZM4TXBTH>
.
|
|
Excellent. I'm glad it worked! FYI, there are discrete codes to select specific Samsung TV input sources. I used them on my HA setup. I got them from the Global Cache IR database (https://irdb.globalcache.com/). Here is an example from the Samsung Most Models set # :595 : Either make the appropriate sendGC() or sendPronto() call, or see if it converts to a sendSAMSUNG() code via: e.g. The GlobalCache IR db for samsung has input selection codes for pretty much every physical input source you'd probably want. It avoids the whole navigation thing. ;-) |
|
This is very good information ,
I will be able to finish my setup with it ,
Thank you !!!
El sáb., 12 de may. de 2018 9:13 PM, David Conran <[email protected]>
escribió:
… Excellent. I'm glad it worked!
FYI, there are discrete codes to select specific Samsung TV input sources.
I used them on my HA setup.
e.g. "INPUT HDMI 1", "INPUT COMPONENT 2", etc.
I got them from the Global Cache IR database (
https://irdb.globalcache.com/).
Here is an example from the Samsung Most Models set # :595 :
"INPUT HDMI
1","sendir,1:1,1,38000,1,1,173,173,21,65,21,65,21,65,21,21,21,21,21,21,21,21,21,21,21,65,21,65,21,65,21,21,21,21,21,21,21,21,21,21,21,65,21,21,21,21,21,65,21,21,21,65,21,65,21,65,21,21,21,65,21,65,21,21,21,65,21,21,21,21,21,21,21,1832","0000
006D 0022 0000 00ad 00ad 0015 0041 0015 0041 0015 0041 0015 0015 0015 0015
0015 0015 0015 0015 0015 0015 0015 0041 0015 0041 0015 0041 0015 0015 0015
0015 0015 0015 0015 0015 0015 0015 0015 0041 0015 0015 0015 0015 0015 0041
0015 0015 0015 0041 0015 0041 0015 0041 0015 0015 0015 0041 0015 0041 0015
0015 0015 0041 0015 0015 0015 0015 0015 0015 0015 0728",,
Either make the appropriate sendGC() or sendPronto() call, or see if it
converts to a sendSAMSUNG() code via:
$ cd tools
$ make gc_decode
[Lots of compiler output deleted]
$ ./gc_decode 38000,1,1,173,173,21,65,21,65,21,65,21,21,21,21,21,21,21,21,21,21,21,6
5,21,65,21,65,21,21,21,21,21,21,21,21,21,21,21,65,21,21,21,21,21,65,21,21,21,65,21,65,21,65,21,21,21,65,21,65,21,21,21,65,21,21,21,21,21,21,21,1832
Code length 71
Code type 7 (SAMSUNG)
Code bits 32
Code value 0xe0e09768
Code address 0x7
Code command 0xe9
e.g. sendSAMSUNG(0xe0e09768);
The GlobalCache IR db for samsung has input selection codes for pretty
much every physical input source you'd probably want. It avoids the whole
navigation thing. ;-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#447 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRVLQ5CJyloHaxzxvKC3kiITkAMk3wks5tx3qUgaJpZM4TXBTH>
.
|
|
Hi David , code set: 3608 code1: sendir,1:1,1,38000,1,37,343,173,19,87,19,86,19,87,19,87,19,86,19,87,19,87,18,87,19,87,19,86,19,87,19,87,18,87,19,87,19,86,19,87,19,1536,344,86,19,1536 hex code1: 0000 006D 0012 0002 0157 00AD 0013 0057 0013 0056 0013 0057 0013 0057 0013 0056 0013 0057 0013 0057 0012 0057 0013 0057 0013 0056 0013 0057 0013 0057 0012 0057 0013 0057 0013 0056 0013 0057 0013 0600 0158 0056 0013 0600 let me know if you need any test from my side. |
|
Did you You can check if it does by looking at/around line 362 in src/IRrecv.cpp. It should have the GI decode before the JVC one. With that change I added a unittest (https://github.com/markszabo/IRremoteESP8266/blob/gicable/test/ir_GICable_test.cpp#L136) for that exact situation and using your above Global Cache example, it decodes as a G.I. Cable with a value of 0x0 as expected. e.g. Thus, as far as I can tell, it should be decoding correctly, if you are up-to-date with the code on that branch. |
|
Ok , let me check before doing anything ,
Thanks
El mié., 16 de may. de 2018 1:33 AM, David Conran <[email protected]>
escribió:
… Did you git pull on that branch (or re-download) before
building/uploading?
That is, does the code you compiled include this commit? (797b67d
<797b67d>
)
You can check if it does by looking at/around line 362 in src/IRrecv.cpp.
It should have the GI decode before the JVC one.
With that change I added a unittest (
https://github.com/markszabo/IRremoteESP8266/blob/gicable/test/ir_GICable_test.cpp#L136)
for that exact situation *and* using your above Global Cache example, it
decodes as a G.I. Cable with a value of 0x0 as expected.
e.g.
IRremoteESP8266$ git checkout gicable
Switched to branch 'gicable'
Your branch is up-to-date with 'origin/gicable'.
IRremoteESP8266$ git pull
Already up-to-date.
IRremoteESP8266$ cd tools
IRremoteESP8266/tools$ make
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRutils.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRtimer.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRsend.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRrecv.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_NEC.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sony.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Samsung.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_JVC.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_RCMM.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_RC5_RC6.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_LG.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Mitsubishi.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Fujitsu.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sharp.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sanyo.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Denon.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Dish.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Panasonic.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Whynter.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Coolix.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Aiwa.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sherwood.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Kelvinator.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Daikin.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Gree.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Pronto.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_GlobalCache.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Nikai.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Toshiba.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Midea.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Magiquest.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Lasertag.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Carrier.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Haier.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Hitachi.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_GICable.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -I../src -I../test -c gc_decode.cpp
g++ -DUNIT_TEST -g -Wall -Wextra -pthread -lpthread IRutils.o IRtimer.o IRsend.o IRrecv.o ir_NEC.o ir_Sony.o ir_Samsung.o ir_JVC.o ir_RCMM.o ir_RC5_RC6.o ir_LG.o ir_Mitsubishi.o ir_Fujitsu.o ir_Sharp.o ir_Sanyo.o ir_Denon.o ir_Dish.o ir_Panasonic.o ir_Whynter.o ir_Coolix.o ir_Aiwa.o ir_Sherwood.o ir_Kelvinator.o ir_Daikin.o ir_Gree.o ir_Pronto.o ir_GlobalCache.o ir_Nikai.o ir_Toshiba.o ir_Midea.o ir_Magiquest.o ir_Lasertag.o ir_Carrier.o ir_Haier.o ir_Hitachi.o ir_GICable.o gc_decode.o -o gc_decode
IRremoteESP8266/tools$ ./gc_decode 38000,1,37,343,173,19,87,19,86,19,87,19,87,19,86,19,87,19,87,18,87,19,87,19,86,19,87,19,87,18,87,19,87,19,86,19,87,19,1536,344,86,19,1536
Code length 43
Code type 41 (GICABLE)
Code bits 16
Code value 0x0
Code address 0x0
Code command 0x0
Thus, as far as I can tell, it should be decoding correctly, if you are
up-to-date with the code on that branch.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#447 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRVDhQ1H2T0jBmkZjS5W-foHhR3lxpks5ty6wsgaJpZM4TXBTH>
.
|
|
David , I checked the code and yes I have compiled using the version that
have de gicode detection before JVC
The receiver is not recognizing the zero digit.
El mié., 16 de may. de 2018 8:58 AM, [email protected] <[email protected]>
escribió:
… Ok , let me check before doing anything ,
Thanks
El mié., 16 de may. de 2018 1:33 AM, David Conran <
***@***.***> escribió:
> Did you git pull on that branch (or re-download) before
> building/uploading?
> That is, does the code you compiled include this commit? (797b67d
> <797b67d>
> )
>
> You can check if it does by looking at/around line 362 in src/IRrecv.cpp.
> It should have the GI decode before the JVC one.
>
> With that change I added a unittest (
> https://github.com/markszabo/IRremoteESP8266/blob/gicable/test/ir_GICable_test.cpp#L136)
> for that exact situation *and* using your above Global Cache example, it
> decodes as a G.I. Cable with a value of 0x0 as expected.
>
> e.g.
>
> IRremoteESP8266$ git checkout gicable
> Switched to branch 'gicable'
> Your branch is up-to-date with 'origin/gicable'.
> IRremoteESP8266$ git pull
> Already up-to-date.
> IRremoteESP8266$ cd tools
> IRremoteESP8266/tools$ make
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRutils.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRtimer.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRsend.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/IRrecv.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_NEC.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sony.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Samsung.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_JVC.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_RCMM.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_RC5_RC6.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_LG.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Mitsubishi.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Fujitsu.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sharp.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sanyo.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Denon.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Dish.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Panasonic.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Whynter.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Coolix.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Aiwa.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Sherwood.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Kelvinator.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Daikin.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Gree.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Pronto.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_GlobalCache.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Nikai.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Toshiba.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Midea.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Magiquest.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Lasertag.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Carrier.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Haier.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_Hitachi.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -c ../src/ir_GICable.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -I../src -I../test -c gc_decode.cpp
> g++ -DUNIT_TEST -g -Wall -Wextra -pthread -lpthread IRutils.o IRtimer.o IRsend.o IRrecv.o ir_NEC.o ir_Sony.o ir_Samsung.o ir_JVC.o ir_RCMM.o ir_RC5_RC6.o ir_LG.o ir_Mitsubishi.o ir_Fujitsu.o ir_Sharp.o ir_Sanyo.o ir_Denon.o ir_Dish.o ir_Panasonic.o ir_Whynter.o ir_Coolix.o ir_Aiwa.o ir_Sherwood.o ir_Kelvinator.o ir_Daikin.o ir_Gree.o ir_Pronto.o ir_GlobalCache.o ir_Nikai.o ir_Toshiba.o ir_Midea.o ir_Magiquest.o ir_Lasertag.o ir_Carrier.o ir_Haier.o ir_Hitachi.o ir_GICable.o gc_decode.o -o gc_decode
> IRremoteESP8266/tools$ ./gc_decode 38000,1,37,343,173,19,87,19,86,19,87,19,87,19,86,19,87,19,87,18,87,19,87,19,86,19,87,19,87,18,87,19,87,19,86,19,87,19,1536,344,86,19,1536
> Code length 43
> Code type 41 (GICABLE)
> Code bits 16
> Code value 0x0
> Code address 0x0
> Code command 0x0
>
> Thus, as far as I can tell, it should be decoding correctly, if you are
> up-to-date with the code on that branch.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#447 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ADKRVDhQ1H2T0jBmkZjS5W-foHhR3lxpks5ty6wsgaJpZM4TXBTH>
> .
>
|
|
i do think that the problem is not on the receiver , the problem may be on the IR-send.cpp |
|
i have scared several time the zero code. Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) 16:m530 Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) 16:m498 Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) 16:m530 Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) 16:m530 |
|
and this is what i receive by decoding the generated signal from the library ecoded Unknown(0): Value:0 Adrs:0 (0 bits) 16:m618
so , you can see the differences im detecting between the code generated by the control, and by the library. let me know if you need other test. |
|
im testing with 65536 instead of zero , will report soon. |
|
PROBLEM SOLVED !! , have to use 65536 , for the zero code instead of the "0" value . thanks |
That signal is most definitely not a G.I. Cable "Zero" key signal. It should look like this Unit Test https://github.com/markszabo/IRremoteESP8266/blob/gicable/test/ir_GICable_test.cpp#L13 which is sending a 0. e.g. e.g. the "bits" in 0,: 3:, 12:, 13:, & 14: are 1's. All the bits should be 0's. According to the table at the start of this issue, 0x900E is the "Nine" key. As for it not matching as a GI cable, looks like we may need to adjust the timings. Try lowering them a little (like half of your calculated offsets) so that they are in the middle of the range for the values you are seeing. |
|
im sending the decimal value the same way as for all other commands , via mqtt from home assistant using tasmota on a sonoff basic . i have not studied what may be the problem with the zero specifically , as after doing some test on sending and receiving i realised that the 65536 decimal code generated the exact match fro the ZERO key value . don't know why the code is "distorted" for the zero value , i followed the code and count find a cause . |
|
What is the MQTT string that is being sent? Assuming you are using our
example code, it should be in the "/send" MQTT topic, and what is in the
"/sent" topic?"
…On Thu., 17 May 2018, 11:46 am gus, ***@***.***> wrote:
im sending the decimal value the same way as for all other commands , via
mqtt from home assistant using tasmota on a sonoff basic . i have not
studied what may be the problem with the zero specifically , as after doing
some test on sending and receiving i realised that the 65536 decimal code
generated the exact match fro the ZERO key value .
don't know why the code is "distorted" for the zero value , i followed the
code and count find a cause .
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#447 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMInDD5sLTKZMWnFigy_WIenUVqk0t6rks5tzNZegaJpZM4TXBTH>
.
|
|
topic: "cmnd/Multi-IR/irsend" |
|
Ah. It looks like you are using Tasmota to send. I think the bug may be in
there.
What was the old '0' commend you were sending?
…On Thu., 17 May 2018, 12:00 pm gus, ***@***.***> wrote:
topic: "cmnd/Multi-IR/irsend"
payload: '{"Protocol": "GICABLE","Bits":16,"data":65536}' # 0
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#447 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMInDPHnOw0vIZGor0IrIuETnqG_D8KVks5tzNmfgaJpZM4TXBTH>
.
|
|
A quick look at the Tasmota code indicates it can't send a Your hack of using 65536 makes the data value non-zero, and tricks the Tasmota software into sending. Thus, the bug is really with the Sonoff Tasmota IR implementation, not with our library. Try replacing that line with: |
|
good catch ! , thankyou |
|
It's now fixed in the dev branch of Tasmota. As I said, the issue isn't with the code I wrote in the gicable branch. Just checking, how are you capturing the sent from the ESP GI Cable messages? Please use our IRrecvDumpV2 for reporting things here, as then I'm sure what code is being used, so I know I'm comparing apples to apples etc. |
* Initial support for G.I. Cable protocol * sendGICable() and decodeGICable() routines. * Add example & tools support. * Basic unit tests. * Based on data/info in Issue #447 * Change GIcable/JVC decode order. GICable "Zero" key is being decoded as a JVC signal. GICable has a manditory repeat code which it checks for. Move it before JVC decoding should make it match or discard correctly any JVC/GICable issues. Add a unit test for this case. Note: Untested against real devices. 39kHz frequency modulation based on external reference, but unverified. Observations indicate that it's _not_ 38kHz.
|
Please note, this (GICABLE) protocol will be number 43 when the Hitachi A/C update gets applied in #461 Typically this only matters if you hardwired the decode type to a number (e.g. not to GICABLE) or if you use MQTT and the IRMQTTServer example code. This GICable support will be in the next official release. |
|
understood , thank you |
|
this has now been included in the latest official release of the library (v2.4.1) |
Ref: Issue arendst#2751 Incorrect assumption that if the result of `strtoul()` is zero (0) it is a parse failure. That's incorrect as the "data" payload could actually be 0. Ref: crankyoldgit/IRremoteESP8266#447 (comment)
i would like to know if this code is similar to other already on the library , ) not the commands of course, but the format and , times , in order to generate the value.
thankyou
The text was updated successfully, but these errors were encountered: