View Single Post
Old 03-14-16, 01:27 PM   #15
bbro62
Lurking Renovator
 
Join Date: Jan 2016
Location: N/A
Posts: 10
Thanks: 2
Thanked 0 Times in 0 Posts
Default update

This project has been moving forward (or backward) in fits and starts so I thought I'd post an update.

I got a cheap logic analyzer and did some sniffing of the commands being transmitted and received from the controller. Of course I had no idea of protocols, data frames, or baud rate used so I had to guess. I assumed the signals were asynchronous serial because of the wiring which is 12vin, Send, Receive, and Grnd. I set the analyzer at the defaults of 8 data bits, no parity, and 1 stop bit. After collecting some samples and filtering what appeared to be noise using the gliche filter, I measured the width of what appeared to be single bit pulses and calculated the baud rate to ~300 baud. When I plugged that into the protocol analyzer, I was able to see consistent bytes without framing errors so I'm hoping I've discovered the magic protocol.

The communication looks pretty simple. When a command is issued on the controller, a single byte is sent to the HRV unit and the HRV sends back what looks to be an acknowledgement (always 0xBC) and then a half second later, the HRV sends a 0x5C which the controller acknowledges with a 0xBC. That pattern is consistent for all commands issued from the controller with only the initial command byte changing. When an HRV cycle is started or stopped from one of the wall timer switches, the HRV sends a command to the controller and the controller acknowledges with a 0xBC. I'm assuming the timer start command initiates a countdown timer in the controller.

Because the communication sequence was consistent and made sense, I felt pretty confident I had correctly deciphered the logic signals I needed to replace the controller with my own. So I turned to the Arduino to see if I could replicate those bytes to talk with the HRV. The first step was just to test a simple serial loop using the Arduino Serial Monitor to read and send bytes and that's where I hit a problem. It turns out that the Arduino does not handle 300 baud communication well. All bit rates of 1200 and up work fine, but not 300, at least not over the hardware serial ports. It just spits out garbage at that speed. Because 300 baud isn't used any more, there doesn't seem to much incentive to fix it. One thread on the forums hinted that using the digital pins for serial communication might work so I set up software serial to test things out.

Unfortunately, I don't have a USB to TTL converter so no way to monitor the software serial ports directly with a terminal emulator. Instead, I wrote a sketch to read bytes on the software serial pins hooked up to my HRV controller and write those bytes out to the hardware serial to be read on the Serial Monitor. When I hook up the Arduino to the controller and issue a command from the controller, I do start reading bytes but it just spits out infinite 255 (decimal) until I reset the Arduino. The it reads nothing until another command is issued. I get that same result even if I change the baud rate on the software serial pins. So I think maybe the Arduino is still not communicating at 300 baud which means I picked the wrong dev board for this project. Alternatively, maybe I don't have the communication protocol as figured out as I thought. For now, I have ordered a USB to TTL converter so I can at least test the baud rate of the Arduino. If that fails, I guess I need to find a different dev board that can handle low bit rates.

If anyone has any other suggestions or advice about what I did wrong, I'd love to hear it.
bbro62 is offline   Reply With Quote