Electronic – Reverse-engineering VGA

Yes.

I have been very pleased with the software from HHD. I used the serial port monitor to do some heavy reverse engineering a few years back and the HHD software was well tailored for the work.

I dabbled with their USB sniffer version but never bought the full version. Back in the day there was a free trial version that was somewhat useful. They may still have it.

At any rate, I got in over my head with USB because I couldn't figure out how to make the "driver" in Windows. If you're using Linux the project may be quite a bit easier, since all of that low level driver I/O logic is easily accessible in the kernel code. Also, Linux 2.6 offers some devices under /dev which can be used to directly send/receive to the USB device without the need for any special module/drivers. Great for development.

So the issue you're probably running into there is that unlicensed radio spectrum is noisy. There's lots of stuff which transmits there, especially cheap wireless electronics like wireless doorbell ringers, wireless LED controllers, and this "power cost" monitor you're looking at. Are you sure you're not just swamped in noise? The receiver you linked to automatically scales so that noise will look like a signal. What comes out when the power monitor isn't connected? If it still looks like the same gibberish you've been getting, there's your problem.

You'll notice the massive number of complaints under that receiver from people who say "I can't get it to connect!" or "it gives garbage data!" and a whole bunch more giving advice on how to fix it. Likely the device you're trying to read has devised a similar scheme to properly encode its data.

For actually trying to "reverse engineer" the protocol, this is normally boring and slow but methodical and logical.

Start by simply taking the receiver you have and hooking it up to something like an oscilloscope in one shot mode and then hook up the receiver that came with your monitor. Then when the encoded packet comes from the cost monitor, save the waveform from your oscilloscope and what it corresponded to from the software output. Then when the next packet comes through, compare what changed in the waveform to what data you received. Slowly, you should be able to figure out what's going on.

In general, the reason you don't see too many amateur reverse engineering jobs is because there's a lot of intuition involved with reverse engineering these things. For example: you'll probably see that even with a single change in data (i.e. a new packet comes with only a change in temperature by 1 degree) there may be multiple changes in the packet. This could be from a checksum packet, but how was it formed? Is it a CRC16? Or simply a sum of all the bits in the packet?

A tool which might help would be a cheap logic analyzer.

Good luck! I hope that helps.