JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

How to import samsung36 code from irscrutinizer?
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Jun 14, 2020 4:38 am    Post subject: Reply with quote

Now we are making progress! Very Happy Cool

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
rondnelson99



Joined: 07 Jun 2020
Posts: 19

                    
PostPosted: Sun Jun 14, 2020 3:33 pm    Post subject: Reply with quote

Ok, I captured all the "unclean" signals, and replaced my old upload agian. Have a link: http://www.hifi-remote.com/forums/dload.php?action=file&file_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.

Quote:
Please try my Infrared4Arduino

Yeah, that does seem much more powerful than IrRemote. I'll give it a try sometime.
_________________
Just another newbie...
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun Jun 14, 2020 11:34 pm    Post subject: Reply with quote

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:
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:
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.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Jun 15, 2020 5:31 am    Post subject: Reply with quote

rondnelson99 wrote:
Ok, I captured all the "unclean" signals, and replaced my old upload agian. Have a link: http://www.hifi-remote.com/forums/dload.php?action=file&file_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.

Quote:

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:
{37.7k,397,msb}<1,-1|1,-3>(6,-5,A:48,1,-42m,(6,-3397u,1,-42m)*)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
rondnelson99



Joined: 07 Jun 2020
Posts: 19

                    
PostPosted: Mon Jun 15, 2020 12:52 pm    Post subject: Reply with quote

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.
_________________
Just another newbie...
Back to top
View user's profile Send private message
rondnelson99



Joined: 07 Jun 2020
Posts: 19

                    
PostPosted: Mon Jun 15, 2020 1:37 pm    Post subject: Reply with quote

Device upgrade is now up. http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25973
_________________
Just another newbie...
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control