JP1 Remotes

Need help from an expert on this one:

I am using a pretty straightforward RMDU for a Toshiba LCD TV;
NEC1, Device 64, Subdevice 191.
see file here :
http://www.hifi-remote.com/forums/dload ... e_id=26727

everything works as expected when uploaded to my URC-9910, including discrete ON/OFF.

But for some weird reason, when using the exact same signals (converted to Pronto Hex) with my Broadlink transmitter, all codes work except Discrete On... Also worth mentioning : The standard power toggle signal works to turn off the TV but won't turn it back on.

However, if I capture the working discrete ON signal with IRScope and convert it to Pronto Hex, it works. (same NEC1, Device 64 detected, but subdevice not identified - pronto hex uploaded in the same link above).

Could someone compare both signals (also below) and pinpoint where the difference is so I can hopefully correct the protocol parameters accordingly?
Maybe the subdevice but it would be weird that it only affects Discrete ON?
I did test with subdevice 0/empty but no luck either.

Any help appreciated,

Discrete ON Pronto Hex from RMDU
NEC1, Device 64, Subdevice 191 EFC 006, OBC 126, Hex 81
(works with URC-9910 but not Broadlink Transmitter)

0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

Discrete ON Pronto Hex export from IRScope-URC-9910 learn
NEC1, Device 64, Subdevice?, EFC 006, OBC 126, Hex 81
(works with Broadlink Transmitter)

0000 006C 0022 0002 0158 00AB 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0609 0157 0057 0015 0E68

* For NEC*, no subdevice/subdevice missing/not identified means the subdevice is the default, namely 255-device (which is also called the one complement).
* Please consider using IrScrutinizer instead of IrScope. It is the better program.
* The quirks with the Broadlink sender should probably be considered a Broadlink transmitter problem. Can you describe in some more detail what you are using, both hardware and software? I have looked a bit into the Broadlink-python package (and to a lesser extent the Broadlink-Java package). I even have contributed to the first one, and have a pull request pending (as bengtmartensson on GitHub). It may very well be that you are exposing quirks in it.
* Try with different number of repeats. You can also try with NEC2 instead of NEC1.
* The last two signals decode to the same signal, NEC1: {D=64,F=126}. The only differences are the computational errors (probably by MakeHex; it computes the same duration as both "0015" and "0016", sigh), but these are well within the error tolerances of a sane receiver.

To repeat what Barf said, your signal is NEC1 dev 64 with no sub-device. Calling 191 the sub-device is misleading because 64+191=255. When NEC signals don't have a sub-device, the sub-device spot in the signal is the complement of the device code, that was the original format before sub-devices were introduced.

Thanks for the feedback;

I generally use IRScrutinizer; was just testing with multiple options.

Using Broadlink RM4 mini and RM4C mini.
Software component is via Homeseer/Broadlink plugin (based on some existing python script)
Signals are uploaded in Pronto Hex form and converted to Broadlink by the plugin.
Also did a number of tests vs this conversion script :
jdoodle.com/ia/FtY
and results are similar so I doubt this is a conversion issue.


My conclusions:

100% of RMDUs tested work as expected when uploaded to my URC-9910.

10 out of 15 RMDU tested also work as expected once transferred to the RM4

4 out of 15 required either repeat or pulse adjustments (available via the plugin and working well; signal failure rate goes from 30-60% to 0-1%, generally adding an extra repeat or adjusting pulse -1 or -2)

2 out of 15 have very specific issues related to the "ON" command (very high signal failure rate just for this specific signal, all others work as expected) This is obviously when the device is OFF - so maybe this has to do with how the electronics are powered once in "idle" mode vs full power ?

The only work around is to learn raw from the remote and convert to Pronto Hex OR learn the signal dirfectly on the RM4.
Both of these return a 100% reliable signal.

However my intent was to completely exclude the need to use the physical remotes in the process, so while all works now I am still interested to understand why a clearly identified signal/protocol is not recognized unless learned via the remote.

Again For reference and always for the same command:

Original Discrete ON Pronto Hex from RMDU
NEC1, Device 64, EFC 006, OBC 126, Hex 81
(works with URC-9910 but not Broadlink Transmitter)

0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

Discrete ON Pronto Hex export from raw learn (IRSCOPE)
NEC1, Device 64, EFC 006, OBC 126, Hex 81
(works with Broadlink Transmitter)

0000 006C 0022 0002 0158 00AB 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0609 0157 0057 0015 0E68


