PPM signaal hoe zit het nou echt?

Cheeta

Forum veteraan
Wie heeft duidelijke documentatie met betrekking tot de PPM signaal.

ik weet dat het ppm signaal opzich er ongeveer zo uit ziet.

ppm.jpg


echter zover ik weet maar helaas niet kan testen op mijn scoop. Wordt dit signaal 8x uitgezonden en komt er vervolgens een resetpuls / leegblok. Dit zal nodig zijn voor de multiswitches neem ik aan. gebeurt dit alleen bij robbe of ook bij andere fabrikanten?

heeft er iemand duidelijk documentatie over?
 
In de laatste MBA staat er een artikel waar het in aangestipt wordt.

Hier ook een vrij complete uitleg:
PCM vs PPM

Kort samengevat: een frame duurt 22,5ms en begint met een startpuls. Daarna komen de 8 kanaalpulsen.

Dat is niet gedaan voor multiswitches etc, maar domweg omdat het nodig is. Stel dat je continu pulsen achter elkaar zou versturen, dan kan je ontvanger onmogelijk weten welke puls voor welk kanaal is. Daarnaast krijg je dan een variabele framelengte. (een frame = het totaal verzonden signaal om voor alle kanalen eenmalig de positie door te geven)

Over het algemeen zitten de kanaalpulsen tussen de 1 en 2.0ms, waarbij 1 de uiterste positie 1 kant op is, 1.5ms het midden en 2ms het andere uiterste. Let op dat dit voor bv. oudere multiplexzenders iets anders is, weet de exacte getallen daarvoor niet meer.

De lengte van de startpuls is zeg maar 22,5 seconde minus de lengte van de kanaalpulsen. Op die manier is de startpuls altijd langer dan een kanaalpuls en zodoende door de ontvanger te herkennen als de startpuls.
 
Laatst bewerkt door een moderator:
Kleine correctie: de ppm-framerate bij meerkanaals Futaba-zenders is 20 ms. Bij de overige merken ligt deze op ongeveer dezelfde waarde. Je komt dan aan een 50 Hz ritme, oftewel 50 berichten per seconde. Vroegâh had Multiplex met 25 ms de langste framerate.

De resetpuls of de synchronisatiepuls, die een conventionele ppm-ontvanger nodig heeft om de juiste kanalenvolgorde te weten bedraagt meestal zo'n 4 milliseconde. Het decoder-ic, dat meestal een schuifregister (CD4015 bij Futaba) of een Johnson counter (CD4017 bij andere merken) is, wordt daarmee geleegd of op '0' gezet. Na deze synchronisatiepuls weet de decoder dan, dat de eerstvolgende puls kanaal 1 is.

Het zelfde zie je ook bij multiswitches. Ook hier heb je een sync-puls om de volgorde aan te geven, gevolgd door de pulsen voor de schakelaars. Volgens mij gebruiken de multiswitches, die je zelf bouwt, de timing zoals ik die ook voor mijn 'Kanaalmultiplexersysteem' gebruikte. Dit is een 8-voudig multiswitch systeem, dat in Hobby Bulletin sept. en okt. 1983 werd beschreven. Zeer aan te bevelen om dit eens door te nemen omdat er wordt uitgelegd hoe zo'n systeem precies werkt. Niet letten op het grote aantal ic's, dat ik nodig had, want ik was toen nog niet vertrouwd met bcd-tellers en schuifregisters. De latere, commerciële versie, had nog maar 3 ic's in het decoderdeel. Tegenwoordig doe je dat uiteraard met een microprocessor.
Als timing gebruikte ik voor een 8-voudig multiswitch systeem 1 ms (= sync), 1,5 ms (= schakelaar uit) en 2 ms (= schakelaar aan). Voor een 16-voudig systeem met acht 3-positie schakelaars: 1 ms (= sync), 1,3 (= schakelaar naar beneden), 1,6 (= schakelaar uit) en 1,9 ms (= schakelaar naar boven).
Zoals te zien, is deze timing tamelijk relatief. Zo lang er maar duidelijke verschillen zijn tussen de diverse pulslengtes en zo lang het voor de ontvanger geldige waardes zijn (niet veel korter dan 1 ms en niet veel langer dan 2 ms) kunnen vrijelijk andere waarden worden gekozen.
 
