Where to start trying to decode a data stream

[elnino]

Hi all, I'm new here but reasonably fluent in basic electronics and circuits as well as a programming and computer background too.

I've had a big ambition for a while now to be able to control my ducted home air conditioner with my home automation system.  The problem is, the protocol it uses to communicate between the 2 controllers and the main indoor unit is unknown.

What I do know:
it uses a single wire data signal at 12v signalling. It has an extremely weak pullup on the data line.  It would appear that the controllers pull the signal pin low to control the data stream but it is a single bus - The data line is common to the 2 wall controllers and the indoor unit and can operate in a multi-master mode.

In isolation, the controller will regularly spit out data when powered on, the data stream changes with different settings active.  However, after about 2-3 mins, it will come up with an error on the screen.  I assume this is because it is not getting responses/data from the main unit.

I don't have a usable scope but i did hook up an opto isolator to the output and pumped it into my sound card on my PC and I have a grab of a few of the outputs.

What I need help with (even if someone can point me to some resources) is some assistance trying to determine the protocol.  Is this impossible?  Where is a good place to start?

The air conditioner is an LG and uses the 'Deluxe wall controller'.  It is based on a Toshiba TMP87PP21DFG 8 bit UC.  It has an SPI port but even with that I am not sure where to start. There is no off the shelf option for any sort of network interface for this model. The unit has an option for a Wireless RF remote but they are impossible to buy/find, otherwise i would have gone down that path..

Any assistance would be greatly appreciated.

[ebclr]

Do you have a osciloscope?

[Ian.M]

You start with a scope that can handle DC coupled input signals.   It needs to have a bandwidth of at least 5x the baud rate of the data signal you are trying to sample.  A sound card scope almost always has AC coupled inputs and with the maximum possible sample rate of 96KHz for a high end card will be unsatisfactory or even useless for any baud rate above 9600 baud.  A crappy 44.1KHz sample rate card will be no good for more than 4400 baud.   As its AC coupled, long busts will drift till they are balanced about 0V further messing up your captured data and making automated processing to decode it more difficult.

Depending on how you wired the optoisolator, and the resistors and output side supply voltage you used with it, you may have further smeared the signal.  Zip up some of the data you've captured and attach it , or post two screenshots, one of the whole data burst and the other zoomed in to show about 20 edges (if you aren't seeing reasonably square edges when zoomed in, your capture method is definitely FUBARed) and we'll see if there's anything recognisable there.

@ebcr: O.P. said "I don't have a usable scope ...."

[brozier]

I'd say you don't need an scope.

You need a logic analyser (cheap salae clone and sigrok will do) and a level shifter / op amp buffer to bring the +12V to +5V without affecting the system...

Sigrok is nice as it has many different protocol decoders so you might strike lucky.

Cheers
Bryan

[Ian.M]

OTOH if you don't have a usable scope, it makes it  difficult to determine if your level shifter is distorting the signal significantly.   You could try a fast comparator  with a fixed potential divider for the input signal and the reference level from a pot between the logic supply and ground, and twiddle it to find the maximum and minimum reference levels that still appear to produce a valid datastream, then set it midway.

[brozier]

OTOH if you don't have a usable scope, it makes it  difficult to determine if your level shifter is distorting the signal significantly.   You could try a fast comparator  with a fixed potential divider for the input signal and the reference level from a pot between the logic supply and ground, and twiddle it to find the maximum and minimum reference levels that still appear to produce a valid datastream, then set it midway.

True everything is easier if you have a scope :-)

Looks like its a common problem to solve :-
https://hackaday.io/project/19473-reverse-engineering-a-fujitsu-air-conditioner-unit/log/52023-baseline-communication

Might be worth looking at the driver chip mentioned in the above project. Should give an insight into slew rates needed. Might even be a similar protocol so an FTDI chip + level shifter might be the answer!

[elnino]

Thanks for the responses everyone!

Here are some snaps of the data.  Yes, you can see that the soundcard is messing with the signal being held high or low but I think it leaves enough to see what is going on.

The Baud rate seems fairly slow.

[Ian.M]

Assuming the second image's timescale is in seconds, it looks like 93.5 baud asynch serial with inverted RS232 framing - 1 start bit, 8 data bits and 1 stop bit.  There's a 13 byte block then a short gap before the next block.   Your trace annotated with framing attached.

