PPM signaal hoe zit het nou echt?

Er valt hier geen argumentatie te weerleggen. In een 2,4 GHz FASST systeem werken Robbe multiswitches niet. Dat is nu eenmaal zo en al argumenterend kan ik het niet voor elkaar krijgen om ze wél werkend te krijgen. De reden moet zijn, dat er tussen het coderen in de zender en het decoderen in de ontvanger bewerkingen plaatsvinden, waardoor de sequentie wordt verstoord. Welke logica daar achter steekt, weet ik niet, maar dat had ik al geschreven. Ik probeerde alleen een indicatie te geven, wat er aan de hand kan zijn.

Waar haal je overigens het idee vandaan, dat er in een 2,4 GHz een ppm-volgorde is? Je gaat toch in een zender geen ppm-signaal omzetten in een digitale code om dit door de ontvanger dan weer in een ppm-signaal te laten omzetten? Dát zou namelijk volkomen onlogisch zijn omdat daarvoor ook geen enkele reden is. Het zelfde geldt voor een pcm-systeem. Daar ga je toch in de ontvanger ook niet eerst een pulstrein genereren om die vervolgens te verdelen over de uitgangen?
 
Wat hezik denk ik bedoeld is dat een ppm signaal wat via een 2.4ghz moduul wordt verstuurd dezelfde kanaal output zou moeten hebben op de ontvanger als bij een 35Mhz moduul. Bij 2.4 zit hier een hoop tussen dus dat kan de boel verstoren. Als elk frame dat binnenkomt op het zend moduul 1 puls op een kanaal oplevert zou dat moeten werken.

Wat ik vermoed is dat de ontvanger een vaste update frequentie heeft van de servo pulsen en dat de interne kanaal data steeds wordt bijgewerkt door de ontvanger data aangeleverd door de pwm frames. Dit is ook zo want als er even geen ontvangst is worden de servo's nog gelijk aangestuurd uit de laatse ontvangen data.

Als de ontvanger dus meer of minder pulsen naar de servo's stuurt dan dat hij als update van de pwm data binnen krijgt dan loopt het niet synchroon. Er kan een update worden overgeslagen of dubbel worden verzonden naar de servo. Hierdoor klopt je crc niet (of decodering van het kanaal of wat dan ook) en krijgt het moduul geen geldige data.

Dit kan je uiteraard voorkomen maar dan krijg je minder data over het kanaal en dus minder opties. Uiteraard zijn de bestaande modules daar niet op voorbereid en deze werken dus niet.
 
Volgens mij is één van de belangrijkste redenen het feit dat er op de 2,4GHz band veel meer verstoring is dan wij allemaal denken. Er zijn vele zenders tegelijk in de lucht en niet alleen van de modelbouw. Ook zenders van andere oorsprong kunnen tot op verrassend grote afstand nog storingen veroorzaken. Het hele ontvangst systeem zit echter zo in elkaar dat wij er niets van merken.
Een 2,4GHz zender zendt geen constant signaal uit zoals bij de "ouderwetse" frequenties wel gebruikelijk is. De 2,4GHz systemen zenden hun signaal in hele korte bursts uit. Die bursts worden een X aantal keren per seconde verstuurd, hoeveel weet ik niet en is ook niet echt van belang.
Elke burst bevat een bepaald aantal bitjes (een blok) die verstuurd moeten worden. Of dat elke keer alles is of dat het in delen gaat weet ik ook niet en is ook van weinig belang. Het gaat erom dat het hele systeem een één richting verkeer syteem is. De zender zendt een blok gegevens uit en gaat er van uit dat de ontvanger dat ook goed binnen krijgt. Het volgende blok bevat de volgende gegevens of het volgende deel van de gegevens.
Wanneer de ontvanger een blok niet goed ontvangt dan zal hij met de gegevens niets (kunnen) doen en als het volgende blok het tweede deel bevat zal hij ook met dat blok niets kunnen doen. De processor negeert die gegevens dan ook gewoon en wacht op het volgende wel goed ontvangen blok gegevens. Zo kan het dus heel makkelijk gebeuren dat een deel van de gegevens verdwijnt. De ontvanger "vraagt" dus ook niet aan de zender of het gemiste blok nog een keer verzonden kan worden want het is een één richting systeem. Bij bijvoorbeeld WiFi, dat ook via de 2,4GHz band gaat, gebeurt dat wel. Daar mag geen data verloren gaan anders kan je niets oversturen. Zijn er veel verstoringen dan wordt de verbinding akelig traag want vele blokken moeten meerdere keren verstuurd worden voordat het goed binnen is gekomen. Dit is bij de modelbesturing onmogelijk want dan wordt het hele systeem veel en veel te traag om er een model mee te kunnen besturen.

