JP1 Remotes

There have been UEI remotes with RF (Radio Frequency) as well as IR capability for a long time, but this used to be through a dedicated RF module that was invisible as far as JP1 was concerned. I have recently become aware that newer UEI remotes with RF capability use RF4CE (RF for Consumer Electronics), a standard developed by the ZigBee Alliance. These are remotes in which the E2 (EEPROM) data area has a segment structure and the RF4CE configuration data is held in this area in segments of previously unseen type.

I am indebted to Chris (ckeays) for providing me with a URC2125BC0 from Rogers Telecom in Canada. This is the first, and so far the only, UEI remote of which I am aware that has both RF support and a JP1 connector, which in this case is the external 5-hole connector rather than the more common 6-pin one in the battery compartment. If anyone knows of other remotes with both RF support and JP1 access, I would be very grateful. There are, however, other UEI remotes that use RF4CE but do not have a JP1 connector. Since Chris provided me with the URC2125BC0, our UK cable company Virgin Media has updated my cable box and this comes with a UEI remote with RF support that I now know to be RF4CE.

RF4CE signals can be read with a suitable packet sniffer. One such packet sniffer is the CC2531EMK from Texas Instruments, though I obtained mine from the UK supplier Farnell at this link. They can be found much more cheaply from Chinese sources by doing a web search, but with long delivery times. I have a Chinese one on order too, but expected delivery is not till April. The TI description mentions it can be used as an IEEE 802.15.4 packet sniffer or for other purposes and it speaks of programming it, but it comes configured as a packet sniffer so no programming is required. It is used together with the TI Packet Sniffer software - NOT Packet Sniffer 2, which is at the same link but which does not support the CC2531EMK dongle. It is unclear which Windows versions the Packet Sniffer software will run on. At that link it says Windows 98 through Windows 7 (32 and 64 bit) but the User's Manual in the download package says Windows XP through Windows 8, despite being dated June 2014 which is the same date as that on the TI site. I have played safe and use it with 32-bit Windows XP in an Oracle VirtualBox, but I suppose it is possible it may run on Windows 10 and this is not mentioned as the documentation precedes the issue of Windows 10.

The sniffer captures the RF signals from the remote, and also from the cable box if used during a pairing exchange, and analyzes them according to the RF4CE standard. Unfortunately that does not allow you to see what data the remote is sending to the cable box when you press a key, as the data is encrypted. The encryption algorithm uses data exchanged between the remote and cable box during pairing, and as the sniffer software treats each signal separately it does not have the data needed for decryption. For this reason I am developing RF Tools as a new feature that will appear in RMIR v2.10. This is intended to be an RF equivalent of IRScope for IR signals. The sniffer can save a sniffing session as a .psd (Packet Sniffer Data) file and RF Tools can read this file. You first register the RF Remote with RF Tools, after which it will decrypt the signals from the remote. Registration can be performed in two ways. If the remote has JP1 access and is already paired with a cable box (or other device) then you download it to RMIR and select a new menu item Register as RF Remote. That makes a provisional registration which is completed by loading a .psd file that captures a pairing request from the remote. This method does not require the presence of the paired device as it does not use the response from that device. For remotes without JP1 access you need to capture the pairing exchange between the remote and device. Loading this as a .psd file completes the registration in a single step. I will include sample files in the RMIR v2.10 distribution so that those without such a remote or packet sniffer can see what it can do.

What the .psd file contains is the raw data received by the sniffer, in the form of the MPDU (MAC-layer protocol data unit) of each signal. The MAC layer of RF4CE conforms to IEEE 802.15.4, which is a standard for wireless Personal Area Networks (PANs) and is distinct from the IEEE 802.11 standards for wireless Local Area Networks (LANs). In RF4CE, each device (cable box, and so on) runs its own PAN and a remote joins that PAN when it pairs with the device. RF Tools performs the RF4CE analysis and decryption of the MPDU, so it could easily be extended to any other packet snffer from which the MPDU can be extracted. The IEEE 802.15.4 MAC layer is also used by the main ZigBee standard which is designed for the Internet of Things, so I am sure there are other sniffers around that will capture these packets in raw form even if they do not support RF4CE itself. I would be very interested to hear of any that users may be aware of.

This is just to report that my Chinese-supplied CC2531EMK packet sniffer has arrived, works perfectly and is about one-tenth of the price from Texas Instruments, or from Farnell in the UK. A development version of RMIR v2.10 including RF Tools is also close to being ready.

Do you have a link for the cheap packet sniffer?

The Robman wrote:Do you have a link for the cheap packet sniffer?

Here is the UK Ebay link I got it from:

https://www.ebay.co.uk/itm/CC-Debugger- ... 3651022167

You should be able to find a US Ebay link to the same supplier, but I only get UK Ebay when I search. It is the CC2531 Sniffer Module on that site, for £3.29 GBP. The full-price one I got from Farnell, the UK distributor, was £42.25 GBP and the price from TI is $49 USD.

If it's just the sniffer module alone that you need, this listing should work for US folks (and probably UK folks too). It's $3.62 USD shipped, which is about £2.77 GBP
https://www.ebay.com/itm/183516647829

Just to confirm that it is just the sniffer module you need, as at Rob's link. The other thing you need is the TI Packet Sniffer software, which is a free download at the link I gave in the first post of this thread.

Here is one at Amazon:
https://www.amazon.com/HiLetgo-Wireless ... B07X52QKK6

Looks to be the same thing - "instant gratification" (well,at least Prime shipping) for $7.99.

I have now posted RMIR v2.10 build 1 in the RMIR Development Folder on SourceForge. This includes support for remotes with RF capability through the ZigBee RF4CE protocol, which is believed to be all recent UEI remotes with RF support, whether or not they have a JP1 connector. The new RF Tools feature will import and analyze Packet Sniffer Data files with a .psd extension that are saved by the TI (Texas Instruments) Packet Sniffer software used with the TI CC2531EMK Packet Sniffer dongle, as described earlier in this thread.

The package includes a new folder, RFToolsTest, of files for demonstrating the RF support without any need to have either such a remote or the sniffer dongle. The files concern two remotes that both have RF capability, a Canadian Rogers Telecom URC2125BC0 that does have a JP1 connector (the external 5-hole type rather than the 6-pin connector in the battery compartment) and a UK Virgin Media URC655552 that does not. Both remotes are paired with cable boxes. Since the Rogers remote has a JP1 connector, the remote on its own provides all that is needed to read and decrypt its RF signals. The Virgin Media remote, however, needs the Packet Sniffer capture of a pairing with the cable box, capturing the signals from both the remote and the cable box, to provide RMIR with the information needed to decrypt its RF signals. Examples of all required files are included in the RFToolsTest folder.

Here is a suggested series of steps to illustrate the new capabilities.

1. Start RMIR and open RogersTest.rmir from the RFToolsTest subfolder of the RMIR installation folder. New columns in the Device Buttons table show that the Cable device has an RF pairing and uses the ZRC (ZigBee Remote Control) profile. Select the Cable device to see the new RF Selectors panel be populated, showing the combinations of IR and RF setup codes that are supported and explaining how they are selected.

2. On the Remote menu, click on the item Register as RF Remote. A dialog box asks you to enter a name, so enter Rogers and press OK. A message tells you that it has been provisionally registered. Press OK then move and resize as you wish the RF Tools window that has opened. You will see that the IEEE Address of the remote is unknown. This is a value embedded in the TI CC2530 chip in the remote, separately from both the firmware and the setup data E2 area and which cannot be read by RMIR. It is needed to complete the registration, and is obtained from a Pairing Request signal sent by the remote. Actually this is a Discovery Request, but documentation about the remote speaks of pairing rather than discovery. It doesn't matter that we do not have the cable box that will answer the request, as the remaining information has been read from the E2 area of the remote. So use the Open button of RF Tools (or the File > Open menu) and open the file RogersTestDiscovery.psd in the RFToolsTest folder. You will get a message that the registration has been completed, giving the IEEE Address. Select the Packets tab of RF Tools to see the Discovery Request commands, sent twice. Select either, then select the NSDU Details tab to show the information sent in that packet.

