PGA460-Q1: I/O communication issue with 5 sensors

Hi Krzysztof,

The commands you sent indicate that you want to detect eight objects.  As a result, when you send an ultrasonic measurement result command, the PGA460 should respond with one diagnostic byte, 4x8=32 data bytes, and one CRC byte (34 total bytes in total).  In the PGA460 response packet that you received, I count 34 bytes as expected.  Based on the response packet, 0x55 seems to be the peak amplitude value for object 4 and 0x1EE1 seems to be the time of flight for object 5.

Can you tell me the following:

• What packet are you sending for communicating to the devices with other addresses? In the response packet, error status [3] (see Table 4 of datasheet for details) seems to be asserted in the diagnostic byte, which would indicate that an invalid checksum was received from the master at some point. 
• What do you get if you do a register read of each device’s PULSE_P2 register (address = 0x1F)?

Thank you,

Mekre

hi,

In general: I do not claim standard IO communication for 5 sensors which works correctly until on IO bus reserved command(26-31) + CRC occurs.

KEY point is this sequence can occur during feedback of measurements from sensor and it is visible as below. it is possible because we do not have any influence for measurement data from sensor. Point is there is no any protection for such cases.

 Example 1 – real data from IO bus, 1E(30) is reserved, in this case sensors 2-5 stopped working because 55 1E E1 came from 1^st sensor

“55 29 4C 8A 40 80 3F

55 21 08 D6

55 25 48 0C 6A 57 D5 12 09 33 59 1A E5 85 78 1D 7A 29 54 1E EF 20 4A 21 46 54 9E 23 1C 3A 79 FF FF FF FF 93

55 21 08 D6

55 25 48 0C 6A 57 D6 12 0A 33 5A 1A E6 86 77 1D 79 29 55 1E E1 23 4C 21 49 54 9C 23 19 3A 76 FF FF FF FF 9D“

Example 2– real data from IO bus, 1B(27) is reserved, in this case sensors 1-4 stopped working because 55 1E E1 came from 5^th  sensor

 “55 A1 08 56

55 A5 60 15 B3 34 6F 16 D2 AC 73 1A 00 50 55 1B E4 12 48 1D 5C AF A3 20 8A DB D2 FF FF FF FF FF FF FF FF E9“

Communication sequence for other addresses is the same, example for addr =1 

“55 29 4C 8A 64 80 1B - reading register 0x4C

55 21 08 D6 - sending configuration

55 25 60 17 9B 81 95 1A C1 24 45 1B B9 42 96 1D 02 FF E5 22 3C 34 63 FF FF FF FF FF FF FF FF FF FF FF FF E7 - getting result of measurement

“

Feedback for 0x1F:

55 29 1F B7 40 25 9A

We are going to test below sequence:

1. Go to low power mode for sensors which are not used for measurements sensor 2-5:  DECPL_TEMP field LPM_EN -> 1b
2. Make measurement for sensor 1
3. Wake up all sensors -> send on bus 0x00
4. Go to 1^st point but use other sensors to make measurement for sensor 2…

Hi Krzysztof,

Can you provide a picture that shows how the UART TX and RX pins of the different devices are connected?  Are you saying that you have the UART TX pin of a device also connected to the UART RX pins of the other devices?    

Regards,

Mekre

hi Mekre,

As a communication bus we use IO  pin on PGA460 we do not use UART = pins are not connected,

All 5 sensors are connected via IO pin to communication bus.

But I assume we went to wrong direction pls read my post above. it is not related to hardware.

Based on our experiences PGA460 is not protected for broadcast reserved commands when we have more than 1 sensor on IO communication bus. So measurement feedback from one sensor can interfere others. That is the key point of this post and question is what is solution for such case?

Hi Krzysztof,

Thank you for clarifying that you are using one-wire uart on the PGA460’s IO pin.  I believe I now understand the issue that you are seeing now.  Can you confirm if this is correct:

You are using one-wire UART for communication on the IO pin of the PGA460. This pin is connected on five different PGA460 devices, where each device has a different UART address.  When you send a burst and listen command to only one of these sensors, the addressed sensor responds with a packet that has 0x55 0x1E 0xE1.  The other four sensors see the 0x55 0x1E 0xE1 part of the packet as a valid command because it has a sync byte, 0x1E is a reserved broadcast command, and the CRC is valid.  After this happens, you are not able to communicate with the other four devices.  Is this correct?

I will need to check internally within our team about the issue that you are seeing.  I should have my next update on Monday or Tuesday. 

Also, I am not able to view the file you attached since it wasn't attached to the actual post, but I think I have all the info I need for now.

Regards,

Mekre

hi,

"You are using one-wire UART for communication on the IO pin of the PGA460. This pin is connected on five different PGA460 devices, where each device has a different UART address". --> YES

  "When you send a burst and listen command to only one of these sensors, the addressed sensor responds with a packet that has 0x55 0x1E 0xE1." --> yes, it occurs randomly in measurement data sending by one of sensors. so that is issue which is unpredictable. Above you can find two real examples. Summary in below link: 

  "The other four sensors see the 0x55 0x1E 0xE1 part of the packet as a valid command because it has a sync byte, 0x1E is a reserved broadcast command, and the CRC is valid.  After this happens, you are not able to communicate with the other four devices" --> YES

regrds

 k.

hi Mekre,

is it your final solution proposal or are you still going to discuss with engineering team?

your proposal could work but it is much complicated from programming point of view so I am wonder if you can develop easier solution.

regards

    k.

Hi Krzysztof,

I was able to finish getting feedback from the internal team before my last post.  This is the proposal that we discussed with the internal team.  

Regards,

Mekre

hi,

so it is bad news for us,

we need to look for better solution when it is part of commercial product and key function! we cannot play with changing communication mode! it is too risky! 

with regards

k.

Hi Krzysztof,

I am sorry to hear that.  Unfortunately, this is the best workaround we have for dealing with this issue.

Regards,

Mekre