Een multiswitch heeft bijvoorbeeld 8 blokken nodig om alle gegevens van de schakelaars te versturen. De decoder MOET al die gegevens in de juiste volgorde binnen krijgen anders klopt er niets meer van de schakelaarstanden. Maar nu valt er één of misschien wel meer blokken uit omdat die niet goed ontvangen worden. Weg volgorde dus ook weg goede werking van de multiswitch. Bedenk je wel dat dit wegvallen van gegevens HEEL VAAK gebeurt. Van alle blokken die een zender per seconde uitzendt wordt misschien wel 30% vervormt of geheel niet ontvangen. Voor de gewone kanalen is dat geen probleem maar juist door die vaste volgorde die noodzakelijk is voor de multiswitch gaan die dingen daardoor de mist in.

Een andere punt is dat de zender ook regelmatig controle signalen (mee) stuurt. Dit zijn allerhande gegevens die nodig zijn om het systeem goed te laten werken. Ook die blokken kunnen de volgorde in het honderd sturen waardoor de zaak niet meer kan werken.

Er is dus een hele goede oorzaak te bedenken waarom dit niet kan werken en daarvoor hoef je dus niet eens zo ver te zoeken maar je alleen een beetje verder te verdiepen in de werking van de multyswitches en van de 2,4GHz systemen.
 
Het kan gewoon niet wat je zegt, Ernst. Als dat de reden zou zijn, zou men het ook in de besturing merken. Dan zouden er ook stuursignalen wegvallen.

De enige geldige reden die ik zie, is dat het mogelijk is dat een blok wat aan zenderkant 1 keer gegenereerd is (bv. puls 1 voor kanaal 1) aan ontvangerkant meerdere keren gereproduceerd wordt, en daardoor de schakelmodule de tel kwijtraakt.

De hele andere handel, bursts, controlesignalen, etc, hebben er niets mee te maken. Die zijn er al weer uitgehaald voordat het eindsignaal de ontvanger uitkomt.

Vergelijk het met de simpele opstelling van 4 personen. Persoon A zegt in het Nederlands tegen persoon B, B zegt het in het chinees tegen C, C weer in het Nederlands tegen D. Dat er dan chinees gebruikt wordt tussentijds doet er niets toe.

Welk mechanisme gebruiken de modulen om elkaar te laten weten dat ze bij kanaal 1 beginnen? Ik bedoel; ergens zal daar toch een synchronisatie tussen moeten zitten.. doen ze bv. 2 pulsen het kanaal op een bepaalde stand en gebruiken ze dat als 'marker' ofzo?
 
Laatst bewerkt door een moderator:
Hezik, je WILT het gewoon niet begrijpen volgens mij. Ga je nu eerst eens verdiepen in de werking van deze zaken. Het is mij duidelijk dat je die werking nog niet echt door hebt want je haalt er zaken bij die niet meespelen en je doet andere zaken af met "die hebben geen effect want...." terwijl die juist een heel belangrijke rol spelen.
 
Ernst, als iemand het niet met je eens is, wil niet zeggen dat hij niet weet hoe het werkt.

Je hebt voor jezelf bepaald dat het niet werkt en waarom het volgens jou niet werkt en hebt nu oogkleppen op.

