Svenska ElektronikForumet

Jag har i ett projekt använt ett protokoll där 64 tecken valdes ut för data av de 256 möjliga, så att 6 bitar källdata skickas per tecken. Det ger då 4 skickade tecken per 3 byte källdata. Det skulle ju också gå att göra med 7 bitar per tecken så kommer man upp i 8 tecken per 7 byte källdata. I vårt fall, där det faktiskt också var telemetridata, blev det väldigt enkelt med 6 bitar per tecken då vår AD-omvandlare hade 12 bitar. Så det går ju komma undan betydligt bättre än 4 bitar per tecken (hex). Starttecken och andra saker kan ju då använda de tecken som inte används för data. Jag körde med ASCII '0' till 'o' (64 st) för data, '#' för start och linefeed för slut. Det blir något i stilen:
En annan möjlighet som någon väl nämnde här tidigare är att använda någon form av "escaping", där du väljer ut ett eller flera styrtecken och sedan ser till att det finns styrteckensekvenser som motsvarar att styrtecknet hade varit med i källdatan. Ett exempel på det är hur backslash i stränglitteraler i C fungerar. Exempelvis "C:\\FOO\\BAR.TXT" som det blir om styrtecknet i sig finns med i källdatan eller "12\tkakor\t34 kr\n" där styrtecknet används för att ge andra kommandon. Ett exempel på ett enkelt protokoll skulle ju då kunna vara att \ i källdata översätts till \\ i sändningen och att t.ex. \$ används som startsekvens för meddelande.

Man får väl bara se upp så att styrtecknet man väljer inte förekommer för ofta i källdatan, för då kommer man ju upp i 50% utnyttjande i värsta fall om källdatan bara består av styrtecknet. Att välja 0x00 eller 0xFF kan vara dåliga idéer t.ex. om man skall skicka binärdata.

Korken: det finns ett sätt (minns ej namnet) där man reserverar ett tecken/bytevärde som specialtecken. Här kallar jag det X för att det ska vara enkelt att skriva.

Starttecken är då t.ex. X 0x01 (alltså två bytes)
För att sända just byten X sändar man X X (eller X 0x02 eller annat)
Man kan ha en End-block markering med t.ex X 0x03 eller liknande.

Detta betyder att man får 100% extra data om man bara sändar X medan man bara får ett extra tecken per block som inte innehåller X.

I essens får man alltså ytterligare 255 extra "tecken" att jobba med medan man fortfarande kan ha en hyffsat hastighet...

Oh de va bra idéer ni gav mig! Tackar!
Specialtecken tror jag kommer fungera bättre i mitt fall, men jag ska testa båda tror jag.
Det kan vara mycket bra att kunna för framtida bruk!

sodjan:
Självklart!
Jag är en girig person som vill ha mer än vad som är möjligt!

Jag har bara skummat igenom tråden lite övergripande men mitt förslag är att du lägger till en kort header med fast längd i varje datapaket. Denna header innehåller antal byte i data, kommandokod och en 8-bitars checksumma eller möjligen några bitar färre. I slutet på datat hänger du på en 16-bit checksumma.

Just nu så kör jag med en 16-bit checksum efter allt. Finns det någon anledning att pilla in en extra efter headern?
Eller kan man inte lita på 16-bits checksumen för någon anledning?

Du måste veta att headern är korrekt annars kan du inte lita på att variabeln data-lenght eller cmd är korrekt.

Om man har Start-Block och End-Block samt checksum är det inte nödvändigt med data över antal tecken.

Labmaster: Borde inte det synas i 16-bit checksumen? För är headern fel så blir ju checksumen också fel.

Om du alltid har samma längd på meddelandet kanske du klarar dig med CRC på hela bocket men har du variabel längd så blir det problem. Dessutom behöver du inte bearbeta hela blocket om det redan är fel i headern. Jag har byggt en hel del applikationer på detta tema och vet genom erfarenhet vad som fungerar bra och mindre bra men du gör naturligtvis som du själv tycker är bäst.

En sak som slog mig som jag inte riktigt vet jag ska söka på är: Hur många bytes kan jag koda in i en viss storlek av CRC innan det inte är unikt längre?
Ja menar, kan jag tex koda 250 bytes i en CRC-16?
Vad ska man söka på för att hitta sannolikheten att två olika meddelanden får samma CRC?

Frågan är ju ett par stycken:
* Vad ska hända om det är fel CRC?
* Finns det tid / plats till omsändning?
* Eller ska hela paketet bara kastas?
* Hur viktiga är de data?
Besvara dessa frågor och jag tror att det hela blir ganska klart då.

- Är det fel CRC så kastas paketet. Vill sändaren få till baka en OK-kod men inte får det så skickas paketet om.
- Hur viktigt datat är är olika med olika paket.

Jag vill mer eller mindre bara ha en tumregel på hur mycket data jag vågar trycka in i en CRC.

CRC16 är på 16 bit och i teorin kan den bara vara unik vid 16 databit eller hur? Alltså är det lika effektivt att skicka alla bytes 2 gångar, först en "normal och sedan en inverterat eller hur?

Men sedan är det frågan för vilken sannolikhet för identisk kod du kan acceptera och då är datamängden nog beroende på vilket sannolikhetsnivå du accepterar.

Jag har lärt mig att i GSM skickas det ju datapaket och mer än hälften i varje paket är felkorrigeringsdata (CRC om du vill)...

Så det är så det ligger till.
Då börjar man fundera på hur stora paket man vågar ha. Hur brukar ni göra?
Jag funderade först på att köra 256byte men det känns lite väl mycket för en 16bit-CRC.

"Vågar"? Är det livsuppehållande utrustning det rör sig om?

Du får avväga om det ens är värd att använda CRC och om det är: hur stor risk som är OK att ta om CRC behövs.