Hi Ingo,

zum HOTT Protokoll gibt es ja genügend Infos so im Netz, wollte jetzt nicht unbedingt bei Graupner ne Anfrage wegen dem Protokoll stellen da man da ja dann ein NDA unterschreiben muss, und sowas macht mir immer Probleme in der Magengegend
I2C dürfte es bei Spektrum sein wenn ich mich nicht irre, die nennen das dann einfach x-Bus glaub ich. Graupner fährt ja fast normales RS232 mit 19k2 Baud 8N1 und 2ms zeit zwischen den Bytes, sowie zusammenfassung von Sende und Empfangsleitung.
Hab mich eigentlich für das ganze nur interessiert, weil ich echt günstig an ne mc32 gekommen bin, vorher hatte ich ne Aurora 9 und da konnte man auch schon viel basteln

Noch mal zu Graupner wenn ich da ein NDA unterschreibe darf ich nichts von dem was ich rausgefunden habe und gebaut habe preisgeben, das ist auch blöd! Bau ich nämlich mal ein paar Sensoren und geb mal einen ab, z.B. im gegenzug zu ein paar Rotorwellen [wegen dem Gewerbe und so] dann dürfte ich das gar nicht. Und wenn ich es so zur Verfügung stellen wollte das es nachgebaut werden kann bin ich auch mit dem Klotz bzw. NDA am Bein richtig dran gehindert. Bei reverse Enginiering, durch
einfaches Abhören und dublizieren sieht das anders aus, solange ich es nicht kommerziell nutze. Deswegen die Rotorwellen. Ich möchte ja nix drann verdienen einfach ein wenig Spaß beim Basteln haben und noch dem ein oder anderen eibne Freude machen können mit nem kleinen Sensor den er leider so von Graupner im Moment nicht bekommt.

Ich selber brauch ja nur maximal 3 davon da ich im Moment nicht mehr Fluggeräte plane, eins kommt in den Rex und das andre in den Protos (Wenn der fertig ist) und das dritte ist zum spielen. Und wer eins will kann ja fragen! Da fallen dann schon welche ab.

Grüße,
Stefan

Ach ja und Updates sollen ganz bequem für die Sensoren über USB gehen, das ist einfach mit dem verwendeten ARM Falls sich mal was am Protokoll ändert

ingo_s hat geschrieben:Hott hat leider im Gegensatz zu MPX je Sensor ein proparitäres Datenformat das dummerweise auch dem Sender bekannt sein muß.

Jep, zumindest beim Binärformat wenn ich es richtig verstanden habe.

Ich habe mich auch ein paarmal am Kopf gekratzt, als ich die Spezifikation gesehen habe... da hätte man einiges schöner machen können, aber wahrscheinlich ist das alles unter ein wenig Zeitdruck entstanden.

Z.B. hätte man sich überlegen können, dass bei der Initialisierung eine Art "Inventory" durchgeführt wird, welche Sensoren überhaupt vorhanden sind. Diese könnten dann zurückgeben, was für Daten sie überhaupt liefern etc. pp...

Naja, vlt. bei V5

Grüße
Markus

Also zum Thema Protokolle, es ist manchmal sehr schwer zu sagen was sich die jenige Entwicklergruppe dabei gedacht hat und vor allem was sie für vorrangige Ziele verfolgt hat.

Binärprotokolle mögen abschrecken sind aber eine rein text basierenden Protokoll überlegen!
Also mit der Entwicklung von Protokollen kenne ich mich aus, mache so was ziemlich oft in der Arbeit. Vor allem für schnelle Messanwendungen. Und zumindest das Graupner und Spektrum Protokoll ist da ganz im rahmen eines einfachen unaufwendigen Protokolls gehalten, also eher nicht sehr kostenintensiv. (Ich persönlich hätte es zwar anders gemacht aber naja ist ja nicht von mir ) Denn alles was man da reinpackt muss man auch Debuggen und das kostet viel viel Zeit! Das MPX Protokoll hab ich mir noch nicht angesehen, da kann ich nix dazu sagen.