Ik haal er geen dingen bij die niet meespelen, dat doe jij. De feitelijke signaaloverdracht doet er helemaal geen zier toe, of ze nou wel of niet retransmitten, of er controlesignalen meegestuurd worden, enzovoort, allemaal totaal niet relevant.

jij WILT niet begrijpen wat ik bedoel.

Ik zal het nog 1 keer uitleggen wat ik bedoel. Het ging mij in het voorbeeld specifiek om een 'ombouw-systeem' , daarom zei ik ook hybride, dus een bestaande 35 Mhz zender die omgebouwd wordt naar 2.4Ghz.

Dat gebeurd vaak door in de zender het PPM signaal te pakken en daar vervolgens iets mee te doen zodat het over 2.4 verstuurd kan worden. Hoe en wat, is totaal niet relevant. Feit is dat er aan ontvangerkant op dat kanaal weer een puls moet komen te staan.

Input is dus PPM en output ook. Waarom werkt het dan niet? Dat kan niet komen door het al dan niet kwijtraken van zaken of de manier van verzenden, immers dan zouden andere kanalen daar ook last van hebben.. dan zou bv. die snaproll die ik stuur door kortstondig mijn sticks in de hoek te gooien, soms ook overgeslagen kunnen worden.

Goed dan, Jan geeft aan dat er voor zo'n schakelmodule vaak gewerkt wordt met sequenties. Dat wil zeggen, de 1e puls is kanaal 1, de 2e kanaal 2, enz.

DAAR kan een reden voor storing inzitten. Niet zozeer het feit dat er pulsen niet overkomen, dat geloof ik domweg niet, maar wel in de timing van die pulsen. Zo kan het bv. zijn dat aan ontvangerkant elke puls bv. 2 keer voorbij komt, dan krijg je dus 2 maal de puls voor het 1e kanaal, 2 maal voor het 2e kanaal, enzovoort. Dat geeft Jan ook aan, dat deed het PCM1024 systeem kennelijk.

Mijn vraag is daarbij heel relevant. Ik ga er vanuit dat alle pulsen wel degelijk overkomen. Dan is het van belang te weten hoe de modules aan elkaar kenbaar maken waar ze zich bevinden in de pulsvolgorde, te vergelijken met de startpuls in een origineel PPM signaal.

De reden dat ik dat vraag.. zodra je dat kunt opvangen met een PICje, is het ook mogelijk om aan ontvangerkant weer de juiste sequentie eruit te filteren.
 
Laatst bewerkt door een moderator:
Wat mij dan zoiezo al verbaast als het zo zou zijn dat blokken dubbel worden uitgezonden of wegvallen.

Waarom werkt de multiswitch van claus poltermann wel?

het princiepe van een multiswitch blijft hetzelfde. echter mogelijk dat de uitvoering wat anders is.
 
Het is niet vaak zo maar ik ben het deze keer compleet met hezik eens :)

Zoals hezik en ik al zeiden: De frame rate en servo puls rate verschillen en daardoor kloppen de signalen niet meer.

Voorbeeldje:

Bij normale zend techniek krijg je deze signalen als frames : 255 0 50 0 80 (kanaal 8 bv in 8 bits uitgedrukt). De ontvanger krijgt frame voor frame binnen en zal na elk frame een puls naar de servo gooien. Als servo signaal zie je op kanaal 8 dus 255 0 50 0 80. Als je dit digitaal bekijkt kan je hier een fout controle op doen.

Bij PCM / 2.4g of welke digitale overdracht gaat dit anders. Theorie is gelijk. De ontvanger geeft elke 50ms een servo pult met de laatste bekende juiste waarde voor kanaal 8. De frames komen net iets langzamer. Je krijgt dan op kanaal 8 bv 255 0 50 50 0 80 Je ziet 2 keer 50 omdat het 4e frame er nog niet is geweest en de ontvanger al wel weer een puls voor de servo gaat aanmaken. Hij gebruikt dan laatst bekende waarde en dat is dus 50. Daarna komt frame 4 wel en krijg je de 0 maar dat zie het moduul dan als 5e frame. Dit is het probleem want de synchronisatie is weg en het moduul ziet het niet meer als correcte data.
 
