Lena/Sep 2016

September 2016

BACK/NEXT

<< BACK NEXT >>

09/01/2016

Moving modulation/demodulation into LUT

Started on addressing the problems in the LabVIEW VIs. The first problem are the overflows in modulation/demodulation paths. The problem is that two 16-bit words are multiplied and they result in a 32 bit word, which is then scaled to fit back into a 16-bit word, and the scaling is not done correctly. I updated the VI, but it wouldn't compile because the compiler ran out of DSP48 blocks. The solution was to replace the Numeric multiplication blocks with High-throughput multiplication blocks and set the implementation to Look-Up Table, as described in this link http://forums.ni.com/t5/LabVIEW/Large-FPGA-vi-compiled-in-LV-2009-but-not-2010/m-p/1678820#M597625

Lab meeting

• File:2016.09.01 Group Meeting.pdf
• Thad suggested that we should have a logarithmic amplifier (so the signal is large enough for the ADC), and a PID loop at sub-Hz frequency to get rid of the DC fields around the sensor array.

09/01/2016

Talked to Mike about the insufficient bit resolution problem. Mike says the correct averaging should give us effectively more bits http://www.analog.com/library/analogDialogue/archives/40-02/adc_noise.html This should work as long as we increase the number of bits after the averaging.

09/08/2016

Implementing Mike's suggestions in LabVIEW (because it's easier to change the code than the hardware). The code mostly works, but still needs some debugging to make it compatible with the heartbeat recording VI.

Changes made compared to the previous version:

1. Data is acquired at the maximum ADC rate of 500 ksps
2. Raw ADC data is scaled up to int32 from int16 and anti-aliased by a rational resampler. The output data rate is ~20 ksps (2011 ticks at 40 MHz instead of expected 2000 ticks).
3. Data is low-pass filtered at 250 Hz by a 6-pole Bessel filter.
4. Data is sent to the PC with 32 bit resolution

09/12/2016

The LabVIEW VI's turned out to be way harder to maintain than I anticipated. For this reason, I cleaned up the project by selecting only the files necessary for the fMCG magnetometer to run (reduced the folder size from 1 GB to about 50 MB) and initialized a GitHub repo in the project folder. The project is pushed to this private GitHub repo: https://github.com/lenazh/fMCG-LabView-VIs

09/16/2016

The 32-bit magnetometer LabVIEW VI finally is working. Took several measurements to compare the noise performance of the 16-bit and the 32-bit VIs. Also measured how magnetic is a thermoresistor used in a different experiment in Chamberlain.

Measurements

Day	Run	Noise	Comment
2016.09.16	25	00	Z mode, 16 bit, with RTD, magnetic noise
2016.09.16	25	01	Z mode, 16 bit, with RTD, technical noise
2016.09.16	26	00	Z mode, 16 bit, no RTD, magnetic noise
2016.09.16	26	01	Z mode, 16 bit, no RTD, technical noise
2016.09.16	28	00	Z mode, 32 bit, no RTD, magnetic noise
2016.09.16	28	01	Z mode, 32 bit, no RTD, technical noise
2016.09.16	32	00	Z mode, 32 bit, with RTD, magnetic noise
2016.09.16	32	01	Z mode, 32 bit, with RTD, technical noise
2016.09.16	32	02	Z mode, 32 bit, no RTD, electronic noise
2016.08.31	14	02	Z mode, Hardware demodulation (SR830)
2016.08.31	00	02	Z mode, 16 bit, no RTD, electronic noise

RTD

The RTD (model) doesn't seem to be magnetic.

Noise comparison

PSD

The 32-bit version performs as good as the hardware lock-in. For some reason, the hardware lock-in PSD noise increases for higher frequencies, and for the 32-bit FPGA lockin it doesn't. The 32-bit version has 50 times smaller noise level than the 16-bit version.

 NoiseCompare(day='2016.08.31', run='14', noise='02', bs=1, Chan=1, direc='Y', label='Elec, Hardware demod/filter', 
 ver='v16', fmax=200, radresp=0, calib=2e-06, Ipr=0.0001, psn=0);
 NoiseCompare(day='2016.08.31', run='00', noise='02', bs=1, Chan=1, direc='Y', label='Elec, LV demod/filter 16 bit', 
 ver='v16', fmax=200, radresp=0, calib=2e-06, Ipr=0.0001, psn=0);
 NoiseCompare(day='2016.09.16', run='32', noise='02', bs=1, Chan=1, direc='Y', label='Elec, LV demod/filter 32 bit', 
 ver='v16', fmax=200, radresp=0, calib=2e-06, Ipr=0.0001, psn=0);

The data is acquired at the sampling rate of 500 ksps, and then averaged to approximately 200 sps (final FPGA filter has fc=180 Hz). This should improve the bit resolution by a factor of Sqrt(500 ksps/200 sps) = Sqrt(2500) = 50 (6-7 bits).

The estimated gain was 25 μV/fT. The LSB voltage step is 300 μV, the effective LSB after averaging should be 300/50 = 6 μV = 0.25 fT.

Filtering/digitization

The digitization of the signal is not visible in the 32 bit version.

16 bit FPGA filtering

32 bit FPGA filtering

Issues with the 32-bit magnetometer

• [FIXED] 16-bit and 32-bit versions return substantially different (20-50%) magnetic field response to both Y and Z fields in Z-mode, although the sensor conditions are the same. 32-bit version reports increased gain for the Y signals, and decreased gain for the X signals
• The op-amp phase response rolls for 32-bit version for about 30 degrees in 0-200 Hz; the phase is flat in the 16-bit version. The phase behavior could be caused by a 0.5ms delay between the reference data and the input data.
• [FIXED] The op-amp response: phase at zero frequency is flipped by 180 degrees in 32 bit version
• [FIXED/not reproduced?] Calibration chirps are cropped too much in the beginning
• Sometimes the subsequent calibration chirps come out at different DC levels. The magnetometer output looks like there is a sudden field jump between the chirps. Sometimes the jumps are larger than the magnetometer range. The jumps seem to be bigger when the field is not completely zeroed. Both 16-bit and 32-bit versions do that.
• [FIXED] Calibration chirps go too far out in the frequency domain and reach 1kHz, the modulation frequency. This causes the X field to not be demodulated incorrectly. Both 16-bit and 32-bit versions do that.