Checksum bepalen RC communicatie

[4lloyd]

Laatst kwam ik op zolder een oude RC auto van Lego tegen en ik wil daarvan het protocol uitzoeken. De bijbehorende zender heb ik nog, maar die is onbetrouwbaar. Hierdoor wil ik zelf een zender maken. Het probleem waar ik nog tegenaan loop is uitvinden hoe de checksum gemaakt wordt.

Even wat achtergrond. De zender heeft 3 standen voor: links, rechts, vooruit en achteruit. Daarnaast zit er nog een schuifknop op om kanaal 1, 2 of 3 te kiezen. Tot slot zitten op de achterkant twee knoppen die ingedrukt kunnen worden.

Samen met een scope heb ik al veel informatie kunnen verzamelen. De zender stuurt een AM signaal waarop de commando's gemoduleerd worden. De draaggolf is 27,145 MHz. Een "bit" in een commando duurt tussen de 16 en 40 ms en de tijd tussen bits is altijd 16 ms. Alle tijden zijn een veelvoud van 8 ms.

Een voorbeeld van een commando (F3-L3, zie tabel hieronder) op de scope:


Een groot aantal uitgelezen commando's heb ik uitgewerkt in een spreadsheet, die staat: hier in Onedrive. Hieronder een stukje daaruit:

Speed	Steer	Preamble	Channel		Button	Steer + direction			Speed		Checksum
F3	L3	48	16	24	16	24	40	40	40	40	16	16
F3	L2	48	16	24	16	24	24	24	40	40	24	32
F3	L1	48	16	24	16	16	24	40	40	40	24	40
F3	M	48	16	24	16	32	24	24	40	40	24	40
F3	R1	48	16	24	16	32	24	40	40	40	32	24
F3	R2	48	16	24	16	40	24	24	40	40	32	16
F3	R3	48	16	24	16	40	40	40	40	40	16	32

De eerste twee kolommen geven het commando aan dat ik geef met de knoppen. Daarachter staan de tijden van een "bit" uit het commando. De tijden tussen "bits" zijn weggelaten in de tabel.

Zoals te zien in de tabel is de betekenis van alle waardes in het commando bekend voor mij. Het enige dat nog niet lukt is zelf de checksum berekenen. Ik heb verschillende dingen geprobeerd zoals: kijken of ik een patroon kan herkennen, de waardes omzetten naar 4-bits reeksen of bytes, XOR en dat soort dingen, CRC RevEng en de som van waardes, maar niets heeft mij tot nu toe tot de oplossing gebracht. De waardes simpelweg overnemen is altijd een optie, maar dan zijn niet alle commando's mogelijk, dus dat heeft niet mijn voorkeur.

Is er misschien iemand die meer ervaring met dit soort checksums heeft en mij in de goede richting van een oplossing kan helpen?

[memphis]

Is het niet gewoon een PPM en dan opgesplitst naar PWM sturing? Dat is vrij normaal bij een 27MHz AM RC....

Ben even aan het zoeken geweest: https://www.philohome.com...wer_Functions_RC_v120.pdf

[CodeCaster]

Tevens TVP vanaf de ontbijttafel, maar het zijn twee bits per waarde denk ik? De relevante data is:

16 ms = 00
24 ms = 01
32 ms = 10
40 ms = 11

Volgens mij kun je daar weer verder mee XOR'en.

[naarden 4ever]

Ik denk inderdaad dat je eerst even de tabel moet omschrijven naar bits om hier wijzer van te worden. Wat @CodeCaster opmerkt, klopt aardig denk ik. Zo zie ik bijvoorbeeld:

BB1 en BB2 niet ingedrukt: Button == 16 (00)
BB1 is ingedrukt: Button == 24 (01)
BB2 is ingedrukt: Button == 32 (10)

Ik denk dat als je BB1 en BB2 tegelijk indrukt, dat Button == 40 (11), indien dat mogelijk is.

Ook denk ik dat het eerste bitje van Steer + direction in jouw tabel een signedness is. Getallen waarbij het eerste bitje hoog is, moeten vaak geïnterpreteerd worden als een negatief getal. Linkssturende bewegingen geven altijd 24 of 16 als eerste getal. Dat betekent dat het eerste bitje altijd uit staat (24 = 01, 16 = 00), oftewel een positieve stuurhoek. Bij rechtssturende of rechtdoorgaande beweging is het eerste bitje juist altijd aan (32 = 10, 40 = 11), dus een negatieve stuurhoek.