dan ziet niet alleen de multiswitch hem niet als correct signaal maar ook de servos en de regelaars.

Als dit gebeurt zoals jij het omschrijft.

frame 4 is nog niet geweest maar en komt te laat. dan zou de servo het signaal krijgen dat niet op kanaal 4 hoort, maar op kanaal 5. en alles door mekaar heen gaan.

enigste dat ik kan bedenken is dat de robbe modules geen checksignal gebruiken echter lijkt me dit ook weer stug.

ik denk dat er iemand die beschikking heeft over een logic analyzer eens aan het meten zou moeten gaan.
 
Nee, een servo doet geen crc check op een serie van pulsen. Een servo bekijkt elke puls apart. Als je niet stuurt is het altijd dezeflde. Het maakt de servo dus niets uit of er nu pulsen wegvallen of extra tussen zitten.

Probleem met de decoder is dat hij niet per puls kijkt maar een paar opvolgende pulsen bekijkt als 1 commando / set van data. Als daar dus enkele wegvallen of bij komen klopt het totaal niet meer.
 
dan zou je dus pulsen missen op hetzelfde kanaal.

Mijn ervaring is naarmate een servo pulsen mist dat die kracht verliest. En dat lijkt mij toch zeer ongewenst bij een moderne zender. Je koopt geen dure 2.4ghz set met dure sterke servos om minder efficient te zijn met je kracht?
 
Ik denk ook niet dat er pulsen missen. Ik denk eerder dat er pulsen teveel zijn.

Los daarvan.. denk even na over wat er gebeurd, het is geen continu proces, het is een batch-proces. Alles gaat in stappen.

Dus bv.. k = kanaal van multiswitch .. aan zenderkant is voor het eerste kanaal de volgorde als volgt:

k1, k2, k3, k4, k5, k6, k7, k8

dan kan het aan ontvangerkant dit worden:

k1, k1, k1, k2 k2, k3, k4, k4, k5, k5, k5, k6, k6, k7, k8,k8

en daar loopt dan de schakelmodule op vast omdat die van een afzonderlijke puls niet kan zien dat die puls niet bij dat specifieke module-kanaal hoort.. die pakt gewoon 8 pulsen en gaat er vanuit dat dat z'n 8 kanalen zijn.

Met een PIC-je zou dit goed op te lossen zijn.. die kan de hele trein aan pulsen analyseren en zo plaatsen wat waar hoort.. mits er dus wel een synchronisatie-puls is, zodat de PIC wel de frameborders kan detecteren.
 
Laatst bewerkt door een moderator:
Stel de zender zendt een blok data uit dat ALLE kanalen in één keer bevat. Dat is onwaarschijnlijk maar het zou kunnen.
Dan bevat zo’n blok bijvoorbeeld de volgende data:

Header met zender ID en dergelijke.
Data van kanaal 1
Data van kanaal 2
Data van kanaal 3
Data van kanaal 4
Data van kanaal 5
Data van kanaal 6
Data van kanaal 7
Data van kanaal 8
Controle data (bijvoorbeeld voor kanaal keuze)
Checksum data.

Dit blok wordt bijvoorbeel 2 keer achter elkaar uitgezonden MAAR zoals reeds gezegd is dat nog geen garantie voor een goede ontvangst.
Krijgt de ontvanger de data wel twee keer goed binnen dan zal de processor dat herkennen aan de header data of de controle data. Het enige effect is dat de processor nu dubbele zekerheid heeft over de juistheid van de data. De processor zal echter de data NIET twee keer achterelkaar naar de servo’s sturen want die blijven met een pulsfrequentie van om en na bij de 50 Herz werken. Dus ook al krijgt de ontvanger het 3 of misschien wel 4 keer zo snel binnen wat naar de servo’s gaat blijft 50Hz!!!!

