Volgorde servo puls Futaba R118F 40mHz ontvanger

Hallo,

Ik ben een Arduino systeem aan het ontwerpen voor in een duikboot dat de ontvanger kanalen uitleest, deze kanalen mixed, en waar nodig een gyro signaal mee mixed ter stabilisering van het onderwatervaren. Ik loop tegen een vreemd probleem aan met het inlezen van de kanalen.

Normaalgesproken (wat ik gemerkt heb) stuurt een ontvangen de servo PWM signalen netjes op volgorde van de kanalen uit. Beginnend met kanaal 1, dan 2, dan 3 enz tot 8. Dat is handig want dan kan de Arduino deze ook op volgorde inlezen en zo de kortst mogelijke tijd daarmee bezig zijn. Zo'n 20 milliseconde, ongeacht of het 2 of die 8 kanalen zijn.

De Futaba R118F in combinatie met een Futaba FX-18 gooit de PWM's er echter in een vrij ondoorzichtige manier uit. Ik heb al heel wat combinaties van uitleesvolgorde geprobeerd maar kom niet sneller uit als 44ms. Heeft iemand een idee wat de volgorde zou kunnen zijn? Op zich zou met die 44ms wel te leven zijn, maar dan wordt de gyro verwerking mogelijk wat traag. Als ik de juiste volgorde kan pakken komt het waarschijnlijk weer op 20ms terecht, hoop ik ... Iemand een idee?

 

Ik heb een (35MHz) FP-R118F even aan de logic analyzer gehangen en die gooit zijn 7 kanalen er netjes op kanaalvolgorde uit. Let op dat de vallende pulsflank van bijvoorbeeld kanaal 1 (Channel 0 in afbeeldiing) samenvalt met de stijgende pulsflank van kanaal 2.

Als je in je Arduino een pin change interrupt zet op de stijgende flank van kanaal 1, dan weet je dat er een pulstreintje is begonnen en zou je dus van alle kanalen alleen de dalende pulsflanken hoeven op te vangen met een pin change interrupt, die steeds een kanaaltje opschuift.

Wat de functie is van die uitgang 8/9 op de ontvanger begrijp ik niet. Op het moment dat de 7 servo pulsen worden uitgestuurd is die "laag" en op het "stille" gedeelte tussen de pulsen is hij "hoog". Dat is de paarse lijn Channel 7. Je zou de falling edge daarvan kunnen gebruiken om de start van het pulstreintje te detecteren. Dan heb je alleen falling edge pin change interrupts nodig.

 

Ik heb van Jan van Mourik RIP wel eens begrepen dat niet alle 2,4GHz ontvangers een keurig pulstreintje aanhouden... Sommige geven min of meer alle servopulsen tegelijk.

 

Heb je in de zender niet nog ergens een mixfunctie aan staan?

 

Dat heb ik bij Futaba Fasst een keer zelf ook gemerkt toen ik er een Arduino aan wilde hangen, die het eerst wel goed deed met een Flysky ontvanger en bij Fasst helemaal in de war ging.
Maar bij de 35MHz ontvangers is het een (PPM) pulstreintje wat vananf de zender aankomt en de ontvanger splitst/verhaspelt dat over de verschillende kanalen en zet ze om in PWM pulsen. Maar aan de timing van de pulsen hoeft die ontvanger niks te wijzigen.

 

Is het deze ontvanger?
https://www.modelbouwforum.nl/threads/futaba-fp-r118f-ontvanger.40146/

 

Je zou op zo'n extra uitgang het CPPM signaal verwachten, maar dit lijkt meer op de laatste uitgang van het shiftregister...
Aha... DSC dus...

 

Die zit er wel in, maar moet je direct vanaf de print ophalen. CPPM zit op de hieronder aangegeven plek op het printje.

 

@hmeijdam. Als je, zoals in jou plaatje, 6 uitgangen krijgt en de zevende is een bijna 50% blokgolf dan heb je een 7 kanalen (of 8) ontvanger maar de zender zendt niet meer dan 6 kanalen uit.
De mogelijke oorzaak van de problemen is denk ik net iets anders.

