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:
The duration of the meeting will be kept as sort as possible.
Orga pad for the next meeting, 2018-11-06 18:00 UTC:
https://hackmd.io/svR43goXTlG8U28DXusKRA?both
The meeting will take place on the new developersā IRC and Matrix channel #satnogs-dev.
For those who are using matrix, follow this link to join https://riot.im/app/#/room/#satnogs-dev:matrix.org
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?
This weekās meeting (2019-02-28) is going to be skipped as @Acinonyx and I will be in another meeting.
As usual for dev issues and discussions you can always join us anytime, not only in the meeting, in #satnogs-dev channel in freenode or matrix.
Hi. Are the meetings still going?
Yes, they are! Feel free to join us.
Some details have changed though. The meeting is in the #satnogs-dev matrix channel every Thursday at 10:00 UTC.
Weekly satnogs-dev meeting moved to Thursday at 15:00 UTC.
Join here: #satnogs-dev:matrix.org
Note: Joining the #satnogs-dev matrix room via IRC is not possible at the moment as the official āMatrix <> Libera.chatā bridge was disabled.