PGA460-Q1: PGA460-Q1

peter mccormick

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

We have the PGA460-Q1 Eval module and everything works perfectly for our application. We are trying to watch the RX and TX serial data that the PC sends and receives to the Eval board. We can clearly see the 55 and all RX and TX waveforms on the scope. We use a simple 3.3V to RS-232 converter to watch the hex data on a serial monitors. The data is random 00 FF 0C.... but we cannot determine the baud rate that the EVM is using.

I know that it autobauds on the 55 but our serial monitor cannot auto baud.

What is the Baud rate when the EVM does all of the register transfers and Commands? 115k, 9.6K... do not seem to work.

Thanks, Peter

over 6 years ago

0 Akeem Whitehead over 6 years ago

TI__Mastermind 27780 points

Hi Peter,

By default, the EVM baud rate is set to 115.2kBaud, but can be set to a lower value (down to 9.6kBaud).

Can you provide an example UART string transmitted from you PC to the PGA460? Be sure that you are using two end/stop bits, no parity, and no flow control.

Also, the PGA460 Software Development Guide [PGA460 Software Development Guide ] and PGA460 Energia Library and Code Example (Version 1.0.0) [http://www.ti.com/lit/zip/slac741] may be useful for you code development and debug.

0 peter mccormick over 6 years ago in reply to Akeem Whitehead

Expert 1080 points

The PGA460 is working perfectly and the Eval software is excellent. We can send and receive data directly to the PGA460 over Rx Tx from our product which is also MSP430 based. Howevre, we want to occasionally use the eval software.

The PGA460 Eval uses the piggyback TI MSP 430 Launchpad development board. If we connect an RS-232 PC to 3.3V 115Kbaud adapter to the Tx and Rx pins on the PGA460 eval board (and bypass the TI Launchpad board), will the Eval software still work? I assume that the TI Launchpad does no more than pass USB data directly the Tx Rx on the PGA460 so the eval software on the PC will still work if we connect the PC Com port directly up to the Tx Rx ??

Thanks, Peter

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

peter,

I'm glad to hear your RS-232 PC to serial adapter is working with the PGA460. There shouldn't be any issue in using your own PC-to-Serial adapter in conjunction with the TI LaunchPad, as long as your adapter's serial pins do not load the Tx/Rx pins of the LaunchPad.

The MSP430F5529 has an integrated USB PHY, so all the GUI PC-to-LaunchPad communication is independent from the PGA460 UART pins.

Let me know if this works out for you! Worst case: you'll have to physically connect/disconnect the LaunchPad as needed.

0 peter mccormick over 6 years ago

Expert 1080 points

One more question:

The PGA460 is excellent, however, can it also do the following?:

1) Can the PGA evaluation software store the setup values for a particular piezo sensor so that we don't need to manually set the frequency, gains, thresholds every time we launch the software? Something like a SAVE PGA .cfg file

2) Can the user EEPROM be made to store All of the thresholds, gains, frequency and default power up values so that these don't need to be sent by the master computer every time it powers up? It seems odd that many of the values are stored in EEPROM but not all of them so that the external computer still must load the values. If yes, can this be done using the eval software?

Thanks, Peter

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

Peter,

The PGA460 itself can save the setup value in its EEPROM space. For instance, if you optimize the frequency, pulse count, drive current, gains, etc., you can burn/program the device's EEPROM to save these values. If you do not wish to burn the values onto the EEPROM, then the GUI can save all register values (including volatile memory, which includes the thresholds) to a .TXT file. This .TXT file can then be loaded any time or to a different device. This is demonstrated in the the last video of the six part training series at: training.ti.com/ultrasonic-sensing-pga460-q1

Whenever you are modifying the user registers values using the GUI, you are actually reading and writing from shadow registers, which are initially loaded with the values from EEPROM when the device is first powered. The only values that the user MUST write to upon every device power-/start-up or reset are the volatile threshold values. The other values you've mentioned should be burned to EEPROM, such that they default to the values required by the particular transducer and driver combination you are using.

