EcoRenovator  

Go Back   EcoRenovator > Improvements > Tools
Advanced Search
 


Blog Register 60+ Home Energy Saving Tips Recent Posts Search Today's Posts Mark Forums Read


Reply
 
LinkBack Thread Tools Display Modes
Old 01-21-16, 12:23 AM   #11
Supreme EcoRenovator
 
Join Date: Jan 2010
Location: elizabethtown, ky, USA
Posts: 2,201
Thanks: 316
Thanked 554 Times in 463 Posts
Send a message via Yahoo to jeff5may
Default

It sounds like you have a good amount of time invested in the project already. From your story so far, you seem to have a good grasp on how the two units interact during operation. From your description, it sounds as if the panel issues commands and the main module either acknowledges the command or replies with an error message. There may be other communication going on that may seemingly have no effect on operation.

The tool you seek here is a logic analyzer. There are literally a jillion of these things on the market to suit many needs. In this case, the hrv controller probably runs in the single digit MHz range, and comms much slower. A cheap, USB-based probe will more than do the job here. Just search for "usb logic analyzer" or "pc logic oscilloscope" and the like. If the unit does indeed chat back and forth, it probably speaks i2c, spi, or some other common language. There are open-source interpreter programs on the web that can help you figure out the details. As with all software, the paid versions are usually better once you learn the process.

If you decide to go the other way, the manual does a pretty good job at spelling out most of the details behind the scenes. The unit seems to use a 10k nyc thermistor for the defrost sensor, so it wouldn't be super difficult to interface with. The relay and motor drivers could be found and tied into. Then you would have to write a firmware of your own.

jeff5may is offline  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
Reply With Quote
The Following User Says Thank You to jeff5may For This Useful Post:
bbro62 (01-21-16)
Old 01-21-16, 08:55 AM   #12
Lurking Renovator
 
Join Date: Jan 2016
Location: N/A
Posts: 9
Thanks: 2
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by jeff5may View Post
The tool you seek here is a logic analyzer. There are literally a jillion of these things on the market to suit many needs. In this case, the hrv controller probably runs in the single digit MHz range, and comms much slower. A cheap, USB-based probe will more than do the job here. Just search for "usb logic analyzer" or "pc logic oscilloscope" and the like. If the unit does indeed chat back and forth, it probably speaks i2c, spi, or some other common language. There are open-source interpreter programs on the web that can help you figure out the details. As with all software, the paid versions are usually better once you learn the process.
Thanks! This is exactly the information I was looking for. Do you have any thoughts about using an Arduino itself as a logic analyzer such as what is demonstrated here: and provided here: https://github.com/gillham/logic_analyzer? This is appealing because it seems like I might be able to use the arduino to analyze the signals, then program it to replicate those signals, and pop the chip out to use in my new controller. And I'd still have the Arduino to use for other projects.

Quote:
If you decide to go the other way, the manual does a pretty good job at spelling out most of the details behind the scenes. The unit seems to use a 10k nyc thermistor for the defrost sensor, so it wouldn't be super difficult to interface with. The relay and motor drivers could be found and tied into. Then you would have to write a firmware of your own.
By this, are you talking about reprogramming the existing chip on the control board, replacing it with my own, or splicing in my own chip to the board while leaving the original in place? I'm actually waiting on delivery of a NOS control board that I picked up cheap on ebay so will soon have a spare to play around with.

Thanks much for your help. I'm finally feeling like I have a path forward.
bbro62 is offline  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
Reply With Quote
Old 01-21-16, 01:29 PM   #13
Supreme EcoRenovator
 
Join Date: Jan 2010
Location: elizabethtown, ky, USA
Posts: 2,201
Thanks: 316
Thanked 554 Times in 463 Posts
Send a message via Yahoo to jeff5may
Default

Yes, you can grab a sketch that will turn an arduino into a logic probe or analyzer, wire it up, and use it. I don't know how accurate or sensitive it would be. I do know the little 8 channel USB ones work, and can be found for less than 20 bucks. They can also be used as digital storage oscilloscopes, so if you don't have an oscilloscope they are definitely worth the purchase price right there. If you do much tinkering on electronic devices, you absolutely need an oscilloscope.

