JP1 Remotes

Hello everyone. Thanks for a great community. I'm just getting started with JP1 (got my first remote and cable about 5 hours ago). I was hoping to get some help with this protocol. It seems like a very simple protocol but I can't seem to get a working upgrade out of it.

Here's what I've done so far... I learned the signals from the OEM remote and verified that I could correctly operate the fan with the learns. I then downloaded the remote into RMIR and discovered the learns were an unknown protocol (boo). So I decided to take a stab at making the protocol myself.

Here are the timings for the three signals (that's all the buttons on the remote...it's a fan after all): Following documentation found around here, I first rounded them to the nearest 25: There doesn't seem to be a Lead In so I moved on to look for the Zero and the One...I made the following determinations: It seems like we have a dev-cmd protocol and this particular device is 00011000 (24). The Lead Out seems weird and only 3 bits for OBCs did as well but then I realized the final off is a combination of both. Working with this assumption, I assumed those final On times were actually part of a final bit. When I subtracted the Off time from my Zero and One, I was left with a consistent Lead Out of -6675. That makes sense so I have this: (Note: I know that the One is the one with the bigger Off time, but having them this way seemed to make the binary make more sense...this gives me OBCs 1, 2, and 8 instead of 14, 13, and 7 which seemed more logical.)

So I went to Protocol Builder and punched in all the stuff:


Here's the Protocol Code: Copy and paste that into RMIR...make a new device upgrade:


Aaaaaaaaaaaand...nothing. =( It doesn't work. I tried a lot of simple variations (e.g. complement yes/no). I also setup all OBCs from 1 to 15 and none of them had any impact on the fan whatsoever. =(

Unfortunately, I have no way to check the signals being sent by my upgrade. I (foolishly) did not order a second remote (to learn from the first with the upgrade) so I have no real way to diagnose/debug at this point. Anyone have any thoughts on this?

In addition to the information above, I've uploaded an IR image of the learns: https://www.hifi-remote.com/forums/dload ... e_id=11230
I've also uploaded an RMIR image with my attempted protocol/device upgrade that does not work (which also contains the learns): https://www.hifi-remote.com/forums/dload ... e_id=11231

Thanks in advance for any assistance.
Vyro

Some of your post isn't self-consistent, in particular the decodes, and how you've defined zero and one. But the learns are a slight variant of the F12 IR protocol. The unusual aspect is the very short leadout times (8 mSec or so). Both IR and RMIR don't handle these short leadouts well, so I imported your learns into IRScope, and set the repeat value to 1. This allowed a suitable decode. Power is F12 Device 3.1 and OBC 129. The IRP for F12 is: Your learned Power signal is: This splits into 110, 1, 10000001. F12 is considered to be lsb, so 110 turns into 011, or 3.
It isn't necessary to think of your learns as F12, and for the most part your executor is OK. However, you've decoded this Power signal as 00011000 0001 (000,1,10000001). For some reason the first two bits have been incorrectly decoded as 00 instead of 11. So in your RMIR file change the device number from 24 (0x18) to 216 (0xD8). I tried 216 and it does give a decode which matches your learns.

Also, you've set the repeat to minimum with Hold = No, which means that the resulting signal is only sent once. I suspect that the fan may prefer more repeats (your learns are repeated), so it may be necessary to set Hold= Yes.

3FG wrote:Some of your post isn't self-consistent, in particular the decodes, and how you've defined zero and one.
...
However, you've decoded this Power signal as 00011000 0001 (000,1,10000001). For some reason the first two bits have been incorrectly decoded as 00 instead of 11.

Sigh... I'm such an idiot. I had originally been looking at the timings and was thinking I had some kind of lead in (since the raw timings of those first two 1s were slightly different), but later I realized it was not a lead in and I did a find-replace and typed wrong damn number. So from there on I was doomed to failure.

3FG wrote:So in your RMIR file change the device number from 24 (0x18) to 216 (0xD8). I tried 216 and it does give a decode which matches your learns.

Agreed...with device 216 it works perfectly. If I had just not made the stupid mistake with those first two bits I actually would have gotten working fine.

3FG wrote:But the learns are a slight variant of the F12 IR protocol. This allowed a suitable decode. Power is F12 Device 3.1 and OBC 129.

With another device upgrade using protocol F12 device 3, I could not make it respond to anything. I tried the OBC 129 you gave and also the others. *shrug* I guess the slight variant is variant enough, and the protocol upgrade works now that I have the correct device number. =p

3FG wrote:Also, you've set the repeat to minimum with Hold = No, which means that the resulting signal is only sent once. I suspect that the fan may prefer more repeats (your learns are repeated), so it may be necessary to set Hold= Yes.

How do you know the learns are repeated? As an aside, it works fine with Hold = No. It's actually better than the OEM remote (much more responsive).


Thanks a ton 3FG for pointing out my silly mistake. It's much appreciated.

How do we know it is repeated? If an IR signal is sent just once, there is no way for the learning device to assign the lead out time-- it is effectively infinite. So the mere fact that your learns had a short lead out time tells us that the original signal did repeat. If the learned lead out time is quite large (>100mS, say) then we may assume that the learning device assigned an arbitrary lead out, but that is surely not the case with an 8 mSec lead out.

Also, while I strongly recommend RMIR in preference to IR for most JP1 tasks, IR does offer different information about learned signals. IR reports that the signals were sent repeatedly.

3FG wrote:How do we know it is repeated? If an IR signal is sent just once, there is no way for the learning device to assign the lead out time-- it is effectively infinite. So the mere fact that your learns had a short lead out time tells us that the original signal did repeat. If the learned lead out time is quite large (>100mS, say) then we may assume that the learning device assigned an arbitrary lead out, but that is surely not the case with an 8 mSec lead out.

Aw...makes perfect sense.

3FG wrote:Also, while I strongly recommend RMIR in preference to IR for most JP1 tasks, IR does offer different information about learned signals. IR reports that the signals were sent repeatedly.

I was looking at in both but I guess I just overlooked that part. Thanks again for your help.

Vyrolan wrote:Hello everyone. Thanks for a great community. I'm just getting started with JP1 (got my first remote and cable about 5 hours ago). I was hoping to get some help with this protocol. It seems like a very simple protocol but I can't seem to get a working upgrade out of it.

WOW, it took me forever to figure out how to write protocols. Its nice to know we have someone else interested in this level of detail!

You did use a very odd combination of tools. Did you know that RM and RMIR have protocol building built in? The current versions are not real friendly to protocol experimentation though, however there is a new version that is in the pipeline that clears up a lot of the problems with "protocol experimentation".



As mentioned before IR give much better information when using unknown protocols. IR is also much easier to use with PB in an experimental stage. You can just keep replacing the code until you get it right.

Unfortunately, I have no way to check the signals being sent by my upgrade. I (foolishly) did not order a second remote (to learn from the first with the upgrade) so I have no real way to diagnose/debug at this point. Anyone have any thoughts on this?

Actually you want a widget. A widget can capture signals that a remote can't. A widget is more convenient than head to head learns too.

Keep up the good work! [/quote]

Wow, from rookie to expert in 5 minutes, I think that's a record! Welcome

vickyg2003 wrote: WOW, it took me forever to figure out how to write protocols. Its nice to know we have someone else interested in this level of detail!

The Robman wrote:Wow, from rookie to expert in 5 minutes, I think that's a record! Welcome

Well you guys have a lot of good material to learn from throughout the site. =p But also I'm a computer nerd for life. =)

vickyg2003 wrote: You did use a very odd combination of tools. Did you know that RM and RMIR have protocol building built in? The current versions are not real friendly to protocol experimentation though, however there is a new version that is in the pipeline that clears up a lot of the problems with "protocol experimentation".

As mentioned before IR give much better information when using unknown protocols. IR is also much easier to use with PB in an experimental stage. You can just keep replacing the code until you get it right.

Yes I've tried to use the latest tools but a lot of the documentation refers to old tools so sometimes I went for the familiarity. I did not know about RMIR being able to do it, but I did figure that out when adding my protocol to it (since it was pretty clear all the same inputs were available there as in PB).

vickyg2003 wrote: Actually you want a widget. A widget can capture signals that a remote can't. A widget is more convenient than head to head learns too.

True. I may get one. But even just a second remote would have been sufficient here. I would have put the timings from the second learn next to the original and seen the error pretty obviously. Oh well.

The Robman wrote:Wow, from rookie to expert in 5 minutes, I think that's a record! Welcome

Off-topic, but fellow Chicagoan here. =)

Vyrolan wrote:

vickyg2003 wrote: Actually you want a widget. A widget can capture signals that a remote can't. A widget is more convenient than head to head learns too.

True. I may get one. But even just a second remote would have been sufficient here. I would have put the timings from the second learn next to the original and seen the error pretty obviously. Oh well.

Well the nice thing about using a second remote, is it IS a second remote. These remotes are really very nice and when you get it setup the way you want you'll probably want a backup, or perhaps another remote for a different location. Its just the learning procedure is a PITA with all the button pushing ;connecting and disconnecting cables; thinking sideways and such. The Widget really streamlines the process, just click the "Capture" button and start shooting codes adding notes as you go. No worry about bad learns. No having to remember where you put the function. For most of my remotes, I don't even have to disconnect the remote from the cable, I just keep uploading and trying the codes until I get it right.

vickyg2003 wrote:Well the nice thing about using a second remote, is it IS a second remote. These remotes are really very nice and when you get it setup the way you want you'll probably want a backup, or perhaps another remote for a different location.

For sure, I'm going to get more for every room in the house as I'm finishing off the purchase and installation of a full home theater system that has lots of IR forwarding between the various rooms. I was originally planning on Harmony remotes but then discovered JP1!

I just need to confirm with my wife which remotes are acceptable. Fortunately she's quite tech savvy and reasonable (unlike your husband, sorry vicky), so I'm sure it's not a problem but I'm still wise enough to check anyway. =)

vickyg2003 wrote:The Widget really streamlines the process, just click the "Capture" button and start shooting codes adding notes as you go. No worry about bad learns. No having to remember where you put the function.

Yea, the limited learning capacity is annoying for sure. You convinced me; I sent Tommy an email requesting to order one of the Widgets. I figure it's better to proactively prevent frustration. =)

Vyrolan wrote:I just need to confirm with my wife which remotes are acceptable. Fortunately she's quite tech savvy and reasonable (unlike your husband, sorry vicky), so I'm sure it's not a problem but I'm still wise enough to check anyway. =)

lol. Sounds like a wonderful gal.