If you have not seen the mini video training series (collectively, less than an hour long), I recommend you view them for an overview of the EVM+GUI. Let me know if you have any additional questions afterwards.

0 peter mccormick over 6 years ago

Expert 1080 points

We used the Eval system and monitor the serial traffic. Some of the responses do not make sense.
Please clarify the ?? below. Thanks, Peter

55 c9 1c 1a    ask for frequency 1c=address
40 32 8d 00     response from eval system
40 ?? is this the address from the PGA with an address of 6?
32=40khz frequency
8d ?? what is the 8d in response
00 ??
-------------------
WE SEND THIS COMMAND 5   I understand the other requests and setup commands
55 ca 40 80 74    echo and retrieve 2 results
55 c0 02 3d
55 ca 40 00 f4
55 c0 02 3d
55 c5 3a
55 ca 40 00 f4
55 c9 4c e9
55 c9 4d e8
55 c9 1f 17

IT RESPONDS WITH THIS
40 00 c0 ff ff 29 5c ff ff 79 00 //response 295f uS=1.828m which is correct !
40 ?? what is this ??
00 ??
c0 ??
ff ??
ff ??
29 5c is 0295C hex is 1.828m ping which is correct
ff is width ?
ff is amplitude? why is it so high?
79 ??
00 ??

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

Hi Peter,
I am in-line responding to your questions by preceding my answer with [AW].

55 c9 1c 1a ask for frequency 1c=address
•40 32 8d 00 response from eval system
•40 ?? is this the address from the PGA with an address of 6? [AW]No, this is the UART Diagnostic Field byte. The PGA460 always initiates its response with a diagnostic field byte to inform the user that the last command was received+processed successfully or not. A value of 0x40 indicates no error. See section 7.3.6.2.1.7 Diagnostic Field of the datasheet for details regarding this byte.
•32=40khz frequency [AW] Correct.
•8d ?? what is the 8d in response [AW] This is the UART checksum generated by the PGA460 device. Similarly to the diagnostic filed byte, the PGA460 always ends its UART transmission with a checksum to detect errors in the data. The checksum information is optional available for use by the master, but is always provided. In this example, 0x8D is the checksum value of { 0x40, 0x32 }.
•00 ?? [AW] This is not part of the UART return, can be ignored.

[AW] Please refer to Figure 28 of the datasheet to see the UART Register Read Response Example which explains this command above. Also see Table 3 - Interface Command List to understand what each byte for a response command means.

-------------------
WE SEND THIS COMMAND 5 I understand the other requests and setup commands
55 ca 40 80 74 echo and retrieve 2 results
55 c0 02 3d
55 ca 40 00 f4
55 c0 02 3d
55 c5 3a
55 ca 40 00 f4
55 c9 4c e9
55 c9 4d e8
55 c9 1f 17

IT RESPONDS WITH THIS
40 00 c0 ff ff 29 5c ff ff 79 00 //response 295f uS=1.828m which is correct !
40 ?? what is this ?? [AW] UART diagnostic byte as explained above.
00 ?? [AW] Object 1 distance MSB
c0 ?? [AW] Object 1 distance LSB
ff ?? [AW] Object 1 width
ff ?? [AW] Object 1 amplitude
29 5c is 0295C hex is 1.828m ping which is correct [AW] Correct, Object 2 distance MSB,LSB
ff is width ? [AW] Object 2 width
ff is amplitude? why is it so high? [AW] Object 2 amplitude
79 ?? [AW] PGA460 calculated checksum
00 ?? [AW] null data, ignore

[AW] The Object 2 amplitude and width is at 0xFF because it is likely the echo signal is saturated, and very wide. You need to reduce your TVG levels and/or Digital Gain multiplier to prevent saturation.
Object 1 is likely triggering very early due to the threshold level and/or threshold glitch timer. See FAQs #5.2 & 5.6 from the Frequently Asked Questions (FAQ) and EVM Troubleshooting Guide (www.ti.com/.../slaa733.pdf) for details on how to mitigate this issue.