3. Go back to the Packets tab, then press the Open button and load the RogersTestData.psd file. You will see a whole selection of RF signals, sent secured (that is, encrypted and authenticated) and displayed in decrypted form. These are from pressing the button sequence:

Power, Yellow, Blue, Red, Green, Ch+, Ch-, 1, 2, 3.

You will see each signal is two bytes. The first is the action, 1 = key pressed, 2 = key held, 3 = key released. These were short keypresses so there are no key held signals. The second byte is the actual key signal. Go back to the main RMIR panel and select the Devices tab. Select Cable/4677 which is the CableRF setup code and press Edit. Go to the Functions tab. You will see that the RF key signal is the third byte of the 3-byte hex value for the function. The significance of the first two bytes, which are the same for all functions, is unknown. Back in RF Tools you can select any data signal and go to NSDU Details to see the encrypted value that was actually sent, together with the 4-byte message integrity field which provides authentication that the decrypt is valid and has come from the purported sender.

4. The new RF Vendor Data tab on the Device Upgrade Editor panel shows the Vendor ID, Vendor String and User String that is a new part of a device upgrade for an RF signal. For this upgrade these are trivial, zeroes or spaces, but if you close the editor, select instead Cable/3989 and reopen the editor, you will see real values.

5. This ends the tour of the Rogers remote, so go back to the Packets tab on RF Tools and clear the display with the button at the bottom of the panel. Now open the VMTestPairing.psd file. This creates a complete pairing entry, so enter a name, say Virgin Media, in the dialog and press OK. You will see the entire signal exchange that creates the pairing. The discovery request and response are followed by the pairing request and response. You can view the details of any signal, but perhaps the pairing response is the most interesting as this is the cable box telling about itself. The NSDU Addressing tab gives, as well as addressing information, the number of the RF channel that it will use.

6. The encryption security key is 16 bytes. It is chosen at random by the cable box and sent to the remote in obfuscated form in a series of 80-byte Key Seed signals. The remote specified how many Key Seeds to use in its pairing request. Once these have arrived, the remote sends an encrypted ping using this new security key, to confirm that it is correct. The data in the ping is random, and even the fact that the command is a ping is encrypted. The cable box responds by sending the same random data back in a ping response. You will see that this was followed by a VDATA (Vendor-specific data) signal. I have no idea what this does.

7. Now open the VMTestData.psd file. This contains signals from the following button sequence:

Power, Home, TV, Red, Green, Yellow, Blue, Clear, PrevChannel.

You will see that this remote only sends key pressed signals, but for keys in common between the two remotes, it uses the same signal values.

This ends the tour. As you can see, there has been a great deal of change made to RMIR to incorporate this. I have tried to take care not to create bugs in features that previously worked, but I may well not have succeeded. So please try this build with things that are not to do with RF, and report anything that no longer works correctly.

mathdon wrote:... URC2125BC0 from Rogers Telecom in Canada. This is the first, and so far the only, UEI remote of which I am aware that has both RF support and a JP1 connector
...
If anyone knows of other remotes with both RF support and JP1 access, I would be very grateful.

Just for the record, the URC-8350 is also an IR+RF combo with JP1 port (and it's on the market for some years already). I don't know anything about its hardware, I haven't opened it yet. I'm using RMIR with the IR part only, but it would be nice to have control over the RF part also...

TiceRex wrote:Just for the record, the URC-8350 is also an IR+RF combo with JP1 port (and it's on the market for some years already).

Unless there is a new version of the URC-8350, the one currently supported by RMIR has an HCS08 processor. It is of the sort characterised in the first post of this thread by

There have been UEI remotes with RF (Radio Frequency) as well as IR capability for a long time, but this used to be through a dedicated RF module that was invisible as far as JP1 was concerned.

Unfortunately there is no way that RMIR can interact with the RF capability of these remotes.

Sorry, I missed that point.

Anyway, I will take this remote apart just to see how its RF part is wired. Maybe there's a way to amend it on hardware level (not within RMIR, of course).