3
\$\begingroup\$

I am trying to reverse-engineer the remote control protocol for my EcoSmart Tankless Water Heater.

Unfortunately, the remote control device is no longer available for purchase, and the manufacturer has no information on the protocol used. I want to try and interface the heater directly to an Arduino so I can monitor/control it via Ethernet.

The heater has a 4-pin connector for the remote, and is connected to the MCU as shown here:

schematic

simulate this circuit – Schematic created using CircuitLab

The unit sends data in the following scenarios:

  • Temperature changed by turning control knob
  • Unit turned on/off by pressing control knob
  • Heater activated/deactivated (water flow start/stop)

My scope has built-in RS-232 decoding, and it does seem to decode some data at 1200bps, but I am not sure I'm actually dealing with RS-232/UART data here. My question to you is: what type of data does this look like to you?

Here is part of the output of an "ON" operation (i.e. press button to turn heater On): http://is.am/fx

To me, this looks like too many high/low transitions for UART... I am leaning toward a variable-width pulse to indicate 0/1. In the timing diagram above, you see my interpretation of both RS-232 and "Other" which indicates an unknown protocol, which would have a digital '0' as a 720uS high pulse, and a digital '1' as a 24mS high pulse.

I would appreciate any insight into the protocol used here. If you need clarifications I'll do my best.

RS-232/UART reference: https://electronics.stackexchange.com/a/227414/16378

Update: After recording and transcribing lots of waveforms from different events, I have figured out part of the protocol.

  1. There is a 'Start' command at the beginning of each sequence. It consists of a logic Low for at least 4ms, then High for 7ms, then Low for 4ms.

  2. After the 'Start' command, short pulses (720uS) represent logic Zero and long pulses (2.4ms) represent logic One. The spaces between pulses are all approx 840uS.

  3. All sequences are 5 bytes long, and are transmitted 6 times.

  4. The first 2 bytes are always the same: 00:FF:0F:F0

  5. The third byte appears to be the command/event identifier:

    • Temperature setting change event (wheel turned): 00:70
    • ON command (button pressed): 00:00
    • OFF command (button pressed): 00:70 (same as temp. setting)
    • Flow start event: 02:70
    • Flow stop event: 00:70 (same as temp setting and Off command)

  6. The fourth byte is the temperature in Fahrenheit, MSB to LSB (80 to 140)

  7. The fifth byte is the temperature in Celsius, MSB to LSB (26 to 60)

So now I have to determine if I can send these same sequences into the RX line to change temperatures and enable/disable the heater remotely. I wonder if a different address is used

UPDATE #2: Success! It turns out, sending the same sequences to the RX pin can be used to adjust the temperature and turn the unit on and off! It was quite easy to bit-bang the protocol with an Arduino Uno, and the heater responds to temperature settings by directly altering the output temperature (no need to step upward/downward one degree at a time). I plan to post the full interface guide along with source code for both input and output when completed.

Thanks to everyone who offered suggestions!

UPDATE #3: Github repository created: https://github.com/ryangriggs/EcoSmartLib

UPDATE #4: See Phil's github repo for further info: https://github.com/PhilRW/ecosmart-remote

\$\endgroup\$
10
  • \$\begingroup\$ Are you sure there are no labels on the MCU? The link you provided features a picture of the control board, is that what you have? \$\endgroup\$
    – Dmitry Grigoryev
    May 10, 2016 at 15:41
  • \$\begingroup\$ @DmitryGrigoryev Yes that is the exact control board. However, the main MCU has no etching at all. I have cleaned it, used a magnifier, etc, but there is nothing printed on it. It is a 28-pin SOP28 package. \$\endgroup\$
    – Ryan Griggs
    May 10, 2016 at 15:50
  • \$\begingroup\$ It might be more recognizable if your timing waveform had a constant time axis. As it is, its difficult to get a feel for the relative timing just by looking at it. \$\endgroup\$
    – brhans
    May 10, 2016 at 17:58
  • \$\begingroup\$ Any idea what year is this device from? Maybe a date stamp on another chip or the PCB? IF it's no longer manufactured and is old, that would limit the available interfaces to check. \$\endgroup\$
    – user68591
    May 10, 2016 at 18:39
  • \$\begingroup\$ @Wojciech I'm going to guess this device was manufactured around 2014, and this model is still being actively manufactured/sold. Unfortunately I've already put it back together and hate to disassemble everything to check the date code. :) \$\endgroup\$
    – Ryan Griggs
    May 10, 2016 at 18:45

1 Answer 1

Reset to default
3
\$\begingroup\$

The Data Protocol that you showed in the linked document looks like the modulation waveform common to some IR Remote Controls. It is possible that the wired setup that you describe may be devised so that the remote control link would also work if an IR receiver module were plugged into the remote header. (Communications would be one way though).

Several common IR protocols are described in this document.

I would venture to guess that the two longer times (7msec/4msec) are the start sync for the transmission. After the sync time the data looks to be encoded in bit cells that are 1440 usec wide encoded as Manchester modulation. One data level being 720usec high at the start of the cell and 720usec low in the second half of the cell. The opposite data level being represented by the data line low for the 720usec at the start of the cell and high in the second half of the bit cell.

This is definitely not an async format used by a typical UART protocol.

\$\endgroup\$
13
  • \$\begingroup\$ WOW that was a fast answer! Thanks Michael, I am researching the Manchester modulation encoding now. I really appreciate your input! \$\endgroup\$
    – Ryan Griggs
    May 10, 2016 at 15:55
  • \$\begingroup\$ In Manchester encoding the longer sample should be twice as long as the short one. Here I can see periods of 24mS, 7ms, 4ms and 720uS, none of them satisfy that condition. Where have you seen 1440us? \$\endgroup\$
    – Dmitry Grigoryev
    May 10, 2016 at 15:59
  • \$\begingroup\$ two 720 us times showing near the front of the "data" waveform. \$\endgroup\$
    – Michael Karas
    May 10, 2016 at 22:58
  • \$\begingroup\$ that does look like an IR waveform, doesnt matter what protocol it lines up with, you have at least a few controls and you have a scope or something you have already captured this with. The long/sort up front looks like the sync pattern, and after that consider the shorts, same size as the lows to be zeros and the longer highs to be ones. \$\endgroup\$
    – old_timer
    May 11, 2016 at 0:41
  • \$\begingroup\$ ideally you want the properly matched led and carrier frequency, but you can sacrifice distance and use 40K or 38K. What i would do first though is while monitoring this interface, take any IR remote control you have and aim it at the thing, if it generates waveforms on this interface, then there you go, it is just dumb and passes them through, and "all you need to do" is generate the right ir signal. \$\endgroup\$
    – old_timer
    May 11, 2016 at 0:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.