0 Pradeep Kumar R over 6 years ago in reply to Akeem Whitehead

Intellectual 290 points

Hello Akeem whitehead

Can you please tell how to get a proper data values through bulk read from pga.
Because if i read through bulk command i cannot read first 6 bytes properly. But after 6 bytes its coming exactly.
Same problem happens for both eeprom bulk read command and ultrasonic measurement results command.
I stuck here. I can read Echo data dump precisely but not ULTRASONIC MEAS RESULT(Object distance).
please help me to solve this problem.

Advance thanks....

0 Pradeep Kumar R over 6 years ago in reply to Pradeep Kumar R

Intellectual 290 points

Hello Akeem whitehead

Like data dump memory address(0x80) type is there any memory address for "ultrasonic meas result" so i can read byte by byte correctly.

0 peter mccormick over 6 years ago in reply to Akeem Whitehead

Expert 1080 points

I read the app note slaa733 to try to "ignore initial burst and decay..." on page 18 so that I can only look for 1 Object instead of seeing this initial crossing #1 on burst and finally my real object as #2. I set the threshold and played with the gains but it still sees the threshold and a distance of .06m for object 1

=set max Thresholds 248

=set gain 1 to minimum of 248. Also set tried with gain 1 to maximum but still same result.

=Threshold Deglitch T is 120uS max which is not enough.

There does not appear to be a way to make the threshold more than the amplitude of the initial burst so it always sees it cross the threshold at .06m.

Is there a deglitch, gain, or threshold that I am not properly setting on the eval software?

PeterLassosPGAcreenshots.pdf

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

Hi Peter,
You have the right idea, but you forgot one step to maximizing the initial threshold to ignore the initial activity. The threshold offset (toward the bottom of the threshold page). Referring to FAQ#5.2 & Figure 17: 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.

You can also try adjusting your the BPF bandwidth and cutoff frequency on the General-->Receive block.

0 Akeem Whitehead over 6 years ago in reply to Pradeep Kumar R

TI__Mastermind 27780 points

Hi Pradeep,
There is no direct address space to read the Ultrasonic Measurement Result (UMR)directly. Only command 5 can be used to read the results. Note, be sure to set the DATADUMP_EN bit to '0' to enable the UMR mode, and properly set your thresholds.

What are the values of the first six bytes reutrned from the EEPROM bulk read command?

0 Pradeep Kumar R over 6 years ago in reply to Akeem Whitehead

Intellectual 290 points

Hello akeem whitehead

What are the values of the first six bytes returned from the EEPROM bulk read command?
3
6
18
30
C0
80
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
C0
32
F0
12
12
35
F5
58
33
EF
7C
F
70
0
0
10
5
0
this is what i read through bulk read command..

USER_DATA1 = 0x00;

USER_DATA2 = 0x00;

USER_DATA3 = 0x00;

USER_DATA4 = 0x00;

USER_DATA5 = 0x00;

USER_DATA6 = 0x00;

USER_DATA7 = 0x00;

USER_DATA8 = 0x00;

USER_DATA9 = 0x00;

USER_DATA10 = 0x00;

USER_DATA11 = 0x00;

USER_DATA12 = 0x00;

USER_DATA13 = 0x00;

USER_DATA14 = 0x00;

USER_DATA15 = 0x00;

USER_DATA16 = 0x00;

USER_DATA17 = 0x00;

USER_DATA18 = 0x00;

USER_DATA19 = 0x00;

USER_DATA20 = 0x00;

TVGAIN0 = 0x00;

TVGAIN1 = 0x00;

TVGAIN2 = 0x00;

TVGAIN3 = 0x00;

TVGAIN4 = 0x00;

TVGAIN5 = 0x00;

TVGAIN6 = 0x00;

INIT_GAIN = 0xC0;

FREQUENCY = 0x32;

DEADTIME = 0xF0;

PULSE_P1 = 0x12;

PULSE_P2 = 0x12;

CURR_LIM_P1 = 0x35;

CURR_LIM_P2 = 0xF5;

REC_LENGTH = 0x58;

