Hello,
I’m trying to build a custom protocol decoder.
It’s centered around the Efergy Energy Meter. Having already tapped into the hardware, I’m trying to analyze the incoming data.
It’s basically a 433Mhz module that uses a custom encoding.
Now, having a logic probe, I’m able to say that the shortest high/low pulse is 6us (microseconds that is).
I was thinking of reading the timing values with my FEZ Domino and translating them into more usable 0/1 values for the computer.
Where I’m actually stuck is the InterruptPort that apparently can’t get below 21 us (that’s the lowest value I’ve got).
Can you confirm that I should look no further and perhaps use some PIC + assembler instead?
I was hoping (based on this entry: http://bansky.net/blog/2007/10/one-wire-bus-and-micro-framework/comments.html ) to get near the 5us mark. I know that the blog author uses a 100Mhz processor, but I was hoping that the 72Mhz of the FEZ Domino is not that far away.
Any ideas would be appreciated.
I would try to get as close to the native code as possible with RLP, but I am afraid you are out of luck here. All FEZ boards are not real time by design. The micro controller itself is capable of that, but taken into account that it runs micro framework and offer all the great benefits of .NET it will not give you the resolution you want. Correct me if I am wrong.
Thanks. I’m not very familiar with RLP, so I guess it’s back to bcf, bsf, incf, etc.
Damn.
You will not be able to do that with any NETMF device. You will need native code to handle data.
There are tricks you can do tough but first let me ask.
Is this a constant stream of data? If not then how long is the message?
What is the bitrate?
Is this a commercial application?
Is it okay to lose some data? I mean the sensor keep on sending values so if you miss one you get the next one.
By the way, you can’t properly write one wire drivers with NETMF and C#. This is why GHI supports one wire natively.
It’s a short burst of data (edit: 35 ms), repeated at 6 seconds interval (can be changed to 30 seconds).
The message contains about roughly 100-120 high/lows (I suppose, as one can notice a pretty standard “pattern” of 1/0).
It’s not a standard UART (that would have been simple) but a pretty specific implementation I suppose.
An older version of the efergy monitor uses this protocol:
No, it’s not a commercial application, it’s just a way of having the computer displaying real time data of an energy meter. The meter has a USB-mode, but it can display only hourly averages and it’s very nice, but highly ineffective for real data mining (finding short electricity bursts, etc).
The plan was to get the information in real time (the lcd display of the unit certainly does it) and store it on a pc for detailed analysis.
I like the E2 meter because it’s precise, unlike other open-source ones that have a documented protocol but a poor metering precision, but this protocol is killing me. I can clearly see it on the logic analyzer (a Saleae) but it’s hard to plot the data & spot the protocol they are using to send the amp reading.
Anyway, I’m pretty motivated, so if the FEZ Domino won’t do it, I’ll take out the Pickit2 and make it readable. It will probably take 3days at least (instead of the 20 minutes I’ve spent writing the Fez application) and some gray hairs but the result can’t be that far away.