pfletch101
Posts: 661
Joined: Sat Feb 24, 2018 4:09 am
Location: Buffalo, NY, USA

Monitoring a Heat-Recovery Ventilator in a Home Control System

Thu Jun 17, 2021 7:42 pm

I am working on an ongoing Pi-based home-control project, with its components written in Python and currently running on a 3B. I want to include (at least) monitoring of a Lennox 'Healthy Climate' heat-recovery ventilator, which is currently managed by its own wall controller and time-switches. These are connected to the main unit in parallel by three wires, and (other than being described in the manuals as 'low voltage'), the way the devices communicate is completely undocumented. I have done some spelunking with an oscilloscope, and there appear to be digital communications going along one pair of the wires, with trains of ~ short (0.5 - 1.5 msec) 3V5 pulses being propagated along them. Under all circumstances that I have looked at, a train of 3-5 pulses appears every 20 msec, and one or two additional and separate pulses appear shortly after the end of every 12th regular train. I think that the more frequent pulse trains are generated by the HRV main unit; the less frequent additional ones seem to be control signals generated by the peripheral devices. There is no obvious internal pattern to the more frequent pulse trains, but the pattern of the less frequent ones does seem to correspond to what the HRV unit is being instructed to do (and does).

Ideally, I would like to 'mask out' the less frequent pulse sequences and respond only to what the less frequent ones indicate. It happens that one particular (and important) circumstance is signalled by a very long (7.5 msec) 'less frequent' pulse, and my minimum aim would be to raise a logical flag when this is seen. My first choice would be to use a dedicated Pi (probably another 3B) for this, communicating with my primary 3B across the network, but I am wondering whether using Python to sample the pulse data on a Pi running RasPiOS via GPI-connected circuitry is likely to be able to accomplish the relatively tight pulse timing sensitivity that is likely to be needed to listen in on these communications. I am really interested in suggestions on strategy at this point, though more detailed tactical suggestions would also be appreciated.

Earlton2
Posts: 81
Joined: Mon May 27, 2013 1:13 am
Location: Tonight it's -28C
Contact: Website

Re: Monitoring a Heat-Recovery Ventilator in a Home Control System

Fri Jun 18, 2021 10:12 pm

I use the RD serial port on a Pi to capture dial pulses from and old telephone. In this case they come in as an '@', which I count to determine the number dialed. Dial zero gets you 10 pulse or '@@@@@@@@@@'.

The ASCII character consists of a START bit followed by up to 8 DATA bits so the character lasts 9 bits where the time for each bit T is 1/BAUD.
if your longest pulse is 7.5 ms then you need 9-bits to be around 8ms (0.008s). T = 0.008/9 giving BAUD = 9/0.008 = 1125. You might try 1200 baud giving a bit time of 1/1200 = 0.833 ms and a character time of 9/1200 = 7.5ms happens to be dead on your max measurement.
Your minimum time of 0.5ms might just trigger a character reception as it is more than half a bit time and would look like a start bit.

Voltages on the RD line must be kept below 3.3 and must normally be HIGH. The START bit is a LOW pulse. The 8 data bits are HIGH for 1.

Data:
If the 0.5 pulse does trigger a character then all the DATA bits come in as HIGH and the value received should be 0xFF = 11111111.
A 4 ms pulse would be 4/0.833 = 4.8 DATA bits at 1200 BAUD. One for the START bit, 4 0''s and 4 1's = 00001111 = 0F0 = 'p'

It might be possible to use odd BAUD rates to modify the captured data.

Dial D-for-diesel still gets you a movie on Youtube and there are some old schematics at https://web.ncf.ca/fx829/comm.html.
I recommend an opto-coupler between your real World and the Pi-RD line.

Hopefully I didn't make too many errors in this response and it at least gives you a useful option.

pfletch101
Posts: 661
Joined: Sat Feb 24, 2018 4:09 am
Location: Buffalo, NY, USA