other working one done with raw learn - IRScrutinizer (Broadlink format - repeat=1 pulse=-2)

260050000001259212121212121212121212121212391212123912391239
123912391239121212391212123912391239123912391239121212391212
121212121212121212121239120005240001253912000C460D0500000000
0000


Discrete ON learned straight from the Broadlink RM4 (Broadlink format)
NEC1, Device 64, Subdevice?, EFC 006, OBC 126, Hex 81
(works with Broadlink Transmitter)

2600600000011C9110141014101410140F14101410380F14103810380F38
10380F38103810140F3810141037103810380F3810381037101410380F14
10141014101410140F1410381000050A00011D4A0F000C0800011C4A0F00
0C0700011D4A10000D050000000000000000

Also tested NEC2 unsuccesfully.

Let me know what you think

ylaviolette wrote:Original Discrete ON Pronto Hex from RMDU
NEC1, Device 64, Subdevice 191 EFC 006, OBC 126, Hex 81
(works with URC-9910 but not Broadlink Transmitter)

0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

Discrete ON Pronto Hex export from raw learn (IRSCOPE)
NEC1, Device 64, Subdevice?, EFC 006, OBC 126, Hex 81
(works with Broadlink Transmitter)

0000 006C 0022 0002 0158 00AB 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0609 0157 0057 0015 0E68

These are both exactly the same signal, there's only a minute difference in some of the timings, differences that won't make a difference to a device, as you've found. So, if one of them works with your Broadlink and the other doesn't, that's really a question for Broadlink. Are there any support forums for it?

Thanks,

From experience, this will be too "technically challenging" to hope for any decent answer from tech support, much less resolution.

I wrongly thought that known protocols/codes (all working on the URC-9910) would a sure bet to avoid relying on the original remotes and/or using further "fine tuning" (repeats/pulse/timing, etc)

But as you pointed out, it's probably related to the Broadlink hardware itself and not a big deal since most work OK and I have some decent workarounds for the remaining issues.

Just weird as there is a clear "pattern" in what doesn't work (only signals waking up the device from OFF mode, IE: Discrete ON or Power toggle) what's even weirder is that the same signal (power toggle) will work 100% to turn off the device and not at all to turn it back on

Anyways I guess I'll just put this in the "twilight zone" category...

Thanks again

ylaviolette wrote:Just weird as there is a clear "pattern" in what doesn't work (only signals waking up the device from OFF mode, IE: Discrete ON or Power toggle) what's even weirder is that the same signal (power toggle) will work 100% to turn off the device and not at all to turn it back on

Ok, it may be the TV is in some sort of standby and does not wake up quicky enough. For this, you may experiment with increasing the first on-duration. That is the 5th number in the Pronto Hex, 015B or 0158 in the examples. Or add some other "junk" in front of the real signal...

Thanks @barf

would the theory be compatible with the fact that the unretouched signal works with the URC-9910? could be some slight difference in the hardware processing speed maybe?

will give it a shot for sure.

If I understand correctly I could try these, right?

0000 006C 0022 0002 03E7 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

Or

0000 0000 0000 0000 0000 0000 0000 0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

Versus the original:

0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

ylaviolette wrote:0000 0000 0000 0000 0000 0000 0000 0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

This one absolutely won't work at all, that's not how you edit Pronto hex.

@ylaviolette:
#1. Right, that is what I mean.
#2. No, that is not a valid Pronto Hex. What I meant was something like
0000 006C 0023 0002 0100 0100 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

The "scrutinize signal" pane on IrScrutinizer is good for trying these things out. If you have connected hardware, you can even send the signal directly with a keypreess.

Thank you, no success with these but will simply use the learned code as this is the only code (out of hundreds) not working correctly.
Thanks for all the insight and support.
Cheers,

Are you just trying to test concepts here, or do you need working Pronto hex for your application?

Assuming it's the latter case, I have created a file of Pronto hex for dev 64 using Makehex, and then customized the results to match the working hex code that you posted. You can match the hex code by comparing the function code from the file with the OBC in your upgrade.

http://www.hifi-remote.com/forums/dload ... e_id=26729

Thanks Rob, I do need working Pronto Hex but this problem is limited to a single code, while all other codes work perfectly (Rmdu to Girr to Pronto Hex to Broadlink). Will still keep this file handy just in case I encounter other issues with this device.
Thanks again! much appreciated.