Hi, from 11-10-2022 19:39 Dutch local time , so 17:39 UTC till about 14 hours later I recorded the 436 MHz satellite band from Airspy 5 MHz wide with 6 el yagi pointing north and Upu 435 filtered preamp. This morning I did run the data file analyser from SDR Console with it and played back a lot of signals from the waterfall which was created. A screenshot from the signals is attached
Around 21:46 I notice some data type signals which I could easily play back from the recording and noticed the transmissions sound like pager type (pocsag ?) modulation. However my pocsag decoder shows no interest in this audio.
I randomly played some of the transmissions while recording audio in WFM, audio file attached.
I had my first view in the Satnogs DB for transmitters today but I don’t see a matching modulation type for the signals I do hear.
the dropbox link contains the MP3 audio recording.
What are the scales of the waterfall axis? I guess 5MHz width but what is the time scale?
The reason I’m asking is that there seems to be very little doppler shift in the signal. If that’s correct, the signal source is likely terrestrial, not in orbit.
We can try mulimon-ng -a POCSAG512 -a POCSAG1200 -a POCSAG2400 to try and decode this signal.
multimon-ng -h
multimon-ng 1.2.0
(C) 1996/1997 by Tom Sailer HB9JNX/AE4WA
(C) 2012-2022 by Elias Oenal
Available demodulators: POCSAG512 POCSAG1200 POCSAG2400 FLEX FLEX_NEXT EAS UFSK1200 CLIPFSK FMSFSK AFSK1200 AFSK2400 AFSK2400_2 AFSK2400_3 HAPN4800 FSK9600 DTMF ZVEI1 ZVEI2 ZVEI3 DZVEI PZVEI EEA EIA CCIR MORSE_CW DUMPCSV X10 SCOPE
Usage: multimon-ng [file] [file] [file] ...
If no [file] is given, input will be read from your default sound
hardware. A filename of "-" denotes standard input.
-t <type> : Input file type (any other type than raw requires sox)
-a <demod> : Add demodulator
-s <demod> : Subtract demodulator
-c : Remove all demodulators (must be added with -a <demod>)
-q : Quiet
-v <level> : Level of verbosity (e.g. '-v 3')
For POCSAG and MORSE_CW '-v1' prints decoding statistics.
-h : This help
-A : APRS mode (TNC2 text output)
-m : Mute SoX warnings
-r : Call SoX in repeatable mode (e.g. fixed random seed for dithering)
-n : Don't flush stdout, increases performance.
-j : FMS: Just output hex data and CRC, no parsing.
-e : POCSAG: Hide empty messages.
-u : POCSAG: Heuristically prune unlikely decodes.
-i : POCSAG: Inverts the input samples. Try this if decoding fails.
-p : POCSAG: Show partially received messages.
-f <mode> : POCSAG: Overrides standards and forces decoding of data as <mode>
(<mode> can be 'numeric', 'alpha', 'skyper' or 'auto')
-b <level> : POCSAG: BCH bit error correction level. Set 0 to disable, default is 2.
Lower levels increase performance and lower false positives.
-C <cs> : POCSAG: Set Charset.
-o : CW: Set threshold for dit detection (default: 500)
-d : CW: Dit length in ms (default: 50)
-g : CW: Gap length in ms (default: 50)
-x : CW: Disable auto threshold detection
-y : CW: Disable auto timing detection
--timestamp: Add a time stamp in front of every printed line
--label : Add a label to the front of every printed line
Raw input requires one channel, 16 bit, signed integer (platform-native)
samples at the demodulator's input sampling rate, which is
usually 22050 Hz. Raw input is assumed and required if piped input is used.
Here an example I use to decode POCSAG in combination with GQRX udp out.
#!/usr/bin/env bash
#
nc -l -u 7355 | \
sox -t raw \
-esigned-integer \
-b16 -r 48000 - \
-esigned-integer \
-b16 -r 22050 -t raw - | \
multimon-ng -t raw \
-a AFSK1200 -a FLEX -a POCSAG1200 -f alpha -
Hi Jan, I made a fresh recording of the same spectrum last night, I will have a look if the same signal appears again and make a small bandwidth IQ file of the pass. If it’s not there I will do the same from the recording from 4 days ago. Going to try if multimonng runs in WSL too
I downloaded the windows 32 bit version and tested with regular pocsag transmissions and that decodes Now waiting for the analiser to make me a nice waterfall for 17.55 hours of recording
So the good news is the signal appeared again in the recording from 13-10 to 14-10, 20:18 utc time and a bit weaker. About 20 minutes earlier as the 2 days before, the 21:48 utc pass was almost unreadable in the waterfall.
So far no decodes with Multimon-ng, now recording the same frequency with only 625 kHz bandwidth.
Now let’s make things a bit more complicated. The recording from 14-10-2022 showed the same modulation type at around 437.140 centered, 20:19 UTC at 437.144 MHz and 20:23 UTC at 437.136 MHz.
However, same modulation type also appeared 19:52 UTC at 437.170 and dopplered down to 437.166 at 19:56 UTC.
Allright, played around with a short recording, to get the feeling. First I adjusted the gain for the rtl_sdr with rtl_tcp, settled for 22.9 dB. After running rfplot I notice I have to adjust Zmax to about 18 - 20, which I can use as fixed setting in the rfplot, but appears way off compared to the 0.01 or 0.05 values from the web instructions ?
Note that this rtl has no tcxo and is not compensated for ppm so the actual image has no value for any conclusions, just to show what I get.
So, indeed after some crash course and some “fun playing with strf” topic reading I managed to get both ISS on 437.800 and VZLUSAT-2 identified
So I did run the same on the recording for the 18th of October. used the -s to get the starting bin about 5 minutes before the transmissions where in my reach.
Tried with s to set, tried with D to set, but trace not identified so far.
but I don’t see a matching modulation type for the signals I do hear.