Re: Monitoring a Heat-Recovery Ventilator in a Home Control System

Fri Jun 18, 2021 11:01 pm

That is an interesting approach, but I think that the variable length (0.5, 1.0, or occasionally 1.5 msec) and number of pulses in the frequent pulse trains would cause confusion in a setup that was expecting just the presence or absence of a regular pulse. After doing some more scoping, I have confirmed that the frequent pulse trains are coming from the HRV unit (God knows what their significance is - possibly just some sort of sync functionality for the peripheral controllers) and the less frequent sequences are coming from the peripheral controllers. I have ordered a couple of picos to play with, and I suspect that I should be able to program one of them to sync to the first pulse of the HRV's output, wait long enough after each one of these to ignore the rest of the train and then listen for controller messages in the 'gaps'. The pico can then tell a locally connected 3B what is happening and the latter can communicate with the 3B that is controlling the rest of the systems.

You are probably right about the advisability of an opto-coupler - at least in the ultimate working setup.

jayben
Posts: 301
Joined: Mon Aug 19, 2019 9:56 pm

Re: Monitoring a Heat-Recovery Ventilator in a Home Control System

Sat Jun 19, 2021 10:06 am

You don't say if the data is async or synchronous (i.e. with a separate clock line) but I assume the former.

The smallest time-value of 0.5 msec does imply a baud rate around 2000; if you measure the width accurately, does it correspond to 2400 baud? Is there evidence of start and stop bits, assuming 7 or 8 data bits? Having determined the baud rate, is the total number of bits in a message a multiple of 8 or 9? If 9, and does the last bit look like a parity bit? Is there are part of the message that always changes, which might be a sequence number (with a step change) or CRC/checksum (with a seemingly random change)?

Before touching the Pi, you could save the scope (or logic analyser) traces as CSV files, then write some software to decode them.

With regard to capturing the data on the Pi, if a UART doesn't work properly, I'd use an SPI input, with a clock frequency significantly greater than the fastest pulse. You'll then get the pattern of 1s and 0s smeared over several clock cycles, and the same code that you used to decode the scope/analyser traces can decode that.

pfletch101
Posts: 661
Joined: Sat Feb 24, 2018 4:09 am
Location: Buffalo, NY, USA

Re: Monitoring a Heat-Recovery Ventilator in a Home Control System

Sat Jun 19, 2021 12:34 pm

jayben wrote:
Sat Jun 19, 2021 10:06 am
You don't say if the data is async or synchronous (i.e. with a separate clock line) but I assume the former.
It is async. There is no data on the third line (which I think is a common return).
The smallest time-value of 0.5 msec does imply a baud rate around 2000; if you measure the width accurately, does it correspond to 2400 baud?
It would if one assumed that baud rate was a meaningful concept in this case, but I did measure the width accurately and the pulses do appear to be exact multiples of 0.5 msec.
Is there evidence of start and stop bits, assuming 7 or 8 data bits? Having determined the baud rate, is the total number of bits in a message a multiple of 8 or 9? If 9, and does the last bit look like a parity bit?
No, no, and no - hence my belief that it is not a standard comm format.
Is there are part of the message that always changes, which might be a sequence number (with a step change) or CRC/checksum (with a seemingly random change)?
The 'message' is a single short pulse train with up to four pulses of width as described. I wondered if there was a a pattern encoding a sequence number, but I cannot convince myself that this is the case - the individual patterns seem to appear at random.
Before touching the Pi, you could save the scope (or logic analyser) traces as CSV files, then write some software to decode them.
With regard to capturing the data on the Pi, if a UART doesn't work properly, I'd use an SPI input, with a clock frequency significantly greater than the fastest pulse. You'll then get the pattern of 1s and 0s smeared over several clock cycles, and the same code that you used to decode the scope/analyser traces can decode that.
I have already 'decoded' he (less frequent) control sequences, and I don't think I need to know what the HRV is 'saying''.

Return to “Other projects”