speziallogger für den jive

[gecko_749]

Moin,

ich würde mir ja auch gern mal ein Log ansehen.

Muß ich mich deshalb jetzt im rechtsschreibforum anmelden oder ist jemand so freundlich und stellt hier auch mal eins zur Verfügung ?

Eine Anbindung der Daten an die telemtriefähigen Anlagen wäre für die Nutzer von Jives sicher hochinterressant.

Wobei ich da zunächst an MPX und Jeti denken würde. MPX gibt die Spec raus und Jeti ist bekannt und wenn man freundlich fragt und erklärt was man vorhat erhält man von denen auch ein ok. Das ist für ein Produkt das verkauft werden soll ja auch nicht gan unwichtig.

Gruß

gecko

 

[Gast_28792]

Ich tu' die Bildchen aus RCH gleich hier rein. Da mache ich es mal nicht auf meinen Webserver sondern als Attachment, und schon..., bingo.

Anbei ein Bildchen zum "Fullset", für Leute, die auch den Openformat-Livestream, den der Datenlogger on top liefert (erstmal "(J)Log" getauft), in LogView auf der Werkbank darstellen wollen. Das werden aber sicher Wenige sein.

Das zweite Bild zeigt die Oberfläche des Programms, das bequemerweise die Config-Datei (-->SD) erzeugt, ginge aber auch durch editieren der einen Zeile darin.

Dann drei Snapshots von Logs, dargestellt mit LogView. Da ist Christian mit einem 4220 von Ralph geflogen, 7kW Peak in einem 600er, nicht schlecht..

Tom

-----
Ich hatte nicht alles beantwortet:
Anbindung an ein Telemetriesystem ginge natürlich auch. Nur, wo ist dann das Logging am Ende? Ich kenne das Zeugs nicht im Detail, doch ein reines Monitoring/Alarming am Ende, siehe Jeti-Box, wäre ja kein Ersatz. ??? Allerdings ginge ein paralleles Anbinden, also Logging auf die SD und gleichzeitig Weitergabe an eine Telemetrieschnittstelle in genehmem Format.
Ebenso interessant wäre, - anstatt sich via zusätzliche Sensorik, für Speed und Höhe, z.B., in deren Gefilde zu begeben, - das Anbinden an etablierte Datenlogger-Systeme wie Unilog. Mein Dingens würde dann aber nicht selbst loggen, sondern nur die Daten aus dem Processing an den etablierten Logger weitergeben, der sie seinerseits mit seinen Mitteln in Log-Records bügelt. Das wäre also ein fallweiser (JIVE) Ersatz der eigenen, zum Steller externen Sensorik des etablierten Datenloggers durch diese Briefmarke, also aus seinem Blickwinkel auch ein "Sensor".

 

[JAyThaRevo]

Ist, das dein ernst das Kontronik sich geweigert hat das ding zu produzieren.
Wie blöd muss man sein. In Verbindung mit Telemetrie wäre Kontronik einer der ersten die alle relevanten Daten senden könnte. Sie wären quasi Vorreiter und man muss keine nervenden zusätzlichen Bausteine einbauen. Echt Schade, sitzen doch sehr kluge Köpfe dort... Mich würde diese Logik echt interessieren....

 

[masterste2000]

Hi Tom,

wie ich das sehe ist das Layout der Platine des Loggers schon fertig. Es fehlt somit nur noch:

1. Ein Hersteller der erstmal 100-200 Logger herstellt.
2. Eine Perfekte Homepage mit einem Online-Shop ( Da kann ich dir da was gutes stricken..)
3. Gewerbe anmelden
4. Etwas Werbung in D/USA Foren

Gruß
Stephan

 

[Gerd Giese]

... bitte löschen ...

 

[nexus665]

Was nen Hersteller angeht könnte ich evtl. helfen, der würde die sicher auch vertreiben. Homepage und Online Shop sind da vorhanden

Wenn gewünscht stelle ich gern Kontakt her.

lG,
Simon.

 

[JAyThaRevo]

2. Eine Perfekte Homepage mit einem Online-Shop

EXTREM WICHTIGER Punkt. Leider oft vernachlässigt...

 

[gecko_749]

