Hi,

I need to create some RECS80 IR codes.

I have seen in MakeHEX that there are two different types. So after a lot of forum reading I now have a massive headache and I am no closer to a result.

What I appear to be missing from the data below is what type of RECS code this is. Is that correct?

I have learnt 2 codes (below) but IRTool with decode.dll does not reconise their type.

Can any one help?

Here is all the info I have.


The used code is a modified RECS80.

The received data will be transmitted in modulated mode with 1 Reference bit (REF) followed by 1 toggle bit (T0), 3 address bit (S0…S2) and 6 data bits (A...F).

Between the stop bit and the next start bit (REF) there will be 10ms

Toggle Address Data
Code T0 S2 S1 S0F E D C B ATargetFunction
320 X 1 0 10 0 0 0 0 0Desk_LStore
321 X 1 0 10 0 0 0 0 1Desk_LM1
322 X 1 0 10 0 0 0 1 0Desk_LM2
323 X 1 0 10 0 0 0 1 1Desk_LM3
324 X 1 0 10 0 0 1 0 0Desk_LStore + M1
325 X 1 0 10 0 0 1 0 1Desk_LStore + M2
326 X 1 0 10 0 0 1 1 0Desk_LStore + M3
327 X 1 0 10 0 0 1 1 1Desk_LRef 1U
328 X 1 0 10 0 1 0 0 0Desk_LRef 1D
329 X 1 0 10 0 1 0 0 1Desk_LRef 2U
330 X 1 0 10 0 1 0 1 0Desk_LRef 2D
331 X 1 0 10 0 1 0 1 1Desk_LRef 3U
332 X 1 0 10 0 1 1 0 0Desk_LRef 3D
333 X 1 0 10 0 1 1 0 1Desk_LRef 4U
334 X 1 0 10 0 1 1 1 0Desk_LRef 4D
335 X 1 0 10 0 1 1 1 1Desk_LFunction 1
336 X 1 0 10 1 0 0 0 0Desk_LFunction 2
337 X 1 0 10 1 0 0 0 1Desk_LFunction 3
338 X 1 0 10 1 0 0 1 0Desk_LFunction 4
339 X 1 0 10 1 0 0 1 1Desk_LFunction 5

Learn 1 - REF 1U
0000 006E 0000 000C 000B 0112 000B 00B6 000B 0112 000B 00B6 000B 0112 000B 00B6 000B 00B6 000B 00B6 000B 0112 000B 0112 000B 0112 000B 0247

Learn 2 - REF 1D
0000 006E 0000 000C 000B 0112 000B 0112 000B 0112 000B 00B6 000B 0112 000B 00B6 000B 00B6 000B 0112 000B 00B6 000B 00B6 000B 00B6 000B 0247

If I am reading this correctly then the 10bits it would be:
Learn 1 - 1U
0101000111 - Correct.
Learn 2 - 1D
1101001000 - Correct.

This is a toggle code and the two lernt codes are in different toggle states.

Hopefully someone is willing to tackle this :)

P.S. The reason I need this is that the learnt codes are unreliable, even taking into consideration the toggle bit.

Thanks
D

Hi sydinstaller,

I changed the last word of the learnt Hex Codes to 076A.

eg.

Learn 1 - REF 1U
0000 006E 0000 000C 000B 0112 000B 00B6 000B 0112 000B 00B6 000B 0112 000B 00B6 000B 00B6 000B 00B6 000B 0112 000B 0112 000B 0112 000B 076A

Learn 2 - REF 1D
0000 006E 0000 000C 000B 0112 000B 0112 000B 0112 000B 00B6 000B 0112 000B 00B6 000B 00B6 000B 0112 000B 00B6 000B 00B6 000B 00B6 000B 076A

I then Pasted the Hex Code into IR Tools and got,

Learn 1 - REF 1U
Protocol: REC80
Device: 5
OBC: 7


Learn 2 - REF 1D
Protocol: REC80
Device: 5
OBC: 8


But IR Tools does not give all the info needed. So I used Decode CCF and got this,

Learn 1 - REF 1U
Protocol: REC80
Device: 5
OBC: 7
Misc: T=0 (291/5120/7562)
Frequency: 37.683


Learn 2 - REF 1D
Protocol: REC80
Device: 5
OBC: 8
Misc: T=1 (291/5120/7562)
Frequency: 37.683


On the JP1 Site the REC80 Protocol is explained as follows,

RECS80
UEI protocol: 0045, 0068, 0090 or ???
IRP notation for 0045: {38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,-45m)+
IRP notation for 0068: {33.3k,180,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,^138m)+
EFC translation: 6-bit MSB comp

RECS80 is a family of related protocols with the same structure, but different timing.

These are moderately non robust protocols, so spurious decodes are possible.

The timing differences are not definitive enough for DecodeIr to identify which RECS80 version is which. Instead it displays the timing information in the "misc" field of the output. That will be three numbers formatted as in this example: (157/5048/7572)

