JP1 Remotes

Posted: **Thu Jun 11, 2020 11:57 am**

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.

Posted: **Thu Jun 11, 2020 12:10 pm**

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.

Posted: **Thu Jun 11, 2020 1:20 pm**

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?

Posted: **Thu Jun 11, 2020 11:14 pm**

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:

Code: Select all

[Teac-K Checksum]
PID=01 60
DevParms=Main Device:4=0,Sub Device:8=4,OEM Code1:8=67,OEM Code2:8=83
DeviceTranslator=Translator(lsb,comp,0,4,20) Translator(lsb,comp,1,8,24) \
                 Translator(lsb,comp,2,8,0) Translator(lsb,comp,3,8,8)
FixedData=3D 35 7F DF
CmdParms=OBC:8=0
CmdTranslator=Translator(lsb,comp,0,8,0)
DefaultCmd=ff
Notes=This executor correctly computes the checksum (the second byte of the command data)
Code.S3C80=43 8B 41 8B 14 8F 44 08 08 00 C5 00 D3 00 C5 02 39 53 CB 06 60 03 AF 06 71 F6 FF 30 20 11 F6 01 46 E6 28 80 E6 29 45 E4 22 20 E4 23 21 8D 01 49 3C 04 B0 C4 B0 C6 87 04 03 F6 FF 63 58 C0 F0 C5 02 50 02 65 4E 3A EF 56 C6 0F 08 07 F6 FF 63 58 C0 F0 C5 56 C0 0F 56 C5 0F 02 06 02 05 F6 FF 63 09 08 AF 60 C0 2C 08 C0 C0 10 C1 2A FA 08 C1 AF
Code.HCS08=20 17 22 47 41 8F 44 08 08 00 C1 00 E7 00 C1 02 4D 53 DF 06 5F 03 C3 06 85 AD 12 3C AA CD FF 5F 6E 80 A2 6E 45 A3 55 7A 35 78 CC FF 5C 3F 56 8C AE 03 E6 60 AD 2A B7 51 62 BB 51 BB 56 B7 56 5A 2A F0 B6 56 A4 0F B7 56 B6 64 AD 14 B7 51 62 A4 0F B7 55 B6 51 A4 0F BB 55 BB 56 AD 03 B7 65 81 43 6E 08 52 46 39 51 3B 52 FA B6 51 81
Code.MAXQ610=33 69 41 14 0F 00 12 00 0F 00 2D 00 5F 06 7C 00 49 00 00 00 7C 00 7F 00 00 80 B4 00 D7 D0 00 59 7C 00 00 00 D5 D6 00 51 D6 D6 00 03 D5 D5 D6 00 D7 D1 00 59 68 00 00 03 D5 D5 D6 51 D6 D6 00 03 D5 D5 D6 00 D7 D2 00 59 54 00 00 03 D5 D5 D6 51 D6 D6 00 03 D5 D5 D6 00 D7 D3 00 59 40 00 00 03 D5 D5 D6 51 D6 D6 00 03 D5 D5 D6 16 D5 D5 0F 00 D7 D4 00 59 28 00 00 00 D9 D6 00 51 D6 D6 00 16 D9 D9 0F 16 D6 D6 0F 03 D5 D5 D9 03 D5 D5 D6 00 D7 D5 00 59 08 00 00 57 38 00 00 17 D7 D7 FF 10 D8 00 07 10 D6 00 00 15 D6 D6 80 55 08 D7 80 16 D6 D6 7F 11 D7 D7 01 12 D6 D6 01 58 EC D8 00 15 D6 D6 80 55 08 D7 80 16 D6 D6 7F 5D 00 00 00 42 44 26 70 71 72 73 74 76 C6 51 01 00 00 00 80 09 04 10 D9 00 01 
Code.TI2541=01 07 01 21 41 14 0F 00 12 00 0F 00 2D 00 5F 06 7C 00 49 00 00 00 7C 00 7F 00 00 80 B4 00 09 02 00 59 7C 00 00 00 07 08 00 51 08 08 00 03 07 07 08 00 09 03 00 59 68 00 00 03 07 07 08 51 08 08 00 03 07 07 08 00 09 04 00 59 54 00 00 03 07 07 08 51 08 08 00 03 07 07 08 00 09 05 00 59 40 00 00 03 07 07 08 51 08 08 00 03 07 07 08 16 07 07 0F 00 09 06 00 59 28 00 00 00 0B 08 00 51 08 08 00 16 0B 0B 0F 16 08 08 0F 03 07 07 0B 03 07 07 08 00 09 07 00 59 08 00 00 57 38 00 00 17 09 09 FF 10 0A 00 07 10 08 00 00 15 08 08 80 55 08 09 80 16 08 08 7F 11 09 09 01 12 08 08 01 58 EC 0A 00 15 08 08 80 55 08 09 80 16 08 08 7F 5D 00 00 00 42 44 26 70 71 72 73 74 76 C6 51 01 00 00 00 80 09 04 10 0B 00 01

Make sure to assign the buttons. I only assigned the digits, arrows, and a few others.

Graham and Bengt,
I no longer can access SourceForge to check in files. I think the above entry should probably be renamed to something better and added to the distribution of protocols.ini. I checked that it operates with MAXQ and S3F80 processors, and machine translated into TI2541. The HCS08 amd MAXQ code was already in protocols.ini under pid: 01 60. This is a long executor, but has the advantage that it calculates the checksum, which 00BB does not do.

Regarding the Girr translation, I note that the 00BB executor entry lists 1 as the default device even though the default fixed data corresponds to device 0. Maybe the translation picks up the default.

Posted: **Fri Jun 12, 2020 1:43 am**

rondnelson99 wrote: I was unable to control my Samsung receiver with your girr file.

