How to import samsung36 code from irscrutinizer?

Barf · Post by **Barf** » Sun Jun 14, 2020 3:38 am

Now we are making progress!

The signal cleaner of IrScrutinizer is the "culprit". After all, 2350 and 2000 differs only by 17%. For cleaning of IR signals, basically the same rule applies as cleaning of laundry: To little cleaning power and your laundry will not be clean, too much, and more than dirt is removed...

So, (last time...), can you turn off the signal cleaner (and the repeat finder) found under Options, and capture the signals (or at least 10 of them) using the non-demodulating capture, and post it as Girr (with raw)?

It appears that the length of the second duration is crucial. So it is strange that the standard Teac-K does not work.

PS. Please try my Infrared4Arduino (Available in the Arduino library manager with the name "Infrared") as alternative to IRremote.

rondnelson99 · Post by **rondnelson99** » Sun Jun 14, 2020 2:33 pm

Ok, I captured all the "unclean" signals, and replaced my old upload agian. Have a link: https://www.hifi-remote.com/forums/dload ... e_id=25966

the re-transmitted signals work fine now. Unless relative tolerance is set below 0.3, they actually decode as Teac-K again. I tried using the generate tab to make equivalent Teac-K signals, and if I edit the on period of the lead-in pulse to be 1000us shorter, they work. However, the skip forward button is the one exception to this rule. It doesn't seem to decode regardless of the relative tolerance. Not a big deal if that doesn't work though.

To re-iterate
pulse +2366, -2366 is invalid, and is the result of the signal cleaner.
pulse +2468, -1937 is valid, and seems to be the most accurate to the original remote.
pulse +3456, -1728 is valid Teac-K, but is invalid for the AV Receiver.
pulse +2000, -2000 and +2456,-1728 are also valid.

It would be relatively easy for 3FG to edit his executor to send the +2468, -1937 pulse, right? I imagine it would only be a couple of bytes that would have to change. I tried looking at the MAXQ610 code myself, but manually disassembling something written for a processor I've never seen before is a pretty daunting task to me.

Please try my Infrared4Arduino

Yeah, that does seem much more powerful than IrRemote. I'll give it a try sometime.

3FG · Post by **3FG** » Sun Jun 14, 2020 10:34 pm

You can make the changes yourself, without understanding the the meaning of everything in the executor, and it will be more efficient if you do it rather than waiting for me. BTW, the MAXQ machine language is interesting (put another way, it is odd-- every instruction is technically a Move), but the executor itself is written in a format developed by UEI, and is used both with MAXQ and TI2541 class CPUs. But the timing part of this executor is easy to manipulate.

The initial 24 bytes of the executor in the Manual Settings upgrade I posted are

Code: Select all

33 69 41 14 0F 00 12 00 0F 00 2D 00 5F 06 5A 00 5A 00 00 00 5A 00 80 00

The first two bytes are the on and off times in units of 0.16667us. Actually it is one plus the value times 0.16667. So 0x33=51 and 52/6=8.67us, and 0x69 becomes 17.67us for a total of 26.33us or 37.97kHz.
0x41 means 4 bytes of fixed data, 1 byte of variable data. 0x14 means there are 20 bytes timing data which are arranged as

Code: Select all

0F 00 12 00               Data1  On/Off: 395uS/474uS   
0F 00 2D 00               Data0  On/Off: 395uS/1185uS   
5F 06                     LO        Off: 42950uS  
5A 00 5A 00               LI     On/Off: 2370uS/2370uS   
00 00                     alt LO    Off:   0uS  
5A 00 80 00               alt LI On/Off: 2370uS/3371uS

As you may imagine, these timings are in units of the modulation period, which we saw above is 26.33us. Note that this is a little endian setup, and each duration is written in two bytes. The alternate LO is not used, and the alternate lead in is used with the ditto.

Just edit the Code.MAXQ610= line in the RMDU file.

Barf · Post by **Barf** » Mon Jun 15, 2020 4:31 am

rondnelson99 wrote:Ok, I captured all the "unclean" signals, and replaced my old upload agian. Have a link: https://www.hifi-remote.com/forums/dload ... e_id=25966

Thanx. The "subwoofer" signal is probably a mis-read, and the "skip forward" has the checksum wrong, ignoring these two for the sequel.

the re-transmitted signals work fine now. Unless relative tolerance is set below 0.3, they actually decode as Teac-K again.

which goes to show that captures with demodulating sensor is really a blunt instrument... and that 0.3 can sometimes be too much.

After removing the two offending signals, IrpTransmogrifier (with r=0.2) identified the IRP as

Code: Select all

{37.7k,397,msb}<1,-1|1,-3>(6,-5,A:48,1,-42m,(6,-3397u,1,-42m)*)

rondnelson99 · Post by **rondnelson99** » Mon Jun 15, 2020 11:52 am

OK! Thanks for the pointers about the hex code. I got everything I wanted working. I'll probably clean things up a little and then post the device upgrade. It'll probably only contain the protocol for MAXQ610, but I'll leave a link to here in case someone else with a similar receiver wants to build the protocol for their processor.

For some reason the Ipod button doesn't work, and I can't test skip forward as it seems to only do anything when in Ipod mode. I really don't think anyone would want to still use the Ipod functionality of the receiver, because it is just for the old 30-pin style dock, so it only works with 10-year-old phones. So I could really care less and I imagine the same would go for just about anyone else.

Everything else worked though, including subwoofer.

Thanks for all your help! I would be so lost without it.

rondnelson99 · Post by **rondnelson99** » Mon Jun 15, 2020 12:37 pm

Device upgrade is now up. https://www.hifi-remote.com/forums/dload ... e_id=25973