How to import samsung36 code from irscrutinizer?

[rondnelson99]

I have two 2010 samsung devices. One is a BD-c5900 blu-ray player, and the other is a HW-c560s home theater system. The BD player has a similar model in the file section here, and that worked great. Link here:
http://www.hifi-remote.com/forums/dload ... le_id=9030
However, none of the upgrades here worked for the receiver. I have the original remote, so I set out to follow this tutorial to import it through irscrutinizer.
http://www.hifi-remote.com/wiki/index.p ... moteMaster
The devices were bought at the same time, and the remotes look almost identical. Based on the BD player's working upgrade file, it would imagine that the receiver probably also uses the samsung36 protocol. I set up IrScrutinizer using an arduino as the capture device, but I only had a demodulating receiver, no non-demodulating one. I checked the "use receive for capture" option, but if you think that's the problem, let me know and I'll try to get a sensor at some point. The problem is, unlike the tutorial where irscrutinizer conveniently recognizes what it sees as an NEC1 signal, Most of the time, irscrutinizer can't decode anything, except occasionally when it decodes something like

Code: Select all

GwtS: {CRC=213, D=240, F=119},  beg=0,  end=15 {UNDECODED. length=84}

I would expect it to say something along the lines of Samsung36. I tried taking the GwtS signal and and carrying on with the tutorial, and when I did I never encountered any errors (I selected Samsung36 in Remote Master), But it certainly didn't turn on my device, and capturing the signal back into IrScrutinizer revealed that the signal was very different.

One other thing I tried was uploading one of the example Arduino sketches for the IRRemote library that would print out the raw data which could be copied into IRscrutinizer. That data looks quite a bit different, and unlike connecting the program directly to GirsLite running on the Arduino, the signals are consistently decoded into the GwtS thing.

2 Examples using GirsLite
Usually looks something like this:

Code: Select all

Freq=38000Hz[+2330, -2330, +336, -1235, +336, -1235, +336, -504, +336, -504, +336, -504, +336, -504, +336, -1235, +336, -504, +336, -1235, +336, -1235, +336, -504, +336, -504, +336, -1235, +336, -504, +336, -1235, +336, -504, +336, -1235, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -1235, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -1235, +336, -504, +336, -504, +336, -504, +336, -504, +336, -504, +336, -44875][+2330, -3400, +336, -44875][]

Code: Select all

IRP:{38.0k, 59, msb}<336u, -504u|336u, -21>(2330u, -2330u, A:48, 336u, -44.875m, (2330u, -3400u, 336u, -44.875m)*){A=0xc2ca80200020}

Decode line is empty


On the off chance that it does manage to decode something it looks like this:

Code: Select all

Freq=38000Hz[+2200, -2200, +344, -1235, +344, -1235, +344, -496, +344, -496, +344, -496, +344, -496, +344, -1235, +344, -496, +344, -1235, +344, -1235, +344, -496, +344, -496, +344, -1235, +344, -496, +344, -1235, +344, -496, +344, -1235, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -1235, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -1235, +344, -496, +344, -496, +344, -496, +344, -496, +344, -496, +344, -50100][][]

Decode:

Code: Select all

GwtS: {CRC=213, D=240, F=119},  beg=0,  end=15 {UNDECODED. length=84}

IRP:

Code: Select all

{38.0k, 152, msb}<2, -3|2, -8>(2200u, -2200u, A:48, 2, -50m){A=0xc2ca80200020}

It seems to only manage to decode something when I press the button for a really short time.




Example copying from IrRemote

Code: Select all

Freq=38000Hz[+2175, -2175, +417, -1180, +417, -1180, +417, -417, +417, -417, +417, -417, +417, -417, +417, -1180, +417, -417, +417, -1180, +417, -1180, +417, -417, +417, -417, +417, -1180, +417, -417, +417, -1180, +417, -417, +417, -1180, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -1180, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -1180, +417, -417, +417, -417, +417, -417, +417, -417, +417, -417, +417, -50000][][]

Decode:

Code: Select all

GwtS: {CRC=213, D=240, F=119},  beg=0,  end=15 {UNDECODED. length=84}

IRP:

Code: Select all

{38.0k, 417, msb}<1, -1|1, -3>(5, -5, A:48, 1, -50m){A=0xc2ca80200020}

This way it decodes consistently.


Sorry it I went off topic there, but if I can't get captures into IrScrutinizer properly, there's no way I can get them into RMIR, right?

[The Robman]

What device are you using to capture the signals?

Is your JP1 remote a learning remote? If it is, have you tried using it to capture the signals?

[rondnelson99]

No, it's not a learning remote. I am capturing using an arduino connected to a demodulating IR receiver. Like I said in the first post, I have tried using the GirsLite firmware, which IRscrutiizer can directly connect to, as well as copy/pasting raw signals captured using the IRremote library, and both give different results.

[The Robman]

