An example of that is my IRTrans LAN infrared transceiver which I’m using since 2009. The IRTrans needs a so-called irserver program, which is the gateway between your application and the IRTrans hardware. Some time ago I found out that I still have irserver running on my Windows server as a service instead of one of my Cubietrucks. And since I want to get rid of the Windows server (a VM running on Hyper-V) I had to find a way to move irserver to something Linux based – either a Raspberry Pi, Cubietruck or Odroid.
So I downloaded the Linux source code for irserver and tried to build it – no luck. Hmm, what’s wrong here. It didn’t take long to find out that I was missing a file: ccf.o. The only thing that worked was ‘make irserver_arm_noccf‘, but that didn’t sound very hopeful – no CCF? So I searched the IRTrans forum and found a post in which I read that there is a ccf.o available, although not suitable for all types of ARM processors (I assume). So I posted a question on the IRTrans forum, waited for about 7 weeks, but no (useful) response from the IRTrans support department. Strange …
Conclusion: CCF on ARM is a no-go. So I decided to create my own solution. Irserver without CCF meant I had to convert all my Philips Pronto CCF codes to hex. Luckily I found an easy way to do that with the IRTrans GUI Client:
By not selecting a command in the Command combobox shown above, all the CCF codes for the selected remote are converted to hex. OK, now we’re getting somewhere… I copied all the output to a text file and repeated this for all the remotes. Now I have a single file with all the remotes, commands and hex codes which looks like this:This file is very easy to parse by my Node.JS IRTrans driver, so with some additional changes in the code this should work.
In the CCF-enabled irserver situation I queried irserver with Agetremotes and Agetcommandlist to find out what commands were available (instead of defining those myself somewhere), but that method is useless with a CCF-disabled irserver in combination with CCF codes. So now that I have to work with a somewhat crippled irserver, I’m gonna use it as a simple hexcode transmitter.
And where I used to send commands to irserver with the Asnd command, I now have to use Asndhex.
My IRTrans now parses the new ‘hex code’ file, saves it in memory and sends the appropriate hex codes based on the commands it receives. So if some UI transmits “upc,yellow”, the driver sends a “Asndhex H3E01000000…” command to irserver instead of “Asnd upc,yellow”.
No changes needed in the User Interfaces, everything is still working as before and all the hex codes I tested do what they’re supposed to do – I haven’t tested them all yet, but the most important ones are working.
Another reason to keep my Windows server ‘up’ is gone – on to the next one!