Hetzelfde geldt voor het laatste bitje van Steer + direction. Bij vooruitgaande beweging is het laatste bitje altijd hoog (40 = 11, 24 = 01), bij stilstand of achteruitgaande beweging is het bitje juist altijd laag (32 = 10, 16 = 00).

Voor je uiteindelijke programmeerwerk bij het maken van een eigen zender gaat het je waarschijnlijk heel veel kopzorgen schelen als je van ieder bitje weet wat het daadwerkelijk voorstelt. En misschien doemt er dan wel een patroon op. Dus schrijf je tabel om door elke 16 te vervangen met 00, 24 met 01, 32 met 10 en 40 met 11.
(Een makkelijke manier om dit te doen: Trek van alle cellen 16 af en deel de waarde door 8, dan krijg je een waarde van 0 tot 3, en dan met de functie DEC2BIN kan je daar een binaire uitvoer van maken)


Dan, wat betreft de checksum:
Ten eerste: op basis van welke informatie weet je trouwens dat de laatste bitjes bij een checksum moeten horen? Ik denk wel dat je gelijk hebt, maar ben wel benieuwd hoe je dat zo zeker weet.

Waar ik als eerste naar ben gaan kijken, is of er mij iets opvalt bij de commando's waarbij de checksum gelijk is. Dat is bijvoorbeeld het geval bij B3-L1 en B3-M. Enige verschil tussen beide commando's is de plaats van een 32 en een 16 (of beter gezegd: een 10 en een 00). Dus verwisselen van die twee bitsets zorgt niet voor een andere checksum.

Het valt mij daarna op dat sowieso bij alle ##-M en ##-L1 commando's de checksum gelijk blijft. Maar bij F2-M en F2-L1 bestaat Steer+direction uit 16-24-40, en bij F2-M bestaat deze uit 32-24-24. Lijkt (vooral met deze notatie) toeval, maar eenmaal in bits geschreven (00-01-11 resp. 10-01-01) dat er wel degelijk een overeenkomst is, namelijk het aantal enen is gelijk in beide commando's. Ook belangrijk op te merken: het zijn in beide sets twee 'tweede' eentjes (dus de het tweede getal van de set bits), en één 'eerste' eentje. Als ik dan vervolgens zoek naar een ander commando met dezelfde checksum, bijvoorbeeld B1-R2, valt mij gelijk op dat Steer+direction hier bestaat uit 40-24-16, oftewel 11-01-00. Wederom hetzelfde verhaal.

Maar vanaf daar loop ik nu ook even vast, en is mijn pauze weer voorbij. Misschien dat ik vanavond nog zin heb om even verder te puzzelen.

[ Voor 36% gewijzigd door naarden 4ever op 06-02-2025 14:31 ]

[Springuin]

Ik denk dat het een lagere bitrate is en Wikipedia: Differential Manchester encoding : een 0 is een steady state, een 1 een wisseling halverwege (of andersom)
Met dat in gedachten zou jouw scope beeld uitkomen op:


Edit: Maar als ik er nog eens verder naar kijk denk ik dat jouw spreadsheet met de bits een betere versie is. Ik heb even zitten spelen met xor's maar kom er zo snel niet uit. Echter, nu je alle combinaties hebt hoef je de checksum niet meer uit te rekenen, toch?

[ Voor 24% gewijzigd door Springuin op 06-02-2025 15:21 ]

[4lloyd]

Bedankt allemaal voor de reacties! Het helpt mij echt om de informatie beter te begrijpen of bepaalde concepten uit te kunnen sluiten .

memphis schreef op donderdag 6 februari 2025 @ 09:02:
Is het niet gewoon een PPM en dan opgesplitst naar PWM sturing? Dat is vrij normaal bij een 27MHz AM RC....

Ben even aan het zoeken geweest: https://www.philohome.com...wer_Functions_RC_v120.pdf

Ik heb mij even verdiept in hoe PPM werkt. Qua signaal lijkt het er wel iets weg van te hebben, maar ik zie nog niet helemaal hoe het alle standen kan verklaren. Daarnaast weet ik dat de snelheid en richting knoppen stappen schakelaars zijn in plaats van bijvoorbeeld potmeters. Daardoor verwacht ik een meer "puur" digitale aansturing.

CodeCaster schreef op donderdag 6 februari 2025 @ 09:05:
Tevens TVP vanaf de ontbijttafel, maar het zijn twee bits per waarde denk ik? De relevante data is:

16 ms = 00
24 ms = 01
32 ms = 10
40 ms = 11

Volgens mij kun je daar weer verder mee XOR'en.

