Это видео недоступно.
Сожалеем об этом.

Practical Pico: CAN bus testing and serial decoding Q&A

Поделиться
HTML-код
  • Опубликовано: 26 мар 2019
  • Barney, Steve and Ben will be answering questions that are asked during and after the "Pico Practical: CAN bus diagnostics and serial data decoding" presentation. The presentation will premiere on Monday 25th.

Комментарии • 7

  • @rodhonco5681
    @rodhonco5681 4 года назад

    Greatly appreciate your knowledge with the Pico Lab scope!

  • @andrewwilson8317
    @andrewwilson8317 5 лет назад +1

    Good job you guys shit hot with oscilloscopes!

  • @liviu2004
    @liviu2004 5 лет назад +1

    If Pico decodes a can message, how we ensure that the automotive controllers do as well? Or put it differently, can it be that acceptable voltage ranges in nodes maybe differ than acceptable ranges set in Pico software?

  • @liviu2004
    @liviu2004 5 лет назад +1

    Questions:
    1. Can Pico software sort live decoding on ID rather than time? And freeze the last message until a new one comes for that ID?
    2. Can Pico software introduce persistance mode but in reverse logic, such that, in combination with question 1 above, any byte change within a new message for same ID, gets colored for a few seconds?
    You know that other companies do that and that is the only reason why serial decoding is needed, besides checking if CAN integrity is ok.

    • @PicoScopeAutomotive
      @PicoScopeAutomotive  5 лет назад

      Thank you for the questions. With regards to Question 2 I will add this to the new feature requests for sure as it could be useful to some users. We do need to mindful that the scope is not a CAN logger and as such does have some limitations as Steve mentioned in our Q&A session last night. That being said when it's all you've got then as long as you are aware of the limitations then why not?
      I believe the to answer question 1 you are looking to use the filter option which is already a feature within the serial decode. This will pick out and only display the ID which matches what you have inputted into the filter field. I've not tried it but I see no reason as to why you wouldn't be able to use this whilst capturing data. Referring back to the main video Steve and Barney did on CAN decoding I have a feeling Steve does use filtering when looking at a specific ID from the shift lever.

    • @stevesmith4724
      @stevesmith4724 5 лет назад +1

      @@PicoScopeAutomotive Hello and thank you for the feedback.
      With regards to: “If Pico decodes a can message, how we ensure that the automotive controllers do as well? Or put it differently, can it be that acceptable voltage ranges in nodes maybe differ than acceptable ranges set in Pico software?”
      This is a great question as we can never assume all CAN Controllers have decoded correctly just because PicoScope has decoded successfully. PicoScope will decode CAN data based upon the threshold voltages selected during the decode set up (which may not be present on the entire CAN BUS). We assume that all CAN controllers are receiving identical voltage levels from the CAN BUS on their respective terminals, but this is not the case. A fault may exist in a CAN branch wire to one CAN ECU/node leaving this node unable to decode, whilst the remaining nodes decode successfully (Inc. PicoScope) With regards to voltage ranges in nodes, the following forum post will help explain how each CAN node is able to deal with varying voltage thresholds on their respective CAN BUS terminals www.picoauto.com/support/topic21743.html
      In such a scenario where one CAN node has failed to decode due to extreme CAN Bus voltage variation we have a number of possible scenarios.
      1. Serial data reports loss of communication to a CAN node that cannot decode CAN BUS data
      2. Multiple CAN nodes reporting loss of communication with one particular CAN node (pointing the finger)
      3. Serial “Data BUS Check” listing “Nodes on line” reveals one missing node
      4. Decoded data displayed in PicoScope may reveal multiple recessive bits within the RTR, ACK fields or CRC errors
      5. Using a dedicated CAN Decoder/Logger would also reveal the field errors mentioned at point 4 above, but decoded at the Silicone level rather than PicoScope at the Physical layer.
      We must remember that PicoScope is not a dedicated CAN Decoder/Logger but an Oscilloscope with limited decoder/logger features. Decoding CAN data based on voltage levels captured at a single measurement point on the CAN BUS (Physical layer) is potentially floored given the voltage levels may not be the same throughout the CAN BUS!
      The following forum post looks a little deeper at unique voltage signatures associated with CAN nodes www.picoauto.com/support/topic21680.html#p98339
      Decoding at the Silicone Layer (via a dedicated CAN logger) allows you to capture exactly what each node can see, as each node will display its interpretation of data from the voltages present on their respective CAN terminals. Here we “By-Pass” the Physical layer measurement to obtain feedback from each CAN controller within each node on the BUS.
      With that said, should the Silicone layer display errors (via your CAN logger) then we need to check the Physical Layer with PicoScope either at one erroneous node, or the complete BUS if multiple nodes are reporting decode errors
      I hope this helps, take care……Steve

  • @liviu2004
    @liviu2004 5 лет назад +2

    We can’t hear the questions ... Speak up and all words ...