FREQ_DIAG = 0x33;

SAT_FDIAG_TH = 0xEF;

FVOLT_DEC = 0x7C;

DECPL_TEMP = 0x0F;

DSP_SCALE = 0x70;

TEMP_TRIM = 0x00;

P1_GAIN_CTRL = 0x00;

P2_GAIN_CTRL = 0x10;

this is what i exactly wrote into EEPROM.

0 Pradeep Kumar R over 6 years ago in reply to Pradeep Kumar R

Intellectual 290 points

hello akeem whitehead

And i have one more doubt. What are thresholds For two transducer configuration. Because there is no burst and decay time in receiving transducer.

0 Pradeep Kumar R over 6 years ago in reply to Pradeep Kumar R

Intellectual 290 points

Hello akeem whitehead

i just continued further testing with two transducers on default thresholds of case 0 as in sample program.

good news is i found right for the object at 2.22 meters

not so good news is am also finding stray values as in screenshot and the sequence continuesly repeats until anther stray value of 10.84 after which i do not either 2.22 or other stray values. In fact it remains 10.84 need guidance on what i may be doing wrong.

0 Akeem Whitehead over 6 years ago in reply to Pradeep Kumar R

TI__Mastermind 27780 points

Hi Pradeep,

I am able to run the EEPROM bulk read command without the initial six-byte error. Here is a screen shot showing what the respond should look like when running the command via the GUI. Notice that the first byte should read out as 0x40, which represents the diagnostic byte with no errors reported from the last UART transaction. Do you also receive 0x40 as your first response byte when running the bulk EEPROM read command, and after (subsequent command)?

How are you writing the first six bytes of the user EEPROM space? Are you using the bulk EEPROM write command? If so, send me the master transmitted sequence you are sending for the bulk write.

When using a bi-static transducer configuration, the threshold does not need to consider the decay profile or time, and can be set more linearly.

The "stray" values could be a result of the echo barely being strong enough to trigger an object detection capture, you are not clearing the serial buffer between commands, the serial read is too fast and corrupting the time-of-flight data, or you are not allowing enough time to pass between burst+listen commands. If not already, please refer to the latest version (1.0.2) of the PGA460 Energia library which helps to improve the ultrasonic measurement result stability by adding additional margin to the serial read time.

0 peter mccormick over 6 years ago in reply to Pradeep Kumar R

Expert 1080 points

We tried using 2 transducers hoping that there we could have objects much closer than about 30mm. The second transducer seems to "hear" the transmitting transducer so you really don't save much. We had much better success by finding a transducer that has low ringing time instead of using 2 transducers. I obviously don't know your application and am not a TI employee expert but thought this might be helpful.

Peter

0 Pradeep Kumar R over 6 years ago in reply to peter mccormick

Intellectual 290 points

Hello akeem whitehead

How are you writing the first six bytes of the user EEPROM space? Are you using the bulk EEPROM write command? If so, send me the master transmitted sequence you are sending for the bulk write.

1. Storing EEPROM DATA one by one into registers
2. Moving them to buffer.
3. writing them serially using softserial(my MCU has only one UART).

0 peter mccormick over 6 years ago

Expert 1080 points

We wired the ability to send data to the RX line from the TI dev board, a PC and out product called the "Omega"

We tested by sending the simple READ command to the PGA. It returns a valid answer always when sent from the TIDev board and PC.

Pulling our hair out trying to figure out why there is no response when 55 C9 1C 1A is sent from our device, ever.

Overlays of traces from PC and our device are shown below. Everything appears to be identical. All I can think is that out baud rate is not Exactly 9600 so it does not respond. Any ideas why we cannot get the PGA to respond when the traces going to the RX line seem identical?

Thanks, Peter

0 peter mccormick over 6 years ago in reply to peter mccormick

Expert 1080 points

Got it to work so never mind. We changed the clock source on the MSP430 for more precision at 9600 baud. Even though it all looked good on the scope and serial monitors, it appears as if the PGA requires a more precise baud rate to do the autobaud on 55.

