Project Logs

Collapse logs

• The protocol from the outdoor unit

  Myles Eftos • 02/25/2017 at 05:28 • 2 comments

  So, I think I've worked out the meaning of the bitstream coming from the outdoor unit!

  On my day off, I took the unit of the wall, got me some coffee and setup shop in the hallway, oscilloscope in hand.

  I must admit, I'm still getting used to using the oscilloscope and I'm sure there is a far better way to do what I'm trying to do, but I found that if I probe the RX pin on the CPU, with the 'scope set to single trigger mode and keep hitting the start button, I'd eventually align the waveform at the start of the cycle. After that I used the onscreen rulers to work out the gaps between the pulses. I then wrote them down in to this spreadsheet. I'd change a setting, take a new set of readings, and repeat until I had covered enough states that I could get a complete picture of what was going on.

  Looking at the data, I could start to see some patterns.

  1. The shortest spacing was around 2ms (some longer; some shorter)
  2. The RX pin is idle low, and there is always a high transition to represent the start bit
  3. There seems to be a low transition to represent a stop bit
  4. There is 9 bits between the start and stop bit (except for the last set)

  It's starting to look like a straight up serial transmission, except the idle state, start and stop bits are inverted, so unfortunately the built in serial protocol decoder wouldn't read it.

  Next I need to find the bits that change between each state.

  The power bit was pretty obvious: there was only one bit that was different when the power was off - the 68th bit.

  Looking at the rest of that byte, there was a pattern developing in the next 3 bits - they seemed to change when the settings changed. Taking LSB first, Fan only mode is represented by 0x01, Humidity mode (Yeah - I don't know what that is either) is 0x02, Cool mode is 0x03, Heat mode is 0x04 and Auto mode is 0x05. The next three bits represent the fan speed: Auto 0x00, Speed 2: 0x02, Speed 3: 0x03, Speed 4: 0x04. But was was the ninth bit?

  Having a think about serial, it's could a parity bit. By summing the number of bits, it became pretty obvious it was odd parity. I checked this against the other bytes, and it checked out - now we are getting somewhere!

  Looking at the next byte, it was clear it was changing with the temperature. I purposely looked at the lowest possible setting for the temperature (15deg) and the highest (30deg) and it was here I was lead down the garden path a little. Reading up on other people's efforts at reverse engineering air conditioner units, this is a fairly common range. Many of the IR transmitters represent this as a 4 bit number, where 0x0 is 15 and 0xF 30. Unfortunately, I couldn't for the life of me work out how that mapped to the numbers I was seeing.

  It turns out, this system uses a 5 bit number - feasibly being able to represent 0 - 31 degrees. Bits 6 and 7 are always 0, and bit 8 is the "economy" settings.

  There is four unknown bytes, and one block that seems to be make up of 5 bytes. My guess is one of the unknown bytes is reserved for errors, and one is a serial number of some sort. I have no clue what the other two could be for, and I'm quite confused by the last, short byte.

  But this is definitely progress!

  I did a final check the get some timing on what is transmitted, and there seems to be three windows of roughly 212ms each. The first from the outdoor unit, the second transmitted by the remote control, and I'm guessing the third is for a slave unit.

  To build a test harness, I'll need to bit-bang the data for 212ms, then set the line to high impedance for 424ms. This will hopefully allow me to get the remote control to work on my bench. Once I can get the remote to work, I can analyse what it is doing. Next, I'll simulate that as well, then set the remote to slave mode and work out that part of the protocol. Once I have the three parts of the protocol nutted out, I can just simulate the outdoor unit, connect the spare remote controller as master, and the microcontroller will become the slave. Easy!

• Baseline communication

  Myles Eftos • 01/16/2017 at 22:03 • 0 comments

  I took the remote unit off the wall again, and this time removed the signal wire fro the remote and attached it to my Oscilloscope.

  And this is signal that comes from the outdoor unit.

  I'm not sure if I stuffed up my reading the last time, but it looks like the pulse width is 2ms.

  Really, I needed to replay this and see if I could get my test unit to initialise. I thought about using an Ardiuno, so I googled bit banging serial to see the best way to do it. One of the results that caught my eye was another Hackaday article entitled "Introduction to FTDI bitbang mode". I had literally just cleaned up my workbench and found a FTDI module. Perfect!

  I knocked up a little circuit that drove a transistor from 0V to 12V, and adapted the code from the article to control the FTDI modules CTS line. I had to reduce the sleep time to 1.8ms to adjust for kernel context switches (I'm guessing) while talking to the adapter. I got it pretty close to 2ms though.

  I wired it up to the controller, and got one step closer - now instead of timing out and flashing C0 12, it just sits flashing "9C" forever.

  My guess? This communication protocol works on one-wire - I'm not releasing the line, so the remote never gets a chance to send a response. It looks like I'll need some sort of tri-state buffer, so I can set the line to high-impedance after I've sent the preamble.

  I was curious to see if I could get any other clues to the protocol, so I started poking around the big chip on the PCB. One of the pins receives the same signal the signal line does, except it's inveted and 0-5V! I went and looked up the chip (it's a UPD78F0393 from NEC - I'm so glad the remote manufacture labelled all their chips nicely), and that pin (#75) is labelled RXD0. That sounds like a serial receive line to me!

  Pin 76 is labelled TXD0, which I'm guessing is the transmit line. This should make decoding stuff way easier, because I'll be able to see what is actually being transmitted and received separately. Win!

  I'm going to try and trace out the front-end to this - so far I see a NJM2904 (an op-amp) is on the path - my guess is that is the thing inverting the signal and driving it to 12V. Tracing this circuit out should allow me to build a compatible circuit from my microcontroller.

• A test unit arrives

  Myles Eftos • 01/16/2017 at 21:32 • 0 comments

  So my test unit arrived!

  I get it on my bench, and test out my theory - if I'm right, it should boot up and start sending commands when the buttons are pressed.

  I was wrong.

  The unit just sits there flashing "9C" for a couple of minutes, then failing over to a "C0 12" error. The Oscilloscope was no use either - I just saw a constant 12V on the signal wire.

  Hmmm.

  Looks like I'll have to pull off the real wall unit.

  Using some wire and alligator clips, I extended the wires so I could reach them with the scope.

  This time I got somewhere - I could see a signal!

  The pulse width is around 1.04ms, going from 12V to 0V. Weird.

  I go distracted for a while trying to decode the protocol - is there start bits and stop bits? What about a parity bit?

  I knocked together a quick D3 script (I'm a web developer, remember - I use web technology for a lot of this stuff because that is what I'm used to) to display the wave form. First, I wrote a ruby script that created a CSV file of just the transitions. There are two entries for each transition - a 0V and 12V value - so the graph ends up looking like a binary stream.

  I then wrote another script that aligned the stream so each pulse was exactly 1.04, and each pulse hight was 12V or 0v. Finally, I scaled everything so the pulse width was 1, as this made reading the graphs easier.

  I ended up with some pretty graphs like this:

  There was still a problem though - I didn't have a baseline for the communications.

  I knew that the control unit didn't send any data unless it was connected to the outside unit. I also knew that changing the temperature changed some of the bits in the data stream, so clearly there was some half-duplex serial communication going on. I needed to find out what the outdoor unit sent to initialise the control unit...

• How does this thing work?

  Myles Eftos • 01/16/2017 at 21:08 • 0 comments

  I've never done any reverse engineering before, but spurred on by this recent Hackaday article, and this article I found I thought I'd give is a crack.

  The first issue: I had no idea what the model number was - it's not written on the unit, nor on the instruction manual. So I just googled for Fujitsu airconditioner remote, hit image results and looked for one that looked the same. Once I found it and clicked through to the source page, I found out that it is a UTB-YUB/GUB/TUB (There are three model numbers depending on where in the world you are).

  I found a supplier on ebay (who was actually Melbourne based), who had a new remote unit for $60, which I bought as I wanted a test unit on my workbench - mainly because trying to test things using the unit on the wall would be really annoying.

  While I waited for it to arrive, I continued googling to find as much info as I could about it. Thankfully, a number of airconditioning repair places have their installation manuals online. Reading though the them, it was clear there was a three wires that connect the remote to the outdoor unit - +12V, GND and a signal.

  Bingo.

  Now, I need to work out what this signal wire does.

  My first hypothesis was the remote unit worked a lot like an IR remote - every button press sent the complete state to the outdoor unit. If this was the case, it should just be a matter of hooking up a DSO (I have the LabNation SmartScope), copying the signal and replaying it via a microcontroller.

  While I could pull the one off the wall, I patiently waited for my test unit to arrive.

View all 4 project logs