Und das mit den Protokollen ist ja so das man nicht will das der Chinese (nix gegen die Chinesen jetzt im allgemeinen!) das ganze ja nicht gleich nachbauen soll blos weil es offen ist und man selbst dann keine Sensoren mehr verkauft.
Dort wo ich platz hab bau ich auch weiterhin Graupner Sensoren ein! Daran wird sich nix ändern! Mein RC Car wird dann nämlich die Orginalen sensoren bekommen, da ist nämlich massig platz drinnen.

Grüße,
Stefan

@Stefan,
Graupner und MPX sind sehr freizügig mit der Herausgabe des Sensor Protokolls. Die NDA bezieht sich auch nur auf das Protokoll und soll nicht weiter gegeben werden. Zumindest MPX hat nichts dagegen auch Source Code, der das Protokoll umsetzt zu veröffentlichen. MPX willl hat wissen, wer das Dokument hat und schickt auch automatisch Updates an die Bezieher raus. Ich denke, bei Graupner wird das ähnlich gehandhabt. Mit den Chinesen hat das nix zu tun nach meiner Ansicht, dazu sind alle Protokolle zu einfach gestrickt. Auch Sensor Fremdanbieter sind gut für das eigene Produkt.

So, gleich gehe ich erst mal meinen Protos lüften

Grüße
Ingo

Ingo, hast Du schonmal ein Update der "Doku" bekommen? Ich hatte mal die Specs bei Graupner angefordert und mit dem Stand 1. Hälfte 2012 bekommen.

Ich finde ja sie sollten eine Mailingliste o.ä. aufsetzen... so könnten sich auch Entwickler austauschen.

Das "NDA" finde ich ein bisschen überflüssig, da die meisten Erkenntnisse mittlerweile sowieso ausgetüftelt wurden und im Netz nachzulesen sind. Graupner sollte versuchen die Kundenbindung dadurch herzustellen, das sie z.B. vernünftige BL-Regler mit einer HoTT Sensorschnittstelle im Programm haben.

Grüße
Markus

Soweit ich weis sollen die Regler kommen.

Kann ich bestätigen. Graupner steht da "erst am Anfang", so die Wortmeldung.

Zum Thema: Mich interessiert vor allem die Temperaturmessung an 1-2 verschiedenen Plätzen, 2 Werte kann die Telemetrie ja "verdauen".
Ich habe mir den UniSens-E besorgt, der zu sehr angenehmem Tarif und bei minimaler Größe alles kann - ausser eben Temperatur.
Strom bis 150A, Drehzahl ohne Extra-Sensor, Kapazität, Vario, Spannung. Achso, Einzelzellen kann er auch nicht, wäre sicher auch
interessant. Nicht lebenswichtig, aber interessant.

Arduino hab ich auch noch rumliegen, Breadboard auch, aber ich bin noch nicht dazu gekommen, mir auch schon Erkenntnisse anzueignen.
Drum wär ich "entzückt", mich irgendwo dranhängen zu können.

Dann lass ich mir mal das NDA von Graupner kommen und schau mir das mal genau an.

Kenne sowas ja bisher nur aus der Arbeit wo wir unter anderem Raumfahrttechnik machen und da sind die NDAs echt übel, da sag ich immer man kommt günstiger weg wenn man dem Teufel seine Seele verkauft als das NDA zu unterschreiben

Aber danke mal so für eure Antworten zu dem Ganzen.

@Sniping-Jack
Mit dem Arduino zeug mach ich eigentlich garnix, das ist mir persönlich viel zu weit weg von der Hardware. Ich kenn das halt so aus der Arbeit unteranderen. Das soll nicht heißen das ich das schlecht finde, das ganze ist genau richtig für viele Einsteiger!
Vor allem es hällt einen von den Ganzen Hardware spezifischen Sachen fern die mal gerne sehr kompliziert werden können. Würde auch keinem Anfämger raten auf einen ARM anzufangen das endet nur in gefrusteten Stunden ohne irgend ein Erfolgserlebnis.

Falls es aber Fragen geben sollte zu grundlegenden Dingen wie das Programm so auszusehen hat, da kann ich gerne helfen. Aber in Arduino müsste ich mich auch erst einarbeiten um da genau durchzublicken. Aber wo ich auch helfen kann ist Analog Technik und Digitaltechnik, da bin ich gerne bereit jegliche Frage zu beantworten auf die ich auch eine Antwort weis. Ich geb auch zu wenn ich keine Antwort hab, kann auch vorkommen zu irgendwelchen Spezialsachen

Wie gesagt ich werde alles für euch zur Verfügung stellen damit es nachgebaut und verändert werden kann!

Grüße,
Stefan

Hey, klingt doch super!
Das "für Künstler und sonstige Amateure" war dann auch das, was mich zum Arduino zog.
Ich kann zwar(halbwegs) programmieren, aber nicht (mehr) coden. Ich brauch also irgendwas, das easy und unkompliziert ist.
Wenigstens am Anfang. Und wenn ich mal angefangen hab, kommt sicher ein Schwall Fragen.

PS: Ihr dürft übrigens das Prädikat weglassen und mich "direkt" anreden - "Jack" oder "Guido" ist doch viel kürzer.

Da ist das Arduino wirklich gut geeignet, damit haben so manche die ersten Schritte mit gemacht und man macht damit sehr schnell Fortschritte! Man kann auch größere Sachen damit machen, zumindest scheint es dafür geeignet. Aber das sind eher so erste Einschätzungen. Wie gesagt mit den Arduino hab ich noch nix gemacht. Da liebe ich einfach die ARMs zu sehr, naja aber mal überlegen ob man doch mal fremd geht
Der Code ist an C++ so wie es aussieht angelehnt, das sollte dann das adaptieren meines C codes sehr erleichtern.

Ins coden kommt man schnell wieder rein wenn man es schon mal gemacht hat, is so wie Farrad fahren.

Aber fragen einfach stellen! Manchmal dreht man sich nämlich wirklich im Kreis und findet den Ausgang nicht mehr Ging mir auch schon so, dann einfach ne kleine Frage und einen Tipp bekommen und man erkennt worann man nicht gedacht hat

Grüße,
Stefan

Die Arduino Umgebung habe ich mir mal kurz angesehen, für unsere Anwendungen ist der größte Nachteil das die einzige vorhandene serielle Schnittstelle durch die IDE schon belegt ist. Einge haben es schon mit einem Software UART versucht, beim MSB mit 38400kBd wird es aber eng und alle anderen ISR's müssen "non blocked" ausgeführt werden.

Ich gehe jetzt auch auf die ARM Schiene, erst mal mit einem STM32F103 den ich Anfang des Jahres als den für meine Sensoren am besten passenden ausgesucht habe.
Sensor Prototyp ist schon bestückt und die Anbindung mit der Coocox CoIDE klappt auch.

Grüße,
Ingo

Naja... ob ARM oder AVR... ich denke bei der gestellten Aufgabe, ein paar Messwerte zu übermitteln, langweilen sich beide MPUs (bei geschickter Programmierung).

Der ARM scheint mir ein bisschen wie mit Kanonen auf Spatzen Aber hauptsache funktioniert...

Grüße
Markus

Zu CooCox kann ich dir sagen, das wenn du das STM Discovery mit dem STLink V2 debugger hast kannst du das als SWD Debugger für alle andren Cortex Prozessoren mit SWD Schnittstelle hernehmen!
Ich nehms für den NXP her da ich im Moment noch jede Menge von denen hier rumliegen hab. Der ST hat 12 bit ADCs, was für Batteryspannungen nicht unbedingt nötig ist da scheinbar Graupner eh nicht so genau auflösen kann soweit ich da informiert bin.

Bin noch ein bischen davon entfernt hier was zum Testen zu haben, da ich zur Zeit kaum Zeit dazu finde

Grüße,
Stefan

Zu Früh abgeschickt.

Die ARMs sind meist günstiger als die lahmen Atmels