Almost didn’t bother with today’s BusanSat pass but even at a max elevation lower than is ideal for my location, the strongest 38k4 S-Band downlink I have seen from this satellite thus far!
https://x.com/scott23192/status/2060407218382479711
… Oh, I did email the address in the payload but no reply (so far).
After several nights of no S-Band downlinks from BusanSat, it was great to see those 38k4 packets again!
… at a max EL of only 57°, I didn’t know if there would be enough SNR to decode anything, but a few were just strong enough.
… I never got a reply from the email address in the payload body, but at least I tried to make contact. Still can’t believe we’re decoding frames from an S-Band downlink; I never really expected that to happen (since S-Band signals are often weaker and/or the modulation is beyond my abilities)!
launch-cas500.txt (1.9 KB)
sites.txt (1.2 KB)
14244742.dat (280 Bytes)
14244555.dat (140 Bytes)
Nulink-1 on 2217.995 MHz
Created the following gr-satellites Yaml file to decode the Gemini-Pollux frames.
name: GEMINI-POLLUX
norad: 69000
data:
&tlm unknown telemetry:
unknown
transmitters:
1k2 BPSK AX.25 G3RUH downlink:
frequency: 436.500e+6
modulation: BPSK
baudrate: 1200
framing: AX.25 G3RUH
data:
- *tlm
9k6 BPSK AX.25 G3RUH downlink:
frequency: 436.500e+6
modulation: BPSK
baudrate: 9600
framing: AX.25 G3RUH
data:
- *tlm
Decoding observation 14339994
gr_satellites GEMINI-POLLUX.yml --rawint16 iq_14339994_436500000_48000.wav --samp_rate 48000 --iq
***** VERBOSE PDU DEBUG PRINT ******
((transmitter . 1k2 BPSK AX.25 G3RUH downlink))
pdu length = 223 bytes
pdu vector contents =
0000: 9c 9e 86 82 98 98 e2 9c 9e 86 82 98 98 61 03 f0
0010: be 04 42 00 00 9a 81 00 00 02 63 ac ff 88 00 ab
0020: 09 37 00 24 00 8f 00 50 09 00 00 00 00 ec 39 02
0030: 00 56 03 d2 0b 75 09 76 02 f1 01 52 09 14 a9 06
0040: 00 60 02 00 00 00 0c 0e a5 ff 03 07 2b 03 e9 07
0050: ec 04 cb 04 84 00 00 00 00 00 00 1e 00 00 00 0a
0060: d2 2c 8e a1 00 00 00 00 1c c0 00 00 00 48 00 00
0070: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 6c 60
0080: 08 07 8e 98 00 00 00 11 00 00 00 0f a8 80 00 00
0090: 00 40 78 00 00 00 00 00 00 6c 60 08 70 a5 a5 a5
00a0: a5 00 e5 ec 00 00 ff 0a 11 a5 a5 67 99 e0 e2 03
00b0: 04 fd 44 fd 12 00 00 00 00 00 a5 00 00 00 00 40
00c0: d2 b5 ae 42 1a 28 e4 a5 00 50 06 01 02 03 fe 03
00d0: 03 03 eb d5 a6 10 ff ef ff e0 00 a5 ff a5 ed
************************************
Jan | PE0SAT
Thanks for the heads-up on Gemini-Pollux, Jan!
As of my own RX tonight (which didn’t quite have enough SNR to decode), as well as the following SatNogs observation:
https://network.satnogs.org/observations/14388833/
… it appears to have switched to 9k6 BPSK.
Since the last few SatNogs Observations for Gemini-Pollux clearly had 1k2 packets in the waterfall, that’s what I setup for on tonight’s pass.
So naturally when it did finally transmit, it was 9k6!
… but, that’s ok - that is what I/Q replay is for. Using GNU-Radio + gr-satellites for the 9k6 BPSK AX.25 decode -and- upload to SatNogs, each of the frames was uploaded w/ its correct timestamp.
I’ve changed back to active the 9k6 transmitter for Gemini-Pollux, thanks for the update @K4KDR!
And over Europe 2026-06-30 09:52:36 it was back to 1k2, it is also strange to see that the AX.25 information is NOCALL when in 1k2 mode.
gr_satellites GEMINI-POLLUX.yml --rawint16 iq_14404836_436500000_48000.wav --samp_rate 48e3 --iq
-> Packet from 1k2 BPSK AX.25 G3RUH downlink
Container:
header = Container:
addresses = ListContainer:
Container:
callsign = u'NOCALL' (total 6)
ssid = Container:
ch = True
ssid = 1
extension = False
Container:
callsign = u'NOCALL' (total 6)
ssid = Container:
ch = False
ssid = 0
extension = True
control = 0x03
pid = 0xF0
info = b'\xbe\x04\xb0\x00\x00\xadY\x00\x00\x01S\xb8\xff\x8c\x00|\x08<\x00%\x00\x8e\x00Z\t\x00\x00\x00\x00\xec9\x02\x00[\x03\x8e\x0b\x9d\x08\xc6\x02\xf4\x01Y\t\x14\xa9\x06\x00\x9e\x00\x00\x00\x00\x0c\x08\xa5\xff\x03\x07$\x02\xd5\x06\xe5\x03\xd0\x04w\x00\x00\x00\x00\x00\x00\x1e\x00\x00\x00\n\xd2,\x8d\xa1\x00\x00\x00\x00\x1c\xc0\x00\x00\x00H\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x00l`\x08\x07\x8d\x98\x00\x00\x00\x11\x00\x00\x00\x0f\xa8\x80\x00\x00\x00@x\x00\x00\x00\x00\x00\x00l`\x08p\xa5\xa5\xa5\xa5\x00\xa2=\x00\x00\xf9\n\x11\xa5\xa5g\xa3\x93Z\x03\x04\xfc\xe0\xfc\xe7\x00\x00\x00\x00\x00\xa5\x00\x00\x00\x00\xbf\xd1\xb9\xa5\xc2w\x90\x1d\xa5\x00P\x06\x01\x02\xfe\x03\xf0\x04\x034\x05\x7f\x10\xff\xd9\xff\xd5\x00\xa5\xff\xa5\xed' (total 207)
Maybe someone of the team can explain this behavior ?
Update, looking at this observation there is 1k2 and 9k6, I have a theory, most BPSK G3RUH radio’s are build by ISISPACE in the Netherlands, maybe there ground station in Delft is commanding the satellite.
Jan | PE0SAT
Interesting, so I guess we should keep both 9k6 and 1k2 as active in DB. I’m on it…
