Aircon Monitor Part 2 – The hardware – current sensor, ADC, thermistor & Arduino

This is the second part of a multiple part series about some hardware & software that I hacked together to monitor the AC current of our outdoor aircon unit. This part I’ll be discussing how I’ve established the hardware parts selection for this project, which are SCT013 Current Sensor, SAR ADC, thermistor, Gertduino, and Raspberry Pi Model B (rev 1).

  • Part 1 – The introduction – Why, what & how
  • Part 2 – The hardware – current sensor, thermistor, ADC & Arduino (You’re reading this)
  • Part 3 – The circuit design – Analog, digital and data flow
  • Part 4 – The firmware – Arduino, RMS calculation & Raspberry Pi’s UART
  • Part 5 – The software – data collection, analysis & decision
  • Part 6 – The solution – still unknown at this stage

To achieve what I outlined in Part 1, which the aircon is reporting overcurrent during a hot day, I’ll need to measure the AC current and the temperature continuously over time. To be able to capture the peak current, the time resolution would have to be reasonably small. Preferably multiple times within a single cycle of our AC here at 50Hz. The hardware should also be remotely accessible, hence Wifi connection is a must 🙂

AC current sensor

To measure AC current safely, I’ve already had a YHDC SCT-013-000, 100A model which should work well for this. So that’s settled. OpenEnergyMonitor project site has a good report on it and various tutorials on using it.

ADC (Analog-to-Digital Converter)

I wasn’t sure how much current I needed to measure. Considering the aircon is on a 15A plug, a range of 15A should be more than sufficient. The ATmega328P on the any of the Arduino board I have only had 10-bit ADC, which for a scale of 15A, I can get about 15mA of resolution. Typically analog circuits are going to be noisy, plus the noise from the switching power supply of the Pi, I’m going to lose 1 bit if I’m lucky, and likely 2 or more bits. That gives me a resolution of 58~117mA. Assuming if the aircon is drawing at 2A at equilibrium, that only gives me about 34 counts out of 8-bit. Designing a low noise circuit is going to be hard when using a perfboard.

I could upgrade to the built-in 12-bit ADC in Redbear DUO, which would give me a much more comfortable 136 assuming effective 10-bits. Since it’s a 3.3V board, I would have less room to work with on the analog front end using op-amp. If I choose to lower the max current, then I might not be able to capture the peak I intended. In the end, I decided to go with an external ADC, giving me more leeway in the design. As for the sample rate, I wanted to get a decent RMS current measurement, most material I could find online suggest at least 1000 samples/s. I decided to do 5000 samples/s, which gives me 50 samples per half cycle, that should be more than enough for the RMS calculation.

Since I don’t have any ADC here, so I sign up for Element14 Singapore. Fun fact, Element14 Malaysia and Singapore shared the same backend system. How I know? I can’t reuse my username from Malaysia ;). I looked for an ADC that runs on 5V with at least 14 bits and faster than 5ksps. Sorted by price, I found ADS8317 from TI, 16-Bit, 250kSPS SAR converter.

In the past I’ve always stayed with Sigma-delta converter, mainly for it’s linearity and higher resolution. For this, I needed something faster, accuracy is not as important, but the resolution is. So using SAR converter allows me to play with something new while having a bit of challenge.

A good challenge will give a better satisfaction at the end 🙂 I’ve also learnt that this particular SAR converter supports “short cyling”, which you can stop the converter once you have enough significant bits to know that you can skip the rest. The converter works in “successive-approximation”, it produces the bits as you read it. If you stop reading, it stop as well, hence “short” cycling. Although I don’t use this feature here, but it’s an interesting concept to learn, that save time and power whenever you know you don’t need the full 16-bits.

Temperature Sensor

I also wanted to hook up a few temperature sensors to monitor the outside temperature and the temperature near the compressor. I had a bunch of spare 10K NTC thermistors from my 3D printer, that should do the work with any of PIC/Arduino’s ADC.

Micro-controller/Micro-processor

I’ve been bringing my microcontroller/microprocessor boards from back home (Malaysia) whenever I go back to see my family. So I’m spoiled with choices from simple Arduino boards, plain PICs, ESP8266, ESP32, Redbear Duo, Omega2 to Pine64 & various generations of Raspberry Pi.

I’ve decided on Gertduino, an Arduino board that doubles as a Pi HAT, and Raspberry Pi Model B (the first version). I wanted something that can run python, which requires less effort and can be easily updated remotely while having enough storage to be left alone when I’m busy during the week. It doesn’t need much grunt work, so and older Pi suffice. The outdoor unit is near my housemate’s bedroom window, so a reliable design helps by giving him less interruption.

