Can anyone point me to a good starting guide to identifying a protocol between two micro-controllers?

The project I am trying to achieve is controlling a heater/pump unit of a Spa. The project has already been done but with an older model than mine - it had 4 wires between the display/buttons and the main controller (5v, GND, Rx, Tx) and used serial with a baud rate of 9600.

My model has 6 wires. I have identified 5v and ground. Two wires don't seem to do anything on the logic analyser or multi meter. I have included the logic analyser output below.... it does not seem to be 9600 serial....

Any ideas to where I should start?

Thanks for any pointers.

 

Some protocols have fixed timing, others bit banged thru a I/O port pin.

Can you remove cover to controller and read part numbers off chips ?
Especially the larger/higher pin count parts (good chance they are
micro(s). Then looking at part datasheet narrow down what COM
protocols it has.


Regards, Dana.

 

The display/pushbuttons will have their own microcontroller. Look up what micro it uses and, like dandak said, you can narrow your choices that way.

How close display/pushbuttons is to the main controller?

 

Thanks for the replies.

The display/buttons are about 30cm from the main controller. It is connected in the middle with a JST-SM 6 pin connector with a ribbon cable going to each board. (see below)


I have previously taken a picture of the boards for the buttons/display and the main controller. However, you can't see the IC markings..... I will have to get out there when it is not raining and open it up again to take some macro photographs.

Main controller with all the relays on. The 6-core ribbon connector is what connects to the display. There are some other wires as well; these are flow and temperature sensors.


Zoomed in on the 6-core connector - no clue as to protocol there


Couple of views of the button/display board. The 6-core connector enters underneath in the bottom right hand corner ('V' and 'G' are helpfully marked, but sadly no reference to protocol e.g. Rx/Tx)

 

sorry, i can't see anything on your logic analyser measurement due to it's very low resolution. a 9600bd signal may toggle 10 times per ms - e.g. you should increase the time base by at least 10x from what you used before.
D0, D1 seem to be dead ends - did you ever trigger some activity there?
D2,D3 may even have higer baud rates of up to 500k (of course i do not thinks so, but never say never...) - did you check this out?
ps: a good starting point to guess the baudrate is to find the shortest signals.

 

I increased by sampling rate to 24Mhz and fiddled with my wires (I am just ramming them into the connector block for now)..... I now get output from three of the pins. It looks to my untrained eye like SPI but there is no SCLK line (unless that is what the flat line is but my logic analyser isn't good enough to get it?)

I tried looking at the chips but there is a waterproof glue over the whole board which means you can't see the faint writing other than a smaller chip on the display..... this seems to be the button controller (FTC334, 1838-E1, TAV249)

Overview - note there are short and long bursts and D1 is always low when D2 and D3 are active


Close up of a 'long burst'


Close up of a 'short burst'


Short and long burst together

 

Looking at the master board the MCU 'looks like' an ATmega328.

There are two pins that are connected to the 8mhz crystal which should be Tosc1 and Tosc2?

That would mean that Rx/Tx seem to run to the ribbon connector meaning that it is some form of UART??

See my annotated diagram.



If it is serial then it isn't 9600 8N1 (or it has frame errors+) and what the third and fourth wires are is anyones guess!

 

think you are already on the track looks like an SPI

D2 is the clk signal with typ. 50us period e.g. 20khz
the rising edge is the hot one (where data is taken)
you can see the byte reload time on every 8th bit
maybe it's software generated because even the single bits are not perfectly stable

D3 is a data line; since it shows the higher activity (compared to D1) i guess this is the data going up from IOC to DSP
just to decode your"close up of short burst" (see my commented image): 0100 0010 1101 1000 1101 1000
considering that the signal may be inverted and MSB or LSB first, the first 8bit group represents one of those values:
0x42 - MSB first
0x42 - LSB first (typ. for start-bytes that they are mirrored)
0xbc - inverted ... uuups! the protocol i found on my pump uses 0xbc as starting charater for frames sent from IOC to DSP ... what a coincidence...


D1 is another data line, but seems to have all low signals (the analyser screenshots show it to be high only while clock is in its inactive state). imho this may represent the data sent by DSP to IOC. just try pressing a key and watch if the D1 changes it's skyline.

with all this knowledge it should be now easy for you to capture a byte stream for further analysis (to save you from fiddeling around with each single bit).

 

the image i promised in my former reply:

 

Thank you very much, I seem to be making progress now!

Just in case I'm being daft the invert of 01000010 is.....
10111101 = 0xbd (and not 0xbc)

I also can't get my logic analyser to invert the output for me. Can't see an obvious temp. readout in there (it is 36-38 degrees usually)

 

p.s do you think the DSP board simply sends button presses to the IOC.... the IOC takes the set temperature from the DSP and does the thermoregulation itself?

Or does the DSP board regulate the heaters on/off itself.

Logically I would say the first option makes sense. However your description of the protocol has no way for the DSP to send the set temp. to the IOC

 

Thank you very much, I seem to be making progress now!

10111101 = 0xbd (and not 0xbc)

View attachment 180342 View attachment 180343

sic - seems i was a bit rash

 

p.s do you think the DSP board simply sends button presses to the IOC.... the IOC takes the set temperature from the DSP and does the thermoregulation itself?

Or does the DSP board regulate the heaters on/off itself.

Logically I would say the first option makes sense. However your description of the protocol has no way for the DSP to send the set temp. to the IOC

in my pump all regulation work is done by the DSP - the IOC just turns the peripheral on/off without any further intelligence (expected the security features such as "no water flow detection").
but your unit may work totally different. since it is older it may have no controller in the DSP (formerly more controllers were more expensive). i read about units where the IOC just sends a bit mask corresponding to the single LED's of the 7-segment displays. maybe you can find 4 bits toggling when temperature changes between 37 / 38 ?

 

ad D0: maybe this is some reset signal which clears the DSP shift registers upon power on. you should see this, when comparing +5V (which should come first) with D0 (which should then come with a slight delay).

 

if you cut the line between DSP and IOC it should be possible to find out who is sourcing which signal. when knowing this you try to stimulate the DSP with some fake signal and have a look what happens. as long as you do not cause two active drivers to work against each others, there cant go anything wrong (or maybe you put a 100R inbetween to be totally sure not to destroy anything).

 

Thanks for your help, however I don't think I will be able to detangle all this in a reasonable timeframe and I've thought of a 'simpler' way.

I am just looking to do the majority of my water heating at night when my heating costs are a 1/3 of what they are in the day and supposedly there is lots of 'spare' electricity int he national grid (special tariff for charging electric cars overnight)

I'm going to put a WiFi relay (Sonoff 4ch pro) with a ds18b20. I will wire the two 240v heating outputs via the WiFi relay and set the temperature of the Spa to 40degrees on the display panel.

I will flash 'ESPEasy' to the WiFi relay. I will be able to then make 'rules' that will allow the temperature to go to 40degrees when I have cheap electricity (as an energy store as I don't really want it that hot all the time) and during day just keep it going below a 'minimum' temperature (e.g 35degrees).

I will be able to integrate it to my home automation system (Domoticz) to log temperature and control the set-points remotely too (+/- integrate with alexa - e.g 'alexa, turn on boost spa')

The safety is that I am leaving all the original controls/cut-outs in place.... I am simply cutting off the heater meaning it never reaches it's set-point when electricity is expensive.

The only issue I can see is trying to get a reliable water temperature which is not an overestimate as the only place I can think of attaching the temp probe is to the outside of the metal heating block...... I will have to experiment where I can get the best measurement of the inlet water temperature without significant modification (maybe attaching it to the plastic pipe with lots of insulation around it?)

 

the original temp sensor is somewhere very close to the heating elements (i think before the heaters in direction of water flow).

i would strictly avoid to make an extra hole for another sensor, especially when this is inside the pump housing.

due to the cheap price of lay-z spa, i guess that the original temp sensor is some PT100 sourced with constant current. in that case you can easily connect your controller in parallel using some high impedancy (>=1M ohm) analog voltage input. you just have to measure once a few interpolation points for the temperature/voltage translation table (which should be nearby linear in your typical operating range).

during heating you have to GRANT that the water pump is on (otherwise the heaters may become destroyed). my spa controller does it that way:

turn on sequence:
- turn on water pump
- waits 2sec
- turn on heater 1 (1kW)
- waits 30sec
- turn on heater 2 (another 1kW)

turn off sequence:
- turn off heater 1 and heater 2
- wait 30sec
- turn off water pump

furthermore there are some important security features, which you should never ever bridge with your add-on control:
a) turn off both heaters anyway when temperatures rises above 40°C - to be considered in your control loop software
b) turn off both heaters when water flow sensor reports "no flow" - the sensor is a simple switch; it should be possible to just connect your controller in parallel
c) emergency power off when temperature fuse is blown (at .approx >45°C) - it's hardwired in the heaters supply wiring - should be still active if you take care to put your relay connections close to the original relay (and not at the pump)

 

Hi,

Just wondered if you ever made progress on the protocol discovery or whether you settled on your alternative solution. I am interested in doing something similar but would prefer interfacing at the control signal point.

Thanks

 

I have a cheap LA stuck in the mail, I can't wait to get it.