Observation 3668657: NOAA 19 (33591)

Satellites & Observations Observations
1

Regarding these observations :
Observation 3668657
Observation 3669399

I don’t understand what happening !
The station has restarted this afternoon, after a hardware upgrade.

I never see this before ! Do you have you an idea ?

2

Hi.

The Observation looks like it caught a good signal / Waterfall but when it came to decoding things went wrong…
What was the Hardware Upgrade ? and was there a Software upgrade done at the same time ?

3

Could you copy/paste the result of Advanced => Support option in sudo satnogs-setup.

4

@fredy, here you see the informations support
------------[ copy here ]-------------
{
“versions”: {
“satnogs-client”: “1.4”,
“satnogs-client-ansible”: “202012231828”,
“satnogs-flowgraphs”: “1.3-1”,
“gr-satnogs”: “2.2.0.0-1”,
“gr-soapy”: “2.1.3.1-1”,
“gnuradio”: “3.8.2.0-2”,
“satnogs-config”: “0.11”
},
“state”: {
“is-applied”: true,
“pending-tags”: null
},
“system”: {
“date”: “2021-02-22T08:47:13.724969+00:00”,
“distribution”: {
“DESCRIPTION”: “Raspbian GNU/Linux 10 (buster)”,
“RELEASE”: “10”,
“CODENAME”: “buster”,
“ID”: “Raspbian”
},
“pending-updates”: true,
“platform”: {
“system”: “Linux”,
“node”: “F6KRKSatnogs”,
“release”: “5.10.11-v7+”,
“version”: “#1399 SMP Thu Jan 28 12:06:05 GMT 2021”,
“machine”: “armv7l”,
“processor”: “”
},
“memory”: {
“total”: 969105408,
“available”: 798949376,
“percent”: 17.6,
“used”: 101056512,
“free”: 137179136,
“active”: 378404864,
“inactive”: 369586176,
“buffers”: 54521856,
“cached”: 676347904,
“shared”: 1994752,
“slab”: 64876544
},
“disk”: {
“total”: 15348867072,
“used”: 4660547584,
“free”: 10018402304,
“percent”: 31.7
}
},
“configuration”: {
“satnogs_antenna”: “RX”,
“satnogs_api_token”: “[redacted]”,
“satnogs_post_observation_script”: “/home/pi/noaa_decoder/src/decoder_apt_from_rpi.sh {{ID}} {{TLE}}”,
“satnogs_rf_gain”: “10”,
“satnogs_rx_device”: “rtlsdr”,
“satnogs_rx_samp_rate”: “2.048e6”,
“satnogs_soapy_rx_device”: “driver=rtlsdr”,
“satnogs_station_elev”: “166”,
“satnogs_station_id”: “793”,
“satnogs_station_lat”: “48.778”,
“satnogs_station_lon”: “2.022”,
“satnogs_waterfall_autorange”: true
}
}
------------[ copy end ]-------------

For your information @ve6kdx the station is now composed of these elements :

5

It seems that you run a custom script for decoding apt, so I guess this is why you get these strange artifacts.

6

You are right I am using a custom script to decode images from APT signal and upload them to Satnogs.
Here is the link about my custom script : Automatic .ogg download
I don’t know if a built-in Satnogs script is available so I designed this script.

This custom script performed well up to this observation : https://network.satnogs.org/observations/3604734/
As you can see from 07/02/2021 I schedule METEOR observations and I also configured my station to decode LRPT images. To do this I follow instructions from Howto: Meteor M2 weather satellite image decoding

7

Hi, I compared an old and new observation. It looks like you have a stronger signal now. The waterfall scale is 20 to 30 db higher. Did you add an extra amplifier? Could be that it is overpowering the sdr. The signal could be too strong. Can you remove one (the ln4all) amplifier? I don’t think it is the scripts. But that is a guess.

8

I also think it could be the gain.
The gain of the last observation was set to 10 dB. I just set the gain to 3dB for the next passes.
Hope this setting will fix the problem.

9

Regarding the last observation Observation #3669405
The gain was to set to 3 dB and I deactivated my custom script.
The same issue appeared on image in the data tab.

I decreased the RF gain in the settings again.

10

change in sample rate? anything else running in the background consuming resources maybe??

What in general was the hardware upgrade? SDR? microSD? RPi? USB 2 <–> USB3?

11

Good point, there are indeed lost samples, you can say that from the short audio duration. In Observation #3669405 the duration of the scheduled job and the waterfall are around 11min while the audio is around 7.5min.

@f4hvq check the logs and see if you can spot any O’s or o’s which means lost samples. Can you also describe the hardware changes?

12

If sample were lost, wouldn’t that affect waterfall and audio equally?

13

I think I have seen some cases in which it affects only the audio. Maybe I’m wrong… I guess @surligas could give us some hint if this can be possible.

14

From the observation Observation 3674515 I modified the sample rate setting 2048 → 1024. APT images seems OK.

Could you please explain why this modification resolve the problem ?

@f4hvq check the logs and see if you can spot any O’s or o’s which means lost samples. Can you also describe the hardware changes?

I didn’t find any log with lost samples. @fredy Can you specify log path(s) I can check ?
Bellow here is the output of “journalctl” command:

pi@F6KRKSatnogs:~ $ journalctl -u satnogs-client.service
-- Logs begin at Thu 2019-02-14 10:11:59 UTC, end at Tue 2021-02-23 19:44:47 UTC. --
Feb 23 18:27:40 F6KRKSatnogs systemd[1]: Started SatNOGS client.
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: rot_init called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: dummy: _init called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: rot_register (1)
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: rot_register (2)
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: dummy_rot_init called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: rot_open called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: dummy_rot_open called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: rot_get_position called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: dummy_rot_get_position called
Feb 23 19:01:10 F6KRKSatnogs satnogs-client[409]: rot_set_position called
Feb 23 19:01:16 F6KRKSatnogs satnogs-client[409]: Found Rafael Micro R820T tuner
Feb 23 19:01:16 F6KRKSatnogs satnogs-client[409]: [INFO] Opening Generic RTL2832U OEM :: 00000001...
Feb 23 19:01:17 F6KRKSatnogs satnogs-client[409]: Found Rafael Micro R820T tuner
Feb 23 19:01:17 F6KRKSatnogs satnogs-client[409]: [R82XX] PLL not locked!
Feb 23 19:01:17 F6KRKSatnogs satnogs-client[409]: [INFO] Using format CF32.
Feb 23 19:01:18 F6KRKSatnogs satnogs-client[409]: Allocating 15 zero-copy buffers

The station is now composed of these elements:

  • Antenna : 137 MHz V-dipole antenna (based on model : LNA for all: DIY 137 MHz WX SAT V-dipole antenna)
  • 137-138 MHz pre-amp (closed to antenna)
  • 50 meters coax cable
  • 13.8 V Bias tee to power the pre-amp (closed to antenna)
  • 137-138 MHz (NOAA) band pass filter (OM) + LNA4ALL
  • RTL-SDR (V3 R820T2 RTL2832U 1PPM TCXO)
  • RPi 3B+

A 13.8 V Bias tee was added to power the pre-amp (closed to antenna)

15

O’s would be visible in journalctl.