Sida 3 av 9

Postat: 21 juni 2006, 22:25:32
av Wise
Du ska inte försöka koda av preamblen, den är endast till för att väcka upp och få upp treesholden på mottagaren till rätt DC nivå. Manchesterkodar du så har du lika många nollor som ettor i dataströmmen du skickar i luften. alltså 50% duty cycle kan man säga. Detta gör att du får störst amplitudskillnad mellan 1'a (hög) och DCmedelnivån och 0'a och DCmedelnivån. Man kan säga att du får högst kännslighet. Ok. För att få upp denna DC nivå till hälften av "effekten" så skickar sändaren preamblen, balanserat. Skickas 0x55 (0b01010101) ett par gånger som preamble så vaknar mottagaren till liv ur allt brus och lägger sig på rätt DC nivå. Men mottagarens UART kan omöjligt skillja på brus som förvirrar mottagaren eller korrekt data. Därför måste du skicka en syncbyte direkt efter preamblen. Denna syncbyte består av enbart ettor (0xFF). Eftersom startbiten är en nolla, och stoppbiten är en etta, så gör denna syncbyte att bitströmmen blir xxxxx0111111111SSDDDDDD. (x= skräp från preamblen, 0=startbit på sync, 11111111=syncbyte, SS=Start/stoppbyte, D=databyte). Mottagarens UART får in 9 stycken ettor på rad, just detta gör att den syncar upp och nästa nolla som kommer vet man är startbiten på den "riktiga datat". (mottagarens UART kan ju inte veta exakt p åvilken bit i preamblen som är startbit etc). SS är en startbyte(eller gärna flera). Så det enda mottagaren ska göra är att lyssna på den unika startmeningen, när den får träff, då vet man att datat kommer efteråt. Naturligvis kan denna startmening slumpmässigt genereras ur bruset i omgivningen, så det kan vara bra att ha en rätt lång startmening...Optimalt är att startmeningen är viktad till lika många ettor och nollor också för att behålla mottagarens DC nivå. Allt detta står från kapitell 4 och framåt i länken annars med bilder också.

Ovan antaget att UART'arna kör med logisk etta vid 0V. (som RS232 ex)

Långt inlägg blev det, men hoppas du fick inblick i hur manchester och överföringen går till. Som ovan har jag kört med billiga RF moduler likande från Kjell med rätt bra resultat. 100-150m fri sikt med enkelt antennspröt tror jag inte är några problem.

Postat: 22 juni 2006, 00:10:58
av chille
Grattis Wise, jag har precis än en gång fått höra en förklaring som styrker min teori om att jag lika gärna kan koda av preamble. För det kommer ju INTE påverka hur datan kodas av. Och att skicka flera byte preamble verkar ju bara jobbigt. Totalt är det 29 bitar som skickas. Av dom 29 bitarna är det 4 nollor i början som alltid är identiska.

Om du vill kan du ju ta en titt på de här två bilderna och försöka klura ut vad det blir. Som du ser är det inte ett ton onödigt preamble och sånt skit. Dessutom verkar det bara overkill då mottagaren verkar ha en stabil nivå redan vid första biten som tas emot.
System 1 Channel 1 On
System 1 Channel 1 Off

Postat: 22 juni 2006, 08:15:06
av Croaton
chille:

Jag har försökt att få igång Nexa systemet hemma, men utan framgång.
Du (eller någon annan) kanske kan reda ut ett par frågetecken åt mig?

1. Du skrev att datat skickas med LSB först och visade följande beskrivning:

Kod: Markera allt

    Hus  ID  Styr    Hus  ID   Styr
    A     1  On      0000 0000 0111 (00000000 00000000 00010101 0)
    A     1  Off     0000 0000 0110 (00000000 00000000 00010100 0)
    B     3  On      1000 0100 0111 (01000000 00010000 00010101 0)
    C    13  On      0100 0011 0111 (00010000 00000101 00010101 0)
Om jag har fattat dig rätt så innebär detta att bittarna skickas med den vänstra biten i ditt excempel först och sedan går man åt höger så att säga.
(Jag blev lite konfunderad när du verkar ha skrivit omvänt)

2. Sändaren jag hittade i källaren är identisk med Kjells 6 pinnars variant, det framgår dock inte om denna kör med ASK modulering, vilket det gör på 4 pin varianten. Någon som vet om den bör fungera?

3. Du skriver 700 baud, menar du då att varje bit är 1.427 ms lång (1/700)? Dsv att alla 25 bittar tar 35.7 ms att skicka.

Vore tacksam för lite svar, för jag vill verkligen få detta att fungera :wink:

(Om man ändå hade ett oscilloskope hemma så att man kunde kolla signalen... )

/Croaton