Die DSC ingang is eigenlijk de uitgang van de middenfrequent filter/decoder die via naar een versterker/signaalvormer naar de kanalen decoder gaat.
Het signaal is niet erg "schoon" en wisselt vrij sterk in signaal grootte als je wat verder weg komt van de zender. Deze "uitgang" wordt ook gebruikt om de middenfrequent filter/decoder af te regelen.
Wanneer je via een kabel de uitgang van de puls generator in de zender daar op aansluit stuur je een vrij sterk signaal rechtstreeks de versterker in en dan naar de decoder. Zo kan je direct de servo's bedienen zonder dat de zender een signaal uitzendt.

Er zijn wat "probleempjes". Het eerste is dat het signaal meestal omgekeerd is. De PWM trein die uit de MF/decoder komt is meestal een trein negatieve pulsen.
Zoals ik ook al schreef is het signaal niet echt een mooi schoon signaal. Wanneer je het signaal eerst versterkt en schoon maakt zal je waarschijnlijk meer succes hebben. Mogelijk zal je het signaal ook moeten inverteren zodat je positieve pulsen krijgt.
Succes.

 

Dat is exact wat ik ook op mijn oscilloscoop zag, toen ik op zoek ging naar het CPPM signaal.
Links van dat component wat net boven de tekst N157 zit meet ik een CPPM signaal met behoorlijk afgeronde toppen. rechts binnen de markering is dat signaal iets versterkt en mooi strak getrokken.
Gelukkig maakt het voor een Arduino niet echt uit of je hem een normaal of geïnverteerd CPPM signaal aanbiedt. Dat vergt een minimale verandering in de software.

Wellicht dat de topicstarter even kan aangeven hoe hij de PWM servosignalen uitleest. Wellicht is het gebruik van Pulsein() mede de oorzaak van het probleem.

 

Heren, allen dank de snelle en informatieve reacties!

Om met de laatste te beginnen, ik gebruik inderdaad pulseIn() voor het inlezen:



Ik heb wat zitten wisselen met de kanalen, en deze deels door trail and error gevonden volgorde levert het snelste resultaat op. De bovenste twee kunnen verwisseld worden zonder effect, ook binnen het tweede blok kan er met enkele gewisseld worden. Maar zodra er tussen die twee blokken gewisseld wordt schiet het naar 64 of 84 ms verwerkingstijd.

Bij ander sketches doe ik dat ook zo en kom bij het uitlezen tot 8 kanalen netjes op volgorde aan 20ms inleestijd. Ja, eigenlijk wachttijd, ik weet het, maar die 20ms is voor 'normaal' RC gebruik prima te doen. En binnen die 20ms wordt dan ook de rest van de sketch uitgevoerd, werkt voor mij prima. Deze FP-R118F is de eerste waar dat niet bij wil lukken dus.

@mheijdam, dank voor het meetwerk. Dan gooit hij het er dus toch netjes op volgorde uit. Misschien zijn de tegelijk stijgende en dalende flanken het probleem in combinatie met de pulseIn() inlees, en wordt er een puls gemist waardoor er weer 20ms extra gewacht moet worden. Het inlezen met pin change interrupt kwam ik bij mijn zoeken naar oplossingen ook tegen, maar heb ik nog nooit zo geprogrammeerd. Daarbij hangt er aan de Arduino Nano een tweede Nano via I2C communicatie om een stepper motor snel genoeg aan te kunnen sturen, en op die lijn komt ook de gyro module te zitten. Geen idee of een pin change interrupt met I2C gaat conflicteren?

Andere ontvangers waar ik wel binnen de 20ms blijf zijn allemaal 2,4GHz ontvangers. Mogelijk is deze 'oude' 40 MHz ontvanger gewoon niet precies genoeg voor dit werk, of het 40MHz zendprotocol? Ik heb ook nog een 40 MHz Jeti en DSC Digital ontvanger liggen, ik zal nog eens kijken of dat verschil maakt. De zender heb ik op voorhand ook helemaal op nul gezet, geen mixers, ATV, EXPO, DR of wat voor zaken dan ook ingeschakeld of aangepast.

 

Zoals ik al aangaf is de kans groot dat de pulserate bij de "oude systemen" lager kan zijn dan 50Hz, of te wel 20ms. Dat zal vrij zeker zo zijn als de zender meer dan 6 kanalen uitzend. Denk dan eerder aan een pulserate van 40Hz, of te wel 25ms.

