My house is equipped with an Itron remote read electric meter. This is a fancy digital electric utility meter that broadcasts it's usage information so the meter guys can just drive around to get usage information for billing. I'd like to track my usage but there isn't an easy way to read the meter electronically, since it is digital it does not have one of those spinning wheels with the index mark on it, just an array of 7 segment LCD numbers and three little dots flashing at the bottom. The dots indicate usage, but are too far under the protective glass housing to read optically (well, they could be read that way, but I'm trying to avoid it). It also has an IR LED that flashes once for each watt-hour consumed. See below for more details on that.
Most of the below is from some research I did a year ago and posted to Mark Turner's blog. I'm republishing it here so I know I can find it again.
I’ve been doing some research on the meter in an attempt to avoid having to install a cheap wireless camera over the meter to OCR the images :D.
Itron makes a number of EMT modules for AMR purposes and I’m guessing that they all use pretty much the same protocol (that makes it easier to sell more stuff and easier to develop new products for the same line). The modules can be integrated with old style meters to retrofit AMR capability to old equipment or it can be installed as a plug-in module to electronic meters (and of course Itron sells their own meters as well, I’ve got the Centron CS1R model). The CS1R/R300 IDM meters presumably either use the 5xESS ERT modules or a built-in version of the same thing. Thus a utility using, e.g. GE meters with 52ESS ERT modules could also buy Centron CS1R meters from Itron and use all the same remote-read equipment.
The literature all touts the Spread Spectrum radio feature, and that generally means some flavor of frequency hopping where bits or chips of the message are transmitted across multiple frequencies and the entire message is not available on any one frequency. Itron seems to keep this information secret though, so their competitors don’t set up to read it (except where the FTC forced them to give a license to Neptune as a anti-anti-competitive measure).
Update: It isn't secret, US Patent 4,799,059 has all the details.
The thing is, I don’t think they are doing anything particularly fancy to get that spread spectrum label. The primary consideration is not security (anybody can walk up to the meter, and its just utility usage data anyway) but reliability. AMR technology is there to save money, and hard-to-read meters cost more. Also, I suspect the ’spread spectrum’ is in the sales literature to look fancy and sound impressive, not to tell us they are using a fancy PN frequency hopping routine to secure the information.
Here are some bits I’ve scrounged up:
“The ERT meter module can be programmed to communicate in either wake-up or bubble-up mode. When used in wake-up mode, it waits for a wake-up signal over a radio frequency and then automatically transmits the meter data to the appropriate meter-reading device. In bubble-up mode, a constant stream of data is transmitted for interception, by the receiving unit, and no FCC license is required. This data includes the meter ID number, registration, and tamper detection information. The RF transmission lasts less than one second and contains eight identical data packets, each at a different frequency. The modules can be read by DataCommand, DataPac and Mobile Collection Systems as well as the G5R handheld and the fixed base MicroNetwork.”
“When programming the 53ESS ERT, customers [utility companies] can select any three payloads from the available list. The 53ESS ERT transmits this data back to the Itron meter reading software via three standard consumption messages (SCMs). Each SCM contains a payload data value, an ERT ID, and counters providing tamper and/or other meter related information.”
“Two counters in each of the SCMs provide a total of six unique status indicators that provide important information about site conditions, including detection of possible tampering.
SCM1 Counter1 Meter has been inverted
SCM1 Counter2 Meter has been removed
SCM2 Counter3 Meter detected a button–press demand reset
SCM2 Counter4 Meter has a low-battery/end–of–calendar warning
SCM3 Counter5 Meter has an error or a warning that can affect billing
SCM3 Counter6 Meter has a warning that may or may not require a site visit, depending on utility practice (for example, reverse energy flow warning)”
One of the important tidbits there is this “The RF transmission lasts less than one second and contains eight identical data packets, each at a different frequency.”
It sounds to me like they are transmitting the exact same, complete message on 8 independent frequencies spread across the spectrum (thus, “spread spectrum” in the sales literature). I would not be surprised at all if this is really just 8 redundant OOK broadcasts at different frequencies. This would be consistent with the two driving principles, avoiding interference and keeping the cost low.
Update: According to the patent this seems to be correct:
The data sounds like it consists of 3 SCM messages, each containing bits representing the payload, the ERT and the counters. The payload for each SCM is configurable. The 3 SCM’s comprise a single data packet and are transmitted in under one second, probably with at least (IIRC) 15 seconds between them (in compliance with FCC Part 15 sub C).
In bubble-up (1 way) mode you’d receive the broadcasts constantly. In wake-up (also referred to as 1.5 way) mode the reader has to chirp some kind of wake up message to get the meter to broadcast. I didn’t find any information about the reader’s wake up broadcast, but there might be some clues in the FCC’s documentation:
EO9DCPN2 Meter Reading Transmitter
EWQ90F2482517-410 Meter Reader/Programmer
EWQ90F2482517E Utility Meter Transceiver
EWQ90F6482517-R Utility Meter Transceiver
If it is confirmed that the meter is transmitting a basic OOK/FSK message as I suspect, it shouldn’t be a huge leap to work out the signaling protocol (probably also a standard scheme). Determining how the checksum works could be more difficult, but for stationary monitoring I can get a way without it. They might also ‘encrypt’ the data, but since we know the KWH used at the time of transmission at least that part of the data should be recoverable (presuming a simple scrambling system).
Update: The CRC is also published:
Here is an index of some relevant patents:
http://www.patentstorm.us/assignees/Itron,_Inc_-52765-1.html
This one is very relevant:
“Communication Protocol for remote data generating stations”
http://www.patentstorm.us/patents/5673252-description.html
In particular the description of the Network Service Module (NSM) is useful.
Also “Frequency Hopping Spread Spectrum system with high sensitivity tracking and syncronization”, which describes the details of how the SS system works:
http://www.patentstorm.us/patents/6934316-description.html
I haven’t finished reading it all, but what I understand is that the receiver starts out in a wideband receive mode to pick out the transmitter’s preamble. Evidently the transmitter and receiver don’t have a predetermined channel hopping pattern, the transmitter hops around however it wishes and the receiver does it’s best to find the signal. When the first part (34 chips of Manchester coded bitstream) of the preamble is found an FFT is run to cut the 7Mhz spectrum into 32 channels which it watches for the remaining 6 chips. These chips show up most strongly in one of the channels, or bins, identifying the narrowband frequency the transmitter is using. The receiver then tunes and syncs a narrowband receiver to that frequency to pick up the packet data. If the signal strength is high enough to receive the data in wideband mode it doesn’t bother switching to narrowband mode.
I think that part is particularly interesting. Because I'm interested in reading only one nearby meter I can ignore the whole frequency hopping part and use a wideband receiver with low selectivity. Since each packet is transmitted 8 times across the spectrum the band doesn’t even have to be very wide, I’ll be likely to pick up enough data with a simple receiver, even if some of the packets and broadcasts are missed.
Some information about the mode used:
Other Itron patents describe the data content of the packets and the length (about 100mS, 8 of which then take “under one second”). So, I think this project can be done without too much trouble.
I confirmed with the Itron rep that works with my power company that my meter operates in bubble-up mode, so I know that the data is there, I just need to set up a receiver to look for it.
This document says that the 53ESS ERT operates in the 900MHz band:
And I found this, which should be helpful in decoding the data, in a WIPO document:
An MRX-005 or MRX-505 might be used to pick it up. It receives at 915MHz. Since the transmitter sends 8 copies of the data, randomly distributed across the 912-918 MHz band, at least one of the transmissions should be easily within the bandwidth of the receiver (that's the point of sending it 8 times, after all). At $14 (receiver) or $25 (transceiver) they are cheap enough to try out.
Just for grins I set up my FT-8800 to scan the band from 912 to 913MHz. I set the squelch well above the background noise and listened for a while. It did occasionally pick up something and stop, but the transmissions are too short to catch. Scanning sections above 930MHz didn't turn up any noise, so it could be that it was picking up the SCM transmissions.
Update : 2008-09-22
I ordered the MRX-005S from Digikey on Friday and it arrived today, Monday. This is a nice all-in-one OOK receiver. It operates from 902-928 MHz and the ERT should be transmitting, as above, between 912 and 918 MHz.
It's simple enough to power up and doesn't require any tuning, so hopefully I can stick the scope on it and take it out to the meter and see if I can pick up some data. If that works it'll just be a matter of piping the data into an AVR, then sending it out the com port to the computer for decoding.
I also found in the documentation that the meter has a simple IR port on it that flashes once per watt-hour, much like the little three dot display on the front. This would be useful for a simple power usage monitor where the usage numbers where not important. For example this indicator could be used as the input to a rate display located somewhere in the house. On example of this that I've read about as a possibility would be a wall sconce that glows green below a certain usage rate and then fades up through various shades until it gets to red above a certain rate. Another option might be vernier-type display. Such display systems would provide immediate and constant feedback for occupants who could then become more aware of how their actions caused power consumption to increase or decrease.
The IR port is located on the top of the meter:
As usual with IR LEDs, you can see the IR light with a CCD, such as a video camera. The flashes are very brief though, so they don't show up very brightly on the video:
The camera frame rate is not synchronized/locked with the led, so it's likely that the video doesn't catch all the flashes or even all of the individual flashes. However, it appears to get most of them as the rate in the video matches pretty close to what was displayed on the front of the meter at the time.
Update 2008-10-1
I dug out my Atmel Butterfly and started setting it up for this project. I bought it a couple years ago and never got around to doing anything with it. Since my STK200 development kit is so old now most of the current development tools don't support it easily. Since I like things to be easy I'm going to see if I can get the Butterfly working as a development platform instead. Once I get the code all working I'll transfer it to one of my older chips, or maybe to anArduino Mini, those are popular and I'd like to play with one.
Update 2009-Jan-20
Well, getting out the Butterfly has kind of set this project back. I ended up getting sidetracked onto making the Butterfly work with the Arduino IDE (see the Butteruino on Google Code). This has ended up sucking up a great many hours. At this point it's working fairly well but could use some more work to pretty it up. I'm going to try to switch back to this project now.
The next step is to see if I can get Timer2 on the Butterfly set up to read the input data from the RF module. Even running at the Butterfly's max clock of 8MHz doesn't leave a lot of time to process the incoming bitstream. It looks like it won't be a problem, but there won't be a lot of time to waste. It's tempting to move up to a 20MHz device, but I suppose I should keep it cheap so I can put it on one of my 2313's.
Update 2009-Jun-20
I've found that I like working with Arduino, so I recently put together a couple of iDuino boards. These are Arduino-compatible boards with a Mega168 running at 16MHz and an onboard FT232 for USB to RS-232 conversion. They are just under an inch wide and have downward-facing headers so they can be plugged into a solderless breadboard. I really like this board, I'd certainly recommend it if you prototype on solderless breadboard and use Arduino.
I was somewhat annoyed to find that the MRX-005 module's pins are not on 1/10 inch centers, so it cannot be plugged directly into a breadboard. Fortunately, while it has a lot of pins only a few actually need to be connected. I have it inverted on my breadboard, dead-bug style, with jumpers wrapped around the legs.
Yeah, it's a messy hack, but it's just a prototype. I attached a few feet of antenna and was able to capture some data.
The transitions aren't as sharp as I'd like to see, but it should easily be clean enough to decode.
I've also writen some C# code for parsing data samples from the OpenAMR project into graphable data. Hopefully the data from my Itron meter will be the same as that data. My library is smart enough to handle different kinds of data input, but I don't want to have to figure out what the fields in this data are.
Next step is to do some research about how to go about decoding this Manchester encoded bitstream on the AVR. I could invent something, but that would be dumb, this wheel has been invented many times.
Update 2009-July-7
I've made a bit more progress over the last couple of weeks. The next step was to impliment an Manchester decoder on the Arduino. I poked around on the Arduino site a bit, but didn't find anything immediately useful. Greg Hancock's brief OpenAMR page on Manchester coding mentions that he is using the scheme that happens to be published in US Patent 5,200,980 "Digital Bi-Phase Data Recovery System" by Dennis M. Briddell. That sounded like a good place to start, so I implemented it in an Arduino sketch (I'll move it to a library once it is all debugged).
While testing I found that the radio module doesn't output a clean logic signal, instead it provides an analog mess which doesn't work very well with the edge triggered interrupt on the AVR. I thought it would be good to clean it up by running it through a Schmitt trigger, but I don't have any and I don't want to pay shipping on only a few chips. It turns out that you can configure a 555 as an inverting Schmitt triggered buffer with no external parts, and it's easily fast enough to handle the 30uS signals from the meter datastream.
For testing purposes I assembled a second iDuino board and set it up to output some test data in Manchester format (sending it sure is a lot easier than receiving it!). The receiver appears to mostly work with the simple test data packets I'm sending, but I get occasional glitches. Even if I can't work those out it won't be much of an issue since the AMR data is retransmitted many times.
I think for the next step I will improve the code on the second iDuino to provide more realistic sample data. Currently the data rate is much lower (1mS chips instead of 30uS) and the data frames are only 4 bytes. I'll use some of the 92 byte sample data from the OpenAMR project, that should let me prove out the decoding routines without the unknown factors in the data from the radio module. Once I've got that working I'll switch back to the radio module and see if I can decode some actual data.
Update 2012-July-12
Here is the above-mentioned sample of the AMR data, in image format. See the comments below for C# code that defines the field layout.
I haven't been doing anything much with this project over the past few years (lots of other stuff going on, including building up the Omaha Maker Group), but I recently obtained one of the new RTL-SDR USB devices that I thought might make this project really easy. I'll see if I can get some data captures with it.
Update 2014-July-17
The RTL-SDR captures the AMR broadcasts very nicely. I placed the antenna directly on top of the transmitter and captured a few transmissions. It's also easy to see broadcasts from other meters in the vicinity.
Recording the incoming data to a wav file produces about what you'd expect:
Looks just like the scope trace. I'm using SDRSharp which supports plugins, so I'm going to look into writing a decoder plugin. The option to record and reply signals with SDRSharp will make debugging quite a bit simpler.
Most of the below is from some research I did a year ago and posted to Mark Turner's blog. I'm republishing it here so I know I can find it again.
I’ve been doing some research on the meter in an attempt to avoid having to install a cheap wireless camera over the meter to OCR the images :D.
Itron makes a number of EMT modules for AMR purposes and I’m guessing that they all use pretty much the same protocol (that makes it easier to sell more stuff and easier to develop new products for the same line). The modules can be integrated with old style meters to retrofit AMR capability to old equipment or it can be installed as a plug-in module to electronic meters (and of course Itron sells their own meters as well, I’ve got the Centron CS1R model). The CS1R/R300 IDM meters presumably either use the 5xESS ERT modules or a built-in version of the same thing. Thus a utility using, e.g. GE meters with 52ESS ERT modules could also buy Centron CS1R meters from Itron and use all the same remote-read equipment.
The literature all touts the Spread Spectrum radio feature, and that generally means some flavor of frequency hopping where bits or chips of the message are transmitted across multiple frequencies and the entire message is not available on any one frequency. Itron seems to keep this information secret though, so their competitors don’t set up to read it (except where the FTC forced them to give a license to Neptune as a anti-anti-competitive measure).
Update: It isn't secret, US Patent 4,799,059 has all the details.
The thing is, I don’t think they are doing anything particularly fancy to get that spread spectrum label. The primary consideration is not security (anybody can walk up to the meter, and its just utility usage data anyway) but reliability. AMR technology is there to save money, and hard-to-read meters cost more. Also, I suspect the ’spread spectrum’ is in the sales literature to look fancy and sound impressive, not to tell us they are using a fancy PN frequency hopping routine to secure the information.
Here are some bits I’ve scrounged up:
“The ERT meter module can be programmed to communicate in either wake-up or bubble-up mode. When used in wake-up mode, it waits for a wake-up signal over a radio frequency and then automatically transmits the meter data to the appropriate meter-reading device. In bubble-up mode, a constant stream of data is transmitted for interception, by the receiving unit, and no FCC license is required. This data includes the meter ID number, registration, and tamper detection information. The RF transmission lasts less than one second and contains eight identical data packets, each at a different frequency. The modules can be read by DataCommand, DataPac and Mobile Collection Systems as well as the G5R handheld and the fixed base MicroNetwork.”
“When programming the 53ESS ERT, customers [utility companies] can select any three payloads from the available list. The 53ESS ERT transmits this data back to the Itron meter reading software via three standard consumption messages (SCMs). Each SCM contains a payload data value, an ERT ID, and counters providing tamper and/or other meter related information.”
“Two counters in each of the SCMs provide a total of six unique status indicators that provide important information about site conditions, including detection of possible tampering.
SCM1 Counter1 Meter has been inverted
SCM1 Counter2 Meter has been removed
SCM2 Counter3 Meter detected a button–press demand reset
SCM2 Counter4 Meter has a low-battery/end–of–calendar warning
SCM3 Counter5 Meter has an error or a warning that can affect billing
SCM3 Counter6 Meter has a warning that may or may not require a site visit, depending on utility practice (for example, reverse energy flow warning)”
One of the important tidbits there is this “The RF transmission lasts less than one second and contains eight identical data packets, each at a different frequency.”
It sounds to me like they are transmitting the exact same, complete message on 8 independent frequencies spread across the spectrum (thus, “spread spectrum” in the sales literature). I would not be surprised at all if this is really just 8 redundant OOK broadcasts at different frequencies. This would be consistent with the two driving principles, avoiding interference and keeping the cost low.
Update: According to the patent this seems to be correct:
the Manchester encoded bit stream forming transponder information packet 42 is used to on-off key (OOK) the carrier signal.
Each transponder information packet 42 of transponder signal 40 is
transmitted at a pseudorandom frequency (i.e., a pseudorandom carrier
frequency) within a predetermined range of frequencies. In one
embodiment, transponder information packets 42 are transmitted at
frequencies ranging from 912 MHz to 918 MHz.
The data sounds like it consists of 3 SCM messages, each containing bits representing the payload, the ERT and the counters. The payload for each SCM is configurable. The 3 SCM’s comprise a single data packet and are transmitted in under one second, probably with at least (IIRC) 15 seconds between them (in compliance with FCC Part 15 sub C).
In bubble-up (1 way) mode you’d receive the broadcasts constantly. In wake-up (also referred to as 1.5 way) mode the reader has to chirp some kind of wake up message to get the meter to broadcast. I didn’t find any information about the reader’s wake up broadcast, but there might be some clues in the FCC’s documentation:
EO9DCPN2 Meter Reading Transmitter
EWQ90F2482517-410 Meter Reader/Programmer
EWQ90F2482517E Utility Meter Transceiver
EWQ90F6482517-R Utility Meter Transceiver
If it is confirmed that the meter is transmitting a basic OOK/FSK message as I suspect, it shouldn’t be a huge leap to work out the signaling protocol (probably also a standard scheme). Determining how the checksum works could be more difficult, but for stationary monitoring I can get a way without it. They might also ‘encrypt’ the data, but since we know the KWH used at the time of transmission at least that part of the data should be recoverable (presuming a simple scrambling system).
Update: The CRC is also published:
In one preferred embodiment, BCH encoder 104 produces a BCH errorI’ve emailed both my power company and Itron about reading the meter myself. Both were very friendly. The Basic DOS-based meter reader is available if you want to buy it, but at a bit over 5 kilobucks it’s not a viable solution (unless you can get your utility company to sell you any broken readers at a substantial discount).
control code constructed of a shortened 255, 239, 2 code Galois field
generated by the following polynomial: P(X)=1+X+X 5 +X 6 +X 8 +X 9 +X 10 +X 11 +X 13 +X 14 +X 16 .
Here is an index of some relevant patents:
http://www.patentstorm.us/assignees/Itron,_Inc_-52765-1.html
This one is very relevant:
“Communication Protocol for remote data generating stations”
http://www.patentstorm.us/patents/5673252-description.html
In particular the description of the Network Service Module (NSM) is useful.
Also “Frequency Hopping Spread Spectrum system with high sensitivity tracking and syncronization”, which describes the details of how the SS system works:
http://www.patentstorm.us/patents/6934316-description.html
I haven’t finished reading it all, but what I understand is that the receiver starts out in a wideband receive mode to pick out the transmitter’s preamble. Evidently the transmitter and receiver don’t have a predetermined channel hopping pattern, the transmitter hops around however it wishes and the receiver does it’s best to find the signal. When the first part (34 chips of Manchester coded bitstream) of the preamble is found an FFT is run to cut the 7Mhz spectrum into 32 channels which it watches for the remaining 6 chips. These chips show up most strongly in one of the channels, or bins, identifying the narrowband frequency the transmitter is using. The receiver then tunes and syncs a narrowband receiver to that frequency to pick up the packet data. If the signal strength is high enough to receive the data in wideband mode it doesn’t bother switching to narrowband mode.
I think that part is particularly interesting. Because I'm interested in reading only one nearby meter I can ignore the whole frequency hopping part and use a wideband receiver with low selectivity. Since each packet is transmitted 8 times across the spectrum the band doesn’t even have to be very wide, I’ll be likely to pick up enough data with a simple receiver, even if some of the packets and broadcasts are missed.
Some information about the mode used:
- The transmitter uses Manchester coding: “the preamble 32 of the packet 30 consists of 20 bits plus one sync bit. This data is Manchester encoded so we have 42 “chips” (i.e. transition states) possible to correlate on. The first 34 chips are used to correlate on and the last 6 to determine the best bin for data decoding.”
- The narrowband data is OOK : “In a preferred embodiment, the encoded data of the packet 30 is on-off keyed (OOK) modulated.”
- Eight duplicate packets are sent, each entirely on a single channel: “A typical end point transmitter will respond to a valid wake-up with eight packets, which will be sent at slightly different frequencies”
- The wake-up tone, if it is used, is a simple flag signal and encodes no data: “end-point modules, even those that normally operate in a bubble-up fashion, respond to a wake-up tone, which is a proper frequency carrier modulated at the programmed wake-up tone.”
- “end point transmitters provide the capability to select a wide range of wake-up frequencies (952-956 MHz) and wake-up tones (28-62 Hz)”
Other Itron patents describe the data content of the packets and the length (about 100mS, 8 of which then take “under one second”). So, I think this project can be done without too much trouble.
I confirmed with the Itron rep that works with my power company that my meter operates in bubble-up mode, so I know that the data is there, I just need to set up a receiver to look for it.
This document says that the 53ESS ERT operates in the 900MHz band:
53ESS ERT Specifications:
• Transmit frequency: 910 MHz to 920 MHz
And I found this, which should be helpful in decoding the data, in a WIPO document:
An example of a SCM format is illustrated in FIG. 3 A. e.g., 21 -bit preamble field followed by 2 ID bits, 1 spare bit, 2 physical tamper bits, 4 endpoint type bits, 2 encoder tamper bits, 24 consumption data bits, 24 ID bits, 16 CRC checksum bits (this can also be found in U.S. Patent No. 4,799,059, which describes the ERT packet in detail)
An MRX-005 or MRX-505 might be used to pick it up. It receives at 915MHz. Since the transmitter sends 8 copies of the data, randomly distributed across the 912-918 MHz band, at least one of the transmissions should be easily within the bandwidth of the receiver (that's the point of sending it 8 times, after all). At $14 (receiver) or $25 (transceiver) they are cheap enough to try out.
Just for grins I set up my FT-8800 to scan the band from 912 to 913MHz. I set the squelch well above the background noise and listened for a while. It did occasionally pick up something and stop, but the transmissions are too short to catch. Scanning sections above 930MHz didn't turn up any noise, so it could be that it was picking up the SCM transmissions.
Update : 2008-09-22
I ordered the MRX-005S from Digikey on Friday and it arrived today, Monday. This is a nice all-in-one OOK receiver. It operates from 902-928 MHz and the ERT should be transmitting, as above, between 912 and 918 MHz.
It's simple enough to power up and doesn't require any tuning, so hopefully I can stick the scope on it and take it out to the meter and see if I can pick up some data. If that works it'll just be a matter of piping the data into an AVR, then sending it out the com port to the computer for decoding.
I also found in the documentation that the meter has a simple IR port on it that flashes once per watt-hour, much like the little three dot display on the front. This would be useful for a simple power usage monitor where the usage numbers where not important. For example this indicator could be used as the input to a rate display located somewhere in the house. On example of this that I've read about as a possibility would be a wall sconce that glows green below a certain usage rate and then fades up through various shades until it gets to red above a certain rate. Another option might be vernier-type display. Such display systems would provide immediate and constant feedback for occupants who could then become more aware of how their actions caused power consumption to increase or decrease.
The IR port is located on the top of the meter:
As usual with IR LEDs, you can see the IR light with a CCD, such as a video camera. The flashes are very brief though, so they don't show up very brightly on the video:
The camera frame rate is not synchronized/locked with the led, so it's likely that the video doesn't catch all the flashes or even all of the individual flashes. However, it appears to get most of them as the rate in the video matches pretty close to what was displayed on the front of the meter at the time.
Update 2008-10-1
I dug out my Atmel Butterfly and started setting it up for this project. I bought it a couple years ago and never got around to doing anything with it. Since my STK200 development kit is so old now most of the current development tools don't support it easily. Since I like things to be easy I'm going to see if I can get the Butterfly working as a development platform instead. Once I get the code all working I'll transfer it to one of my older chips, or maybe to anArduino Mini, those are popular and I'd like to play with one.
Update 2009-Jan-20
Well, getting out the Butterfly has kind of set this project back. I ended up getting sidetracked onto making the Butterfly work with the Arduino IDE (see the Butteruino on Google Code). This has ended up sucking up a great many hours. At this point it's working fairly well but could use some more work to pretty it up. I'm going to try to switch back to this project now.
The next step is to see if I can get Timer2 on the Butterfly set up to read the input data from the RF module. Even running at the Butterfly's max clock of 8MHz doesn't leave a lot of time to process the incoming bitstream. It looks like it won't be a problem, but there won't be a lot of time to waste. It's tempting to move up to a 20MHz device, but I suppose I should keep it cheap so I can put it on one of my 2313's.
Update 2009-Jun-20
I've found that I like working with Arduino, so I recently put together a couple of iDuino boards. These are Arduino-compatible boards with a Mega168 running at 16MHz and an onboard FT232 for USB to RS-232 conversion. They are just under an inch wide and have downward-facing headers so they can be plugged into a solderless breadboard. I really like this board, I'd certainly recommend it if you prototype on solderless breadboard and use Arduino.
I was somewhat annoyed to find that the MRX-005 module's pins are not on 1/10 inch centers, so it cannot be plugged directly into a breadboard. Fortunately, while it has a lot of pins only a few actually need to be connected. I have it inverted on my breadboard, dead-bug style, with jumpers wrapped around the legs.
Yeah, it's a messy hack, but it's just a prototype. I attached a few feet of antenna and was able to capture some data.
The transitions aren't as sharp as I'd like to see, but it should easily be clean enough to decode.
I've also writen some C# code for parsing data samples from the OpenAMR project into graphable data. Hopefully the data from my Itron meter will be the same as that data. My library is smart enough to handle different kinds of data input, but I don't want to have to figure out what the fields in this data are.
Next step is to do some research about how to go about decoding this Manchester encoded bitstream on the AVR. I could invent something, but that would be dumb, this wheel has been invented many times.
Update 2009-July-7
I've made a bit more progress over the last couple of weeks. The next step was to impliment an Manchester decoder on the Arduino. I poked around on the Arduino site a bit, but didn't find anything immediately useful. Greg Hancock's brief OpenAMR page on Manchester coding mentions that he is using the scheme that happens to be published in US Patent 5,200,980 "Digital Bi-Phase Data Recovery System" by Dennis M. Briddell. That sounded like a good place to start, so I implemented it in an Arduino sketch (I'll move it to a library once it is all debugged).
While testing I found that the radio module doesn't output a clean logic signal, instead it provides an analog mess which doesn't work very well with the edge triggered interrupt on the AVR. I thought it would be good to clean it up by running it through a Schmitt trigger, but I don't have any and I don't want to pay shipping on only a few chips. It turns out that you can configure a 555 as an inverting Schmitt triggered buffer with no external parts, and it's easily fast enough to handle the 30uS signals from the meter datastream.
For testing purposes I assembled a second iDuino board and set it up to output some test data in Manchester format (sending it sure is a lot easier than receiving it!). The receiver appears to mostly work with the simple test data packets I'm sending, but I get occasional glitches. Even if I can't work those out it won't be much of an issue since the AMR data is retransmitted many times.
I think for the next step I will improve the code on the second iDuino to provide more realistic sample data. Currently the data rate is much lower (1mS chips instead of 30uS) and the data frames are only 4 bytes. I'll use some of the 92 byte sample data from the OpenAMR project, that should let me prove out the decoding routines without the unknown factors in the data from the radio module. Once I've got that working I'll switch back to the radio module and see if I can decode some actual data.
Update 2012-July-12
Here is the above-mentioned sample of the AMR data, in image format. See the comments below for C# code that defines the field layout.
Update 2014-July-17
The RTL-SDR captures the AMR broadcasts very nicely. I placed the antenna directly on top of the transmitter and captured a few transmissions. It's also easy to see broadcasts from other meters in the vicinity.
Recording the incoming data to a wav file produces about what you'd expect:
Looks just like the scope trace. I'm using SDRSharp which supports plugins, so I'm going to look into writing a decoder plugin. The option to record and reply signals with SDRSharp will make debugging quite a bit simpler.
