Monthly Archives: March 2013

The Rentalito

“Say Hello to The Rentalito!”

That was the first message The Rentalito displayed almost 2 years ago. The Rentalito means something like “small rental monitoring thingy” (free translation from “rental” and “ito”, which is the suffix for “small” in Spanish). It was born to display the rentals in a VOD project my team was working at that time. The Rentalito displayed total rentals, rentals by day and it beeped every time a new rental showed up in the database displaying the movie that was just rented.

The Rentalito at Work

In the beginning it was funny and kind of a party every time it beeped. The time between beeps was quite spaced but it was just the beginning, you know. But as the project went on and the rentals didn’t reach the required pace my team was moved to other projects and shortly after I left the company and The Rentalito came back home with me.

The Rentalito uses two 32×16 RG Dot Matrix displays by SureElectronics. They cost about $32 each on the official store, I bought it on ebay. They use a Holtek HT1632C driver and there are a bunch of libraries (in github, in google code) and examples on using these displays with Arduino. I grabbed one that suited my needs (it works, it’s easy to use, and has scrolling text functionality) and added a couple of functionalities. You can check it out here.

The first version of The Rentalito was based on an Arduino UNO with an Ethernet shield and the display was wired with jumper wires to the shield headers. Quite messy. So every thing was hidden from view with a cardboard (!!) box with a sticker on it designed by the team designer (yeah, it’s a VHS video tape). Everything was held together with a sheet of plywood, some screws and spacers.

The code was not better looking but it worked. The Arduino requested the data to a PHP web application that was running on my laptop, it queried the production database to get the latest data and built a message in a proprietary format that was sent back to the Arduino, there it got parsed and displayed. The server application used a SQLite database to store aggregated data and custom messages that could be scheduled based on date and time (like “Good morning” before 10am or “Today is Einar’s birthday!!” when it was Einar’s birthday). The response could contain more than one message. Each message had title and body (or just body for a full screen message) and some control codes (text color, beep,…). The system worked fine but it was not very flexible.

The Rentalito goes WIFI

In its second life The Rentalito went WIFI. Using a Roving Networks RN-XV module and a custom Arduino shield that had a male header to plug the cable from the display. Tidier.

Rentalito Schematics

Rentalito Schematics

Software side I replaced the Ethernet library with WiFlyHQ by harlequin-tech. The library is really good, easy to use and very configurable but it doesn’t implement the Ethernet Client API so it is not a drop-in replacement for the stock Ethernet library.

The Rentalito goes MQTT!!

The last evolution of The Rentalito has been integrating into my home network as a MQTT client using excellent Nick O’Leary’s PubSubClient library for Arduino. But to make it work  I had to switch to a WIFI library that uses the Ethernet Client API. After testing some existing libraries I chose Sparkfun’s Wifly Shield library, basically because it worked.

Although there are several points for improvement in the code (mainly the ht1632c library) the approach is much more flexible now. The main problem is some ugly incompatibility between the ht1632c library and the WiFly library which causes the connection to hang sometimes when a new message arrives while refreshing the display. It’s probably due to the fact that I am using SoftwareSerial library instead of hardware serial. Anyway, if not using scrolling messages the display works for hours without problems and even if there is a problem there is code to reconnect and keep going. The code is available on github.

On the outside the new version has also seen some changes. I finally got rid of the wooden sheet and then cardboard box replacing them by two sheets of methacrylate which make it look cooler (my opinion at least) and give it  some support to stand over a flat surface.

The Rentalito perspective

The Rentalito perspective

The Rentalito close view

The Rentalito close view

The Rentalito displaying the current power consumption

The Rentalito displaying the current power consumption

The Rentalito has suffered different metamorphosis for the past months and I am sure this won’t be it’s last reincarnation.

Door sensor

UPDATE: check my post about my new Moteino based door monitor.

In the past I’ve been monitoring my home door with an IP camera and the motion software in my server. Whenever something was moving in the camera range the server saves a little footage, takes a snapshot and calls a couple of scripts I use to send notifications via NMA and email.

The problem with this set up was that it had lots of false positives. Mainly due to shadows or changes in the luminosity when someone opened or closed a door in the corridor that leads to the front door. Playing with the software configuration (sensitivity, zone patterns, trying to remove luminosity bursts,…) made no significant difference. Some days 80% of the alerts were due to this type of events, and then the whole system becomes useless because you stop checking the notifications…

Continue reading

Decoding 433MHz RF data from wireless switches. The data

[UPDATE 2013-03-01] I have added links to the encoder chips these two remote use and removed some miss-assumptions for the Noru remotes. The explanation now is simpler, but the main questions about the Noru codes remain.

In my previous post I explained how I decoded the data from two wireless outlet remotes using a couple of libraries for Arduino and a Bus Pirate in logic analyser mode. Now I want to go more in-depth, showing the captures from OLS and the data I obtained.

A bit of theory

Just a little bit. These remotes send the information using a common type of modulation called Amplitude-Shift Keying (ASK). This is the digital equivalent to the Amplitude Modulation (AM) used in long distance radio broadcast. The information is encoded as an increase or decrease in the amplitude of a carrier wave of (in this case) 433.92MHz. The information itself is sent at lower frequencies (some tens of KHz).

