Posts by TMS

    ...diese Kabel verwende ich auch gerne. u.a. mit den Powerbox-Crimp Kontakten.

    0,5² ist für diese Crimps (bis AWG22) schon fast zu viel. Geht aber aufgrund der dünnen Isolierung gerade noch reproduzierbar, wenn der Crimpdruck nicht zu hoch ist; sonst wird der ganze Kontakt verformt. Mit einem Crimp-Automaten sieht das natürlich wieder anders aus, aber wer hat den schon ;-)


    Wichtig ist immer beim Herstellen von Crimps das die Litzen nicht vorher "verdrillt" werden und nicht mit dem Hautfett etc. in Berührung kommen.


    Wäre dennoch mal an einem Foto eines Crimps von dir zwecks Vergleich interessiert - insbesondere da du ja schon einge gemacht hast. Routine/Übung macht da viel aus. Hast du mal nach einer Profizange Ausschau gehalten ?


    Besten Gruß

    Thomas

    Guten Morgen Oliver,


    interessante Anwendung; wollt ihr etwas simulieren bzw. autonome Bootssteuerung untersuchen ?


    Sehe ich genauso wie Dirk. Den Empfänger in ein (wasser)dichtes Gehäuse setzen (z.B. kleine VT-Dose von Spelsberg etc.) und am angedachten Empfangsort montieren und nur die Antennen vorteilhaft ausgerichtet herausschauen lassen. Ein Kabel mußt du von der Plattform zur Brücke ja ohnehin laufen lassen. Bevor du dich mit "low-loss HF Kabel" rumschlägst, ganz zu schweigen von dessen Kontaktierung, ist das mit Sicherheit der bessere Weg...


    Als Datenkabel würde ich dünne Sensor-Leitung (PU) aus der Industrie verwenden, z.B. von PHOENIX Contact, dass ist nicht empfindlich und dort kannst du auch die Powerbox "JR" Stecker ancrimpen...


    Viel Erfolg & Gruß

    Thomas

    ...das war mir soweit bereits bekannt, nur fehlte mir immer der Backslash auf der Bildschirmtatstur um damit zu spielen. Ist der inzwischen eingebbar ?


    LG

    Thomas

    ...das haben wir auch schon beobachtet. Bei großer Abweichung stecken wir die Akkus an der V3 zwischen den Flügen einfach um. Wir kommen gut an die Steckverbindungen dran, die wir zum Laden ohnehin trennen müssen. Klar wäre eine gleichmäßige Entladung angenehmer, aber wir können uns mit dieser Tatsache arrangieren. Redundanz und damit Safety First sind für uns von großer Bedeutung. Und die CORE/ATOM Telemetrie der V3 nutzen wir in jedem Modell, wo wir diese eingebaut haben. Das ist schon eine super Sache. FÜr eine "V4" wäre für uns dann noch die Temperatur interessant um Rückschlüsse auf die Belastung der Weiche ziehen zu können...


    LG

    Thomas

    ... alle "freien" Entwickler können bei Interesse die Spezifikationen von Richard Deutsch bekommen; da hat man sehr viele Möglichkeiten seine Einstell-Menüs umzusetzen. Eine vorbildliche Telemetrie-Protokoll-Implementierung wie ich finde. Und diesen Zirkus mit den *.bin Files/Dateien wie bei Jeti gibt es nicht :-)


    "Spirit" und Weitere könnten also sofort loslegen und nativen Support für CORE / ATOM in deren Produkte einbauen...


    LG Thomas

    ... und das interne GPS ist ebenfalls nicht aufgeführt, dass wäre für "Look & Find" (Modellbergung) notwendig sowie das automatische setzen der Zeit.

    Vermutlich gibt es noch weitere kleine Unterschiede, die im Detail liegen ... Wir dürfen gespannt sein bzw. bleiben :-)

    Hallo Christian,


    sprich mal den Richard an, er ist sehr kooperativ. Du kannst die Informationen gegen NDA von ihm erhalten. Im Gegensatz zu dem "Theater", das Yeti veranstaltet (keine vollständigen Informationen, z.B. Thema *.bin" Dateien) bekommst du hier Zugriff auf alle Möglichkeiten, die der P²-Bus bietet; was die von dir angestrebte Sensorentwicklung angeht.


    LG & viel Freude bei der Entwicklung


    Thomas

    Hallo Reinhard,


    ich fliege kein OLC, aber so wie ich es verstehe, benötigst du ein Stück Software an Boden, dass die vom GPS gemeldeten Positionen mit Karten.Koordinaten ("das Dreieck") vergleicht und entsprechende Ausgaben vornimmt. Bei BAT gab (gibt?) es den Sky Navigator, ansonsten gibt es für CORE (und andere Systeme) Sensoren samt passender Software zur Auswertung von Positionsdaten hinsichtlich des "Dreiecks"-Kurses. Wurde hier im Forum schon besprochen im Rahmen des GPS-Dreieck-Fliegens. Hersteller ist: https://www.rc-electronics.eu Das scheint recht fortschrittlich zu sein, da es auch senderseitig von der Ausgabemöglichkeit der CORE Telemetrie-Daten gebrauch macht. Schau doch dort mal nach, ob es das ist, was du suchst.


    Mehr kann ich dir aber leider nicht sagen, da ich die Produkte nicht verwende. Aber andere Benutzer hier, wie z.B. TK7, scheinen das im Einsatz zu haben. Evtl. können sie weitere Fragen beantworten.


    Ich wünsche dir viel Erfolg bei der Umsetzung, Kannst ja zu gegebener Zeit mal deine OLC/CORE Erfahrungen schreiben.



    LG


    Thomas

    Hallo zusammen,


    es liegt m.E. nach kein Fehler im CORE vor, was den Sensor-Scan angeht. Entweder ist der Sensor schnell genug und kann antworten oder nicht...

    Wenn man hohe Adressen verwendet, sollte auf jeden Fall genug Zeit sein. Das sieht man ja an den Adaptern für JETI und MPX und vielen anderen Sensoren, die damit zurecht kommen...


    Vielleicht wäre es möglich, den Sensor-ReScan via Short-Cut Icon vom Home-Screen aus zu ermöglichen. Einmal tippen ist sicher zumutbar... und das Problem wäre aus der Welt.



    LG


    Thomas

    ...Ich habe ganz vergessen, auf die Frage von Modell13 zu antworten:


    Wir bereiten derzeit einige Sensoren für den CORE vor. Für eine Web-Präsenz fehlte uns bisher die Zeit, die stecken wir aktuell in die Entwicklung ;-)

    Wir werden das dann auch hier im Bereich "3rd Party" bekannt machen.


    Wer jetzt schon Interesse hat, kann mir gerne eine PM über das Forum schreiben. Wir antworten zeitnah und gerne.



    Herzliche Grüße


    Tim & Tom

    Abschließende Bemerkung von uns: Tim und ich können da keine Lösung anbieten, dass kann nur der Entwickler des Sparrow (Ausschlußverfahren).


    Tk7: Wir können also keinen Knoten durchschlagen noch können wir überhaupt einen sehen. Auch sehe ich keine einseitige Betrachtung von unserer Seite, wir stehen in diesem Fall nämlich weder auf der einen noch auf der anderen Seite, sondern außerhalb...


    Wir wollten nur kurz zeigen, dass der CORE die richtige Darstellung beherrscht. Und das auch nur, weil wir uns gerade im Rahmen der Entwicklung mit dem Thema GPS und CORE beschäftigen. Es sollte nur helfen, die Sache besser zu verstehen. Die Tatsache, dass das Sparrow System die GPS Daten auf den eigenen Gerät (Snipe?) richtig anzeigen kann, muss nicht zwangsläufig bedeuten, dass diese Daten auch richtig zum CORE-Interface für die Darstellung gesendet werden.

    Das können wir als Entwickler definitv beurteilen ;-) Sicher wäre in dem Fall nur, dass der GPS Empfang funktioniert und GPS-Daten im Downlink ankommen.


    Haltet uns bitte auf dem Laufenden, wenn es hier neue Erkenntnisse gibt. Wir lernen ja immer gerne dazu.


    Bis dahin alles Gute

    Tim & Tom

    Hallo Gerd,

    ich verwende keinen Sparrow bzw. verwandte Produkte dieses Herstellers. Jedoch befassen wir uns gerade auch mit der Integration von GNSS/GPS in die CORE-Telemetrie, was inzwischen gut funktioniert. Der CORE verändert nicht die Daten, die er vom Sensor bekommt; er stellt sie lediglich in der gezeigten Formatierung auf dem Display als Widget da. Von daher würde ich vermuten, dass als Position tatsächlich "Null" geschickt wurde oder ein ungültiger Wert, der den CORE dazu veranlasst, alles mit "Null" anzuzeigen. So oder so eine interessante Beobachtung von dir. Solltest du noch weitere Erkenntnisse dazu sammeln, schreibe diese bitte hier.


    Danke & Gruß

    Thomas

    Hallo Roman,

    der Sensor muss die Sprachen bereitstellen. Der Sensor kann auch vom Sender erfahren, welche Sprache dort eingestellt ist, muss diese aber nicht zwingend benutzen, sprich man kann die Sprache auch im Sensor-Menü einstellbar machen, was Vorteilhaft sein kann.

    Eine "Text-Eingabe" für den Sensor vom Sender aus ist aktuell nicht vorgesehen. Man könnte sich aus Entwicklersicht einen Work-Around dafür programmieren, ist aber etwas umständlich. Wenn man aber nicht zu häufig Daten eingeben muss, wäre es eine Überlegung wert. Wir werden das mal ausprobieren...


    LG

    Thomas

    Hi Pat,


    that´s exactly the reason why we decided to make the displayed units selectable within the setup menu ouf our TTM FlowSensor and therefore independed from the main setting in the CORE. Just ask the vendor of the sensor if he is willing to implement this choice... CORE telemetry is very flexible and offers many choices to the programmer.


    have a nice day

    Thomas

    ... really ?


    I would tend to disconnet the power supply pin from the tacho lead, which usually powers the optional 4-digit RPM display of the ignition. (Which can be bought as an optional part from GP / DLA ...) Don´t really know if the ignition likes to get fed backwards on this power output ?


    I think all the SS Pro needs is signal and GND from that tacho lead of the ignition. Or did I get something wrong here ?


    At least, this config works for us (DLA64 / DLE128), aside some EMC-related problems which we have to discover when there is time for it...



    all the best


    Thomas

    ...wenn alles nichts helfen sollte, kann ich dir unseren TTM USB SIM Adapter für CORE ans Herz legen. Da hast du gleich auch noch Telemetrie mit dabei. Der funktioniert auch zusätzlich mit Phoenix R/C, RealFlight v9x und weiteren SIMs. Bei Interesse schreibe mir einfach eine PM. Dann sende ich dir vorab mal die Bedienungsanleitung. (Unser Adapter wird am P²-Bus des Powerbox-Empfängers betrieben und versorgt sich und den Empfänger mit Strom.)


    LG

    Thomas

    Hallo Marcel,

    ja genau. Durch die Verwendung von S.BUS ist man hier bei der Wahl des Schüler-Senders ziemlich frei, solange dieser ein S.BUS Signal liefern kann. Man benötigt also nicht zwingend zwei CORE für den L/S Betrieb. Sollte es mal ohne Zusatzhardware (hier den S.BUS fähige Empfänger) funktionieren, wird man aber in diesem Fall nicht um den Einsatz zweier CORE herumkommen. Daher ist die jetzige Lösung ideal. Wenn tatsächlich zwei CORE verwendet werden sollen, könnte der kommende PBR-5S "Mini" ein guter Zuspieler sein. Strom zum Betrieb des Schüler-S.BUS Empfängers wird ja an der PPM/Servo-Buchse des CORE bereitgestellt. Der Verkabelungsaufwand ist so also minimal. Nur sollte man darauf achten, dass die Antenne(n) des Schüler-S.BUS Empfängers möglichst weit von den Antennen des CORE Lehrer-Senders entfernt sind. Insbesondere wenn dieser auch sendet (Telemetrie).


    Schönen Abend

    Thomas

    Hallo Julius,

    das Eingangssignal vom Schüler-Sender muss als S.BUS Signal vorliegen, z.B. aus einem Empfänger, der am Schülersender gebunden ist. Dieser muss dann einen S.BUS Ausgang haben. Dieser wird mit einem "Patchkabel" mit der PPM/SERVO-Buchse des CORE verbunden. "Detektieren" untersucht dann den seriellen Datenstrom vom "Schüler-Empfänger" (S.BUS) und du kannst die Funktionen zuweisen....

    LG

    Thomas