search

crankyoldgit / IRremoteESP8266

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/
GNU Lesser General Public License v2.1
2.97k stars 832 forks source link

question : sat tv Decoded G.I.Cable(9) ' is it similar to other , included on the lib ?? #447

Closed gnkarn closed 6 years ago

gnkarn commented 6 years ago

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

CONTROL DE TV SATELITAL      
Decoded G.I.Cable(9): Value:5006 Adrs:0 (16 bits)      
Raw samples(36): Gap:12134      
Head: m9018  s4462      
0:m530 s2202    1:m530 s4462             2:m530 s2202   3:m530 s4462      
4:m530 s2202    5:m530 s2202             6:m530 s2202   7:m530 s2202      
8:m530 s2202    9:m530 s2202             10:m530 s2202  11:m530 s2202      
12:m530 s2206   13:m530 s4462            14:m526 s4462  15:m530 s2206      
       
16:m530      
Extent=66766      
Mark  min:526    max:530      
Space min:2202   max:4462      
power 5006    
guide c0b    
MENU 9806    
OK 8807    
IZ 6C0E    
ARR 2C09    
DER EC06    
ABAJO AC01    
CH MAS D00A    
CH MENOS 3002    
0 0    
1 800F    
2 4007    
3 COOB    
4 2003    
5 A00D    
6 6005    
7 E009    
8 1001    
9 900E    
WATCH CABLE 5006 Value:E0E040BF SON DOS CODIGOS CONSECUTIVOS
gnkarn commented 6 years ago

i found some info here , https://github.com/cyborg5/IRLib2/blob/master/IRLibProtocols/IRLib_P09_GICable.h

will check if protocols are the same .

crankyoldgit commented 6 years ago

The "format" is very similar & standard. It's just a typical 16-bit space-encoded protocol by the looks. According to the link you provided, it operates at 39kHz. None of the existing protocols in this lib use that. Not hard to add etc. Feel free to take a crack at it.

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.

gnkarn commented 6 years ago

thanks , for your input, will do as you recommend and report back .

gnkarn commented 6 years ago

trying to understand how the tools works, how to feed the data , and obtain the output , any brief guide is appreciated ..

gnkarn commented 6 years ago

i found the remote here ! , it matches what i see from dumpV2 ,
still dont know how to use the Tool though

https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/general_instrument/XRC-200.lircd.conf

gnkarn commented 6 years ago

HERE SOME data from the dumpV2.ino program_:

code , POWER COMMAND Timestamp : 003640.724 Encoding : UNKNOWN Code : 21AC1554 (21 bits) Library : v2.4.0

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 Encoding : UNKNOWN Code : 1E384041 (20 bits) Library : v2.4.0

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 Encoding : UNKNOWN Code : E9602C19 (21 bits) Library : v2.4.0

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 ncoding : UNKNOWN Code : 53B466CC (20 bits) Library : v2.4.0

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 ncoding : UNKNOWN Code : 20E64D7 (20 bits) Library : v2.4.0

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 Encoding : UNKNOWN Code : BE244F46 (20 bits) Library : v2.4.0

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

crankyoldgit commented 6 years ago

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.

crankyoldgit commented 6 years ago

I've coded up what I think will support the GI Cable protocol in the GI Cable branch.

@gnkarn Can you test it please?

gnkarn commented 6 years ago

of course , thanks , will test and report back tomorrow. !

gnkarn commented 6 years ago

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 Code : 43F90786 (20 bits) Library : v2.4.0

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 .

gnkarn commented 6 years ago

it is working fine , ! i still have not 100% match cases , but suspect that is the receiver , that is not working fine with 3,3 volts .

ncoding : GICABLE Code : B00C (16 bits) Library : v2.4.0

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 uint64_t data = 0xB00C;

Checked , against the "actual remote"

will , check later with all codes , and the actual device .

thankyou !

gnkarn commented 6 years ago