Ik had al gespeeld met het idee, maar ik kreeg de informatie niet echt duidelijk. Maar samen met de reactie van @naarden 4ever zie ik wel dat het de beste kans heeft.

naarden 4ever schreef op donderdag 6 februari 2025 @ 13:35:
Dan, wat betreft de checksum:
Ten eerste: op basis van welke informatie weet je trouwens dat de laatste bitjes bij een checksum moeten horen? Ik denk wel dat je gelijk hebt, maar ben wel benieuwd hoe je dat zo zeker weet.

Als ik eerlijk ben, weet ik dat niet zeker. Het is vooral hoe de data veranderd dat ik verwacht dat het iets van een checksum moet zijn. Als namelijk ervoor maar een van de waardes veranderd, dan zie ik dat gelijk terug in (wat ik verwacht) de checksum. Daarnaast, kijkend naar de binaire waardes, rekent het ook mooi. Want dan kunnen de 2 bits van een waarde, gecombineerd worden tot 4 bits en dan krijg je 4 keer 4 bits aan informatie en 1 keer 4 bits aan checksum. Oftewel, misschien rekent de processor met 4 bits.

Want ik denk inderdaad dat kijken naar de binaire waardes de beste weg tot nu toe is. Ik heb ze toegevoegd aan de spreadsheet. In eerste instantie had ik er al (te) kort naar gekeken, maar met jouw uitleg zie ik wel duidelijk een betekenis in de waardes. Daardoor heb ik nu het protocol wel duidelijker. Ik ga nu uit van het volgende:

	Channel	Button	Left/right	Steer level	Forward/backward	Speed level	Checksum
bits	4	2	1	4	1	4	4

De betekenis daarvan is voor mij nu het volgende:
Channel
0001 = Channel 1
0011 = Channel 2
0101 = Channel 3

Button
01 = Button 1
10 = Button 2

Left/right
0 = Left
1 = Right

Steer level
0010 (000) = Level 0
0011 (001) = Level 1
1010 (100) = Level 2
1111 (111) = Level 3

Forward/backward
0 = Backward
1 = Forward

Speed level
0001 (000) = Level 0
0101 (010) = Level 1
1001 (100) = Level 2
1111 (111) = Level 3

Daarnaast valt het mij op dat bit 4, 10 en 16 altijd 1 zijn. Bij een aantal heb ik de waardes tussen haakjes erachter gezet zonder de vaste waarde.

Springuin schreef op donderdag 6 februari 2025 @ 14:56:
Ik denk dat het een lagere bitrate is en Wikipedia: Differential Manchester encoding : een 0 is een steady state, een 1 een wisseling halverwege (of andersom)
Met dat in gedachten zou jouw scope beeld uitkomen op:
[Afbeelding]

Edit: Maar als ik er nog eens verder naar kijk denk ik dat jouw spreadsheet met de bits een betere versie is. Ik heb even zitten spelen met xor's maar kom er zo snel niet uit. Echter, nu je alle combinaties hebt hoef je de checksum niet meer uit te rekenen, toch?

Differential Manchester encoding is ook een interessante manier om naar de data te kijken en was inderdaad een goede mogelijke optie. Qua combinaties heb ze helaas nog niet allemaal. O.a. de combinaties met de knoppen aan de achterkant en de verschillende kanalen mis ik nog. In basis zijn het inderdaad genoeg om mee te kunnen rijden, dus als ik er echt niet uitkom, dan moet ik het er maar mee doen.

Voor nu ga ik kijken of ik met setjes van 4 bits verder kom om de checksum te bepalen. Mocht iemand daarin nog iets opvallends zien, dan hoor ik dat uiteraard graag .

[memphis]

4lloyd schreef op donderdag 6 februari 2025 @ 16:54:
Bedankt allemaal voor de reacties! Het helpt mij echt om de informatie beter te begrijpen of bepaalde concepten uit te kunnen sluiten .


[...]


Ik heb mij even verdiept in hoe PPM werkt. Qua signaal lijkt het er wel iets weg van te hebben, maar ik zie nog niet helemaal hoe het alle standen kan verklaren. Daarnaast weet ik dat de snelheid en richting knoppen stappen schakelaars zijn in plaats van bijvoorbeeld potmeters. Daardoor verwacht ik een meer "puur" digitale aansturing.

Bij normale PPM heb je een serieschakeling van de aantal kanalen PWM signalen.
Iedere puls kan in breedte van 1ms tot 2ms variëren met 1.5ms als middenstand. Na de serie aan pulsen is er een tijdje niets dat als detectie wordt gebruikt dat er een nieuwe string aan pulsen aan komt. Bij normale RC is de pulsbreedte geheel analoog, bij een RC dat alleen kanalen schakelt zal de pulsbreedte 2 standen kennen. Dus mogelijk kent iedere puls in jouw geval inderdaad 4 standen of 2 schakelkanalen.