As for your "option 1" solution, the only way you could reprogram the existing chip (if it is programmable- some are burnt like a DVD or bootstrapped from a prom) is sort of like the ftdi method with the older arduino boards. You would have to have a complete programming studio for the chip in question. Not easy, plus you would need to come up with a sketch for the micro to work.

If you wanted to completely remove the micro from the main board, you could. Doing measurements while the micro was still in to figure out what signals come and go on what pins would save a ton of time in decoding the board. Using this method, once the stock micro is removed, you would have lots of easy to solder empty holes that would most likely directly plug and play with jumper wires and a generic dev board.

Going at the end of the trail is even easier. Letting the stock micro do its business and "jinxing" input and output signals is easier than writing a sketch to account for every possible situation. You could tap into certain points on the main board to keep tabs on signals and states of important aspects and ignore pretty much everything else. In this rig, the dev board would just sit and listen, allowing the factory micro to control everything while the unit is working like you think it should. When a condition came up where you wanted to change functional state, the dev board would either feed the factory micro a command to force the desired state, or switch output signals directly and feed the micro a signal to hide the change. Depending on how much redundancy is built into the stock micro, it may or may not go postal when its control is severed. Since a hrv is probably not programmed as a critical system, I'm thinking it wouldn't complain much.

Looking at the stock micro datasheet reveals it has a built in serial interface. The thing wires up using TWI (three wire interface) standards. It is 5 volt TTL and its pinout looks like this:

If the board is using the built in serial interface, you will see activity on pins 11, 12, and 13. Tying a logic analyzer to your wires between the main board and control panel, along with these 3 pins would quickly reveal whether or not (and how) the micro is using that port for comms. If not, other pins could be tapped to find out pdq which port is being used.

The easiest way to snoop on your micro is to grab a "piggyback" connector for your particular micro footprint. Most clamp on over top of the ic like a clothespin and have wires or sockets that you plug your analyzer into. Again, you can spend as much as you want on one of these. The expensive ones are more securely attached and are less fragile than the cheapo items. Depending on how clumsy you are with tiny probes and chips, a more expensive one would greatly reduce Murphy's law from showing up and ruining the day. Even then, you still have to be careful with static electrical charges and shorting pins and such.

Last edited by jeff5may; 01-21-16 at 04:55 PM..
jeff5may is offline  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
Reply With Quote
The Following User Says Thank You to jeff5may For This Useful Post:
bbro62 (01-26-16)
Old 01-26-16, 05:39 PM   #14
Lurking Renovator
 
Join Date: Jan 2016
Location: N/A
Posts: 9
Thanks: 2
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by jeff5may View Post
Yes, you can grab a sketch that will turn an arduino into a logic probe or analyzer, wire it up, and use it. I don't know how accurate or sensitive it would be. I do know the little 8 channel USB ones work, and can be found for less than 20 bucks. They can also be used as digital storage oscilloscopes, so if you don't have an oscilloscope they are definitely worth the purchase price right there. If you do much tinkering on electronic devices, you absolutely need an oscilloscope.
Got sidetracked for a few days but wanted to thank you again for this incredible information. The only logic analyzers I could find for under $50 were generic Saleae knock offs but they supposedly work according to reviews. So I have one on order. While I wait, I'm reading up on the basics of microcontrollers at that is the only mysterious black hole in this system for me. I'm sure I'll have more questions after the analyzer arrives.

But thanks again!
bbro62 is offline  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
Reply With Quote
Old 03-14-16, 01:27 PM   #15
Lurking Renovator
 
Join Date: Jan 2016
Location: N/A
Posts: 9
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  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
Reply With Quote
Old 01-10-18, 03:20 PM   #16
Lurking Renovator
 
Join Date: Jan 2018
Location: Muskego, WI
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by bbro62 View Post
This project has been moving forward (or backward) in fits and starts so I thought I'd post an update.

If anyone has any other suggestions or advice about what I did wrong, I'd love to hear it.
I don't have suggestions but wondered if you ever figured this out? I'm looking to buy an HRV and was quoted for the same model you have, but don't like the controller at all. I would really like a "smart" or at least smarter option. I also have a gen3 Nest.

lakereef is offline  
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 12:22 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Content Relevant URLs by vBSEO
Ad Management by RedTyger
Inactive Reminders By Icora Web Design