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-Q1: Problem with the data read from PGA460-Q1

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

We are currently developing a distance measuring system that uses ultrasonic sensors. For this purpose, we decided to use the PGA460-Q1 with the Transformer-Driven schematic, as described in its datasheet section 8.2 (Application and Implementation – Typical Applications).


Since we are going to use 10 ultrasonic transducers we inserted a multiplexer between the transformer circuit and the transducers in order to reduce the number of PGA's and transformers necessary. In this manner we could select to which transducer the PGA would send and receive signal from.


Done that, we first configured the PGA using the given example “Get-Distance”, as showed in the document “PGA460 Software Development Guide”. In our project, we use an ATmega2560 to communicate with the PGA-460. Using the Serial1 of the Atmega2560 we believe to be possible to use the libraries provided for the Energia in the “Tool & Software” section (www.ti.com/.../toolssoftware).


To test the system, we fixed an ultrasonic transducer in front of a wall, within a distance of around a meter and a half and we performed some measurements. In this first test, we weren`t using the multiplexer.
As results we, got a series of uncoherent measures, which sometimes were constant 7 meters, or sometimes 5,64 meters and other times they were apparently random.
We even tried to customize de “Get-Distance” example, so, using the multiplexer, we could get measurements for all the 10 ultrasonic sensors. Unfortunately, this method showed the same results as the previous test.


What can we do to correct our results?

  • Hello,

    Please share some more details on the results when no multiplexer is used. PGA460 is designed to be used this use case. What are the parameters for the burst, what data you get back from the UART and voltages on the OUTA and OUTB pin during burst. Can you confirm that that when you are not using the multiplexer, the MUX chip is actually removed the S+ pin is not connected to the MUX pin at all physically?

    For the multiplexing case I have the following observation:

    It seems like that your multiplexing the secondary side of the transformer so that you only need to mux one pin. However depending on VPWR voltage, transducer resistance, current limit setting and turn ratio on the transformer the S+ voltage can swing very high which can be outside the input range of the mux. The max swing that you can see at either OUTA or OUTB will be 2*VPWR. The mux might also be limiting the current that is needed to drive the transducer. You can measure the S+ voltage to see the swing when no multiplexer is installed not the board and S+ is connected to the transducer.

    Regards,

    Vaibhav
  • Hi Carlos,

    Our transducer multiplexing solution using the MUX36xxx at e2e.ti.com/.../603257 has only been tested with a half-bridge driver since transformer drivers require more power compatible switches (high current at the primary or high voltage at the secondary). You may need to considering using a discrete muxing solution for a transformer driver.

    Regarding your invalid results, have you optimized your driver, receiver, and threshold settings, or are you using the generic settings offered through the COM terminal prompt of the GetDistance Energia sketch? Can you export the user EEPROM space by using a bulk EEPROM read ocmmand (USART command 11) so we can see the values you are using? Typically the GUI is used to optimize these settings as demonstrated in PGA460-Q1 EVM GUI video training series: training.ti.com/ultrasonic-sensing-pga460-q1

    Considering you are getting repeat distance results and occasionally random results, I suspect your long range gain multiplier is too large and/or your time varying gain is ramping to a very high level causing the noise floor to rise and trigger the threshold comparator. If you do not have the PGA460-Q1 EVM hardware, you can still export the echo data dump from the Energia script, and import the echo data dump into the PGA460-Q1 EVM GUI's threshold page to visually configure the threshold times and levels.
    Alternatively, you can run the auto-threshold Energia script to programmatically wrap the threshold more effectively around a no-object echo data dump. The GetDistance sketch uses a fixed level threshold, which is not always optimal.