ESP8266 or Redbear Duo both can achieve the same thing, but I have experienced both crashes in a shorter period than the Pi. Not blaming the hardware, but rather the overall system allowing me to crash it with lousy code. The ESP will also require additional ADC for the thermistors. And I’m not fond of tinkering with C++ code when I do my analysis later. Python works best as I could transfer from Jupyter notebook to python script with little to no modification.

That’s all for this week. I’ve had this sitting in my draft for a while. I recently learnt from Coaching for Leaders that I need to have the “courage to be rubbish”, to keep posting consistently, which is what matters than to make sure everything is perfect. I’ll keep up with posting the next part within the next 2 weeks.

Aircon Monitor – Part 1 – The introduction

This is the first part of a multi-part series about some hardware & software that I hacked together to monitor the AC current of our outdoor inverter aircon unit, which is reporting an overcurrent error.

  • Part 1 – The introduction – Why, what & how (you’re reading this)
  • Part 2 – The hardware – current sensor, thermistor, ADC & Arduino
  • Part 3 – The circuit design – Analog, digital and data flow
  • Part 4 – The firmware – Arduino, RMS calculation & Raspberry Pi’s UART
  • Part 5 – The software – data collection, analysis & decision
  • Part 6 – The solution – still unknown at this stage

Note: I’ll add the links when those posts are published 🙂

The Why

TLDR; I want to learn about inverter fail-safe features.

I and my housemate have started working from home around mid-March 2020, right before the Circuit Breaker measure imposed by the Singapore government. With the hot season coming, we started turning on the aircon after lunch and we noticed that it wasn’t cold, and would switch off after some time with the power indicator blinking, which usually means something is wrong. After cycling the power it will be back on, and maybe cold again or it might take a few more power cycling. We never noticed this before COVID-19 when we only operated the aircon at night.

Thanks to my housemate who did a quick search and found out how to read the error code, E7 – Inverter instantaneous overcurrent (DC output). After calling Daikin, they suspected the compressor and for this older model, it will cost around S$700~800 (USD500~575) with a labor charge of at least S$500 (USD360). They recommend a new unit instead which costs around the same. After speaking to our agent and landlord, we decided that we don’t mind observing for now and continue using it as is.

After some observation, we noticed that if we turn it on earlier in the day before the sun shines on the outdoor unit, or when the day is gloomy, it works immediately, and on a hot day, it will work earlier then shut down afterward. So it has to do with the heat in the outdoor unit.

My understanding of the error is that the controller wasn’t able to start the compressor within the designed current limit. Daikin is known for its good fail-safe design. When the outdoor unit is trying to start, we could hear the fan start, and the compressor tries to start and stop after a few seconds. It will keep trying for a while before giving up and throw us the error code E7.

I had some experience with aircon servicing and know the internal quite well, but this fail-safe feature is new to me, especially around the inverter. So I thought why not I try to monitor the current and temperature to see what’s causing it to stop while learning more about this fail-safe feature.

Aside from that, I have used a non-intrusive current sensor coupled with OpenScopeMZ to help my previous landlord troubleshoot a frequent power trip, which didn’t work as expected. I end up using a Murata power monitor which is intrusive as it requires the mains wire to run through the permanent current loop. This is a good opportunity to learn and get the current sensor working. I’ve also wanted to understand the RMS calculation for continuous current measurement.

Lastly, this gives me a stronger nudge to restart my blog post. I’ve broken it down into smaller posts so it’s less daunting to start. Hopefully, it will keep the blogging wheel turning.

The What

What should I measure? Since it’s overcurrent, the obvious thing is to monitor the AC current. Although the error indicated overcurrent on the DC output, getting that requires tapping into the controller sitting outside, a big no-no since we live on the 14th floor and the outdoor unit is hanging outside the bedroom window with no easy access. AC current is the closest and safest I could get to. I also happened to have a spare clamp style AC current sensor in my parts bin, which allows non-intrusive current measurement.

The next parameter is the temperature, so I know at which level of heat that caused the overcurrent. I have a couple of spare thermistors from my 3D printer, so that’s taken care of.

The How

I’ll be making a custom Arduino shield on veroboard, put it on a Gertduino and Raspberry Pi. I think this is long enough as the introduction. I’ll dive deeper into the How in the next part. If this is interesting, stay tuned for Part 2, which comes next week.

DIY Case for Raspberry Pi