Of course I'm guessing about the data bits being inverted or not and whether its low bit first like RS232 or high bit first like SPI, but the above would be good enough to read it with a level shifter and a FTDI USB<=>logic level serial cable set to a custom baud rate divisor of 32100, then the rest could be fixed up once you've grabbed the dat5a.

[elnino]

Wow, that is awesome!  Thank you so much - It makes so much more sense now! That's way more than what I was hoping for.  I'm just not used to analysing data like this though.

I believe the signal here is actually inverted because of the method I used to acquire the waveform so its entirely possible its a more standard serial stream, just at a very low bit rate.

I'll have a tinker with an FTDI adapter and see how I go.

[Ian.M]

Logic level serial is inverted with respect to RS232 anyway, so its already the right way up for a logic level serial adaptor. However I've just checked the FTDI documentation and the maximum divider is 16384 giving 3MHz/16384 = 183.1 baud as the lowest a FTDI adapter can do.   

You are going to need something to translate the baud rate up to something a modern PC can handle.  I believe an Arduino with a hacked version of its softwareSerial library (to add a new entry 93 baud in the baud rate table, with the appropriate delays), would be the best option.  Its got plenty of time between characters so you can do the rest of the decoding there and send ASCII HEx to the PC.

[martinator]

[elnino]

I should be able to mod the software serial library ok - It's a bit beyond my knowledge in relation to serial timings etc but I should be able to nut it out.  Thanks for the assistance!

[Ian.M]

It looks like newer versions of the library compute the baud rate on the fly when you use the .begin() method.  It takes an integer, so assuming you've already created a SoftwareSerial object called mySerial, try:

Code: [Select]

  mySerial.begin(94);Its better to be fractionally faster so its ready for the next start bit so 94, not 93.
You can try sending repeated 0x55 (ASCII 'U') which is alternate '0' and '1' bits, and if you send it continuously, should give you a frequency of 47Hz on your chosen TX pin (use the . print method to send a long string of repeated U characters for minimum gaps).

[elnino]

Wow, you have gone so far beyond my expectations you've been a massive help, thank you so much Ian!

I do have a scope but it's some old CRT thing from the 80's, hence my statement no 'usable' scope but perhaps this might actually be useful here.  I'll load up some code onto an arduino a bit later and check it out. With any luck this might be way simpler than what I first imagined.  One can only hope!

[Ian.M]

Gack!  I took the time for 11 bytes - 110 bits not 100.  Corrected baud rate 102.8 - still assuming that the timescale in the plot you posted is in seconds.
Try .begin(103) and you'd be looking for 51.5Hz out sending 'U'.

A reasonably good analog scope is fine for this sort of stuff except for the flicker you get at low sweep speeds.  If it's got two channels + ext trigger capability, a dual (delay) timebase and 50MHz or better bandwidth, its plenty good enough for all hobbyist stuff up to about 10MHz.

If you set up the Arduino sending 'U' on Ch2 and the original signal on Ch1, in 'chop' mode, triggering on Ch1, with the tmebase at about 0.1s/div you can see how close the baud rate is by the speed the Ch2 signal drifts past the CH1 one.

[elnino]

That time scale is in seconds, you are right.

I think the scope I have is 2 channel but I can't remember, it does have a trigger input though. TBH, I've only used it a couple of times.  It was one of those things someone was throwing out and it seemed too much a shame to let it go to the bin.

Comparing some of the other data streams I captured in various states of the controller, the data makes much more sense now.

EDIT: looking closer over the captured waveforms (and having the ability to zoom in nicely) and pairing it with your info Ian, it pretty much works out to bang on 100bps.  The pulses work out to pretty much 10ms but a few are down to 9ms.

[elnino]

Well I have analysed the data stream and comparing 9 samples I took from the controller I seem to have been able to at least start to decipher the data.

I can see bits changing for the Fan speed, Set temp and the Zone control.  The zones are obvious, so is the fan speed but the set temp still has me a tad baffled. It does not seem to align with anything yet.  Either the raw binary equivalent of the set temp value, nor an 'offset' (Some reading suggests that for some units, the value is an offset from the minimum or maximum the system is able to be set at)

