Number of receivers decreased significantly with time for a fixed processing date

[AKHughes1994]

Hi,

Running a containerized version of ALBUS is producing significantly different results for a fixed date, depending on the time of the run.

Specifically, I've run ALBUS for a fixed direction to solve for the ionospheric RM on the date of October 15, 2023. The results differed notably:

A run performed in August 2024 used 26 GPS receivers.

A run performed in July 2025 used only 2 GPS receivers.

Admittedly, ALBUS is a bit of a black box to me, so I'm not exactly sure where to look to understand the issue. If you can provide any advice, it would be greatly appreciated. For context, I've attached two log files for the runs, labeled "good" and "bad."

goodlog.log
badlog.log

[twillis449]

If you are trying to get ionosphere corrections for a MeerKat observation, the South African network of GPS stations used for this purpose is provided by the 'trignet' data service. It looks to me that on the date of your 'badlog' observation, the trignet system was not available or responding for some reason (I have no idea why) So you will only get data from the ~ 300 stations that are part of the international GNSS network. 'SUTH' which is at the SAAO site near Sutherland is one such station and is successfully found in the 'badlog' observation. I would just try another run ....

[AKHughes1994]

Hi,

Thanks for the quick reply.

The issue seems to have persisted for ~a month (and on going) so I've emailed trignet.

I'll let you know what I find.

Cheers,
Andrew

[AKHughes1994]

Hi,

I emailed TRIGNET and they informed me that the migrated formats from RINEX2 to RINEX3, but this also results in a change in the naming convention.

More specifically, the L1L2_30sec doesn't seem to exist in ftp anymore being replaced with Daily_30sec.

So, what I did to fix it was, change the line in Albus_RINEX.py from:

site_str = "ftp://ftp.trignet.co.za/RefData.%2.2d/%3.3d/L1L2_30sec/%s"%(year-2000, doy, ftp_file_name)

to

site_str = "ftp://ftp.trignet.co.za/RefData.%2.2d/%3.3d/Daily_30sec/%s"%(year-2000, doy, ftp_file_name)

and my instance is now picking up 20+ stations again.

[AKHughes1994]

For completeness I've attached the memo that described the new directory structure

Introducing the new FTP archive_RINEX 3 _ Step by step instructions on how to access TrigNet data.pdf

[twillis449]

Thanks for investigating this issue. Too bad the main trignet web site has not been updated to fix this issue. RINEX 3 data can have more than two frequencies, but I am absolutely never gonna want to add in additional frequencies so I use the program gfzrnx to filter things down to the equivalent of RINEX 2 data. BTW at the moment be careful about downloading ALBUS directly from github as the SARAO people are trying to get a version of ALBUS to build using cmake which may or may not work for you.

[twillis449]

BTW - any idea when this change took place? I would assume that trignet will not update RINEX2 files from e.g. 2011 to RINEX 3 but will have just switched over from some particular date. ALBUS has numerous sites where we have had to switch over so things are relatively easy to fix.
Tony

[AKHughes1994]

I've sent a reply email to trignet asking for the exact date/information about the change. I will update the ticket when they reply.

I also have a older repo on a local machine (Around June 2024 it was downloaded) that I will/have update with the fixes. So (I thin) that should be fine

[twillis449]

I'm starting to think that you were lucky! When I try to decompress files, I get lots of errors of the form

[/home/twillis/meerkat_data/CALV125Z.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case, the central directory and zipfile comment will be found on
the last disk(s) of this archive.
Cannot find observation data for MJD 59339 station 'calvZAF'

So on my local computer, the decompression routine is confused. :(

I have never encountered this error before. There is some discussion of how to handle this on Stack Exchange. Looks like I might have to install java. we will see.'

And of course I now have to generate code to specify RINEX 3 file names etc for downloads after the start of 2025. That should be fairly easy, as I already had to do so for Australia back in about 2020

[AKHughes1994]

Hi,

Two (intermediate updates).

The swap from RINEX2 to RINEX3 occurs on March 20, 2025 (day 080 seems to be the first long-name RINEX3 file). I'm just asking the TRIGNET team if that is correct because there was some discussion about some of the 2025 data having the short name convention, but also being RINEX3; I haven't been able to find an example, so I asked for a follow-up.

There is also some unusual directory structure in 2025; sometimes the 'Daily_30sec' directory doesn't exist, sometimes it uses the old convention of L1L2, and sometimes the directories are empty. I raised the issue so I'll let you know what the reply is.

The second thing is the ZIP issue. That's odd, I downloaded that file manually from trignet:

wget ftp://ftp.trignet.co.za/RefData.21/125/Daily_30sec/CALV125Z.zip

and could decompress as normal

unzip CALV125Z.zip

Likely a silly question, but were the downloads getting corrupted halfway? I've tried it now for several dates in 2023 and 2024, and it works fine. I'd be happy to share a log file from one of my runs if it would be useful.

[AKHughes1994]

To add to this, I ran my containerised version for that day, and it runs without fail (although some of the TEC estimates for specific times are junk

Here is a screenshot of the snippet of code:

Where the calv sensor is used, I've included the output 'report' and log.log file in case they're of use.

log.log
albus_report_parallel_RI_G03_meerkat_J1331+3030.txt

[AKHughes1994]

I'm not sure what the timeline is for adding the naming flag to handle the RX3-to-RX2 conversion for the Trignet receivers, but whenever you figure out which lines need to be edited, would you mind dropping a note here? That way I can easily update my local branch. Thanks in advance!

[twillis449]

I have the system working for RINEX 3 files, but I still have to combine the 'old' and 'new' scripts. Unfortunately, the nominal 'switch' over day-of-year == 80 seems open to debate - sigh. There's no old or new data around this date. I suppose I can work backward from some date where I get RINEX 3 data consistently, but it's all annoying. At least when other organizations have switched over on a fixed date, then everything has worked after that date. As you have mentioned in earlier messages, the trignet directory structure seems somewhat ambiguous around that time.

[twillis449]

By April 1, no old or new data was found. I do get new data by May 2 :)

[AKHughes1994]

Yeah there is something weird going on in 2025 (i.e. RefData.25), I emailed the trignet people about that, but maybe this information will be helpful here for verification to see if we are getting the same (wrong) thing, this is what I sent a few weeks ago:

day 089, 090, 092 is missing the Daily_30sec subdirectory
day 091 has the Daily_30sec subdirectory but its empty
day 001 to 087 use the old directory naming of L1L2_1sec <- This isn't really relevant for our use cases

If I download and unzip: wget ftp://ftp.trignet.co.za/RefData.25/080/Daily_30sec/CALV*Z.zip this does seem to be the first time I see the longform name + RINEX3.

Doing more digging, the structure of storing the files seems to change as well, for example, despite having the long names, some times the RX3 data is stored in .zip files like the past precedent, for example:

/RefData.25/080/Daily_30sec/WORC080Z.zip
/RefData.25/100/Daily_30sec/WORC080Z.zip

but for later observations its now stored as open directories that can be parsed:

/RefData.25/094/Daily_30sec/WORC/[files]
/RefData.25/120/Daily_30sec/WORC/[files]

althought this doesn't seem to be contiguous because (for me) 080/100 are zip files, and 094/120 are directories. If you find out a good way to nicely parse the files to identify when to perform RX3-to-2 conversion I would be interested to see it 😅