• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 1436 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PGA460: Measurement short distance

Ivan Sedenkov36
Prodigy 30 points
Part Number: PGA460

Is it possible to measure short distance (<10 cm) with PGA460?

  • 0
    TI__Mastermind 27940 points
    Hi Ivan,

    Yes, it is possible to detect less than 10cm using the PGA460.
    What is your required minimum and maximum range?

    The monostatic Murata MA58MF14-7N (twisted-wire transducer) on the EVM is only able to measure downwards of 10cm in mono-static mode, so this specific transducer configuration may not work for your application.

    The PGA460 can detect echoes as low as physically possible (not device limited, but transducer limited). If your range is <10cm, I recommend the following options:
    1) Mono-static high-freq transducer (180-480kHz) in transformer driver mode
    2) Mono-static high-frequency transducer in a bridge driver mode
    3) Bi-static low-frequency transducer (40-80kHZ) in any driver mode

    The benefit of high-freq transducers is that they are designed to be more effective at measuring in the very short range (sub-10cm). Depending on the specific type of object (size, shape, surface material), you may be able to use a high-freq transducer with a bridge driver for long-ranging as well to eliminate the cost and size of the transformer. Low-freq transducers will always offer superior long range performance. Note: high-frequency transducer also have very focused beam patterns / field-of-views (sub-20deg).

    I recommend that you look into the Massa 200639-501 (Model E-188/220) high freq transducer in either bridge or transformer mode. You can use the EVM's half-bridge driver for evaluation. Otherwise, you will need to order a high-freq transformer. High-freq transformer options include:
    1) TDK-EPCOS B78416A2386A003 transformer
    2) Wurth Electronics 750316928
    When contacting either of these companies, be sure to mention that you are developing an ultrasonic sensing solution using the TI PGA460 for samples.

    For a full-listing of high-frequency transducers and transformers, go to:
    e2e.ti.com/.../620399
  • 0 in reply to Akeem Whitehead
    Prodigy 30 points

    HI Akeem,

    Thanks for reply. I want to measure speed of sound at fixed distance (~5cm). Now i test with 40KHz direct drive transducer wich give very coarse resolution and false detection near zero distance.

    First and second targets are false:

    And i get trouble with echo dump. I only first few bytes of received echo data are valid.

    For example two echo dumps with preset1 and preset2:

    It's shown, what only first part different, and other data bytes like noise and same always, until restart PGA460.

  • 0 in reply to Ivan Sedenkov36
    TI__Mastermind 27940 points
    Hi Ivan,

    Can you send me your Bulk User EEPROM and Bulk Threshold values? Ideally, if you can use the PGA460 EVM GUI to save these values in the GUI's Memory Map formatted text file format, I can import your settings for a quick review.

    Based on your echo data dump output, I suspect you are not waiting long enough between the burst/listen command, and then performing a follow-up readout of the ultrasonic measurement results or echo data dump results.

    The speed of sound travels at approximately 343m/s in air (which is relatively slow compared to a micro controller) , so if you want a complete valid echo data dump readout at the PGA460's minimum record length setting of 4.096ms (~70cm), you need to add a delay of 4.096ms after sending the burst/listen command to ensure a complete set of echo data can be captured. The echo data dump registers are random at startup; this is why the echo data dump output appears to be mostly random when you read back the data before it has finalized its capture.

    The stability issue may be partially resolved by adding additional delay, but it would still help to see a valid echo data dump after you apply more delay. I suspect stability is more so impacted by your threshold settings, and the amount of threshold comparator deglitch (THR_CMP_DEG) you have applied. I recommend setting THR_CMP_DEG to a non-zero value (mid-code of 64us as a starting point) to ensure the device is able to reject random noise which may otherwise trigger the threshold comparator to log an object.
  • 0 in reply to Akeem Whitehead
    Prodigy 30 points

    Hi Akeem,

    Sorry, but i cant save data by GUI because i dont use velution board. I connect PGA460 direct to PC with usb<->com adapter and adopt Energy IDE code for Qt.

    I try delays more 1second when echo dumping, but no results

    Readout values (diagnostic and CRC bytes included):

    Threshold Bulk Read:

    0x40 0x88 0x88 0x88 0x88 0x88 0x88 0x84 0x21 0x08 0x42 0x10 0x80 0x80 0x80 0x80 0x00 0x88 0x88 0x88 0x88 0x88 0x88 0x84 0x21 0x08 0x42 0x10 0x80 0x80 0x80 0x80 0x00 0x55

    EEPROM Bulk Read:

    0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x88 0x88 0x88 0x41 0x04 0x10 0x40 0xc0 0x32 0xa4 0x04 0x08 0x40 0x40 0x19 0x33 0xee 0x7c 0x8f 0x00 0x00 0x09 0x09 0x13

    Echo data dump:

    0x41 0xa5 0xff 0xff 0xdb 0xa8 0x10 0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xaf 0xff 0xff 0x2d 0x68 0x36 0xfc 0xc0 0x32 0xa4 0x04 0x08 0x40 0x40 0x19 0x33 0xee 0x7c 0x4f 0x00 0x00 0x09 0x09 0x99 0x39 0x14 0x84 0x1b 0xd5 0xdc 0xa1 0x65 0xac 0xea 0xa2 0x0f 0xe0 0xc6 0x63 0x4e 0x65 0xe6 0x0a 0xcf 0xc7 0xfe 0x34 0x54 0x35 0x67 0x8c 0x9f 0x0a 0xee 0x4e 0x52 0x0d 0xbd 0x64 0xc7 0x56 0xc9 0x5a 0xa5 0x10 0xc6 0xa1 0x34 0xe4 0x8d 0x10 0x18 0xe0 0x97 0x10 0x07 0x59 0x5d 0xa7 0xce 0x56 0x62 0x25 0xdf 0xa0 0x7d 0x24 0xef 0x60 0xff 0x68 0x40 0x2c 0xb6 0x13 0x2c 0xe0 0xce 0xa9 0x35 0x77 0x9c 0x28 0xb3 0xb1 0xae 0xd1 0x7f 0x6d

  • 0 in reply to Ivan Sedenkov36
    TI__Mastermind 27940 points
    Hi Ivan,

    Based on your readout of the echo data dump, the first byte (diagnostic field) of 0x41 indicates that the device was still busy when you ran the echo data dump read command. When plotting the echo data dump, it does appear that the first eight bytes do follow the expected trend data dump trend, but then the subsequent string of zeros indicates there was a communication based disruptor while the echo data dump was trying to fill during the burst/listen command.

    The delay must be added between the burst/listen command (CMDs 0-3) and the transducer echo data dump (CMD 7) or ultrasonic measurement result (CMD 5). Sequence:
    1) Send burst/listen command
    2) Wait the equivalent of the preset record length (use 1s to check)
    3) Read back echo data dump
    4) Wait until all 128 bytes of EDD have been read (use 1s to check)