What it seems like though is the 13th byte is some sort of checksum as it seems to vary a lot which might take some extra work but at least it's progress!

I will hook up the arduino over the weekend to assist with the data capture and comparison.  As i said though, I'm a bit new to this so reverse engineering a checksum is probably going to be a challenge.

[elnino]

Well thanks to Martinator and Ian I have been able to reverse engineer the protocol and I am successfully reading the codes from the controller - I am ecstatic!

I have been wanting to do this for ages and now it is finally within my grasp.

I have set up some arduino code, reading the output from the controller and printing it in normal human readable strings now.  I also managed to determine that the checksum for the data (13th byte) is a sum of the 12 bytes XORed with 0x55 and then the just using the lower byte of the resulting 16 bit int.

Still some challenges to tackle such as the fact that it uses a single wire for Tx and Rx but it's awesome to see it even reading the codes!

Thanks so much guys!

[NivagSwerdna]

I don't have one of these but I'm a bit surprised it is a single data line.... wouldn't it be more normal to have a pair of differential signals e.g. RS485?

... I did a google... indeed GND, SIG and 12V.   I'm surprised

[Ian.M]

The concept of 12V (or there abouts) active low single wire serial bus is surprisingly common.  Its even made it into the automotive environment as the LIN bus standard. At its simplest the interface is just a couple of transistors, one PNP, emitter to +12V, base to a tap on the bus pullup, with a potential divider on its collector to get the desired logic levels at the RX pin, and a NPN, emitter to ground, base driven (via a resistor) from the TX pin.   A more sophisticated  interface might use a dual comparator with open collector outputs.

The next thing that needs to be done is to examine a data packet closely on a DC coupled scope.  The soundcard scope wont do because it doesn't have enough bandwidth and is AC coupled.   What you are looking for is signal levels and edge slew rates so you can design a suitable bus transciever (or if you are lucky, use an off-the-shelf one)   Specifically, the  rising edge, which if its an exponential curve will tell you the bus uses passive pullups, If its a straight sloping line then it must be a constant current pullup.  If its a near vertical edge, the bus is actively driven high.  Check the whole data packet as the master may use an active pullup.  Try connecting a 1nF then a 10nF capacitor to the bus as additional loads and each time measure the risetime, which will let you calculate the existing bus capacitance and pullup resistance or current.  The fall-time gives you some idea of how hard the existing units pull the bus down or if their drivers are slew-rate limited to reduce EMI.

Alternatively tear-down a device on the bus and trace the bus driver circuit to get a partial schematic, part numbers and values.

[nctnico]

I'd say you don't need an scope.

For this kind of reverse engineering tasks you will be completely lost without an oscilloscope because the first thing you need to know is what the signal looks like.

[elnino]

This might shed some light.

It's a bit more technical than I prefer but it looks like there are 4 transistors and a diode that handle the signal coming from the MCU.  I can take closer up pics but there does not seem to be too much multi-layer stuff going on.  what you see is basically it.

I got the SMD parts under the microscope and the markings for the transistors and diodes are (from left to right)

NB10 PBAI AV49 NB10 PBAI

To me that looks very much like the PNP/NPN driver you are suggesting Ian.

It looks like it might be as simple as hooking on to the 2 pins for transmit and receive.  I'm currently using a level shifter for reading the 12v signal direct but I think that If I put my rx/Tx lines on these pins i can probably easily control the bus.

What do you think?

[Ian.M]

You can't tap in there for transmit as it will conflict with the MCU on the board.  What you can do is duplicate the bus interface circuit.  However its probably better to simply analyse it (start by drawing up a schematic with component values), then pick a compatible off-the-shelf transceiver.  If you cant find the transistors in a SMD codebook you'll probably need to power it up and check signals anyway, as checking in-circuit with a diode tester that outputs more than 2V or 1mA, or removing one to put on a component analyser is relatively high risk.

[elnino]

This is now really pushing the edge of my knowledge and ability to comprehend whats going on in that circuit.

Would something like the attached perhaps work?

Pulled from https://www.maximintegrated.com/en/app-notes/index.mvp/id/214

[Ian.M]

No. as that would apply 12V to the MCU UART input pin.    However it would do for output.