• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 616 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: Ultrasonic Measurement Results Return Previous Result Instead of Most Recent

Chris Fildes
Prodigy 20 points
Part Number: PGA460

I am in early development with a PGA460 interfacing with an MCU.  I have adapted the slac741h library to work with my MCU with minimal changes and am using the library similar to the example code.

The setup seems to be working, except that the ultrasonic measurement results that I am reading seem to indicate the previous result instead of the most recent.  This is evident when moving the distance from an object to the transducer while debugging.  After I move the object, the first result reflects the previous distance.  If I trigger another measurement, then it is correct.

I would typically assume I am doing something wrong, but I notice that when using the GUI and the BOOSTXL-PGA460, requesting a single ultrasonic measurement results triggers two sets of burst pulses, leading me to believe the GUI is possibly working around the same issue by simply performing the measurement twice.  Is there indeed an errata with the PGA460 that I am experiencing, or some common mistake that could have to do with pulling the result to quickly?

The commands I'm using for my measurement are ultrasonicCmd(), followed immediately by pullUltrasonicMeasResult() and printUltrasonicMeasResult().  I have inserted a delay of up to 1ms before calling pullUltrasonicMeasResult() with no change in behavior.


Any advice would be most helpful.  Thanks

BOOSTXL-PGA460

  • 0
    TI__Mastermind 27920 points
    Hi Chris,

    I suspect your MCU's USCI receive buffer is not clearing properly between bursts, or you are not waiting long enough to read the latest UMR results after bursting. You can confirm that the latest UMR results are sent by the PGA460 by using a logic analyzer.

    The sequence you have described is correct, but please confirm:
    1) Send burst/listen command [ultrasonicCmd]
    2) Wait for record time length to expire (4.096-65.536ms depending on preset configuration) [delay]
    3) Read ultrasonic measurement results from PGA460 [pullUltrasonicMeasResult]
    4) Call on specific UMR result (distance, width, or amplitude) [printUltrasonicMeasResult]

    Since you have adapted/ported the slac741h library, I cannot assume you maintained all of the delays. You'll notice at the end of the ultrasonicCmd function, I added a fixed delay (referring to step 2 above):
    delay(70); // maximum record length is 65ms - delay with margin
    Do you apply this present record-length dependent delay in your version? 1ms will not be sufficient.

    There is no error/errata for this process. The GUI runs burst/listen commands independently for the echo data dump (EDD) and ultrasonic measurement result (UMR) modes. When both Ultrasonic Echo Display Format check boxes are checked, the first burst/listen applies to the EDD to plot the 128byte equivalent on the chart, while the second burst/listen applies to the UMR to update the UMR table. The PGA460 cannot record both the echo data dump values and ultrasonic measurement results simultaneously (see EE_CNTRL register DATADUMP_EN bit). If you only check the List Measurement Results box, then the GUI will only execute one burst/listen command.
  • 0 in reply to Akeem Whitehead
    Prodigy 20 points
    Hi Akeem,

    Thanks for your fast response. Your answer very quickly made me realize my mistake - when I adapted the library, for some reason I incorrectly thought the delay() function was in microseconds. Now that I've changed it to milliseconds, it appears to have corrected the issue.

    Thanks,
    Chris