The Japan Meteorological Agency (JMA) will switch operations from Himawari-8 to Himawari-9 on 13 December at 05:00 UTC
Himawari 9 has been in space in on-orbit storage since 2016, Happily waiting for its chance to become the primary Satellite, taking over from Himawari-8. Same tech, identical satellites, same AHI sensors, etc. Now is the time for JMA to make the switch. While Himawari-9 has been active since Sept 2022 it is only on Dec 13th. 2022 that it will take over completely for Himawari-8.
The Japan Meteorological Agency (JMA) will switch operations from Himawari-8 to Himawari-9 on 13 December at 05:00 UTC. At that time, Himawari-9 products, instead of Himawari-8, will be provided to NESDIS and they will in turn be broadcast by HRIT/EMWIN in place of Himawari-8. (NOAA converts from the Himawari Standard Format (HSD) to HRIT format, prior to rebroadcasting via NESDIS PDA.)
Himawari data on the GOES-W HRIT broadcast is normally at about 10 minutes after the hour, therefore the first Himawari-9 products will appear at about 05:10 UTC on 13 December 2022.
(The actual time stamp on the HRIT imagery usually shows as 51 minutes after the preceding hour).
The Himawari-9 products will continue in Virtual Channel ID 60 on the GOES-W HRIT/EMWIN broadcast. There will be no change in product selection, schedule, name, or format. The Band numbers will be the same; the NOAA-specific LRIT/HRIT product Header will be unchanged (including, to be explicit, the Product ID and Subproduct IDs).
What this means for the end user-
The Product ID (43) and Sub-Product IDs (1/3/7) will be identical to Himawari-8. So with the current software as it is, Goestools and Xrit Decoder, SatDump and others, Himawari 9 Imagery will seamlessly appear in your reception, with this notable exception, they will still show as Himawari-8, until the respective software can be updated by the authors.
So, if you do nothing, then you will receive Himawari-9 BUT it will show as Himawari-8….
It would be simpler if Himawari LRIT files simply stated if they were from 8 or 9, but they don’t and won’t, so the file name headers, at least as they come in raw, are identical.
This has a trickle-down effect as well, other tools such as Sanchez, VitalityGoes, and other post-processing software, will need to be some tweaking as well, but I think there should be a consensus as to what file naming path will be used amongst the decoders.
A simple fix to show the imagery as HIMAWARI-9
Because, at least for goestools, the built-in ingestor assumes that ALL data from Himawari will be from Himawari-8, And since NESDIS will be relaying Himawari -9 with exactly the same product ID and sub-product ID’d the simplest way to fix the naming issue is to replace the existing Himawari 8 handler in your goesproc configuration file (goesr-goesproc.conf is usually found in /usr/share/goestools/).
BUT, do this just before 13 December at 05:00 UTC. At that time, Himawari-9 products, instead of Himawari-8 will be provided to NESDIS and HRIT/EMWIN will in turn broadcast them in place of Himawari-8. This will need to be done regardless of whether you receive it from GOES 17/18, or relayed via GOES-16
# Images relayed from Himawari-9 After Dec 13th 2022.
[[handler]]
type = "image"
origin = "himawari8"
directory = "./himawari9/{region:short|lower}/{time:%Y-%m-%d}"
filename = "Himawari9_{region:short}_{channel:short}_{time:%Y%m%dT%H%M%SZ}"
format = "jpg"
json = false
[[handler.map]]
path = "/usr/share/goestools/ne/ne_50m_admin_0_countries_lakes.json"
[[handler.map]]
path = "/usr/share/goestools/ne/ne_50m_admin_1_states_provinces_lakes.json"
NOTE: Leave origin = “himawari8” do not make it “himawari9” There is no handler currently in goestools for himawari9 and you will crash the software with an error. Comment OUT (or remove) the Himawari8 handler with “#” as well, otherwise, you will have duplicate files, just named differently.
For those who want details…
I received two files from JMA, one from H-8 and one from H-9 both with the same timestamp..
Here is the raw Himawari-8 file name:
IMG_DK01VIS_202211302151_001.lrit
Here is the raw Himawari-9 file name:
IMG_DK01VIS_202211302151_001.lrit
Same file name, but different satellites, and this is where the confusion can happen.
NOAA has decided to not change Product ID (43) and Subproduct ID(1/3/7) when Himawari-9 takes over.
The reasons:
- The subproduct ID isn’t necessarily arbitrary. (This identifies VS, IR, and WV) , the numbers refer to things that aren’t changing between 8 and 9.
- Changing the Product ID subproduct ID puts a strain on downstream users and on NOAA, unnecessarily. Time is short now, too. If we remain configured as we are, H9 data will simply flow on HRIT when it becomes available.
- If for some reason JMA failed back to H-8 from H-9, data would flow fine on HRIT without intervention. Robustness like that is a plus.
Note for Himawarcast and Eumetcast users: None of this applies to you, as JMA will be changing the filenames accordingly
New addition to Sanchez
If you have applied the goestools handler fix above, AND you use Sanchez, then you will need to update the satellite.json file in ..sanchez/resources/ to be able to apply all that Sanchez has to offer.
{
"DisplayName": "Himawari-9",
"FilenamePrefix": "^Himawari9_FD_IR_",
"FilenameParser": "Goesproc",
"Longitude": 140.7,
"LongitudeAdjustment": -0.8,
"Brightness": 1,
"Crop": [
0.007273,
0.007272,
0.007273,
0.007272
]
}, You can add it just under the Himawari8 section shown below:
