Is it possible to schedule an observation without the doppler correction?


#1

Is it possible to schedule an observation to be made without the doppler correction being applied?

I’d like to be able to schedule an observation and get the UNcorrected-for-doppler audio because I would like to measure the actual doppler shift for purposes of orbit calculation, especially on recent launches when the existing TLEs might be less than perfect.

Can it be done, or would this be a feature request?

Regards,
Douglas


Implementing a scanning mode
#2

Hi @ka2upw – to the best of my knowledge, this isn’t something exposed in the GUI in network mode; I’m not sure about standalone mode. I’d definitely encourage you to submit a feature request in the satnogs-client repo.


#3

Hi @saintaardvark
Feature request submitted.
Douglas


#4

Have you looked at existing observations? Because I’m not sure that disabling Doppler shift will be enough to support what you are trying to do. For instance, I don’t think the audio passband for CW and PSK is wide enough to contain the signal; and for FSK you probably can’t use the audio method.


#5

@csete : The .ogg observations that I looked in at Audacity were recorded at 48000 samples per second, which should be fine for Doppler shifts at 145 MHz and 435 MHz (amateur radio bands for satellite downlinks at 2m and 70cm). Even if the downlink signal was outside the recording bandpass at the beginnings and endings of the recording, the rate of change at TCA (time of closest approach) is valuable information itself, and that should be at the middle of the recording in the middle of the spectrum at the nominal downlink frequency.

To elaborate on an earlier point, if there were three objects on a particular launch they would each get a NORAD ID and probably be named OBJECT A, OBJECT B, and OBJECT C. If we had a recording without Doppler correction, we can look at the recording and determine TCA from the uncorrected recording, then compare that to the predicted TCAs for each object.

We can also try to determine which NORAD ID corresponds to the observed downlink by applying the Doppler correction for OBJECT A to the original uncorrected recording, then applying the Doppler correction for OBJECT B to the original uncorrected recording, then applying the Doppler correction for OBJECT C to the original uncorrected recording. We can plot the spectrums for all three corrected recordings. We would expect one of them to plot as a straight line and two of them to plot as “S” curves. The straight line spectrum plot is the NORAD ID for our downlink.

But to do any of this, we need to start with an uncorrected-for-Doppler recording.

Have I made a mistake somewhere?


#6

@ka2upw

Thanks for the info.

Yes, that is correct. The sample rate is 48 kHz; however, the analog bandwidth is limited to 1 or 2 kHz in the case of CW and PSK. You can confirm that if you load the the OGG file into a tool like Audacity and look at the spectrum.

For the sake of experiment, one could introduce a RAW IQ mode, where raw IQ samples are stored at 48 kHz without further filtering.


#7

@ka2upw the TLE used for the specific observation is stored with the rest of the data.

This would allow a hack job way of backing out the applied doppler correction to get an estimate of the raw curve through using the waterfall image as opposed to the baseband .ogg file.

No idea if the resulting precision would be sufficient to re-estimate a new TLE. @cgbsat has more experience in that area and might have an opinion.


#8

@danwhite: Yes, we discussed exactly this a few days ago in IRC (@cgbsat, @DL4PD, @csete @ar3itrary). :smile:

Summary:
The current waterfall.dat files contain doppler-corrected data with delta-time from zero. In combination with the exact start time and the used TLE, it could certainly be used for doppler-measurements/orbit determination (according to @cgbsat).

Based on the discussion, possible implementation steps are:

  • Add the absolute start time to the waterfall.dat file (gr-satnogs)
  • Make sure that the delta-times in the waterfall.dat files are actual time deltas. If sample counts are used instead (see gr-satnogs/waterfall_sink_impl.cc#L254), make sure there are no overflows (gr-satnogs).
  • Update the parsers of the waterfall.dat file to be able to read the new format (gr-satnogs/gnuplot-script, satnogs-client/matplotlib-script)
  • Let the client upload the waterfall.dat file to the network, e.g. by changing the file extension (satnogs-client)
  • Provide the waterfall.dat file to download from network (satnogs-network)
  • Create a script to de-doppler the waterfall.dat file based on the exact TLE which was used for the doppler-correction provided by the network for each observation

In some of the repos there were already issues created to track this as recommended above (e.g. by @ka2upw):

  • Feature request satnogs-client#303: “Schedule an observation without Doppler correction”
  • Feature request satnogs-network#481: “advanced setting: disable doppler correction for an observation”

#9

The above method could probably be made to work, but going from the doppler corrected waterfall.dat (the image?) and then un-applying the doppler corrections sounds like it could introduce some unwanted problems in all of the data conversions. If I understand the data path correctly, it would be the raw samples that get FFTed and doppler corrected then converted to the waterfall, then converted back?

Would it not be easier to introduce a RAW IQ mode, where raw IQ samples are stored at 48 kHz without further filtering and just upload the recorded RAW IQ samples?

For the doppler TLE calculation method that I was proposing, the recording does not need to last for the entire satellite pass. It would only need to record “near” the time of closest approach (TCA), so the near-TCA recording would be much smaller than the complete pass. Of course, if size/space are not an issue, the RAW recording of the whole pass would be best. :slight_smile:

Douglas KA2UPW


#10

Hi all,

Sorry to drop by in the middle of the discussion
(which I missed the irc part).

Can you tell me if it would be sufficient to
disable Doppler correction in method WorkerFreq of
file worker.py based for example on an environment variable
(from settings.py).

What is the action of the WorkerFreq by the way:
is it telling doppler corrected frequency to rigctld which
in turn tells it to gr-satnogs script after, or is there
a direct link?

73,


#11

Hello everyone!

Congratulations for this amazing and great project!

I am a newbie here and I am very interested in the use of doppler info to improve TLEs. In fact I recently registered on satnogs just for that reason. I thing that combining doppler data from the same pass from multiple base station could be powerfull method to improve a orbit determination.

From my naive point of view could be enough just to record and report the doppler shift applied by gr-satnogs to each recording in a UTCtime-deltaHz table. Isn´t it?

Nacho