|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Mon Jun 08, 2020 3:28 pm Post subject: How to import samsung36 code from irscrutinizer? |
|
|
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.php?action=file&file_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.php/Importing_Foreign_IR_Remotes_in_RemoteMaster
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: | 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: | 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: | 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: | 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: | GwtS: {CRC=213, D=240, F=119}, beg=0, end=15 {UNDECODED. length=84} |
IRP: Code: | {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: | 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: | GwtS: {CRC=213, D=240, F=119}, beg=0, end=15 {UNDECODED. length=84} |
IRP: Code: | {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? _________________ Just another newbie... |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Jun 08, 2020 4:15 pm Post subject: |
|
|
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? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Mon Jun 08, 2020 4:20 pm Post subject: |
|
|
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. _________________ Just another newbie... |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Jun 08, 2020 4:40 pm Post subject: |
|
|
Yeah, Barf will have to help you with IRScrutinizer, I don't know how to use it. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Mon Jun 08, 2020 4:47 pm Post subject: |
|
|
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! _________________ Just another newbie... |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Jun 08, 2020 9:10 pm Post subject: |
|
|
If you have working learns in an RMIR format I can help with that, let me see the RMIR file. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Mon Jun 08, 2020 10:32 pm Post subject: |
|
|
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. _________________ Just another newbie... |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Tue Jun 09, 2020 2:55 am Post subject: |
|
|
It appears that the device does not use Samsung36,
Code: |
{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:
Quote: | 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.
Quote: |
IRP:
Code: |
{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).
Quote: |
Decode:
Code: |
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.) |
|
Back to top |
|
|
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Tue Jun 09, 2020 12:39 pm Post subject: |
|
|
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.php?action=file&file_id=25965 _________________ Just another newbie... |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Tue Jun 09, 2020 12:57 pm Post subject: |
|
|
@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. |
|
Back to top |
|
|
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Tue Jun 09, 2020 1:15 pm Post subject: |
|
|
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.php?action=file&file_id=25966 _________________ Just another newbie... |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Wed Jun 10, 2020 7:16 am Post subject: |
|
|
(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: |
{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: |
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
|
|
|
Back to top |
|
|
rondnelson99
Joined: 07 Jun 2020 Posts: 19
|
Posted: Wed Jun 10, 2020 1:50 pm Post subject: |
|
|
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. _________________ Just another newbie... |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Thu Jun 11, 2020 12:41 am Post subject: |
|
|
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: | {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. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Thu Jun 11, 2020 3:20 am Post subject: |
|
|
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: |
$ 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
Quote: | RM/RMIR do not calculate the second byte of the Hex data correctly; it should not be always FF. |
that is disturbing... |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|