0 Akeem Whitehead over 6 years ago in reply to Pradeep Kumar R

TI__Mastermind 27780 points

Pradeep,

Here is an example of what I am sending:

Command 12 EEPROM Bulk Write:
0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AA AA AA 00 00 00 00 C0 8C 00 01 12 07 FF 1C 00 EE 7C 0A 00 00 00 00 FA

then reading back the bulk data to verify the register values have been updated correctly

Command 11 EEPROM Bulk Read:
0B F4
return data:
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AA AA AA 00 00 00 00 C0 8C 00 01 12 07 FF 1C 00 EE 7C 0A 00 00 00 00 C6

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

Peter,
Is your master's UART configured for 8 data bits, 2 end/stop bits, no parity, no flow control? By default, most UART terminals are configured for 1 end/stop bit, which will still work with the PGA460 at low baud rates. If you're already configured with 2 end/stop bits, then there is definitely a lower-level clocking issue at fault. What baud rate do you prefer to use?

0 peter mccormick over 6 years ago in reply to Akeem Whitehead

Expert 1080 points

We changed to a more precise clock on the MSP430 so now everything is perfect and it does everything we need (for now). It seems that it does not like a baud clock that is not exact.

Petert

0 Pradeep Kumar R over 6 years ago in reply to Akeem Whitehead

Intellectual 290 points

akeem whitehead

The same what am doing here. But the problem is PGA Device is always busy when i wanted to take anything back from PGA. I checked PGA busy through diagnostic command from PGA during response command from Master.
I had done almost everything Like BULK writing, Register Read and write, Data dump Read(getting exact echo), Bulk threshold writing. But the problem is my SoftwareSerial is not properly Reading Bulk read commands(in some cases Register reading also). I am using arduino Uno, so it is necessary to use SoftwareSerial.

0 peter mccormick over 6 years ago in reply to peter mccormick

Expert 1080 points

There is about 20 ft of wire between the PGA sensor and our MSP430 based product. We put a driver chip for the PGA RX line

msp430>driver>----------PGA Rx.

Should we put a driver chip next to the PGA for the data back to the MSP430? If the PGA has a 25mA driver on the TX line then that should be good over 20ft of twisted pair wire. I could not find the TX mA driver spec.

Thanks, Peter

0 peter mccormick over 6 years ago in reply to peter mccormick

Expert 1080 points

We cannot get a New PGA to communicate using RX and TX. I read the memory from a working PGA and saved it into a new non-working PGA and saved it to EPROM. Now it communicates.

What register changed that made it suddenly work?
Does it working have something to do with the IO_DIS bit in address 1E? If yes, how do we enable RX TX on a new device?

Do we program 1E to 24 then store EEPROM to force RX TX to work on a new device?

