Topic voor : Servonaut, Beier-USM-RC en MFU en alle Besturings en Verlichtingssystemen.

Ik heb de kabel set ook liggen, vanmorgen niet gebruikt.
Heb de handleiding niet gelezen maar is de enige reden die ik kan bedenken dat die sd kaart het niet doet in de SFR. Mijn laptop leest het kaartje gewoon uit en kan het project dat er op staat bewerken en weer opslaan.
 
Ik heb dat geloof ik al eens eerder ergens aangegeven dat de kaart een SDHC type moet zijn. Deze kaarten gaan maar tot maximaal 32Gb. De SDXC kaarten gaan vanaf 32Gb en zijn dus niet geschikt. Beier zou dat wel iets beter kunnen specificeren, dan weet je beter welk type kaart je moet hebben.

Hetzelfde geldt ook voor bijvoorbeeld mijn Jeti zender, wellicht bij Graupner en FrSky ook. Ik gebruik de Industrial kaart van Kingston, deze zijn beter bestand tegen temperatuurschommelingen en vocht: https://www.kingston.com/en/memory-cards/industrial-grade-microsd-uhs-i-u3

A
ls je deze formatteert als FAT32 werkt die als SCHC, als je formatteert als ExFAT werkt die als SDXC kaart, toekomstbestendig dus.
Onder andere hier verkrijgbaar:
https://www.megekko.nl/product/2091...flashgeheugen-16-GB-MicroSDHC-UHS-I-Klasse-10

https://www.distrelec.nl/nl/geheuge...=Kingston&filter_Capaciteit~~GB=16&track=true

https://www.hardwarewebwinkel.nl/op...ston-industrial-microsd-memory-card-16gb.html
 
Is ook zo, maar zie zo’n kaart nog te vinden, en zo ja, dan is het prijsverschil hooguit een paar euro’s.
Dat is rare marktwerking, ze worden nauwelijks nog verkocht.

De Beier is een kwaliteitsproduct, dat zit waarschijnlijk een leven lang in het model, de aanschaf van de kaart is ook eenmalig, is niet onoverkomelijk lijkt mij.
 
Raadsel blijft waarom de meegeleverde SD kaart in de SFR1 ( wat uiteraard het juiste type zal zijn) niet functioneerde in eerste instantie.

Of is er bij het programmeren iets niet goed gegaan, en is het een gebruikersfout .
"Het oorspronkelijke kaartje (32GB) bevatte heel veel bestanden maar niet het project (.sfr bestand) en de geluiden. Nadat deze bestanden er op waren gezet werkte alles gelijk."
 
Als bij ons op werk iets niet werkt in de software en we de support bellen zit de fout vrijwel altijd tussen het toetsenbord en de rugleuning :frustie:
 
Gerard had twee SD kaartjes en zijn auto met SFR mee.

Als eerste heb ik de SD kaartje van Geraard in mijn SFR gestopt. Bij mij gaf de SFR dezelfde foutmelding. Mijn kaartje in de SFR van Gerard deed het wel.
Hiermee hadden we uitgesloten dat het aan de SFR zou kunnen liggen.

Na wat speuren bleek op het ene kaartje het project te staan met alle geluiden, zou het dus moeten doen. Ik vermoed dat dit kaartje niet herkend word door de SFR. Mogelijk door de grootte (64GB).

Het oorspronkelijke kaartje (32GB) bevatte heel veel bestanden maar niet het project (.sfr bestand) en de geluiden. Nadat deze bestanden er op waren gezet werkte alles gelijk.
Niets aan toe te voegen :-)
 
Hallo,
Ik heb geprobeerd het Robbe multiswitch signaal via de Sbus aan te bieden op de Beier USM-RC3 echter hij luistert er niet naar, kan het zijn dat dit signaal uitsluitend via de prop ingang aangeboden kan worden?

Sbus signalen op de gewone prop# kanalen gaat verder prima
 
Main probleem is om er de juiste timing in te krijgen, normaal tap je een sync signaal af bij Futaba zenders…
Hierop reageerde de multiswitch op tijd en weet de decoder wanneer er een sequence compleet is.
Dit was een rede dat alleen destijds Jeti hieraan kon voldoen, met de nodige settings.
Ik denk dat je meer bereikt met je eigen switch Sbus setup, daar dit minder tijdgevoelig is.
 
Jeti (LBT protocol) verliest wel eens een overdrachtssignaal, dat risico heb ik niet omdat dit een zelfgegenereerde Sbus uitgang is van de Teensy. Zowel de volgorde als de pulslengte is volgens mij ook correct maar hij pakt hem niet via de Sbus ingang van de beier. Ik zal eens controleren of hij hem wel op de aparte prop-3 ingang als PWM accepteert.

