Regular IRC meeting for SatNOGS

network
db
client

#1

The weekly SatNOGS status meeting is back!

It will take place every Thursday at 18:00UTC , on #satnogs-dev channel @FreeNode IRC network (also accessible via riot.im. The agenda will include:

  • News
  • Updates
  • Discussions and decisions about SatNOGS
  • State of the project
  • Outstanding issues

The duration of the meeting will be kept as sort as possible.


Regular IRC meeting for SatNOGS client
#2

Orga pad for the next meeting, 2018-11-06 18:00 UTC:
https://hackmd.io/svR43goXTlG8U28DXusKRA?both


#3

The meeting will take place on the new developers’ IRC and Matrix channel #satnogs-dev.


#4

For those who are using matrix, follow this link to join https://riot.im/app/#/room/#satnogs-dev:matrix.org


#5

Logs from 2018-12-20 meeting


#6

Logs from 2018-12-27 meeting


#7

Since I had to step off during the meeting, here are some comments on the waterfall discussion.

[21:03:56] “on the power domain, the conclusion was that 8bits are enough by default” <-- This gives us 256 steps which if mapped to a range of -110 - -40 dBm gives approximately 0.3dB resolution
[21:05:19] Also, this is the worst case scenario in which noise is -110dBm while signal is -40dBm. Normally the range will be dynamic an “normalized” to the maximum and minumum observed in the waterfall
[21:11:34] back to waterfalls: on the power domain we have defined 3 attributes that characterize the waterfall and must be part of the metadata that are associated with it:
[21:11:57] Power resolution (in dBm, 8bit)
[21:11:57] Power minimum (in dBm, 8bit)
[21:11:57] Power maximum (in dBm, 8bit)
[21:12:43] 8 bits is the default value and can be configurable by the station owner in settings in cases she/he needs better resolution

Here we need to be careful. A strong unrelated terrestial signal could
strongly raise the maximum value, such that a weak signal gets lost in
the noise. What is more important, the accurate representation of the
strenght of a strong signal, with the risk of losing a weak signal, or
clipping a strong signal while retaining information on weak signals?

My preference would be to set dynamic limits (minimum and maximum),
based on the data of each spectrum. In other words, for each spectrum
in the waterfall file the mean and standard deviation is computed and
used to set a minimum and maximum power value, for example min =
mean-2standard deviation, while max = mean+3standard
deviation. These minimum and maximum values are then stored with each
spectrum such that the spectral values, represented by 8 bit integers,
can be converted back to floating point values that represent the
original signal.

[21:07:17] that means that if a the artifact is a PNG image, it will still be a PNG image inside the container
[21:07:40] If it is a tar, it will remain a tar
[21:08:17] But the idea is everything to be HDF5 so that we have common handling of artifacts

Note that HDF5 can store arrays as well, so my suggestion would be to
store the waterfall data as 8 bit integers in the HDF5 with additional
arrays representing the minimum and maximum values (as floats), and
arrays for time and frequency.

[21:32:22] “on the frequency domain we’ll be having somehting similar” 3 values
[21:32:44] center frequency, bandwidth and FFT bins

Agreed, this is all that’s needed.

[21:39:13] on the time domain again 3 values but we can skip the timespan size since it is infered by the size of the file
[21:39:30] So we will be having update interval and start timestamp

I strongly disagree with this approach as it does not account for
overflow/packet loss in the GRC script. The approach I use for the
timestamped waterfalls generated by STRF is to average, say, 100
consecutive spectra over a second of time, and store the UTC timestamp
before and after performing the FFT and averaging them. Each averaged
spectrum then gets time tagged with the mean UTC timestamp
(i.e. 0.5*(tstart+tend)), as well as the integration length
(tend-tstart). This way, if data is lost, only a single spectrum is
affected, yet the mean time stamp still represents the time of that
averaged spectrum, while the integration length shows you that data
may have been lost.

For SatNOGS I would propose the same; for each spectrum in the
waterfall the UTC timestamp is stored, preferrably as an array in the
HDF5 file. These can be offsets with respect to some start time.

[21:37:38] There will be some kind of averaging
[21:37:55] surligas suggests peak hold I think

Currently the gr-satnogs scripts use peak hold, which does not do any
averaging. For STRF I do average, which reduces the noise and works
better for weaker, but consistent signals. I’d have to run tests how
well averaging would work for packet bursts.

Not discussed at the meeting are the requirements for the time and frequency resolution. For STRF I use 1 second averaged, with 50Hz frequency resolution on UHF and 10Hz on VHF. This yields about 20 to 30 m/s velocity resolution, which, by trial and error, seems to work well for identifying Doppler curves with TLEs.
SatNOGS uses 0.1 second time resolution, and typically 1024 channels over 48000Hz bandwidth, i.e. ~47Hz channels, irrespective of frequency.

These would be constraints for TLE determination, but are there other constraints on the required time and frequency resolution?