Ok terug naar de zender. Kanalen 7 en 8 worden gebruikt voor het over zenden van de multiswitch data. De multiswitch werkt synchroon met de pulsgenerator in de zender en is compleet onafhankelijk van de zendmodule.
Op een bepaald moment begint de coder met een nieuwe reeks. Hij krijgt een puls van de pulsgenerator en gaat dan aan het werk. Als eerste zet hij een start code op de kanalen 7 en 8. Daarmee verteld hij de decoder dat een nieuwe reeks is begonnen.
Bij de start van de volgende pulstrein krijgt de coder weer een puls. De positie van de eerste schakelaar(s) wordt verwerkt in de kanalen 7 en 8 welke daarna verstuurd worden.
Bij de start van de volgende pulstrein krijgt de coder weer een puls en hij zal de positie van de volgende schakelaar(s) in de twee kanalen stoppen. Zo zal de coder een aantal pulstreinen nodig hebben om de posities van alle schakelaars via die twee kanalen over te sturen. Dit kan bijvoorbeeld 7 pulstreinen zijn om alle schakelaar posities over te sturen.

De decoder krijgt bij het begin een startcode van de coder en zal naar de begin positie toe gaan. Hij krijgt van de ontvanger een aantal pulsjes via de kanalen 7 en 8 en omdat hij een startpuls heeft gehad weet hij dat die posities voor de eerste schakelaar(s) zijn. Bij de volgende pulsjes zijn het de posities voor de volgende schakelaar(s) die binnen komen. Zo gaat het verder tot alle posities ontvangen zijn. Dit gaat echter verspreidt over 7 datablokken.

Maar dan komt het probleem. Tijdens de verzending valt er 1 van die 7 blokken tussenuit. Dat blok wordt niet goed ontvangen en dus genegeerd door de processor. Voor de overige kanalen is dat geen ramp want de processor blijft gewoon de juiste stand van de vorige keer doorsturen. Voor de multiswitch is dat wel een ramp want hij krijgt een keer niet de juiste gegevens binnen. De processor stuurt twee keer dezelfde data naar de uitgangen omdat er een blok dat verloren is gegaan. Nu is de volgorde zoek en de multiswitch zal niet goed meer werken.

Zo simpel is het. Ja het is PPM in en PPM uit maar er is meer aan de hand. Je moet je realiseren dat een multiswitch MEERDERE pulstreinen nodig heeft om alle schakelaar posities over te sturen. Die gegevens worden in een vaste volgorde verstuurd en die volgorde is van levens belang voor de goede werking van de multiswitch. Het is een time multiplex systeem. Wanneer daar één of meerder blokken tussenuit vallen zal de timing niet meer kloppen en de zaak niet goed meer werken. Als er een blok in de reeks weg valt is er dus data van de multiswitch verloren gegaan!!!!! Daarmee zal bijvoorbeel de posities van schakelaar 3 en 4 verloren zijn gegaan. Omdat de processor gewoon weer de data van het vorige (wel goed ontvangen blok) op de uitgangen zet zullen de schakelaars 3 en 4 dezelfde posities krijgen als 1 en 2. En wanneer de ontvanger de data compleet negeert, dus ook niet de oude data opnieuw uitstuurd (dat kan namelijk ook gebeuren) dan zullen de posities van schakelaars 5 en 6 naar 3 en 4 gaan. Zo schuiven de kanalen dan allemaal een stukje op. Bij de ontvangst van de laatste posities zal de decoder nog een set pulsen verwachten voor de laatste kanalen maar krijgt die niet omdat er een blok verloren is gegaan.
Code: 
         Zender				Ontvanger
Pulstrein  Coder uitgang	  Decoder ingang         Uitgangen
  1	   Startcode           Reset naar het begin      Geen verandering 
  2	   Kanalen 1 en 2      Kanalen 1 en 2            Kanalen 1 en 2
  3	   Kanalen 3 en 4      Valt weg                  Kanalen 1 en 2!!!
  4	   Kanalen 5 en 6      Kanalen 5 en 6            Kanalen 5 en 6
  5	   Kanalen 7 en 8      Kanalen 7 en 8            Kanalen 7 en 8
  6	   Kanalen 9 en 10     Kanalen 9 en 10           Kanalen 9 en 10
  7	   Kanalen 11 en 12    Kanalen 11 en 12          Kanalen 11 en 12
