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)
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.
In the week from March 27th to 31 NOAA performed some new downstream tests over HRIT link on GOES-16. The idea was to transfer some CMI (Cloud and Moisture Imaging) products and see if the software developers and current stations could receive it fine. Before starting talking about that, please notice that all data sent so far is stated as test data and should not be used for any real world measurements. As NOAA states (and I forwarded on my last post):
The user of that link assumes all risks related to the use of their data and NOAA disclaims and any and all warranties, whether express or implied, including (without limitation) any implied warranties of merchantability or fitness for a particular purpose.
So I kept my dish pointed to GOES-16 all over the week and did record the Monday testing (that contained CMI images) and recorded all files sent all over the week. Some of them are automatically posted on Twitter / Instagram by my OSP Bot but not all of them. I had discovered some issues with my Virtual Channel Ingestor on GOES Dump, and also most of the new data was not being handled correctly by Goes Dump. Working together with @usa_satcom we managed to almost zero-out the bugs in GOES Dump.
Yesterday I received an email from NOAA (I’m on their “tester” list) about some tests on GOES-16 that will happen this week. Before I start talking about what will be the tests I want to be clear that GOES-16 is NOT operational yet and any data received from the LRIT/HRIT downlink are test only data. This means the user of that link assumes all risks related to the use of their data and NOAA disclaims and any and all warranties, whether express or implied, including (without limitation) any implied warranties of merchantability or fitness for a particular purpose.
So this week ( from 27th to 31th march ) HRIT will go into a new test phase that will send out DCS, Environmental Messages and charts through. They also will send from 16h to 20h UTC on Monday (27th) some CMI (Cloud and Moisture Imaging) data. That might be interesting for anyone that have a 1.5m+ dish that can run Linear Polarization at 1694MHz and be interested in trying out the super-alpha version of OpenSatelliteProject, that is already compatible to HRIT.
Please keep in mind that while OSP does support HRIT, it doesn’t mean it will support the new products coming out from HRIT link. They’re currently testing sending NetCDF files over HRIT, and so far OSP doesn’t support those. In normal case (no bugs) the output product should be stored in a folder named Unknown with the filename provided by NOAA. Regardless of that I will be trying to record the IQ / decoder output in the CMI period and run the OSP over all week in GOES-16.
While running in GOES-16 the Twitter / Instagram bots will not be outputing any GOES-13 data (sadly I only have one dish so far) but may output the products from GOES-16.
Some usefull links for you if you’re interested in more information:
Few *times* ago I started to check on GOES 16 transmissions to see if I can get any data from it and make OpenSatelliteProject work with it. Me and @usa_satcom noticed that the HRIT signal was transmitting using differential encoding that was not predicted on NOAA’s HRIT Specification (You can check it here http://www.goes-r.gov/users/hrit-links.html ). So I decided to send an email to NOAA asking what was the current HRIT specs for GOES-16. Of course I expected no answer from them (they would probably be really busy with GOES-16 Testing), but surprisingly they answered sending the specs and saying that any feedbacks would be helpful and appreciated. So the HRIT indeed uses Differential Encoding (NRZ-M to be more specific). Knowing that I could start changing OpenSatelliteProject to be compatible with HRIT.
It has been some time since I posted something here about my satellite projects. So now I finished assembling my new dish! Previous (on GOES Satellite Hunt) I use a 1.9m TV dish that was cheap (R$200 or about US$70) and got really nice results (about 6dB SNR on LRIT and 10dB SNR on EMWIN). But I was willing to get the new GRB Signal from GOES-16 (previous named as GOES-R) that went up to Geostationary orbit last month. The GRB is the replacement for the GOES 13/14/15 GVAR signal. Basically GVAR is a rebroadcast of the partially processed data from the satellite. It is basically the raw sensor data packed in a format so the users can get and process by their own. The disadvantage of GVAR system over LRIT is that it does not have any error correcting methods. So either you have a very good signal, or you don’t have anything at all. The GRB signal that is on GOES-16 will send same raw data as the GVAR (actually it will send more data than GVAR, but thats another point) but now it will use DVB-S2, a market standard, for transmitting their data. Being DVB-S2 it does have error correcting like LRIT signal ( wikipedia has a good info about DVB-S2). But the bandwidth of GRB is much higher than LRIT and GVAR (LRIT is 600kHz wide, GVAR is 2.5MHz wide and GRB is 9MHz wide) so I would need a bigger dish to get a good signal.
Yesterday I saw a new blog post by Adam (9a4qv) in LNA4ALL. The post (here) talks about a band pass filter he did for Weather Satellites and I decided to try as well.
Unfortunately I don’t have a exact match for that components at home, so I tried to do something with the components I have. So the lower value I had for capacitors was 10pF, and the needed values for Adam’s Filter is 1pF, 4.7pF and 15pF. I decided then to use 10 in series to do the 1pF, 2 in series for the 4.7pF (that will be 5pF) and then one in parallel with two in series to give me the 15pF. Its a very close match, and I’m unsure about the effects of serialization of capacitores in the filter (increase inductance maybe?). So here is the results.
In the last chapter of my GOES Satellite Hunt, I explained how to obtain the packets. In this part I will explain how to aggregate and decompress the packets to generate the LRIT files. This part will be somwhat quick, because most of the hard stuff was already done in the last part. Sadly the decompression algorithm is a modified RICE algorithm, and the Linux version of the library provided by NOAA cannot be used anymore because of incompatibilities between GCC ABIs ( The NOAA library has been compiled with GCC 2). Until I reverse engineer and create a open version of the decompression algorithm, I will use the workaround I will explain here.
In the last chapter I showed how to get the frames from the demodulated bit stream. In this chapter I will show you how to parse these frames and get the packets that will on next chapter generate the files that GOES send. I will first add C code to the code I did in the last chapter to separated all the virtual channels by ID. But mainly this chapter will be done in python (just because its easier, I will eventually make a C code as well to do the stuff).
In the last chapter of GOES Satellite Hunt, I explained how I did the BPSK Demodulator for the LRIT Signal. Now I will explain how to decode the output of the data we got in the last chapter.
One thing that is worth mentioning is that most (if not all) weather satellites that transmit digital signals use the CCSDS standard packet format, or at least something based on it. For example this frame decoder can be used (with some modifications due QPSK instead BPSK) for LRPT Signals from Meteor Satellites (I plan to do a LRPT decoder as well in the future, and I will post about it). I will not describe my entire code here, just the pieces for decoding the data. I will also not write the entire code here, since it can be checked in github. So before start see the picture below (again). We will some info from it as well.