Soyuz-2.1b/Fregat - Ionosfera-M 3&4 - Vostochny - 25 July 2025 (05:54 UTC)

239Alferov over Brazil :brazil: !!

4 Likes

Strong and wide signals were received here at ~435.335MHz.

Weaker but wide signals were received at ~435.500MHz, ~435.660MHz, and ~436.720MHz.

Updated TLE

239ALFEROV is a bit high in frequency 436.272200, the receiver isn’t GPS locked so some room for error

239ALFEROV
1 98560U          25206.57638889  .00000000  00000-0  50000-4 0    09
2 98560  97.4200 172.3285 0022184  95.1182 294.4869 15.20780493    04

4 Likes

Updated TLE

GEOSCAN-1 
1 98559U          25206.57638889  .00000000  00000-0  50000-4 0    07
2 98559  97.4200 172.1177 0022180 107.1563 282.2990 15.21797488    06

3 Likes

Updated TLE

GEOSCAN-2 is a bit high in frequency 436.162600, the receiver isn’t GPS locked so some room for error

GEOSCAN-2
1 98558U          25206.57638889  .00000000  00000-0  50000-4 0    06
2 98558  97.4100 171.9757 0022955 120.1302 269.6656 15.22011860    03

4 Likes

Updated TLE

GEOSCAN-3 is a bit high in frequency 435.74100, the receiver isn’t GPS locked so some room for error

GEOSCAN-3
1 98557U          25206.57638889  .00000000  00000-0  50000-4 0    05
2 98557  97.4100 171.9950 0011560  49.4078 340.2648 15.21521646    04

4 Likes

Updated TLE

GEOSCAN-4
1 98556U          25206.57638889  .00000000  00000-0  50000-4 0    04
2 98556  97.4100 172.2626 0014369  56.1820 333.5891 15.21192689    03

4 Likes

Oh my… be careful what you wish for.

With higher elevation on today’s 2010utc pass over the Eastern U.S., it’s going to take quite a while to sort through & decode (hopefully) the -7- (!!!) different LoRa downlink streams that showed up monitoring 436 MHz to 438 MHz on the 2.5-turn helical omni.

I’m hoping that ‘3’, ‘4’, ‘5’ and ‘6’ turn out to be the CSTP-4.x sats since the bandwidth matches the 62.5k (shown by the cursor that I have right at 437.000 MHz) that the previous CSTP satellites are using.

5 Likes

TLE Update

GEOSCAN-5
1 98555U          25206.57638889  .00000000  00000-0  50000-4 0    03
2 98555  97.4200 171.9858 0017096  63.3472 326.3554 15.19825980    09

3 Likes

TLE Update

GEOSCAN-6
1 98554U          25206.57638889  .00000000  00000-0  50000-4 0    02
2 98554  97.4200 172.1202 0021954 111.1616 278.3879 15.21241162    07

2 Likes

TLE Update

INNOSAT3 
1 98553U          25206.57638889  .00000000  00000-0  50000-4 0    01
2 98553  97.4100 171.9996 0008420  44.2001 345.5076 15.21424471    01

3 Likes

TLE Update

INNOSAT16
1 98552U          25206.57638889  .00000000  00000-0 -10368-1 0    01
2 98552  97.4100 172.0128 0016147 141.4184 247.6357 15.21804565    06

3 Likes

All nine CubeSats with known tx frequencies were received and decoded from a 28.6 deg. max el. pass, with turnstile antenna and LNA+BPF in Greece.
https://x.com/SV2HWM/status/1948759088298426500
https://x.com/SV2HWM/status/1948835087300395133

6 Likes

Ok, successfully reversed the LoRa parameters for the -4- 62.5k streams that I assume are the CSTP-4.x sats.

While just approximate, the freqs are:

436.734
437.162
437.246
437.326

#1, those freqs are ‘close’ - hopefully over time a more accurate center freq can be determined.

#2, I have no idea which sat goes with which freq… there was no ASCII in the payloads to identify the source.

For example, here’s one of the packets from 436.734 as I was replaying a packet to work out the parameters:

[22:58:47:734] Listening for downlink on 436.734 ......
[22:58:47:860] 
[22:58:47:860] BW=62.5    SF=8    CR=4/6
[22:58:47:860] Preamble_Len=6  SyncWord=0x12
[22:58:47:860] CRC=ON    LDRO=OFF    invertIQ=OFF
[22:58:47:967] -------------------------------------------------------
[22:58:49:035] 
[22:58:49:035] Reception Success!
[22:58:49:035] 
[22:58:49:035] Received 68 bytes:
[22:58:49:035] 
[22:58:49:035] 00 02 7E C0 3E B3 74 BA 83 68 C9 06 02 00 B0 0E 00 A8 FF F9 62 A2 00 00 62 A2 00 00 CE 20 80 00 12 40 07 00 14 00 05 01 11 00 01 76 46 32 48 F1 4C 01 01 01 00 08 08 00 00 00 08 00 3D 00 00 00 00 2C 00 00 
[22:58:49:286] 
[22:58:49:286] ..~.>.t..h..........b...b.... ...@.........vF2H.L...........=....,..

… always nice when there is some ASCII in a decode, but not this time.

I’ve notified the administrator of tinyGS.com so that he can add these 4 sats to that system. Collectively, the world-wide ground stations contributing to that database should be able to zero in on the exact frequencies and satellite ID’s of these downlinks.

As a bonus, there were a couple of 125k LoRa downlinks plus one 250k downlink. I’ll reverse those as soon as possible to see if they’re already known or something new.

5 Likes

In addition to the discovery of the -4- 62.5k streams that I hope and expect are the CSTP-4.x sats, I have a bit of breaking news.

An object that certainly appears to be from this deployment is downlinking that 250k stream which turns out to contain IoT/LoRaWAN frames! While there are numerous commercial interests trying to get a foothold in the IoT market via satellite, this is the first time that I’ve actually captured this type of downlink over the U.S. (IoT/LoRaWAN is more common over Europe & surrounding areas).

This downlink appears to center around 437.360 MHz.

… and after the usual trial & error of reversing packet parameters with in-house replay testing, the 0x34 syncword indicates that this is probably an IoT/LoRaWAN payload:

… and sure enough, while everything except the Device Address (DevAddr) and Frame Counter (FCnt) fields are encrypted, the frame does decode as a valid LoRaWAN payload:

… obviously it’s very unfortunate to see this type of downlink in the Amateur spectrum.

7 Likes

GEOSCAN-1 Updated TLE

GEOSCAN-1
1 98559U          25207.18563185  .00000000  00000-0  49954-3 0    06
2 98559  97.4200 172.6204 0022180 107.1563  17.2202 15.21492870    01

3 Likes

GEOSCAN-2 Updated TLE

GEOSCAN-2
1 98558U          25207.18548637  .00000000  00000-0  49954-3 0    00
2 98558  97.4100 172.5054 0022955 120.1302   4.7956 15.21977925    03

3 Likes

To receive photos from Innosat16, you may try to look for packet with this structure:
Header: 11 98 3E 50 41
Offset: 38 00 00 (in this case it is 0x38)
Data: rest of the packet (at the end there are 8 bytes reserved and they are zeroes)
First packet of image transmission

11 98 3E 50 41 00 00 00 FF D8 FF E0 00 10 4A 46 49 46 00 01 02 00 00 01 00 01 00 00 FF DB 00 43 00 0A 07 07 08 07 06 0A 08 08 08 0B 0A 0A 0B 0E 18 10 0E 0D 0D 0E 1D 15 16 11 18 23 1F 25 24 22 00 00 00 00 00 00 00 00

Second

11 98 3E 50 41 38 00 00 1F 22 21 26 2B 37 2F 26 29 34 29 21 22 30 41 31 34 39 3B 3E 3E 3E 25 2E 44 49 43 3C 48 37 3D 3E 3B FF DB 00 43 01 0A 0B 0B 0E 0D 0E 1C 10 10 1C 3B 28 22 28 3B 3B 3B 3B 00 00 00 00 00 00 00 00
4 Likes

Thanks for that info!

So do you just assemble those frames one after the other into a single file?

And what image format is the resulting image? (JPG, PNG, etc.)

You just need to put data field at the offset (parsed from offset field). Then you will get an image in jpg format

2 Likes