Adding data to a CouchDB from Arduino.

Sometimes when using the Arduino to collect data, I need to store this data somewhere. Usually I just send the data over the usb/serial link and then have a python script running on my computer that collects the data and stores it in a database.
But now that I have a ethernet shield for my arduino, I figured I would try to remove one step from that equation.

Some time ago, as part of my work, I looked at different NoSQL databases, and one database caught my eye. Even though it did not fit the problem I had then, CouchDB still intrigued me. I especially liked the cached views and build in map/reduce functionality.

Unlike most other databases, who uses proprietary binary protocols, CouchDB has a simple HTTP RESTful API. This makes it easy to talk to from the arduino.

Lets get started, first we need to initialize the ethernet board:

#include <WProgram.h>
#include <wiring.h>
#include <HardwareSerial.h>
#include <SPI.h>
#include <Ethernet.h>
#include <utility/socket.h>
#include <avr/eeprom.h>

static const uint8_t g_gateway[4] = {0, 0, 0, 0};
static const uint8_t g_subnet[4] = {255, 255, 255, 0};
static const uint8_t g_ip[4] = {192, 168, 1, 170}; // change me!
static const uint8_t g_mac[6] = {0x90, 0xa2, 0xda, 0x00, 0x25, 0x65};

void setup()


I have chosen to stay away from the higher level ethernet api (Server/Client ...), and instead use the lower level W5100 and socket api. This is mainly to avoid the blocking nature of the Client class.

Unfortunately the WIZnet controller does not know its own MAC address, so we have to hardcode it into the source. You can use almost any made up MAC address, but if you have multiple ethernet shields, you must make sure all used MAC addresses are unique. If you look at the backside of the ethernet shield PCB, you will find that the Arduino people have been nice enough to print a unique MAC address on the board.

You will also need to change the ip address, at line 11, to one that matches your local network.

If you have multiple arduinos and ethernet shields, you might want to program a unique IP and MAC address into the arduinos eeprom. On my boards I use the bytes from 0x3f0. Here is a example how how to read the eeprom:
void setup()

  uint8_t ip_mac[4+6];
  eeprom_read_block(ip_mac, (const void*)0x3f0, sizeof(ip_mac));
  if(ip_mac[0] == 255)
    Serial.println("PANIC: missing IP address");
    for(;;) /**/ ;


Next, we have the main loop. This example will read some analog and digital ports and then connect to the CouchDB to store the result in the database called "test1".

#define FD 0
#define DB_NAME "test1"
static const uint8_t g_couchAddr[4] = {192, 168, 1, 1};
static const uint16_t g_couchPort = 5984;
void loop()
  uint32_t nextsampleat = millis();
  uint16_t lasta0;
  uint16_t lasta1;
  uint8_t lastd2;
  bool hassample = false;
    uint32_t now = millis();
      Serial.println("sampling value");
      lasta0 = analogRead(0);
      lasta1 = analogRead(1);
      lastd2 = digitalRead(2);
      hassample = true;
      nextsampleat += 10*1000; // 10 secs;
    uint8_t sockstatus = W5100.readSnSR(FD);
      case STATE_IDLE:
          socket(FD, SnMR::TCP, 1100, 0);
          connect(FD, (uint8_t*)g_couchAddr, g_couchPort);
          netstate = STATE_CONNECTING;
        if(sockstatus == SnSR::ESTABLISHED)
          Serial.println("connected, sending doc");
          char doc[64];
          unsigned doclen = snprintf_P(doc, sizeof(doc),
            PSTR("{\"a0\":%u, \"a1\":%u, \"d2\":%u}"), lasta0, lasta1, lastd2);
          char header[64];
          unsigned headerlen = snprintf_P(header, sizeof(header),
            PSTR("POST /" DB_NAME "/ HTTP/1.0\r\n"));
          send(FD, (const uint8_t*)header, headerlen);
          headerlen = snprintf_P(header, sizeof(header),
            PSTR("Content-Type: application/json\r\n"));
          send(FD, (const uint8_t*)header, headerlen);
          headerlen = snprintf_P(header, sizeof(header),
            PSTR("Content-Length: %u\r\n\r\n"), doclen);
          send(FD, (const uint8_t*)header, headerlen);
          send(FD, (const uint8_t*)doc, doclen);
          netstate = STATE_CLOSE_WAIT;
        else if(sockstatus == SnSR::CLOSED)
          Serial.println("conection failed");
          hassample = false;
          netstate = STATE_IDLE;
      case STATE_CLOSE_WAIT:
        if(sockstatus == SnSR::CLOSE_WAIT || sockstatus == SnSR::CLOSED)
          Serial.println("conection closed");
          // ignoring http reply since we can't deal with db errors anyway.
          hassample = false;
          netstate = STATE_IDLE;