;GRID_USER_MEMSPACE
00 (USER_DATA1),00
01 (USER_DATA2),00
02 (USER_DATA3),00
03 (USER_DATA4),00
04 (USER_DATA5),00
05 (USER_DATA6),00
06 (USER_DATA7),00
07 (USER_DATA8),00
08 (USER_DATA9),00
09 (USER_DATA10),00
0A (USER_DATA11),00
0B (USER_DATA12),00
0C (USER_DATA13),00
0D (USER_DATA14),00
0E (USER_DATA15),00
0F (USER_DATA16),00
10 (USER_DATA17),00
11 (USER_DATA18),00
12 (USER_DATA19),00
13 (USER_DATA20),00
14 (TVGAIN0),8D
15 (TVGAIN1),EE
16 (TVGAIN2),EF
17 (TVGAIN3),10
18 (TVGAIN4),A5
19 (TVGAIN5),20
1A (TVGAIN6),FC
1B (INIT_GAIN),40
1C (FREQUENCY),32
1D (DEADTIME),F3
1E (PULSE_P1),24
1F (PULSE_P2),C0
20 (CURR_LIM_P1),5C
21 (CURR_LIM_P2),7F
22 (REC_LENGTH),67
23 (FREQ_DIAG),11
24 (SAT_FDIAG_TH),22
25 (FVOLT_DEC),69
26 (DECPL_TEMP),40
27 (DSP_SCALE),00
28 (TEMP_TRIM),00
29 (P1_GAIN_CTRL),19
2A (P2_GAIN_CTRL),22
2B (EE_CRC),73
40 (EE_CNTRL),00
41 (BPF_A2_MSB),85
42 (BPF_A2_LSB),8D
43 (BPF_A3_MSB),F9
44 (BPF_A3_LSB),A5
45 (BPF_B1_MSB),03
46 (BPF_B1_LSB),2D
47 (LPF_A2_MSB),7E
48 (LPF_A2_LSB),67
49 (LPF_B1_MSB),00
4A (LPF_B1_LSB),CD
4B (TEST_MUX),00
4C (DEV_STAT0),80
4D (DEV_STAT1),21
5F (P1_THR_0),A8
60 (P1_THR_1),77
61 (P1_THR_2),77
62 (P1_THR_3),77
63 (P1_THR_4),8A
64 (P1_THR_5),AB
65 (P1_THR_6),FF
66 (P1_THR_7),F3
67 (P1_THR_8),6A
68 (P1_THR_9),45
69 (P1_THR_10),ED
6A (P1_THR_11),50
6B (P1_THR_12),46
6C (P1_THR_13),32
6D (P1_THR_14),2D
6E (P1_THR_15),07
6F (P2_THR_0),61
70 (P2_THR_1),6E
71 (P2_THR_2),65
72 (P2_THR_3),C9
73 (P2_THR_4),54
74 (P2_THR_5),58
75 (P2_THR_6),C6
76 (P2_THR_7),80
77 (P2_THR_8),DC
78 (P2_THR_9),39
79 (P2_THR_10),02
7A (P2_THR_11),42
7B (P2_THR_12),DD
7C (P2_THR_13),0C
7D (P2_THR_14),89
7E (P2_THR_15),85
7F (THR_CRC),BE
EOF

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

Hi Peter,
Out of curiosity, have you tried reducing the wire length to determine if this makes a difference in the success rate for UART communication? You are correct to assume that 20ft of cabling should not cause communication to fail. I assume power and ground are also cabled at 20ft?

Regardless of what the IO_DIS bit is set to, the UART Tx/Rx channels will always be responsive. IO_DIS only impacts communication mode on the IO pin.

I loaded your configuration to the GUI. Here are a few things I noticed:
•The first issue I notice is that this memory config assumes a UART_ADDR of '6', instead of the default '0'. I am changing the config's UART_ADDR to '0'.
•Preset 2's burst pulses is set to '0', so no transmit energy will be generated. I am increasing this to 16.
•Time Decouple is set to the minimum. I assume you are not using the decouple feature since I do not see it connected on your schematic. I am maximizing this to 65.536ms to prevent any possible false positives.
•Since you are using a transformer driver mode, there is no reason to set the deadtime to a non-zero value. Setting deadtime to 0us.
•The threshold is random. I assume you did not clear the THR_CRC_ERR before saving the memory grid. I am updating the threshold to mid-code values so the THR_CRC_ERR clears with reasonable values.

After applying the aforementioned changes, this is the new altered memory map:

;GRID_USER_MEMSPACE
00 (USER_DATA1),00
01 (USER_DATA2),00
02 (USER_DATA3),00
03 (USER_DATA4),00
04 (USER_DATA5),00
05 (USER_DATA6),00
06 (USER_DATA7),00
07 (USER_DATA8),00
08 (USER_DATA9),00
09 (USER_DATA10),00
0A (USER_DATA11),00
0B (USER_DATA12),00
0C (USER_DATA13),00
0D (USER_DATA14),00
0E (USER_DATA15),00
0F (USER_DATA16),00
10 (USER_DATA17),00
11 (USER_DATA18),00
12 (USER_DATA19),00
13 (USER_DATA20),00
14 (TVGAIN0),8D
15 (TVGAIN1),EE
16 (TVGAIN2),EF
17 (TVGAIN3),10
18 (TVGAIN4),A5
19 (TVGAIN5),20
1A (TVGAIN6),FC
1B (INIT_GAIN),40
1C (FREQUENCY),32
1D (DEADTIME),F0
1E (PULSE_P1),24
1F (PULSE_P2),10
20 (CURR_LIM_P1),5C
21 (CURR_LIM_P2),7F
22 (REC_LENGTH),67
23 (FREQ_DIAG),11
24 (SAT_FDIAG_TH),22
25 (FVOLT_DEC),69
26 (DECPL_TEMP),4F
27 (DSP_SCALE),00
28 (TEMP_TRIM),00
29 (P1_GAIN_CTRL),19
2A (P2_GAIN_CTRL),22
2B (EE_CRC),CF
40 (EE_CNTRL),00
41 (BPF_A2_MSB),85
42 (BPF_A2_LSB),8D
43 (BPF_A3_MSB),F9
44 (BPF_A3_LSB),A5
45 (BPF_B1_MSB),03
46 (BPF_B1_LSB),2D
47 (LPF_A2_MSB),7E
48 (LPF_A2_LSB),67
49 (LPF_B1_MSB),00
4A (LPF_B1_LSB),CD
4B (TEST_MUX),00
4C (DEV_STAT0),80
4D (DEV_STAT1),00
5F (P1_THR_0),88
60 (P1_THR_1),88
61 (P1_THR_2),88
62 (P1_THR_3),88
63 (P1_THR_4),88
64 (P1_THR_5),88
65 (P1_THR_6),84
66 (P1_THR_7),21
67 (P1_THR_8),08
68 (P1_THR_9),42
69 (P1_THR_10),10
6A (P1_THR_11),80
6B (P1_THR_12),80
6C (P1_THR_13),80
6D (P1_THR_14),80
6E (P1_THR_15),00
6F (P2_THR_0),88
70 (P2_THR_1),88
71 (P2_THR_2),88
72 (P2_THR_3),88
73 (P2_THR_4),88
74 (P2_THR_5),88
75 (P2_THR_6),84
76 (P2_THR_7),21
77 (P2_THR_8),08
78 (P2_THR_9),42
79 (P2_THR_10),10
7A (P2_THR_11),80
7B (P2_THR_12),80
7C (P2_THR_13),80
7D (P2_THR_14),80
7E (P2_THR_15),00
7F (THR_CRC),28
EOF

0 peter mccormick over 6 years ago in reply to Akeem Whitehead

Expert 1080 points

Akeem,

I assume the address was the problem. RxTx came to life after loading the file and saving eprom so I assume it had something to do with the addressing. Shorter cable had no affect.

If we use the Decouple transistor and time decoupling, can we detect objects closer than about 20 inches? Now we see too much initial ringing so no detection less than 20 inches. Less than 20 inches would be nice. I have fooled with current and pulses and it didn't help much closer than 20 inches and still be able to do 10ft.

We only use Preset 1 burst-listen. Do we need to set P2_Pulse to make OUTA work with preset1 (confusing)? Does P2_pulse have something to do with preset 1 other than address?

I don't know why the thresholds are random what I sent you (probably forgot to reload thresholds before creating file). They are good on the graph.

Thanks, Peter

0 Akeem Whitehead over 6 years ago in reply to peter mccormick

TI__Mastermind 27780 points

Hi Peter,
The decouple transistor will not add any benefit to short range detection. You should be able to see objects within 20 inches (0.5m) with the circuit as-is. However, you can read through a discussion on another thread to see how to measure down to 0.1m after changing the value of the transducer's tuning cap from 1500pF to 680pF, and the dampring resistor from 2.7kOhm to 10kOhm. The thread is here:
e2e.ti.com/.../609638

The register named P2_PULSE just happens to contain the UART_ADDR for the entire device, but has not other impact on Preset 1.
Preset 1 and 2 are completely independent from one another. If you are not using Preset 2, then the P2 pulse count can be '0' The presets are best described as stated in the EVM User's Guide:

Presets — Two preset configurations can be saved to switch between two different use-cases for the
same hardware configuration. A typical best practice is to allocate Preset 1 for short distance
(i.e. between <30 cm to 1 m), and allocate Preset 2 for long distance (between 1 m to 7 m). The number
of burst pulses and the driver current limit determines the drive strength of the transmitting signal.
The record time length determines how long the listen mode is active to capture
and compute the ultrasonic data up to an equivalent distance.

It is possible to configure a single preset to detect both short and long ranges. This is where the TVG and digital gain multipliers become especially useful. If you cannot see below 20 inches, make sure your initial TVG gain and gain range are not too large, and your digital gain multiplier is set to a low value (x1 or x2).

0 Pradeep Kumar R over 6 years ago in reply to Akeem Whitehead

Intellectual 290 points

Hello Akeem whitehead

My arduino Uno's UART has 1 start bit, 8 data bits, 1 stop bit and no parity. But i don't know about softwareserial UART protocol. Is this causing any problem for a UMR bulk read. As i mentioned in my earlier posts i am stuck with UMR read. Am getting good DATA dump result but i am not UMR result as in data dump. It is definitely random result in UMR. Am using Hardware UART for serial monitor and Softwareserial for communicating with PGA. Please suggest me a good method, beacause i was stuck since last 2 months.

Advance thanks

0 Akeem Whitehead over 6 years ago in reply to Pradeep Kumar R

TI__Mastermind 27780 points

Hi Pradeep,
If your data dump result is ok, then you should be able to get your UMR to work.
Ensure you have:
• Set DATADUMP_EN bit to '0' to disable echo data dump mode, and enable object detection mode. (Note: Object detection cannot occur when the DATADUMP_EN bit is set to 1.)
• Set the threshold mapping with appropriate level and timing values. Try a fixed/mid-code set of values.
• Allowed the preset record length value to expire before attempting to read back the UMR values.
• Increase the number of objects to detect to a value of more than '1' in case the DSP-ramp is triggering a an early false positive for object 1.

The PGA460 datasheet has recently been updated to reflect the correct UART command listings in Table 3. Please ensure you have downloaded Rev.A of the datasheet at:
www.ti.com/.../pga460-q1

0 Pradeep Kumar R over 6 years ago in reply to Akeem Whitehead

Intellectual 290 points

Hello akeem whitehead,

Finally i get the UMR result from PGA 460. I changed softserial to normal hardware UART.
Now my question is, my minimum measurable distance is 20 inch. Am getting blindzone till 20 inch.
Am using two transducer one for Tx and one for Rx. Can you please suggest me how to overcome from this problem.

Is that necessary to connect Decoupling circuit for bi-static transducer configuration. If necessary what is the circuit connection for that configuration.

thanks for your previous suggestions and guidelines.

thank you

0 Akeem Whitehead over 6 years ago in reply to Pradeep Kumar R

TI__Mastermind 27780 points

Hi Pradeep,
20 inches (50cm) is a very long blindzone for nearly any transducer configuration (mono- or bi-static).
The decoupling pin is always optional, regardless if mono- or bi-static, and not required for the bi-static mode. If not used, ensure the DECPL pin is floating.

Here are a few items you can check:
1) Reduce your AFE gain range to 32-64dB
2) Reduce the Digital Gain Multiplier to x1
3) Disable Non Linear Scaling

With these noise and decay reductions, when does your blind zone now end?

Additional steps you can take to reduce the blindzone:
1) Depending on your driver mode, add passive tuning in parallel to the transducer. For direct-drive, only add a parallel damping resistor (1k-10kOhm). For transformer-driver, try adding both a damping resistor and tuning cap. Passive tuning is described in the PGA460 Ultrasonic Module Hardware and Software Optimization AppNote (www.ti.com/.../slaa732).
2) Minimize the reference voltage to 6-7V for a weakened driver.

Can you specify the transducers part numbers you are using, and provide your bulk EEPROM settings?

Sensors

Sensors forum

PGA460-Q1: PGA460-Q1