atm digital receiver (echotek card)
sep,2005
Contents:
Intro:
History:
Linux config:
Ryan seals thesis (.pdf)
Notes/bugs echotek online gui
12nov09: sine wave to check freq, timing
30mar06:
echotek config error caused IQ imbalance.
sep05: glitches (out of order ipps) in the data.
sep05: baud transitions show power
overshoots
Intro: (top)
The echotek card is used to filter and sample the
aeronomy
signals. It plugs into the pci bus. The 30 MHz IF is sampled at
80
MHz and then reduced to 5 or 10 MHz bandwidth. The card returns 16 bit
complex samples. The card operation is:
The sampling is normally triggered by the transmitter rf pulse
(from the
sps).
BurstCount samples are acquired and shipped to the cpu.
This value
is user programmable. It needs to be a multiple of 4096 bytes.
A linux driver runs a dma chain that tells the echotek where to
put the
data. There are two buffers that the driver loads.
The data taking software grabs a completed buffer from the
kernel. It
selects
a portion of the input data and moves it to one of two output buffers.
A tx section, height section, and noise section are selected. This
selection
is needed so the i/o rate to disc is manageable. The number of output
buffers
is currently set at two (but it can be increased).
A separate thread takes the full output buffers and writes them
to disc.
The data files contain an ascii primary header followed by
a set
of records (or tables). Each record contains an ascii header followed
by
a number of ipps of data. This is typically 100 ipps. At 10 millisecs
per
ipp each record holds 1 second worth of data. Files are filled with an
integral number of records until the 2 Gb limit. New files are
created
automatically. Data should be continuous across files.
12nov09: sine wave checking freq/timing
A sine wave was injected into the echotek card to
check the freq and timing.
Setup:
- 80 MHz sampling clock
- 30 MHz + 16010Hz input signal
- 10 millisecond ipp
- transmitter window
- data window
- 600 usec gate delay
- 22000 data samples, 4400 usec
- noise window:
- 5000 usec delay
- 10 samples: 2 usecs
- took about 30 seconds of data.
The data is plotted in black, the red plot is a 16010 Hz
sinewave computed with the amplitude of the measure data and the phase
of the measured sinewave at the start of ipp0.
- Page 1: ipp 0
- top: start of tx window.
- the first 5.6 usecs have no data.
- middle: end of tx window, start of data window.
- the black horizontal line is where no data was taken.
- bottom: end of data window.
- Page 2: ipp 99
- top: start of tx window.
- middle: end of tx window, start of data window.
- bottom: end of data window.
Summary:
- The computed sine wave aligns with the measured data
- the echotek is downconverting and sampling correctly.
- The first 5.6 usecs of each ipp have incorrect data. Must be the
delays thru the digital filter.
Glitches (out of order ipps) in
the data. (top)
Out of order records (glitches) were found in
test data taken 11aug05. The glitches appeared to be aligned with the 1
second records.
see: 11aug05:
out of order records in the 11aug05 test data.
More test data was taken on 07sep05. This data did
not
show any of the jumps seen in the 11aug05 data.
see: 07sep05:
test data shows no out of order records.
The differences in the echotek card configuration for the two data sets
was:
- The burstCount. On 11aug05 it was 50176. On 07sep05 it was 46080.
- The card configuration for the bandwidth. On 11aug05 the card
provided
5 MHz of bandwidth. On 07sep05 it provided 7.5 MHz.
The IF configuration was also different on the two days. On 11aug05 the
sampled signal was centered at 434 MHz. On 07sep05 it was centered at
430
MHz. Since the transmitter samples were always at 430MHz,
the
11aug05 had the tx samples offset by 4MHz from DC. This made the
tx samples look different, but should not have had any affect on the
records
being out of order.
sep05: baud transitions
show power overshoots
The transmitter is phase
coded
with a barker and random shift register code (clp). On
07sep05
the atm digital receiver recorded power and coded long
pulse
ipps. The data was output as 10 MHz complex samples. The bandwidth was
7.5 MHz. The plots show the
transmitter response to these transitions (.ps) (.pdf)
:
- Fig 1: The transmitter samples for the power profile. It uses a 4
usecond
barker code. The data samples are every .1 useconds. The colors
are:
Red voltage I, green voltage Q, black scaled power.
- Top: 1 complete barker code. The dashed blue lines are blown up
in the
lower plot.
- Bottom: This is a blowup of the top figure. The transition
takes about
8 samples (.8 usecs). The power (black line) overshoots by about 50%,
goes
close to 0 (as the phase goes thru 0), and then stabilizes.
- Fig 2 top: The transmitter samples for an entire coded long pulse
tx
window.
This used a 1 usecond baud.
- top red: the I voltage sample
- 2nd green: the Q voltage sample. Most of the overshooting is
occurring
in this signal.
- 3rd black: The scaled power. The data between the dashed blue
lines are
blown up in the bottom plot.
- Bottom: This over plots the voltage and scaled power for 8.5
useconds.
The power is also overshooting by about 50% before doing the
transition.
It is taking about .6 useconds.
processing: x101/050907/txsamples_07sep05.pro
linux software config
05apr06:
logfile are not being written?,
ntpd not running system clock is 5 seconds fast.
/etc/cron.daily is running slocate every morning at 3:01.
History:
05apr06: ntpd has not been running. system clock is fast by
5 seconds.
05apr06: cron.daily has been running slocate at 3:01 every morning.
This
should probably be removed.
Notes/Bugs online software:
Notes:
- profilelength: number of samples needed to be taken by echotek
card in 1 ipp.
- It is ok to make the ipp in menu > actual ipp as long as:
- It is then your responsibility to check that the burst counter
does not go beyond the end of the ipp
- The buffer space in the echoTek card will be < than 1
second. If you have a 1ms ipp but put 2ms in the window then you will
only have .5 secs of buffer space.
Configure gui: ..src/echoConfig/src
- main_gui.cpp
- MaxSampleLength() -
computes maximum number of samples in ipp
- Bug ..rounds ipp to integer before computing this...
- ConfigMain:AlignBurstCounter
- inputs burstcount, delay count, computes totalcount
- checks to see if burstCount +delaycount >= maxSamplesIpp
(see bug above)
- itemp= (<uint>(burstCount/1024) + 1)*1024 +
delayCount
- --> if burstCount multiple of 1024, makes it 1024
bigger than needed.
- if (itemp >=maxSamplesIpp) while(burstCount%1024
!= 0) --burstCount
- else while(burstCount%1024 != 0) ++burstCount
- Errors:
- itemp can be bigger by 1024 from bug above
- modulo operator !=0 does not decrease value. if 1024 too
big it leaves it there..
- --> maxsamples in ipp has not been rounded to 1024 so
if < maxsmpipp, burst count could be made bigger than maxsamplesipp.
- These errors should show up in the
burstcount,totalcount,profilelength (== burstcount)
- CheckWindow()
- checks to see if window goes beyond samples in ipp.
- Uses profileLength as max samples available (that they have
asked for.
- If lastsample>=ippSampleLength
- decrease first sample till < ippSamplength
- decrease samplesize till last sample <
ippsampleLength
- this could give a samplesize=0 if firstample =
ippSamplength-1.
- Does not allow use of last sample of ipp.
RadarTk: class definitions: ../RadarTk/*.h
- dmaBuffer.h
- dmabuffer(sampleSize,ippSec,captureSizeUsec)
computes dma buffersize.
- sampleSize passed in is profile length. Ipp has been rounded
to millisecs before converted to secs
- capturesize=1000 usecs
- dataRate_=samplesSize_*busWidth/ipp_ .. io/rate out of
echotech assuming only samplesize(or profilelength) samples are output
by echotech each ipp.
- Using Ipp too large, dateRate is too low ...
- dataRate is bytes/sec.
- bufferSize_=dataRate*captureSize_ /1000.f (captureSize_
set to 1000. before entry..)
- bufferSize_ is one seconds worth of data
- align()... align to 4k buffer lengths of system
- float temp=bufferSize_*1.f/blockSize_ (blockSize_ =
4k bytes)
- bufferSize_=round(temp)*blockSize_;
- --> Bug. if
buffer size = 5.3 blocks then round make it 5 blocks..
- Probably no problem since this is for 1 seconds worth of
data and we never get this far behind.
- captureSize_=bufferSize_/dataRate_ * 1000. ... still about 1
sec worth of data (in millisecs)
<-
page
up
home_~phil