Both me and @dereksgc have been having this issue, some observations where this happens:
(there are more examples of this but I can’t put more than two links in a post)
I have never had this problem before with the exact same setup and gqrx/sdrpp.
Both me and @dereksgc have been having this issue, some observations where this happens:
(there are more examples of this but I can’t put more than two links in a post)
I have never had this problem before with the exact same setup and gqrx/sdrpp.
Hi @xerbo
[edited, sorry I missed the ORBCOMM reference in the subject]
I just took a look at some other NOAA-18 observations in the UK and see something similar in the couple I checked
Observation 6397327
Observation 6399219
Here’s a link for all NOAA-18 SatNOGS observations that have data uploaded for your reference.
Whatever is happening, it’s not specific to your hardware/software from what I can see
satcolintel5 (from reddit/amateursatellites a long time ago! )
I can confirm that ORBCOMM does not use these frequencies in reality (their band plan was specifically set up to not interfere with weather sats), and while this seems to be common on SatNOGS it has never happened to me outside of it with just SDR#.
Personally I think this should be looked into, because if it is also affecting other satellites besides NOAA/ORBCOMM it could be having a real impact on the overall efficiency of the SatNOGS network (RFI spikes could be aliased as well, who knows how many stations are suffering from those, and it wouldn’t surprise me if its also resulting in a slightly higher noise floor).
I posted a link to this thread on the SatNOGS matrix board to get more input. I don’t have a VHF antenna any longer to test this.
@dereksgc @xerbo It would be a good starting point if you could post your satnogs-client setup configurations.
sudo satnogs-setup
→ Advanded → Support
so versions of various components are known. Any info on LNA/filters being used too.
EDIT: no filter or LNA in use
EDIT2: the current gain set is configured for the L-band, I believe for VHF it was lower (I fine-tuned the gain with a laptop connected to the exact same setup to see what is the lowest value I can use without losing SNR)
------------[ copy here ]------------
{
"versions": {
"satnogs-client": "1.6",
"satnogs-client-ansible": "202109022142",
"satnogs-flowgraphs": "1.4-1",
"gr-satnogs": "2.3.1.1-1",
"gr-soapy": "2.1.3-1",
"gnuradio": "3.8.2.0-2",
"satnogs-config": "0.12"
},
"state": {
"is-applied": true,
"pending-tags": null
},
"system": {
"date": "2022-08-29T16:35:11.700271+00:00",
"distribution": {
"DESCRIPTION": "Raspbian GNU/Linux 10 (buster)",
"RELEASE": "10",
"CODENAME": "buster",
"ID": "Raspbian"
},
"pending-updates": true,
"platform": {
"system": "Linux",
"node": "raspberrypi",
"release": "5.10.63-v7+",
"version": "#1496 SMP Wed Dec 1 15:58:11 GMT 2021",
"machine": "armv7l",
"processor": ""
},
"memory": {
"total": 448774144,
"available": 215105536,
"percent": 52.1,
"used": 180535296,
"free": 140201984,
"active": 67395584,
"inactive": 187887616,
"buffers": 7159808,
"cached": 120877056,
"shared": 716800,
"slab": 28454912
},
"disk": {
"total": 62746816512,
"used": 3714441216,
"free": 56428318720,
"percent": 6.2
}
},
"configuration": {
"satnogs_antenna": "RX",
"satnogs_api_token": "[redacted]",
"satnogs_rf_gain": "43.3",
"satnogs_rx_samp_rate": "2048000",
"satnogs_soapy_rx_device": "driver=rtlsdr",
"satnogs_station_elev": "485",
"satnogs_station_id": "2571",
"satnogs_station_lat": "49.6",
"satnogs_station_lon": "14.9"
}
}
------------[ copy end ]-------------
My installation lacks satnogs-setup for some reason (it runs in docker with satnogs-client-docker) but here are the important details, I’m using a NooElec LaNA.
.env
SATNOGS_API_TOKEN="[redacted]"
SATNOGS_STATION_ID="2791"
SATNOGS_STATION_LAT="50.8"
SATNOGS_STATION_LON="-0.7"
SATNOGS_STATION_ELEV="60"
SATNOGS_SOAPY_RX_DEVICE="driver=rtlsdr"
SATNOGS_RX_SAMP_RATE="1.024e6"
SATNOGS_RF_GAIN="23"
SATNOGS_ANTENNA="RX"
SATNOGS_LOG_LEVEL="INFO"
SATNOGS_POST_OBSERVATION_SCRIPT="/usr/bin/satnogs-post {{ID}} {{FREQ}} {{TLE}} {{TIMESTAMP}} {{BAUD}} {{SCRIPT_NAME}}"
free -h
total used free shared buff/cache available
Mem: 1.4Gi 373Mi 289Mi 0.0Ki 746Mi 1.0Gi
Swap: 976Mi 1.0Mi 975Mi
df -h
Filesystem Size Used Avail Use% Mounted on
overlay 27G 6.2G 20G 25% /
...
Hi all. I did some measurements on the satnogs_fm.py flowgraph, described here.
I think I can confirm there seems to a odd imaging problem in it. I set an obs manually running the noaa 18 frequency 137.912MHz at 2msps, then swept my crtu-ru from 137 to 139 in 10kHz steps synchronized to each second, so 30s should be 137.300MHz in the waterfall.
It seems to have something to do with the 100kHz tuning offset in the tuning to avoid the dc spike.
So I’m guessing it’s somewhere in the satnogs_doppler_correction() ?!
EDIT: the two frequencies that can be seen in the center is 137.912MHz as expected, then also 137.766MHz, so - 146kHz, close to 3*48 (48 is audio samp rate) ?!
This is very interesting, since I have the same problem with interference in the 2m amateur satellite band.
When I installed my SatNOGS station a while ago, I did not had such problems and apart from sporadic local noise, the band was quite clean.
FM repeater outputs in our region are directly below the 145.800 MHz in 12,5kHz raster.
I don’t know when it happened, but sice 1 year ago or so, the above FM repeater outputs are mirrored into the 145.800 to 146.000 part. I can even identify which repeater these are… some are even further away.
This is indeed very annoying. I was hoping a more recent update would cure the problem, but it’s persistent…
So perhaps this is the same issue…
gr satnogs !304 should fix this, for now I manually edited dopper_compensation.py with this change
That’s a good idea. I have also edited the doppler compensation file. First three observations on my station 2015 look good. Thanks!