I was able to take a look at the I/Q recording from N6RFM’s station in the North-East U.S. and visually spotted -3- possible MESAT-1 packets in Inspectrum, but all were much to weak to consider trying to decode. Here is one:
.
.
… Oh my, I sure hope all these similar observations from around the world are just low elevation and not another un-deployed antenna situation. But, it’s still better than not seeing anything at all.
Great news!!
And every time I refresh the dashboard, another new callsign shows up. Thank goodness!
I just processed this pass from KU4JY and it had three frames across two safe mode transmissions:
https://network.satnogs.org/observations/9793917/
No luck here either - thanks for sharing the file.
It seems that the duration of the signal is so long, that your doppler correction is “moving” the tuning while the signal is still being received.
Since BPSK has to be centered almost perfectly to decode, it might be exactly right at first but then the SDR tuning moves away from the signal just enough to prevent decode. I’ve seen that many times.
We are spoiled by FM / FSK, etc., since it will often decode if you are just in the neighborhood of the signal. You would be decoding 100% of these BPSK signals if they were shorter.
It might be worth making the I/Q recording with NO doppler correction so that, on replay, you can focus on the strong packets & even gently tune by hand if required. I often cut out a single, strong packet and play it in a loop in GNU Radio. The same could be done in many SDR apps as well.
Then, as the one packet repeats, slow adjustments can be made to get exactly centered on the packet with only enough bandpass (i.e., approx 3 kHz) to span the packet. In that case, demod as BPSK w/ a 1.5 kHz offset and you usually get a clean decode. Of course, if the signal is a little wider and 4 kHz looks better, use a 2 kHz BPSK offset to decode. (I do realize I’m saying things you already know - please don’t take offense… others might find this thread later)
Today during the daytime (10:56UTC) pass over Brazil, MESAT-1 was heard
Sorry about the size of the IQ (I forgot to reduce the RTL sample rate)
Yagi 7el + RTL SDR V3
Object-G TLE (60209)
I couldn’t get anything out of it
Direct link to Google Drive HERE (IQ file)
yeah, the 100ms update on satnogs upsets the phase…
recording without doppler and using Dani’s doppler-correction block instead as it does sample by sample correction would be much better.
Have a look at this code how to generate the doppler file from TLE.
Or, for that matter, use the above mentioned ground-station to record it, it is quite nice (:
I notice that MESAT-1 is associated with temp object 99219 in Satnogs, but that has different TLEs to object 60209. Should it be updated? There is about a 20 degree pointing angle difference right now between the two TLEs sets.
One caveat. It’s possible that I have overwritten one of the objects with a local file update in my GPredict. So apologies if I got that wrong.
Off-topic, I know, but on the outside chance that anyone is curious, a good way to purge out ‘extra’ or preliminary objects, or to get rid of temp names, etc., in GPredict is to navigate to
.config/Gpredict/satdata
in your $HOME directory and delete all or a portion of the .sat files.
Then, simply update from the network source you use and you’ll be back in-sync w/ all the ‘official’ names & object numbers!
There are command line options for this.
gpredict --help
Usage:
gpredict [OPTION…]
Gpredict is a graphical real-time satellite tracking and orbit prediction program.
Gpredict does not require any command line options for nominal operation.
Help Options:
-h, --help Show help options
--help-all Show all help options
--help-gtk Show GTK+ Options
Application Options:
--clean-tle Clean the TLE data in user's configuration directory
--clean-trsp Clean the transponder data in user's configuration directory
--display=DISPLAY X display to use
--clean-tle and or --clean-trsp
As long as we aren’t sure about the object, we keep using 99219 and follow the most likely object and that is currently 60209.
But it is pretty early and that can still change.
My yesterday’s 5 AUG high EL IQ file links (2 links for one passage) :
https://1drv.ms/u/s!Ah9pXGTFUz9HhKU6XMvrqkIbkS_DDQ?e=ejxeZ9
https://1drv.ms/u/s!Ah9pXGTFUz9HhKU5bSxUsXjZAvGQww?e=tDmNOI
AZ/EL Ant 2x 70 cm Mastpro with LNA.
see on X :
https://x.com/PA5OXW/status/1809129614658179301
Couldn’t decode, maybe the experts ?
73
Albert
PA5OXW
Thanks Albert,
I nice to see you here, we will give them a try
Using an I/Q recording of MESAT-1 shared by PY4ZBZ
https://x.com/N8MH/status/1809234608979866029
… it was obvious on replay that it’s VERY difficult to cleanly decode a BPSK packet of such long duration. But, by hand-tuning in HDSDR, I got close enough for FoxTelem to recognize the data. I see several more callsigns showing up on the Leaderboard for MESAT-1 telem as well. So, it IS possible!
@K4KDR it is quite difficult to tune this by hand as you say. If you have a recording without doppler compensation then you need to compensate for that. That means you need to know the lat lon of the receiving station and recalculate the Doppler for the pass, either by setting your clock back or using a program to retune the signal.
The packets are about 5 seconds long, there are two in each SAFE mode transmission. I agree they are long. This helps with throughput but is harder with low signal to noise.
The satnogs recordings are all straight down the middle with the current TLEs so tuning is not an issue. If you play back one of the strong recordings then at least some packets decode in FoxTelem.
Note, if you decode recordings from satnogs and the data is uploaded to amsat.org then please credit the original observer by using their station name as the callsign. Use dashes instead of spaces. At amsat.org we de-dupe everything so repeated observations are fine.
The PI9CAM group did an observation with there 25 meter dish.
The recorded IQ file can be download at SatNOGS IQ data
I tried to replay the recording and get some frames but wasn’t able to, I used SDR++
Thanks @PE0SAT, many thanks for trying a decode.
I saw the @pi9cam recording this morning and I am very appreciative of their observation. They did post some frames live from their observation run, so it decoded directly in FoxTelem. I believe they run it in parallel with their satnogs setup.
I will likely be able to extract some more frames from the recording. I have not had a chance yet as there have been two passes over the east coast that AMSAT operations have been working, with my support.
Just FYI, I can extract all 10 frames of data from the PI9CAM recording. This is possible directly from the.ogg file.
How do you compensate the 12k offset when using the ogg file ?