i have only problem with two keys , the watch cable key and the zero .

the code for the "0" key is recognized as JVC Encoding : JVC Code : FFFF (16 bits) Library : v2.4.0

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 uint32_t address = 0xFF; uint32_t command = 0xFF; uint64_t data = 0xFFFF;

The "watch cable" key , send 2 consecutive codes , and are doceded ok, but , see is marked by the SAMSUNG decoder

imestamp : 004094.004 Encoding : GICABLE Code : 5006 (16 bits) Library : v2.4.0

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 uint64_t data = 0x5006;

Timestamp : 004094.101 Encoding : NEC (Repeat) Code : FFFFFFFFFFFFFFFF (0 bits) Library : v2.4.0

Raw Timing[3]:

uint16_t rawData[3] = {9040, 2174, 606}; // NEC (Repeat) FFFFFFFFFFFFFFFF uint64_t data = 0xFFFFFFFFFFFFFFFF;

Timestamp : 004095.186 Encoding : SAMSUNG Code : E0E040BF (32 bits) Library : v2.4.0

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 uint32_t address = 0x7; uint32_t command = 0x2; uint64_t data = 0xE0E040BF;

so it seams i can match it bu sending first a GIcable 5006 followed by

samsung E0E040BF .

will see if it works on the device...

gnkarn commented 6 years ago

For some reason , de IRsend, is not able to code and send either a ZERO .0 neither FFFF

crankyoldgit commented 6 years ago

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 sendGICable(0x5006, 16, 2);

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. It' also has two repeats.

So to duplicate that sequence, try:

sendGICable(0x5006, 16, 2);
delay(1000);
sendSAMSUNG(0xE0E040BF, 32, 2);
crankyoldgit commented 6 years ago

FYI @gnkarn I've pushed a new update to that branch that should solve the decoding issue of the Zero key.

See: https://github.com/markszabo/IRremoteESP8266/commit/797b67d634b19354aef23e30215a5750c2c3518e

crankyoldgit commented 6 years ago

FYI, 0xE0E040BF is Samsung Power "Toggle". 0xE0E09966 is Samsung Power On, and 0xE0E019E6 is Power Off.

gnkarn commented 6 years ago

perfect, will test it tomorrow , and thanks for the samsung info ! .

crankyoldgit commented 6 years ago

Have you had a chance to test the update https://github.com/markszabo/IRremoteESP8266/tree/gicable branch yet?

crankyoldgit commented 6 years ago

Another reminder to test that branch please. :-)

gnkarn commented 6 years ago

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 notifications@github.com 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 https://github.com/markszabo/IRremoteESP8266/issues/447#issuecomment-388523748, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKRVElULYpQY5Y-3t-PHmx1oA_ONa0Zks5txkhygaJpZM4TXBTH .

crankyoldgit commented 6 years ago

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,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
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. ;-)

gnkarn commented 6 years ago

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 notifications@github.com 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 https://github.com/markszabo/IRremoteESP8266/issues/447#issuecomment-388592011, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKRVLQ5CJyloHaxzxvKC3kiITkAMk3wks5tx3qUgaJpZM4TXBTH .

gnkarn commented 6 years ago

Hi David , for some reason i missed to check correctly the "zero" issue on the GI cable 9 protocol, sorry for that . it is still not working, ( the only one i found) from Global Cache site , this is the code for 0; in their format

code set: 3608 function: DIGIT 0

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.

crankyoldgit commented 6 years ago

Did you git pull on that branch (or re-download) before building/uploading? That is, does the code you compiled include this commit? (https://github.com/markszabo/IRremoteESP8266/commit/797b67d634b19354aef23e30215a5750c2c3518e)

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.

gnkarn commented 6 years ago

Ok , let me check before doing anything , Thanks

El mié., 16 de may. de 2018 1:33 AM, David Conran notifications@github.com 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 https://github.com/markszabo/IRremoteESP8266/commit/797b67d634b19354aef23e30215a5750c2c3518e )

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 https://github.com/markszabo/IRremoteESP8266/issues/447#issuecomment-389391500, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKRVDhQ1H2T0jBmkZjS5W-foHhR3lxpks5ty6wsgaJpZM4TXBTH .

gnkarn commented 6 years ago

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, gnkarn@gmail.com gnkarn@gmail.com escribió:

Ok , let me check before doing anything , Thanks

El mié., 16 de may. de 2018 1:33 AM, David Conran < notifications@github.com> 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 https://github.com/markszabo/IRremoteESP8266/commit/797b67d634b19354aef23e30215a5750c2c3518e )

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 https://github.com/markszabo/IRremoteESP8266/issues/447#issuecomment-389391500, or mute the thread https://github.com/notifications/unsubscribe-auth/ADKRVDhQ1H2T0jBmkZjS5W-foHhR3lxpks5ty6wsgaJpZM4TXBTH .

gnkarn commented 6 years ago

i do think that the problem is not on the receiver , the problem may be on the IR-send.cpp

gnkarn commented 6 years ago

i have scared several time the zero code.

Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) Raw samples(36): Gap:20614 Head: m8994 s4490 0:m498 s2234 1:m526 s2206 2:m502 s2230 3:m502 s2230
4:m526 s2210 5:m502 s2230 6:m502 s2230 7:m526 s2206
8:m502 s2234 9:m526 s2206 10:m526 s2206 11:m526 s2206
12:m526 s2206 13:m530 s2206 14:m526 s2206 15:m526 s2206

16:m530 Extent=57738 Mark min:498 max:530 Space min:2206 max:2234

Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) Raw samples(36): Gap:33494 Head: m9018 s4462 0:m502 s2230 1:m502 s2234 2:m526 s2206 3:m526 s2206
4:m526 s2206 5:m526 s2206 6:m502 s2234 7:m498 s2234
8:m498 s2234 9:m502 s2230 10:m526 s2210 11:m498 s2234
12:m498 s2234 13:m502 s2230 14:m502 s2230 15:m502 s2234

16:m498 Extent=57706 Mark min:498 max:526 Space min:2206 max:2234

Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) Raw samples(36): Gap:4766 Head: m9022 s4462 0:m526 s2206 1:m526 s2206 2:m530 s2202 3:m530 s2206
4:m526 s2206 5:m526 s2206 6:m526 s2206 7:m530 s2202
8:m530 s2206 9:m526 s2206 10:m526 s2206 11:m530 s2202
12:m530 s2202 13:m530 s2206 14:m526 s2206 15:m530 s2202

16:m530 Extent=57738 Mark min:526 max:530 Space min:2202 max:2206

Decoded G.I.Cable(9): Value:0 Adrs:0 (16 bits) Raw samples(36): Gap:17082 Head: m9022 s4462 0:m526 s2206 1:m526 s2206 2:m526 s2206 3:m530 s2206
4:m526 s2206 5:m526 s2206 6:m526 s2206 7:m530 s2202
8:m530 s2206 9:m526 s2206 10:m526 s2206 11:m530 s2202
12:m530 s2206 13:m526 s2206 14:m526 s2206 15:m530 s2202

16:m530 Extent=57738 Mark min:526 max:530 Space min:2202 max:2206

gnkarn commented 6 years ago

and this is what i receive by decoding the generated signal from the library

ecoded Unknown(0): Value:0 Adrs:0 (0 bits) Raw samples(36): Gap:2762 Head: m9050 s4378 0:m614 s4354 1:m618 s2142 2:m618 s2142 3:m618 s4342
4:m618 s2142 5:m618 s2142 6:m618 s2142 7:m618 s2142
8:m618 s2142 9:m618 s2142 10:m618 s2142 11:m618 s2142
12:m618 s4342 13:m618 s4346 14:m614 s4346 15:m614 s2146

