URC-6440 small issues

[Jellby]

I'm trying to set up my URC-6440 properly and I've encountered a couple of issues.

1. For some reason the "extra" device selection key does not light up like the others when pressing a key or when selecting it to program a code or copy a key. Is this normal? Otherwise it seems to work alright.

2. I have two internet radios (different brands) whose remotes I'm not able to replicate. Raw codes extracted with irrecord and passed through IrScrutinizer look like standard NEC1 codes, like my other devices, but the URC-6440 does not capture any signal from them, and using the codes from irrecord has no effect on the devices. This is one example:

Code: Select all

begin remote

  name  IR-F4S.conf
  flags RAW_CODES|CONST_LENGTH
  eps            30
  aeps          100

  gap          107925

      begin raw_codes

          name standby
             9055    4429     635     497     578     529
              609     524     625     508     578     529
              609     525     624     508     577     530
              609    1657     577    1662     636    1604
              609    1657     578    1662     636    1603
              610    1656     578    1662     636     497
              578     529     609     524     636     497
              577     530     609     524     636     497
              577     530     611    1654     578    1662
              636    1604     609    1657     577    1663
              635    1604     609    1658     576    1663
              636

The only "strange" thing I could see is that the device code seems to be 0. Is this a problem? What else could I try to do?

Here are the device update files I have so far:

https://www.dropbox.com/s/ng3lq9jki5ov3 ... .rmdu?dl=0
for http://www.globalmarket.com/product-inf ... 06885.html

https://www.dropbox.com/s/i9rrm3cnkbm25 ... .rmdu?dl=0
for https://www.amazon.co.uk/IP-Diamond-Por ... B002AW53GC

The remotes actually seem to work on each other. For instance pressing "4" in the first remote toggles mute in the second device.

[Barf]

irrecord is a terrible program. Designed by Alfred Hitchkock?? You appear to have a /dev/lirc (device name /dev/lirc0 or something like that); you can have IrScrutinizer to read and write directly to that -- just select Sending hw -> /dev/lirc, select your device (typically /dev/lirc0); select Capturing hw, and then subpanel /dev/lirc. You can then caputure directly from /dev/lirc0. The only drawback is that Linux normally does not support measuring modulation frequency, built-in restriction in almost all /dev/lirc-drivers (but not a priori so...)

So, assuming that you have a working /dev/lirc (both sending and receiving), I would recommend that you capture with IrScrutinizer + /dev/lirc, and send (at least for testing) also using IrScrutinizer + /dev/lirc.

If that still does not work, describe in detail what you want to achieve, and what you are using.

Please upload your attachments to the diagnosis area in preference over dropbox etc.

[mdavej]

What is the "extra" device selection key?

Please post the make and model of the devices you want to control. Have you attempted to find codes for these devices from the SimpleSet site or some other source like Global Cache or Remotecentral?

[Jellby]

So, assuming that you have a working /dev/lirc (both sending and receiving)

I don't. I have only a receiver, no transmitter.

If that still does not work, describe in detail what you want to achieve, and what you are using.

What I want: Configure the URC 6440 to mimic this remotes. And understand why my attempts haven't worked so far.

What I used: irrecord in a Raspberry Pi with an IR diode like this. I first used irrecord in raw mode, as shown above, then with "irrecord -a" and with IrScrutinizer I got the device and subdevice codes and the OBC. I compared the headers from irrecord's output with those of other working remotes, there doesn't seem to be any significant difference (but maybe I don't know what to look for). I also tried using the copy function of the URC 6440 itself, but every button I tried just timed out and nothing was captured.

The Raspberry is running a lightweight linux distribution (Volumio), I don't think I can (easily) run IrScrutinizer on it. I can't even run it on my main computer, because apparently the Java version (5.2) is not supported, so I run it on a secondary computer which has a more updated distribution. I don't have any other computer-compatible IR receiver.

Please upload your attachments to the diagnosis area in preference over dropbox etc.

Sorry for that. I will upload them.

ETA: The relevant files are now in http://www.hifi-remote.com/forums/dload ... e_id=25225

What is the "extra" device selection key?

The URC 6440 has 4 device selection keys (buttons): TV, PVR, DVD and EXTRA (see https://www.oneforall.com/media/wysiwyg ... gn_400.jpg)

Please post the make and model of the devices you want to control. Have you attempted to find codes for these devices from the SimpleSet site or some other source like Global Cache or Remotecentral?

One is IR-F4S, the other is dnt IP Diamond 201314. It's difficult to find any kind of information online.

I had searched here, and Remote Central, and tried what SimpleSet had to offer, without much success.

I've now tried again all DNT codes in SimpleSet, and at least a couple of them make the IP Diamond react (nothing useful, though). The difference with the codes I extracted, apart form the OBCs, is that the device is 16 instead of 0 (subdevice is still 255). I changed that in my codes and suddenly it works.

But this didn't work with the IR-F4S. Strangely, this reacts to the "mute" button of the original IP Diamond remote (which corresponds to "4" here), but it doesn't to the button in the URC 6440 that works correctly as "mute" with the IP Diamond...

[Barf]

So, assuming that you have a working /dev/lirc (both sending and receiving)

I don't. I have only a receiver, no transmitter.

Then you cannot send . But you can still receive. (You have to open the device as "sending hw" however.)

The Raspberry is running a lightweight linux distribution (Volumio), I don't think I can (easily) run IrScrutinizer on it.

You just need to install Java 8 (JRE will do); should be easy with apt-get or such. (I think you should have the "hard floating point" version.) Then you can run RMIR too.

[Jellby]

Well, I've done some more experiments and I think I've solved it.

The crappy unbranded internet radio didn't respond to codes sent with 0,255 (device,subdevice) combination, but it does to 0,blank. I guess the difference between 20 or 00 in the first byte of the fixed data is important.

The IP Diamond, however, seems to respond to, at least, both 0,blank and 16,255. Unless I did a mistake, it didn't respond to 0,255 though.

The fact that each device can see the other's remote could mean that both are sending 0,blank signals. Maybe the URC 6440 ignores these when using the copy function? Can anyone try?

Still, the extra key doesn't light up. Unless this is normal behaviour I guess it's broken. Probably not enough to send it back, since otherwise it appears to work normally.

[mdavej]

Glad you got it sorted out.

The EXTRA button is labeled AUDIO on my US version of this remote. That's why I didn't recognize it.

Yes, it is normal for it not to light until there is some function assigned to the particular button you press when that device is active and not in activity mode. If you were to assign an audio device to EXTRA and set the volume lock to EXTRA in an activity, the button should light when using the vol buttons.

Your remote isn't ignoring the variable subdevice code, but your device likely is.

I've always found the operation of this remote very complex. If I don't use it regularly, I quickly forget how it works.

[Jellby]

Yes, it is normal for it not to light until there is some function assigned to the particular button you press when that device is active and not in activity mode. If you were to assign an audio device to EXTRA and set the volume lock to EXTRA in an activity, the button should light when using the vol buttons.

The thing is I do have a device assigned to the EXTRA button. And I guess the button should also light up when selecting it for a setup code or for the copy function. The other 3 buttons do, the EXTRA button doesn't.

[yaworski]

It should light up. Mine does (European URC-6440, with EXTRA button label :)). So it seems it is damaged in some way. It's hard to get access to the LEDs on the PCB: first of all this remote requires a lot of patience when disassembling it and the keyboard side is covered with a layer containing light diffusal material and tactile domes for the buttons. I don't remember how the device LEDs are placed.

[The Robman]

Well, I've done some more experiments and I think I've solved it.

The crappy unbranded internet radio didn't respond to codes sent with 0,255 (device,subdevice) combination, but it does to 0,blank. I guess the difference between 20 or 00 in the first byte of the fixed data is important.

The IP Diamond, however, seems to respond to, at least, both 0,blank and 16,255. Unless I did a mistake, it didn't respond to 0,255 though.

The fact that each device can see the other's remote could mean that both are sending 0,blank signals. Maybe the URC 6440 ignores these when using the copy function? Can anyone try?

When the first byte is 0x00, it tells the remote to just look at the first device code, and complement it (ie, subtract it from 255) to get the sub-device code. When it is 0x20 it tells the remote to use both supplied device codes. So, 0,blank should result in a signal with a sub-device code of 255, so I am curious why one works and the other does not.

[Jellby]

When the first byte is 0x00, it tells the remote...

Maybe it tells the remote, and the remote will correctly send 0xFF and 0x00 for the 2nd and 3rd bytes, but one of the devices will ignore anything that does not start with 0x00FF00? This would at least match the observation.

[yaworski]

I've just checked this myself on URC6440. I've created two device upgrades, both using NEC1 with OBC 0 to 9 on digit keys. Both set to device 0 and the only difference between them being the subdevice, like in Jellby's case (one with 255, second with empty field).

I've captured the signals in IrScrutinizer and compared then. There's no difference at all in the signals between both devices.

[The Robman]

When the first byte is 0x00, it tells the remote...

Maybe it tells the remote, and the remote will correctly send 0xFF and 0x00 for the 2nd and 3rd bytes, but one of the devices will ignore anything that does not start with 0x00FF00? This would at least match the observation.

Ok, so here's some background on how a JP1 remote works. There are 2 portions to a device upgrade, there's the regular portion which feeds in some fixed data and some button codes, then there's the protocol executor, which is written in assembler and which sends the actual signal.

What I was trying to say above, is that the executor has 2 modes, one where it sends 2 individual device codes (ie, the hex 20 mode) and one where it sends one device code followed by its complement. But either way, the signal produced would be exactly the same, so the device would not know the difference.

[Jellby]

OK, then the only explanation is that I made some mistake when I tried the 0,255 version.