[Springuin]

Ik heb even zitten rekenen of de bits in het checksum een lineaire relatie hebben met de data bits, maar die lijkt er niet te zijn. Het is dus niet een simpele checksum, eerder een CRC.

Wel lijkt het zo te zijn dat je sommige bits kunt uitwisselen en blijft het checksum hetzelfde: bijvoorbeeld bits 7 en 11, bit 3 en 8, bit 5 en 13, bit 2 en 14, bit 6 en 14.
Ik heb ook dit gevonden van Lego: https://www.philohome.com...wer_Functions_RC_v120.pdf en daar wordt een LRC gebruikt per 4 bits, maar dat past niet bij jouw data.

[memphis]

Moet het een checksum hebben? Dit is een vrij simpele communicatie met een continue stroom van frames. Wordt ergens iets verkeerd gelezen zal een volgende frame dat wel herstellen

[naarden 4ever]

Ik heb nog even verder gepuzzeld.

Ten eerste heb ik jouw tabel een beetje anders opgezet, door de functies van de bits in de kolommen te categoriseren in plaats van setjes van 2 bits. Dit maakt het mijn inziens makkelijker om de bits aan de functie die het heeft te koppelen, en te controleren of patronen consistent zijn. Zie onderstaande link:

https://1drv.ms/x/c/2409c...43rLwWJJZ0IeoebQ?e=Mc1biI

Van enkele bits weet ik niet 100% zeker wat de functie is, maar heb ik wel een aanname gedaan. Deze staan bovenin beschreven met een vraagteken.

Tijdens dit werkje denk ik dat ik op een aantal fouten gestuit ben, dus mijn vraag of je die zou willen controleren of dat inderdaad verkeerd genoteerde waarden zijn of dat ze wel kloppen in de tabel en mijn aanname juist is. De potentiële fouten zijn:

• F2 C2 M: Ik denk dat de 'checksum' van deze waarde 3 is (0011), niet 2 (0010)
• S C1/2/3 R1/2/3: Ik denk dat de stuurwaarden hier niet kloppen, en respectievelijk 3, 10 en 15 moeten zijn, consistent met de stuurwaardes uit de andere regels met stuurhoeken R1/2/3..
• Regel 63 en 64 in jouw tabel Beschrijven S C2 R4 en R5, maar ik denk dat dat een typfout is, en R3 moet zijn bij deze twee regels.

Ik hoor graag of deze aannames al dan niet juist zijn!

De waarde voor de stuurhoek vind ik vreemd, en bovendien valt mij op dat bit 2 altijd hoog is bij L3 of R3 (maximale uitslag stuurhoek), en bit 3 altijd 1 is. Ik vermoed daarom dat bits 1 en 4 samen de stuurhoekwaarde voorstellen, want als je bit 1 en 4 achter elkaar zet krijg je waarde 00 voor de middenste stand, 01 bij L1/R1, 10 bij L2/R2 en 11 bij L3/R3. Het is een beetje vreemde formattering, maar wel consistent. Bit 3 is denk ik ook weer een filler bit, of een gereserveerde bit, en bit 2 zal dan inderdaad aangeven of dit de maximale stuurhoek is.

Er wordt ook iets meer duidelijk over de checksum. We zien dat de afstand tussen de waarden in de eerste kolommen ook consistent zijn:

• L3: 0
• L2: +6
• L1: +7
• M: +7
• R1: +9
• R2: +8
• R3: +2

Bovendien zie je bij het setje F2 L3-R3 dat als het getal 16 is bereikt, de waarde terugvalt naar 0, en dan opnieuw begint. F2 L3 begint met een checksum met waarde 10, de checksum van F2 L1 zou dus 10+7 = 17 (10001) moeten zijn, maar dat past niet in 4 bits, dus is de waarde 1 (0001). Vergeet dus niet dat een +9 ook een -7 kan zijn, dat heeft dezelfde uitkomst.
(voorbeeld: 8 + 9 = 17 (10001), eerste bit valt weg, dus wordt 1 (0001). 8 - 7 = 1 (0001) )

