spectregrams/spectre

When users create a config and use it to record data, they are thereafter blocked from updating it. This is enforced by _caution_update, which calls _has_batches. The intention is to protect users: once a config has been used to record data, updating it would cause it to no longer meaningfully represent the data already recorded. However, the REST API exposes no queryable locked state, so a client can only discover that a config is locked by attempting to update it, at which point the server rejects with a generic internal server error: spectre create config -t cw -r signal_generator -m cosine_wave spectre update config -t cw -p time_range=0.5 spectre record signal -t cw -d 5 spectre update config -t cw -p time_range=1.0 # An internal server error has occured. Received the following error: # raise FileExistsError(error_message) # FileExistsError: Files exist under the tag 'cw'. ... This is unintuitive. Config resources should expose a locked boolean that reflects whether batch file

Description FITS files produced by IQStreamBatch.write_spectrogram are Single Image FITS (SIF): a primary header block followed by a single primary data array with no extensions. Recovering the time and frequency coordinate arrays requires reconstructing them from WCS keywords, adding some complexity for consumers of the files. The EXTEND keyword is hardcoded to False at _iq_stream.py#L291, with an inline TODO noting the intention to add an extension. FITS files produced by IQStreamBatch include a binary table extension, conforming to FITS Standard 3.0 Section 7, that carries the time and frequency arrays of the spectrogram as explicit columns. CallistoBatch.write_spectrogram already produces this structure, with TIME and FREQUENCY columns in a BinTableHDU, and serves as the reference implementation.

When running tests, a lot of deprecation warnings pop up from matplotlib. This can probably be addressed by bumping its version to the highest that is reasonable, then addressing any breaking changes from it. While preserving our own public CLI and REST APIs.

The public method which reads FITS files reconstructs the time and frequency world coordinates by materialising a NAXIS1xNAXIS2 array of pixel array indices in memory. This can be reduced, since it really only needs the indices at one fixed time and one fixed frequency. This will speed up plot creation time. At the same time, we can restrict the language from pixel_coordinates as written in the implementation to pixel_indices as per the FITS standard.

Currently, the shared Pydantic field output_type (see here) controls signal recording file formats. This name made sense during development, as it configures the sample types produced by each receiver in GNU Radio (e.g., here). However, from a user perspective, it's confusing. The "output type" of what? We'd like to rename this field to signal_format, which is more intuitive. A crude approach would simply change the name and update all references to it, but that would constitute a breaking change. Users may need to manually update their config or face errors. Instead, we want to maintain backwards-compatibility. Configs created before this change should continue to work exactly the same. Finding a solution to this special case will be valuable, as we're likely to bump into the same problem again in the future. One approach might make use of Pydantic aliases