CAN bus analyzeren

Hey, ik zou graag een rPi aan mijn domotica systeem koppelen.
Dit systeem werkt via CAN bus.
Ik heb de hardware koppeling gemaakt, en krijg data binnen als ik op knopjes duw, maar ik snap er niets van..
ik gebruik " DEBO CAN MODUL MCP2515/MCP2562" op mijn rpi en lees uit via candump.

Hoe begin je aan de analyse van de data? Kan je ergens afzender zien?

hieronder zie je hoe ik 2keer op een knop duw, maar hoe weet ik wat een knop event verstuurd? voor hetzelfde geld is 1e lijn verstuurd door op de knop te duwen, en 2e lijn is een ander device die daarop antwoord, of gans de blok is gewoon data die verstuurd wordt door de device die knop duw event ontvangt..

Iemand tips hoe je zoiets analyseert?

can0 01600D00 [5] 92 68 05 00 01
can0 01640D00 [3] 00 A2 0B
can0 01B80B00 [2] remote request
can0 01A00B00 [5] 92 50 00 05 01
can0 01A40B00 [3] 00 1A 00
can0 01780D00 [8] remote request
can0 01AC00FF [4] 62 05 04 00

can0 01600D00 [5] 93 68 05 00 01
can0 01640D00 [3] 00 A2 0B
can0 01B80B00 [2] remote request
can0 01AC00FF [4] 62 05 04 01
can0 01A00B00 [5] 93 50 00 05 01
can0 01A40B00 [3] 00 1A 00
can0 01780D00 [8] remote request

Alvast even een klein beginnetje.
Elke regel van de dump is een apart CAN bericht.
De waarde tussen[ ] geeft het aantal data bytes aan dat met een bericht meekomt. Dus [3] betekent 3 data bytes. Deze bytes staan rechts van deze aanduiding.
Links van deze aanduiding staat de bericht header met o.a. afzender en het verzend adres.
Ik zou er ook even in moeten duiken om de afzender er uit te kunnen halen.

aha we zijn al stap verder
als ik dit vestuur

can0 01600D00 [5] 93 68 05 00 01
can0 01640D00 [3] 00 A2 0B

gaat licht aan en licht uit.

Nu wordt het dus elke knop afgaan en noteren wat er achter zit...
En dan guitje maken is we zijn vertrokken

code:


can0            Dit is de device op je Pi
01600D00        Dit is het message ID
[5]             lengte van de data (DLC)
92 68 05 00 01  de databytes zelf

zie wiki of https://www.canopen.nl/can-2.0/het-formaat-van-een-can-bericht

het is mogelijk dat jouw lichtschakelaar een node nummer heeft en daar een message ID bij hoort. Hoe meld je de lichschakelaar aan in het systeem? Dipswitch? draaischakelaar?

heb je een master? zit er ergens een besturingsbox?

ik zou beginnen met afluisteren tussen maximaal 2 deelnemers.

maak verschillende dumps:
Schakelaar 1 verbonden-stand uit
Schakelaar 1 verbonden-stand aan
Schakelaar 2 verbonden-stand uit
schakelaar 2 verbonden-stand aan

zo kun je filteren wat de data en message verschilt, maar ook wanneer deze overeenkomt.