Since ASK is meant for digital communications, the information itself is encoded as a stream of 0’s and 1’s. A pattern of 0’s and 1’s define a “state”. The remotes like the Avidsen I have use 3 different states, code bits or tribits. They all begin with a high pulse (a 1) and end with a low pulse (a 0). The next image shows the pattern for these 3 states:

Tribits

Note that you can speak these patterns in different ways: as a succession of pulse lengths, like “short long short long” or “1313” (the long pulses are three times longer that the short ones) for the tri-bit 0, or as a tuple of bits like “00” (1 for a long high, 0 for a short high).

Now, the full signal is a series of code bits, a code word. 12 for the two remotes I have checked. These 12 code bits can be writen down as “11111FF0FFF0” (this is the ON command for outlet C in channel 31 for the Avidsen remotes).

Since the tribits are, well, 3-state bits, you can think of the previous code as a base-3 number, where the ‘F’ is a ‘2’: 111112202220. the RemoteSwitch library has a method that accepts the decimal equivalent for this base-3 number, with in this case is (read back-wards, the least significative bit is the rightmost one):

0*3^0 + 2*3^1 + 2*3^2 + 2*3^3 +
0*3^4 + 2*3^5 + 2*3^6 + 1*3^7 +
1*3^8 + 1*3^9 + 1*3^10 + 1*3^11 = 266649

But this number is just a convenience and we are moving away from the actual signal representation.

Avidsen remote

These remotes use the PT2262 parallel to serial encoder (datasheet). These chips have 12 parallel input lines you can individually set to HIGH, LOW o leave them floating for the three different states or tri-bits. When the input lines are set you assert low the TE pin and the data is encoded and output through the DOUT pin. They are supported by existing Arduino libraries (more or less, see the patch for the RCSwitch library in my previous post). The code word is a stream of 12 tribits arranged this way:

  • The first set of 5 are the channel (the one you configure in the dip switch of the remotes and the outlets). This is a value from 0 to 31 which is actually encoded in binary where the tribit 1 represents a 1 and the tribit F represents a 0.
  • The second set of 5 tribits is the outlet identification you configure in the second set of 5 dip switches of each outlet. All the tribits in this set must be set to F except for one, which represents the outlet selection in the remote from A to E.
  • The last set of 2 tribits represent the action, and it can be “F0” for ON, or “0F” for OFF.

Now, some captures.

Channel 00, Outlet A ON - FFFFF0FFFFF0

Channel 00, Outlet A, ON – FFFFF0FFFFF0

Channel 31, Outlet C ON - 11111FF0FFF0

Channel 31, Outlet C ON – 11111FF0FFF0

Channel 31, Outlet A OFF - 111110FFFF0F

Channel 31, Outlet A OFF – 111110FFFF0F


With these information you can actually control up to 32*5=160 different outlets from your favourite microcontroller.

Noru remote

This remote uses the HS1527 programmable encoder (datasheet). These chips have a hardcoded preamble of 20 bits (normal 0/1 bits) and 4 data lines to set 4 data bits. The total length of the message is the 24 bits. Mind these are normal bits: 0 is encoded as a short high pulse followed by a long low one whilst 1 is encoded as a long high pulse followed by a short low one.

The message length is thus the same as in the previous remote but it is not 100% compatible with the Arduino libraries since you can encode a forth combination of highs and lows, a fourth state or tetra-bit mimicking the naming convention:

Tetrabits

The codes for the 14 buttons of the Noru remote are (in binary format and tetra-bit format):

Button Binary Tetrabits
ON1 110100000000001101011000 1F000001FFX0
OFF1 110100000000001101010110 1F000001FFFX
SET1 110100000000001101011101 1F000001FF1F
ON2 110100000000001101011100 1F000001FF10
OFF2 110100000000001101010100 1F000001FFF0
SET2 110100000000001101011011 1F000001FFX1
ON3 110100000000001101011010 1F000001FFXX
OFF3 110100000000001101010010 1F000001FF0X
SET3 110100000000001101011110 1F000001FF1X
1H 110100000000001101011001 1F000001FFXF
2H 110100000000001101010111 1F000001FFF1
4H 110100000000001101010011 1F000001FF01
8H 110100000000001101010001 1F000001FF0F
ALL OFF 110100000000001101010101 1F000001FFFF

As you can see the first 20 bits are always de same. It’s the identification hardcoded in the HS1527. Only the four rightmost bits change. There are 16 possible combinations and 14 are being used by the 14 buttons (only the 00 and 11 endings are missing from the table). But, is there any pattern in this 4 bits?

There are some clues to start working with:

  • Some codes are common for all the outlets (the timeouts and the ALL OFF button)
  • Some codes are specific for a certain outlet (ON, OFF and SET)
  • When you start using an outlet you first have to set it in learning mode and press the ON button in the remote for the number you want to assign to it. From then on the outlet will start responding to that button, but also to the OFF and SET buttons for the same number. So there has to be some pattern that links ON, OFF and SET buttons for the same outlet.
  • According to the documentation an outlet can learn more than one code. The same code can be linked to more than one outlet and one outlet can respond to more than one code. I don’t know if this is somewhat useful to figure out the pattern but it’s cool!

Some captures for a couple of Nero remote signals and enough for now.

Outlet 1 ON - 1F000001FFX0

Outlet 1 ON – 1F000001FFX0

Outlet 2 SET - 1F000001FFX1

Outlet 2 SET – 1F000001FFX1