While waiting for a proper Raspberry Pi case from element14 (formerly known as Farnell), I stumble across a site where the author designed a paper case for his Pi and kindly shared it to the world. I gave it a try today, and easily done it in less than 30 minutes.

The design is well done, taking consideration into paper thickness and folding allowance. Bravo!

Migrating transmission-daemon from RT-N16 to Raspberry Pi + Baby Monitor

Lately transmission on my RT-N16 has been acting a little too unreliable. Since I have 2 spare Raspberry Pi sitting in my drawer, I’ve decided to start utilizing them as my Bit Torrent client. At the same time, I’ve had plan to turn the Pi into a baby monitor. Great!!! Since the router is not far from the infant bed, I could setup both on the same Pi.

First thing first, is to get the Pi up and running. I chose to use the default Raspbian image as I’m more familiar with Debian and for maximum compatibility, in case I need to compile any software. I won’t go through the setup as there’s plenty of “Getting Started” tutorial online for the famous Raspberry Pi. Since I need to connect a webcam to it, I was guessing I’ll need at least the X11 desktop as it involved video. Also based on my prior experience in video streaming via VLC, which needs to run in a window. With that in mind, and my plan to run this headless, I’ll need to setup a remote desktop next.

TightVNC is the de facto Remote Desktop package for Debian. After doing a little bit of reading, I found that x11vnc is actually a better choice, as it utilized the existing instance of the desktop powering the display, which means less resource hog. Using TightVNC on Linux would be akin to using RDP in windows, though TightVNC behaves as x11vnc when running in windows. Instruction to setup x11vnc can be found here.

Now it’s time to tackle the video streaming. I was in luck this time, as my Sensonic Webcam 8000 works out-of-box with Raspbian, and I found a good alternative to VLC, motion. Although motion was meant to do motion detection, but it also serve MJPEG via it’s built in web server. After following these instruction, all I need to do is to turn off motion detection and my baby monitor is done, yeah!!! Wait, where’s the audio? Well, since I live in a small house, my wife doesn’t need audio streaming, which allows more resources for my torrent client >-)

The video stream default to http://my_raspberry_pi:8081. Testing it on the desktop works flawlessly, but the opposite when viewed from an Android phone. The default Android browser tries to download the file. It does work on Chrome running on my SGS3, but it’s too heavy to be installed on my wife’s Xperia Mini. I then downloaded a few popular browsers and non of them work with the stream. Later on I found out that MJPEG is not supported oob in Android, bummer. Luckily I found an app called Mjpeg Viewer. Simply key in the URL and “click” Show. Voila! No complicated configuration or lengthy trial and error.

Product Image

Now it’s time to work on my torrent. I ran the Shibby mod of TomotoUSB firmware on my router. It comes with transmission and I’ve downloaded more than 100GB of “stuffs” using this setup, though it has a few glitches which I could bare with, until it time traveled back a month one day. A few of my downloads goes from 100% to less than 20%. Doing a “Verify Local Data” or force recheck is just too taxing for this little 200Mhz CPU, and it crashed transmission repeatedly. Don’t get me wrong, I love this router. It just didn’t do the “extra” that well.

So now I’ll move the “extra” job over to the Pi, with 700MHz CPU, the task of hashing file should be, chestnutty though not peanuts :p. Setting up wasn’t any tougher with these instructions. I only followed the part for transmission and ntfs-3g (Default ntfs driver from the kernel is readonly) and skip the hard drive setup as I’m using my existing torrent drive, a 600GB external hard disk. Automount on Raspbian is helpful too, allowing me to avoid editing the error prone fstab.

To make this copy of transmission recognizing all the previous progress, I need to copy the content of resume and torrents into /var/lib/transmission-daemon/info/. After firing up transmission, it listed all my torrents but all 0% with error “No Data Found”. Weird, so I decided to have a peek into the files inside resume and found that the existing path pointing to the actual file is hardcoded along with some cryptic resume data. I would normally avoid editing hundreds of resume files, but it’s not easy to move the mount point to the expected path, which is /tmp/mnt/Torrent/ while it’s currently mounted at /media/Torrent/. The shortcut to this is to create a shortcut a.k.a symbolic link which I can allow transmission to access all the data via both path.

That only solved 80% of the torrents. What happen to the 20%? It must have been caused by some glitch on transmission with the path pointing to /mnt/Torrent/. Well, another symbolic link to the rescue, and now I have all my torrent back, ready to seed and download. It’s time to go back to the future, by “Verify Local Data”, and sure enough it doesn’t crash this time.

It’s 1am now, time to sleep -_- {zzzzzz

PS:Any veteran linux user would notice a potential problem. No prizes but give it a guess.