Laatst bewerkt:
Als het om een eigen ontwerp multiswitch gaat, zou ik het heel anders aanpakken.

Verdeel elk kanaal in 8 stappen ipv 3. Daar is ruimte genoeg voor om nog voldoende onderscheid te kunnen maken. 8 stappen is 3 bits. Je zend dan dus elk frame 24 bits over.

Dan kun je bv. 2x 9 bits (512 stappen) proportionele kanalen maken en 6 schakelkanalen, of 24 schakelkanalen, of, of...

Dit heb ik in de praktijk korststondig getest toen ik voor mijn Cessna bezig was en dat leek goed te werken. Als blijkt dat 8 stappen per kanaal teveel is, kun je terugstappen naar bv. 4 stappen (2 bits, wat het geheel 16 bits maakt)

Je zou er ook voor kunnen kiezen om een aantal bits toe te wijzen voor een 'checksum-achtige-functie'.
 
Laatst bewerkt door een moderator:
ppm.jpg

dit is mij duidelijk.

echter wat mij niet duidelijk is, is of dit 8x herhaald wordt dus de hele cyclus. en vervolgens een reset komt of dat dit gewoon oneindig herhaald wordt.

als het 8x herhaald wordt en er dan een resetpuls volgt is het mij niet duidelijk waarom robbe modules bijvoorbeeld niet werken op 2.4ghz?

als het signaal oneindig herhaald wordt dan kan dit inderdaad wel een stuk complexer komen te liggen.

nu betekent het nog niet dat ik daar geen oplossingen in zie maar geeft het wel wat meer uitdaging.

ik ben nu ook aan het kijken naar een eventuele eigen ontwikkeling en dan voornamelijk voor mijn telekraan omdat ik daar gewoon chronisch kanalen tekort heb.
 
Blijkbaar is het niet duidelijk, want deze vraag heeft Hezik hiervoor reeds beantwoord.

Ook vraag ik me af of de kanalen helemaal goed worden geïnterpreteerd bij dit scoopbeeld. De eerste neergaande flank is het einde van de synchronisatiepuls en het begin van kanaal 1. De volgende negatieve flank is het einde van kanaal 1 en tegelijk het begin van kanaal 2. De daaropvolgende is het einde van kanaal 2 en het begin van kanaal 3, enz. De laatste negatieve puls is dan weer het begin van de sync.
Elk kanaal bestaat hier dus nog uit een negatieve puls (met vaste lengte) en een positieve puls (van variabele lengte). In de ontvanger worden deze twee door het decoder-ic samengevoegd tot één positieve puls.
 
... als het 8x herhaald wordt en er dan een resetpuls volgt is het mij niet duidelijk waarom robbe modules bijvoorbeeld niet werken op 2.4ghz?...

Bij 2,4 GHz verbindingen is het geen PPM meer dat door de lucht verstuurd wordt ... maar datablokken die je meer met IP moet vergelijken ... in de ontvanger wordt er weer door de ingebouwde microprofessor "iets" van gemaakt dat de gemiddelde servo begrijpt, maar of timing tussen de onderlinge servo-uitgangen intact blijft ??? ...
 
Bij 2,4 GHz verbindingen is het geen PPM meer dat door de lucht verstuurd wordt ... maar datablokken die je meer met IP moet vergelijken ... in de ontvanger wordt er weer door de ingebouwde microprofessor "iets" van gemaakt dat de gemiddelde servo begrijpt, maar of timing tussen de onderlinge servo-uitgangen intact blijft ??? ...

Bij de meeste 2.4 Ghz systemen wordt de pulstrein (puls positie) de lucht ingestuurd gemoduleerd als QPSK (Quadrature Phase Shift Keying) of een variant van QPSK zoals O-QPSK (Offset-QPSK) en zelfs pi/4-QPSK zoals bij Bluetooth Blijkbaar kan Graupner iFS/XFS nu (of in de toekomst) ook PCM code versturen in een van de QPSK varianten. Het voordeel daarvan is mij niet duidelijk.

Na demodulatie is er niet "iets" dat de servo gebruikt maar een pulstrein (puls positie) die dan na enige decodering door de servos begrepen wordt.

