Olika metoder för att skicka stora datamängder (UART)

[sodjan]

Det finns väl dokumenterat vilken träffsäkerhet t.ex CRC-16 har.
T.ex : http://www.ece.unb.ca/tervo/ee4253/crc.shtml.

In essence, 100% detection is assured for all errors E(x) not an exact multiple of P(x). For a 16-bit CRC, this means:

100% detection of single-bit errors;
100% detection of all adjacent double-bit errors;
100% detection of any errors spanning up to 16-bits;
100% detection of all two-bit errors not separated by exactly 216-1 bits (this means all two bit errors in practice!);
For arbitrary multiple errors spanning more than 16 bits, at worst 1 in 216 failures, which is nonetheless over 99.995% detection rate.

[Korken]

Tack sodjan! Den sidan förklarade många frågor över hur CRC fungerar!

Icecap:
Nej det är inte livsupprätthållande utrustning det är den trådlösa överföringen på KFly.
Vad för andra val av error-detection finns? Hash kanske? Jag har ingen bra koll på detta utan tar de jag hittar och CRC va vanligt förekommande sätt.

[sodjan]

Sen så finns det ju olika sidor av det hela. CRC-kontroll handlar ju till
stor del om att verifiera att ett komplett meddelande är korrekt. Sen
så är det ju ett lite annorlunda problem om man tappar bitar helt.
Det kan fångas upp via förväntade meddelandelängder, antingen
som en fast längt eller ett längdfält i meddelandet.

Ett tredje område som ibland behöver kollas är att värderna är OK,
även om överföringen som sådan är felfri...

[Korken]

Sant så sant!

Jag kör med fast datalängd på headern och i headern så står det hur stort datapaketet är.
Så det blir två saker som håller koll så det kommer rätt mängd data.

[dangraf]

Istället för att skicka samma data flera gånger skulle du kunna titta på felrättande koder som t.ex "hamming" ( http://en.wikipedia.org/wiki/Error-correction_coding )
Det finns säkert färdig kod du skulle kunna använda för att både packa och packa upp data du vill skicka.

Vad är det för typ av fel som du får? är det hela bytes som missas eller är det enstaka bitar i bytes pga att synkningen inte stämmer? För om det är hela bytes skulle man kunna göra som man gör när man skickar radio, blandar om bitarna innan man överför. Om du har 16 bytes som skickas över och 1 byte försvinner skulle man teoretiskt kunna sprida ut bitarna så att de första 2 byten man skickar innehåller första biten från de 16 bytes man vill skicka. Nästa 2 bytes är bit nr2 från ditt data osv.. Då blir det lättare att återskapa den försvunna byten. metoden kallas interleaving (http://en.wikipedia.org/wiki/Interleaving)

[Korken]

dangraf:
Jag får inga fel än, jag vill bara ha ett bra protokoll.


Nu ska vi se...
Jag ritade upp en state-machine för överföringen. Kan ni ta en titt och se om jag har missat något eller om något är fel?

serial_state.png

[Swech]

Om du står i D och det kommer en sync innan du anser dig vara färdig, vad skall hända då?

Swech

[Korken]

Mm, såg det också nu.
Mer såhär tror jag:

EDIT:
Sync från D borde nog gå till 3an.

serial_state.png

EDIT2: Fixad.

serial_state2.png

[Korken]

Jag glömde ju att en SYNC inte får komma som kommando (för enkelhetens skull).
Då borde det bli såhär. Vad tror ni om det?

EDIT: La till CMD för mer klarhet.

serial_state.png

[vespaman]

Förmodligen har du löst det nu, men om inte..

En variant är att escapa de värden som används aktivt i lågnivå protokollet, tex ditt 'SYNC' tecken, så att det aldrig kan komma i data eller header/CRC. Nu skickar du ju över BT, och kanske har odentligt knökigt med bandbredden, men annars är 9-bit protokollet guld om man har koll på hårdvaran mellan burkarna.

Vad gäller CRC, så är det ju beroende på hur mycket processor du har i bägge ändorna, personligen har jag slutat använda CRC16 i de flesta sammanhang, eftersom det ofta inte kostar speciellt mycket mer processor med CRC32, som är många gånger bättre. Man kan tycka att CRC16 borde räcka, men jag har på ett tidigare jobb, insett att då och då så faller det igenom och missar fel.

Har du mer processor, eller/och kryptosupport i processorn, kan MD5 vara ett ännu bättre alternativ. Fast det kostar betydligt mer processor än CRC, dessutom är det 16 bytes att skicka istället för 2 alt. 4, vilket kanske är droppen för din bandbredd.

Att sända med DMA är absolut bäst, och *oftast* inte speciellt knepigt. Om man har längden först i headern, så kan man även få till rx med DMA med lite trixande. Interrupts tar som bekant snabbt död på den bäste av processorer, fast DMA är ju jobbigare att avlusa, så kanske mer intressant att hoppa på när man behöver cyklerna senare i projektet..