PGA460: Direct Data Burst - Byte Count varies

Hi Mathias,

The maximum USART synchronous mode baud rate mentioned in the datasheet is 8 Mbsps, so I don't recommend running the SPI Master SCLK above this frequency.  

In regards to item 5, there is no plan to change the PGA460 specifically.  When you are referring to an external clock, are you referring to the clock that is used to generate the pulses to the transducer?  If so, the TUSS4470 and TUSS4440 devices have this capability.  With these devices, you can drive transducers at their desired center frequency by providing pulses at this frequency at the input of the IO2 pin of these devices. 

Items 1, 2, and 4 would require internal discussion. I will get back to you by Thursday on these other items.

Regards,

Mekre

Hi Mekre,

i am aware that 8Mbps is the required baud rate and i do operate the SPI master in my MCU with 8MHz SCLK. The fact is, that there are two independent clock sources (MCU and PGA460) that are never really exactly synchronous.  So they drift apart during spi transfer. In my case, the 8MHz SCLK provided by the MCU is slightly obove the clock seen at PGA460 test pin 8Mhz output. I think this is a common issue, because PGA460 core's clock source accuracy is about +/- 4%.

My question about external clock input for pga460 targets this communication problem. 

Regards,

Mathias

Matthias,

I still need a couple more days to try to simulate these conditions.  I should get back to you with the next update by Monday.

Regards,

Mekre

Hi Mekre,

in the meantime i did some further analysis on direct data burst response frames.

I can see, that the byte count varies from frame to frame. This includes the number of Null-Bytes at the beginning of the frame as well as the following number of data bytes. In all cases the Check-Byte matches, so i assume the frames are valid.

In the following example frame (12bit data, Burst and listen)  there are 118 Null-Bytes and a total frame size of 8406 Bytes.

This is much more i would expect. As mentioned before, rec_len=1, so i expect 2*4096 = 8192 Bytes.

I made an interesting observation by checking the sample counter padded to the 12bit sample data. Normally it incements by 2 from sample to sample, but occasionally it increments by 1. 

I assume that these readouts are caused by unmatching clock rates.

In this example frame there are 45 of these samples.

Now I tested other prototype boards with similar results. One board with a particular good clock matching showed sample counter increments from 1 to 3.

I compared three different boards, an found that this behaviour was dependent on the board. So each board showed a little different clock matching. One board showed about 45/46 increments by 1. Another board showed about  58/59 increments by 1, and one board with really good clock matching showed mostly no irregular increments.  But this board showed another effect, that i saw occasionally. There where quite long sequences of 1/3 increments.  Maybe the clocks where a little out of phase.

When I added up all increments of different frames I realized that there were really little difference   (max. 3) and this also across different boards. So I think it does not really matter that the samplecounter increments are varying.  Maybe if the readout is too slow, it is possible to loose samples, because there is no buffering.

Byte-Count Analysis
All test till now where made with rec_len = 1 (8192) and Burst-And-Listen response frames. 

To examine nominal byte counts of frames with rec_len=0 and rec_len=1 and different commands, Burst-Listen and Listen-Only, i took the board with really good clock matching and found following results:

Listen-Only response frames have expected data count, but Burst-Listen response frames have 24 more 12b data samples and thus has 48 bytes more than Listen-Only response frames.

The Null-Byte Sequence at the beginning of response frames showed no tendency and varies about 104 to 122 bytes.

One thing seams to be clear: The Null-Bytes come on top when calculating total frame size.

Nethertheless one will get differing byte count values if clock rates do not match.

eg. burst-listen, rec_len=1  frame size = Diag+Nullbytes+Data+chk = 1+120+4120*2+1 = 8362 bytes (nominal)

The frame at the beginning had 8406 Bytes. That is +0.5%  (clock mismatch)

Clock accuracy for PGA460 is specified with +/- 4%.

Regards
Mathias