Observation 9271897: METEOR M2-3 (57166) - bandwidth insufficently set?

wingattackplanr · May 8, 2024, 7:49pm

Could someone tell me why the bandwidth on my observations of the Meteor 2-3 (LRPT S-E RHCP D 72 kbps) emitter show as ~40kHz (-20 to 20) on the waterfall plot, when multiple other stations observations of the same emitter have waterfall plots that are 120-160kHz wide. I have not been able to decode anything from Meteor 2-3 despite seeing the RF and I believe it is because my bandwidth is being set too low and not capturing the necessary bandwidth. Is there an argument value I should configure to resolve this? is this a known issue with the airspy drivers?

Cheers

Example of a successful collection at 3x the bandwidth
https://network.satnogs.org/observations/9483285/

SA2KNG · May 9, 2024, 7:41am

LRPT does not have a entry in this list of modes that selects anything other than the default FM (and this runs at 48k). There are however a few modified stations out there, it is possible to add this to that list.

If you select the “IQ recording” modes a fsk flowgraph is used instead, that reads the baud and results in a recording wide enough.

wingattackplanr · May 9, 2024, 11:06pm

@SA2KNG ,

Thanks so much for the background. After doing some more digging I understand why, and a little about how a few folks are taking recordings, processing them and uploading the imagery. I appreciate the tip on making IQ recordings and after seeing some older posts about how, I took an IQ snap of the APT from NOAA18 and one LRPT from Meteor 2-3. After a few minutes of screwing around in SatDump, and figuring out the sample rate is 4x the listed baud rate, produced an image from both!

Thanks for making this community so welcoming to the less experienced.

Cheers

SA2KNG · May 10, 2024, 6:33am

Nice (:
We’ve been working on a script to run satdump on satnogs-client but hasn’t completed it yet. Feel free to experiment with it and contribute to it’s progress if you wish.

github.com

kng/satnogs-client-docker/blob/main/addons/scripts/satdump.sh

#!/bin/bash
if [[ ! "${SATDUMP_ENABLE^^}" =~ (TRUE|YES|1) ]]; then exit; fi
set -eu

# {command} {{ID}} {{FREQ}} {{TLE}} {{TIMESTAMP}} {{BAUD}} {{SCRIPT_NAME}}
CMD="$1"     # $1 [start|stop]
ID="$2"      # $2 observation ID
FREQ="$3"    # $3 frequency
TLE="$4"     # $4 used tle's
DATE="$5"    # $5 timestamp Y-m-dTH-M-S
BAUD="$6"    # $6 baudrate
SCRIPT="$7"  # $7 script name, satnogs_bpsk.py

PRG="SatDump:"
: "${SATNOGS_APP_PATH:=/tmp/.satnogs}"
: "${SATNOGS_OUTPUT_PATH:=/tmp/.satnogs/data/}"
: "${UDP_DUMP_PORT:=57356}"
: "${SATDUMP_KEEPLOGS:=no}"
BIN=$(command -v satdump)
LOG="SATNOGS_APP_PATH/satdump_$ID.log"

This file has been truncated. show original

There’s a few remaining steps on this implementation:

conf for what images to produce
waiting for that to complete
naming these properly for -client to upload.
removing all residual files

For testing it should be possible to replay the IQ dump and spit the data out as UDP, or just runt it on a few good observations and set SATDUMP_KEEPLOGS=yes so it doesn’t remove the results. Keep in mind that these results can be quite large, so storing them in /tmp (ram, tmpfs) might not be a good idea.