16:m618 Extent=69218 Mark min:614 max:618 Space min:2142 max:4354

control   library delta
502   614 -112
2234   4354 -2120
526   618 -92
2206   2142 64
498   618 -120
2234   2142 92
498   498 0
2234   4342 -2108
498   618 -120
2234   2142 92
526   618 -92
2210   2142 68
498   618 -120
2234   2142 92
498   498 0
2234   4346 -2112
498   498 0
2234   2142 92
522   522 0
2210   2142 68
526   526 0
2210   2142 68
498   498 0
2234   4346 -2112
498   618 -120
2234   4342 -2108
498   618 -120
2234   2142 92
498   498 0
2234   2142 92
526   526 0
2210   2146 64

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.

gnkarn commented 6 years ago

im testing with 65536 instead of zero , will report soon.

gnkarn commented 6 years ago

PROBLEM SOLVED !! , have to use 65536 , for the zero code instead of the "0" value .

thanks

crankyoldgit commented 6 years ago

ecoded Unknown(0): Value:0 Adrs:0 (0 bits) Raw samples(36): Gap:2762 Head: m9050 s4378 0:m614 s4354 1:m618 s2142 2:m618 s2142 3:m618 s4342 4:m618 s2142 5:m618 s2142 6:m618 s2142 7:m618 s2142 8:m618 s2142 9:m618 s2142 10:m618 s2142 11:m618 s2142 12:m618 s4342 13:m618 s4346 14:m614 s4346 15:m614 s2146 16:m618

That signal is most definitely not a G.I. Cable "Zero" key signal. How did you produce it? (i.e. code snippet please)

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. sendGICable(0x0); 0x0 is the Zero key according to your table.

e.g. the "bits" in 0,: 3:, 12:, 13:, & 14: are 1's. All the bits should be 0's. It looks like the code is transmitting 0b1001000000001110 = 36878 (Dec) = 0x900E

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.

gnkarn commented 6 years ago

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 .

crankyoldgit commented 6 years ago

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, notifications@github.com 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 https://github.com/markszabo/IRremoteESP8266/issues/447#issuecomment-389718357, or mute the thread https://github.com/notifications/unsubscribe-auth/AMInDD5sLTKZMWnFigy_WIenUVqk0t6rks5tzNZegaJpZM4TXBTH .

gnkarn commented 6 years ago

topic: "cmnd/Multi-IR/irsend" payload: '{"Protocol": "GICABLE","Bits":16,"data":65536}' # 0

crankyoldgit commented 6 years ago

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, notifications@github.com 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 https://github.com/markszabo/IRremoteESP8266/issues/447#issuecomment-389720388, or mute the thread https://github.com/notifications/unsubscribe-auth/AMInDPHnOw0vIZGor0IrIuETnqG_D8KVks5tzNmfgaJpZM4TXBTH .

crankyoldgit commented 6 years ago

A quick look at the Tasmota code indicates it can't send a data value of 0. I think it fails due to this line: https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/xdrv_02_irremote.ino#L301 i.e. if (protocol && bits && data) { Because 0 is the same as False, this if statement will never evaluate to True when data == 0.

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: if (protocol && bits) { instead and it should allow a data value of 0. No idea, if that has any other effect on the rest of the Tasmota code.

gnkarn commented 6 years ago

good catch ! , thankyou

crankyoldgit commented 6 years ago

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. The timing issues may be another matter.

Just checking, how are you capturing the sent from the ESP GI Cable messages? I've seen the format you're reporting before, but I can't immediately place the program that produces that output. i.e. It's not our IRrecvDumpV2's format. Perhaps it's some code using IRlib2's code?

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.

crankyoldgit commented 6 years ago

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.

gnkarn commented 6 years ago

understood , thank you

crankyoldgit commented 6 years ago

this has now been included in the latest official release of the library (v2.4.1)