I am unsure why there is such a strong supplemental signal with the FengYun satellites always beginning with a cut at ~-150kHz from the expected frequency propergating to ~-100kHz on the waterfall.
Also from other stations:
Is this by design/ another satellite / another transmitter/ etc.?
Those wider observations shows the DC spike from the SDR, the default tune offset is 100kHz so with the narrower 48kHz waterfalls it is not visible.
When using higher sample rates and doing wider observations you can increase the SATNOGS_LO_OFFSET to move it further away.
I’m running at 8MHz wide and based on least amount of spurs chose a offset of 2MHz, ofc this needs to be well within the sample rate and leaving room for the actual frequency of interest (:
Look at the metadata of obs 7872972.
samp-rate-rx: "8e6", lo-offset: "2e6"
On station 1918 it’s running at 5MHz, so 1MHz offset should be safe ?
That is a good point. Thanks! We missed the LO Offset while configuring and changed it to 1MHz.
The newest FengYun observation looks better than before and misses the DC spike.
Now we just need to figure out why suddenly the audio lenght is not matching with the waterfall. Will look into Observation failed but with waterfall and sound - #4 by SM0TGU
Sorry I have nothing new info about the audio length is not matching with the waterfall. I’m have no idea what to do next.
Also if you’re running plutosdr, make sure to set the BW to the closest filter available for that sample rate.
What hardware are you running this on ?
Reducing the sample rate of the Pluto solved the audio waterfall issue. This in turn possibly causes Satnogs to crash if high bandwidth satellites like Umka-1 or Birkeland are observed.
Hardware is a Pi4.