Yeah, Barf will have to help you with IRScrutinizer, I don't know how to use it.

[rondnelson99]

Upon further analysis, I'm beginning to think that my problem is not to do with IRscrutinizer. I think this 2010 AV receiver must not use the Samsung36 protocol. I found some other arduino sketch that could correctly identify the BD player's signals as Samsung36, but it still saw the receiver's signals as unknown. I was also able to import the BD player's codes into IRscrutinizer, transfer it to RMIR and finally upload it to my remote and everything worked, so I know my recording setup is functional now. Do you know where I should look to try to figure out what protocol it might use? I found Vicky G's Infrared Protocol Primer and it certainly helped me understand this a little better but is these some list of all the supported protocols and their descriptions? Thanks for all the help!

[The Robman]

If you have working learns in an RMIR format I can help with that, let me see the RMIR file.

[rondnelson99]

No, unfortunately those learns I put together was just to test if the recording setup I put together was working. They weren't actually for the AV receiver I was trying to control. I think it must use some really weird protocol that IRscrutinizer doesn't support. I guess the next step is to look into the RMPB and try to figure out how that stuff works.

[Barf]

It appears that the device does not use Samsung36,

Code: Select all

{38.0k, 417, msb}<1, -1|1, -3>(5, -5, A:48, 1, -50m){A=0xc2ca80200020}

while you seem absolutely determined it is...(for example the title of the thead). Not uncommon in this business that a device uses another protocol than the one you expect.

