JP1 Remotes

1. Device: Delta Air Cleaner #50-875
2. Type of device: Shop Air Cleaner
3. Year: 2004 (no longer available)
4. JP1/UEI Remote model: URC-8810
5. Do you have a JP1 cable? Yes Tommy JP1, JP1.2/3
6. Still have original remote? Yes but Failed
7. Checked the file section? Yes
8. Checked Pronto file section (at R/C)? Yes
9. Partially working setup code? No
10. Learning remote question? Learned Codes Work but Convert to Device Upgrade failed
11. Have you tried the JP1 Lookup Tool? Yes, but no help
12. If you have a OARUSB04G, URC-6440 (or similar) remote, have you tried simpleset.com? NA

Link to IR File:
https://www.hifi-remote.com/forums/dload ... e_id=26458

The Delta IR Remote for the Air Cleaner has just 3 Buttons, Time, Start/Stop, Speed. which saves getting out a footstool to operate it (as it hangs on the ceiling in the shop). Before the Remote hard failed, I capture the three functions on L1-L4; (start/stop) is captured twice. These learned signals work, but the original Delta Remote does not. Tried "Convert to Device Upgrade" in RMIR 2.13 but that failed.
Looking for help in transforming these Learned signals into this Device Upgrade, since the Delta Remote is no longer available and other folks may be interested a more workable solution.

10. Learning remote question? Learned Codes Work but Convert to Device Upgrade failed
11. Have you tried the JP1 Lookup Tool? Yes, but no help
12. If you have a OARUSB04G, URC-6440 (or similar) remote, have you tried simpleset.com? NA

I'd recommend you upload your your RMIR file for analysis.

Did post the .IR file for analysis at the Link to IR file in my post.
Could open the .IR file & re-save it as RMIR if that would help you.

But at this point I no longer can create a fresh RMIR file, as the original remote is inop.

Load your .ir file into RMIR latest release, which is v2.13.2. Go to the Learned Signals tab, select the four signals and press the Convert to Device Upgrade button. Note that this only creates functions from the learned signals. You then have to go to the Devices tab and edit the upgrade it has created, to assign the functions to buttons on your remote.

It is as simple as that. It works, I have just tried it.

Already did exactly what you suggested (see original post).
However that new "Convert to Device" upgrade did not work. (By that I mean it did provide an upgrade, but the new upgrade failed to control the Delta Air Cleaner.)

Prior to posting, read about "Convert to Device Upgrade" it was described as a simple algorithm that didn't always provide a successful upgrade. However, if you found your self in that situation, you should post your downloaded file and experts could explore the learned code and manually create a new upgrade that could be downloaded and verified. ("This is where the experts really earn their stripes, as we'll try to decode the signals and create an upgrade to replicate them."... The Robman)

When you said "It is as simple as that, It works and I just tried it."
Can I ask if you had an Air Cleaner to verify that the resulting upgrade works? If so, please send that Upgrade.

hgetz wrote:Prior to posting, read about "Convert to Device Upgrade" it was described as a simple algorithm that didn't always provide a successful upgrade.

Then you read something long out of date that refers to the original implementation. The current implementation of "Convert to Device Upgrade" is very thorough, far from simple, and based on Barf's IrpTransmogrifier that is incorporated into RMIR. I am not aware of any learned signals for which the version in RMIR v2.13.2 creates an upgrade but the upgrade does not correspond to the learned signals. If that is the case with yours then I will investigate further.

Do you want an upgrade simply because the remote on which the signals were learned no longer works? If so, are you aware that you can copy learned signals from one remote to any other that supports learning? You have to do it one signal at a time, but there are only three signals so that should not be a problem. Select a signal, click on Edit and copy the Pronto hex that is displayed. Then on the new remote, click New and paste the copied text, set the device and key you want the signal on and click OK.

To your point, perhaps I did read an older thread. All I can say for certain is the Learned Signals work; the Convert to Device - Upgrade does not.

