Dataöverföring via IR mellan 2 picar - Protokoll ?

[stekarn]

Hejsan!

Ska till och bygga en dataöverföring mellan 2 picar, kommunikationen skall ske med IR. Har någon tips på lämpligt protokoll man kan använda. Ska man utgå från nåt fjärrkontrollsprotokoll kanske och anpassa det till eget behov?

tips och ev informativa länkar emottages tacksamt!

mvh/Stekarn

[ensten]

RS232 är väl rätt ok om man pratar om dataöverföring du har väl sådana portar på dina PIC'ar?

EDIT> Googla så hittar du med största säkerhet allt du behöver veta. När du kommit lite längre så finns vi på forumet till din hjälp.

[Icecap]

Vilken typ av data?

Har varje byte en funktion eller ska varje information styckas ihop av fler bytes?

Hur snabbt måste det gå? Hur ofta kommer datan?

Är det olika datafunktioner eller är det bara samma funktion som ska överföras?

Dessa parametra har alla betydelse för det bästa protokoll och innan man vet svaren är det nära nog omöjligt att svara.

Edit: Ska det vara felkorrektion eller övervakning för utstörd kommunikation?

[ensten]

Ok var kanske LITE för snabb med mitt svar. *Bugar mig djupt och backar*

[bengt-re]

Ett bra tips om datamängderna är små och hastigheten inte så kritisk är att ta att i princip köra sonys RC5-kod. Med andra ord en lång startbit (>1700us) och därefter 8 bitar data. Representera en etta med 600 us och 900us för nolla eller tvärtom. Vill du ha fast längd på meddelandet så låt bitmellanrummet vara längre för korta pulsen (ger möjlighet att i mottagaren mäta både till och fråntid för ökad säkerhet, men behöver inte utnyttjas om man vill ha enklare kod för mottagningen).Val av "bit-tid" är i någno mån fritt, dock skall mottagaran hinna med att prosessa data innan nästa bit kommer. Vill du så lägger du till CRC eller paritet, men faktum är att om tar snäva gränser för vilken tid som mottagaren accepterar som startbit så brukar länken ge riktiga data så fort startbiten blir rätt. En förklaring till detta är att ir-mottagaren mättas i någon mån så det svåraste för den är att ta emot startbiten felfritt och gör den detta så blir det andra nästan alltid rätt.

För sändningen av pulserna kan du ta en ne555 som du trimmar in till 38kHz och sätter en andgrind så att du kan grinda den ifrån uP enkelt. För mottagning använd då en vanlig fjärrkontrollmottagare typ Everlight ELIRM8xxx, eller om du vill ha bättre prestanda sharp IS1U621 (dock klart dyrare).

Den andra riktiga fuskmetoden är att du kör samma koppling med 555, men om du nu kör en uP med USART låter USARTen grinda sändaren och sen koppla mottagaren till USART-ingång på mottagaren via ir-mottagarmodulen. Nackdelen med detta är att det ger fler fel, men snabbare överföring och enklare programering.

Den första metoden har jag använt vid ett flertal tillfällen och det fungerar väldigt bra, men som sagt - det blir lite mer kod och lägre hastighet. Dock så är båda lösningarna billiga och enkla att testa med. En liten varning dock - everlight modulerna är tämligen EMI-känsliga och om du har mottagare och sändare på samma kort följ råden i databladet för avstörning av matningsspänningen, då det annars lätt blir problem.

[Hedis]

Skall länken vara dubbelriktad?

[stekarn]

"Vilken typ av data?"
Det är information om en Robots körning/tillstånd ex "00:14 - Roboten backar" som först skall lagras och därefter skickas över till en annan pic efter avslutad körning.

"Har varje byte en funktion eller ska varje information styckas ihop av fler bytes?" Tror jag borde klara mig med en byte per funktion

"Hur snabbt måste det gå? Hur ofta kommer datan?"

Det borde inte vara så tidskritiskt, datan skall hämtas från någon form av lagringsminne!

"Är det olika datafunktioner eller är det bara samma funktion som ska överföras?"

Det blir väl olika datafunktioner, jag ska skicka över både tid och status

"Skall länken vara dubbelriktad?"

I den enkalste varianten skall det vara simplex!

[cyr]

Jag skulle nog testa med en variant av bengt-re's fuskmetoder.

Använd USARTen, skicka data med låg baudrate och med paritet. Skapa 38KHz bärvågen antingen med extern hårdvara (555) eller med PWM-modulen i PIC (om den finns). AND-grinda ihop USART-ut med 38KHz-signalen, och se till att polariteten blir så att IR-sändaren är av när man inte skickar data.

På mottagarsidan blir det bara en vanlig färdig IR-mottagare och USARTen.

Nu har jag inte gjort det här själv, men det är iaf vad jag skulle försöka med innan jag letade efter någon krångligare lösning...

[Icecap]

Du ska alltså skicka teststränger, är det rätt uppfattat?

Först antar jag att du såklart har IR-länken klar samt att den sitter på en UART för det var ju protokollet på hur du skickar datan du frågade efter eller hur?

Jag hade, då datan kan variera i storlek osv, helt enkelt skickat det som följer:
STX datan-som-ska-skickas ETX.

Därmed kan mottagaren nolla sin inbuffer när det kommer en STX, fylla i allt eftersom det kommer bytes och när det kommer en ETX är det ett färdigt budskap, behandla det (spara/skriva ut eller vad du vill) och ta emot nästa.

[Schnegelwerfer]

Jag gjorde lite överslagsberäkningar tidigare om vilken hastighet man kunde uppnår vid vanlig 38kHz-modulation, och kom fram till maximala dathastigheten borde bli runt 4kbit/s.

Detta förutsatte att man behöver 3 38kHz perioder av bärvåg, samt ungefär lika mycket icke-bärvåg för att modulera en bit.

Jag vet inte hur känsliga IR-mottagarmodulerna är, men jag tycker att 3 perioder av 38kHz borde vara rimligt i alla fall.

[$tiff]

Vanliga avstämda IR-mottagare har sisådär minst 0,4 ms reagenstid enligt databladet, så det blir väl 1/0,4ms = 2,5 kbps maximal överföringshastighet. Eller?

[bengt-re]

Men i verkligheten kan man gå lite under 400us i pulslängd utan problem, dock ökar felrisken självklart, men sällan någon mening med att stressa länken. Jag har brukat köra med en sändningstakt på 50 Byte/s vilket ger med resonemanget cirka 500baud, Det går att köra bra mycket fortare, men räcker denna låga takt så varför stressa länken ? Ett tips är att man låter fråntiderna inte vara för korta om man gör pulslängdsmätningsvarianten för att återigen undevika mättnadsproblemet med ir-mottagaren. En tråkig sak med 38kHz modulerna är att timingen mellan pulståget början och slut inte är så vidare väldefinerad, men pulslängden brukar bli rätt ut, därav att jag i första hand rekomenderade en pulslängsmätande koppling. En annan fördel med längdmätande koppling är att klockfel på flera procent mellan sändare och mottagare inte stör länken nämnvärt eftersom man inte får addition av tidsfel om klockorna går olika. Faktum är att man kan låta mottagaren kalibrera sig på startpulen och sen definera ettor och nollor som delar av startpulslängden. Gör man det så kan man ha 20-30% kockfel och ändå säker länk.

[Schnegelwerfer]

Vanliga avstämda IR-mottagare har sisådär minst 0,4 ms reagenstid enligt databladet, så det blir väl 1/0,4ms = 2,5 kbps maximal överföringshastighet. Eller?

Det där stämmer säkert. Jag tittade inte i databladen efter reagenstid utan gjorde bara lite antaganden.

[stekarn]

"Du ska alltså skicka teststränger, är det rätt uppfattat?"

Menar du textsträngar så är det rätt!

"Först antar jag att du såklart har IR-länken klar samt att den sitter på en UART för det var ju protokollet på hur du skickar datan du frågade efter eller hur?"

Nej har ingen hårdvara helt klar än, är fortfarande på planeringstadiet! Men det jag har minst koll på är själva prtokollet, därför undrar jag över detta!

[bengt-re]

Det kan vara intressant att koppla en ir-sändare som pulsar och utgången ifrån ir-mottagaren till andra kanalen för att skapa sig en bild av känslighet, timing och beteende när signalen är svag. Snabb labb som ger en en bra känsla för dessa rätt roliga prylar.