• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 646 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: PGA460-Q1 SPI communication unclear SPI protokoll

Olfu
Prodigy 100 points
Part Number: PGA460-Q1
Other Parts Discussed in Thread: ENERGIA, PGA460

Hello

I have encountered an unclear documentation of the behaviour at the Ultrasonic results command (5).

According to the PGA460-Q1 latest data sheet this is a response command with no data sent to PAGA460.
This implies that only sync byte and command byte needs to be transferred to get the Ultrasonic measurement results.

In the Energia example there is in addition a checksum transmitted.

Line 1039;         byte buf5[3] = {syncByte, UMR, calcChecksum(UMR)};

What is correct?
I tried both and got an RX response already after the command. So I would expect checksum is not necessary?

What I am wondering in addition is the fact is that I get no checksum results (always 0x00) in last byte from the PGA460 in the MISO line.
This is the case w and w/o checksum in TX at the receiver transfer (14 byte for 3 objects but also for other number of objects) 

In Energia no RX checksum is analyzed. 

Is this a correct behaviour? 

Where is this documented?

BR

Oliver

  • 0
    TI__Mastermind 27950 points
    Hi Olfu,

    You do not need to transmit the checksum byte for command 5 or all other response operations (except register read). See section "7.3.6.2.1.6.2 Response Operation (All Except Register Read)" of the datasheet for additional details. The Energia code demonstrates that you can add the checksum to every master transmitted command without error. For maximum efficiency, you can remove the master generated checksum from response operation commands.

    All slave responses from the PGA460 should generate a checksum including command 5 (UMR read) . Here is an example where all eight (max # of objects) UMR results are zero, but the checksum is non-zero:
    40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BF
    You should see one diagnostic byte, 4*8=32 UMR bytes, and one checksum byte for a total of 34 bytes.

    Can you use an oscilloscope to confirm the device is responding with the correct number of bytes? Perhaps the code is not configured to read the correct number of response bytes.
  • 0 in reply to Akeem Whitehead
    Prodigy 100 points

    I confirmed this behaviour with an Oscilloscope. See attached screen shot.

    I have configured 3 Objects. Ind the received data you can see in the next screen shot showing the debugger readouts from the receiver butter.

    In all other commands I get correct checksum.

    BR

    Olfu

  • 0 in reply to Olfu
    Prodigy 100 points

    Hi Akeem

    meanwhile I tried to read on additional byte (drag, 3 objects, checksum, spare)  to see if something went wrong but also  here no checksum is transmitted or calculated as 0x00.
    See attached screen shot.You can seethe the diagnostic field (64 or 0x40) indicates no error. Also Scope shows checksum 0x00 transmission.

    I have set some thresholds form the Murat 40?? example but I have another but similar Transducer. So could it be the bas that no checksum is calculated by the PGA460 because the 
    ultrasonic results are not valid?

    BR

    Oliver

  • 0 in reply to Olfu
    TI__Mastermind 27950 points
    Hi Olfu,
    If the burst/listen command is not successfully executed prior to reading the UMR, or a fault or diagnostic error is gating the UMR from updating, then it is possible that the checksum will be zero. Can you reattempt this experiment with a proper threshold and confirmed object detection?
  • 0 in reply to Akeem Whitehead
    Prodigy 100 points

    Hello Akem

    meanwhile I found that if the PGA 460 detects less objects than requested, these objects are reported and closed with the appropriate checksum.

    So when for example, 3 objects where requested and only two are found, the two are reported with checksum at the end of the second object data. Which makes sense but is not documented as far as I see.

    But this leads to the same direction as you proposed. Setting the threshold so low that always the number of requested objects will be detected you will always get he checksum at the expected position, but the objects a probably are detected from noise.

    Br

    Oliver