I have a sony remote which i have been trying to decode using a program called sircs all which should decode all sony protocols, however this remote doesnt comply with any of there protocol formats.
The remote is from a DVD recorder(RDR-HXD970) and is for service purposes, the main remote that came with the unit is the standard protocol.

Is there a program out there that can utilise a serial port and a ir receiver to record the signal. Looked at the IR function in Remeote master and that uses the paralle port which i dont have on my laptop. Must be a simple interfaceas im away from home for a few weeks

LIRC uses a serial port IR receiver. It does not decode the results, but it does store them in a moderately human readable form.

If you post the info from an LIRC capture of those signals, I can tell you what the would be in other formats.

LIRC is primarily a Linux package, but there is a Windows version. I don't know exactly where you would find the software to use it with your serial receiver. But you should be able to find it starting from
http://www.lirc.org/

Edit: I found one of the Windows versions of LIRC at
http://winlirc.sourceforge.net/

I have used a program called RCExplorer from [Link: slydiman.narod.ru] to decode the signals and have concludedd from the program that the codes are in NEC format for example the the "0" key gave me address 22440 (0x57A8) and command 0 (0x00) see the below pic



Now it seems strange that Sony would use this coding but after some searching on the web it appears that this DVD recorder is actually made by Pioneer and so i guess that the service remote works with their commands whilst the actual remote for every day usage is their own codes.

What did you want to do with the results of that decode? Translate it to Pronto Hex? Use it in a OneForAll remote? Or what?

The Pioneer protocol is based on NEC protocol, but the modulation frequency is different. I expect your capture device ignores frequency. Maybe the DVD does as well, but you're probably better off regenerating the signals with the correct frequency.

If I remember correctly, the Pioneer service signals intentionally violate the NEC check byte rule, so you wouldn't find them if you generated the full set of 256 valid signals for that address.

Did you capture the service signals? You just mentioned the '0' signal and quoted a picture of the 8 signal.


Which "their" do you mean there?

I think you're saying you think the ordinary remote uses Sony signals and the service remote uses Pioneer signal. Seems unlikely. Did you actually capture any Sony signals from a remote that operates that device?

I captured all the codes from the service remote and the actual user remote. The user remote complies with the Sony Sircs schema and has the 3 different codes catagories.
I usually scan codes for devices i have just to create my own database which i use in my programmable ones after i converted them to the format they use.
I have a NX7000 and a AX4000 and have slowly been generating new device codes for Sony products as they seem to have given up on them. The only one i have had problems converting is the Foxtel remote which i think uses the pace codes ( Nokia32) and havent been able to learn a clean set of codes.

I was expecting the "Adr: 0x57A8" part of those decodes wouldn't mean anything to you, so you would want some help with translation. I didn't understand it myself until I compared it to the picture.

It means the same thing as "Device=168" in MakeHex. You would use that in the Pioneer.irp file to get Pronto Hex.

Most vendors would document that as "Custom Code A8" or "Custom Code A857", not as "57A8. NEC standard documents bits within each byte in the opposite sequence from that in which they are transmitted. But it does not document the Custom Code bytes in the opposite of transmit sequence. In that signal the A8 is sent first, followed by the 57, (followed by 08 then F7). That capture tool you found documents the A8, 57 in the opposite of transmit sequence.

I forget how Pioneer protocol is encoded for an AX4000. I'm pretty sure it was one of the ones I documented when I did a big post on AX4000 signal encoding a long time ago.