Wanneer de ontvanger de vorige goede signalen niet herhaald maar niets zendt als er iets fout is ontvangen dan krijg je de volgende tabel:
Code: 
         Zender				Ontvanger
Pulstrein  Coder uitgang         Decoder ingang         Uitgangen
  1	   Startcode           Reset naar het begin     Geen verandering 
  2	   Kanalen 1 en 2      Kanalen 1 en 2           Kanalen 1 en 2
  3	   Kanalen 3 en 4      Valt weg                 Nog even niets !!!!
  4	   Kanalen 5 en 6      Kanalen 5 en 6           Kanalen 5 en 6 gaan naar 3 en 4!!!!
  5	   Kanalen 7 en 8      Kanalen 7 en 8           Kanalen 7 en 8 gaan naar 5 en 6!!!!
  6	   Kanalen 9 en 10     Kanalen 9 en 10          Kanalen 9 en 10 gaan naar 7 en 8!!!
  7	   Kanalen 11 en 12    Kanalen 11 en 12         Kanalen 11 en 12 gaan naar 9 en 10!!!!
De kanalen 11 en 12 krijgen nu geen update want er is een datablok weggevallen.

Zoals al geschreven vallen er met grote regelmaat datablokken weg door verstoringen. Daar merken we normaal gesproken zo goed als niets van door de ook al gegeven redenen maar een multiswitch gaat er door de mist in, dat moet toch wel te begrijpen zijn lijkt me.

Een voorbeeldje waar een soortgelijk verhaal speelt en dat we wel merken. Wat dacht je van je mobile telefoon? Die werkt ook met burstuitzendingen. Een x aantal keren per seconde zendt je mobieltje zijn digitale data naar het basisstation en met soortgelijke bursts ontvangt hij de digitale data terug. Af en toe valt er wel eens een blok data uit door om het even welke reden en dat hoor je dan door een kleine "hik" in de stem van de persoon waar je mee spreekt. Dat geeft niets want meestal kan je toch nog wel verstaan wat er gezegt wordt. Als hier nu ook multiswitch data mee verstuurd zou worden dan zou de decoder ook de mist in gaan omdat hij een blok gegevens niet heeft gekregen en zo "de tel" is kwijtgeraakd.

Duidelijker kan ik het niet uitleggen.
 
Laatst bewerkt:
Ik ontken niet wat je zegt Ernst. Het is ook een mogelijkheid.

Welke van de 2 scenario's precies optreedt; is pas te zien als je de hele handel aan een scoop zet en gaat meten.

Ik ben duidelijk positiever dan jij. Jij denkt dat het niet werkt omdat er signaalblokken wegvallen. Ik denk niet dat dat de reden is dat het niet werkt.

In jouw stellingname zou je verwachten dat het systeem wel werkt indien zender en ontvanger erg dicht bij elkaar staan op een ideale ontvangstafstand en er geen stoorzenders zijn. Is dat ook zo? Of werkt het helemaal niet? Als het helemaal niet werkt, is mijn verklaring meer aannemelijk.
 
Ik geloof er ook niks van, dat er signalen wegvallen. Wél, dat de decoder de tel kwijtraakt omdat het rijtje, wat-ie te zien krijgt niet correspondeert met het oorspronkelijke rijtje, dat in de zender wordt opgewekt. Nu is dat toevallig ook, wat ik de hele tijd al beweer, dus ik ben in herhalingen aan het vallen.

V.w.b. de vraag over de synchronisatie: multiswitch systemen werken met een afwijkende pulslengte als sync signaal, zoals ik op de eerste blz. van dit draadje al schreef: een puls van 1 ms = sync, 1,5 ms = schakelaar-uit en 2 ms = schakelaar aan. De allereerste 6-voudige multiswitch systemen van Robbe deden dit door twee keer zo'n puls te genereren. De huidige gebruiken juist een iets langere puls als sync, maar het principe is het zelfde.
 
