tv-fjärr, ir-protokoll och nogrannhet!!

[StRob]

StRob, RLL .. eller kanske ev byte-run är en slags komprimering i farten så att säga. Då slipper man lagra en lång sträng av säg "0"-or. Istället skickar man "sänd 250 st 0-or", osv. Visa tekniker tillåter "sänd 225 st 00110-sekvenser".
Fördelen är att man det kräver mindre av länken mellan MCU och styrdator. Samt att det beroende på timing går att använda mindre minne.

Eftersom frekvens ej är specad. Så kan vi utgå från mitt tidigare exempel med 12,5 instruktioner per IR-cykel. Och då bör man inse att det krävs assembler för att det ska ha en chans att fungera.

Jo, jag är helt med på innebörden och vad man kan tjäna i att packa datan, men det jag ser inte hur det blir smidigare/snabbare i detta fall. Måste vara något jag missar?

På tal om demodulering: Problemet är ju inte att demodulera, det överlägset enklaste alternativet jag ser är att använda en färdig IRmodul då denna har filter och AGC (auto gain control) inbyggd. skulle man använda enklare IRdetektor krävs det separat annars blir den väldigt störkänslig för solljus och övrig belysning. (Jag har sett andra projekt och avståndet på vilket fjärren fungerar blir lidande). Problemet är att dessa HAR just demodulator inbyggd. Och vi vill ju inte demodulera (ta bort bärvågen). Där kommer processorn in i bilden och MODULERAR om signalen. (Och hur byte-run hjälper här ser jag inte riktigt?) UART-varianten har jag funderat på, men det blir mest bökigt tycker jag. Då måste man räkna ut hur många tecken, t.ex ASCII "U", som ska skickas och det blir ju endast hela multiplar av det. Krångligt att klippa mitt i antar jag.

EDIT: Är det så här ni menar att byte-run-metoden skulle fungera?: Man skulle alltså spara datan från IR-modulen först och SEN återskapa den istället för att låta signalen från IRmodulen t.ex. tillåta PWM-avbrott eller togglingen direkt? Det ser jag inte som en smidig lösning, men det kanske är något jag inte ser?
En fördel vore iofs att man kan återskapa den hur många ggr man vill. (en knapptryckning på fjärrkontrollen består av flera repetitioner av en datasträng (pulståg) så det kan finnas fall där detta kan vara bra faktiskt. Om den ligger i sleep vid batteridrift och den vaknar och bara får med en av repetitionerna) Men då krävs mer kod för att detektera start och slutet i varje datasträng.

[blueint]

Fördelen med bitkompression är att man kan jobba direkt med den råa bitströmmen och därmed kan använda godtyckliga frekvenser, modulering, koder osv.. utan att använda kopiösa överföringshastigheter eller minnesstorlekar. Och detta på ett generaliserat sätt.

[StRob]

men det faller väl ändå på att vi redan har en demodulerad sigal? Hade vi inte haft det så visst, då kunde vi använda olika frekvenser (för jag antar att det är modulationsfrekvensen du avser?). Men då hade det väl ändå varit klart redan?? bara koppla den modulerade signalen till en förstärkare och ut direkt på IR-dioden utan att blanda in någon µC?

Men nu har vi ju en modulerad signal och då vet vi att det är runt 38 kHz ioma mottagaren detekterat den. (Inbyggt filter)

MEn har ni någon bra ide på hur man gör en IRmottagare som klarar ett större frekvensområde och fler protokoll och ändå klarar att behålla räckvidd och godtagbar immunitet mot störande belysning så är jag klart nyfiken.

Har jag fortfarande inte förstått vad du menar?

[jesse]

>bara koppla den modulerade signalen till en förstärkare och ut direkt på IR-dioden utan att blanda in någon µC?

men tanken var väl att den skulle minnas signalen och skicka ut den senare!

[StRob]

Var det så han menade? jag fattade det som att han ville göra en IR-repeater, som jag själv gör.
Då är det väldigt tydligt helt plötsligt!

Men jag är fortfarande nyfiken på om någon har ett bra tips på en fungerande design, som inte innefattar massa dyra komponenter, som fixar en IR-mottagare som är mer generell och klarar fler frekvenser än bara 38 kHz-protokollen.

EDIT: läste om förta inlägget och visst var det så! JAg fastnade för IR-repeatern och glömde den delen. Aja, det blev ju väldigt tydligt och det var säkert matnyttiga saker som kom fram iaf.

[blueint]

StRob, Vilka är dom dyra komponenterna?

Hur man konstruerar en generell IR hanterare är egentligen inte konstigare är samplat ljud. Den stora skillnaden är att det går mycket fortare men är å andra sidan bara en bit "bred".
Processorn bör ha en arbetsfrekvens som överstiger den samplade signalen med marginal. Samt klara eventuell bearbetning ("DSP") av data i realtid.
En 20 MHz AVR MCU borde klara det galant. Då det är hög frekvens och 1 instruktion per klockcykel. Sen får man avväga vad som ska göras i MCUn samt vad som görs via länk på mer kapabla enheter.
Är det t.ex. ett multidrop nätverk är det kanske olämpligt med realtidsdata den vägen osv..

Synpunkter på detta vore intressant.

[StRob]

En koplett mottagare med AGC, filter och (tyvärr) demodulator kostar 6 kr på ELFA. Dessa ingående komponenter är enligt min mening (och många andras om man tittar på andras projekt) viktiga. Och att göra en AGC och ett filter av motsvarande grad kommer kosta mer än 6 kr är min gissning. Men om någon redan gjort en bra mottagare som har bra räckvidd så vore det ju intressant att kika på!

IR är lättare ioma det är faktiskt bara dubbla frekvensen gentemot ljud och som du säger så är det ju bara en frekvens som är av intresse. JAg är väl medveten om samplingsteoremet (> dubbla frekvensen) och visst, det går att använda DSP att programmera riktigt fina filter, men knappast med en PIC på 4 MHz intern klocka.

[blueint]

Min tanke var aldrig en riktig DSP bara principen..
Hantering av modulation "on-the-fly" samt kodning osv.
Kanske någon simpel 1-bits anti alias.

[StRob]

Jo, jag förstod att du menade att använda AVR:en som en enkel DSP och det går nog väldigt fint med 20MHz klocka. Men i mitt fall så försöker jag få till det i en batteriapplikation och då är strömförbrukningen kritisk och därför vill jag försöka använda den inbyggda 4/8 MHz klockan, och i sleep kanske tom 128 kHz klockan. Största problemet jag har är att hitta en strömsnål IR-mottagare som fortfarande har godtagbar prestanda.

[blueint]

Du kan förmodligen köra avsevärt långsammare än 20 MHz. Allt beror på hur mycket databearbetning du vill ha.

[StRob]

Med risk för att glida ifrån trådskaparens ursprungliga frågor, men fortfarande inom ämnet/rubriken så utvecklar jag det något:

Eftersom jag ska driva IR-repeatern från batteri så kräver det att jag inte har mottagaren aktiv hela tiden (om jag nu använder en färdig IR-modul som tidigare beskrivits) utan µC behöver:
-Räkna lite tid och köra ett par if-satser för att jämföra räknaren osv.
-Vakna och kolla efter IR.
-Sampla och spara meddelandet, lämpligtvis med tidigare nämnda algoritm.
-Skicka ut 38 kHz enligt sparat bitmönster.

Som jag ser det vore det bäst om man kunde detektera startpulsen i meddelandet och således endast spara EN av upprepningarna i meddelandet. (Ex: Sonys protokoll upprepar samma slinga var 20-30 ms när man trycker på en knapp på fjärren. Där meddelandet ser ut enligt: 1: Pausetid mellan upprepningarna 20-30ms. 2: Startpuls 2,4ms 3: 12 st databitar där en "etta" representeras av 1,2ms och en "nolla" 0,6ms. Alla tider, utom pausetiden, representerar den låga delen av pulsen. Den höga är alltid 0,3ms.)

Är det någon som vet hur generellt Sonys protokoll är? finns det någon gemensam nämnare som t.ex att startpulsen alltid är minst Xms eller liknande? (Annars blir man väl tvungen att spara allt som kommer in utan att bry sig om sådant?)