Maar de basisvraag is dus of het multiswitch signaal van Robbe ook via de Sbus geaccepteerd wordt door de Beier of dat het gewoon niet kan wat ik wil :-(

De Sbus van de ontvanger lees ik uit met de Teensy om de 18 switches die over kanaal 13 t/m 16 binnenkomen te decoderen, dat werkt goed, ook het omzetten naar 14 propkanalen (kanaal 1 is gereserveerd voor het motorgeluid en kanaal 5 gebruik ik voor het volume) in SBus gaat goed en de beier lust dat ook.

De schakelaars waar geen geluid bij nodig is sturen via de SPI poort een leddriver aan om de verlichting te regelen dus het is in principe geen probleem dat de beier niet alle schakelaars uit kan lezen maar het zou leuk zijn als de beier alle 16 3-standenswitches uit kan lezen als multiswitch via de Sbus.
 
Laatst bewerkt:
LBT of andere protocollen staan hier los van, de hele timing is er niet meer, zoals het zijn moet.
Als een digitaal pakket niet aankomt, de ontvanger spuugt dan zijn laatste waardes nog een keer uiy, dit geeft een niet synchroon signaal.
Hierdoor is de decodering niet meer juist te krijgen.

Edit:
Jeti had met een bepaalde firmware de optie om de timimg door de Tranciever te laten bepalen, ipv bijv. Een vaste 18MS.
 
Een pulstrein moet toch ook weer gedecodeerd worden aan de ontvangerzijde?
Dit doet de Beier in dit geval, dan kun je geen Sbus gebruiken volgens mij, want de Beier moet zoals @Mark300 schrijft in Nautic modus staan.

Het is of/of, niet en/en, dus of nautic/multiswitch, of Sbus overdracht tussen ontvanger en Beier.
 
De timing op 20ms kan idd een punt zijn maar de overdracht van zender naar ontvanger gaat prima en is getest. Dat komt omdat de overdracht van zender naar de ontvanger niet afhankelijk is van een pulstrein maar in 1 pakketje verpakt zit. (kanaal 13 t/m 16 elk 5 switches per pakketje, de 2 2standen schakelaars worden 2x verstuurd omdat ik dan 4 identieke coderingen binnen krijg i.p.v. kanaal 13 en 14 5 switches en kanaal 15 en 16 4 stuks).

De Decoder maakt een nieuw SBUS signaal waarbij ik op kanaal 1 de gasknuppel doorgeef en die komt iig goed aan. Ook als ik via een schakelaar een variabele waarde doorgeef op de overige kanalen (1000 - 1500 - 2000 us) begrijpt de Beier dat en kan ik op ieder kanaal een schakelactie uitvoeren. Ook in de diagnostic mode is dit goed te zien.

Het enige wat nog niet werkt is het multiswich signaal (1e puls = 935us; volgende 8 zijn 1000, 1500/ of 2000us) op SBUS kanaal Prop#3 en evt #4. Ik geef idd ook aan dat de Nautic module op prop#3 zit maar er staat echter ook "Prop#3 (X2/3)" en ik trek de info voor prop#3 in dit geval uit de SBUS. In De beier staat ook nadrukkelijk dat Prop# 3 niet gebruikt kan worden in het tabblad Proportionele kanalen omdat deze voor de nautic switch gereserveerd is (uiteraard alleen wanneer de nautic module geactiveerd is)

Maar ik ga eerst eens een SBUS>>PWM decoder aansluiten om op die manier kanaal 3 en 4 als PWM aan te bieden op de Beier, als dat niet werkt moet ik mijn pulstrein beter opbouwen, als dat wel werkt denk ik dat het idd niet via de SBUS aangeboden kan worden en zal ik 2 extra uitgangen op de decoder moeten gaan gebruiken voor de betreffende PWM signalen.
 
Laatst bewerkt:
Nog sterker via de Sbus kan ik al 2x14 functies aansturen :-)
En die extra kabel is idd het alternatief wanneer de nauticmodule in de beier idd niet via de Sbus aangestuurd kan worden.
Momenteel werk de nautic module ook nog niet via de extra kabel met daartussen een Sbus >> Pwm converter. Binnenkort maar eens verder knutselen.
 
Het is of/of, niet en/en, dus of nautic/multiswitch, of Sbus overdracht tussen ontvanger en Beier.

Dat is inderdaad het antwoordt op mijn basisvraag :).

Conclusie is dat ik het niet via de nautic input ga doen maar via de prop# kanalen van de Sbus ingang houd, geeft ook ruim voldoende mogelijkheden en is bovendien veel sneller.

Ik kan wel 2 extra poorten gebruiken om het Robbe signaal uit te sturen maar er is geen noodzaak voor aangezien er 15prop kanalen (plus 1 gereserveerde voor het motorgeluid) via de SBus uitgelezen kunnen worden en die kunnen ook nog eens op 100% en 50% aangestuurt worden voor aparte functies.
 
Back
Top