Maar TCP/IP data wordt er niet verstuurd, dat zou heel moeilijk worden met eenwegs 2.4 Ghz systemen ook met UDP datagrammen.
 
Laatst bewerkt:
Wat ik bedoel is dat er geen pulstrein op basis van een timing wordt verstuurd, maar een reeks "getallen" ... bestaande uit een header (met o.a. het zender codegetal) gevolgd door en aantal "getallen" en een checksum (om te bepalen of de overgezonden data valid/compleet is) ... dus meer op een manier zoals TCP/IP data verstuurd ...
 
Laatst bewerkt:
Wat ik bedoel is dat er geen pulstrein op basis van een timing wordt verstuurd, maar een reeks "getallen" ... bestaande uit een header (met o.a. het zender codegetal) gevolgd door en aantal "getallen" en een checksum (om te bepalen of de overgezonden data valid/compleet is) ... dus meer op een manier zoals TCP/IP data verstuurd ...

Dat gebeurde al in PCM met FEC (Forward Error Correction). In 2.4 Ghz systemen wordt er in QPSK ook FEC, of Viterbi, of Reed-Salomon gebruikt.

Maar dat is absoluut niet te vergelijken met TCP/IP, echt niet. Het lijkt er zelfs in de verste verte niet op want TCP/IP is ontworpen voor CSMA/CD systemen (Carrier Sense Multiple Access/Collision Detection) draadgebonden of draadloos. Dit systeem impliceert overigens steeds een duplex verbinding, draadgebonden of draadloos. Bij TCP/IP heb je steeds een ACK of NAK in functie van de window size (het aantal paketten dat verzonden wordt voordat er een ACK of NAK komt). Dat zou nogal voor een latentie zorgen voor het besturen van een model.

Maar goed, men kan alles vergelijken. In dat geval zou men ook kunnen zeggen dat de 2.4 Ghz systemen lijken op het Philips TOR (Telex Over Radio) systeem uit 1950. Daar worden ook bitjes ( 5 bit per byte) overgestuurd met een FEC checksum.
 
Hoe de data overgebracht wordt is niet eens zo heel erg interessant, alleen als je een 2,4 GHz module in je PPM zender zet heb je geen PPM meer, maar wordt het een PCM variant, waarbij de data met een snelheid van iets tussen de 0,25 en de 1 Mbps wordt overgestuurd, stel dat een datablok 250 bit is dan wordt dat binnen een paar duizendste van een seconde overgezonden i.p.v. een binnen paar honderdste bij PPM/PCM op de "oude" frequenties ...

In de "oude" systemen worden de servo-uitgangen sequentieel aangestuurd (er staat maar op één uitgang te gelijk één servo-puls) ... bij de "nieuwe" systemen is het veel interessanter/efficienter alle uitgangen gelijktijdig van een puls te voorzien ... servo's en ESC's hebben hier absoluut geen moeite mee, maar multi-switchen kunnen hier wel op stuk lopen ...
 
Hoe de data overgebracht wordt is niet eens zo heel erg interessant, alleen als je een 2,4 GHz module in je PPM zender zet heb je geen PPM meer, maar wordt het een PCM variant, waarbij de data met een snelheid van iets tussen de 0,25 en de 1 Mbps wordt overgestuurd, stel dat een datablok 250 bit is dan wordt dat binnen een paar duizendste van een seconde overgezonden i.p.v. een binnen paar honderdste bij PPM/PCM op de "oude" frequenties ...

Dus, de puls postie pulstrein die de 2.4 Ghz module in een PPM zender ontvangt wordt sneller gecodeerd en gemoduleerd dan de snelheid waarmee deze puls positie data in de 2.4 Ghz module binnenkomt?

U heeft gelijk en ik ga terug naar de TU. De wetten van de fysica zijn blijkbaar drastisch veranderd.
 
Futaba stuurt 260 x per seconde 1,8 ms data uit en Assan 221 keer 0,9 ms data ...

Dus bij futaba wordt de PPM/PCM data 5x herhaald en bij Assan "slechts" 4x ....
 
Het probleem voor multiswitches is, dat de codering in de zender en de decodering in de ontvanger niet 1 : 1 synchroon lopen.

