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.