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: Wrong values read for the object detection on PGA460

Part Number: PGA460
Other Parts Discussed in Thread: , ENERGIA

Hi Everyone,

I am currently working on the PGA460. My application is an air range sensor. I use an Airmar ATK75 transducer (75kHz).

I experience some issues when I try to read the distance information. In fact, all the returned values (8 objects) never update and are not coherent with the analogic signal that I can see on the TEST pin of the PGA460. I already read the FAQ about this case and I changed the value of my threshold but without any success.

So I implemented the data dump mode in order to see more precisely what happen. In fact the initial burst peak is larger on the data dump than on the analog output. Plus the signal remains stuck at 0 after the initial burst (for a few milliseconds). Even if I raise the gain value at the maximum output stay stuck at 0. After that (at the end of the recording) I can see valid signal with a peak that corresponds to a real object.

I also notice another strange thing, when I change the threshold value the shape of the initial burst peak is modified on the data dump data.

If you have any clue for helping me to find a solution you will be welcome.

Thank you.

  • Hi Adrien,

    Thank you for your description, but I will need to see the following to help you troubleshoot this:
    1) Oscilloscope output of the AFE output at the TEST pin, and the corresponding echo data dump plot.
    3) Ten subsequent ultrasonic measurement result captures.
    4) Memory map register output file (.txt).

    Can you clarify the following:
    1) Are you using the PGA460-Q1 EVM and GUI to evaluate the Airmar ATK75 transducer, or are you using your own hardware and software?
    2) Are you using the digital gain multiplier?
    3) Are you using a transformer or direct-drive mode?
    4) Are you using either of the PGA460's decouple feature?

    Here are a few items to check:
    1) If the DATADUMP_EN bit in the EE_CNTRL register is set to '1', then only the echo data dump is updated, and the ultrasonic measurement results will not change. If DATADUMP_EN is set to '0', then only the ultrasonic measurement results are updated, and the echo data dump will not update.
    2) A change to the threshold levels should never change the peak amplitude, but a change to the threshold timing may impact the echo data dump output if the SR and LR digital gain multipliers are not the same (i.e. SR=x1, LR=x8).
  • Hi Akeem,

    Thank you for your answer.

    First here the answer to your question:

    1)      I am using the PGA460 eval kit but I use my own software

    2)      No I don’t use the digital gain multiplier

    3)      I am using the transformer mode

    4)      I am not using any of the decouple feature

    Concerning my problem, I made some progress on my side.

    Before every burst I update some of the PGA460’s registers (the gain profile, the threshold registers, and some others). I need to do this because I want to modify dynamically those parameters.

    I execute the command in this order: update the registers, read the data from the previous burst, trigger the burst. And I notice that the data that I believed were the initial burst were actually the data I have just send to the registers. That’s why the “initial burst” was changing when I change the threshold levels.

    Then I swap the reading of the previous burst data and the writing of the register. And now my data dump data are good. Do you have any explanation for this phenomenon?

    I have another question:

    -          For the threshold 1 to 8 the register is only 5 bits wide. But on the figure 8 of the datasheet, this point is symbolized between 0 and 255. How the conversion between 5 bits wide registers and 8 bits wide value is made?

    Thank you.

  • Adrien,

    Your new sequence is the recommended order:
    1) Write registers to dynamically update results
    2) Send burst+listen command
    3) Pull ultrasonic measurement results or echo data dump

    However, even in your old sequence, the echo data dump and ultrasonic measurement result data should not be overwritten by any register-reconfiguration commands. The issue may be related to the UART receive buffer not completely clearing between commands. In the PGA460 Energia demo code (www.ti.com/.../slac741 and www.ti.com/.../slaa730), I regularly execute a serial-flush command to prevent any residual data overlap or back-up between each command.
  • Hi Akeem,

    I follow your recommendation:

    1) Write registers to dynamically update results
    2) Send burst+listen command
    3) Pull ultrasonic measurement results or echo data dump

    I use my own software to run echo data dumps,however,I use echo data dump command,Pull echo dump data,Data read by debug remains unchanged,May I ask what caused my echo dump data read from the PGA 460 to remain the same.

     

     

  • Thank you for your answer.

    I need another advice.

    I have some issues with what I call multiple echoes. If I put a large target in front of my transducer, the ultrasonic wave is making multiple round trips, generating false echoes. In fact, it is not a huge problem because all I need to know is the location of the first target. But if the target is getting closer to the transducer, close enough to entering into the dead zone. Then the PGA460 is reading the false echo. What I would like to do is to freeze the measure value at the dead zone distance when my target is in it.

    Do you think that is possible? If it is do you have any advice for me?

    Thank you.

  • Hi user5127206,

    A few questions I have:

    • Does the echo data dump look like a proper echo data dump when plotted, or are the values random?
    • Have you checked to see if the transducer is actually burst by probing the transducer's positive terminal?
    • Do you write to threshold map before attempting to burst+listen?
    • Is the DATADUMP_EN bit always a value of '1'?

    Be sure you have:
    1) Written to any of the threshold registers at least once to clear the THR_CRC_ERR. If THR_CRC_ERR is a value of '1', then the driver stage will not execute a burst/excitation of the transducer.
    2) set the DATADUMP_EN the DATADUMP_EN bit in the EE_CNTRL register is set to '1'. This value defaults to a value of '0' at power-up. If DATADUMP_EN is set to '0', then only the ultrasonic measurement results are updated, and the echo data dump will not update.
  • Adrien,

    Section 5.2 of the PGA460 FAQ (www.ti.com/.../slaa733.pdf) discusses how to implement echo masking by saturating the threshold levels. If you'd like to ignore activity in the dead-zone, then I recommend that you initially saturate the threshold to prevent inaccurate measurements.

    5.2 How can I detect more than eight objects? Can I set the threshold to ignore ringing decay ripple or objects for a given time after bursting? How can the Threshold Offset be used?

    The threshold map can be set to ignore ultrasonic activity at any point of the record window, when the threshold level is set to a value of 255. The user may want to consider setting the threshold to a value of 255 during the initial burst and decay time. Even when the return data is saturated, such as during the burst window or strong return peaks, the threshold comparator will not trigger when the threshold is maximized. For threshold levels 1-8, the value of 255 can only be attained when the threshold level is maximized to a value of 248, and the threshold offset is set to a maximum positive value of +7. This offset applies to all 1- 8 levels. For levels 9-12, the offset does not apply, and these levels can be independently set to 255.

  •  Hi Akeem,

    (1)I have now solved the problem of constant echo data,The first 40 echo data is normal, but the subsequent data becomes a random value,May I ask the possible reasons for this problem?

    (2)The maximum value of the threshold registers for the first eight PGA460s is 248,pga460 in the implementation of a burst command will appear when the value of 255,this will cause the current value to exceed the threshold,this will lead to wrong judgment distance, if so, how to avoid it?

    (3)I am trying to execute a system diagnostic command after an outbreak. According to the description of the UART structure of the manual, the front is the diagnostic byte, followed by three data, plus a check bit, it should be five data, but I only received four bytes of data, which data lack?

  • user5127206,

    Responding to your questions:

    (1) Be sure you wait until the record length time expires. For instance, if you have set a preset record length of 12.288ms, you need to wait 12.288ms before attempting the read back the echo data dump values or ultrasonic measurement result values. If you read the values to early, then the echo data dump will not completely update, which is why you may be seeing random values towards the end.

    (2) Refer to Section 5.2 of the PGA460 FAQ (www.ti.com/.../slaa733.pdf) which discusses how to implement echo masking by saturating the threshold levels. You need to set the level of the first eight threshold points to 248, but also set the threshold offset to +7 to set the final value to 255. This will prevent any echo activity from triggering the threshold comparator.

    (3) Refer to Table 3 of the datasheet (www.ti.com/.../datasheet) for the correct S-to-M Data UART bytes for command 8 (system diagnostics command), which are only four return bytes total:
    • Byte0: Diagnostic filed
    • Byte1: Transducer frequency
    • Byte2: Decay period time
    • Byte3: Slave generated checksum
    Be sure you are using Rev-A of the datasheet. The initial release contained an extra third data byte (which you may be referring to), which is no longer true.
  •  Hi Akeem,

    1) I modified my software based on your suggestion,I started to try to test the distance, but now my software with or without obstacles, the data is 2.25 meters, may I ask the possible reasons? I set the threshold in accordance with my echo data, the recording time length of 8.192ms, the number of pulses 5!

    2) I am using a hardware transformer can only rise to 50 ± 2V, whether it will affect the above problems!

     

  • user5127206,

    Responding to your latest questions:

    1) Be sure you have set the DATADUMP_EN bit to '0' before sending a burst-and-listen command and reading the ultrasonic measurement results. If the DATADUMP_EN bit in the EE_CNTRL register is set to '1', then only the echo data dump is updated, and the ultrasonic measurement results will not change. If DATADUMP_EN is set to '0', then only the ultrasonic measurement results are updated, and the echo data dump will not update.

    2) If you have used the GUI to confirm that the threshold follows and wraps a no-object burst-and-listen profile as shown in #5.3 of the PGA460 FAQ (www.ti.com/.../slaa733.pdf) then your ultrasonic measurement result readout should always be 0xFFFF for no-object detected. The hardware will not impact the performance of the ultrasonic measurement result readout if the threshold was properly configured using the echo data dump output. Refer to the video PGA460 ultrasonic sensing: EVM GUI data monitor (training.ti.com/pga460-ultrasonic-sensing-evm-gui-data-monitor for an example of setting the threshold using the GUI.

  • Hi Akeem,

    1) I have now completed the PGA460 driver, the test distance is not much of a problem, but I need four PGA460 debug together, each PGA460 pulse interval how many times will not affect each other?

    2)In a single debugging process, we have burned two PGA460, we tested our hardware, no problem, then the burst interval is too short, resulting in PGA460 burn? Or other reasons?

     

  • user5127206,

    Responding to your latest questions:

    1) When using multiple PGA460 devices, it is important to wait until the record length expires between each burst+listen iteration. For instance, if PGA460(1) sends a burst+listen command with a record length of 12.288ms, you must wait at least 12.288ms before sending a burst+listen command to PGA460(2). Otherwise, the echo from PGA460(1) could interfere with the results of PGA460(2), or vice-versa.
    If all four PGA460 devices are using transducer with different frequencies (at least 8kHz of center-freq difference), then all transducers use the burst+listen command simultaneously (via broadcast command) without interfering with one-another since each frequency is out-of-band from the rest.

    2) I am not certain what you mean. Can you repeat your statement using the pseudo code process you have described? If you are using up to four PGA460 devices on the same USART or OWU bus, then each device must have a different UART_ADDR. Are you burning a different EEPROM address top each device? Refer to PGA460 FAQ #2.4, 4.4.11, and 5.5  for details pertaining to multi-address systems.