Software Radio for Satellite TV on your Computer

Look at your TV today. It receives analog free-to-air TV signals using some built-in receiver circuitry. If your TV is capable of receiving digital channels, great – but did you know that it actually uses a separate set of receiver circuitry to make it happen? That’s why for those with an older TV set, they need to get a set-top box to get the digital channels. Wouldn’t it be great if we can use the one set of hardware to receive every channel out there, be it analog TV, digital terrestrial TV, satellite TV and even the TV standards yet to be developed? Well that’s what software radio here for.

Throughout this year, I was busily working on my undergraduate thesis project, with the goal of developing a software based transmission system for satellite TV. In particular, I wanted to implement the European standard DVB-S using a general purpose computer and the free software radio framework called GNU Radio and a generic radio device called the USRP from Ettus Research.

How did I go? It worked! I was able to correctly decode the captured signal from the satellite and recover the MPEG-2 transport stream that can be played using MPlayer, but unfortunately that’s not the end of the story. Ideally we’d like to receive the satellite signal and decode it in real-time, but our processing speed hasn’t quite got there yet. The performance can be summarised in the figure below:

In this chart, we’ve taken the throughput of each component signal processing block in the receive chain and normalised it to a value of 1 meaning that it’s just able to run in real-time assuming that each block can be run in parallel. A value of lower than 1 means that it’s slower than real-time while values greater than 1 mean it’s more than fast enough for real-time processing. Looking at the proportion of CPU time spent in decoding, there are only three blocks taking up most of the time: the Viterbi decoder, the M-PSK receiver for symbol timing recovery and the frequency correcting frequency locked loop:

So what we need to do now is improve the efficiency and throughput of each of those blocks, then we should be well on our way to real-time, satellite TV decoding on completely generic and reconfigurable software radio on the computer!

More details can be found in my treatise, which can be found under my blog’s Sydney Uni page.

Analysing pv’s attempt to work with CMS-5000

There’s a library a wrote a little while ago that was designed to interact with some photovoltaic inverters via the serial port. It was written based on captured communication between the official ProControl software

Reader contribution

Simon’s tried out my code to see if it’ll work on a newer inverter, the CMS-5000. Unfortunately the library as it stands doesn’t quite work. So let’s take a closer look at the packets:

First we reset the inverter:

SEND -> aaaa 0100 0000 0004 00 0159

Discover inverters:

SEND -> aaaa 0100 0000 0000 00 0155

RECV <- aaaa fe00 0000 0080 0a 52353634363033303631 04fd OK

Mostly OK so far, but something that strikes me is that the first byte (0xFE) of what I assumed to be the source address seems to have some other significance (it’s not 0×0000). Moving on…

Register the inverter with address “0001”:

SEND -> aaaa 0100 0000 0001 0c 523536343630333036310001 0384

The inverter acknowledges

RECV <- aaaa fe01 0000 0081 01 06 02db OK

So even though the first byte of the address 0xFE is incorrect, things still seem to be working.

Now we try to find what status fields the inverter gives:

SEND -> aaaa 0100 0001 0101 00 0158

RECV <- aaaa fe01 0000 0181 01 15 02eb OK

This bit here is the interesting bit. First, (if my assumptions about the comms protocol were correct), the inverter only gives 2 fields: 0×01 and 0×15. That’s really few compared with the ones I’ve seen before. Not only that, but we don’t yet know what the field 0×15 is for. Basically I assumed that the reply I get is a listing of the status fields, but instead I get something else.

So let’s query the inverter for its status:

SEND -> aaaa 0100 0001 0104 00 015b

RECV <- aaaa fe01 0000 0184 12 05dc003c071c0abe1290139a009900e8034a 080f OK

So here we have the full status update from the inverter. We can’t decode what it’s saying, because it doesn’t quite match the status field query. This is why the pv library is failing to interpret this packet based on the received structure that was supposedly just 2 fields long.

What does this mean?

In the most basic level, there are a few assumptions + generalisations that I’ve made which turned out to be inaccurate, hence it’s not working for a different model inverter.

What we’d need now is a capture of the raw communication between the official monitoring software and the inverter to get a better understanding of what’s going on.

pv – a Python library to monitor/control PV Inverters

After having the solar electricity system installed, I can monitor the energy output of the inverter using Pro Control. However, because the software runs on Windows, I’d have to have a PC turned on just for that purpose wasting quite a bit of energy. So, my goal is to use a low-power embedded Debian box (which is usually on) to do the monitoring. Instead of just writing an application to do the job, I’ve decided to write a library others can use to write their own custom logging software.

pv can be found at http://pv.codeplex.com/, and should work for you if you have a Carbon Management Solutions CMS-2000 or Schneider Electric SunEzy 600E (judging from a sample protocol exchange).

I’ll have to give full credit to the folks at http://www.solarfreaks.com/cms2000-inverter-rs232-serial-port-hack-cms-2000-rs232-t271.html who did the initial work on reverse engineering the communication protocols. Building on what has already been done on working out the protocol, and doing a bit of reverse engineering myself, the library supports sending arbitrary data frames for further exploring, as well as the known protocols.

Read more »

Mini-Project: Command line speech synth tool for Windows

The story behind this mini-project is, a friend of mine mentioned how he would SSH into his Mac at home and use “say” to send a short message to his parents, just like in a past XKCD webcomic:

Mac users, lucky you. You get a Terminal utility called “say” that converts text to speech. Windows doesn’t come with this tool, so I thought, it couldn’t be that difficult to make my own command line speech synth tool for Windows.

Read more »

COM interop for applications on Windows Phone 7?

So recently an image for the phantom phone “HTC Mondrian” was leaked and spattered across the internet. Catching a chunk  of the spatter, I dug in to see what was inside.

I noticed something rather interesting, while digging through the “HTC Test Tool” package. There is apparently a “normal app” called BatteryTool:

    <App xmlns=""
        ProductID="{ae2781c8-7afb-4e16-a643-c9c0ff33fc15}"
        Title="BatteryTool" RuntimeType="SilverLight" Version="1.0.0.0"
        Genre="NormalApp"  Author="" Description="" Publisher="">
...

But yet when we take a look inside the Silverlight .xap file, there is a dll called “COMInterface.dll”. The guess is that HTC’s using COM interop from within the Silverlight application to get access to lower level OS resources.

So even though apps should be running inside its own tightly sealed container in Windows Phone 7, I think it’s quite possible to break out of it via COM. Unfortunately this (ARM?) dll won’t quite work in the x86 WP7 Emulator…