I suggest that you capture the signals as raw (that is on the Scrutinize Remote -> Raw remote pane, export them as text or Girr (with "Raw" selected) and post it to the diagnostic area for us to have a look at. Best if you capture all commands, otherwise a "representative" subset will do. Turn on the repeat finder and signal cleaning (found under the Options menu).

On Controltower, there is a set for "HW-C Series". It contains a mixture of Samsung-36, Teak-k and Necx2 signals!!

Some comment:

I set up IrScrutinizer using an arduino as the capture device, but I only had a demodulating receiver, no non-demodulating one. I checked the "use receive for capture" option

That is correct. Even better, if you are compiling, to undefine the CAPTURE signal in the config.h; that way the firmware will know that there is no non-demodulating receiver. But it is not necesarry.

IRP:

Code: Select all

{38.0k, 417, msb}<1, -1|1, -3>(5, -5, A:48, 1, -50m){A=0xc2ca80200020}

This is an absolutely plausible way to send a 48-bit command, no reason to believe that it is flawed. The other IRPs are numerically close to this one (with exception of the parameter value of course).

Decode:

Code: Select all

	
GwtS: {CRC=213, D=240, F=119},  beg=0,  end=15 {UNDECODED. length=84}	

This is a spurious decode, and should be ignored. (Note that it only matches the first 16 of 84 durations.)

[rondnelson99]

Thanks for the input. Here's that raw dump. When I was exporting, IrScrutinizer warned me that "some signals in export are erroneous." I'm not sure what that means. I'm still not all too familiar with IrScrutinizer, so I hope I didn't do anything wrong.

http://www.hifi-remote.com/forums/dload ... e_id=25965

[Barf]

@rondnelson99:
There is only one command in the file, and it does not have a name. So my guess is that you did not give the commands names. Since the names must be unique, meaning that there can only be one command without name, the rest are ignored. This was probably the meaning of the warning message. Yes, not a very good warning.

[rondnelson99]

Oops. I guess I put all the button names as comments rather than the actual names. Hopefully this dump will be better. I tried Importing back into IrScrutinizer and that worked okay, but exporting still gave me the same warning.

http://www.hifi-remote.com/forums/dload ... e_id=25966

[Barf]

(Note that you can edit your old uploads by uploading a new file "on the top" of the old one, just use the "Edit" button. Several versions of the same file can be confusing and error prone.)

I put the signals through IrpTransmogrifier, and, after some tweaking of the parameters, arrived at a protocol

Code: Select all

{38.0k,400,msb} <1,-1|1,-3>(6,-6,D:32,F:16,1,-43.912m,6,-3412u,1,-43.912m,(6,-3418u,1,-44.86m)*)

with the following parameters (hexadecimal, first D, then F)

Code: Select all

power           c2ca8020        0020
input select    c2ca8020        2450
dimmer          c2ca8020        ca30
1               c2ca8020        80a0
2               c2ca8020        2ef0
3               c2ca8020        ce70
4               c2ca8020        4eb0
5               c2ca8020        0650
6               c2ca8020        0210
7               c2ca8020        8860
8/sleep         c2ca8020        8e30
9               c2ca8020        84e0
0/audio assign  c2ca8020        94f8
pro logic       c2ca8020        2cd0
dsp             c2ca8020        1ec8
skip back       c2ca8020        a850
skip forward    c2ca8020        5087
rewind          c2ca8020        a4d0
fast forward    c2ca8020        58f8
stop            c2ca8020        68d0
play            c2ca8020        c0e0
pause           c2ca8020        e830
vol+            c2ca8020        0460
vol-            c2ca8020        0ce0
tuning/ch+      c2ca8020        c490
tuning/ch-      c2ca8020        cc50
mute            c2ca8020        08a0
asc             c2ca8020        6e88
tuner memory    c2ca8020        1470
sub woofer      c2ca8020        18b0
mo/st           c2ca8020        ee48
setup/menu      c2ca8020        8c10
info            c2ca8020        6af0
return          c2ca8020        9878
exit            c2ca8020        4c90
up              c2ca8020        4ad0
down            c2ca8020        2ab0
left            c2ca8020        a6f0
right           c2ca8020        aa70
enter           c2ca8020        8a50
bd/dvd          c2ca8020        5248
sat             c2ca8020        5ea8
tv              c2ca8020        5408
cd              c2ca8020        5628
multi ch        c2ca8020        5ac8
aux             c2ca8020        da28

[rondnelson99]

Thank you! Am I correct in assuming that the next step would be for me to use RMPB to that information into a JP1 protocol?

I was just looking at the help file in RMPB and it said that it only works for devices with the JP1.3 or earlier interfaces. Currently I'm using an Atlas 1056 B03 which uses the JP2 interface and a MAXQ610 processor. I'm kind of confused though, since the other day I downloaded an upgrade for my roku, which I believe uses its own special protocol (does it?), and that worked fine on my JP2 remote. It did say that a few protocols had been "painstakingly constructed by hand." Is this roku protocol one of those?

I also have a 1056 B01 laying around which does use the JP1.3 protocol, but for some reason my FTDI cable (which is actually just an arduino with the processor taken out) won't work with it. I can probably pick up a new cable if need be though.

[3FG]

I used simpleset.com and it suggested among other possibilities PID=01 60, using setup code Audio 1281. Using a OARUSB04G, digit 1 shoots Teac-K device 0.4, OBC 113. IRScope (sorry, Barf) gives the IRP as

Code: Select all

{37.6k,408,msb}<1,-1|1,-3>(8,-1922u,A:48,1,-42.9m){A=$C2CA80208E30}

which is the same as your digit 8. Other buttons follow the same format. So I think it is highly likely that the correct decode is Teac-K. BTW, examining the executor shows that it has a longer lead out sequence than given in IRScope.

PID 0160 is only available for MAXQ610 and HCS08 processors (and TI2541 is an easy conversion). It is a lengthy executor that seems to correctly compute the Teac-K checksums. Protocols.ini has an entry for PID=01 60, but it isn't yet written in RMIR-friendly form. I don't have time right now to edit such an entry, but I can probably get to it this weekend if no one else does it in the mean time. From that it will be easy to make an upgrade.

[Barf]

Thanx Dave for the observation. As I wrote in a previous contribution, the signals from ControlTower also, partially, decode as Teac-K. However, the timing of the first two durations of the intro, and the first two of the repeat ditto differs so much from the Teac-K signals, so that it strictly speaking does not qualify as Teac-K.

But we are not proving theorems, we cook up things that will be recognized by existing receivers...

With the normally not very sane relative tolerance of 50%, the first of rondnelson99's signals ("power") does decode:

Code: Select all

$ irptransmogrifier -r 0.5 decode 0000 006D 0032 0002 0058 0058 000D 002F 000D \
002F 000D 0013 000D 0013 000D 0013 000D 0013 000D 002F 000D 0013 000D \
002F 000D 002F 000D 0013 000D 0013 000D 002F 000D 0013 000D 002F 000D \
0013 000D 002F 000D 0013 000D 0013 000D 0013 000D 0013 000D 0013 000D \
0013 000D 0013 000D 0013 000D 0013 000D 002F 000D 0013 000D 0013 000D \
0013 000D 0013 000D 0013 000D 0013 000D 0013 000D 0013 000D 0013 000D \
0013 000D 0013 000D 0013 000D 0013 000D 0013 000D 0013 000D 002F 000D \
0013 000D 0013 000D 0013 000D 0013 000D 0013 000D 06AA 0058 0082 000D 06AA
        Teac-K: {D=0,F=0,S=4}

Voila! So I set Options -> Protocol parameters > Relative tolerance to 0.5 in IrScrutinizer, and re-imported the signals. Everyone (except "Skip forward" which appears to have the checksum wrong) decodes! I renamed the nameless signal to "no_name" (which made the error message when exporting disappear). I then exported as Girr, with parameters. The latest (2.10build10) RM can import such files, and generate a device update, which I did. These files are found here.

Actually, it appears that the import did not go quite right, D=1 instead of 0? (Graham, can you have a look?). Also there is a comment in RM

RM/RMIR do not calculate the second byte of the Hex data correctly; it should not be always FF.

that is disturbing...