Het is overigens de zender die de pulserate bepaalt bij deze systemen. De ontvanger doet dat niet!

 

Als je pulsein() gebruikt met opeenvolgende kanalen ben je per definitie steeds net te laat om het volgende kanaal te pakken. Je mist dan namelijk net de opgaande flank van de opvolgende puls omdat die bij deze ontvanger precies samenvalt met de neerwaartse flank.
Steeds 1 kanaal overslaan is inderdaad met PuldeIn() het snelst haalbare. Bij 1-3-5-7-2-4-6-8 heb je immers steeds tussen 1 en 2 milliseconden de tijd om na afronden van het uitlezen van bijvoorbeeld kanaal 5 de zaak tijdens het inkomen van kanaal 6 klaar te zetten voor het uitlezen van kanaal 7. PulseIn() vereist nl zowel het zien van de opgaande als neergaande flank van de puls. En blokkeert terwijl hij uitleest ook nog eens je hele Arduino.

Je gooit dus sowieso 50% van je processortijd weg aan wachten binnen Pulsein(). Vandaar de suggestie om dit met pin change interrupts te doen. Nu is het programmeren daarvan wel ingewikkelder, maar ik heb ooit een library gevonden van een fransman die dat inlezen van servokanalen op de achtergrond uitvoerde. Ik ga eens zoeken of ik die kan vinden.

@Ernst Grundmann De zender die ik aan de analyzer had hangen deed 44Hz

 

Dat klopt met 7 kanalen. Als het 8 kanalen zouden zijn krijg je (ongeveer) 40Hz. Voor het gemak was ik daar van uit gegaan.

 

Weer teruggevonden en even een test programmaatje voor je Nano gemaakt

1) installeer deze library (druk op groene button "code" en dan "download zip")
2) Laad onderstaande sketch in je Nano en je ziet de servokanaalwaarden geprint. Ik heb de pins 4 t.m 11 gekozen voor je 8 kanalen, maar die kun je naar eigen willekeur veranderen.

Misschien leuk om te weten, maar de franse ontwikkelaar van deze servo library is ook een scheepsmodelbouwer

 

Hi Hmeijdam, dank voor je moeite, top! Ik ga daar eens me spelen, ik zal het laten weten! Dit krijgt geen ruzie met I2C? Merk ik anders ook vanzelf, Nano nr2 hangt er via I2C al aan om de stepper aan te sturen. ... maar zou dan wellicht niet meer nodig zijn als dit interrupt inlezen straks inderdaad zonder tijdverliezen kan draaien. Ben heel benieuwd .. !

Met de pulseIn() heb ik al verschillende sketches voor Nano's gemaakt die meerdere kanalen inlezen, en kwam altijd op 20ms totale inleestijd uit, ook met 6 of 8 kanalen. Maar dat waren allen 2.4GHz systemen (Graupner, Jeti, Radiolink). Jou uitleg lijkt logisch waarom het eigenlijk niet zou moeten werken, maar het doet het toch wel. Nu dit oude, maar voor subs onontbeerlijke 40MHz systeem nog op de knieën krijgen ..

 

Ik heb meteen de library gedownload maar bij zip bibliotheek toevoegen krijg ik dan een foutmelding:

Error: 13 INTERNAL: Library install failed: moving extracted archive to destination dir: library not valid

 

Gebruik jij soms Arduino IDE V2.x.x?
Ik gebruik zelf een portable installatie van Arduino IDE 1.8.19

 

Yep....

 

De library is al wat ouder, dus zal niet geschikt zijn gemaakt voor automatische installatie in de nieuwe IDE. Je kunt hem proberen handmatig uit te pakken in de libraries folder in je sketchbook folder.

Dan krijg je ..(jouw pad naar)..........Documents> Arduino> Libraries> 31 directories met alle libraries

Zojuist even getest met 2.3.2 en bij mij werkt dat dan

Ik denk dat je die 2e Nano om de stepper mee aan te sturen straks niet meer nodig hebt. De I2C (TWI) heeft trouwens zijn eigen interrupt dus de pin change interrupt die door deze library wordt gebruikt zit dat niet in de weg.