@PE0SAT @K4KDR Thank you for your reception reports! Please PM me with your mailing address at loren@g.ncu.edu.tw if you would like a physical QSL card.
2 Likes
SCION-X reception in Greece at 08:00:27 and 09:35:01 UTC.
IQ recordings available at Upload files for free - 2026-09-24 SCION-X.rar - ufile.io
4 Likes
Thanks for the offer,
In the meantime can you share some details on TLM and howto decode it?
Is the assumption correct that SCION-X is using SPINO framing?
Thanks in advance,
Jan | PE0SAT
1 Like
Hi Merkouris,
Unfortunately, I am unable to download the Scion-X IQ. Is there another link to try?
Thanks,
Bob
Hi Bob,
Three IQ files, the 93750 sample rate are from Merkouris, the other one if I remember correctly is from one of the team members.
Jan | PE0SAT
2 Likes
Hi Bob! Here it is https://drive.google.com/file/d/1JwxUSukkxAiW8co3DUQ8-3YcQvMoUQ_r/view?usp=sharing
1 Like
Thanks Jan!
1 Like
Thanks Mercouris and Jan!
b.
2 Likes
@sv2hwm @N6RFM It seems there is something wrong with 09-33-17_437498418Hz.wav / iq_093317_437498418_93750.wav I am unable to open the file for replay, the other is fine.
Jan | PE0SAT
It’s quite strange. I suspected that the first recording might be problematic because I had trimmed it and saved only the one-minute segment containing the strong packet using Audacity. The second one is exactly as recorded by SDR#. In any case, both files can be loaded into SDR# here. 
EDIT: I’ve just checked the file on your website. Here, it can be replayed without any problem.
1 Like
Thanks both for the files. Tried numerous approaches. So far, the only file that can be decoded is 0317_iq_ver1.bin referenced in the GitHub - JacyyChang/scionx-decode-writeup: GFSK/9600bps HDLC-AX.25 decoding stalls at CRC for a CubeSat (SCIONX) recording from SatNOGS — sharing the diagnostic pipeline and asking the community for a fix. · GitHub repo. This is an IQ file btw. The other files kindly shared certainly have signals which seem a bit weak.
Looking at the repo results, what seems to have emerged is SCION-X uses plain NRZ, no NRZI, no G3RUH scrambling — non-standard for gr-satellites’ built-in AX.25 presets, which assume NRZI.
We clearly need data with better SNR and more information from the team.
Cheers,
Bob
N6RFM
3 Likes
Hi @PE0SAT . We are using AX.25 framing for our telemetry.
Decoding is difficult because our student team did not have enough time to implment NRZI and bit scrambling. As a result, clock synchronization is difficult and the bit error rate is high. We have had some luck in recovering some useful telemetry using AI tools.
You can see our current efforts at decoding, including code and documentation at: GitHub - JacyyChang/scionx-decode-writeup: GFSK/9600bps HDLC-AX.25 decoding stalls at CRC for a CubeSat (SCIONX) recording from SatNOGS — sharing the diagnostic pipeline and asking the community for a fix. · GitHub
2 Likes
69892 ICEYE-X77 detected on 2263.500 MHz
Not confirmed yet
1 Like
@PE0SAT Also, here is the SCION-X beacon telemetry format:
3 Likes
Ref. SCION-X, not the news I was hoping to report. The pass tonight in the 0345-0400 UTC time frame produced NO visible signals. This was a medium elevation pass in VA but a much higher pass over Bob’s (N6RFM) station in RI.
Will keep watching!
3 Likes
The same was observed here in Greece a little earlier, during a 56° max el pass (2026-09-25, 21:22 - 21:34 UTC).
3 Likes
2026-09-26 21:31-21:43 UTC No signal from SCION-X
2 Likes
Good news - SCION-X transmitting again over the Eastern U.S. 0415utc 28-Sept. on the 200-sec interval.
Unfortunately, still not enough SNR to decode.
4 Likes
Dear Friends,
Scott K4KDR and I have been working diligently to receive some SCION-X frames suitable for further analysis.
Today, I was fortunate enough to receive a frame with a decent SNR.
However, I was unable to decode this frame using standard GNURAdio based tools. In parallel, I have been employing the Claude LLM to examine earlier bursts received at my FN41iq QTH in Bristol, RI. Again, without success until today.
Summary
Frame N6RFM-20260928-150431Z was received error-free from frame byte 48 to the end
of its FCS, but its first 48 bytes, including both callsigns, were never transmitted. So the
frame decodes to real telemetry, yet cannot be CRC-verified. No idea why this is happened, and if it occurs routinely.
Received: frame bytes 48–273 (226 bytes, 1,809 bits after destuffing), at about 24 dB
in-band SNR, with zero marginal bit decisions.
Missing: bytes 0–47. The carrier switches on about 40 ms into the frame. There is no
radiated energy before that anywhere in the 50 kHz capture. A second, weaker frame
from the same pass starts at the same point.
Header: not in this frame. The 11 independent SatNOGS flight frames of 7 July 2026 all
read BN0CU → BN0SCX , UI frame, PID F0, which is what this frame would have carried.
That is inference from those frames, not reception.
CRC: could not be used. The first 48 bytes include a timestamp, a previous-packet
timestamp and counters that change every beacon, which is far more unknown bits
than CRC-16 can resolve.
Transmitter anomaly: at frame byte 181 the satellite omitted a mandatory HDLC
stuffing bit. A standard receiver deletes a real bit there and fails the CRC even on a
perfect signal.
Telemetry at 15:04:31Z: battery 8.230 V at 90.98 % state of charge, charging at +0.951
A, about 1.66 A from the solar panels. UHF radio at −11 °C on 437.500 MHz. ADCS, X-
band and payloads off. 17.9 h left on the command-loss hard-reset timer.
My question - Given the above telemetry is the satellite otherwise healthy? At first glance, looks that way to me. 
What might the team do to restore proper header transmission timing (assuming this is a real issue or can be worked around by other means)
A more detailed report and the IQ file from today may be found at -
Hope this is helpful to the team.
Good Hunting All,
Bob
N6RFM
7 Likes
hi bob, what app you use to create this iq file? i trying to see information using soxi and convert using sox, but failed. thank you