PGA460-Q1: Burst pulses are out of sync on Broadcast command BC_P1BL

Hey Akshay, 

Are you using transformer-based or direct drive for the transducer excitation?  

And are you using the synchronous USART interface?  I'm not sure why your out of sync is happening but suspect it is related to the communication or commands.

The broadcast burst-and-listen command should work for you.   Please check out the PGA460 Array of Ultrasonic Transducers for Triangulation and Tracking ( https://www.ti.com/lit/an/slaa783/slaa783.pdf ) app report for a detailed explanation on synchronizing multiple PGA460 devices. You don't need to add the triangulation algorithm for your application, since you don't need position tracking.  Specifically see the 3.1 Transceiver and Receiver section, it details basically what you want, though you want the slight opposite (3x transmit and 1x receive, instead of the described 1x transmit and 2x receive). 

Check out this post which is similar to you, it discusses a multi-receiver setup - https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/895721/boostxl-pga460-using-two-pga460-evms-for-indoor-positioning-system

Maybe it would be an option to use all 3 devices as transmitters and receivers and then average or compare or sum the result?  

Regards,

Jacob

hi,

  we are using a transformer-based drive, Asynchronous UART, and broadcast burst-and-listen command.

  Our aim is to increase the burst power to get more range.

Hey Akshay,

For both modules to be synchronized, a bus communication interface is required. The PGA460’s USART or OWU interfaces enable a shared bus connection for up to eight PGA460 devices. 

So in your case I think you'll need to use USART Synchronous Mode.  See section 7.3.6.2.1.8 USART Synchronous Mode in the datasheet for details on it.  This should make them actually perform the bursts at the same time.  So I think your algorithm for the transceiver solution should be as follows: 

1. Send broadcast threshold bulk write command (CMD25).
2. Send broadcast burst-and-listen command (CMD17/18).
3. Wait until the preset record length time expires.
4. Send an ultrasonic measurement result command (CMD5(?)) to read back the time-of-flight data from
   your 1 listening IC
   
   1. Alternately, listen on all the devices and average their results, or just take the max result, or add them together and do some signal processing on them.  

Best, 

Jacob

Hi Jacob,

               I tried with USART synchronous and followed your steps but still got the same result that is the burst pulses are out of sync.

We are developing a project to detect object using the transducer driver PGA460 and a 40KHz ultrasonic sensor. Our aim is to detect objects at a distance of upto 20m. The PGA460 + Sensor combination gives a maximum distance of about 10mts. This is mainly restricted by the received signal to noise ratio.

Given that the receiver’s sensitivity is fixed, one way to increase the received SNR is to increase the transmitted power. On a single PGA460 + Sensor combination, it is limited by the sensor performance ( 105db Spl at 30cm )

To overcome this, we plan to have 2 sensors transmitting at the same time ( to get 2x the Tx power ) , in phase. The distance between the sensors is a fraction of the wavelength. So for all practical purposes, the 2 sensors act as one with twice as much power output capability. Provided we can excite them at the same time. This is possible using the Broadcast command of the PGA460, sharing the USART interface. See diagram below 

Setup

Transformer based Sensor excitation

Transformer Model : WA8351-ALD ( 1 : 1 : 10 )

Sensor Model : CUSP-TR80-15-2500-TH

USART interface running at 115200Hz ( checked at 5MHz as well )

The flow used is as follows

1. Issue a Broadcast Burst and Listen command. Both the PGA460 will receive this command simultaneously as they share the USART interface

2. Monitor the SCLK of the USART and the DECPL pin ( or OUTA pin ) of the 2 PGA460

Given that the chosen Tx frequency is 40KHz ( 25us time period ), the uncertainty in the start of the Tx waveform should be max of +-2us to ensure maximum power delivery.

To study the jitter on the DECPL pin relative to the end of the command (last SCLK falling edge), we observed the DECPL signal on one PGA460 relative to its SCLK. Expectation is that the DECPL will have a steady delay relative to the command with low jitter (couple of ms is ok )

Unfortunately, we observe the uncertainty to be +-10us ( in the extreme, the waves are in opposite phase and can cancel each other ) . This we verified by observing the OUTA signals across PGA460 and also the rising edge DECPL pin ( easier as it is a digital signal ). The rising edge of the DECPL pin relative to the end of the Tx Burst command has a timing variation of +-10us with a delay of 110us. See diagrams below

Above Images are captured on scope, where purple is the clock (4th byte)from master controller and yellow is the rising edge of DECPL pin on pga460 . As we can see, the rising edge of the DECPL pin on the same PGA460 IC itself changes at each burst commands from master controller

A recorded video of this phenomenon is listed here

We also observed the OUTA signal across 2 PGA460 devices. These also show similar magnitude of jitter. Ideally both these should have come at the same time but there is a time lag ( quite significant as a fraction of its period ) between them. See below

Questions:-

1. Is the +-10us jitter expected ? If not, what can we do to reduce the same ?

2. Though not important in the final application, why is there a delay of 110us after the command.

Given the internal clock is 8MHz, any internal processing should have been fast .

Hello Akshay,

Thanks for all the info here and the video.

Let me first address your questions: 

1. Is the +-10us jitter expected ? If not, what can we do to reduce the same ?

• This was not validated during our validation process so it is hard to say if it is an expected amount of jitter, but my expectation is that you cannot do anything to improve this jitter. This would require both PGA460 systems to have shared internal clocks to ensure very little to no jitter between the output of each device. This is why the jitter isnt constant, I am sure at times you see device A leading and then at times device B.

2. Though not important in the final application, why is there a delay of 110us after the command.

• The reason the delay is as large as you see it is mainly due to the fact that there are various digital blocks that have to work hand in hand for this device to operate properly. So the digital logic inside the device has to ensure that all blocks are ready to not only emit the signal but that they are also ready for the ADC to sample, implement the gain and thresholding at proper times, applying all the digital processing required by the device. So there is a lot of behind the scenes work that imagine takes to load and sync for proper operation. It is also possible that the 8MHz clock is divided down internally so some items may not be running at 8MHz, I am not sure of this is the case but its definitely a possibility. Like you said though this might not matter at the end application level since you should be able to tune for this time.

Some comments on the +/-10us jitter, I understand that the signals themselves as they look in the scope look like they could be destructively interfering with each other hence why you would want them to match with each other as much as possible. But my argument would be that physically the transducer is altering how these signals are interpreted since it is a mechanical relationship between the electrical signal provided to the transducer and the sound that is created by the transducer itself. Meaning that the set of waves your transducer creates could be very different from the ones you see on the scope here. I think it may be worthwhile to try and quantify if a 10us jitter makes much of a difference compared to a 1us jitter to the perceived SPL at a device input. I think running this level of analysis will tell you if the jitter will be a problem and if needs to be addressed. If the return looks about the same at 10us vs 1us then I think it is safe to assume that this does not have the impact we expected.

Best,

Isaac