His .iq file is a 32-bit float, sample rate = 50,000
1 Like
Hi Bali,
Recorded using Advanced File Sink block. An enhanced version of the standard GNURadio File Sink block. See GitHub - N6RFM/gr-filerepeater_n6rfm: GNURadio block to play back files with delays between replays and/or limited replay counts. · GitHub for additional information.
It can be replayed using the standard GNURadio File Source block into whatever downstream blocks are desired.
Soxi needs a wav header. You can convert to a WAV that soxi can read:
sox -t raw -r 50000 -e floating-point -b 32 -c 2 scionX_50000SPS_437500000Hz_2026_09_28_T15-04-31Z_snip.iq out.wav
1 Like
ah this is the easiest path to open the file. no need convert to open on sdrpp.
super!
The middle of my 3 SCION-X packets tonight was the best I’ve gotten, but still not enough to decode. Where’s a 20-meter dish when you need one!
3 Likes
Thank you for the very comprehensive report! Based on what we know, the SCION-X spacecraft is functioning on orbit, but beaconing is sporadic. Due to the lack of NRZI and bit scrambling, the bit error rate in the decoded packets is not ideal, however we have been able to get some useful information by observing trends or states that are consistent across multiple beacon packets.
I am actually plesantly surprised that you found a high battery SOC. Post processing of past beacon packets showed that we were at a very low SOC and one of our 5 solar panels was generating an anomalously low current. I noticed in the report that you used Claude Opus 5.5 LLM. Was this used simply to generate code, or was there some application to signal processing or error correction?
The spacecraft was in a nominal state for the first 24 hours after launch, beaconing every 10 seconds. You can see a good example at: SatNOGS Network - Observation 14459039
The spacecraft abruptly went silent 24 hours after launch, but started beaconing again sporadically after about 4 days. This has been the case since then, punctuated by occassional periods of radio silence, or even what apparently looks like a recovery of regular beaconing as in: https://network.satnogs.org/observations/15051956/
Our spacecraft power bus is designed such that the subsystems will not be powered if the SOC is 0% and the spacecraft solar panels are not collecting sunlight. As we have recieved beacons from when the spacecraft was in eclipse, the sporadic beaconing cannot be attributed solely to low battery SOC, although it may play a role.
Our current working hypothesis is that the UHF communications anomaly is caused by impedence mismatch between our UHF transceiver and the UHF antenna, which eventually trips overcurrent protection on the power rails to the UHF transcever, causing its power to be cut and disrupting normal beaconing. We have been trying to correct this by commanding the spacecraft to reduce Tx power to low and increasing the interval between beacons. However, this has been complicated by tracking errors due to mis-identified objects (hopefuly not an issue now), as well as the high bit error rate in the beacon telemetry. If the spacecraft doesn’t receive any valid commands for 48 hours, it performs a hard reset, returning the state to factory settings.
Our UHF antenna was originally tuned using the spacecraft engineering model chassis. However, we found that when installed in the flight model chassis complete with solar panels, the central frequency of the antenna was way off the required value. It was observed that due to energy being reflected back to the UHF transceiver, the temperature of the power amplifier went up. This causes its efficiency to go down, leading to the transceiver drawing more electrical current to compensate. We re-turned the antenna and installed EMI absorbing material around the RF harnessing which semed to correct the problem. We also replaced the original UHF transceiver, which was damaged in the process. However, as we were close to the delivery deadline, we did not have time for longer duration functional testing. It is possible that the fix was not as good as we would have liked and that combined with continuous beaconing for 24 hours in a thermal vacuum environment, the power amplifier temperature would eventually trip overcurrent protection, thus explaining the sporadic beacons.
Thank you all for your support! I am still hopeful that we can work our way out of this problem and complete spacecraft commissioning. At any rate, it is providing more hands on educational oppertunities for our students!
4 Likes
Hi,
Yes, I have been using the LLM to both generate code and more recently develop a prototypical parser which tabulates the telemetry from the partial frames. Of course, the tricky part is that the complete header does not appear to be transmitted. This makes decoding quite an interesting challenge.
While Jan PE0SAT shared a link above to a spreadsheet describing the ScionX telemetry fields, that spreadsheet contains another Google Drive link to a different spreadsheet. Please provide a copy of that. I believe the file is here, but do not have access.
In the meantime, I have uploaded more results to the MEGA folder I have shared. Also added to the folder is a prototype parser written in Python and a report describing it. Hope that the team and all of the friends here will find this helpful and offer further advice on correcting any errors.
Best,
Bob
N6RFM
5 Likes
The document linked in your previous post containts the voltage and current ranges of the different spacecraft subsystems. It can be accessed here: SCION-X Subsystem Electrical Interfaces.xlsx - Google Sheets
Another spreadsheet linked in the telemetry file is the ADCS telemetry and command format. Because we are using a commercial off the shelf ADCS (CubeSpace CubeADCS), I am unable to share that document as it is covered by the NDA we signed with them. Your understanding is appreceated.
1 Like
Per the latest updates in space-track.org (for TR-17 objects, 2026-156), previously tracked NORAD ID for SENTINEL-1 (2026-156AE, 69897) is claimed by SPEAR-1C. We would appreciate it if you can track us under 2026-156J (OBJECT-J, 69877). Still at 402.000 MHz +/- 200 KHz.
Thanks
Wael Ibrahim
Ethereal Space
1 Like
Quite strong signal from KITA-36 on ~400.497 MHz. IQ recording is available at https://drive.google.com/file/d/1-qrdCD6rWivHiuWzflcdUIR2eYOmOzS-/view?usp=sharing if any of the experts would like to analyze/demodulate it.
2 Likes
I also have it in a bunch of observations from July–August:
But at least up to the beginning of August they also match 69932 very well.
2 Likes
suggested sat to DB and set frequency. 401.250
2 Likes
