“In the Beginning…”
I first became interested in weather image reception after ordering a ‘manual’ from a company called “Information Unlimited” sometime in the mid-80’s. In it, they described how to receive POES weather satellites images with a tracking helical antenna, a decoder board, and oscilliscope and a Polaroid camera. I never was able to figure out what to do with those plans. I didn’t have an oscilloscope, couldn’t figure out the schematics and didn’t live in a place where I could track a satellite for more than a few minutes overhead, but I was bitten by the bug of weather satellite image reception.
Years intervened and I amassed a collection of articles on how to receive other formats of weather imagery, including shortwave weather fax and GOES Wefax.
Early on, these images were in the format of WEFAX…an analogue format (which NOAA polar orbiting satellites still use) and which was relatively easy to receive. All one needed was a dish, downconverter and receiver. Things were nice…sort of. The problem was that the pictures were good…but not great. Additionally, little processing could be done to them.
Then, LRIT came along. A digital format based on BPSK (google it). It had the promise of crystal clear images and the ability to do some real post processing on them. The trouble was…how was one to receive it? NOAA contracted a company in 2003 to look into a receiver design, and the results can be found on the NOAA LRIT website. Ths money spent on that contract was not really worth their while (in my opinion). The design didn’t use a readily available receiver (at this point, it becomes more of an issue of a demodulator) and there was discussion of a board, the design of which was not available… a BIG flop…at least in my opinion.
Fast foward to 2008 when a gentleman in the western USA managed to connect his dish to an LNA, then feed that into a satellite modem which he got cheap off of Ebay. He then connected the modem to an FPGA breakout board…and received data!
This was published in the GEO Quarterly (Group for Earth Observation). I became thrilled at the possibility of again receiving GOES imagery. The only problem…finding a satellite modem. I did finally manage to get one (an SDM-300A) I hooked it up to my Quorum 1691-137.5 Integrated Feed/Downconverter…turned everything on… and … nothing. Not a single lock. It would appear the VSAT downconverters have gains that are REALLY big… and my Quorum downconverter just wasn’t doing it. The Modem went back on the shelf (but, hey…it did only cost me $25…a steal. These thing retail for $4000!)
“The quest Continues…”
So…there I was…surfing the internet one day in the early fall of this year, and did a routine google search for ‘LRIT”…but this time a new site came up. Yes, sure, the routine sites for the aforementioned NOAA LRIT contract…and sites describing long range identification and tracking of ships. But, there was a new one from the people at GOES-R. Here was described a simple, low cost, tested, and documented LRIT receiver called an “AID”. I had to have one.
Well, it turns out that they aren’t available. Foiled again…
…but not completely…
What is available is what it was modeled after. It seams that several years back, a philanthropist named John Gilmore initiated a software initiative headed by Eric Blossum for software defined radio. Hardware for the platform was created by Matt Ettus. For more information google it…
I tracked down the people at Aerospace Corporation (who were contracted by NOAA) and asked some questions….specifically, is the USRP1 a drop-in replacement for the AID board. They said yes… and I had a USRP1 within the week.
There are caveats in life. One is that life is somehow fair. Another is that the USRP1 is equal to the AID receiver. As it turns out, the AID is based upon the USRP1. Each use a high speed A/D converter and send the data to an FPGA, and ultimately on the the computer. There, software assess the data and demodulated the signal. What i found out in my experiment was that the front end of the USRP1, with a BasicRx daughterboard, needs a signal of about 2v p-p and I was nowhere near that with my downconverter. But…I did have an extra wefax preamp laying around…
Well, after figuring out how to rig the bias-t’s to power both the preamp and LNB, I was set to see if it worked… and … it didn’t. It appears that the software that Aerospace created dosn’t run on on anything created by AMD. (correction…they do on the higher-end AMD chips…but my desktop wasn’t one of those) Blame the fact that Intel’s compiler basically cripples any software that might try to run on an AMD CPU. I think that this was a situation that went before the US Department of Justice…but I digress. Off to the computer store for a generic Intel computer.
Back home, the computer was unpacked, set up and and everything was connected….the DOS window was opened…the program name was entered…the return key was pressed…and…
SUCESS!
There was signal lock and as I watched, data was decoded and LRIT files were being deposited on my hard drive.
Ultimately, I went and purchased a Dartcom USB LRIT ingester and set it up. It has been running flawlessly for the past month and a half. It is a extruded aluminum box that sits on the computer and connects via USB. The .lrit files are decoded and placed on the computer and the processing software assembles them into the appropriate images. All in all it works pretty well, but there are some minor things that are on a wish list to change.
I’ve also been looking at writing my own software to decode the .lrit files. This would be focused on those people who have gone the way of using the Ettus box, or even the AID board from the Aerospace corp documentation. I’ve spent the past few days looking at the files from a binary point of view, using a hex viewer, to see how all the header information is put together. There is two current image viewers that I have used. The first is from Avdyne Corp. and can be found on the GOES LRIT site here. The second is a small visual basic program written and can be found here.
Here is what I have found regarding the .lrit file header structure. First, it’s all in there. Aside from the primary header (the first sixteen octets of the file), the rest of the header structure is included, so one can figure it out. Here is a brief summary…
The primary header tells you the size of the primary header, total size of all the headers, and the size of all the image data.
Here is a breakdown of the header structure as of a received file 12/31/2010.
Name octects type Header Name (code)
-----------------------------------------------------------
PriHdr 1 unsigned int Primary Header (0x00)
PHlength 2 unsigned int
PHfilecode 1 unsigned int
PHtothdrlngth 4 unsigned int
PHdatafldlngth 8 unsigned int
NOAALRIT 1 unsigned int NOAA Header (0x82)
NLfieldlen 2 unsigned int
NLagency 4 CHAR
NLprodID 2 unsigned int
NLprodSubID 2 unsigned int
NLprodParm 2 unsigned int
NLcompressflag 1 unsigned int
ImageStruct 1 unsigned int Image Structure Record (0x01)
ISfieldlen 2 unsigned int
ISbitsperpix 1 unsigned int
ISimagecols 2 unsigned int
ISimagelines 2 unsigned int
IScompressflag 1 unsigned int
ImageNav 1 unsigned int Image Navigation Record (0x02)
INfieldlen 2 unsigned int
INprojection 32 CHAR
INcolscalefctr 4 int
INlinescalefctr 4 int
INcoloffset 4 int
INlineoffset 4 int
ImageDataFunct 1 unsigned int Image Data Function Record (0x03)
IDFfieldlen 2 unsigned int
IDFdatadef 2689 CHAR
ANNOtation 1 unsigned int Annotation Record (0x04)
ANNOfieldlen 2 unsigned int
ANNOtxt 48 CHAR
TimeStamp 1 unsigned int Time Stamp Record (0x05)
TSfieldlen 2 unsigned int
TSccsdspfield 1 unsigned int
TSccsdsday 2 unsigned int
TSccsdsms 4 unsigned int
ANCillary 1 unsigned int Ancillary Text Record (0x07)
ANCfieldlen 2 unsigned int
ANCtxt 225 CHAR
SegmentID 1 unsigned int Segment Identification Record (0x80)
SIDfieldlen 2 unsigned int
SIDimageID 2 unsigned int
SIDsequencenum 2 unsigned int
SIDstartcol 2 unsigned int
SIDstartrow 2 unsigned int
SIDtotalnum 2 unsigned int
SIDmaxcol 2 unsigned int
SIDmaxrow 2 unsigned int
RiceID 1 unsigned int Rice Compression ID Record (0x83)
RIDfieldlen 2 unsigned int
RIDflags 2 unsigned int
RIDpixel 1 unsigned int
RIDline 1 unsigned int
Notes:
1) type ‘I’ (integer) or UI (unsigned integer) has a variable octet size depending on the octet numbers (8,16,24 or 32 bits)
2) ‘char’ is one octet (8 bits)
For a more detailed treatment of this information, please see “Part 3 – Receiver Specification” at the NOAA LRIT site. Note that “Part 4” gives an incomplete treatment of some of the records
Once you read all this data in, you have all the information you need to display the image. Some caveats… the image timestamp is not the time the image was scanned…it’s the time the file was transmitted. One of the problems that I’d like address when I write my program, is the ability to pick any .lrit file (not just the first segment) and display the entire image (if all the segments are present).