I have many legacy remotes (hopefully can find one that is simple and supports learning) which I can copy the signal via Pronto Hex as you describe. (Prefer not to tie this solution to a single remote that has more than 50 buttons. Yes, that remote does still work, sort of)

My quote about the "experts really earn their stripes" was taken from section 10 of the Announcement at the top of the Code Search Forum "Read Before Posting..."
https://www.hifi-remote.com/forums/viewtopic.php?t=49
So perhaps you can understand my incorrect expectations.

hgetz wrote:These learned signals work, but the original Delta Remote does not. Tried "Convert to Device Upgrade" in RMIR 2.13 but that failed. ... All I can say for certain is the Learned Signals work; the Convert to Device - Upgrade does not.

I took your remark that the conversion to device upgrade failed to mean that it did not create a device upgrade. When I said I have done the conversion and it worked, I meant that it did create a device upgrade. I have no way of testing whether or not it would actually operate your Air Cleaner.

What the conversion does is create a device upgrade that sends the same signals as the decodes shown on the Learned Signals tab. In your case these use the F12 protocol and the conversion did as intended. However, the decodes also say "Non-standard repeats". This comment is produced by the IrpTransmogrifier decode process and suggests that the signals are not exactly F12 ones but the conversion does not take that into account. Perhaps in such a situation the conversion should fail rather than create an upgrade that may not work. I don't know what in IrpTransmogrifier triggers this "Non-standard repeats" message. I will consult with Barf, its creator, to try to work out what it is best to do in such circumstances. In your case I suspect that the RMIR protocol database, protocols.ini, does not have a protocol that will accurately recreate your learned signals so copying the learns may be the best option.

Edit: I have just seen a remark in the document "Interpreting Decoded IR Signals", available on the RMIR Help menu, that suggests protocol with PID=016D sends similar signals to F12 that at first glance may actually be what is needed for your Air Cleaner. I will investigate further and see if I can make an upgrade for you to try. If it works then I will also try to incorporate it into RMIR and the learned to upgrade conversion for the benefit of other users in future.

@hgetz

I have created this upgrade at great speed as I haven't got much more time today, so it may not even do what I intended. But I would be grateful if you could give it a try. It does not exactly reproduce the learned signals, but it is closer to them than the F12 upgrade. It uses PID=016D as I mentioned above, which is an official UEI protocol.

First of all: there are three (#3 and #4 are identical) signals, and they are not extremely long, so keeping them as "learned signals" is probably a good pragmatic solution.

The F12 protocol (for IrpTransmogrifier) is defined as i.e., it is one sequence that is sent twice, with a "long" pause in the middle. Unfortunately, it is a limitation that the decoder has a problem with the long middle pause. If only one sequence is identified, this is output as "F12_relaxed".

However, the decodes also say "Non-standard repeats". This comment is produced by the IrpTransmogrifier decode process and suggests that the signals are not exactly F12 ones but the conversion does not take that into account.

If a signal decodes as F12_relaxed (which is the case here), this is delivered to RMIR as "F12" with the comment "Non-standard repeat". This is governed by IrpProtocols.xml entries, in XPath notation /irp:protocols/irp:protocol[@name='F12_relaxed']/irp:parameter[@name='uei-executor']/rm:deployment/rm:protocolName and /irp:protocols/irp:protocol[@name='F12_relaxed']/irp:parameter[@name='uei-executor']/rm:deployment/rm:commentItem. (Almost surely written by Graham...) Should this transformation not be desirable, can the corresponding element irp:parameter[@name='uei-executor'] be changed or removed.

The learned signals decode as
#1: F12_relaxed D=3, S=1, F=17 (as repeat)
#2: F12_relaxed D=3, S=1, F=65 (as repeat)
#3: This is an intro-only:
so it i two F12_relaxed, then the same again with the highest bit of F inverted.


My personal gut-feeling is that something goes wrong when generating the parametrization for the executor.

Posibly we should consider using another parametrization?

Mathdon & Barf,

The test upgrade mathdon supplied did work. Verified on the Delta Air Cleaner with both a URC-8810 and a ReplayTV 5000 remote. Updated the RMDU file with the actual functions that correspond to the EFCs.

It is posted here: https://www.hifi-remote.com/forums/dload ... e_id=26460

Not sure how to move/include in Device Upgrades of working Upgrades (Fans or Misc.), can you do that or should I?

Big thanks mathdon & Barf

Many thanks, Hal, for confirming that my test upgrade worked. As a result I have now posted development build RMIR v2.13.8 in the RMIR Development folder on SourceForge. This includes full support for the protocol with PID=016D, now re-named F12x, which previously had only a minimal entry. So if you download this build and again convert your learned signals to a device upgrade, you will see that they are identified as F12x signals and the converted upgrade is the one you tested, which works. I have edited the .rmdu file you posted to change the protocol name to F12x, as the old name of pid: 01 6D is not recognised by the revised RMIR/RMDU, so the file will now load into v2.13.8 and all subsequent ones.

Bengt, my apologies over the "Non-standard repeat" comment. I had looked in IrpProtocols.html rather than IrpProtocols.xml, where the uei-executor entry for F12_relaxed is blank, so thought that signals identified as F12_relaxed were not converted. Now I see where the comment comes from, I see no reason to make any change. I have, however, used rmProtocols.xml to add an entry for the F12x protocol (see above paragraph). To prevent Hal's signals getting multiple decodes of F12_relaxed and F12x, I have also used rmProtocols.xml to change the minimum lead-out for F12_relaxed from 6000 to 15000. I could have got away with a somewhat smaller value, but since 15000 is still less than half the lead-out of F12 itself, I saw no harm in this new value. I hope you are content for me to make these additions. I have a related question, though. Is there any way for me to create, for RMIR, an updated version of IrpProtocols.html that includes the additions and changes made by rmProtocols.xml?

Is there any way for me to create, for RMIR, an updated version of IrpProtocols.html that includes the additions and changes made by rmProtocols.xml?

First you generate the merged XML file with the command line command like This generates an XML file merged.xml. Then the XSLT transformation IrpProtocols2html.xsl is used to generate the HTML version. For this you can use any XSLT (version 1.0) transformation engine, like xsltproc. Unfortunately, although Windows comes with an XSLT engine in msxml.dll, there is easy way to call it from outside of a program. (I think it could be done in 10-20 lines of VB...) So instead there is an command line XLT engine in IrpTransmogrifier, class (surprise!) XmlTransmogrifier. So you can achieve the desired result by e.g.

I have also used rmProtocols.xml to change the minimum lead-out for F12_relaxed from 6000 to 15000.

Isn't <prefer-over> enough?

Having said that, I am not at all happy with the current stand. I think a good F12 protocols should be something like In particular, a protocol should be logical object, and not a emulation of the Toshiba chip (TO9148P). There is no need to model restrictions like "only one bit can be one". If the protocol allows a proper superset of the signals actually generated by the chip, fine. (The other way around would be a problem...)

Barf wrote:Isn't <prefer-over> enough?

Apparently not, though I don't know why. You will see that there is a prefer-over in my entry but without the lead-out change it makes one of the three signals decode as F12_relaxed, one as F12x and the third as both.

Having said that, I am not at all happy with the current stand. I think a good F12 protocols should be something like ...

The IRP is a true representation of the PID=016D executor which is UEI code, not ours. I don't know what you mean about emulating a Toshiba chip. UEI has 016D executors for three processors, all very different from one another. I want an entry that will identify signals that can be generated by this executor, so have followed the executor rather than some nicety about what a "good F12" signal should be. It is clearly similar to F12, so I called it F12x. I could call it something completely different, but it seems a bit silly to do so when it is so similar to F12.

@Barf

Many thanks for the instructions on how to create a merged IrpProtocols.html for inclusion in RMIR. It works beautifully.