How do I properly handle DDC metadata and settings?

Question

Using REDHAWK Version 2.0.5,

Given a CHANNELIZER centered at 300MHz and a DDC attached to the CHANNELIZER centered at 301MHz. The DDC is set relative to the CHANNELIZER and in this case the DDC is centered at a 1MHz offset from the CHANNELIZER.

A) How should I present the DDC center frequency to a user in the frontend tuner status and allocation? For example, would they enter 1MHz or 301MHz to set the center frequency for the DDC? Currently I am using the latter version.

B) In version 2.1.0 of the REDHAWK manual in section F.5.2 it says the COL_RF SRI keyword is the center frequency of the collector and the CHAN_RF is the center frequency of the stream. In the above case, I set COL_RF to 300MHz and CHAN_RF to 301MHz but the REDHAWK IDE plots center at 300MHz for the DDC. Should the CHAN_RF be a relative value such as 1MHz? Currently, at 301MHz, the IDE plots appear to center at the COL_RF frequency of 300MHz.

C) When the CHANNELIZER center frequency changes, I only set the valid field in the allocation to false on attached DDCs. Is there any other special bookkeeping that needs to be done when this happens?

D) Should disabling or enabling the output from the CHANNELIZER also disable or enable the output for the attached DDCs?

E) Must deallocating the CHANNELIZER force all DDCs that are attached to deallocate?

Answer 1

A) All external interfaces (allocation, FrontendTuner ports, status properties, etc) assume RF values, not IF or offsets. Allocate or tune to 301MHz in order to center a DDC at 301MHz. The center_frequency field of the frontend_tuner_status property should be set to 301MHz for that DDC.

B) Your understanding of how to use COL_RF (300MHz) and CHAN_RF (301MHz) is correct. You may be able to work around this by reordering the SRI keywords to have CHAN_RF appear first, if necessary.

For (C) and (D), there are some design decisions that are left up to the developer since the implementation, as well as the hardware (if any), may impact those decisions. Here are some recommendations, though.

C) In general, if at any point the DDCs become invalid, they should be marked as such. It is possible to retune a CHANNELIZER by a small amount such that one or more DDCs still fall within the frequency range and remain valid, but that may also be hardware dependent. Additionally, it's recommended that DDCs only produce data when both enabled AND valid, so if marking invalid you may also want to stop producing data from the invalid DDCs.

D) CHANNELIZER and RX_DIGITIZER_CHANNELIZER tuners both have wideband input and narrowband DDC output. Some implementations of an RX_DIGITIZER_CHANNELIZER may have the ability to produce wideband digital output of the analog input (acting as an RX_DIGITIZER). In this scenario, the RX_DIGITIZER_CHANNELIZER output enable/disable controls the wideband output, while the DDCs output enable remain independently controlled. The behavior of a CHANNELIZER, which does not produce wideband output, is left as a design decision for the developer. For behavior consistent with RX_DIGITIZER_CHANNELIZER tuners, it's recommended that the DDCs remain independently controlled. Note that the enable for a tuner is specifically the output enable, and not an overall enable/disable of the tuner itself. For that reason, it's recommended that the enable for a CHANNELIZER not affect the data flow to the DDCs since that data flow is internal to the device. Again, this is all up to the developer and these are just recommendations since the spec leaves it open.

E) Yes, deallocating a CHANNELIZER should result in deallocation of all associated DDCs.