Possibly it is not Teac-K after all?

I was also unable to re-transmit captured signals from the original remote.

This is bad! Unless you find something that works (like 3FG's file), I would here suggest that you get a non-demodulating receiver, TSM58000 or equivalent (a photo diode or -transistor is NOT equivalent!) and recapture the codes.

Was that to be expected since the demodulating receiver puts everything into 38khz?

Only if the (unknown) carriere frequency is very different from 38000.

3FG wrote: I've uploaded a tested upgrade which shoots the Teac-K protocol.

Great! But the link is wrong.

I no longer can access SourceForge to check in files

You (as well as I) are listed as "Project Members", while Graham, Greg, and Chris are "administrators". One of these three might be able to help.

Posted: **Fri Jun 12, 2020 10:21 am**

I edited the link to the upgrade.

Posted: **Fri Jun 12, 2020 11:59 am**

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.

a photo diode or -transistor is NOT equivalent!

I was just thinking yesterday that I would probably need a better capture device, and looking through my stuff I found an LTR-301 phototransistor. I hooked it up between 5v and the input and pulled the input down with a 220 ohm resistor. It worked SO much better than the demodulating receiver (besides only having a fraction of the range). I edited my upload (the second one) and entirely replaced the captures with ones from the phototransistor.

I'm willing to buy a new sensor, but first I just want to know what it would let me do that the phototransistor can't already. I don't see how the timings could get any more accurate. Are there some really short pulses that the phototransistor won't pick up at all? Again, I'm ok with buying a new sensor, it's just kind of a pain to get them shipped in canada.

Posted: **Fri Jun 12, 2020 2:08 pm**

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.

Posted: **Fri Jun 12, 2020 3:47 pm**

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.

Posted: **Fri Jun 12, 2020 4:19 pm**

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.
https://www.hifi-remote.com/forums/dload ... e_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.

Posted: **Fri Jun 12, 2020 9:15 pm**

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.

Posted: **Fri Jun 12, 2020 10:13 pm**

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.

Posted: **Sat Jun 13, 2020 12:29 am**

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.

Posted: **Sat Jun 13, 2020 1:34 am**

rondnelson99 wrote: - 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.

Now that is interesting! Please post all details (sending only), sketch etc.

I assume that you have tried the usual stuff: different distances, block possibly disturbing light (temporarily turning off the sun

), different number of repeats (Sending hw -> Count). Possibly you can look into the device and identify the receiver -- post photos if you cannot identify it yourself.

I found an LTR-301 phototransistor. I hooked it up between 5v and the input and pulled the input down with a 220 ohm resistor. It worked SO much better than the demodulating receiver (besides only having a fraction of the range)

OK, if it works, fine. When I tried with a photo diode it had extremel short range (millimeters), with a photo transistor slightly longer (centimeters). But, according to data sheets, the rise time is 10micros, fall time 15micros. Consider a 40kHz carrier with a duty dycle of 40%: the on-period is then 10micros...

But if it works, it works, and I am not going to tell you that the bumble bee cannot fly

I just made a quick experiment, and my Arduino with TSMP58000 works at 2 meters (= 6 feet).

3FG wrote:Girr files are limited to integer numbers of the modulation period.

The Pronto format (as well as the GlobalCache sendir format) have this limitation. IrScrutinizer/Girr also supports raw format (in microseconds), just click the raw checkbox on the export pane. @rondnelson99: It would be a good idea to do so.

Posted: **Sat Jun 13, 2020 3:02 pm**

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:

Code: Select all

#include <IRremote.h>

IRsend irsend;

void setup()
{

  unsigned int irSignal[] ={2350, 2000, 300, 1300, 300, 1300, 250, 550, 300, 550, 300, 550, 300, 550, 300, 1250, 300, 550, 300, 1300, 250, 1300, 300, 550, 300, 550, 300, 1250, 300, 550, 300, 1300, 250, 550, 300, 1300, 300, 550, 300, 550, 250, 550, 300, 550, 300, 550, 300, 550, 300, 550, 250, 550, 300, 550, 300, 1300, 250, 600, 250, 550, 300, 550, 300, 550, 300, 550, 300, 550, 250, 550, 300, 550, 300, 550, 300, 1300, 250, 550, 300, 550, 300, 550, 300, 1250, 300, 550, 300, 1300, 300, 550, 250, 550, 300, 550, 300, 550, 300, 550, 300
  //unsigned int irSignal[] = {2366, 2366, 419, 1184, 419, 1184, 419, 419, 419, 419, 419, 419, 419, 419, 419, 1184, 419, 419, 419, 1184, 419, 1184, 419, 419, 419, 419, 419, 1184, 419, 419, 419, 1184, 419, 419, 419, 1184, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 1184, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 1184, 419, 419, 419, 419, 419, 419, 419, 1184, 419, 419, 419, 1184, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 419, 43025};
  int khz = 38; 
  irsend.sendRaw(irSignal, sizeof(irSignal) / sizeof(irSignal[0]), khz); 


}

void loop() {
}

This is the sketch I was using before to record and playback signals using the arduino: https://github.com/z3t0/Arduino-IRremot ... record.ino

In my code above, the first definition of IrSignal is copy/pasted from the serial output of the IrRecord demo. It creates a working signal. The second, commented-out version is copy-pasted from Irscrutinizer, using options > output text format > raw (without signs). When uncommented, it doesn't work, but it will if the second 2366 is changed to 2000. Likewise, If I manually change the 2366 to 2000 in the Scrutinize Signal tab, It works when pressing the transmit button.

BTW, the button code in both definitions is "mute". I doubt that's really relevant but I'll mention it anyway.

I also tried a lead-in pulse of (2000, 2000), and that worked too.

JP1 Remotes

How to import samsung36 code from irscrutinizer?