Student myDAQ - audio radar - sync transmit and receive

[rmp]

Hi folks,

I purchased the Student Labview 2016 with the myDAQ device. I want to create an audio imaging radar to teach high school (maybe gifted) kids signal processing, simple Labview programming and some physics. I'm really struggling with the myDAQ device. I'm hoping you can help narrow in on an approach.

As intro, I'll say that I've been programming in Labview for more than 10 years, and am an electrical engineer so I'm well versed in the basics for this task. Most of my Labview programming has been data processing but I have done some data collection with serial devices (compasses, IMUs, rotators).

For this radar to work I need to:

 - transmit a 10-20 ms pulse (linear frequency ramp... 100 - 5000Hz)

 - simultaneously (maybe within a micro-sec or so... haven't done the math yet) receive the echos for about 30-40 ms (about 20 ft range at speed of sound)

 - I'd like to repeat the xmit/rcv paired process ("sweeps") about 10-20 times/sec (50-100 ms period)

So far with the myDAQ I've been able to generate tones and linear ramps, and I can receive signals. I understand setting the sample rates. And, I purchased a cheap function generator to provide an external trigger for the sweeps.... although I'd rather not use this if I don't have to.

But, everytime I go down a path of trying to mix the xmit and rcv in some synchronized form I get errors (start.retrigger, start.digital edge). Here's what I'd like to find out:

 - when I "filter" "DAQ MX Trigger" property for my device, it says that start.retrigger is allowable. Is that a lie (I'm seeing other discussions saying it's not available)?

 - how about start.digitalEdge... is it allowable for my device?

 - how do I find out what features/properties are actually allowable with my device. The manual is of little help for this level of detail, and so far my fingers are raw from Googling/ni info, but I can't tell if it applies to my device... what is the model# of my Student myDAQ device?

 - I also see reference to "internal output signals" so that I could generate a clock and just use that output signal as a trigger without actually wiring two pins together (although it wouldn't kill me to wire two pins together)... is that allowable with my Student myDAQ?

 - do you think I have enough capability in my student MyDAQ to:

       - synchronize a xmit and rcv pulse within a micro-second

       - generate 10 - 20 20-40ms sweeps/sec

       - control the period between sweeps to within a micro-second

       (note: I could postpone all data processing until a full ensemble of 64-128 sweeps were collected; so I'd only be doing data collection during xmit/rcv) 

Thanks in advance for any help, advice, or thoughts...

[Bob_Schor]

The myDAQ has significant I/O capabilities, with Analog (or 2-channel Audio) In up to 400KHz and Analog (or 2-channel Audio) Out up to 200KHz.  I've done a fair amount of Analog Input, but not as much AO, and specifically haven't put a myDAQ through its paces, but if you use DAQmx functions and build AI and AO Tasks (either in MAX or in LabVIEW Project), I'm pretty sure you should be able to accomplish this fairly easily.

Bob Schor

[rmp]

Thanks for the encouragement Bob,

I shared your optimism when I researched options for this project. I only need about 5 kHz of bandwidth so the AO and AI speeds were more than adequate. And, with digital I/O I figured I had the options to trigger externally if I needed to.

I've been experimenting with the DAQmx functions in Labview. From the examples, user manuals, Elvis apps, ni support docs I've been able to program tone out (single tone and linear ramp) and analog input with varying rates and number of samples. No problem. More than adequate speed.

But, I have not been able to synchronize analog out with analog in. Have you tried:

 - trigger start of analog out (or analog in) from a digital input?

 - start analog out and analog in, simultaneously (within 1 micro-second)?

 - repeat a burst of analog in, on a fixed time period (20 bursts/sec, with less than 1 micro-second variation in burst-to-burst period)?

I can't rely on a non-deterministic operating system (Windows 10) running on a cheap HP laptop to synchronize analog out and analog in threads in Labview (when I do just a pure simulation in Labview I get several milli-seconds of variation when I just move the mouse).

[Bob_Schor]

Good questions.  I just plugged Analog Out into Analog In.  I'll try to generate a 500Hz sinusoid for a second using a 20KHz sampling clock and see what happens when I sample it (I'm particularly interested in the phase of the input signal, which should ideally be whatever phase I programmed into the output).  This should (Famous Last Words) be an easy test ...

Bob Schor

[rmp]

Oh, Bob, I applaud your ingenuity sir... such a simple, elegant test! That 500 Hz signal has a 2 ms period, so be careful to check for start_phase + n*2PI (I'm guessing you've already come up with an elegant solution to this also).

The more I think about my application, the more I think that there must be an easy answer. Surely folks that want to use this for circuit analysis would have the same issues, wouldn't they? You'd want to generate an impulse and look for the impulse response.

[Bob_Schor]

It is harder than I would have thought.  The myDAQ Analog I/O system appears to be non-triggerable, so getting them perfectly "in synch" seems, shall we say, "difficult".

I did try the following:

• Generate 1 second of a 30 Hz sinusoid of amplitude 1 using a 20KHz "sampling time" (i.e. generate 20000 points that show a sinusoid going up and down 30 times).
• Add amplitude 0.2 Gaussian White Noise (without some noise, spectra look really odd).
• Set up myDAQ Analog In and Analog Out on Audio L, ±2V (the max), 20K points at 20KHz.
• Write the Waveform to the Analog Out, set write mode to No Regeneration (do once).
• Start Write Task.
• Start Read Task.  Acquire 19000 points (to keep spectra "clean").
• Get Amplitude and Phase spectra of results.
• Plot Amplitude, Phase, Original Waveform, and Sampled Waveform.

When I do this, the Good News is that running this several times, the answers appear to be consistent (the phase doesn't change in an obvious fashion).  However, there is a definite phase lag between sending and receiving that I estimate as 600 samples = 600/20000 = 30 msec.  Putting the start of the Read Task "simultaneous" with the Write Task (the Error Line branches into both Start Task functions) cuts the delay about in half, but there seems to be a bit more "jitter" in the measured phase.  [I just did the second measurement as I was writing this -- the results were sufficiently surprising that I went back and repeated the first one, and indeed, the delay is longer and the phase is more consistent, i.e. less jitter].

Anyone else doing Waveform Analog Out on a myDAQ?  I should also try this on a myRIO, which is a tad newer and possibly more sophisticated (it at least has a RealTime OS).

Bob Schor

[rmp]

Thanks Bob,

Well, after many experiments, a few beers, banging head against wall a few times... I've done what most engineers do at this point... I've modified my application to work around the inadequacies of the hardware.

I wanted the AO to be synchronized with the AI so that I could accurately determine range to the reflection target. My work-around is:

• start the receive (AI) prior to the transmit (AO)
• increase the receive time period to accommodate my max desired range and the variability in the AO start time
• position my AI microphone close enough to the AO speaker to allow some leakage of the transmit pulse into the receiver.
• If I use the transmit leakage as time=0, then the target reflected signal is ALWAYS correctly delayed relative to time=0.

Since the transmit leakage should be the first signal received, I "should" be safe in assuming that the first signal is the leakage signal. Of course, differentiating this from near-range reflectors, or ambient noise, is going to be a bit of a challenge... the first compromise of robustness.

[rmp]

BTW, I think I have a mechanism to allow faster xmit/rcv cycles:

1) I started out with the following algorithm:

• configure AO to xmit one (finite) pulse of 1024 samples; configure AI to receive 6000 samples at the same rate as AO
• loop: start AI, wait a few millisecs, start AO; repeat loop

With this algorithm I could get about 10 loops/sec... not fast enough for my application

What seems to work better, but has its own technical issues is:

• configure AO to continuously xmit a pulse of 1024 samples + another 6000-1024 samples of 0 volts; configure AI to receive 1 second of data (in my case that's 200k samples)
• start that continuous pulse train going
• loop to repeatedly receive 1 sec of data (about 33 xmit pulses)

So, I've increased my AO/AI rate from 10 Hz to 30 Hz. The problem now is that I start the AI in some random time in the AO/AI sequence, so I don't know where the beginning of a xmit pulse is. I'm going to try electrically summing the AO into the AI so that I see the xmit pulses (hopefully distinct looking from the over-the-air signals).

I hope this makes sense...

[Bob_Schor]

Good luck!  It is always easier when the Hardware can handle some of the burdensome chores ...  

Bob Schor