...Ich hatte nicht alles beantwortet:
Anbindung an ein Telemetriesystem ginge natürlich auch. Nur, wo ist dann das Logging am Ende? Ich kenne das Zeugs nicht im Detail, doch ein reines Monitoring/Alarming am Ende, siehe Jeti-Box, wäre ja kein Ersatz. ??? Allerdings ginge ein paralleles Anbinden, also Logging auf die SD und gleichzeitig Weitergabe an eine Telemetrieschnittstelle in genehmem Format.
Ebenso interessant wäre, - anstatt sich via zusätzliche Sensorik, für Speed und Höhe, z.B., in deren Gefilde zu begeben, - das Anbinden an etablierte Datenlogger-Systeme wie Unilog. Mein Dingens würde dann aber nicht selbst loggen, sondern nur die Daten aus dem Processing an den etablierten Logger weitergeben, der sie seinerseits mit seinen Mitteln in Log-Records bügelt. Das wäre also ein fallweiser (JIVE) Ersatz der eigenen, zum Steller externen Sensorik des etablierten Datenloggers durch diese Briefmarke, also aus seinem Blickwinkel auch ein "Sensor".

Moin Tom.

Danke.

Zu der Telemetrie - das Problem mit den MPX und Jeti - Telemetriedaten ist das sie eben nicht gelogt werden. Und beim Unilog werden keine seriellen Daten aufgezeichnet - das heißt man müßte erst mal wieder analoge Daten erzeugen

Ok das PWM kann man wahrscheinlich direkt einspielen. Und der Unilog krankt js auch daran das man die Daten etwas umständlich seriell auslesen muß. Ich habe dafür früher das Unilog immer erst mal ausgebaut - da ist eine micro SD schon ein richtiger Fortschritt.

Also das was aus meiner Sicht Sinn macht ist die Daten aufzeichnen und seriell für Telemetrie bereitstellen mit einstellbaren Alarmen. Das reduziert dann unter anderem auch den Drahtverhau im Modell gegenüber zusätzlichen Sensoren. Was wiederum die Betriebssicherheit erhöht.

Gruß

gecko

 

[Gast_28792]

@gecko

Wenn ich das richtig verstanden habe aus den spärlichen Informationen, dann ist die Telemetrieschnittstelle ganz simpel asynchron-seriell. Wie ich ja schon schrieb, sendet der Logger eh parallel immer die Daten als Openformat-Livestream (für LogView), das käme also unten direkt für LogView an. Da es sich um nur EINEN UART im Prozessor handelt, und ein weiterer Software-UART nicht möglich wäre, da nur Rx/Tx UART und SPI (4-wire) an der Platine zugänglich sind (Sparvariante seitens der Pin-Konnektierung am Prozessor-Chip), muss das dann aber zwingend über 9600 Bd 8,N,1 gehen. Das scheint aber eh der Fall zu sein für Jeti/MPX-Telemetrieinterface, wenn ich das richtig seitens des dafür verwendeten "COM"-Interfaces am Unilog verstanden habe.

Vorbehaltlich eines Irrtums meinerseits aufgrund zu dünner Infos, ist also die Telemetriestrippe an dem Logger bereits vorhanden, man muss sie nur anlöten.

Tom

 

[gecko_749]

Moin,

leider nein. Es handelt sich bei beiden Systemen nicht um eine einfache serielle Kommunikation.

Bei Jeti werden Datenpakete von 32 Byte im Format 9o2 mit etwas Verwaltungsinfo erwartet. Und bitte nur 7bit ASCII - Zeichen. Mal grob vereinfacht gesagt.

Bei MPX gibt es einen seriellen Sensorbus. Der Master ist der Empfänger und der fragt die Leitung ab. Bekommt er eine Antwort dann sendet er 3 Byte dieser Sensoradresse runter. Davon ist der eigentliche Wert 15 bit signed.

Es geht also nicht ohne auf das jeweilige System angepasst zu reagieren.

Die genauen Infos sind im Netz zu finden resp. gibt MPX die Spec auf nachfrage raus. Dauert nur ...

Gruß

gecko

 

[Gast_28792]

OK. Dann war es nicht passend, mal eben Infos aus einem quer gelesenen User Manual beziehen zu wollen.

Sofern die Informationen irgendwo fassbar sind, siehe Spektrum, z.B., lässt sich beides natürlich implementieren.

