Quite some time ago I got fed up with the huge amount of power a pool pump uses and got one of those cool permanent magnet, variable speed pumps. It's really cool, it can run from a few RPM up to way over 3000. All of the speeds use less power than a conventional motor and you can actually circulate water with 200 watts of power usage. This is what they look like:
![]()
![]()
Off 0x10, 0x02, 0x0C, 0x01, 0x00, 0x00, 0x00, 0x1F, 0x10, 0x03
100% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x64, 0x00, 0x83, 0x10, 0x03
45% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x2D, 0x00, 0x4C, 0x10, 0x03
![]()
There's three pieces to these things, the controller, the actual motor and the filter-impeller. Hayward calls the controller the 'drive'; I don't have any idea why except maybe because they make pool controllers and they don't want customers to get confused. The drive is this part here:
Yes, I stole the image off the web. It was too hot to go out and take my own picture. The drive can be separated from the motor and remotely set up. This makes it convenient for ease of use, and nice if you have the rest of the stuff inside an enclosure.
The drive has its own controls, but it can also be controlled by my Goldline P4 controller. The problem is that the darn controller only supports two speeds: low and high. Sure, I can set the speed for each of them to anything I want, but I only have two speeds for my variable speed motor. That has always ticked me off. Hayward decided that I only get two speeds for the motor that are easily done. To do anything else I have to futz around with settings each time. Really ??
A few weeks ago one of my readers asked if I had ever pursued breaking the protocol between my controller and the drive. I hadn't, but it sounded like a cool project to take on. So, armed with my motor, his motor, his skills, my lack of skills, we embarked upon a project to get control of this motor. Naturally, there is zero documentation on the protocol, but we had some hints.
It's RS485 half duplex because it works on the same line as the other controls for the P4. It's 19.2Kbaud for the same reason. That meant that we could set up monitors and code to listen to the conversations between the devices as we changed things and might stand a chance to get a hint on how to control it.
Guess what? After a few false starts, we beat it. We can now control the motor and change the speed to anything we want to. It turns out the protocol is relatively simple; you send a command to the motor periodically telling it the speed you want it to run. If you stop sending, the motor stops. If you send a speed of zero, the motor stops. If you send a specific speed, the motor runs at that speed.
The motor protocol works in percentage. If you send 100%, it will run at the top speed. If you send 0%, it stops. You can choose any percentage in between and the motor will go to that speed. You can't send 1000 RPM, you have to send a percentage instead. Still, it works quite nicely. The protocol looks like this:
Off 0x10, 0x02, 0x0C, 0x01, 0x00, 0x00, 0x00, 0x1F, 0x10, 0x03
100% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x64, 0x00, 0x83, 0x10, 0x03
45% 0x10, 0x02, 0x0C, 0x01, 0x00, 0x2D, 0x00, 0x4C, 0x10, 0x03
The 0x10, 0x02 is the start of packet indicator. The 0x0C, 0x01 means from device 1 to device 12. The 0x00 is just a zero, never saw it become anything else. the 0x00 or 0x64 or 0x2D is the percentage in hex (0, 100, 45) the next two bytes are the checksum and the 0x10, 0x03 is the end of packet indicator. So, to change the speed, change the percentage, recalculate the checksum and send it. The motor will change speed. You have to send this at half second intervals to keep the motor running. Actually, I've gone up to a second and a half and still had the motor run, but better safe than sorry.
The checksum is a matter of adding the byte values and sticking them in place. In the first packet above,
10 + 2 + C + 1 + zeros = 1F. Remember, it's hexadecimal and the checksum is two bytes long, so it's 0x00, 0x1F. Similarly, the 100% packet is 10 + 2 + C + 1 + 0 + 64 = 0x00, 0x83. The last two bytes, 0x10, 0x03 are not used in the checksum.
The code for something like this was relatively simple to put together, but it gets really complex when you add in whatever method you use to control it. I have an XBee network that I send commands through, but most folk out there want wireless ethernet or wires. It can be controlled from a board as simple as an Arduino (like me and my colleague), or any other device that can either provide RS485 or handle an adapter to convert TTL serial. My setup is described here <link>, I just added code to it to handle the motor separately and turned off control of the motor in the Goldline P4 I have.
The physical connection is with two wires from your RS485 device to the motor drive unit on the communications port. You may have to use shielded cable and connect the ground up as well; these motors are extremely noisy on both the power line and RF near the unit. So, grab some of that shielded CAT5 cable and go for it.
I cut this right out of the installation manual for the Ecostar motor. Pin 7 is the plus (+) side of the RS485 link and they clearly label the comm connection. This image also shows how the connection is made to a pool controller like my P4.
If you do this to control your motor, there is something that will help you. When you send something to the motor that it can't understand, it locks up the drive unit. I sent many a packet that was constructed incorrectly and the drive would go nuts and not respond after that. You have to actually power down the motor and then turn it back on to continue. Not the most robust software in the world.
There is another protocol here that I will research in more depth later. Not only is the 'drive' controlled by the pool controller, the motor itself is controlled by the 'drive'. Yes, the motor itself has a protocol all it's own that the drive supplies. That's why you can separate the drive from the motor and mount it somewhere else with some wires running between. This is also RS485 and it runs at 1200 baud. It has a different checksum scheme and there are bits in there that have to be figured out. We haven't made much progress on this protocol, but we can make the motor turn on without the drive unit even being there. This may come in handy at some point in the future when the drive dies and the warranty has expired. Those drives cost almost as much as the entire assembly ... jerks.
There you go folk, you now have control of that expensive motor Haward has been keeping secret. That's two of their secret protocols I've put on the web now.
Maybe I should think about hiding for a while...