Analog To Digital Software

[Julian Gladyshev]

HiI've created a DDS using an digital, encounter based flow and brought it into virtuoso as a Verilog block. I'm simulating it with spectre-XPS and the output is 6 bits "output". In Viva, I use "create digital bus" to create a digital bus from the analog output signals and things look good. However, it would be easier for me to verify the functionality of the DDS by actually looking at the sinusoidal output. Essentially, my question is, is there a good way to look at the output as "output-code vs. time"? I've search and tried out all sorts of things but I can't seem to figure it out. I tried using dac_8bit_ideal from ahdlLib but it doesn't seem to work at all. I've tried a few things out in the calculator as well but to no avail.

You can do this easily in ViVA. If your bus bits were analog in the first place, you can then create a digital bus from this using Measurements->Analog to Digital. Then select that bus and convert it back to Analog using Measurements->Digital to Analog - making sure you pick the options to have Bus output as Voltage. For example, I created a bus, mybus, from the analog bits at the top, and then the signal at the bottom is that bus converted back to a voltage:

I've not used IC616 in detail for a while (since that's two major releases ago) and can't remember whether there was an issue. Is there a good reason why you have to use such an old release? I can only imagine that this was a bug that was fixed (I vaguely recall there being an issue with converting a waveform to digital and then back to analog again - it didn't keep the overall expression correctly).

I am programing a pulse sequence which contains some Digital pulses and analog voltages and during the pulse sequence I need to read an analog voltage. All these channels needs to be synchronized I am using Ni-DAQmx.

I know the patterns of the AO and DO in advance, I could definitely append them one after other for all the 10,000 patterns and run it with out loop. But in the future I might have to do something else between the patterns (unrelated to AO and DO) so I am putting it in the loop

I am attaching a sample pulse sequence here, in reality I will have few more channels and little more complicated pattern and I need to scan one of the parameter, for example the amplitude of the AO or the distance between the pulse in the DO, So I am putting it in the For loop.

One question. Is there a reason you left all four timers outside the For loop? I put them Inside the loop and it was still working fine, Because this way I can also change the sample size for each cycle of the for loop.

And the way the syncing works is, for every cycle in the loop, it waits to collect the errors from all the channels at the Start Task of the CO, before executes the tasks, is that it? If yes, this looks like the syncing is a by-product of collecting all the errors (which in itself is not that important). I would assume the syncing should get the preference.

If you might change the # of samples from iteration to iteration of the For loop, you are right to put the calls to DAQmx Timing *inside* the loop. It will be *ncessary* in that situation. I thought you were delivering the same pattern & # samples every iteration, making it safe (and slightly more efficient) to put them outside.

- merging errors before starting the counter uses LabVIEW's *dataflow* as the sequencing mechanism. It's usually considered more LabVIEW-like to rely on dataflow when feasible rather than resort to things like Sequence structures.

- in apps involving close sync of multiple tasks, an error in any one of those tasks is usually going to mean that the rest of the tasks won't be useful without the one that errored out. I often consolidate errors from multiple tasks for this additional reason.

One last tidbit: in most systems I've dealt with that sync'ed output and input, I configured the outputs to generate on the *leading* edge of the sample clock while the inputs capture on the *trailing* edge. This gives the system a little bit of time to respond to the new stimulus. You don't *have* to do this, but I've usually found it be preferable.

Sure. There's a presently-unwired 'active edge' input terminal available in your calls to DAQmx Timing. Because the CO pulse train you're using as a sample clock is specified to idle low, that means each pulse will produce a rising edge first and a falling edge second. So you can just specify 'Rising' for the AO task (and probably also the DO task) and 'Falling' for the AI task.

Absolutely. That's the beauty of using a counter pulse train that you control as the sample clock. You'd typically define a frequency and duty cycle, where the duty cycle ranges between 0 and 1 (but not exactly 0 or 1). A larger duty cycle means a larger pulse width and more delay from rising (AO) to falling (AI) edge. IIRC, you defined your pulse train in terms of high and low time so delay is defined simply by the high time, and it's a simple calc to choose a low time that gives you the right frequency.

With only a single AI channel, you can feel pretty free to use a duty cycle as large as 0.9 or more. If you had multiple AI channels in your task on a multiplexing device, you'd need to be more carefully about the AI multiplexing operations "spilling across" the next AO sample. The default behavior of the multiplexer is to spread the AI conversions widely across the entire sample period. You might find yourself needing to purposely speed that up by setting a higher rate for the "convert clock" that gets your AI sampling done before the next AO sample can exert its influence.

I want to acquire multiple analog and digital inputs. The analog input should run at a rate of 100 Hz and 10 samples be read, resulting in a loop duration of 100ms. Therefore I have timed the digital inputs at a rate of 10 Hz with the AI Sample Clock as a source and read only one sample to have the same loop duration.

Now when I use simulated channels it works perfectly fine, but when I use the real world device (the NI cDAQ-9178 with the modules NI 9205 for the analog voltage inputs, the 9203 for analog current inputs, the 9217 for RTD inputs and 9422 for digital inputs) it only displays the analog values, not the digital values.

I have an application which needs to acquire data from different devices, such as a normal cDAQ for the sensor inputs, a CAN device for a external cooling pump and from a TCP/IP protocol of a high voltage power supply unit.

What is the best practice for this problem, if I want to acquire the data all at the same time and then send it via a queue and notifier to parallel loops to display it and log it so that all data is synchronized?

Should I just put all the acquiring functions in one loop or is there a better way to do this?

What is the best practice for this problem, if I want to acquire the data all at the same time and then send it via a queue and notifier to parallel loops to display it and log it so that all data is synchronized?

For your coding in the first post, you should use an error cluster or stack sequence structure to ensure that the slave task starts before the master task. Otherwise, the sample clock from the master task might reach the slave device before it is ready. Besides, you cannot set a different sample rate when using sample clock synchronization. The digital slave task must also use 100 Hz of the sampling rate. You can average the data returned from DAQmx Read VI.

Unfortunately, TCP/IP is lacking hardware-timed sampling mechanism. It will always have a non-predictable latency. What are you trying to read using TCP/IP? Perhaps the third-party software or device can use sample clock and send data at precise intervals.

The lowest latency can be achieved by using the sample clock to time the timed loop that does the polling with EA-PSI. However, this requires DAQ Devices with Hardware-Timed Single Point Sampling Mode Support and cDAQ does not support this.

In your case, if your acquisition rate is low (below 1000 Hz), you can place all three into a single while loop and read ONE sample per iteration. This should give you minimal latency between the three devices, probably at around 100ms.

However, if you need a higher streaming rate for logging, the best you can do is to use three separate loops for DAQ, CAN and EA-PSI, then synchronize the DAQ and CAN. The latency and timing accuracy of EA-PSI would have to be sacrificed.

If CAN is not possible, you should use RS-232 or USB instead of TCP/IP. Ethernet has the worst latency performance. RS-232 has the lowest latency but it would require you to use the onboard RS-232 port. If you are using a USB-232 adapter, you should just use the USB to communicate with EA-PSI directly.

What I think might be the best plan is to come up with a single solution that allows taking digital, analog, and/or analyzer data, run some code with it, and produce digital, analog, and/or protocol data. Basically an extension that users could write that builds on what we can do now with protocol analyzers, which are essentially digital data to protocol data converters. This would just expand the input formats to support analog or other protocol analyzer outputs, and expand the output to support digital and analog data. The new python high-level analyzers and measurements are a step in this direction.

I still hope to find out how to use the oscilloscope properly. But in case the Saleae devices would support this out of the box, I would directly order one.

The specs are looking great: 25V input protection (for analog too?), 10V signal level for analog. And the fact it features analog inputs really made me hope it would be able to convert the analog to digital.

Now, the idea was to check if there is any failure in the data itself, while checking back to the waveform if it is signal related.

Since debugging the target machine is not possible right now, we are limited to check the data received, we are now working on a tool to check the data with the transmitted checksum.

Also, both, target and source, were used many times before without problems and even a source-simulator (a tool on PC using a RS422 dongle) is working without problems.

3a8082e126