Hur är detta möjligt?

[Pjoms]

Jag knycker rubriken rakt av från en annan tråd, då jag inte kan komma på något bättre...
Nåväl, här handlar det om "slumpen":

Jag håller på och pysslar med trådlös överföring av lite mätdata mm med slaktade trådlösa ringklockor som Tx/Rx enheter. Så långt från "hightec" man kan komma med andra ord, med bl.a. mängder med skräp, eller brus om man så vill, ur mottagaren som följd.
Den dubbelriktade kommunikationen mellan olika enheter fungerar i alla fall, och allt borde vara "frid & fröjd" - men...

Jag har lagt upp det så att jag skickar ett "Sync-tecken", i detta fallet 'S', som mottagaren ligger och lyssnar efter. Efter detta "sync-tecken" skickar jag 19 bytes manchester-kodad data, dvs 38 byte. Sista byten av dom 19 är en CRC på hela klabbet. Allt skickas som 1200 8-N-1.

Och nu till själva rubriken:
Jag har ett par gånger fått in brus som trasslat sig igenom allt detta!!!

* Sync-tecken
* 19 bytes manchester-kodad data
* CRC:n
* och allt detta i 1200 8-N-1

Hur i hela fridens dagar är det ens möjligt??? Det borde vara lättare att vinna 100 miljoner på lotto!?!?
Nu hände inget i alla fall, då en av de 19 byten är adress till vilken enhet som anropet är till, samt en annan byte som talar om vilket kommando som skall utföras, men ändå! På det här viset borde alla trådlösa ringklockor, termometrar, garageöppnare mm "få fnatt" nå'n gång i mellanåt.
Jag är helt förbluffad!

[gurgalof]

Jadu... Ibland har man otur.

[Icecap]

Det finns en anledning till att de trådlösa ringklockor ska ha ett antal giltiga koder innan de reagerar.....

Hur räknar du ut din CRC? Om det är en simpel summering kan det mycket väl vara för enkelt.

Kom dock ihåg att bruset kör kontinuerligt och att det alltså konstant "testar" olika kombinationer.

Det finns en anledning till att det säljs dyrare radiomoduler........

[oJsan]

Inom hur lång mätperiod har det hänt att bruset ibland trasslat sig igenom?
1200bit/s (vid 8N1) ger 120byte/s vilket blir ungefär 10 miljoner byte skräp per dygn.

Hur genereras checksumman? Jag antar att olika (giltiga) datapaket kan generera samma checksumma?
Kan det vara en mjukvarubugg/tankevurpa vid mottagarkontrollen?

Edit: Förtydligade...

[Pjoms]

> "Hur räknar du ut din CRC? "
Jag använder samma 8-bitars CRC-beräkning som "Dallas OneWire" kör med.


> "Kom dock ihåg att bruset kör kontinuerligt och att det alltså konstant "testar" olika kombinationer."
Självklart är det så. Det är en prima slumpgenerator, men ändå...


> "Jag antar att olika (giltiga) datapaket kan generera samma checksumma? Kan det vara en mjukvarubugg/tankevurpa vid mottagarkontrollen?"
Ja, samma checksumma kan genereras på olika datapaket, och visst, allt är möjligt, men jag ser inget direkt (just nu) som skulle tyda på löss i programmet.


> "Inom hur lång mätperiod har det hänt att bruset ibland trasslat sig igenom?"
Igår hände det fyra gånger på ett par timmar.


> "Det finns en anledning till att det säljs dyrare radiomoduler........ "
Absolut, detta har till viss del överväkts, men dom faktorer som blev avgörande i detta fall:

* Jag lär mig en massa på vägen - Ger nya kunskaper
* Jag hade några ringklockor liggandes - Billigt (i kronor & ören, men inte i tid...)
* Jag kan även använda Tx-modulen till att styra NEXA/PROOVE trådlösa strömbrytare - Smidigt
* "Det går att göra!" - En inte helt ovesäntlig faktor...



Jag får rätt ofta "CRC-fel" när mottagaren bara står och lyssnar efter Sync-tecknet, vilket jag inte tycker är så märkligt. Det räcker ju med att den byten trillar in rätt så kommer ju dom resterande 38 sannorlikt också att fyllas med skräp. Men då säger som sagt CRC:n ifrån.

Jag fick vid ett tillfälle i början CRC-fel på alla paket jag tog emot, men då hade jag klantat mig och råkade skriva i en byte *innan* jag kontrollräknade CRC:n...
Efter att ha fixat det blev CRC:n ok. Jag ser det som att CRC-rutinen funkar.

[vfr]

En 8-bits CRC är inte mycket på en linje med mycket störningar, även om den är bättre än vanlig 8-bitars checksumma med summering eller XOR. Prova och gör en CRC16 istället så får du upp säkerheten väsentligt.

[Icecap]

Ett alternativ kan ju vara att skicka CRC-8 + en inverterat CRC-8, det borde få bort minst hälften av falska meddelanden men självklart är CRC-16 bättre.

[Pjoms]

Hmm... Jag får nog överväga en 16-bitars CRC.
Då jag bl.a. har OneWire givare i projektet var det så enkelt att använda samma rutin för "RF-CRC:n" också.

> "även om den är bättre än vanlig 8-bitars checksumma med summering eller XOR."
Menar du om man bara kör XOR på varje byte efter varandra? Dallas OneWire kör ju med nå'n XOR också, men där skiftars ju bitarna runt.
Jag har inte satt mig in så noga hur det funkar igentligen, då jag hittat en färdig rutin för det.

Jag har för övrigt en 16-bitars rutin också, så det är väl bara att stoppa in & köra. Det tar ju dock lite mer minne om man måste ha två CRC-rutiiner.

[Andax]

