Having tested the prototype software with my own domestic remotes, I needed to set up and test the device with the Foxtel remote control. IRLib was not recognising the protocol as one of the ‘standard’ types it has built in, so I needed to do some research. This turned out to be the real learning experience on this project.
There are very few technical details on the internet about the Foxtel remote control. I also discovered that the Foxtel remote physically looks a lot like the Sky+ remote control, so that gave me a few more clues.
According to irdb, the Foxtel protocol is Nokia32 protocol with device 33 subdevice 160, and I assume the ’32’ means 32 bits. Nokia protocol is also known as Philips RC-MM.
Researching the RC-MM protocol got me to SB-Projects, which defines the RC-MM protocol as having the following characteristics:
- 12 bits or 24 bits per message.
- Pulse position coding, sending 2 bits per IR pulse.
- Carrier frequency of 36 kHz.
- Each message is preceded by a header pulse with the duration of 416.7 µs (15 pulses of the carrier), followed by a space of 277.8 µs (10 periods of the carrier).
- This header is followed by 12 or 24 bits of data. (No 32 bits?)
|0 0||166.7 µs (6 cycles)||277.8 µs (10 cycles)|
|0 1||166.7 µs (6 cycles)||444.4 µs (16 cycles)|
|1 0||166.7 µs (6 cycles)||611.1 µs (22 cycles)|
|1 1||166.7 µs (6 cycles)||777.8 µs (28 cycles)|
Also, at the Silicon Junction Blog, the Foxtel protocol parameters measured empirically are
- Carrier frequency of 36 kHz
- PWM Duty Cycle 33%
- Encoding Space4
- 32 data bits
- Header Pulse of 417 µs followed by a space of 333 µs
|0 0||167 µs||333 µs|
|0 1||166 µs||500 µs|
|1 0||166 µs||667 µs|
|1 1||166 µs||833 µs|
So this is slightly different from the protocol specification, but the gist is the same – except for the 32 bit part…
(36k,msb} <164,-276|164,-445|i64,-614|164,-783> (412,-276,D:8,S:8,X:8,F:8,164^100m)+
Again, this definition somewhat matches the other two, but we also now have an encoding for the message (Device is 8 bits, followed by Subdevice 8 bits, X(?) 8 bits and Function 8 bits). Given the data from irdb (D = 33 and S = 160) the message should start with (in hex) 21A0xxff. In fact, these are the exact codes that Silicon Junction showed at the start of their messages.
At this point I have a definition of what the protocol should be. However the timing data I am measuring from the Foxtel remote, using the Arduino and RTLib, did not support this. I needed to be able to analyse the signals being received in more detail.
During the course of all this research I had come across mention of AnalysIR software a number of times. So I visited their web site, decided that the tool was worth trying and invested a very modest amount of money and buy their tool to analyse my IR signals.
Immediately I could see that the trace I was recording was not as I would have expected from all the information I had collected. Timing parameters and the entire look of the trace did not fit. So clearly what I was looking at
- Was not RC-MM, although the spaces did follow about the right timing to encode 2 bits in the same way.
- The header was consistently 1500 µs and the following space is always around 450 µs.
- The IRP notation also implied a stop bit 164 µs long and this can be seen in most traces.
- The marks also seem to encode two bits, similar to the space, so this may have been pulse distance coding?
- The number of transitions in various recorded message varied between 15 (30 bits) and 16 (32 bits). This made no sense to me.
- Manually decoding the start of the message using simple timing multiples gives (in hex) 411Dxxxx which differs from the expected device 160 sub 33.
At the same time I received an email from the AnalysIR guys asking me what I was doing with the software – a standard email that I would not have normally paid much attention to.
Instead, I described what I was doing and, over the course of a few days, Chris from AnalysIR was exceptionally helpful in helping to analyse what was happening. Coincidentally, it turns out that some time ago they also did something similar.
Initially he suggested that my receiver circuit may be the problem. When I described how it was configured, he suggested that it might still be the problem. Importantly they had a ‘recording’ of the codes from a Foxtel remote that I was able to compare to my traces (figure below). Clearly the shape and length are similar but the detail is missing.
Chris suggested (again) that the receiver may be the problem, so I went to my local Jaycar and bought a TSOP4136 receiver and just plugged it in, ‘naked’, to the power, ground and Arduino I/O, replacing my standard IR receiving module in the prototype.
This new receiver is tuned to 36 kHz. As Chris had ‘hinted’, the receiver was the problem, even though it seemed to work perfectly well with the other remotes I had in the house (which were probably 38 kHz). I immediately saw traces that were recognisable and matched the known Foxtel codes. IRLib was also able to decode the messages.
The guys at AnalysIR have a great product and were exceptionally helpful, well above and beyond the call of duty considering the small amount they charge for their software. They deserve all our support.
So, with the Foxtel issue solved, time to move on to building the device for real.