Yesterday I updated satnogs-flowgraph to 2.4+4+ga91ba984-1 on Debian 12.13. Since then the IQ files (*.raw) are kept and not deleted. I noticed it when running out of space.
My quick and dirty fix was just removing them via post-script. Maybe someone has experienced the same behaviour? I have not checked the diff to my old version yet.
Have a nice sunday 
Regarding this, although IQ_DUMP_FILENAME="/tmp/.satnogs/iq.dat" is specified in the config file, the actual output is saved as like iq.dat_cs16_2026-04-24T12-07-46.raw. Since the original iq.dat is not being overwritten, these files are consuming all the disk space.
The temporary fix with pre- or post script could also help with this issue. I guess the real fix is very minor, but this workaround will help immediately.
or maybe cancel the update, backward to stable release
Thanks for reporting this, I suspect this behavior occurs when iq capturing is disabled right?
It looks like the iq publisher is being connected regardless of this parameter. I will open an issue on the repo and work on a fix. Until then you can roll back to the latest release
Thanks for sharing this, @Acinonyx or someone else of the dev team, can you confirm this change?
Jan | PE0SAT
For future bugs or ideas, what would be the best place to submit those things? Do you have a small reference for this? In case I just have a small patch for thins like this…
I would suggest, the gitlab issue’s page librespacefoundation / SatNOGS / satnogs-flowgraphs · GitLab.
Jan | PE0SAT
This happens when ENABLE_IQ_DUMP="true".
I dont have access to my station to verify this right now, can you please tell me if it happens when it is false?
If the question was addresses at me. I have relied on the default setting and have not specified IQ or RAW keeping it in the config. Until the update the files have been removed after the processing.
The same issue persists even when the setting is set to false. As a result, an IQ file with a timestamp was generated.
Thanks! I’ve opened an issue you can track the progress here
@uhf-ops you are always welcome to contribute if you are interested 
Yes there is a bug with the latest code (not the latest release) in the repository and the solution is worked on. You can see the progress on the issue here
the core is back
The timestamp is also a new feature we are implementing for easier management of multiple saved IQ files unrelated with the capturing of files without the user enabling the option.
The fix is pushed here. You can try it.
Thanks for interacting with this community post.
One thing I do find confusing.
ENABLE_IQ_DUMP, IQ_DUMP_FILENAME and ZMQ are two different variables are we discussing the same ?
At the same time, what is the expected new behavior, this to inform users that are now using scripts to handle IQ files.
Here a function that I use:
if [[ "${ENABLE_IQ_DUMP}" =~ (True|true|1) ]] && [ -f "${IQ_DUMP_FILENAME}" ]
then
mv "${IQ_DUMP_FILENAME}" "${DIR}"/iq_"${SPS}"_"${1}".raw
zip -j -m -T "${DIR}"/iq_"${SPS}"_"${1}".raw.zip \
"${DIR}"/iq_"${SPS}"_"${1}".raw
echo "${UNIXTS} ${1} ${6} ${SATNOGS_STATION_ID} ${SAT} ${NORAD} ${SPS}" >> \
"${DIR}"/observations.txt
fi
Jan | PE0SAT
The env variable ENABLE_IQ_DUMP, if set to True, enables the creation of IQ files in cs16 format as always.
The IQ_DUMP_FILENAME is still used but now used as a prefix for the created filename. The complete file name is of the form {IQ_DUMP_FILENAME}_cs16_YYYY-MM-DD-Thh-mm-ss.raw
e.g
ENABLE_IQ_DUMP=TrueIQ_DUMP_FILENAME=satnogs_iqgenerated filename: satnogs_iq_cs16_2026-04-28T17-30-05.raw
For your script for example you should add a wildcard after "${IQ_DUMP_FILENAME}" to correctly match the generated file. This is done so a user can save multiple iq files without interacting with the client on an observation basis. Also the format is added for more clarity, although that will be probably unneeded when proper sigmf files are gonna be created.
I didn’t not understand the part of the question about the ZMQ. What i can add on zmq is that yes with the latest changes the file is generated through a zmq subscriber and not from a GNURadio file_sink. This is done because the goal is to move all artifact handling outside the radio part of SatNOGS. The radio will be responsible to expose the data at various points of the flowgraph that anyone could attach to and do whatever processing seems fit.
There is also a milestone that tracks what needs to be moved that might give a better overview.
Can you please use the obs ID in the IQ file creation.
Regarding ZMQ:
When I follow the link that you shared Start zmq subscribers conditionally (#99) · Issues · librespacefoundation / SatNOGS / satnogs-flowgraphs · GitLab
" Start zmq subscribers conditionally"
Jan | PE0SAT