Using those three numbers and the frequency, you should be able to determine whether the signals fit the 0045 version, the 0068 version, the 0090 version or none of them. You should look at all the learned signals for your device together when doing that. A single device won't mix versions of RECS80, so any differences in frequency or timing between learns is due to the IR learning process, not due to any differences among the correct signals. You should find one RECS80 version that is a good enough fit for all signals of the device.

For 0045,

* frequency should be between 37000 and 39000
* first timing number between 100 and 200
* second timing number between 4500 and 5500
* third timing number between 6800 and 8300

For 0068,

* frequency should be between 32300 and 34300
* first timing number between 130 and 250
* second timing number between 5100 and 6300
* third timing number between 7700 and 9500

For 0090,

* frequency should be 0
* first timing number between 0 and 40
* second timing number between 4500 and 5500
* third timing number between 6800 and 8300

You may find decodes that don't quite fit either. If it almost fits, it may be worth testing to see if it works, but it's most unlikely to work if the second timing number is above the suggested max or the third timing number is below the suggested min. For example, I found a decode with frequency 41879 and timing numbers (132,5092,7652). The three timing numbers are perfect for protocol 0045, but the frequency is quite wrong. I have no device to test with, but my guess is that it would work anyway. For protocol 0068, the third number 7652 is below the minimum of 7700 making it quite unlikely to work. I found a different device with frequency 33333 and timing (450,5770,8656). For 0068 all but the first number are perfect and I would be quite surprised if it didn't work. For 0045 the second number 5770 is too high for the max of 5500, so it's unlikely to work.

The decodes for RECS80 all report EFCs for protocol 0045. These are not correct EFCs if you select a protocol other than 0045, so it is better to use OBC numbers when creating a JP1 upgrade based on these decodes.


So going by that info I would try the "recs80_45" IRP File in MakeHex, Device=5, T=0 and T=1 if you haven`t already.

I would say that these would be the Function Numbers,

0= 320 X 1 0 10 0 0 0 0 0Desk_LStore
1= 321 X 1 0 10 0 0 0 0 1Desk_LM1
2= 322 X 1 0 10 0 0 0 1 0Desk_LM2
3= 323 X 1 0 10 0 0 0 1 1Desk_LM3
4= 324 X 1 0 10 0 0 1 0 0Desk_LStore + M1
5= 325 X 1 0 10 0 0 1 0 1Desk_LStore + M2
6= 326 X 1 0 10 0 0 1 1 0Desk_LStore + M3
7= 327 X 1 0 10 0 0 1 1 1Desk_LRef 1U
8= 328 X 1 0 10 0 1 0 0 0Desk_LRef 1D
9= 329 X 1 0 10 0 1 0 0 1Desk_LRef 2U
10= 330 X 1 0 10 0 1 0 1 0Desk_LRef 2D
11= 331 X 1 0 10 0 1 0 1 1Desk_LRef 3U
12= 332 X 1 0 10 0 1 1 0 0Desk_LRef 3D
13= 333 X 1 0 10 0 1 1 0 1Desk_LRef 4U
14= 334 X 1 0 10 0 1 1 1 0Desk_LRef 4D
15= 335 X 1 0 10 0 1 1 1 1Desk_LFunction 1
16= 336 X 1 0 10 1 0 0 0 0Desk_LFunction 2
17= 337 X 1 0 10 1 0 0 0 1Desk_LFunction 3
18= 338 X 1 0 10 1 0 0 1 0Desk_LFunction 4
19= 339 X 1 0 10 1 0 0 1 1Desk_LFunction 5

Hope this helps!

Cheers
Jason

Jason,

WOW thanks heaps for the info.

I am getting a Linak system t in the showroom next week. This will give me time to read and understand all the above info.

I have had decodeCCF for some time now and never thought of using it. While not a fast/easy as IRTool it does give some very usefull aditional info (In the case of RECS codes anyway)

I will post back with the test results.

D.

Jason,

It worked a treat.

As a bonus the Linak does not use the toggle bits. T=0 worked each and every time.

Thanks again for the info it is greatly appreciated.

D.

Since I have no clue what the device is nor what its commands mean, this may be a stupid question.

Are there any commands that are used multiple times in a row to activate discrete steps (such as the up arrow key in an on screen menu in many devices)?

The toggle bit in an IR signal usually only matters when you send the same command twice in a row (without any other command in between), and even then it may only matter for certain commands, especially those that operate some discrete step action as I described above.

Did you decide Linak does not use the toggle bit just because each command works once with T=0? Or did you identify the commands/situations (such as menu navigation) most likely to need the toggle bit and test those commands used twice in a row?

Hi John,

I tested by starting and stopping the up and down cycles. I.E. Start going UP, stop (press UP again) continue going UP (press UP again). That is 3x pressing the UP command in a row.

All was good.

My understanding is that if I did need to use a toggle the second button press (UP) would not have worked.

The same was true for DOWN.

That is the also the same under standing I got from reading your post.

Can you please clarify my logic.

Thanks

D.

Sounds like you understand it perfectly and tested it correctly.