239Alferov over Brazil
!!
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
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
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
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
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
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.
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
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
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
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
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
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.
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.
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
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
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
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

