Dit is ook reeds het geval bij gebruik van het pcm1024-systeem, maar daarvoor zijn de decoders dan ook uitgerust met een keuzeschakelaar ppm-pcm. In de ppm-stand wordt gewoon rechtstreeks doorgegeven, wat er vanaf de ontvanger binnenkomt. In de pcm-stand bewerkt de microprocessor in de decoder het signaal.

Op 2,4 GHz wordt t/m de 7-kanaals ontvangers een op pcm1024 lijkende data gedecodeerd, bij 8-kanaals en hoger een op pcm-G3 (pcm2048 ) lijkende data. Blijkbaar is dit in beide gevallen zodanig anders dan pcm1024, dat men niet met een software-aanpassing komt. Er worden dus voor 2,4 GHz nieuwe multiswitch-modulen ontwikkeld. Wanneer die uitkomen is de vraag. Eind dit jaar werd er geroepen. Multi-modulen worden zo'n beetje uitsluitend voor Europa gefabriceerd en dat is wereldwijd gezien voor Futaba nu eenmaal niet de meest interessante markt. Om deze reden ontwikkelde Robbe tot nu toe dan ook zelf de meeste multi-modulen.
 
Het mooiste zou zijn dat je zowel aan de zender- als ontvangerkant de "PCM" code rechtstreeks kan manipuleren ... met twee 10 bits woorden kan je dan al 1024 "schakelaars" bedienen die elk 1024 standen kunnen innemen ... niet 100% realtime natuurlijk ... maar voor de meeste additionele stuurfuncties meer dan voldoende ... en zie maar eens 1024 extra knopjes op je zender te krijgen ... ;-)
 
mbt. multiswitches begrijp ik het probleem nog steeds niet. Aan zenderkant wordt er een PPM signaal gemaakt (ik ga even van een hybride systeem uit). Hoe dat signaal bij de ontvanger aankomt, is verder niet relevant. Aan ontvangerkant komt er weer een PPM signaal uit.

Hoe het dan zou kunnen dat multiswitches niet werken, is mij een beetje een raadsel.

Het enige wat ik mij kan bedenken is dat de timing van de kanalen onderling een hindernis zou kunnen zijn (dat bij een 2.4Ghz zet elke servo gelijktijdig gepulst zou worden) maar dan nog is dat heel simpel met 1 picje op te lossen..
 
Laatst bewerkt door een moderator:
Het ligt er maar net aan hoe het signaal bekeken wordt maar normaal gezien zou je zeggen dat 1 enkel kanaal van de pwm gelijk uit de ontvanger moet komen wat er ook tussen zit.
 
Volgens mij had ik al een duidelijke verklaring gegeven: de codering in de zender en de decodering in de ontvanger lopen niet 1 : 1 synchroon. Dat is voor een tijdmultiplex systeem nu eenmaal een voorwaarde. Uiteraard maakt het daarbij geen enkel verschil of kanalen gelijktijdig of sequentiëel op de uitgangen van de ontvanger verschijnen. De multiswitch decoder is nu eenmaal uitsluitend geïnteresseerd in de info van z'n eigen kanaal.
Het hele verhaal is, dat de sequentie van het multiswitch kanaal niet verstoord mag worden. In de eerste pulstrein moet de info van schakelaar 1 aanwezig zijn, de tweede heeft de info van schakelaar 2, enz. Het mag dus niet zo zijn, dat om één of andere reden de info van schakelaar 1 een keer wordt herhaald of dat-ie wordt overgeslagen. Ook niet eens in de zoveel tijd. Het rijtje klopt dan niet meer.

Bij het eerste pcm-systeem van Futaba was eenvoudig vast te stellen, wat de problemen veroorzaakte. Tussen de ontvanger en de decoder moest een tweedeler worden opgenomen. De eerste puls werd doorgelaten, de tweede niet, de derde weer wel, enz. De verklaring was eenvoudig: om tijd te sparen werd het multiswitch kanaal slechts de helft van de tijd bemonsterd en vermoedelijk ook slechts de helft van de tijd verzonden. De ontvanger genereerde daarbij dan twee keer achter elkaar dezelfde puls om het 'gat' op te vullen. Voor een servo, een regelaar of een gewone kanaalschakelaar maakt zoiets praktisch geen verschil: in plaats van na max. 0,02 sec te reageren op het stuurcommando wordt er dan na max. 0,04 sec gereageerd. Een multiswitch heeft dan echter een probleem.

