JP1 Remotes

mdavej wrote:I had one like that. Got a refund.

This joker wants me to pay to ship the two defects back to him in China. Least this guy could do it pop 3 AAs in the things before he sends them.

-N

The Robman wrote:did it work before or did it come like this?

if it used to work, can you recall what the last thing you did to it was, before this happened?

Showed up like that. :/

-N

Anyone experienced this?

The remote will update and be programmed thru the UEI website without issue, but the screen never deviates from full-on white pixels...

It too the firmware update from the site, but no change in behavior.

Unit is brand new (supposedly)

-N

Bumpitty-bump.

Anyone able to guess why the Nevo does that the 6540 does not?

-N

... another find -- nearly any command issued on the Nevo from that Samsung device will trigger the RC-5 command -- in fact it may be receiving several different RC-5 variants... but only the Nevo does it... 6540 behaves. I don't recall this ever happening with my 15-1994, either... so that points ...

It is not that odd really.

Also my experience tells me that RC5 signals are comparatively likely to false hits. It is a very simple protocol, consisting of only 900ms and 1800ms durations, around 10 pairs, with no redundancy.

I once had a Plasma globe lobotomizing a Maranz AV receiver (using RC5 ...

Odd, indeed.


...and it gets more interesting. That "fix" didn't work... It just so happens that my Samsung panel and CCTV NVR both use EFC 001/OBC 153 for a command...

The Samsung uses it for Discrete On, and the NVR the "right arrow" - so whenever I turn on the TV, the camera view changes. I ...

I am breaking in a Nevo and as part of the configuration in my Den, I have a series of Activities that launch various things. One is a "Watch CCTV Cameras" Activity which does the following:

Turns on my Display (NECx2 commands)
Selects HDMI1 as the input on the same display
Selects the appropriate ...

... there isn't an "IMPORT ANYMOTE" function.
While I am pretty happy about the procedure for adding export formats (just add to the text file exportformats.xml), the same is not true for the import formats.

However, it would be a rather simple exercise to write a little stand-alone proggie for ...

Try this testversion to see if it solves the problem. If "Raw" or "Pronto Hex" is selected, and the signal cannot be rendered, it still does all the other stuff, including the parameters.

(Overwrite existing IrScrutinizer.jar (or IrScrutinizer-jar-with-dependencies.jar) with this file.)
Is this ...

Ok, it is clear now. Thank you. Sorry I did not get it earlier. What happens is that if "Raw" or "Pronto Hex" is selected on the export/Girr pane, AND the signal is not renderable (like an unknown protocol) the exporter gives up completely. This is not a very good situation, and something I will ...

Am I correct in presuming if you have a LKP Macro on a device button that the inherent SHIFT-DEV2, XSHIFT-DEV3 functionality to select a device is broken? (at least on DEV3, since perhaps you can shift-cloak the first two DEVs...)
If this is so, I am not aware of it. Please post a .rmir file that ...

Looking back, I see that the S3C80 protocol repeats every signal at least three times. I forgot to put that into the MAXQ version. Try changing the code line to

Code.MAXQ610=32 64 01 0A 6F 00 27 00 24 00 70 00 37 07 00 00 63 10 01 03 70
which has these repeats.

Boom! This appears to work as ...

As for the PID, there is already an official UEI protocol with PID=0160 that is not Roomba, so that cannot be used in protocols.ini. I chose a value higher than any known PID, but 02 60 would be equally suitable. Note that many remotes will not accept PIDs greater than 01FF, but the MAXQ remotes do ...

Graham,


Am I correct in presuming if you have a LKP Macro on a device button that the inherent SHIFT-DEV2, XSHIFT-DEV3 functionality to select a device is broken? (at least on DEV3, since perhaps you can shift-cloak the first two DEVs...)

I have something on STB3, but LKPs on the device buttons ...