JP1 Remotes

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

Thanks everyone! It seems like you're making progress! On my 1056B03 remote with the MAXQ610 processor, I tried Barf's upgrade file. It didn't control my receiver, even after changing the device code to 0 like you mentioned. However, capturing the JP2 remote's signals back into irScrutinizer led to rather strange results (or maybe they're completely normal, I don't really know what I'm doing.) The majority of buttons don't decode at all, but there are some that decode perfectly and consistently. the following is a complete list of the correctly decoding buttons:

Info
no_name (which was supposed to be named Ipod; sorry for not putting that in)
left
fast forward
2
0/audio assign

Every other button never decodes. My guess would be that it has to do with that comment about the second byte, and for those few keys FF just happens to be correct, but my guess probably isn't useful at all, as I've only been here for less than a week. I should note that the buttons which decode correctly still don't control the receiver.

Let me know if there's any dumps or anything that would be helpful. Again, I don't know how this scenario usually goes down, but at least I'm learning lots in the process.

I also edited my upload to fix the missing name.
_________________
Just another newbie...

Barf · Posted: Thu Jun 11, 2020 1:10 pm Post subject:

rondnelson99, can you try the following;

Equip your Arduino with a sendind IR LED. (See for example this for inspiration). Important: first make sure that it works and that you can send IR signals to something simple, for example a Sony or Philips TV. After that, try to send the commands in the girr file contained in my zip, and see if your Samsung reacts.

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

Yeah, I was able to do that. I had to harvest an IR led from an old remote, but I got it. I was able to control my TV using IrScrutinizer, but I was unable to control my Samsung receiver with your girr file. I was also unable to re-transmit captured signals from the original remote. Was that to be expected since the demodulating receiver puts everything into 38khz?
_________________
Just another newbie...

3FG · Expert Joined: 19 May 2009 Posts: 3367

I've uploaded a tested upgrade which shoots the Teac-K protocol. Barf's upgrade, as he feared from the messages, had both the wrong device number and checksum. To use it, add the following entry to protocols.ini:

Barf · Posted: Fri Jun 12, 2020 2:43 am Post subject:

3FG · Expert Joined: 19 May 2009 Posts: 3367

I edited the link to the upgrade.

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

Well I tried 3FG's new upgrade and it did not control my receiver, but at least it calculates the checksums properly, so it'll probably help anyone else with Teak-K remotes.

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

My dad also owns one of those fancy Logitech Smart Hub remotes, and I set that up for the receiver. I tried plugging the capture pin on the arduino directly into the ir blaster output plug on the hub in order to double-check my captures while bypassing all infrared hardware entirely. The captures came out identical, save for the original remote's signals being slightly stretched out. (is that something that happens because of low battery levels?) Anyway, At this point I really don't think my new captures have any problems. But then again, if the captures are fine, I should be able to play them back as well, so something isn't working.

BTW, the fancy Logitech hub is able to control the receiver.
_________________
Just another newbie...

3FG · Expert Joined: 19 May 2009 Posts: 3367

Have you tried capturing any of the signals from the upgrade in the 1056B03? I ask for two reasons. I'd like to see the difference between the original remote and the 1056B03--it's difficult for me to imagine that a receiver uses a IR protocol which has the same OEM numbers and overall framing as Teac-K (and the same device, subdevice and OBCs) but differs only in the lead in timing. Secondly it can form a useful check that the the JP1 programming was successful.

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

Yeah, everything from the 1056B03 decodes as valid Teac-k, with all the expected function codes etc. Here's a raw capture of a subset of the commands.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25970

Some other findings:
- Other arduino programs (I tested the IrRecord demo for the IrRemote library) are able to take the original remote's signals, record them as raw, and spit them out, even when using the demodulating receiver. The AV receiver accepts this signal.

- I tried capturing the original remote's signals into Irscrutinizer. I then got another arduino and another session of Irscrutinuzer, put the two devices right beside each other, and transmitted the signal from one arduino to the other. It was perfectly re-created in the other window.

The first test seems to indicate a problem with how IrScrutinizer transmits raw signals, at least through an arduino running the GirsLite firmware. The second test seems to indicate that IrScrutinizer's transmissions are flawless. It all seems odd to me.
_________________
Just another newbie...

3FG · Expert Joined: 19 May 2009 Posts: 3367

I've updated the upgrade to Manual Settings pid = 01FF, using the same basic executor code but with the lead in and ditto timings revised to match your learns. Please give it a try.

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

They decode pretty much exactly the same, but somehow don't work.

For example, Power gives this

JP1 remote:
{38.5k,426,msb}<1,-1|1,-3>(2360u,-2360u,A:48,1,-43.761m,(2360u,-8,1,-43.761m)3){A=0xc2ca80200020}

original remote:
{37.7k,418,msb}<1,-1|1,-3>(6,-6,A:48,1,-43m,(6,-8,1,-43m)5){A=0xc2ca80200020}

Would raw captures be helpful?

The differences seem insignificant, at least they do to me. Do you think my capturing hardware is to blame for this data, or do you have any other ideas? On one hand, these signals capture as identical despite only one working, but on the other hand, even the less accurate demodulating receiver is able to produce a working signal then paired with different software.
Thanks for sticking with me through all of this weirdness.
_________________
Just another newbie...

3FG · Expert Joined: 19 May 2009 Posts: 3367

Yes, I think raw data would be useful, although I'm not sure what you mean by it. Girr files? That's probably OK, but we're apparently looking for something pretty subtle, and Girr files are limited to integer numbers of the modulation period.

BTW, the Girr files you more recently posted of, I believe, the original remote do show a frequency of 37.7kHz or 26.54us based on the 006E frequency divider, but the duration of the lead in on off pairs are both shown as 005A. 90*26.54 is 2388us, but 6*418 is 2508us. So I suppose that the decoded IRP is already rounded to an integer value of the base timing interval. Put another way, I guess the actual timings are quite similar between the two remotes: 2360us versus 2388us for the lead in.

The JP1 remote should provide a frequency of 37.97kHz if the crystal is accurate, but you found 38.4 or 38.5kHz; that could show up as about a 1% difference in the total duration of the 48 bits. Hardly ever matters though.

Barf · Posted: Sat Jun 13, 2020 2:34 am Post subject:

rondnelson99 · Joined: 07 Jun 2020 Posts: 19

I think I figured it out! For some reason, IrScrutinizer always would see the remote's lead-in pulse as approx. +2350, -2350. Perhaps this is due to my capturing hardware, although it happened with the demodulating receiver as well. The other arduino sketch I tried saw +2350, -2000. This appears to be the key difference.

The following is a barebones raw send sketch I was using for testing: