347004 Virgin Media URC174001-00R00

[Knuckx]

I have got hold of a Virgin Media remote (this one) that is made by UEI which is not accessible by any of the JP1 tools I have tried. Raw download in RMIR either says "no remotes found" or "Unable to read the signature of the remote". JP2Sniffer High Level just times out constantly.

JP2Sniffer Low Level can read some form of signature from the remote: BeginComm then GetInfo then GetSigBlk places 6000 in the SigBlk Address box, and the processor type changes to MAXQ610.

Hex dump from JP2Sniffer Low Level as above:

Code: Select all

S: 00 02 51 53
R: 00 02 00 02
S: 00 02 50 52
R: 00 06 00 C1 06 60 00 A1
S: 00 06 01 60 00 00 2C 4B
R: 00 2E 00 15 B3 00 00 00 4C 33 34 37 30 30 34 FF FF FF FF FF FF FF FF 00 FF 00 FF 00 FF FF FF FF FF FF 00 FF 00 FF FF FF FF FF FF 00 80 00 04 BB 

BTW - Setup/Magic mode on these remotes is entered by holding TV and *.

[mathdon]

Do you have a better image of this remote than the one in your link? I would like to be able to see the names on the buttons. I now have a prototype version of RMIR that should support this remote, but to create an RDF for it I need a better image. If you can provide that, would you like to help further by testing the prototype?

[The Robman]

How about this (from this ebay listing)...

[Knuckx]

Do you have a better image of this remote than the one in your link? I would like to be able to see the names on the buttons. I now have a prototype version of RMIR that should support this remote, but to create an RDF for it I need a better image. If you can provide that, would you like to help further by testing the prototype?

