atm digital receiver (echotek card)

sep,2005

Contents:
Intro:
History:
Linux config:
Ryan seals thesis (.pdf)
source locations:
Notes/bugs echotek online gui
all buffers get written to disc.

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

2600 samples, 520 usecs

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.

Plots showing the results of the test (.ps) (.pdf):

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.

Source locations (21jan13)

Source code for the software is located on the daeron computer:

svn repos:
/home/svn/radarSVN

svn list file:///home/svn/radarSVN/trunk
.files
INSTALL
bin/
build-dist
configure
icons/
lib/
radarTk/
src/
test/

working area
/usr/local/radarTk

cd /usr/local/radarTk
svn info
Path: .
URL: file:///home/svn/radarSVN/branches
Repository Root: file:///home/svn/radarSVN
Repository UUID: 7d53ecaf-a2f4-0310-94ec-ef7151cc01ef
Revision: 136
Node Kind: directory
Schedule: normal
Last Changed Author: rseal
Last Changed Rev: 136
Last Changed Date: 2006-12-20 17:41:53 -0400 (Wed, 20 Dec 2006)

Note: this was checked out of branches, not from the trunk.

runtime programs and their links:

radarConfig -> /usr/local/radarTk/bin/config
radarOscope -> /usr/local/radarTk/bin/oscope
radarRun -> /usr/local/radarTk/bin/run
radarToolKit -> /usr/local/radarTk/bin/toolKit
radarView -> /usr/local/radarTk/bin/dataView

class: WriteBuffer.. is the class that writes from the kernal buffs of echotec to the shared memory buffers
class: ReadBuffer.. reads from the shared memory, processes and writes out to disc.

class definitions: /usr/local/radarTk/radarTk

This had all the .h files.. which has most of the code.

program code:

radarTk/src/xx
to run program: radarTk/src/echoRun/src/

runForm.cpp -- code that looks reading the data and processing it.
look at runForm.h for variable defs. e:q
:Lq

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)

All buffers get written to disc instead of just clp buffers.

Occasionally the echotek code writes all buffers to disc rather than just the clp buffers.

The code to figure this is:

radarTk/clpDetect.h

class,struct: CodedLongPulse
function: codedLongPulse(sampreate,txsize,isActive=false)

isValid_ = txSize_ >= win3_ + winSize_

sampRate_ is 5
winSize_=20,win3_=880. this is twice the usecs for the windows.
for isValid to be true txSize >=(440+10 usecs ).
*2 since using sizes, and there are 2 samples i,q (i think
The +10 could be the 10usec turnon delay of tube.. but the echotek only gets the rf pulse, not the txIpp ???

Active( &active) {

if (isValid_) isActive_=isActive.

radarTk/write.h .. defines WriteBuffer().

if !clp->Active() then writeDAta_=true all the time..
A little earlier a function Mode(int txMode) {

txMode_=txMode
if (txMode_ != 0) clp_->Active(true).

so the code path is:

User calls runFormMain.cpp (in radarTk/src/echoRun/src)

creates runForm window
calls into window show

runForm.cpp

Eventually the user pushes the run button..
runForm::run() gets called

calls getBuffer
calls buffer.write-Write()

After initilizing, starts write.run thread to do the i/o

write.h RadarTk/radarTk/write.h

init of write calls clp_ CodedLongPulse(samplerate,txsize)

This 0's Active

somewhere the must call write.Mode(txMode).

My guess is that the codedLongPulse* is setting isValid =0 because of what it thinks the txWindow is.

<- page up
home_~phil