Bypassing Doppler Correction to collect raw IQ from Soapy Source (Ubuntu)

SatNOGS Software
1

https://community.libre.space/t/generating-accurate-tle-for-rotator-pointing/12006?u=hubert-nuspace

image
image842×543 92.4 KB

hey all, I’ve tried to get this generic IQ sink to work, but it seems that whatever modification i make to the flowgraph isn’t being taken place. Our station is set up using the ubuntu installation process detailed here: Ubuntu - Client Installation - SatNOGS Wiki

For example: I wanted to see if i could get an IQ recording direct from the soapy source. I queued an observation up here SatNOGS Network - Observation 9895987

Steps i’ve done:

  1. Modified the satnogs_fsk.grc as well as the satnogs afsk1200 ax.25 flowgraph in satnogs-flowgraph/generic. set new IQ sink file path to a desktop folder.
  2. Disable the old IQ sink block post dopplercorrection.
  3. Rebuilt the satnogs-flowgraph using cmake, make and sudo make install.
  4. Confirmed that the python file installed to /usr/local/bin by sudo make install has the file path we set above.
  5. Restart satnogs-client.service and confirm reboot.

Instead, the iq dump is still happening after the doppler correction ( i see it in /tmp/.satnogs/ instead of the file path i’ve defined), showing that the file the satnogs-client is using isn’t the one i’ve modified. How do i tell which flowgraph is being used? I’m going off the transmitter modes but I cant see any debug messages in the log that tells me which python file is being ran. The metadata doesn’t show me which python file is being ran as well.

I need the IQ file because I would like to perform RFFFT and RFPLOT on it subsequently to improve our TLE creation method as linked at the very top.

2

If you need this for STRF then I suggest to stream the raw data over a UDP port and use pre-obs scripts with netcat to feed it into rffft. That’s really the only way to get the timestamping accurate, as the timestamp of a recorded IQ file may differ by seconds compared to the scheduled start time.

I’ve been doing this for a few years, see this (brief) description: Observation 1037954: Raw data Needed - #12 by cgbsat

This doesn’t help you solve your problem, and I’m not sure why the reinstall wouldn’t work. In the end, you can have a look at the difference in the python files that gnuradio-companion produced. For my python files, the changes are that a blocks_udp_sink block is added, which is connected to the soapy_source, with lines like:

self.blocks_udp_sink_0_1 = blocks.udp_sink(gr.sizeof_gr_complex*1, udp_dump_host, (int(10 * rigctl_port)), 1472, True)
and
self.connect((self.soapy_source_0_0, 0), (self.blocks_udp_sink_0_1))

Note the int(10 * rigctl_port) definition for the UDP output stream.

1 Like