Hex naar dec

wat bedoel je met checksum?

dit is een berekening (hex to dec) die redelijk recht toe recht aan is.
een checksum gebruik je om de verzonden data te valideren na een transmissie (i.e. of het wel goed aangekomen is) ik lees hier niets over verzenden.

omzetten van HEX naar DEC is relatief simpel, maar elke programmeer omgeving kan dit zelf casten (sterker nog, ze rekeken intern eigenlik stiekem met bits, die ze vaak hex weergeven, omdat dit beter overzicht geeft dan dec of zelfs bin)

maar ik lijk hier excel te zien...

ben erg in de war, maar het kan ok met excel, ik zou alleen wel van vooraf beginnen (MSB) als je het in excel moet doen...

Moet het een 8 bits checksum zijn?
Er zijn vele manieren om dat te berekenen, dit is er eentje (Totaal is de opgetelde som van alles):

Checksum = ((Totaal Mod 256) Xor 255) + 1

Zal wel '2's complement' moeten zijn ipv 'two supplements'. Die laatste ken ik niet iig.

Bij een 8-bit checksum zijn het altijd de laatste 2 hex digits die tellen.

In dit geval moet je (denk ik) alle bytes bij elkaar tellen, en het resultaat aftrekken van 0. Zodat je altijd op 0x00 uitkomt als je alle bytes inclusief checksum bij elkaar optelt. En dan tellen alleen de laatste 2 hex digits. Daarmee wordt het gemakkelijk om te controleren of de checksum correct is.

zet de binaire code onder elkaar, en de waardes van de bits erboven. 8,4,2,1. als je binair een 1 ziet tel je de waarde die bovenaan staat er bij op.

@arco, wat jij doet is een 8-bits "min" operatie met de hand uitschrijven. De lol daarvan is dat als je de checksum procedure bij ontvangst door laat lopen tot en MET de checksum je dan altijd "0" krijgt (mod 256).

Een commando is geen getal (hij ziet er misschien úit als een getal, maar dan is het alleen het commandonummer. De betekenis is geen getal, en je kunt er niet mee rekenen; de betekenis is het moeten uitvoeren van die bepaalde instructie.)

Omrekenen van de ene basis naar de andere doe je al, dat lijkt geen probleem. In Excel zitten zulke functies gewoon meegeleverd.

'Een checksum' kan alles zijn, van de eenvoudigste 'parity bit' tot de wat geraffineerdere polynoomberekeningen, zoals de X25-checksum en nog andere.
Met die uitgebreidere checksums kun je niet alleen beter en meer fouten vaststellen, maar er zelfs een of meer weer corrigeren. Het zal duidelijk zijn dat je dan meer dan een enkel pariteitsbit nodig hebt.

Dus de vraag is: wélke checksum moet je maken?

kan ook een hash zijn (lijkt me hier overkill), maar ik zie niet in waarom je een checksum in wilt bouwen....

Nogmaals doe je normaal alleen als je gaat verzenden en er kans is op datacorruptie.

bij een omzetting van ene naar andere formaat is die er in mijn ogen dus niet. komt altijd hetzelfde uit. kans op fouten nul en anders zul je dat er met een checksum niet uithalen. een checksum op een algoritme is gewoon heel vreemd.

een algoritme om een checksum te maken is niet vreemd. Sterker nog:d at is heel gebruikelijk.

Het gaat hier om communicatie met een testapparaat. Deze vereist een checksum bij het zenden van commando's. Voor zover ik in de datasheet heb kunnen vinden is het niet mogelijk om deze checksum niet mee te sturen (dan doet het apparaat simpelweg niks).

Ik probeer dit in excel uit te dokteren zodat ik weet wat ik precies moet programeren in de PLC. Excel is alleen een tool hier om uit te vissen hoe het werkt.

@arco: Dit is volgensmij de formule die ik ook in excel gebruikt heb. Alles behalve de startbyte en de checksum bij elkaar optellen. Dat delen door 256 En dan de rest van die deling aftrekken van 255. Dan kom ik namelijk ook op 5 (dec) uit. Even voor het idee. De som is 1531 (dec) en de checksum zou 83 (dec) moeten zijn.

@deKees: die quote in mijn openingspost komt letterlijk zo uit de datasheet. Tijdens het nodige zoekwerk ben ik regelmatig two's complement tegen gekomen. Ze noemen telkens hoeken. Maar het lijkt er op dat supplement neerkomt op het moet samen de maximale waarde zijn (90graden voor een hoek dus) en voor een Complement moet het samen 0 zijn (180graden voor een hoek). Al kan je dit anders interpreteren als je het niet over hoeken hebt natuurlijk....

@Frederick: ik snap dat het cijfertje alleen maar een bepaald commando voorsteld voor het apparaat. Het enige wat ik heb om op af te gaan is die quote in de openingspost en wat voorbeelden in de datasheet.

@High met henk: Het gaat dus niet om de omzetting van het een naar het ander. Het gaat om het berekenen van het checksum. Dat omrekenen zit er alleen maar in zodat excel de sommen juist uitvoert. (En ik de rekensommen wat intuïtiever kan lezen).

Dit is overgens het apparaat. Voor wie zelf de datasheet wilt checken. De commando's staan vanaf pagina 5-3.
https://www.atecorp.com/atecorp/media/pdfs/data-sheets/chroma_19071-72…

Dan kom ik namelijk ook op 5 (dec) uit.

Dat klopt toch ook? Wat bedoel je met die 83?

@hmh: Het is een schoolvraag. De bedoeling is dat ze een keer een checksum hebben uitgerekend, ook al wordt er hier niet fysiek iets verstuurd.

Volgende week: je ontvangt 01 02 03 04 05 f1 klopt dat?
je ontvangt 02 03 04 05 06 ea klopt dat?

@Arco, Die 83 is de checksum die volgens de datasheet hoort bij die string. Ik neem aan dat in de voorbeelden in de datsheet de checksum klopt (bij een handvol van die korte kom ik wel uit op wat het zou moeten zijn. In dit geval is het een reactie van de tester (zie bijlage)

@rew: Het is een schoolvraag, klopt. Maar wel voor een opdracht (stage) waar we daadwerkelijk gaan comuniceren met dat apparaat.

Checksum klopt niet in het voorbeeld. Moet 0x05 zijn, niet 0x53...

Die droeftoeters vonden het nodig om weer eens wat anders te bedenken...
De eerste parameter 0xAB (header) telt niet mee voor de checksum...

Haha hm, daar had ik nog niet bij stil gestaan... De header tel ik inderdaad niet mee, het is de optelsom van alles behalve de header en (uiteraard) de checksum want die ben je aan het berekenen.

Ik probeer het morgen meteen even uit. Maar een fout in de datasheet verklaart ook waarom het bij een hand vol andere comando's wel uitkomt en bij deze niet...

In elk geval iedereen dank voor het meedenken en ik laat ht nog even weten als dit het inderdaad was!

allemaal bedankt voor de reacties!

het is gelukt!

Op 13 september 2022 17:54:53 schreef Arco:
De eerste parameter 0xAB (header) telt niet mee voor de checksum...

Er valt wat voor te zeggen: Als je de header "AB" niet hebt ontvangen, dan ga je ook niet zoeken naar een packet. Je weet dus dat als je een pakket aan het verwerken bent dat dat ding correct aanwezig is.