Postat: 22 juni 2006, 08:16:36
av oJsan
chille: Var är signalen i de två bilderna uppmätt? Direkt på utgången på en custom RF-mottagare, eller efter den köpta mottagarens mottagardel? Det ser då inte ut som att den innehåller någon preamble tycker jag.
En kompis höll på med nått liknande projekt och la då märke till att alla kommandon skickas tre gånger. Kanske är det så att upprepad sändning får samma funktion som preamble/sync? Har du kollat hur många gånger signalen sänds? (Det kan ju vara, ett i sammanhanget, rätt stort mellanrum mellan de tre signalerna, vilket gör dem svåra att se på ocsilloskopet...)

Postat: 22 juni 2006, 08:55:00
av vfr
Croaton> Det stämmer. Dom skickas från vänster till höger så som chille skrivit dom. Tittar man på dom så är dom då omvända mot den adress resp. id som han skrivit.

Postat: 22 juni 2006, 14:04:51
av mel
oJsan skrev:Många verkar vara intresserade, inklusive mig... kanske vore det en idé att starta någon sida på nätet för en DIY serieportssändare?!
Den här gjorde jag för ett tag sedan:

http://www.mellander.org/per/projects/?project=nexa

Postat: 22 juni 2006, 14:20:07
av chille
Croaton:
Jag skulle precis springa iväg och mäta upp pulstiderna. Men nu såg jag att mel postade en länk med en beskrivning av protokollet. Tiderna 320µS och 960µS låter väldigt bekant. Fast jag tror inte det är så noga att de är exakt.

Kan även tilläggas att bitarna jag skrev inom parantes är exakt det som ska skickas, från vänster till höger. Det jag menar med att LSB skickas först är att till exempel så blir 3 0100 istället för 0010.

oJsan:
De två bilderna är uppmäta på en cusom-motagare. Jag tror inte att de skickas flera gånger, för det borde jag lagt märke till. Men jag ska ställa om timebase och dubbelkolla. Och jag har fortfarande svårt att tro att man skulle behöva skicka preamble/sync i denna applikation, eftersom det verkar funka bra utan. Och även nexa kör rakt på med datan, fasst de har kommit på ett MYCKET bättre sätt att skicka på än någon fjantig manchesterkodning :)

mel:
Kanske dags att fixa en ny uppdaterad sida?

Postat: 22 juni 2006, 16:16:12
av micke.prag
Om någon är intresserad så har jag portat Mellanders drivrutin till 2.6.x-kärnan.

Postat: 22 juni 2006, 16:24:41
av chille
Är det inte lite overkill att skriva en helt egen drivrutin för detta?

Postat: 22 juni 2006, 19:54:23
av mel
Varför skulle det vara overkill? Har du en bättre lösning?

Postat: 22 juni 2006, 22:09:15
av Croaton
Success! Nexa-Croaton, 0-1 victory is mine! :D

Jag var helt ute och cycklade med mitt första försök, men efter att ha läst beskrivningen på mellanders sida så lyckades jag på första försöket!

Tacka alla för informationen!

Nu är det bara att knåpa ihop en RS232 -> Nexa interface, blir dock med ATtiny2313 och en sändarmodul i stället för mellanders specialare. (btw: Jag kör mot rustas billiga Proove moduler och inte nexa systemet)

mel: Jag har en "bättre" lösning (se ovan). dvs RS232 -> Nexa = Inget special.

/Croaton

Postat: 22 juni 2006, 22:22:18
av mel
Kul att det funkar - det är det som är huvudsaken :D

Postat: 22 juni 2006, 23:23:44
av Croaton
mel: Kunde inte ha sagt det bättre själv :)

Postat: 23 juni 2006, 07:16:46
av oJsan
Yiha! Kul att det gick att lösa problemet, något som säkert många funderat på! Frågan är bara vad kodningsprincipen kallas, om den ens är känd.. eller om det är något som Nexa har hittat på för att ge oss huvudbry! ;) Påminner lite om manchesterkodningen (ger dom radioegenskaparna)...

Postat: 23 juni 2006, 15:17:51
av chille
Kodningsprincipen känd? Jo det kan man ju säga, den används på flera ställen. Jag förstår inte varför manchester skulle ha fördelar mot den här. Manchester är ju jobbig att koda av då man måste hålla sync hela tiden, viket kan vara knepigt. Att koda av datan från Nexa (med flera) är ju så enkelt som att man triggar på stigande flank, sätter en timer på 400µS och sen när timern går så läser den av. Hur enkelt som helst ju 8) Och DC-balanserat blir det ju också, då man alltid har 50% duty cycle.

Angående drivrutinen: Jo jag tyckte det först verkade overkill att dels ha en drivrutin och sedan bli tvungen att ha ett program för att styra skiten. Då hade man ju lika gärna kunnat baka in styrkoden direkt i programmet. Men sen slog det mig att man inte kan bitbanga serieporten genom att bara skriva till /dev/xxx