Fragt sich nur, zu welchem Zweck? Diese ganze Telemetrie hat doch offenbar nur den Zweck, mit z.V. stehenden Mitteln (s. Jetibox) ein Monitoring zu machen, Statistik/Saldierungen, die man erst nach dem Flug beguckt (Kapazität und so'n Zeugs) und Alarme auf bestimmte Messwerte zu setzen. Will ich den Kram remote loggen, gibt's kein Interface dafür am Sender(?)

Die Platine des Loggers ist ja nur so klein, weil minimalistischerweise nur die Interfaces des Prozessors (MC) zugänglich gemacht werden, die für den Urzweck benötigt werden. Das ist auf der applikativen Seite zunächst nur der UART des Proc, also Rx/Tx, on top SPI (4-wire) für ISP Flashing.

Ich würde nun das SPI für eine Daisy Chain von Loggereinheiten nehmen, also hier dieselbe Platine nochmal als Telemetrieinterface/Protocol-Engine.

EagleTree scheint das ja bereits zu machen, eine Daisy Chain, vermutlich mit TWI (2-wire), nur die Basis-Sensoren haben ein proprietäres Interface an der Base Unit der Loggerei. Die Jumper-Kabel finde ich aber doof, ist jede verarbeitende Einheit richtig klein, kann man die als Sandwich direkt übereinander stecken, so, wie die "Proto Shields" bei Development Kits. Mit drei Einheiten, z.B., wäre das dann eben ein dickerer Würfelzucker statt einer Briefmarke.

Aber, wie ich schon sagte, war die Intention und mein "Ehrgeiz" ja eigentlich nicht, gegen bestehende Logger mit ihrer Vielfalt von Sensoren anzutreten. Im Gegenteil, es wäre sinnvoller, diese Logger mit dem (J)Log als weiteren Sensor zusammen zu bringen. Einzige Crux ist möglicherweise, dass das Loggen mit meinem Dingens in Files eines Filesystems auf einem Wechselmedium (SD) nun offenbar "Begehrlichkeiten" weckt, die die herkömmlichen Logger mit einem EEPROM als Medium (noch) nicht erfüllen.

Tom

 

[gecko_749]

Hi Tom,

na der Zweck kann sein wie ich oben schon schrieb den Drahtverhau im Modell etwas einzudämmen.

Klar kann man die wesentlichen Werte auch jetzt schon mit vorhandenen Systemen zum Sender zurückschicken. Aber halt nur mit einigem Hardware und damit auch finanziellen Aufwand.

Ich halte es eben für eleganter die Daten die eh schon im Regler ermittelt werden zu nutzen anstatt noch weitere Sensoren dazwischen zuschalten.

Brauchen tut man die Anzeigen am Sender eher nicht, wohl aber akustische Alarme für Akkuspannung und verbrauchte Energie. Oder Temperatur bei hochbelasteten Antrieben.

Aber wenn Du nicht Zugriff auf die Systeme hast und die Quellen für Andere nicht zugänglich sind wird das schwer da etwas zu entwickeln. Da macht es eher Sinn das vorhandene erst einmal auf den Weg zu bringen.

Gruß

gecko

 

[Gast_28792]

Aber wenn Du nicht Zugriff auf die Systeme hast und die Quellen für Andere nicht zugänglich sind wird das schwer da etwas zu entwickeln. Da macht es eher Sinn das vorhandene erst einmal auf den Weg zu bringen.

Eigentlich bin ich eher optimistisch, was das "Erkennen" solcher Protokolle betrifft. Es gäbe ja auch keinen Grund für Jeti oder MPX, da zu mauern. OK, Horizon bzw. Futaba machen wg. ihrer Protokolle auch einen Affenzirkus, aber mit NDA ist alles in Sack und Tüten. Bei Spektrum war ich zu faul dazu, hab' den Sherlock-Holmes-Spaß bevorzugt, SBus ist mir i.Augenblick schnuppe.

Klar, erst auf den Weg bringen.

Ich habe mich nun entschlossen, noch eine kleine Verzögerung einzubauen, die im Ergebnis es den Anwendern ermöglichen wird, selbst ein Update durchzuführen, ohne, dass Raubkopie bzw. Re-engineering Tür und Tor geöffnet wird. Ich fühle mich gegenüber Kontronik in der Pflicht, Dinge zu schützen, die man evtl. als "sensibel" betrachtet.
Dadurch wird es dann möglich, so ein Addon für Telemetrie-Anschluss oder sonstwas jederzeit nachzulegen. Einschicken zum Update ginge zwar auch, ist aber immer doof.

Tom

 

[nexus665]

...super, Tom!

Ich für meinen Teil warte lieber ein paar Tage/Wochen länger und habe das Gefühl, daß hier keiner Partei irgendwas verlustig gehen kann

Was Zusatzfeatures angeht - tolle Sache.

Die Geschichte mit MPX/Jeti Direktanbindung finde ich auch verfolgenswert - in weiterer Folge auch für Spektrum, im September soll die Telemetrie bzw. die DX8 ja endlich kommen...

lG,
Simon.

 

[JAyThaRevo]

Achtung LAIE!!!

Darf ich fragen welchen Prozessor (µC) du verwendest und in welcher Sprache du das Programm geschrieben hast. Nicht die Windows Application, die wird C# sein nehm ich an.

MfG

 

[Gast_28792]

ATmega 328p@16, mein Lieblingsspielzeug für solche Zwecke, selbst für 'ne IMU mit viel Addons hat der gereicht. Die dickeren AVR's wie 1280 sind einfach zu groß. Es gibt bessere MCU's, doch preislich ist der 328 ein guter Kompromiss. Sprache ist "C" barfuß.

Der Konfigurator ist in Visual Studio .NET, was sich heute so "BASIC" nennt, - eine objektorientierte Katastrophe. Ich musste mich aus anderen Gründen mit dem Mist "anfreunden", also hab' ich's gleich genommen.

 

[JAyThaRevo]

ATmega 328p@16, mein Lieblingsspielzeug für solche Zwecke

Wenn ich mir so das Datasheet anschaue dann hat der doch eh alles was ein Programmiererherz begehrt !

- eine objektorientierte Katastrophe

Haha, musste ich lachen.
Ich weiß nicht warum aber bis jetzt ist mir der Knopf bei objektorientieren Sprachen noch nicht aufgegangen....

 

[Powercroco]

um abzuschätzen, ob sich da lohnt, mit ein paar elektronisch bewanderten befreundeten bastlern was anzuschieben,
wäre es jetzt schön zu wissen:

- wieviel interesse es gibt
- was sowas den am ende kosten dürfte.

vg.
ralph

 

[Gast_3969]

- was sowas den am ende kosten dürfte.

Leiterplatte vom Schnelldienst ca. 3,50 im kleinen Nutzen und angenommenen 40-50 Stück drauf, Kabel 1,- Hühnerfutter je nach Bezug geschätzte 5,-, der Lötaufwand ist der grösste Teil, sagen wir Handlötung, 4Stck/Stunde runde 15,-

Macht 24,50 x 2 damit was verdient wird und die Entwicklung halbwegs umgelegt wird, simmer bei 49,- is doch ne schöne Zahl, da kann man den Speicher mal mitschenken.

Industriell betrachtet siehst natürlich anders aus

p.s.: das wären Preise, die eine Automobilindustrie dafür zahlen würde

 

[Gast_28792]

Es geht darum, dass wir irgendwo dem Mutigen, der das produzieren/vertreiben soll, was sagen können wollen, also eine Bedarfserhebung. Wenn das bei RCN möglich ist, würde ich einen Thread an geeigneter auffälliger Stelle machen, alles kurz noch mal darstellen, ungefähren Preis nennen und so eine Statistiktabelle (Zähler) drüberhängen.

49,-...., jaja. In Natura sind da noch ein paar Handaufhalter, nicht nur die Märchensteuer...

Die Platine wird quasi industriell gefertigt, sie kostet dadurch natürlich mehr als irgendeine Kleinserie vom Küchentisch.

Der Startpreis würde vermutlich bei 119..129 inkl. Märchensteuer liegen, Tendenz fallend gegen 99. SD Card und USB-Reader dabei.
Das wäre mMn nicht ganz daneben, ein Unilog ohne alles (Sensoren) kostet 89.

FTDI-Interface und Livestream-Adapter kämen extra, bei Bedarf. Dieser Bedarf käme vor allem auch mit Updatewillen, wenn dann (später) Sub-Devices kommen, Telemetrie, evtl. Höhe, Speed und anderer Quatsch, auch eine Echtzeituhr für Timestamps an den Files im Filesystem.
Bin ja immer noch des Kinderglaubens, dass hier kein neues Loggersystem etabliert werden soll.

Ist aber noch nicht ausgegoren, der "Mutige" hat das Sagen.

Tom