Laatst bewerkt:
Daar kan ik geen antwoord op geven want ik heb geen mogelijkheden om dat te testen. Wat ik wel zeker weet is dat er dus echt veel blokken wegvallen. Dat zit een soort vastgebakken in het systeem en het grote aantal signalen op de 2,4GHz band. Juist omdat dit zo veel gebeurt zitten al die "beveiligingen" in het systeem. Daarom wordt er gebruik gemaakt van meerdere kanalen tegelijk of hopt een systeem over meerdere kanalen heen of wat voor andere systemen er ook bedacht zijn. Allemaal om er voor te zorgen dat er zo veel datablokken als maar mogelijk is goed aankomen.
Pas wanneer 50% of meer van de blokken wegvallen gaan we er echt iets van merken. Dan wordt de besturing langzamer en lijkt het net alsof je met een te trage computer aan het simmen bent. Je stuurt en als je denkt "gebeurt er nog wat?" reageert je model pas.
Zoals ik al in een ander draadje heb geschreven heb ik al enige tijd een Futaba 7C waar ik een tijd lang mee heb lopen "spelen". De betrouwbaarheid van het systeem is mij heel erg meegevallen. Ik heb hele rare dingen moeten doen om de verbinding helemaal weg te laten vallen. In eerste instantie wordt het systeem alleen maar trager maar het blijft betrouwbaar werken. Geen trillende servo's of plotselinge stuurbewegingen. Geen regelaars die plotseling volgas gaan of dergelijke dingen. Alleen wordt alles steeds trager en trager om dan plotseling helemaal weg te vallen. Zolang er nog een minimum aantal datablokken ongeschonden binnen komt blijft alles werken. Pas wanneer dat minimum niet meer wordt ontvangen schakelt de fail-safe mode in. Helaas zal in zo'n geval de multiswitch er al veel eerder mee ophouden. Als daar maar één blok mist klopt het al niet meer.
Natuurlijk zullen er systemen te bedenken zijn die dit probleem omzeilen en toch goed kunnen werken. Met een beetje fantasie kan ik ook wel een systeem bedenken. Zo zou je bijvoorbeeld de pulstijd tussen de 1 en 2msec op kunnen delen in 10 stapjes. 1msec is kanaal 1, 1.1msec is kanaal 2, 1.2msec is kanaal 3 en zo voorts. Met het tweede kanaal kan je dan bepalen wat dat kanaal moet doen. Je kan zelfs elk kanaal proportioneel laten werken. Mis je dan op de ene of andere manier een blok of krijgt de decoder hetzelfde blok meerdere keren binnen dan is er niets aan de hand. De tijd van de eerste puls geeft duidelijk aan welk kanaal er wordt verzonden. Ook hier geldt dat alles trager gaat werken als er (te) veel verstoring is maar de volgorde blijft goed en elk kanaal krijgt de eigen data.
Met behulp van de moderne PIC processors moet dit te realiseren zijn. Helaas weet ik te weinig van die dingen af en ook het programmeren ervan is voor mij grotendeels een soort "Chinees".
 
Laatst bewerkt:
Ik zal het wel eens gaan testen. Oplossing is ook vrij simpel door dubbele frame waarden te detecteren. Kwestie van zo coderen dat je kan zien dat er een dubbele waarde in zit en die eruit filteren.
 
Die kant zat ik inderdaad ook op te denken.. enige nadeel van de uiteindelijke implementatie kan zijn dat e.e.a. iets trager wordt.. en het was al wat trager.

Aan de andere kant, de mensen die multi-switch modules gebruiken zullen het doorgaans niet erg vinden of een lampje nou na 10ms of na 50ms gaat branden.. dat overleven ze wel (wat kort door de bocht gesteld)
 
You must log in or register to reply here.
Back
Top