I'm doing work with one of my professors on an automated antenna test platform. We imagine our setup will work as such:
- WiFi router with antenna will be mounted to a general purpose antenna rotator.
- Computer with wifi card will run labview program/etc, map signal strength while rotating antenna.
Unfortunately the antenna rotator we got our hands on has a design out of the 1940's, the rotor base with antenna attachment and the control box have identical motors inside them. Moving the dial on the control box causes both motors to run until a relay is tripped in the control box. The assumption is that identical models of motors will run at the same speed, so dial position on the control box will accurately reflect the positioning of the rotor base. This is of course not how it works in practice, the error between the two builds up quickly and the control box has a feature to resync them (by rotating full left, followed by full right, not a smart device, just mechanical relays).
It turns out that all antenna rotators work like this, in order to remain backwards compatible. Even the newer control box we got our hands on (a Channel Master 9537A Antenna Rotor with an IR remote) was still just an open-loop DC motor driver. It'll have to do.
My current plan is to replace the control box's IR interface with a serial one. The first step is to reverse-engineer the remote control's protocol. This of course started with a google search to see if anyone had already done it. Success! I think. Here's what I found courtesy of Daniel Tonks. They have some sort of fancy universal remote that learned the IR codes of the device and the settings were uploaded to the internet. Here's what I extracted using the software Philips provided:
| Cmd | Code |
|---|---|
| Pwr | 1CE3 |
| rotor+ | 10EF |
| rotor- | 11EE |
| 1 | 01FE |
| 2 | 02FD |
| 3 | 03FC |
| 4 | 04FB |
| 5 | 05FA |
| 6 | 06F9 |
| 7 | 07F8 |
| 8 | 08F7 |
| 9 | 09F6 |
| 0 | 00FF |
Each command was prefixed with an identical header: 900A 006D 0000 0001 AC53
Something about this just doesn't sit right with me; its partially that I don't know exactly what these numbers represent (I assume binary data being transmitted) and its also that I've never heard of any IR protocol that would use anywhere near 12 bytes of data per command. I'll have to attach the remote's IR LED to a logic probe and check this for sanity.
In the meantime I'll have to work on the interface circuitry, as it will be the same regardless of what the commands will look like. I'm planning on building a tiny board with a serial header and a microcontroller. I'll remove the IR receiver on the controller and replace it with a signal coming from my board. As long as I sent the right code at the right speed it should perfectly emulate an IR signal.
