Spektrum DX3R framerate
- Topicstarter Evert:-)
- Startdatum
Uiteraard blijven de servo pulsen hetzelfde maar je moet het zien als de Futaba HRS technologie. Omdat de frame van 20mS naar 5mS is gezet zal veel analoge dingen eraan in de problemen kunnen komen omdat die ingesteld zijn op een frame van 20mS.
Digitale servo's kunnen alleen maar goed samen werken als ook vele andere digitaal gestuurde electronica.
Digitale servo's kunnen alleen maar goed samen werken als ook vele andere digitaal gestuurde electronica.
Sleurhutje
Forum veteraan
Voor digitale schakelaars, stuurelektronica en ook bepaalde servo's geldt dat deze na inschakelen proberen te achterhalen wat de neutraalstand is. Doordat de lengte van de puls die van de lengte van de pauze tussen twee pulsen nadert, kan de software van dergelijke systemen niet meer goed bepalen wat nu de puls en wat de pauze is van het servosignaal. Gevolg is dus dat er een heel merkwaardig gedrag optreedt wat zich uit in onregelmatig aan/uit gaan of "trillen".
Als de software goed zijn best doet dan kan deze aan de hand van opgaande en/of neergaande flanken van de pulsen kunnen bepalen wat de tijd tussen twee pulsen is. Maar da's veel meer programmeerwerk. En tijd is geld en dat wil de gemiddelde consument niet betalen.
Als de software goed zijn best doet dan kan deze aan de hand van opgaande en/of neergaande flanken van de pulsen kunnen bepalen wat de tijd tussen twee pulsen is. Maar da's veel meer programmeerwerk. En tijd is geld en dat wil de gemiddelde consument niet betalen.
Zoals Roelof al opgeeft, is analoge apparatuur berekend op een framerate van 20 ms. Als je analoge servo's dan ook op een framerate van 5 ms laat werken geven ze een continue brom, worden loeiheet en zijn binnen de kortste tijd ter ziele. Dit komt doordat het pulsverlengingsnetwerk in de war raakt. Ook analoge schakelaars en regelaars hebben hetzelfde probleem.
Ook digitale apparatuur, zoals regelaars en schakelaars, zijn vaak berekend op een frame-tijd van 20 ms. In de software-parameter is dan opgenomen, dat de eerstvolgende puls binnen een bepaald tijdsbestek binnen moet komen. Als deze te vroeg of te laat komt, wordt dit als een storing beschouwd.
Ook digitale apparatuur, zoals regelaars en schakelaars, zijn vaak berekend op een frame-tijd van 20 ms. In de software-parameter is dan opgenomen, dat de eerstvolgende puls binnen een bepaald tijdsbestek binnen moet komen. Als deze te vroeg of te laat komt, wordt dit als een storing beschouwd.
Burp
Forum veteraan
Bij de spektrum zender, de DX3R, is de framerate standaard 11ms, traag op 16ms en snel op 5,5ms. 20ms lijkt mij dan ten opzichte van deze wel erg traag of niet?
De meeste servo's en switches werken allemaal feilloos tot 11ms maar daaronder gaat het mis, wat is daar nu de oorzaak van....
De meeste servo's en switches werken allemaal feilloos tot 11ms maar daaronder gaat het mis, wat is daar nu de oorzaak van....
Zou je zoiets op kunnen lossen door een tellertje er tussen te zetten die eens in de 4 pulsen een puls doorlaat?
Dan kom je weer in de buurt van de 20ms framerate.
Sleurhutje
Forum veteraan
Dan kun je makkelijker op je zender de framerate terug op 11ms of 16ms zetten. :?
Er zou een tweedeler tussengeschakeld kunnen worden, maar het nut daarvan zie ik ook absoluut niet. Het verschil in framerate merk je namelijk uitsluitend als je dit weet. Je hebt namelijk domweg zelf niet het reaktievermogen om deze verschillen te bemerken.
In een ander draadje heb ik al eens geschreven, dat de mens 10 tot 15 keer per minuut met zijn ogen knippert. Zo'n oogknipper duurt 100 tot 150 milliseconde. Ná de oogknipper heeft het oog op z'n minst dezelfde tijd nodig om weer te focussen op het object. Van dit hele proces merken we niets, doordat onze hersenen ons foppen. De oogzenuw wordt tijdelijk uitgeschakeld, zodat we gedurende zo'n oogknipper feitelijk blind zijn. Als je daarvan dus niets merkt, moet je niet de illusie hebben dat je een paar milliseconde in framerate wel opmerkt.
Als je dus echt wat wil doen aan response tijd of latency of welke kreet men ook gebruikt, zou je je oogleden met tape moeten afplakken.
Het enige verschil bij een kortere framerate is, dat servo's sneller en nauwkeuriger het zendersignaal kunnen volgen. Voorwaarde daarbij is dan wel, dat je uiterst snelle en uiterst nauwkeurige servo's gebruikt. Nog een voorwaarde is, dat je een jeugdige toprijder moet zijn om vervolgens te bemerken, dat het wat strakker stuurt. Het gekke is echter, dat velen - als ze weet hebben van een kortere framerate - opeens merken, dat servo's sneller sturen. Dat is dus puur een kwestie van jezelf bedriegen.
In een ander draadje heb ik al eens geschreven, dat de mens 10 tot 15 keer per minuut met zijn ogen knippert. Zo'n oogknipper duurt 100 tot 150 milliseconde. Ná de oogknipper heeft het oog op z'n minst dezelfde tijd nodig om weer te focussen op het object. Van dit hele proces merken we niets, doordat onze hersenen ons foppen. De oogzenuw wordt tijdelijk uitgeschakeld, zodat we gedurende zo'n oogknipper feitelijk blind zijn. Als je daarvan dus niets merkt, moet je niet de illusie hebben dat je een paar milliseconde in framerate wel opmerkt.
Als je dus echt wat wil doen aan response tijd of latency of welke kreet men ook gebruikt, zou je je oogleden met tape moeten afplakken.
Het enige verschil bij een kortere framerate is, dat servo's sneller en nauwkeuriger het zendersignaal kunnen volgen. Voorwaarde daarbij is dan wel, dat je uiterst snelle en uiterst nauwkeurige servo's gebruikt. Nog een voorwaarde is, dat je een jeugdige toprijder moet zijn om vervolgens te bemerken, dat het wat strakker stuurt. Het gekke is echter, dat velen - als ze weet hebben van een kortere framerate - opeens merken, dat servo's sneller sturen. Dat is dus puur een kwestie van jezelf bedriegen.
Misschien is het een een beleving maar de reactieverbetering lijkt wel merkbaar te zijn, mogelijk dat het versterkt wordt vanwege de snellere servo's.
Ik heb een Spectrum HRS systeem waarmee niet de framerate in te stellen is en nog een partij snelle analoge servo's en zou een stukkie electronica van een paar cent daarin kunnen helpen om niet massaal voor al mijn modellen digitale servo's te kopen.
Ik gaat eens experimenteren....
Ik heb een Spectrum HRS systeem waarmee niet de framerate in te stellen is en nog een partij snelle analoge servo's en zou een stukkie electronica van een paar cent daarin kunnen helpen om niet massaal voor al mijn modellen digitale servo's te kopen.
Ik gaat eens experimenteren....
Sleurhutje
Forum veteraan
Naarmate je auto verder is (meer dan 70 meter 8O), lijkt het aantal "missers" van de ontvanger toe te nemen. Dit merk je o.a. aan een tragere response bij het sturen. De missers worden echter door de ontvanger gecorrigeerd totdat er teveel missers zijn en dan springt de failsafe in werking.
Verder wat Corrien zegt, de servo wordt niets sneller door een andere frame rate. Het is net als een lawaaiige uitlaat. Daardoor lijkt het ook harder te gaan (in weze wel, maar dan voor het aantal decibellen :lol
.
Verder wat Corrien zegt, de servo wordt niets sneller door een andere frame rate.
Het is net als een lawaaiige uitlaat. Daardoor lijkt het ook harder te gaan (in weze wel, maar dan voor het aantal decibellen :lol.
Burp
Forum veteraan
Het niet sneller worden ga ik tot op zekere hoogte in mee, de servo zelf wordt niet sneller maar de reactie op een verandering is wel beter naarmate de framerate omhoog gaat volgens mij. Stel je voor dat een volgende puls pas na 1 seconde komt, de servo gaat natuurlijk gewoon op zijn snelheid werken maar na een seconde is er pas weer een verandering.
Ergo, bij veel beweging van de stick moet je ook een marginale verbetering in de totale snelheid kunnen meten. (niet te merken verder volgens mij maar sneller is het wel
)
Ergo, bij veel beweging van de stick moet je ook een marginale verbetering in de totale snelheid kunnen meten. (niet te merken verder volgens mij maar sneller is het wel
)
Sleurhutje
Forum veteraan
Maar als je servo een stelsnelheid van 0,08sec/60° heeft, dan is dat nog altijd 80 milliseconden voor 60°. Leuk dat de servo eerder weet welke positie die aan moet nemen, maar de techniek laat de elektronica toch een beetje in de steek dan. :? Dus alleen bij hele kleine veranderingen is het merkbaar (lees meetbaar).Het niet sneller worden ga ik tot op zekere hoogte in mee, de servo zelf wordt niet sneller maar de reactie op een verandering is wel beter naarmate de framerate omhoog gaat volgens mij. Stel je voor dat een volgende puls pas na 1 seconde komt, de servo gaat natuurlijk gewoon op zijn snelheid werken maar na een seconde is er pas weer een verandering.
Ergo, bij veel beweging van de stick moet je ook een marginale verbetering in de totale snelheid kunnen meten. (niet te merken verder volgens mij maar sneller is het wel
Sleurhutje
Forum veteraan
Ik heb nog geen scoop op de AR3100 gehangen. Het principe zal niets anders zijn dan het bestaande. De pulsbreedte voor de servo-aansturing zal nog steeds 1-2msec zijn. Alleen de pauze tussen twee pulsen is aanmerkelijk minder.
Op basis van oude analoge technieken is de pulstrein te verantwoorden ten opzichte van de snelheid van de servo's (elk kanaal werd sequentieel gemeten en doorgestuurd via radiogolven). Met de komst van digitale technieken is dat natuurlijk achterhaald. De ontvanger maakt zelf de pulsen aan op basis van de binnengekomen datastroom. Om die reden werken de klassieke failsafes ook niet. Er kan namelijk geen storing in het servo-signaal optreden omdat er geen enkele relatie is met het radiosignaal.
Om de pulsbreedte goed te detecteren/meten door middel van elektronica moet dus niet zomaar aangenomen worden dat om de zoveel milliseconden een puls plaats vindt. Wil je het goed doen, dan start je een timer die start bij de opgaande/neergaande flank en meet tot aan de volgende identieke opgaande/neergaande flank. Dat is de afstand tussen twee pulsen en daar kun je je sample-frequentie op afstemmen (de timer wordt dus softwarematig ingesteld na de meting en niet hard geprogrammeerd met een vaste waarde). Als je de afstand tussen de pulsen weet, kun je daarna de breedte van de puls gaan bepalen om zo de servo-positie te bepalen.
Als je eens met je scoop zou willen kijken hoe het eruit ziet zou ik je dankbaar zijn.
Ik ben voor Burp een Motor kill-switch aan het maken, maar deze wil maar niet werken met een framerate van 5ms. De overige framerates werkt perfect.
Maak ik zelf een puls van 1-2ms met een framerate van 5ms dmv een AVR, dan werkt het ook goed.
Het lijkt er toch op dat het niet helemaal zo is als wij denken.
Sleurhutje
Forum veteraan
Ik zal hem komend weekend eens aan de scoop hangen en wat plaatjes maken.
Teleurstelling voor onze clubleden natuurlijk, die lopen Burp gek te maken om die killswitch.
Burp
Forum veteraan
Hahaha, Evert is er druk mee bezig (we ontwikkelen deze al geruime tijd en verschillende testen gedaan.)
Ik kan de ontvanger ook even meenemen naar je Evert, als je een scope hebt dan weten we het meteen....
Of we wachten even op de plaatjes van Sleur... (nu ligt de bal een beetje bij jou sleur :rolling
Ik kan de ontvanger ook even meenemen naar je Evert, als je een scope hebt dan weten we het meteen....
Of we wachten even op de plaatjes van Sleur...
(nu ligt de bal een beetje bij jou sleur :rolling
Sleurhutje
Forum veteraan
Over frame rates, pulsbreedtes en built-in failsafe
@Burp, Evert en anderen die er interesse in hebben:
Ik heb even de scoop aan de AR3100 DSM2 ontvanger, SR3005 Micro-ontvanger in combinatie met een Spektrum DX3R zender en een AR6200 DSM2 ontvanger in combinatie met een Spektrum DX6i zender gehangen.
Dit zijn de bevindingen:
- De pulsbreedte van de servo-puls is in alle gevallen tussen de 1,0 en 2,0 milliseconde (conform de standaard);
- De pauzetijd tussen de pulsen is bepalend voor de frame rate (da's logisch :?). De totale tijdsduur van puls en pauze blijft gelijk, dus voor 16,5 msec wordt de pauze langer of korter al naar gelang de servopositie;
- De puls is positief. Dus de pauzeperiode is gelijk aan 0 Volt, de puls zelf is +5 Volt (spanning die de voeding aanlevert);
- Meest schokkende: Als de failsafe aanspringt is de frame rate voor alle Spektrum ontvangers 8 milliseconde!!! 8O
Conclusie:
Er is een wezenlijk verschil tussen de frame rates als de zender communiceert met de ontvanger en als de ontvanger geen signaal krijgt en in failsafe springt. Om deze reden werken "normale" failsafes dus ook niet goed in combinatie met de failsafe van de Spektrum ontvangers.
Te doen:
De software moet zodanig zijn dat deze niet meer afhankelijk is van de framerate. Dit kan gedaan worden door de Timer van de microcontroller te starten bij de opgaande flank van de puls en vervolgens de tijdsduur tot de neergaande flank te meten. Dit is de enige consante in het verhaal (circa 1,0 tot 2,0 milliseconden). Dus het bepalen van de frame rate bij de initialisatie is geen goede optie.
Ik hoop dat je hier wat mee kunt. Succes met experimenteren. 
@Burp, Evert en anderen die er interesse in hebben:
Ik heb even de scoop aan de AR3100 DSM2 ontvanger, SR3005 Micro-ontvanger in combinatie met een Spektrum DX3R zender en een AR6200 DSM2 ontvanger in combinatie met een Spektrum DX6i zender gehangen.
Dit zijn de bevindingen:
- De pulsbreedte van de servo-puls is in alle gevallen tussen de 1,0 en 2,0 milliseconde (conform de standaard
);- De pauzetijd tussen de pulsen is bepalend voor de frame rate (da's logisch :?). De totale tijdsduur van puls en pauze blijft gelijk, dus voor 16,5 msec wordt de pauze langer of korter al naar gelang de servopositie;
- De puls is positief. Dus de pauzeperiode is gelijk aan 0 Volt, de puls zelf is +5 Volt (spanning die de voeding aanlevert);
- Meest schokkende: Als de failsafe aanspringt is de frame rate voor alle Spektrum ontvangers 8 milliseconde!!! 8O
Conclusie:
Er is een wezenlijk verschil tussen de frame rates als de zender communiceert met de ontvanger en als de ontvanger geen signaal krijgt en in failsafe springt. Om deze reden werken "normale" failsafes dus ook niet goed in combinatie met de failsafe van de Spektrum ontvangers.
Te doen:
De software moet zodanig zijn dat deze niet meer afhankelijk is van de framerate. Dit kan gedaan worden door de Timer van de microcontroller te starten bij de opgaande flank van de puls en vervolgens de tijdsduur tot de neergaande flank te meten. Dit is de enige consante in het verhaal (circa 1,0 tot 2,0 milliseconden). Dus het bepalen van de frame rate bij de initialisatie is geen goede optie.
Ik hoop dat je hier wat mee kunt.
Succes met experimenteren.