Bij het Futaba pcm1024 systeem wordt er heel wat ingewikkelder gegoocheld met de data van de kanalen. Hoe dit precies zit, weet ik niet. Over zoiets wordt geen informatie verstrekt en volgens mij heeft ook nog nooit iemand de moeite genomen dat eens uit te zoeken. Er is in ieder geval niet meer zo'n geprononceerd verschil tussen snelle en trage kanalen, maar er is nog steeds verschil. Ook spelen andere dingen mee, zoals bijv. het om de zoveel tijd verzenden van failsafe data (vermoedelijk in plaats van de data van kanaal 8 )en het in clusters beoordelen van data op geldigheid. In ieder geval is er voldoende verschil om een onregelmatige verwerking van de multiswitch gegevens te veroorzaken en dus het rijtje te verstoren. Zoiets moet dan in de software van de multiswitch decoder worden gecorrigeerd. Dit gebeurt dan ook als de keuzeschakelaar op pcm wordt gezet.

En dan op 2,4 GHz. Daar wordt dus weer op een andere manier met de data omgesprongen. Waarom ook niet? Je hebt dan niet meer een framerate van 20 ms nodig om alle info te verzenden. Dat kan veel sneller en dat wordt dan ook gedaan. Zo kun je vanaf de 8-kanaals ontvangers een aantal kanalen op hrs (high response speed) schakelen. Daarbij reageren ze niet meer met een vertraging van 17 ms (de FF10 werkt geloof ik op 2,4 GHz zo snel), maar al na pak 'm beet 6 ms.

Niet, dat ik persoonlijk denk, dat dit grote voordelen biedt, maar het begrip 'latency' staat momenteel in het centrum van de belangstelling. Het is dus een prima extra verkoopargument.
 
ik hoop toch eerdaags met de robbe modules te kunnen testen op 2.4ghz.

aangezien het met de ms12 met software van c.poltermann wel al werkt.

Nu kan het in de software zitten echter ga ik er toch van uit dat de princiepe werking niet veel scheelt tussen robbe en c.poltermann.

dus ben erg benieuwd.
 
Volgens mij had ik al een duidelijke verklaring gegeven:

Blijkbaar toch niet dus ;)

Het hele verhaal is, dat de sequentie van het multiswitch kanaal niet verstoord mag worden.
[..]Bij het eerste pcm-systeem van Futaba was eenvoudig vast te stellen, wat de problemen veroorzaakte.
[..]
En dan op 2,4 GHz. Daar wordt dus weer op een andere manier met de data omgesprongen. Waarom ook niet? Je hebt dan niet meer een framerate van 20 ms nodig om alle info te verzenden. Dat kan veel sneller en dat wordt dan ook gedaan. Zo kun je vanaf de 8-kanaals ontvangers een aantal kanalen op hrs (high response speed) schakelen. Daarbij reageren ze niet meer met een vertraging van 17 ms (de FF10 werkt geloof ik op 2,4 GHz zo snel), maar al na pak 'm beet 6 ms.

Allemaal leuk en aardig, maar je noemt nog geen argument waarom e.e.a. niet zou werken. We hebben het hier niet over PCM, dus dat hele verhaal is niet van toepassing. We hebben het ook niet over hrs kanalen, dus wederom niet van toepassing.

Dan resteert dus de vraag of het zo is dat de ppm pulsvolgorde in een 2.4Ghz systeem veranderd of herschikt wordt, wat de werking van de multiswitch zou verstoren. Ik heb daar vooralsnog nog niets over gezien.. het zou ook volstrekt onlogisch zijn.

Vooralsnog is mijn argumentatie niet weerlegd. Aan zenderkant is er op enig moment sprake van een ppm puls. Aan ontvangerkant wordt die puls gereproduceerd. Er is geen reden om bij 2.4Ghz een puls verminderd te bemonsteren of om de volgorde van pulsen te veranderen, ik zie dan ook niet in waarom aangenomen wordt dat dit wel het geval is.
 
Back
Top