One problem with CAN is that it is not a good word to search for in any forum so I hope I'm not duplicating another topic (I hope using CAN-BUS in a topic helps).
I use my PicoScope 3000 series for decoding decoding data in a CAN Bus. I can see that the bus is working because there is a device that shows the data on a display and there data is updatind al the time. But when I look at the data in Picoscope 6, most of the datapackets are reported with errors. Sometimes CRC, Bit Stuffing and Valid column are all wrong and no data is shown, sometimes only the Valid column shows cross. But even if everything is wrong, the display still shows that actual values. What I also notice is that most of the time, only one channel is properly decoded. It can be H or L, but (almost) never both.
Maybe it is just the way I connect the probes, but I wouldn't know what. Does anyone have tips on what to watch out for? A list of common mistakes (if they are common, I probably made them )
Devices attached to the bus are one device that send a 0x37 message each second with temperature values in it. The other sends 0x36 messages with suspension values. Each second if there is no change, otherwise as as as the Arduino can send them. In the dataset attached, not one was seen as a proper message whereas the display showed the changing dat al the time.
I've tried some more myself, but I'm only getting more confused. Would me nice if yo could shed a light on it.
I would suggest using an Advanced Trigger, Pulse Width with a time of 25usec, and set the position to 5% so that you always get the start of the message.
Sorry it took me some time to return to this thread. I also have to spend some time working, but mostly your replies showed me how little I knew and I didn't want to be the proverbial newbie to which you can only say RTFM.
So, I decided to experiment a bit with the triggers and although there is still more to learn, I am now able to get good results. But, it wasn't only the triggers. I also noticed that the default settings for serial decoding tool are not, as I would expect, based on built-in knowledge of the CAN protocol, but are determined by logic I don't understand yet but that goes of the rails sometimes (maybe if you start the decoding tool without a CAN signal present?).
But anyway, the settings aren't really critical, as long as they are compliant with the protocol. So, 2V for CAN lo en 3V for CAN hi will do. The only time I see an Invalid message now is when I immediately see a retransmit, so it really was a flawed message.
So thanks for the help. I learned lot and maybe this can help others as well.