Here is what the code does:

  • line 29+30: the address and port of the CouchDB. You most likely need to change this to match your computers address.
  • line 44-53: every 10 seconds some hardware ports are read, and the result stored away to later transmission to the db.
  • line 55-110: the async network state machine.
  • line 59-65: when a new sample is ready, a connection to the database is opened.
  • line 92-97: if we fail to connect to the database, the sample is thrown away, and the connection will be retried when a new sample is ready.
  • line 73-75: the CouchDB document is created.
  • line 77-86: creation and sending of the HTTP header.
  • line 88: here the CouchDB document is sent to the server.
  • line 92-109: the connection is closed, and we wait for acknowledgment.

When running the code, CouchDB will start to contain documents much like this:
  "_id": "135cfbc9bc4709ba24e4d84b5006ae91",
  "_rev": "1-43e825eaf711e9c7b4aaf4274813d677",
  "a0": 484,
  "a1": 1023,
  "d2": 0

Looks nice and all, but for my project I also need to know when each sample were made. One option is to add a DS1307 real time clock, but since I'm more of a software guy, I choose to let CouchDB add the timestamp.

To insert a timestamp into the document, we use a small javascript snippet called a update hander. A update handler can also add a new document to the database, so we can add and update the document in one database call.

This is the update handler used for my samples, it will create a new document, add a posix timestamp and the 3 samples.
  "updates": {
    "new": "function(doc, req) {
      return [{
        time:(new Date()).getTime()/1000.0, 
        a0:Number(req.form.a0), a1:Number(req.form.a1), d2:Number(req.form.d2)
      }, \"updated\"];
To upload this design document to the database, save it as test1_design.js and use curl:
curl -X PUT http://duff:5984/test1/_design/test -d @test1_design.js

The arduino code must be change slightly to use this new update handler.

Since we are no longer adding the document directly to the database, but calling the update handler, the post URL must be changed to:
#define DB_NAME "/test1/_design/test/_update/new"

We also need to change the HTTP post data from a JSON document to HTTP post arguments:
unsigned doclen = snprintf_P(doc, sizeof(doc), 
  PSTR("a0=%u;a1=%u;d2=%u"), lasta0, lasta1, lastd2);

And at last the HTTP mime type needs to be changed:
headerlen = snprintf_P(header, sizeof(header), 
  PSTR("Content-Type: application/x-www-form-urlencoded\r\n"));

After running this new version, all new documents will have a timestamp:
  "_id": "135cfbc9bc4709ba24e4d84b500ac935",
  "_rev": "1-9d17bbf14ccaac2435deaba4bc1b9ead",
  "time": 1296423519.513,
  "a0": 549,
  "a1": 1023,
  "d2": 0

All we need now is a CouchApp to render graphs of the collected data, but that is beyond my current javascript capabilities :)


NGE101 – Norgo wireless energy meter (part 6)

In the previous posts I showed the bits in the captured frames in the order they were captured and decoded, ie. the first received bit were shown to the left.
When I managed to decode the main payload in the frames, I learned that the frames are send with the least significant bit (lsb) first, so I was actually showing the captured frames in "reverse". This ended up being a bit confusing since binary number are normally shows with the msb at the left, and lsb at the right, so in this post I will show the frames reverse compared to the previous posts, so what looked like:

preamble/header      payload                              checksum
11111010100011001001 110010111110011111010000000000000000 110100111110010
11111010100011001001 000101111110011111010000000000000000 000111100001010
11111010000011001001 00100111111100000000                 111000010110010
11111010000011001001 01100111111100000000                 111001010010000

will now look like this:

checksum        payload                              header/preamble
010011111001011 000000000000000010111110011111010011 10010011000101011111
010100001111000 000000000000000010111110011111101000 10010011000101011111
010011010000111                 00000000111111100100 10010011000001011111
000010010100111                 00000000111111100110 10010011000001011111

The first thing I wanted to figure out, was how the checksum should be calculated, so I started by capturing and looking at thousands of frames to see if I could find a pattern.

Here are a few frame pairs where just the lowest bit in the payload are different:

111010001010001 00000000110010001010 10010011000001011111
110010101000001 00000000110010001011 10010011000001011111

110000011001000 00000000110100010010 10010011000001011111
111000111011000 00000000110100010011 10010011000001011111

010010010001000 00000000110100010110 10010011000001011111
011010110011000 00000000110100010111 10010011000001011111

If you look closely at the checksum, you might notice that the xor of the two checksums in each pair is the same value: 001000100010000.

More frames with just one flipped bit in the payload:

  111111101010010 00000000111110111001 10010011000001011111
^ 101110101110010 00000000111110111011 10010011000001011111
= 010001000100000

  110100001000101 00000000111111001000 10010011000001011111
^ 100101001100101 00000000111111001010 10010011000001011111
= 010001000100000

  100010000111000 00000001000000000000 10010011000001011111
^ 000000001111000 00000001000000000100 10010011000001011111
= 100010001000000

  000110110111001 00000001000000011000 10010011000001011111
^ 100100111111001 00000001000000011100 10010011000001011111
= 100010001000000

After some time I managed to find these patterns:

111110000000001 - payload bit 12
011011010000000 - payload bit 11
001101101000000 - payload bit 10
110110100100000 - payload bit 9
001011000010000 - payload bit 8
100101100001000 - payload bit 7
100010100000100 - payload bit 6
000001000000010 - payload bit 5
100000100000001 - payload bit 4
000100010000000 - payload bit 3
100010001000000 - payload bit 2
010001000100000 - payload bit 1
001000100010000 - payload bit 0
110100000001000 - header bit n
111010000000100 - header bit n-1
011101000000010 - header bit n-2

To me, it looked very much like these xor patterns were generated by a "many-to-many" linear feedback shift register (lfsr), but no matter now much I tried, I could not figure it out.

So to crack the lsfr, I wrote a c++ program that used a genetic algorithm to find the lsfr tabs:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <time.h>
#include <algorithm>
typedef unsigned int uint;
uint patterns[] = {
  0b111110000000001, 0b011011010000000, 0b001101101000000, 0b110110100100000,
  0b001011000010000, 0b100101100001000, 0b100010100000100, 0b000001000000010,
  0b100000100000001, 0b000100010000000, 0b100010001000000, 0b010001000100000,
  0b001000100010000, 0b110100000001000, 0b111010000000100, 0b011101000000010,
static const uint pattern_cnt = (sizeof(patterns)/sizeof(patterns[0]));
uint calcErrors(uint mask[15])
  unsigned errors = 0;
  for(unsigned i=0; i<pattern_cnt-1; i++)
    unsigned ipattern = patterns[i];
    unsigned opattern = patterns[i+1];
    unsigned pattern = ipattern;
    pattern = (pattern>>1);
    for(int biti=0; biti<15; biti++)
        pattern ^= mask[biti];
    errors += __builtin_popcount(pattern^opattern);
  return errors;
struct genome
  uint mask[15];
  uint errors;
  bool operator<(const genome &other) const { return errors<other.errors; }
static const uint POP_SIZE = 10000;
int main()
  static genome population[POP_SIZE];
  for(uint i=0; i<POP_SIZE; i++)
    for(uint j=0; j<15; j++)
      population[i].mask[j] = rand()&0x7fff;
  for(uint generation=0; generation<1000000; generation++)
    for(uint i=0; i<POP_SIZE; i++)
      population[i].errors = calcErrors(population[i].mask);
    // sort genomes, so that the most fit will be in the beginning of the array
    std::sort(population, population+POP_SIZE);
    if(population[0].errors == 0)
      for(uint j=0; j<15; j++) printf("%04x ", population[0].mask[j]);
    static genome newpopulation[POP_SIZE];
    for(uint i=0; i<POP_SIZE; i++)
      uint parent1 = pow(double(rand())/RAND_MAX, 3.0)*POP_SIZE;
      uint parent2 = pow(double(rand())/RAND_MAX, 3.0)*POP_SIZE;
      // produce offspring:
      memcpy(&newpopulation[i], &population[parent1], sizeof(newpopulation[i]));
      for(uint j=0; j<15; j++)
          newpopulation[i].mask[j] = population[parent2].mask[j];
      // mutate offspring
        uint bit = rand()%15;
        uint mask = rand();
        for(int j=0; j<15; j++)
            newpopulation[i].mask[j] ^= 1<<(bit%15);
    memcpy(population, newpopulation, sizeof(population));
   return 0;

It only took the program around 15 seconds to find the correct "taps": 0x4880 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x2080 0x4000 0x4000 0x4000 0x4000 0x4000 0x4000.

To verify that I now had enough information to verify the checksum of captured frames, I wrote another small python script that calculates the checksum for a frame, and checks itagains the checksum in the captured frame:

checksum_taps = (0x4880, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
  0x2080, 0x4000, 0x4000, 0x4000, 0x4000, 0x4000, 0x4000)
def next_mask(mask):
  next_mask = mask>>1
  for i in range(15):
    if mask&(1<<i):
      next_mask ^= checksum_taps[i]
  return next_mask
def verify(checksum, data, datalen):
  mask = 0x0001
  cchecksum = 0
  for i in range(datalen-1, 7, -1):
    mask = next_mask(mask)
    if (data>>i)&1:
      cchecksum ^= mask
  assert checksum == cchecksum
#        |checksum-----|    |payload---------------------------||header----||preamb|
verify(0b010011111001011, 0b00000000000000001011111001111101001110010011000101011111, 36+20)
verify(0b010100001111000, 0b00000000000000001011111001111110100010010011000101011111, 36+20)
verify(0b010011010000111,                 0b0000000011111110010010010011000001011111, 20+20)verify(0b000010010100111,                 0b0000000011111110011010010011000001011111, 20+20

By trial and error, I also managed to find out that the preamble is 8 bits long, and not included in the checksum, so the packages now look like this:

checksum        payload                              header       preamble
010011111001011 000000000000000010111110011111010011 100100110001 01011111
010100001111000 000000000000000010111110011111101000 100100110001 01011111
010011010000111                 00000000111111100100 100100110000 01011111
000010010100111                 00000000111111100110 100100110000 01011111

Now that I can generate frames with correct checksums, I can start sending my own frames to the NG101 receiver and see how it reacts when the different bits are set. This will make it easier to discover what all the bits the the header and payload are used for.
But that will have to wait for another day :)


NGE101 – Norgo wireless energy meter (part 5)

This time, I will take a quick look at the long frames captured from the NGE101. Just like the short frames, they consist of 3 parts; a 20 bit preamble/header, the payload and last, a 15 bit checksum.

preamble/header      payload                              checksum
11111010100011001001 110010111110011111010000000000000000 110100111110010
11111010100011001001 000101111110011111010000000000000000 000111100001010
11111010100011001001 001111111110011111010000000000000000 100111000101011
11111010100011001001 000010000001011111010000000000000000 111000001111000
11111010100011001001 010001000001011111010000000000000000 001001000101100
11111010100011001001 110011000001011111010000000000000000 101011000011000

The payload is an ever increasing value, and when converted to decimal, they are:
000101111110011111010000000000000000 = 780264
001111111110011111010000000000000000 = 780284
000010000001011111010000000000000000 = 780304
010001000001011111010000000000000000 = 780322
110011000001011111010000000000000000 = 780339

The values are the number of times the LED has flashed on my smart meter since I installed the NGE.
Since these frames are send exactly 86 seconds apart, it's easy to calculate the average power usage between two of the samples:
((780284-780264 flashes) / 86.0 s * 3600 s/h)/(1000 flashes/kWh) = 0.837 kW

Here, where I live, we pay around 2 kr/kWh, so if I sustain this usage for a whole day, I would end up paying:
0.837 kW  * 24 h * 2 kr/kWh = 40.19 kr.

Next time, I will take a look at the package headers of both the short and long frames.

NGE101 – Norgo wireless energy meter (part 4)

Now that I have managed to capture some raw data from the NGE101, it's time to decode it.
The NGE sends two types of packages, one that's 55 bits long and another that is 71 bits long.
In this post I will concentrate on the shorted packages.

Here are a few of the thousands of packages collected in the last few days:

11111010000011001001 00100111111100000000 111000010110010
11111010000011001001 01100111111100000000 111001010010000
11111010000011001001 00110111111100000000 111000000111010
11111010000011001001 00000000000010000000 000111000010001
11111010000011001001 10010000000010000000 000101011011101

I have separated the package into 3 "chunks"
  1. the first 20 bits are always the same in every package, it's most likely a preamble, device id, channel and other static data.

  2. the middle 10-15 bits are almost always different, but when looking at thousands of samples, its possible to see that it's a binary value.

  3. the last 15 bits looks like random noise, so it it most likely a checksum.

The middle chunk of bits is the one we want, so I captured a few packages and wrote down the power usage reported by the NGE101 reciever. In the following samples I have removed everything but the middle bits:

captured package             | receiver shows
... 11000011100010000000 ...   0.81
... 01011011111100000000 ...   0.90
... 00000010111100000000 ...   0.94
... 01110000000100000000 ...   1.78
... 10101100001000000000 ...   3.42

It looks like the the least significant bit is to the left, so when decoded we get:

captured | receiver shows
4547       0.81
4058       0.90
3904       0.94
2062       1.78
1077       3.42

Since the captured value and the one shown on the receiver are inversely proportional, we find the factor by multiplying them: 1077 * 3.42 = 3683. This is very close to the number of seconds in an hour, 3600, but not quite.
In a earlier post I speculated that the micro controller in the transmitter was clocked by a 32768 kHz crystal, and based on that speculation, it's likely that the timing code does not use base 10, but base 2. This also simplifies the hardware, since no divisions are necessary as shifts can be used instead.
With that in mind, the 3600 would end up as 3600*1024/1000 = 3686 which is much closer to the derived factor.

Since my smart meter blinks its LED once for every Wh used, it should now be apparent that the number captured from the transmitter is in fact the number of milliseconds (in base2) between two blinks. And to convert from the captured number to power usage we just use this formula:

(3600*1024/1000) / captured_value

In the next post I will take a look at the longer, 71 bit, frames.


NGE101 – Norgo wireless energy meter (part 3)

Before decoding the data from the NGE101, it was necessary to find out the duration of the pulses it sends. To do this I needed a small sketch that could output the exact duration of the received  pulses.

This is the code I came up with, it will print a stream of bits and there durations in microseconds.

uint8_t lastinput = LOW;
uint32_t lastinputat;

void setup()
  pinMode(2, INPUT);
  lastinputat = micros();

void loop()
  uint8_t input = digitalRead(2);
  if(input != lastinput)
    uint32_t now = micros();
    uint32_t dt = now - lastinputat;
    lastinput = input;
    lastinputat = now;
    Serial.print(input, 10);
    Serial.print(' ');
    Serial.println(dt, 10);

The output looks something like this:
1 1068
0 472
1 488
0 416
1 568

The durations were not as consistent as I had hoped they would be, so to get a better idea of what I was dealing with, I wrote a python gui application to graph the durations.

import wx 
import re 
import serial 
import sys 
import time 
import math 

WIN_WIDTH = 590 # pixels 

class TestFrame(wx.Frame): 
  def __init__(self): 
    wx.Frame.__init__(self, None, title='test', size=(WIN_WIDTH, WIN_HEIGHT)) 

    self.line_re = re.compile('([01]) *([0-9]+)') 

    self.ser = serial.Serial('/dev/ttyACM0', 115200*8, timeout=0.000) 
    self.last = None 
    self.recvqueue = '' 
    self.durations = [[0]*WIN_WIDTH, [0]*WIN_WIDTH] 

    self.panel = wx.Panel(self, size=(WIN_WIDTH, WIN_HEIGHT)) 
    self.panel.Bind(wx.EVT_PAINT, self.on_paint) 

    self.timer = wx.Timer(self.panel, 123) 
    wx.EVT_TIMER(self.panel, 123, self.on_timer) 

  def on_paint(self, event): 
    dc = wx.PaintDC(self.panel) 

    dc.SetPen(wx.Pen('red', 1)) 
    dc.DrawLine(0, WIN_HEIGHT/2, WIN_WIDTH, WIN_HEIGHT/2) 
    for i in range(0, WIN_WIDTH, 1): 
      if math.floor(t/0.001) != math.floor((t-DURATION_PER_PIXEL)/0.001): 
        dc.DrawLine(i, 0, i, WIN_HEIGHT) 
      elif math.floor(t/0.0001) != math.floor((t-DURATION_PER_PIXEL)/0.0001): 
        dc.DrawLine(i, WIN_HEIGHT/2-8, i, WIN_HEIGHT/2+8) 

    dc.SetPen(wx.Pen('black', 1)) 
    for i in range(WIN_WIDTH): 
      dc.DrawLine(i, WIN_HEIGHT/2+1, i, WIN_HEIGHT/2+1+self.durations[0][i]) 
      dc.DrawLine(i, WIN_HEIGHT/2-1, i, WIN_HEIGHT/2-1-self.durations[1][i]) 

  def on_timer(self, event): 
    redraw = False 

    while True: 
      line = self.ser.readline() 
      if not line: break 
      m = self.line_re.match(line) 
      if not m: continue 

      bit = int(m.group(1)) 
      duration = float(m.group(2))/1000000.0 
      print bit, duration 

      self.durations[bit][min(int(duration/DURATION_PER_PIXEL), WIN_WIDTH-1)] += 1 
      redraw = True 

    if redraw: 

app = wx.App(False) 
frame = TestFrame() 


The result looked like this. The window covers a durations of 3 milliseconds, so there is a tall vertical line per millisecond.

It's now possible to see that the durations fall into 4 groups:

  • short high pulses (logic level 1) in the range 400-600 milliseconds.

  • short low pulses (logic level 0) in the range 300-500 milliseconds.

  • long high pulses in the range 900-1100 milliseconds.

  • long low pulses in the range 800-1000 milliseconds.

I suspect the difference in timing from the high and low pulses is because the sender has an extremely slow cpu, and it spends a few more cycles when sending a 1 than sending a 0. A bit of goggling suggest that 32.768 kHz is very common speed for low powered embedded micro controllers. At that speed, the time difference (0.15 ms) between high and low pulses are just around 5 cycles.

Visualizing the data as a pulse train, using __, _ for low pulses, and --, - for high pulses, a pattern start to revel itself. Here are 4 bursts of data:




The script used to print these pulse trains:

import serial
import sys
import time
serdev = '/dev/ttyACM0'
ser = serial.Serial(serdev, 115200*8)
def decode(bit, duration):
  if bit==1 and duration>=400 and duration<=600: return '-'
  if bit==1 and duration>=900 and duration<=1100: return '--'
  if bit==0 and duration>=300 and duration<=500: return '_'
  if bit==0 and duration>=800 and duration<=1000: return '__'
  return None
while True:
  line = ser.readline().strip()
  pulse = decode(int(line[0]), int(line[2:]))
  if pulse: sys.stdout.write(pulse)
  else: sys.stdout.write('\n')  sys.stdout.flush()
A examination of the pulse trains reveals that short pulses always come in pairs! This suggest that the data is likely to be Manchester encoded, or more likely Differential Manchester encoded. After applying a differential Manchester decoder to the data, we see some very promising patterns:
(100 ms delay)
(43 s delay)





The data is being send it bursts with around 43 seconds between them. In each burst there are two frames, separated by around 100 ms. As can be seen, every second burst have a longer frame than usual, the other bursts just appear to be repeating the same frame twice. The differential Manchester decoder:
lastshort = False
while True:
  line = ser.readline().strip()
  pulse = decode(int(line[0]), int(line[2:]))
  if pulse in ('_', '-'):
    if lastshort:
    lastshort = not lastshort
  elif pulse in ('__', '--'):
    if lastshort:
      print 'ERROR'
      lastshort = False
    lastshort = False
    sys.stdout.write('\n')  sys.stdout.flush()
That's it for now, next time I will try to make some sense of the newly discovered bits...

NGE101 - Norgo wireless energy meter (part 2)

I want to capture the data from the NGE101 power meter transmitter so that I can later analyze the data, or maybe even send it to Google Powermeter. But first I need to find out how the data is transmitted and encoded.

According to the manual the NGE101 is transmitting the data on 433 MHz, so I dug out an old wireless weather station receiver that I had lost the transmitter for.

Old weather station with 433 MHz receiver.
Even though the weather station was powered by 3V (2 AA batteries) I did not see any components on the receiver PCB that should not be able to handle the 5V from the arduino uno. Its impossible to see in the picture, but the IC on the PCB is a LMV358 op-amp, and its rated for 2.7-5.5V.

The receiver only has three pins, and they are labeled V,R and G. V and G are used for Vcc and Gnd, so by elimination, the R pin must carry the received signal.

When hooking up the receiver to the arduino, I just got a lot of random static, but with some occasional faint hints of something that sounded like bursts of old-school modem noise.

Arduino and the 433 MHz receiver.
Fearing that I might have killed the receiver, I quickly cut the power, and then did what I should have done first; I connected the receiver to the 3.3V pin on the arduino.
Unfortunately the output voltage from the receiver was not high enough for the arduino to detect it, but that was easily fixed by using a 4050 buffer to pull the signal up a bit.

This worked beautifully, I started to get some nice clear data from the arduino. I'm not sure why I got so much noise when it was connected to 5V, maybe there is a lot of digital noise on the 5V power line, maybe its simply not meant to run of that high a voltage.

I wrote a small arduino sketch to capture the signal and output the data as a .au sample. Here is one of the captured data frames:

And here is the source code:

uint32_t nextsampleat = 0;

void setup()
  pinMode(2, INPUT);
  Serial.write((const uint8_t*)".snd", 4); // magic
  Serial.write((const uint8_t*)"\x00\x00\x00\x18", 4); // header size
  Serial.write((const uint8_t*)"\xff\xff\xff\xff", 4); // data size (-1 = unknown)
  Serial.write((const uint8_t*)"\x00\x00\x00\x02", 4); // coding (2 = 8-bit linear PCM)
  Serial.write((const uint8_t*)"\x00\x00\x27\x10", 4); // rate (10kHz)
  Serial.write((const uint8_t*)"\x00\x00\x00\x01", 4); // channels
  nextsampleat = micros();

void loop()
  uint32_t now = micros();
  if(int32_t(now-nextsampleat) &gt;= 0)
    uint8_t input = digitalRead(2):
    nextsampleat += 100;

A small python script that connects to the arduino, and just dumps all incomming data into a file:

import serial, struct
ser = serial.Serial('/dev/ttyACM0', 115200*8)
samplefile = open('sample.au', 'wb')
while True:
  data = ser.read(1)
Next time I will examine how the data is encoded.


NGE101 - Norgo wireless energy meter (part 1)

Norgo NG101 Receiver and transmitter

About a month ago, I bought a NGE101, it's a cool gadget that records and displays how much power a household is using.

It works by counting the light pulses emitted from  digital Smart meters and then transmits that data back to the receiver. According to the manual, it does this once every 45 seconds.

This also means that the device will only with with the new digital smart meters, and not the old "analog" type with a spinning wheel and mechanical counters.

The smart meter that is installed in my apartment blinks a red LED light once for every 1 kW that is used, so by timing the duration between two blinks, it is possible to calculate how much power is being used at any moment.

You can read more about the device here.

Its all nice and good that the NGE101 can show the real time usage, and also the totals for the last 5 hours, 5 weeks and 5 months, but I want more :)

I would really like to collect the real time power usage numbers into a database so that I can graph them over time with a higher resolution that what the NGE101 can do itself.

As a first step I took the receiver apart, mostly because I was curious, but besides a few testing pads and open jumpers, the only real interesting thing I spotted was the dangling ground wire coming out of the receiver PCB. Its not the antenna, as it's just connected to ground and the real antenna can be seen to the far right in the "Guts" image. I don't know a lot about antenna design, but it seem to be strangely placed if it is supposed to be the ground plane for the monopole antenna. Antenna design is apparently really complicated, so who knows :)

Main logic board
Transmitter circuit board
Keyboard circuit board

I hope that the 433 MHz transmitter is using ASK modulation, which is commonly used in wireless weather stations and other one-way cheap wireless devices. And I also happen to have a arduino microcontroller and a 433 MHz receiver module handy, so the next step is to see if I can receive any data from the NG101 transmitter.

But that will have to be another post, another day.


Happy new year!

My one and only new years resolution this year was to get started with blogging.

I'm fairly bad at formulating myself in written form, and if there is one thing that I have learned from playing RPG games, it's that the only way to get better at something is to keep repeating it, again and again :)