GOES GRB First Light!

Written by Lucas Teske
on 15 October 2017

When the GOES-16 was first announced I got interested in their GRB Downlink (although the first try was at HRIT downlink). Basically GRB is a replacement for the old PDR downlink in GOES 13/14/15 generation, which gives few advantages over the old link:

Uses market standard DVB-S2 Generic Stream
Have FEC (as defined by DVB-S2)
Higher bandwidth
Easier to receive due DVB-S2 FEC

For those who don’t know, the GRB is a direct rebroadcast of GOES data, with minimum processing as possible (usually just packaged into NetCDF files with calibration parameters) and is intended for anyone that want’s to get full data from the satellite.

The down-link itself is split into two channels transmitted at same frequency (1684.5 MHz) with different circular polarities. That makes extremely necessary to use Circular Polarized feeds, since a Linear Feed will suffer with cross polarization (sum of each channel at the same signal).

For HRIT downlink usually a 1 meter dish is enough for receiving with a good signal (needs a very good hardware setup though). But for GRB, the minimum dish size listed by NOAA is 3.8m for the best regions.

We all know that NOAA has big margins over their recommended sizes (especially for GRB which tecnically should work in any weather condition). So we were testing with few dish sizes (and still testing) and checking which is the minimum size to receive a GRB signal.

I have a 2.2m prime focus dish, but sadly my station is offline for house changes (which I hope to finish by start of next year), @usa_satcom did some tests with his 1.8m dish with a RHCP feed and a TBS device and haven’t got a lock (although @drmpeg did some tests with his IQ and got a lock and almost a decodable signal with about 6dB SNR). One of OpenSatelliteProject users at OSP RocketChat , Ray Weber ( @weather01089 ) nave a 3m dish in Boston with a nice Septum Feed from RF Ham Design which gets about 12dB SNR signal and a perfect lock. Sadly for some reason the CCSDS inner data looks corrupt for unknown reasons right now. I tested with Ray with a TBS Card and a Ayecka Device with alpha testing firmware for raw BB Frame output and so far no luck (for unknown reasons).

We will continue trying and checking, and any people that has a DVB-S2 Generic Stream capable receiver and a dish bigger than 2 meters and visiblity to GOES 16 is welcome to help us with testing for GRB. Notice that GOES-16 will change position next month to its final location replacing GOES 13.

GRB Ingestion

Besides that, I decided to make a GRB Ingestion module for Open Satellite Project (which I plan to receive 24/7 in the future). I asked NOAA if they had some test data I could use, and they forwarded me to CSPP-GEO project which has some test data. CSPP-GEO is a nice ingestion software for GRB and it’s probably the standard receiver nowadays. It outputs NetCDF files and receives a CADU UDP stream for each polarity. Still I wanted to learn the GRB ingestion process and do a more centralized processing (CSPP-GEO has several python scripts and a java ingestion server). So I downloaded their test data and started making the ingestor.

The ingestion process is not fully complete right now, but it does output SUVI and ABI imaging in 16 bit PGM format and optionally a PNG image (with values scaled to 8 bit). It also outputs other files as raw. The ingestion process is similar to GOES LRIT/HRIT since it uses CCSDS, but the frame size is different (2044 bytes instead 896 bytes) and it always have a second header for each packet (LRIT/HRIT doesn’t have a second header). Also ABI/SUVI images are compressed using JPEG2000 instead Goloumb Rice (SZIP), which makes easier to decompress (since its more standard than SZIP). The image segmentation is different having two parts of segmentation.

The first segmentation occurs from the original Image that is sub-divided in blocks in both axis (so a 2D Block grid). This requires a image buffer for drawing these blocks since they can be received out of order. The second segmentation occurs inside blocks, which looks similar to LRIT/HRIT segmentation since they’re only across Y axis and their output can be just appended.

Each segment of block is compressed using JPEG2000, meaning that for final image assemble all segments of block should be decompressed to assemble a block, then to assemble final image. These images always come as 16 bit / pixel since all sensors have higher than 8 bit depth, and that makes processing in C# (native language of OSP Ingestor) a bit tricky. For helping the image manipulations I created a Image16 class that works similar to the Bitmap class on GDI+.

Another difference in the ingestion is that in LRIT/HRIT the files would have a segment counter in the header, but in the case of GRB the segments of the same file are identified by APID and Epoch in Microseconds. Basically any received image with the same APID and Epoch Timestamp are from the same image.

For testing purposes I made it save in a PGM file which is supported by GIMP and supports 16 bit. Then I can use GIMP 2.9.7 (which natively supports 16 bit imagery) to display / edit. I also made a PNG image saver that normalizes and scales down the 16 bit image to 8 bit, being possible to visualize with any program.

The full source code is available at https://github.com/opensatelliteproject/grbdump and instructions of how to use will come soon, but for now it supports UDP BBFrames / CADU on port 1234 (just compile, run and stream to port 1234 and you should have it ingesting and saving files).