Ik denk toch dat het een vrij eenvoudige functie is, want vooral de voorbeelden met het wisselen van de kanalen laat zien dat +1 kanaal een +2 in de checksum geeft. BB1 zorgt voor een verandering van de checksum met +4, BB2 met +8. Dat is consistent met de positie van de bit in de reeks, want als je bits 5-8 als één hexadecimaal getal beschouwd, zorgt het hoog zetten van BB2 met het hoog zetten van de eerste bit in die reeks die een waarde van 8 representeert.

Mocht ik nog verder komen, laat ik het weten!

[naarden 4ever]

Ik heb de code gekraakt.

Het is niet een hele moeilijke berekening. Hij staat erbij in bovenstaand document, kolommen AD-AK.

Je maakt van de bits 4 setjes van 4, dus bit 1-4 vormen samen één hexadecimale waarde van 0-F, bit 5-8 vormen er een, enzovoorts. Zo krijg je 4 hexadecimale getallen (elk met een decimale waarde van 0-15). Vervolgens neem je de som van deze waardes, modulo 16 (dus de rest van een gehele deling met 16).

Voorbeeld: F3 L1:
BIN: 0001 - 0000 - 0111 - 1111
HEX: 0x107F
DEC: 1 - 0 - 7 - 15

1 + 0 + 7 + 15 = 23
23 % 16 = 7
Checksum = 7 (0111)

[4lloyd]

Enorm bedankt @naarden 4ever voor de moeite die je hierin gestopt hebt, de uitleg die je gegeven hebt en het vinden van de juiste oplossing. Jouw hulp heeft dit project echt in een stroomversnelling gebracht!

Uiteraard de rest ook bedankt voor de input die jullie gegeven hebben.

Hieronder zal ik nog even ingaan op de vragen die je had gesteld, zodat we het verhaal compleet kunnen maken.

naarden 4ever schreef op vrijdag 7 februari 2025 @ 10:32:
De potentiële fouten zijn:

• F2 C2 M: Ik denk dat de 'checksum' van deze waarde 3 is (0011), niet 2 (0010)
• S C1/2/3 R1/2/3: Ik denk dat de stuurwaarden hier niet kloppen, en respectievelijk 3, 10 en 15 moeten zijn, consistent met de stuurwaardes uit de andere regels met stuurhoeken R1/2/3..
• Regel 63 en 64 in jouw tabel Beschrijven S C2 R4 en R5, maar ik denk dat dat een typfout is, en R3 moet zijn bij deze twee regels.

• F2 C2 M: Klopt, 0011 hoort de checksum te zijn.
• S C1/2/3 R1/2/3: Ik denk dat ik een fout heb gemaakt met het automatisch doorvoeren in Excel. Alle waardes (S C1/2/3) zijn voor alleen R1.
• Regel 63 en 64: Zelfde als hierboven, dat is inderdaad mijn fout.

En tot slot nog de laatste "missende" checksum in de tabel:

• B2 R3: Hierbij heb ik de checksum verkeerd uitgelezen van de scope. De goede waarde is: 1011.

Met deze wijzigingen kloppen alle checksums in de tabel.

[Springuin]

Mooi werk @naarden 4ever! Ik heb daar ook mee zitten puzzelen, maar het klopte te vaak niet en toen heb ik het idee aan de kant gezet.

[naarden 4ever]

Heel graag gedaan @4lloyd ! Was een leuk puzzeltje om in mijn pauzes even naar te kunnen staren.

Ik heb in het Excel-bestand je laatste verbeteringen ook nog even doorgevoerd. Nu kloppen alle checksums, behalve die van S-M. Had dat signaal wel een checksum?

Ik ben heel benieuwd of het je uiteindelijk lukt om een zelfgebouwde zender voor dit setje te kunnen maken. Als je nieuws hebt, laat het graag weten!

[4lloyd]

naarden 4ever schreef op donderdag 13 februari 2025 @ 09:04:
Ik heb in het Excel-bestand je laatste verbeteringen ook nog even doorgevoerd. Nu kloppen alle checksums, behalve die van S-M. Had dat signaal wel een checksum?

Nee, dat signaal heeft geen checksum. Dat komt omdat het niet bestaat. In die positie staat namelijk de auto stil en het stuur in het midden, dus de afstandbediening stuurt dan niets uit. Aan het einde van de tabel staat wel een "END" signaal. Die wordt kort verstuurd net nadat de besturing op nul staat. Dat signaal zou het beste passen op de plek S-M en komt qua bitjes overeen.

Ik heb ondertussen al wat testen gedaan en ik kan in basis de auto besturen met een microcontroller. Nu moet de gain nog een beetje omhoog, zodat de auto verder kan dan een meter. Als ik zover ben, dan zal ik hier een update posten met het resultaat!