DLITE/DL/IF2C/G(XN) Family: Configuration Options

Examples of configurations: Very low power, solar/battery, SD-card data storage UT NDT applications:

  1. Stand-alone cellular/satellite self-reporting station
  2. Synchronized sleeping mesh network node
  3. Embedded “pingable” Bluetooth or short-range RF
  4. LoRa node
Continue reading “DLITE/DL/IF2C/G(XN) Family: Configuration Options”

IF2C: Charging

Plug in a USB Mini B terminated charging cable to a standard USB port or equivalent 5VDC 500mA capacity AC-DC adapter.

The IF2C is populated to charge at a maximum current of 500mA from the 5VDC charging source. This can be changed.

Especially for Lithium chemistries is it safest and best practice to charge only at a maximum current corresponding to the battery’s capacity. The generally recommended range is 0.5C to 1C. Maybe something like 0.8C is typically recommended. Please see additional resources for recommendations including the battery manufacturer’s data. You may wish to change the charging current setting depending on the battery capacity you are using.

The charging cycle may last several hours to overnight, at the charging rate as shipped, depending on your battery capacity selected.

During charging, the RED charging LED should illuminate on the IF2C. And the host power should shut down. If you have an XBee radio socketed on the host, you’ll see the radio LEDs turn off.

When you unplug the charging cable, regardless of where the charging cycle is in its progress, the regular GREEN and BLUE LEDs on the IF2C will illuminate.

During charging, you may still see the VSYSIN LED (host board) and GREEN BOOST LED (IF2C) dimly lit in this revision.

IF2C: GXN-Hosted Power Consumption Data

Data here is important for understanding the impact of configuration and software on power consumption for any system.

With a stack of the HDL-0108-IF2C + DL0102GXN at this prototype revision, the near minimum power consumption is 11.2mA from a 4.1VDC source (aka charged SC-LiPoly).

That’s not small enough for real field battery-powered deployment. The main culprit is just the standby power for the solid state relays.

Good enough for an intermediate prototype that tests a bunch of other things. Future forward, next rev milestones defined.

Tested Power Consumption and Conditions

4.1VDC source via battery input to HDL-0108-IF2C

XBee device-controlled main-power disable, 2.4GHz DigiMesh PCB trace antenna radio in cyclic sleep (during sleep)11mA
XBee device-controlled main-power enable, same radio, awake86mA
USB-to-3.3VDC-TTL-Serial converter, using PC software APIfor main-power disable
11mA
USB-to-3.3VDC-TTL-Serial converter, GXN-host, main-power enable, sleep instruction during idle enabled, all host peripherals powered up165mA
XBee 2.4GHz DigiMesh PCB trace antenna radio, GXN-host, main-power enable, sleep instruction during idle enabled, all host peripherals powered up240mA
Upper envelope, all peripherals enabled, no sleep instruction on host, XBee 2.4GHz DigiMesh PCB trace antenna radio350mA

What contributes to the power consumption?

  • Is your communications module configured to control (turn off) host power when the system is not active? Even if just for a short bit? The power up time is short in terms of user perception.
  • What is the power requirement of your communications choice? Is it a higher power device?
  • How is your communications module configured when active? What is its transmit power?
  • Are the on-host peripherals (like power subsystems) being shutdown by the firmware when inactive?
  • System configuration: Is your system and use-case set up to include power management of the host board and subsystem, including any sleep modes for radio communications modules? Some of this can be automated in firmware, some requires supervisory software or system implementation management.

6 Components of Power Minimization

Viewed as interacting constraints:

  1. Hardware limitations – inherent design or component limitations
  2. Configuration – jumper/shunt positions, module such as comms module choice
  3. Settings – comms module implementations, what mode is it running in?
  4. Hardware build options
    1. DNPs
    2. Components values
  5. Software and firmware implementations
  6. Use-case strategies

Every aspect matters.

IF2C: Example Data Acquisition Sequence

For IF2C as of this writing (Feb 2019), demo of sending commands while you’re waiting for the UT software package to be updated, so you can play now.

Tools used here: DL0102GXN, IF2C, XBee DM 2.4GHz radio on the HOST (not sleeping for these tests), another of the same radio model in a USB dongle at the PC, CoolTerm and UT Software in some legacy version. This is on a Mac OS X. You could use a USB-Serial cable (3.3V TTL) to connect too of course.

Continue reading “IF2C: Example Data Acquisition Sequence”

IF2C: Quick Start

The IF2C and GXN board-pair package has shipped with updated firmware on the GXN to handle the command set on the IF2C. Your UT software would need to be updated to speak these extra commands. In the meantime, you can use a serial port program to send those few extra commands first (as needed) and then switch over to your UT software.

Materials (Get Stuff Ready)

  1. Battery: Single-cell Lithium-ion polymer with JST-PH connector: See this Digikey search.
    1. “Wait, I don’t like those JST-PHs…” sure, yep, you can populate the screw terminal block component with this TE 282834-2 Part or the general purpose 1×2 0.100″ male header or of course solder wires to your favorite in-line etc.
    2. Watch for the little “+”s on the PCB in silkscreen (do they really use silk anymore?). The polarity of the JST-PH should match generally prototyping style JST implementations of battery polarity.
  2. Jumper wire to bring +5VDC from the IF2C to the HOST. Perhaps included in your shipment. Perhaps you want to rework this and wire it to your liking.
  3. USB cable ending in a Mini-B for charging only (not data at this point).
  4. HOST board with comms module of choice, configured to your taste and needs.
  5. SMA-SMA cables, at least 2, short ones – these are just board-to-board jumpers. Shorter cable = less inductance etc.
  6. Transducers with SMA cable terminations, at least one.
  7. Maybe an SMA-MMCX cable so you can test the MMCX connector(s) on the IF2C.
  8. Maybe your favorite serial port terminal program (CoolTerm, HyperTerm, whatever it is) so you can issue commands directly, if the UT software has not yet been updated to handle the IF2C commands.

Steps to Assemble and Power Up

  1. Choose your HOST board (here, if referenced, the host is a DL0102GXN)
  2. Know what your HOST board configuration and firmware status is.
    1. See IF2C/Host comms options
    2. For example: are you using a socketed radio (XBee (TM?) style) that controls the HOST main power with a GPIO pin? Is the jumper set correctly?
    3. Are you using firmware that has been updated to work with the IF2C command set?
    4. Here, we assume you’re using the firmware that shipped on a demo GXN board that integrates the API for the IF2C. But that your UT software doesn’t yet supported the automated use of the same API.
  3. STACK! The IF2C can be stacked on top or underneath the HOST board. They both work. However, so far at the bench here, stacking with the IF2C on the bottom gives better noise performance when hosted by a DL0102G(XN) due to various switchers etc. on the HOST that create some (electro)magnetic storms under the IF2C.
    1. Use standoffs/spacers. The spacing is slightly greater with the HOST on top.
    2. The GPIO 2×12 header is what stacks. You’ll see the 3x screw mount holes line up too. One is Southwest (SW) and the other is Southeast (SE) and the 3rd is oddly placed in the Northish area under in the radio/multi-comms footprint.
    3. The flip side to the stacking order is that the GXN (R01 A1) as a HOST can only be programmed via its TAG-CONNECT interface when it is separate or stacked on the bottom. By design.
  4. Connect the IF2C power to the HOST:
    1. The +5VDC from the IF2C goes to the +VSYSIN terminal on the HOST. Ground is already connected at a single point via the GPIO stacking header.

Steps to Connect Signals and Transducers

  1. Connect the HOST channel for Tx to the XPULSE_IN connector which is on the NW corner of the board, a vertically-oriented surface mount SMA connector, left-most. If your host is the DL0102GXN, use Chan 1 as the Tx signal (this is your only option).
  2. Connect the HOST channel for Rx from the IF2C (Chan 2 on the GXN) to XRX_OUT_BUF (South-central) on the IF2C. You could alternately try connecting to the XFX_OUT (non-buffered output). These are the right-angle (R/A) through-hole (TH) SMAs on the board. Be careful not to zap components under the SMA barrel area.
  3. Connect your transducer(s) to whatever channel(s) you want to on the IF2C. Four channels, starting with Chan 1 at the top (North) centerish, are numbered in increasing channel number moving Westward. Chans 1 – 4 are the surface mount (SMD) SMA straight connectors. Chans 5-8 are numbered in increasing order going from North to South along the West edge of the board. These are the edge-launch SMAs.

Steps to Power Up and Talk to the Board(s)

  1. Power Up! Plug in the battery (to the board, not to an AC outlet or something like that). That just turned things on. Assuming the battery was reasonably charged.
  2. Have your USB-Mini-B cable handy for charging. Maybe plug that in. A standard USB port is fine. As shipped, the charge current is limited acceptably for use by a standard USB port.
  3. Use your UT software to check that you can talk to the HOST, and/or that your comms module is configured correctly, etc. Or use a serial terminal program (again, maybe CoolTerm? that’s what’s used here) to send some commands.
    1. WAIT! First command didn’t work? The default firmware that ships on the HOST GXN now contains a sleep command with a 1-minute timeout from active operation (comms) until sleep. So, just send the command twice. Your UT software probably needs to be updated to work with a sleeping HOST.
  4. With updated firmware, the HOST receives all commands and forwards IF2C commands as needed.

Example data acquisition sequence, step by step.

DL0102G vs DL0102GXN – Channel Isolation

The “GXN” is a DLITE-Family compatible 2-Channel R&D ultrasonic (UT) board with high channel-to-channel isolation. It is a mod for specific applications, and a prototype for future designs and revs.

This brief is about the channel-to-channel isolation on the GXN. A complete list of updated features will be available soon …

Compared with the “G”, the “GXN” provides a HUGE advantage in channel-to-channel isolation for applications using dual element transducers or channel-to-channel (“cross channel”) measurements where the receive (Rx) transducer is VERY close in space to the transmit (Tx) transducer – and thus the Rx waveform section of interest is close in time to the Tx waveform also. This is especially useful where high receive gains are needed.

See the waveforms below where transmit is on channel 1 and receive is on channel 2 which is unconnected.

Need more technical specs? Just get in touch.

DL0102″G” Tx-Chan:1 and Rx-Chan:2 with Tx@-200V RxGain@1 RxDelay@10 Unconnected Rx input

The point: the above image Y-axis maxes out to the +/-5VDC Rx range with a gain of only *1* while in the image below for the GXN, the Y-axis covers a comparatively very small range and the Rx gain is MUCH higher at *8* which is 21dB higher receive gain than the gain used above for the G variant test. All other settings and configurations are the same.

DL0102″GXN” Tx-Chan:1 and Rx-Chan:2 with Tx@-200V RxGain@8 RxDealy@10 Unconnected Rx input

So you can see how much more signal isolation there is in the GXN variant. To estimate a difference, there is around 20log(1V/0.1V) + 21dB = 41dB of difference (that is a lot) between the two variants. This matches the design total isolation of about 70dB for the GXN design variant, using the actual isolation from the source channel return voltages, which in the early DLITE family is at about 26dB.

Both boards and general design variants have appropriate applications and trade-offs for particular use cases.