I can provide a nice image suitable for imagemap use (I'll use a scanner), but that will be in 16 hours or so.
I have photos of the insides of the remote as well, but once again, that will be later.
I will happily test a prototype of RMIR. I assume you know about the email conversation I had with 3FG regarding this remote?

[The Robman]

Is the remote pic that I posted the same remote as yours?

[3FG]

Yes, mathdon and I have been corresponding about this remote and also the URC6820.

[mathdon]

Thank you all. Knuckx, please go ahead with the scanned image for an image map. If you know how to create the map file itself, do go ahead and do so, otherwise I will do it when I have your jpg file.

The map file isn't necessary for testing, so I have now posted RMIR v2.04 build 1 in the RMIR Development area of SourceForge. It is a full installation package, so unzip it into a new folder separate from that you use for v2.03. It includes the provisional RDF for the Virgin Media remote. When you download from the remote, you will get a message about the missing map file but it won't stop anything from working. Please give it a try and let us know how you get on.

[The Robman]

Are you guys saying that the remote pic that I posted is not clear enough? Because it seems a lot clearer than many of the pics that we do use.

[Knuckx]

Thank you all. Knuckx, please go ahead with the scanned image for an image map. If you know how to create the map file itself, do go ahead and do so, otherwise I will do it when I have your jpg file.

The map file isn't necessary for testing, so I have now posted RMIR v2.04 build 1 in the RMIR Development area of SourceForge. It is a full installation package, so unzip it into a new folder separate from that you use for v2.03. It includes the provisional RDF for the Virgin Media remote. When you download from the remote, you will get a message about the missing map file but it won't stop anything from working. Please give it a try and let us know how you get on.

So: here is a image/map.
It didn't scan as well as I had hoped, as the scanner doesn't like curved objects...

I have tested using the remote with RMIR, and first impressions are that is seems to work. I loaded a device upgrade and assigned keys; Every key seemed to work apart from the "*" key. However, with a custom device upgrade present on the STB device, I can't switch device to TV (regardless of if I have assigned a function to the TV button).

Thank you very much; I wonder how many other 'JP1.4N' remotes UEI make?

[mdavej]

Your map looks correct. "*" should work as long as you use the same button name in the RDF and that "*" isn't some sort of special character that's not allowed by RM. In that case, just give it a different name in the map and RDF like Star or Asterisk.

[mathdon]

However, with a custom device upgrade present on the STB device, I can't switch device to TV (regardless of if I have assigned a function to the TV button).

Can you switch device to TV after using RMIR to set one of the two built-in STB codes? It doesn't matter if you can't test whether the STB works, I just need to know if the TV works. If it doesn't, can you use the remote itself to create a setup in which the TV does work? If you can do this, please do a RAW download of the remote and post it for me to look at. It must be a raw download as I need to be sure that RMIR hasn't changed any bytes. I have an idea of what is wrong, but as I don't have one of these remotes myself, I'm afraid you will have to do the testing for me.

Edit: You could also test my idea as follows. Edit the RDF with a text editor and in the Buttons section, which at present is

Code: Select all

[DeviceButtons] 
STB   = $80 $80 $10 0
TV    = $81 $80 $10 0

change it to

Code: Select all

[DeviceButtons] 
STB   = $80 $80 $10 0
TV    = $81 $81 $10 0

and possibly even try

Code: Select all

[DeviceButtons] 
STB   = $80 $81 $10 0
TV    = $81 $81 $10 0

to see what effect that has.

[mathdon]

Here's some more info to help you test. In RMIR, drop down the Options menu and select Advanced. On the sub-menu that opens, check "Show Segment Editor". This will add a "Segments" tab to the RMIR display. If you open the Segments tab when you have a Virgin Media setup loaded, you will see that there are two segments with 00 in the "Type" column. The last 3 bytes of their data are all FF's. It is the 3 bytes before those FF's that we don't properly understand in JP1.4N and where your problem of not being able to select the TV device probably resides. We understand those bytes in JP1.4 but their use seems to have changed in JP1.4N. In JP1.4 they are punchthrough bytes and I keep that name here for lack of anything better.

As I said above, the [DeviceButtons] section of the RDF for your remote currently is

Code: Select all

[DeviceButtons] 
STB   = $80 $80 $10 0
TV    = $81 $80 $10 0

Here is what those values mean. On the right hand side, the first value ($ means that the value is hexadecimal) selects which of the type 00 segments the entry refers to. It corresponds to the first byte in the type 00 segment data. The punchthrough bytes of that segment are then set to the remaining three values on the right. If you do a download from the remote, RMIR will overwrite the downloaded values for these punchthrough bytes with those from the RDF, though of course those new values will not get into the remote until you do an upload. The values in the RDF are those in the data that you provided to 3FG.

We don't know what those values mean or what changes them in normal (i.e. non-RMIR) use of the remote. They may change when you set up a TV device. That is something I would like to know. You can experiment to see what changes them as follows. Delete their values from the RDF, leaving that section simply as

Code: Select all

[DeviceButtons] 
STB   = $80
TV    = $81

RMIR will then leave these bytes unchanged, so that when you do a download, the Segments tab will display whatever values the remote has set them to. My aim will be to get RMIR to mimic what the remote does with their values when devices are set. The present situation in RMIR is designed to keep these values from changing, to see if it has any adverse effects. It seems that it does, so the next step is to find what other values it writes to them and the conditions under which it does so. That, I'm afraid, is going to be up to you as the only user with one of these remotes. So please do experiment as I suggest and let us know what you find.

In case you don't realise it, you can edit the RDF from within RMIR. Pressing the toolbar button that looks like a sheet of paper with a magnifying glass will open a display of the RDF that you can edit and save to make to any changes you want to try.

[Knuckx]

I'm at work, so can't test right now, but that the 'punchthrough' bytes were wrong was my assumption. I read the new version of the RDF spec to try to figure out what was so different about these new remotes; and that coupled with the behavior I noticed in the segment editor (in preserve original mode) when setting up TV from the remote itself lead me to the assumption that RMIR was clobbering these new bytes.

When I set TV up from the remote itself, the first punchthrough byte on both devices was 0x81; without TV set up, it was 0x80 on both. I thought the byte might be a set of flags showing devices available, although that hypothesis is untestable without a JP1.4N remote that has 3 devices or more that can be set up independently from the remote itself.

[Knuckx]

Right, some testing later:

Magic equivalent is hold Star+TV.

As far as I can tell, 9xx codes don't work; it waits for a fourth digit, as if interpreting it as a device code.

As 9xx's don't work, I cannot attempt to test learning.

I have wiped the remote several times via Initialize to $00, as 981 doesn't work. The remote rebuilds its config to defaults immediately after communications end.

Macros don't work.

Keymoves, both function and key based, don't work.

Device upgrades, both STB and TV appear to work.

I haven't tried a protocol upgrade.

This remote does not have a TV mode. I was wrong when I assumed the TV was a mode. It is always in STB mode, with optional volume punchthrough to the TV device, and a couple of other keys that can send TV codes, see below.

The LED lights red when sending from the STB device and green when sending from the TV device. Text in the battery compartment states that orange flashing indicates a low battery.

The * key doesn't appear to work, even after I renamed it to Star in the RDF. It doesn't even do anything in the default STB code. It appears to be some sort of device select key! Pressing Star+Help or Star+Power sends the respective button from the selected TV device. If you did Star+Help the navigation keys (U/D/L/R/OK) send TV codes for a short period, or until you press OK (or any other non navigation key) once; then they revert to the STB codes.

The punchthrough bytes appear to be 'normal' for a JP1.4 remote:
I edited the RDF so that PunchThru=V and punchthrough select works correctly. This zeros the second punchthrough byte (normally 0x10), but otherwise appears to work, allowing me to enable and disable VPT from STB to TV.

Here is a pair of raw DL's, both configs entirely generated by the remote, with no RMIR involvement, one with no TV device (and no VPT), one with TV 0009 and VPT auto-enabled by the remote.

[mathdon]

Thanks, Knuckx. No time to digest this all now, as it is late, but here's a little more info. The only other known JP1.4N remote is the URC-6820Z Zapper+, which I do have. It too has no device selection and TV works through punchthrough, but Punchthru=V is wrong for that remote. That first punchthrough byte works differently in the Zapper+, in a way that I do not yet understand. The 2nd punchthrough byte may work the same way in both remotes - that is not yet clear - but it isn't the normal behaviour for a JP1.4 remote. The only valid values, if your remote was JP1.4, would be (hex) 80, 81 and 00 and the 2nd byte would control punchthrough for the transport buttons.