So for FossaSat-1, what demodulator is going to be best to capture the signals transmitted?
Clearly the 125 kHz LoRa signal is too wide to be captured within the passband of any of the current demod flowgraphs, so we wonāt even be able to capture wide enough IQ for analysis. Maybe we need a āgeneric waterfall + IQ onlyā flowgraph for situations like these?
As for the RTTY signal, that really needs a single-sideband demodulator. The CW demod flowgraph is the only one of these we have at the moment. As an interim step, maybe set this sats transmitter to CW, so thereās a chance of getting some audio that can be demodulated in something like fldigi? The 3 kHz passband is going to mean it might take a few tries to get the signal lined up right, depending on drift, etcā¦
Hey guys, FossaSat-1 builder here As you know first 24 hours are critical for knowing if the mission is succesful (even if we canāt decode stuff we can know if the antennas and solar panels deployed from the signals) so any detecting is really really useful, especially fist hours where we have no coverage.
As clarification of the above, āclamp releaseā essentially means launch time. Currently scheduled for 07:56:22Z, but may be delayed (which means the TLE will need to be recomputed).
Transmitters are now in DB and the first observations are scheduled.
Two notes:
For Fossasatās RTTY we selected BPSK1k2 mode as it may let us decode it as for this mode stations use bpsk gr-script instead of the generic FM one
We have scheduled for the first 5 hours, given that the launch will be at 2019-11-29T08:20:00Z, if you want to schedule for later please donāt go to far in the future as the TLE may change before or after launch.
Hey Everyone, first pass on a SATNOGS station will be aprox from 11:24:25 until 11:30:49 on South Australia Stations (Not sure which one is the . Then we will get a pass over the 453 - IFSC-SJ station from 11:54:29 until 12:01:10. Is it possible to program observation on these stations?
I will keep you guys updated. On everything, maybe someone can do some pass predictions using the TLEās
Our MFSK modulation scheme is nonstandard due to the radio chip we used.
Can the SatNogs MFSK demodulation deal with 156.25 Hz frequency steps?
If not, I would suggest to use upper sideband instead (zero-frq starting like 2kHz lower: 437.073), so the data could be preserved in the audio.
Alternatively CW that preserves the band around 437.075 as audio.
The bandwidth is 3kHz, but - if possible - a wider bandwidth would be better in case we are a bit off.
Agreed, I think a better approach is to do the same as being used for Fossasat-1, which is to use the BPSK Demodulation flow-graph, which will save USB-demodulated audio (and completely fail to demodulate any BPSK, but thats OK). The BPSK demodulator automatically aims for the signal to be at a 1.5 kHz IF in the demodulated audio, so there should be no need to adjust the RX frequency from the nominal.
The CW decoder does the same, but it will likely mistakenly decode some CW data, which will cause the observation to be incorrectly flagged as valid (known issue).
Iām pretty sure the RX will be off-frequency initially, due to TLE inaccuracies and other drift. A few stations (mine included) are set up to save IQ data, so that will help.
Old-school SiLab chipā¦ Hopefully the reference is something stable-ish?
Any more details on the modulation? Iām wondering if I can throw together a demodulator using David Roweās fsk_demod utility. We use a 4FSK downlink on our high-altitude balloon flights, also modulated using a Si4432 (on a recovered an reprogrammed Vaisala RS41 radiosonde) - some info on this here.
Yes, on my site I put details about demodulation: www.uac-lab.com, under the tab āTRSI Sat infoā.
You can find I/Q-WAVs there, recorded under different RX conditions.
Some other thing:
A year ago or so I wrote a baseband codec which LOSSLESSLY compresses the huge recorded I/Q-WAV into a 40kHz baseband I/Q with only 20kbyte/sec - with the hope it would be integrated into SatNogs. ItĀ“s really the raw data, preserving all phase information losslessly stored.
I have put the encoder/decoder into GitHub, itĀ“s plain C code, has been compiled on Raspi by a comunity member (long ago, I already forgot who took care of porting it, must be in the logs somewhere), but I unfortunately didnĀ“t have time to take care of it anymore. It looks that this codec is just rotting away. ItĀ“s a pity, because raw data is extremely valuable when there is no demodulator around. It could be demodulated even years later, and the specific observation would not be lost. This could be a valuable tool, as it really doesnĀ“t create big files, and the decoder creates a standard I/Q-WAV from the compressed file.
(It makes I/Q frequency shifting, sharp low pass filtering with practically no overshoots, Huffman encoding of sample differences and creates/restores an I/Q wave with a selected bandwidth and frequency shift. No zero-frq errors, fast processing, generates standard WAVs, readable with HDSDR or SDR#, command line examples included. ItĀ“s only for 8bit waves, time was too low to include a 16bit version, but WAVs could be downconverted before compressing)
As you know first 24 hours are critical for knowing if the mission is succesful (even if we canāt decode stuff we can know if the antennas and solar panels deployed from the signals) so any detecting is really really useful, especially fist hours where we have no coverage.
