Ik zit te knoeien om deze ontvangers te linken met de zender, als ik alles vlgs het boekje doe en ik zoek het fhss protocol in de zender dan krijg ik de tekst: "ch is lacking. it can not change" datzelfde krijg ik met Fasst-7ch Heeft iemand daar ervaring mee, en wat de oorzaak daar van kan zijn? Gr. Jan
is er toevallig geen update mis gegaan? of misschien gewoon heel het zend deel gefrituurd? lijkt mij iig dat hij blijkbaar iets niet kan vinden, softwarematig of hardwarematig. misschien dat @Corrien meer weet..
Tja, ik heb hem net een upgrade gegeven naar versie 8 maar hij doet exact hetzelfde, ik heb de zender 2 wkn geleden al naar @Corrien gestuurd omdat er een schakelaar niet goed werkte, dat is nu goed en hij vertelde me dat de zender verder ok was,is, dus ja......nou weet ik het ook niet meer, mss is het gewoon een miskoop.......
Beste Welke merk en type ontvanger praat jij over? het verschil zou kunnen zijn het zend protocol. Futaba heeft enkele jaren geleden dat ge upgrade na Listen Before Talk.. mijn T-12 heeft dus nog het oude protocol. Groet Hans https://www.modelbouwforum.nl/threads/futaba-update-fasst-protocol.224980/ https://www.modelbouwforum.nl/threads/futaba-t18sz-en-fasst-ontvangers.273959/
Ik wil het verhaal niet moeilijker maken, maar die Dymnd ontvangers zijn volgens mij iets apparts. Ik heb zelf de R-600 FHSS (2 zelfs) maar dit zijn geen FHSS ontvangers maar Fasst ontvangers.... Geen idee waarom er FHSS in de naam staat als ze eigenlijk Fasst zijn. Ik heb ze gebonden aan mijn T8FG (die alleen maar Fasst heeft) en dat werkt goed. Wellicht werken ze ook op FHSS, dat kan ik niet testen, maar het lijkt me niet. Dus voor mij zijn deze ontvangers een beetje een vraagteken, maar ze werken bij mij goed op Fasst.
het grapje wil, dat bij alle (futaba) zenders die ik tot nu toe een bind procedure heb gedaan, ik nog nooit een foutmelding heb gehad. echt, nooit. wel dat het niet lukt. te herkennen aan het rode lampje op de ontvanger (origineel futaba) maar, de zender gaf nooit een fout. de zender melde gewoon helemaal niets. wat wel kan, en waar ik wel eens een fout heb gehad, is bij het aanmelden van een telemetrie functie van een ontvanger. volgens mij, dacht ik.. dat de oude 14 multi protocol is (als 1 van de laatste) en dat hij telemetrie heeft. zit je geen telemetrie te koppelen met een anti telemetrie ontvanger? voor telemetrie binden moet je wel een aparte actie in de zender doen.. voor normaal binden (zonder telemetrie) moet ik in 1 menu ergens (lang geleden, menu parameter of zoiets) het zendprotocol wijzigen (als dit verkeerd staat) zender uit, aan. knopje op de ontvanger induwen (en ingedrukt houden), stroom erop, en binnen 5 a 10 sec wordt het lampje groen. in de zender hoef je normaal niks te doen, verder. zit je op een verkeerd protocol, bind de ontvanger gewoon niet. maar dat zie je alleen aan het rode lampje, geen foutmeldingen op de zender.
Inmiddels doet de zender wat er van 'm verwacht wordt . In gezamenlijk overleg hadden Norwen en ik afgesproken, dat-ie nog een keer bij mij op tafel zou komen om naar dit verschijnsel te kijken. Nu blijven software-perikelen mij verbazen en soms ook zenuwachtig maken, dus het is maar goed dat ik er in het grijze verleden na een omscholing toch maar niet mijn beroep van heb gemaakt. Ook hier weer zoiets, waarbij je alleen maar kunt beredeneren of je blijven afvragen wat het was waarover het apparaat ontevreden was. Er stonden twee modellen in de zender geprogrammeerd en er waren twee nieuwe modellen aangemaakt. Alle 4 modelgeheugens stonden op FASSTest 14. Nu is het bij dit protocol zo, dat je bij het binden met een ontvanger alleen de zender in bind-mode moet brengen, waarna het ID van de ontvanger in beeld verschijnt als de bindprocedure is gelukt. Bij een nieuw aangemaakt model is dit uiteraard niet het geval, dan krijg je op die plaats alleen liggende streepjes in beeld, maar dit start wél op met het protocol, dat je het laatst hebt gebruikt. Nadat ik zelf ook weer nieuwe modellen had aangemaakt kreeg ik precies het zelfde verschijnsel als Norwen. Het apparaat beweerde niet te kunnen wisselen met als mededeling 'ch is lacking' en dat deed-ie bij elk nieuw aangemaakt model. Pas na het lumineuze idee om eens te kijken wat het apparaat er van vond als de modulatiesoort van modelgeheugen 1 werd gewisseld was het probleem opgelost. Dat wisselen ging wel en nu was dat opeens ook op alle modelgeheugens mogelijk. Ook nadat modelgeheugen 1 weer op FASSTest 14 was ingesteld, het ontvanger-ID toonde en (als laatste modelgeheugen) was geactiveerd. Nieuw aangemaakte modellen startten nu ook weer op in FASSTest 14, maar konden nu wel normaal wisselen. Uiteraard is het duidelijk, dat de zender niet kon wisselen omdat-ie een gegeven miste, waaruit bleek in welke modulatiesoort 't ie stond. Nu heeft elk modelgeheugen z'n eigen record, dat pas wordt opgediept als het wordt geselecteerd en in het actieve geheugen wordt geplaatst. Daarbij behoort ook de modulatiesoort. Bij het aanmaken van een nieuw model wordt dat blijkbaar ergens anders vandaan gehaald, mogelijk staat ergens geparkeerd wat het laatst gebruikte was of het wordt geleend uit het record van het laatst gebruikte geheugen. Ik snap dan echter niet hoe de fout op alle reeds aanwezige modelgeheugens kan verdwijnen als alleen dat laatst gebruikte geheugen wordt veranderd. Normaal gesproken wordt in service zoiets opgelost door een systeem-reset uit te voeren omdat dit het snelste werkt, maar dat is vaak te makkelijk. Meestal ga je eerst wat knopjes indrukken en kijken of je het ook zó kunt oplossen en ben je uiterst tevreden als dat lukt.
Tja, bedenk het maar, soms is de logica in de wereld van electronica een beetje te simpel om aan te denken, ik ben in ieder geval blij dat het opgelost is Met dank aan Jan! Gr.Jan