Tycker inte det är så konstigt att data slipper igenom en CRC-8 kontroll.

Oavsett meddelandelängd genereras ju en kontrollsiffra med 256 olika värden som kan antas.

Så en störning som dyker in i meddelandet gör ju att det beräknade CRC-8 värdet blir ett slumptal mellan 0-255. Sannolikheten att det matchar den skickade CNC-8 kontrollsumman är ju 1/256.

Säg att det kommer in ett slumpmässigt fel i 10% av dina meddelande och du skickat 10000 meddelanden över några timmar. Då kommer 0.10*10000=1000 meddelanden vara felaktiga. Eftersom i snitt 1 per 256 meddelande kommer ha matchande CRC-8 kommer alltså ca 4 stycken av dessa 10000 meddelande slinka igenom trots att de är felaktiga.

Kör du med CRC-16 får du en lösning med en faktor 256 sannolikhet att ett felaktigt meddelande slinker igenom.

[oJsan]

För att du ska få in ett skräp-paket så krävs följande. Ett 'S' slumpas fram ur bruset, mottagaren triggar och samlar in 38 byte med brus. Sannolikheten för att nästa byte är rätt checksumma är sedan 1/512 (startbit måste ju också finnas med, därav 2^9).
Eftersom sannolikheten för ett 'S' också är 1/512 så borde sannolikheten för skräppaket vara 1/262144. (ett per halvtimme ungefär...?)
Jag vet inte hur smart din UART är, men den borde kunna sortera bort en del bitfel, varpå sannolikheten minskar en del.
Bättre checksumma behövs alltså. Ett mycket okomplicerat och kodsnålt alternativ är att sända dubbelt, dvs 'S' och sedan de 38 byten två gånger direkt efter varandra och sedan kolla om byte[n] och byte[n+38] matchar vid mottagning.
Sändningstiden kommer att öka från ~300ms till ~600ms för ett paket, kommer det att göra någon större skillnad i ditt system?

[Pjoms]

> "Ett mycket okomplicerat och kodsnålt alternativ är att sända dubbelt ... kommer det att göra någon större skillnad i ditt system?"
Nej, jag kommer inte att behöva sända så ofta att det ska påverka. Jag sänder redan nu datapaketet fem gånger efter varandra för att minska risken för bortfall.

Varje "försändelse" (5xdatapaket) har en byte med löpande serienummer. Detta serienummer kör jag XOR på mot CRC-byten för att skapa ett "unikt" ID på försändelsen.
På så sätt kan jag hålla isär omskick / ny data, och borde utan större möda kunna läsa in och jämföra två datapaket.

Kanske kan man dessutom fila lite på CRC-rutinen så att den tar både 8 och 16 bitar? Ska nog titta lite på det...

[xxargs]

Jag kan säga att det du håller på med är något som flera borde hålla på med i microkontroller-världen - Vid utvecklingen är det nästan alltid korta sträckor och 'perfekt' överföringsmedium, sedan när det körs ut över större ytor i kanske industrimiljö, så kommer alla problemen...

---

Ett minimumkrav tycker jag i allafall är att kommunikationen alltid skall kunna ske över en liten isolertransformator per riktning - dvs. ingen 'DC-nivå' som är gemensam för båda ändarna. Det betyder att en UART-ingång från säg en RS485-buffer kan stå och brusa vid ingen data på linan. Man kanske måste ha en synksekvens för att starta upp det hela, felhantering. Plocka ut giltiga sekvenser ur en brusström etc. etc. utan att MCU:n i något läge hänger sig (något som tydligen inte gäller många RS232-USB-konvertrar...)

mao den situationen du slåss med nu!

Till detta bör du skapa en scrambling-paket så att '1' '0' densiteten är ungefär lika över tiden oavsett data du skickar (bl.a för att ev isolertrafo-kärna inte skall gå i DC-mättnad och börja dista signalen vid långa 000000000100000000000100000000010000-sekvenser) - detta gör nästan alla länkprotokoll inklusive Ethernet just för att man skall kunna använda billiga små isolertrafos som galvaniska barriärer.

Dra lärdom av det här - gör ett litet kommunikations-subrutinspaket av det här och använd detta i dina framtida projekt så fort det är risk för 'ej perfekta kommunikationslänkar' eller krav på galvanisk isolering mellan enheterna - vilket nästan alltid gäller så fort det är en vägg mellan enheterna och olika jord och skyddsjord-referenser om det är nätanslutet.

[Pjoms]

> "Till detta bör du skapa en scrambling-paket så att '1' '0' densiteten är ungefär lika över tiden oavsett data du skickar... "
Det är ju just detta som manchester-kodningen gör. En "etta" skickas som '10' och en "nolla skickas som '01'.
I detta fallet för att hålla DC-nivån i sändaren.

[$tiff]

>> Pjoms

Ha inte för höga förhoppningar. Jag har gjort ett arbete med nRF2401-chip i ungefär dessa moduler. De har integrerad beräkning för adress och 16-bits CRC (valbar), men ändå slipper brus genom denna kontroll. Alltså, först gissa rätt på 16 bit CRC och sedan rätt (8-bits) adress. Brus är lurigt!

[xxargs]

> "Till detta bör du skapa en scrambling-paket så att '1' '0' densiteten är ungefär lika över tiden oavsett data du skickar... "
Det är ju just detta som manchester-kodningen gör. En "etta" skickas som '10' och en "nolla skickas som '01'.
I detta fallet för att hålla DC-nivån i sändaren.

du har rätt - scramblingen görs för att få till spreadspektrum så att man inte fastnar i en EMC-godkännanden - gjorde man inte sådant så skulle tex. Gigabit Ethernet fastna på att den sände ut 31.5 MHz bärvåg alldeles för starkt...