Wednesday, August 5, 2009

Updating the User Interface

Have you ever had trouble updating a chart when using a slider to control the axis?

I have tried using event cases that run on:
  • value change - updates but in a clunky manner
  • mouse up - you don't always mouse up over the slide after dragging it
  • drag end - does not update on the fly, so there is no feedback
The solution I have started using requires an event driven producer consumer. It was suggested to me by one of the LabVIEW architects at my company (CPE Systems)

The trick here is to enqueue the update case only if it is not already in the queue. If the case already exists in the queue nothing is added to the queue. When the consumer handles the case it takes the latest value from the slide itself. Providing smooth, live updates. This trick also works for other complicated user interface redraws.

Have you got any neat tricks you use to enhance the look or feel of your software?

Friday, July 24, 2009

Understanding Synchronisation with NI hardware

Synchronisation is a term commonly used when dealing with hardware timing. It is used in many different contexts with many different meanings. A recent application our company (CPE Systems) developed for a client required synchronisation between devices to determine the relatively small propagation delay between a transmitted and received signal. Getting an acceptable level of synchronisation and meeting the other requirements of resolution, sampling rates and start delays proved more challenging than first anticipated.

Our client was interested in measuring the velocity of a soundwave based on its propagation delay. The velocity of the soundwave is calculated by measuring the phase difference between the transmitter and receiver. Phase is used instead of time because it can be extracted from low level signals when lots of noise is present. We know approximately the time taken for the transmitted signal to reach the receiver, then using the phase shift we can accurately calculate this time delay. To accurately measure the phase difference between the transmitter and receiver the devices must be synchronised so the phase difference measurement does not vary between iterations.


Figure 1 - System Diagram

The receiver connects to the PXI-5922 (Digitizer) and the transmitter connects to a PXI-5412 (Arbitrary Waveform Generator). Calculating the velocity is a simple process as we have a known distance between the transmitter and receiver, and we calculate the time it takes to get there. Some high end instrumentation was required to allow us to trial a range of sampling rates, bandwidth and resolution. The hardware was chosen to meet the mega sample generation and acquisition requirement and the high resolution requirement. The PXI platform was chosen because it allows for more advanced synchronisation options.

Figure 2 - PXI Hardware

In order to achieve the synchronisation required we attempted two methods:

  1. Sharing a reference clock and external trigger source
  2. NI-TCLK

Shared Reference Clock and Trigger Source

Each of the NI PXI cards have a voltage controlled crystal oscillator (VCXO) that is phase locked (rising edges occur on rising edges of the reference clock) to the PXI 10MHz reference clock. The external trigger is connected to both devices by the same length and type of wire, to ensure both instruments receive the trigger at exactly the same time. The PXI-5412 has a generation delay of 110ns + 43 sample clock periods when no filtering is enabled and the PXI-5922 digitizer starts acquiring when the function generator is ready, so we know how far around the sensor has rotated since the start trigger. At a common sample rate of 500 kHz, the start delay is 80-82 us.

Function Generator (Rate)

Digitizer (Rate)

Phase Delay

100 kHz

100 kHz

10 us

1 MHz

1 MHz

1 us

10 MHz

10MHz

0.1 us

Table 1 - Shared reference clock and trigger source phase delay results

Phase delays measured in Table 1 represent how far a sample can shift between multiple measurements. The results show that the sample (taken by the digitizer) can be out by as much as one sample clock period when compared with where the function generator sample occurred. The phase delay determines the accuracy the velocity is calculated with.

Tclk

NI Tclk aims to have devices respond to triggers on the same sample period and have the sample clocks closely aligned. This is achieved by introducing another signal-clock domain. Each device generates this trigger clock (Tclk). It is a lower frequency than the sample clocks and calculated based on the sample clocks of all devices. The master device receiving/generating the trigger sends the trigger to all devices including itself on a Tclk falling edge. The devices then respond to the start trigger on the next rising edge of Tclk, resulting in the trigger being synchronised to a Tclk pulse. The drawback of Tclk is the lower frequency of the signal and the instance that the trigger occurs will influence the start delay. At a common sample rate of 500 kHz the start delay varies between 500-1050 us. The delay is due to the slower Tclk frequency, aligning clock edges and triggering devices.

Function Generator (Rate)

Digitizer (Rate)

Phase Delay

100 kHz

100 kHz

27 ns

1 MHz

1 MHz

4.9 ns

Table 2 - Tclk phase delay

Phase delays measured in Table 2 show that when using Tclk the time variation between samples is greatly reduced.

The Solution

In order to reduce the phase delay to an acceptable level the methods have been implemented in the following ways:

  1. Pulse Mode (Shared Reference Clock – no Tclk): This method generates and acquires data at 10 MS/s producing a phase delay of 100 ns and a start delay of 4.41 us. Due to the high sample rates this mode can only be operated in short bursts or the waveform generator and digitizer will run out of on board memory. This method allows us to get an estimate of the delay expected when using the more accurate Tclk method.
  2. Continuous Mode (Tclk): This method uses Tclk and acquires and generates data at 500KS/s producing a phase delay of around 20 ns. The start delay is varied between 500-1050 us. The velocity calculated is the average velocity for a single generation acquisition run.

For more information about Tclk visit:

http://zone.ni.com/devzone/cda/tut/p/id/3675

For more information about sharing reference clocks and triggers and other synchronisation information visit:

http://zone.ni.com/devzone/cda/tut/p/id/3615

Tuesday, March 17, 2009

Comments wanted from Embedded Systems Engineers

I have recently been spending time thinking about how tough debugging can be some times, why this is so and what to do about it.
This resulted in a whitepaper "debugging embedded systems" (http://www.clarinox.com/index.php?id=59).
I am hoping to get some comments from the embedded systems community with permission to publish these on the link (http://www.clarinox.com/index.php?id=4).

So far I have had comments from US, UK and Europe and hope to add some interesting comments from the embedded systems community in Australia.

Tuesday, March 3, 2009

Upcoming NI Workshops in March

Below are some NI Hands-On Workshops coming up in March:

1) Graphically Programming FPGA’s for Advanced Industrial Measurements and Control – Hands-on Workshop. 11 March 2009 in Glen Waverly, VIC. As part of this, CPE Systems will be giving a short presentation on a cRIO application, using LabVIEW RT and FPGA.For full workshop details, visit: http://sine.ni.com/apps/utf8/nievn.ni?action=display_offerings_by_event&event_id=1227&country=AU&site=AU&l=US

2) Introduction to PC-based Measurements and Graphical Programming with LabVIEW - Hands-on Workshop. 13 March 2009 in North Ryde, VIC. As part of this, CPE Systems will be giving a short presentation on the Portable DAQ System (PDAS) in the morning, and Balaton Technologies will be doing a short presentation in the afternoon. For full workshop details, visit: http://sine.ni.com/apps/utf8/nievn.ni?action=display_offerings_by_event&event_id=1219&country=AU&site=AU&node=160480&l=US

Followers