Matt noticed that DAN (in contrast to old-style nulling) requires handling both the large "carrier" current through the bolometer and the small-scale "signal" fluctuations in the same feedback path. Unfortunately, the existing DAN build introduces significant digitization noise. Here, we propose an update to DAN which tweaks/improves/expands various parts of the DfMUX/DAN project in order to solve the issue of digitization.
Proposed rework
Fig. July16.1: DAN signal path, 3 Aug 2010 plan.
This differs from the previous DAN build in the following ways:
DAN feedback: CIC2 -> CIC1
The additional bandwidth reduces the effective digitization noise.
The upgrade is planned for both the regular DfMUX build as well as the DAN build. This may allow an upgrade from 68 to 128 channels.
Bit widths, use 24 bits of the CIC1 output, then keep 24 bits throughout
Streamer -> 32 bits
Updated Mar 2011 to reflect the comprehensive firmware update:
DMFDs now use "real" mixers and DDSes.
The build uses fixed I/Q mixers throughout, instead of non-complex mixers that can be arbitrarily paired.
Bit requirement of the streamer
The current DAN strategy requires streaming the some measure of the full current through the bolometer. That means the MSB-to-LSB ratio should be greater than the ratio of the total current through the bolometer to the minimal current that leads to acceptable digitization noise.
%BEGINLATEX%
\begin{equation}
N_{bits} = \mathrm{log}_2 \frac{V_{MSB}}{V_{LSB}} = \mathrm{log}_2 \frac{3 \mu \mathrm{A}}{1 \mathrm{pA} / \sqrt{\mathrm{Hz}} \cdot \sqrt{90 \mathrm{Hz}}} = 18.2
\end{equation}
%ENDLATEX%
At least some padding is required at the most significant side (e.g. a sign bit). Having a few extra bits at the least significant side reduces digitization noise. This suggests a ~24 bit streamer would be ideal for DAN. This solves the equivalent problem for DAF. Since the CPUs tend to use either 16 bit or 32 bit widths, using 32 bits seems to make more sense than using 24 bits.
-- TijmenDeHaan - 03 Aug 2010
svg 