[Bericht gewijzigd door Progger op dinsdag 5 januari 2021 22:09:33 (19%)

GMT+1

Het CAN-ID moet voor elke message die een controller verstuurd binnen het netwerk uniek zijn. Je kunt het een beetje beschouwen als het verzender adres (maar officieel is er geen verzender adres).

Een uitzondering op die duplicaten is een RTR (Remote Frame), daar is het data pakket altijd leeg (0 bytes). Waarom in de dump 2 staat weet ik ook niet maar zou niet moeten. Zo'n pakket is een broadcast naar alle nodes om te vragen wat de data is die bij het CAN-ID hoort wat zojuist verzonden is. De controller die het CAN-ID "bezit" hoort dan die message te herhalen.

Als er meerdere devices zijn die eenzelfde apparaat aansturen moeten die dus ieder een eigen uniek CAN-ID hebben en zal in de DATA van het CAN frame dus een commando of iets dergelijks moeten staan wat er moet gebeuren. Of je gebruikt (ook) een paar bits van het CAN-ID om aan te geven wat je wilt schakelen.

Wil je zelf (vanuit je RPI) dus iets anders aansturen moet je een CAN-ID gebruiken wat in het CAN netwerk uniek is anders gaat het mis.

Er wordt dus nooit data naar een specifieke ontvanger gestuurd: alles is een broadcast en de ontvangers die geinteresseerd zijn in een bericht kunnen er iets mee doen.

1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.

Een RTR frame bevat geen data, maar de DLC bevat de lengte van het bericht dat je terug verwacht te krijgen. In de praktijk wordt dit veld meestal genegeerd.

Het valt me op dat het gevraagde pakket niet verstuurd wordt.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
High met Henk

Special Member

@henri:

totaal niet waar: ik ben al zoveel varianten tegengekomen:

ooit in een trekker al een bericht gezien met 4x zelfde ID die in een burst van 10 mS verschil, dan 100 ms dood TOTAAL verschillende data verstuurde..

heeft me wel even gekost omd at uit te filteren....

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

@HmH: dat is waarschijnlijk een multiplexed message geweest; daarbij wordt een langere array van data in blokken verstuurd, waarbij het eerste byte meestal een oplopende waarde heeft, waarmee wordt aangegeven welk deel van de totale transmissie in dat bericht zit.

Meerdere nodes die op dezelfde ID gaan zenden is echt het grootste recept voor problemen; de arbitation werkt dan niet meer, nodes gaan error frames verzenden, error counters gaan oplopen, nodes gaan naar BUS-OFF state, etc.

Dat geeft dus gelijk een probleem voor de TS: je kunt niet zomaar berichten met een bepaalde ID op een bus gooien, als de oorspronkelijke verzender van die berichten ook nog actief is.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
High met Henk

Special Member

klopt helemaal sparky.

en idd iedere zender moet wel unieke ID's verzenden...
Echter mogen er dus wel meerdere zijn.
Het mogen ook dezelfde ID's zijn maar dan idd multiplexed.

is wel ongebruikelijk en IMO ook niet gewenst...

[Bericht gewijzigd door High met Henk op woensdag 6 januari 2021 12:46:03 (32%)

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

Multiplexed messages zijn ongebruikelijk voor "live process data", maar juist wel weer heel gebruikelijk voor het uitlezen van logging, zoals EOBD foutcodes e.d.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
High met Henk

Special Member

hmm schrale troost: ging hier o.a. om het stoelcontact van een trekker.

Is hier ooit voorbij gekomen met die vraag: https://www.circuitsonline.net/forum/view/127950

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

Op 6 januari 2021 10:54:31 schreef High met Henk:
@henri:

totaal niet waar: ik ben al zoveel varianten tegengekomen:

ooit in een trekker al een bericht gezien met 4x zelfde ID die in een burst van 10 mS verschil, dan 100 ms dood TOTAAL verschillende data verstuurde..

heeft me wel even gekost om dat uit te filteren....

Dat kan makkelijk, ik heb nergens gezegd dat de data bij een specifiek CAN-ID hetzelfde moet zijn, sterker nog die is meestal anders anders had je net zo goed een leeg bericht kunnen versturen.

Wat niet mag zijn meerdere controllers die hetzelfde CAN-ID versturen en VERSCHILLENDE data (of uberhaupt data). Dan werkt de collision detection namelijk niet meer.
Een controller mag technisch wel een leeg bericht versturen met eenzelfde CAN-ID maar dat is eigenlijk "not done".

Op 6 januari 2021 02:24:05 schreef SparkyGSX:
Een RTR frame bevat geen data, maar de DLC bevat de lengte van het bericht dat je terug verwacht te krijgen.
...
Het valt me op dat het gevraagde pakket niet verstuurd wordt.

Inderdaad er komt geen response op, die messages kun je waarschijnlijk gewoon negeren.

[Bericht gewijzigd door henri62 op woensdag 6 januari 2021 14:40:38 (18%)

1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
High met Henk

Special Member

aha, verkeerde interpretatie van mij: normaal is het namelijk zo dat 1 ID een bepaalde dataset heeft die gewoon in een protocol vast ligt.

en dat is dus bij de zgn. muliplexed messages niet zo. (uiteraard is er nog wel een protocol, maar dat is in een soort van arrayed structuur)

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???

Op 6 januari 2021 14:39:04 schreef High met Henk:
en dat is dus bij de zgn. muliplexed messages niet zo. (uiteraard is er nog wel een protocol, maar dat is in een soort van arrayed structuur)

Die "multiplexed" term is ergens ooit door iemand verzonnen als kreet om een protocol aan te duiden wat er gebruikt wordt. In de CAN spec komt die kreet nergens voor zover ik me kan herinneren.

1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.

Op 6 januari 2021 14:26:06 schreef henri62:
Een controller mag technisch wel een leeg bericht versturen met eenzelfde CAN-ID maar dat is eigenlijk "not done".

Daar zijn wel een paar uitzonderingen op; het SYNC bericht (default 0x80) bij CAN-open bijvoorbeeld.

Het zou wel voor kunnen komen dat meerdere devices hetzelfde RTR frame verzenden, maar aangezien die frames dan tot het laatste bit identiek zijn is dat eigenlijk geen probleem. Sowieso worden RTR frames in mijn beleving niet heel veel gebruikt, in de automotive kom je ze zeer zelden tegen.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken