StanleyB wrote: I like their use of xml files to store the code data. I have part of the clipsal system at home, but I am not happy with the way you have to go about adding the code to the system, in order to control your equipment remotely. The code reader (5100RP) set me back U$800!
What does a code reader do? Learn signals from the original remote?
Take a look at CaputerIr if you want a good inexpensive way for a PC to learn signals from an original remote.
If their xml files are reasonable, that should mean you can edit new code sets into those files, without using whatever hardware/software they sell for doing that.
StanleyB wrote:I work in a place where all sorts of AV equipment pas sthrough for testing, repair etc. But we don't have access to every handset going,
You repair and/or test AV equipment without the associated remote?
StanleyB wrote: A PC program output via the irda port would be sooooo much quicker and accurate.
Do you know the raw hardware access details for doing that? (If you had the series of On and Off times, do you know how to make an irda port in Windows transmit that?)
Many years ago I did a little with programming irda chips to send and receive remote control codes. I found it needed chip specific information that the chip makers didn't want to give out. I also was unable to get that kind of access to the chip through the interference of the Windows OS. I assume a lot has changed in those many years. But I still haven't seen any clear description of how one might send remote control signals through an irda chip in Windows.
Unless you think all those aspects are easy, you might want to get some of that nailed down using a much smaller collection of device data before you focus on gathering the device data.
You seem to be overly focused on storing the device data. That seems to me to be a trivial detail as compared to gathering it and using it.
It sounds like your system needs to:
1) Start with a brand and model and generate a good guess at the code set. That would require a big hard to gather database to do right. The manual that comes with an OFA remote is a pretty rotten version of THAT database. Maybe you don't intend to do better.
2) Given a code set, look up the protocol, device number(s), subdevice number(s) and command numbers. That's the database inside an OFA remote that you want to copy. Depending on how well you want to test or control AV devices, the OFA database (even if copied) would be a serious problem because advanced functions are left out and other functions are questionably arranged to fit the labels of an OFA remote.
For fairly recent, fairly high end AV equipment, the code sets covered by CCF files at RC has much more than are in an OFA remote. OFA has much better coverage of cheap and/or obsolete AV devices. But why would you be repairing such?
3) Given protocol, device, subdevice and command, convert that to a time series of On and Off. That is the step where I suggested using IRP notation to describe the signals and software similar to MakeHex (free C++ source code available).
4) Given an On/Off time series, make the irda port send that. I have no clue. Hopefully you do.
5) Wrap it all in a UI.
That quite a bit and I don't think (2) is where you should be starting.
.
What's the big idea! 
I originated the use of the word "thingies" in this context. 
Your unauthorized usage of this term infringes on my intellectual property rights! 
)