Anzeige Anzeige
  flying-circus.de
Seite 8 von 31 ErsteErste 123456789101112131415161718 ... LetzteLetzte
Ergebnis 106 bis 120 von 464

Thema: Graupner HoTT Telemetrie-Sensoren Eigenbau DIY | Telemetrie-Protokoll entschlüsselt

  1. #106
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    PS: Was mir gerade in den Sinn kommt, ist eine Minimaltelemetrie für den JLOG1. Also z.B. Kapaalarm per ATTiny weiter an einen HoTT Empfänger ...
    Jo, das ginge natürlich. Am besten den OpenFormat-Livestream (asynchron-seriell 9k6) von JLog1 auswerten, da sind alle Daten und auch die Alarme einzeln drin. So macht es ja auch Linus mit seiner eigenen Telemetrie mit XBee, mit JLog1 und 2.

    Meine eigene Telemetrie "JTX" macht es ja quasi auch so, nur, dass ich die binären Datenpakete des JIVE in einem am Modell befindlichen JLog2 (Hardware) auswerte, logge und alarmbewerte, dann modifiziere und mit eigenen Daten auffülle (Status, mAh nur am Modell berechnet wg. möglichem Datenverlust auf der Strecke, JLog-eigene Sensoren (Daten)) und per XBee zu einem zweiten JLog2 (Hardware) am Boden sende, der mit den Basisdaten in den Paketen genau dasselbe macht, wie das Teil am Modell. JLog-eigene Sensordaten sind für den nur genauso "virtuell" wie die Sensordaten aus dem JIVE. Er kann nun auch loggen, oder man schaltet das im JLC ab. Er macht dann einfach JETI(box) oder Unidisplay oder HoTT (SmartBox) zur Anzeige und alarmiert mit eigenem Geber (Buzzer, LED). Siehe hier.
    Bitte unbedingt auch die Nachsätze beachten. Ungeschachtelt zum Uplink im selben Band zu senden (Was übrigens auch Spektrum mit dem TM1000 macht!), kann u.U. leicht ungesund für die Hauptanwendung sein. In DE bleibt uns dann nur das 433MHz-ISM-Band als Ausweg, was ich als HAM hasse, oder eben evtl. 868MHz.

    EDIT: Oops, Du sprachst ja von HoTT, da war mein Gelaber über "JTX" nicht ganz passend. Sorry, nicht aufgepasst.

    Und kannst Du ein paar Worte zur Smartbox sagen? Habe bisher nur Textmode und Binärmode verstanden.
    Ich weiß jetzt nicht genau, was Du meinst. Die SB ist ein Busmaster wie auch der Empfänger, weshalb man auch mit der SB nicht einen Rx im Direktanschluss als Terminal konfigurieren kann, wohl aber die anderen Sensoren.
    Die SB kennt nun logischerweise, wie ein Sender, die zwei Modi, "Text" (Terminal, 8x21Z, interaktiv mit 4 Tasten) und "Binär" (unidirektional). Allerdings zeigt die Box im Direktanschluss an einen Sensor binär nichts an, nur, wenn sie an einen Tx-Modul angeschlossen wird, also so ein Ding zur Auf-/Nachrüstung. Grund ist, dass eine Binäranzeige immer mehr will, als ein einzelner Sensor sendet, nämlich vor den Daten des eigentlichen Sensors (GAM/GEM, EAM, VARIO, GPS) auch teilweise Daten des Empfängers als Sensor, in einem Header. Das liegt in der "embedded SB" in einem Full-HoTT-Sender vor, und natürlich auch beim Anschluss einer physischen SB an einen Tx-Modul, die TXe kriegen ja ihr Zeugs von einem Rx.
    (Ich habe dann den Bodenteil meiner "JTX"-Telemetrie ("JTX Base") seitens HoTT modifiziert, sodass bei Wahl einer SB (also HoTT) als Display auch die grafischen Binärseiten wahlweise verwendet werden können.)

    Wurden die Datenstrukturen, außer mit Nullbytes Auffüllen auf die neuen Framelängen geändert?
    Das ist jetzt so 'ne Frage. Erstmal: Ja. Nur, der Wechsel von v3 auf v4 war ja kein glatter, da haben Ralf Helbing und ich (Evtl. auch Andere?) so einige Gefühlswechsel durchleben dürfen, weshalb es mir gerade im Vergleich zur v3 direkt schwer fällt, die letztendlichen Änderungen zu benennen. Ich nehme mal an, Deine Frage bezieht sich auf den Unterschied zur Vorversion, also v3, also den offiziell einzigen Schritt v3-->v4? Das Blöde war eben nur, dass es für mich verschiedene Schritte waren, mit Zwischenschritten, da hat die Altzheimer freie Bahn.

    In Stichworten:
    - Textmodus: Sensoren haben jetzt auch eine dedizierte Adresse wie im Binärmodus, vorher gab es (zum Glück) auch schon eine Adresse, aber EINE Adresse für alle Sensoren. Das ist der Grund, weshalb ein Sender zusätzlich "etc" bzw. eine SB "oldSensor" kennt, damit wird ein alter Sensor (v3) textuell adressiert. Glücklicherweise ist die Sammeladresse, die in V3 verwendet wurde, in v4 nicht mehr in Benutzung, alle dedizierten Adressen unterscheiden sich von der (alten) Sammeladresse.

    - Binärmodus: Zunächst kamen die 9 Bytes hinten ran, Byte 35 bis 43, die kann man im Augenblick einfach mit Nullen füllen, solange neue Binärdisplays, die das nutzen, noch nicht da sind (im Sender, in der SB). In den Datenbytes davor blieb alles unverändert. Was sich noch verändert hat, ist der Header, Byte 1 bis 6: Nach 5ms Idle Line (!) kommt wie zuvor Byte1==0x7C, dann Byte2==<binäre SensorID>, Byte3==Alarmbits (wie in v3), Byte4==<SensorID wie im Textmode, 4Bit-Tastencode==0>(!), Byte5,6==Alarm-Inverse-Bits (wie in v3). Ab Byte7 dann die Daten wie in v3, also z.B. Zelle1 beim GAM. -- Der empfangende Binärmodus der SB (nur für Betrieb an einem Tx-Modul gedacht) sieht völlig anders aus als der sendende eines Sensors, - zwischen binärer und textueller SensorID befinden sich 13 Bytes des besagten Rx-Headers, und die beiden Alarm-Inverse-Bytes finden sich nach den 9 neuen Datenbytes und vor dem Endezeichen.

    Mannomann, ich werde noch des Hochverrats angeklagt..
    Like it!

  2. #107
    User
    Registriert seit
    26.09.2009
    Ort
    -
    Beiträge
    68
    Daumen erhalten
    1
    Daumen vergeben
    2
    0 Nicht erlaubt!

    Standard

    Hallo Tom,

    danke Dir. Das muss ich erstmal unzippen. Die Framestruktur, in die die Daten eingebettet sind, hatte ich so ungefähr auch beisammen. Der Livelog ist eine super Idee. 9k6 müsste auch in Software zu machen sein. Dann könnte das auch so ein Arduino Mini. Ich glaube mein Projekt für die persönliche idle task steht. Hast Du zufälligen einen JLog1 Openformat log rumliegen?

    VG Michael
    Like it!

  3. #108
    User
    Registriert seit
    27.10.2006
    Ort
    .
    Beiträge
    960
    Daumen erhalten
    1
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Zitat Zitat von mha1 Beitrag anzeigen
    ...Hast Du zufälligen einen JLog1 Openformat log rumliegen?

    VG Michael
    Hi,

    interessanter wäre das, was aus dem Jive kommt

    Damit ich ohne JLog .....

    Grüße
    MX-20 HOTT weil es Up-to-Date ist
    Pulsar P3+ und P3
    Like it!

  4. #109
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Ist hier etwas OT...

    Ausschnitt:
    $1;1;0.0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0
    $1;1;45.20;0;0;0;15;59;8;16;215;0;0;0;74;6;15;0;0;0;0;0
    $1;1;45.30;0;0;0;15;59;8;19;247;0;0;0;74;6;15;0;0;0;0;0
    $1;1;45.40;0;0;0;15;59;9;19;244;0;0;0;74;6;15;0;0;0;0;0
    $1;1;45.50;0;0;0;15;59;10;22;287;0;0;0;73;6;15;0;0;0;0;0
    $1;1;45.60;0;0;0;15;59;10;23;297;0;0;0;73;6;15;0;0;0;0;0
    $1;1;45.70;0;0;0;15;59;11;24;315;0;0;0;73;6;15;0;0;0;0;0
    $1;1;45.80;0;0;0;15;59;11;25;329;0;0;0;73;6;15;0;0;0;0;0
    $1;1;45.90;0;0;0;16;59;12;28;361;0;0;0;79;6;16;0;0;0;0;0
    $1;1;46.00;0;0;0;15;59;13;29;372;0;0;0;74;6;16;0;0;0;0;0
    $1;1;46.10;0;0;0;15;59;13;30;391;0;0;0;74;6;16;0;0;0;0;0
    $1;1;46.20;0;0;0;16;59;14;31;402;0;0;0;79;6;16;0;0;0;0;0
    $1;1;46.30;0;0;0;16;59;15;32;422;0;0;0;79;6;16;0;0;0;0;0
    $1;1;46.35;0;0;0;16;59;15;33;432;0;0;0;79;6;16;0;0;0;0;0
    $1;1;46.50;0;0;0;18;59;16;35;457;0;0;0;89;6;18;0;0;0;0;0
    $1;1;46.55;0;0;0;18;59;16;36;468;0;0;0;89;6;18;0;0;0;0;0
    $1;1;46.70;0;0;0;18;59;17;38;491;0;0;0;89;6;18;0;0;0;0;0
    $1;1;46.75;0;0;0;19;59;18;39;501;0;0;0;94;6;19;0;0;0;0;0
    $1;1;46.90;0;0;0;17;59;18;40;524;0;0;0;84;6;19;0;0;0;0;0
    $1;1;46.95;0;0;0;35;59;19;42;544;0;0;0;173;6;35;0;0;0;0;0
    $1;1;47.10;0;0;0;23;59;20;43;561;0;0;0;113;24;35;0;0;0;0;0
    $1;1;47.15;0;0;0;22;59;20;45;578;0;0;0;109;24;35;0;0;0;0;0
    $1;1;47.30;60;0;494;26;59;21;46;597;1;0;0;128;24;35;0;0;0;0;0
    $1;1;47.35;59;13;493;24;59;21;47;613;1;0;0;118;24;35;0;0;0;0;0
    $1;1;47.50;60;0;494;26;59;22;50;644;1;0;0;128;24;35;0;0;0;0;0
    $1;1;47.55;60;0;494;26;59;23;51;655;1;0;0;128;24;35;0;0;0;0;0
    $1;1;47.70;60;0;494;27;59;23;53;686;1;0;0;133;24;35;0;0;0;0;0
    $1;1;47.75;60;0;494;30;59;24;54;698;1;0;0;148;24;35;0;0;0;0;0
    $1;1;47.90;60;5;493;28;59;25;56;728;1;0;0;138;24;35;0;0;0;0;0
    $1;1;47.95;59;6;494;28;59;25;58;744;1;69;0;138;24;35;0;0;0;0;0
    $1;1;48.10;59;0;493;31;59;26;59;769;1;69;73;153;24;35;0;0;0;0;0
    $1;1;48.15;60;0;494;33;59;26;61;783;1;69;73;163;24;35;0;0;0;0;0
    $1;1;48.30;61;0;493;36;59;27;63;808;1;69;73;177;24;36;0;0;0;0;0
    $1;1;48.35;60;0;493;32;59;28;64;824;1;69;73;158;24;36;0;0;0;0;0
    $1;1;48.50;60;0;494;35;59;28;66;851;2;69;73;173;24;36;0;0;0;0;0
    $1;1;48.55;60;0;493;39;59;29;67;866;2;69;73;192;24;39;0;0;0;0;0
    $1;1;48.70;60;28;492;38;59;30;69;891;2;69;73;187;28;39;0;0;0;0;0
    $1;1;48.75;60;34;494;35;59;30;70;902;2;69;73;173;34;39;0;0;0;0;0
    $1;1;48.90;60;6;493;42;59;31;73;941;2;69;73;207;34;42;0;0;0;0;0
    $1;1;48.95;59;0;493;36;59;31;74;951;2;69;73;177;34;42;0;0;0;0;0
    $1;1;49.10;60;0;494;38;59;32;76;984;2;69;73;188;34;42;0;0;0;0;0
    $1;1;49.15;60;23;494;40;59;33;77;992;2;69;73;198;34;42;0;0;0;0;0
    $1;1;49.30;59;6;494;36;59;33;79;1020;2;69;73;178;34;42;0;0;0;0;0
    $1;1;49.35;60;0;494;41;59;34;80;1034;2;69;73;202;34;42;0;0;0;0;0
    $1;1;49.50;60;0;493;39;59;35;82;1062;3;69;73;192;34;42;0;0;0;0;0
    $1;1;49.55;60;0;494;43;59;35;83;1072;3;69;73;212;34;43;0;0;0;0;0
    $1;1;49.60;60;5;492;48;59;36;86;1104;3;69;73;236;34;48;0;0;0;0;0
    $1;1;49.70;60;0;493;44;59;36;87;1117;3;69;73;217;34;48;0;0;0;0;0
    $1;1;49.80;60;0;494;49;59;37;89;1151;3;69;73;242;34;49;0;0;0;0;0
    $1;1;49.90;60;0;492;49;59;37;90;1166;3;69;73;241;34;49;0;0;0;0;0
    $1;1;50.00;61;0;494;51;59;38;92;1190;3;69;73;252;34;51;0;0;0;0;0
    $1;1;50.10;60;0;493;46;59;39;93;1201;3;69;73;227;34;51;0;0;0;0;0
    $1;1;50.20;60;9;493;48;59;40;95;1219;4;69;73;237;34;51;0;0;0;0;0
    $1;1;50.30;60;0;494;48;59;40;96;1234;4;69;73;237;34;51;0;0;0;0;0
    $1;1;50.40;61;23;491;49;59;41;98;1265;4;69;73;241;34;51;0;0;0;0;0
    $1;1;50.50;60;0;491;49;59;41;98;1265;4;69;73;241;34;51;0;0;0;0;0
    $1;1;50.60;60;0;492;64;59;42;100;1286;4;69;73;315;34;64;0;0;0;0;0
    $1;1;50.70;60;0;492;59;59;42;103;1322;4;69;73;290;34;64;0;0;0;0;0
    $1;1;50.80;60;0;493;61;59;43;104;1335;4;69;73;301;34;64;0;0;0;0;0
    $1;1;50.90;61;26;493;58;59;44;106;1367;5;69;73;286;34;64;0;0;0;0;0
    $1;1;51.00;60;25;493;60;59;45;107;1384;5;69;73;296;34;64;0;0;0;0;0
    $1;1;51.10;61;28;491;60;59;45;109;1408;5;69;73;295;34;64;0;0;0;0;0
    $1;1;51.20;60;6;491;62;59;46;110;1423;5;69;73;305;34;64;0;0;0;0;0
    $1;1;51.30;60;0;492;62;59;46;113;1451;5;69;73;305;34;64;0;0;0;0;0
    $1;1;51.40;60;21;493;58;59;47;113;1459;5;69;73;286;34;64;0;0;0;0;0
    $1;1;51.50;60;9;492;63;59;47;115;1484;6;69;73;310;34;64;0;0;0;0;0
    $1;1;51.60;60;20;492;65;59;48;116;1498;6;69;73;320;34;65;0;0;0;0;0
    $1;1;51.70;59;0;492;66;59;49;118;1518;6;69;73;325;34;66;0;0;0;0;0
    $1;1;51.80;59;29;492;61;59;49;119;1532;6;69;73;300;34;66;0;0;0;0;0
    $1;1;51.90;60;26;491;63;59;50;120;1544;6;69;73;309;34;66;0;0;0;0;0
    $1;1;52.00;60;5;492;63;59;50;121;1562;7;69;73;310;34;66;0;0;0;0;0
    $1;1;52.10;60;0;492;70;59;51;123;1581;7;69;73;345;34;70;0;0;0;0;0
    $1;1;52.20;60;0;492;66;59;52;124;1596;7;69;73;325;34;70;0;0;0;0;0
    $1;1;52.30;60;61;491;77;59;52;126;1622;7;69;73;378;61;77;0;0;0;0;0


    $1;1;Sekunden.sekunden;Ubec*10;Ibec*10;Ubat*10;Imot*10;Gas;PWM;RPMuni/10;RPMmotor/10;mAh;tempFET°C;tempBEC°C;PowerWatt;IbecMax*10;ImotMax*10;mAh-Alarm(0|1);Ubat-Alarm(0|1);tempFET-Alarm(0|1);UbecDrop-Alarm(0|1);0 <-- Checksumme immer Null, ist eigentlich Männerulk im Logfile. (Im "JTX" sind die Pakete mit CRC, weil'se durch die Luft gehen und das modifizierte JIVE-Pakete sind, die eh CRC haben.)

    Files finden sich auf j-log.net im JLog1-Bereich.

    Falls Du nicht fit genug sein solltest seitens Software-UART, denke dran, Du brauchst 2 serielle Interfaces, Nummer 1 nur 9k6 in (OF), Nummer 2 19k2 in/out (HoTT, 1-Wire, Rx/Tx parallel schalten). Der kleine Arduino-Kram hat einen 168 oder 328 drauf, der hat nur einen Hardware-UART.

    Tom
    Like it!

  5. #110
    User
    Registriert seit
    27.10.2006
    Ort
    .
    Beiträge
    960
    Daumen erhalten
    1
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Zitat Zitat von dl7uae Beitrag anzeigen
    ...
    Falls Du nicht fit genug sein solltest seitens Software-UART, denke dran, Du brauchst 2 serielle Interfaces,..
    Hi dl7uae,

    Bin HardWärker.

    also lieber Hardware UART mit INTs als Software

    Grüße
    MX-20 HOTT weil es Up-to-Date ist
    Pulsar P3+ und P3
    Like it!

  6. #111
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Jo.., dann einen 644p, wenn's ATMEL sein soll.

    Auf der 1-Wire-Seite muss man eh ständig eingreifen, also Tx/Rx on/off und so.

    Wenn man die Arduino-IDE benutzt (reine Geschmacksfrage), hat man ja automatisch C++ an der Backe und kann die Lib "NewSoftSerial" nehmen. Die ist mit 16MHz immer gut für 38k4, oft auch noch bis 57k6. Damit dann aber rein asynchron-seriell, also sozusagen nur in "Missionarsstellung", denn ein Eingreifen hier für 1-Wire könnte etwas mehr Kopfschmerzen machen, vor allem auch das Idle Line.

    -----
    Mist, ich hatte schon wieder nur mit halbem Auge gelesen, Du hattest Dich ja schon auf einen Software-UART festgelegt. Mit C++ und am besten gleich mit der Arduino-IDE (wg. der Lib-Struktur) kannst Du damit tatsächlich mit einem Mini oder Nano ganz lässig die 9k6 lesen auf einem GIO-Pin. Auf dem UART machste dann den HoTT-Kram.

    -----
    interessanter wäre das, was aus dem Jive kommt

    Damit ich ohne JLog .....
    Nö.., sorry.
    Ich kann Dir dazu aber auch gleich sagen, dass Dich der Datensatzaufbau auch nicht glücklich machen würde, weil man eine ziemlich verzwackte State Machine drum rum braucht, um das Geseier des JIVE für ein Log nutzen zu können. Die Härte ist aber das Data Processing für den Strom aus dem JIVE, unbearbeitet kann man damit nur seine Lottoscheine ausfüllen.
    Like it!

  7. #112
    User
    Registriert seit
    27.10.2006
    Ort
    .
    Beiträge
    960
    Daumen erhalten
    1
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Hi,

    [privat] ich arbeite mit C und AVR....

    Grüße
    MX-20 HOTT weil es Up-to-Date ist
    Pulsar P3+ und P3
    Like it!

  8. #113
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Jo.., ist mir symphatisch. JLog2 ist ja auch AVR, ein 644p, und alles Barfuß-C, um den Platzbedarf besser "tweaken" zu können.

    Teilweise nehme ich aber auch einen Arduino und ärgere mich permanent über den JAVA-Überbau der IDE, wenn ich Libs der Community nachnutzen will.

    Aber auch andere Mütter haben schöne Töchter, z.B. ARM mit der Cortex-Familie, da kann dann, je nach Taktfrequenz, richtig die Luzi abgehen. Na ja, die Welt ist bunt, Infineon soll auch nicht verschwiegen werden.., und natürlich auch nicht die Ritter der PICs. Meist klebt man ja 'ne Weile an was fest, eben nach der alten Bauernregel, "Wat der Bur net kennt...".
    Like it!

  9. #114
    User
    Registriert seit
    27.10.2006
    Ort
    .
    Beiträge
    960
    Daumen erhalten
    1
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Zitat Zitat von dl7uae Beitrag anzeigen
    Jo.., ist mir symphatisch. JLog2 ist ja auch AVR, ein 644p, und alles Barfuß-C, um den Platzbedarf besser "tweaken" zu können.

    Teilweise nehme ich aber auch einen Arduino und ärgere mich permanent über den JAVA-Überbau der IDE, wenn ich Libs der Community nachnutzen will.

    Aber auch andere Mütter haben schöne Töchter, z.B. ARM mit der Cortex-Familie, da kann dann, je nach Taktfrequenz, richtig die Luzi abgehen. Na ja, die Welt ist bunt, Infineon soll auch nicht verschwiegen werden.., und natürlich auch nicht die Ritter der PICs. Meist klebt man ja 'ne Weile an was fest, eben nach der alten Bauernregel, "Wat der Bur net kennt...".
    Hi,

    eigentlich habe ich bisher nur 1280er verwendet, weil die mir "geschenkt" wurden

    Aber wegen dem Platzbedarf muss ich nun mit einen 168er auskommen

    644 ist ne Hausnummer, aber der Pinbedarf.....

    Grüße
    MX-20 HOTT weil es Up-to-Date ist
    Pulsar P3+ und P3
    Like it!

  10. #115
    User
    Registriert seit
    26.09.2009
    Ort
    -
    Beiträge
    68
    Daumen erhalten
    1
    Daumen vergeben
    2
    0 Nicht erlaubt!

    Standard

    Hallo Tom,

    danke Dir. Peinlich, ich dachte Openformat wäre wieder ein eigenes Format. Sind ja die Logs selbst. Davon habe ca. 150 aus dem TDR. Also alles da. Und ja, ich hätte den Jlog Datenstrom mit NewSerialSoft eingelesen und den Telemetrie Output per HW UART an den Empfänger geschickt. Zwei HW UARTS wären zwar schön, aber ein Arduini Mini liegt gerade rum.

    Zum Zusammenschalten RX und TX: sollte man das nicht durch eine Diode entkoppeln? Hätte man sonst nicht sein Echo auf der Leitung? Braucht die one wire Leitung zum Empfänger einen pullup?

    Name:  rxtx.jpg
Hits: 3096
Größe:  9,3 KB
    Like it!

  11. #116
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Zum Zusammenschalten RX und TX: sollte man das nicht durch eine Diode entkoppeln? Hätte man sonst nicht sein Echo auf der Leitung? Braucht die one wire Leitung zum Empfänger einen pullup?
    Nee, einfach zusammenknallen, Du hast ja immer nur einen aktiv, Tx oder Rx. Den Rx clearst Du, wenn Du gesendest hast und auf Rx umschaltest. Sprich, das ist ja half duplex. - Einen Pullup brauchst Du nicht, das Zuschalten (sind ja nur 35..50k im AVR) stört aber auch nicht.

    Ja, OpenFormat ist das, was LogView dann als Device Input frisst. Der OF-Livestream des Loggers unterscheidet sich leicht zu dem, der aufgezeichnet wird. Das liegt am LogStop: Maxwerte für die Aufzeichnung werden nicht aktualisiert, wenn gerade LogStop Condition vorliegt, also nicht aufgezeichnet wird. Minwerte gibt es nur in der Telemetrie, nicht im LiveStream. Letzteres hat als Grund, damit der Aufbau des LiveStreams identisch zum OF der Aufzeichnung ist. Der OF-LiveStream war ja mehr für LV auf der Werkbank (via USB) denn für Telemetriezwecke gedacht.

    Tom
    Like it!

  12. #117
    User
    Registriert seit
    27.10.2006
    Ort
    .
    Beiträge
    960
    Daumen erhalten
    1
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Zitat Zitat von dl7uae Beitrag anzeigen
    ...
    Ach so, und wenn ich schon mal dabei bin: Das ist hier das übliche Idle-Line-Protokoll, um auf einem 1-Wire-Bus kollisionsfrei mit n Slaves arbeiten zu können. Ich zitiere mich mal selbst:.
    Hi,

    bin gerade dabei das Idle-Line einzubauen und habe dazu ein Experiment mit dem original GAM gemacht.

    AVR direkt mit dem GAM verbunden ohne Empfänger.

    - AVR sendet 0x80, 0x8D, also einen "Request" zum GAM.
    - GAM antwortet mit seinen Daten.

    Nun wollte ich das Idle-Line vom GAM testen.

    - AVR sendet 0x80, 0x8D, 0x65, und noch ein paar Bytes im 2ms Raster.
    - GAM antwortet trotzdem mit Daten bzw. es entsteht Datenmüll wegen Kollision.


    Also habe ich mein programmiertes EAM zusammen mit GAM an den Empfänger angeschlossen.
    In der Fernsteuerung nur EAM aktiv. GAM deaktiviert.

    - mein EAM antwortet schön auf den Request und es kommen aktualisierte Daten in der Funke an.
    - GAM macht nix, hat ja auch kein Request
    (damit ich sehe dass was ankommt, lasse ich einfach die Temperatur hoch und runter laufen.


    Nun habe ich in die EAM Daten irgendwo 0x80 und 0x8D hintereinander eingebaut.

    - mein EAM antwortet auf den Request und sobald die 0x80 und 0x8D in den Daten von meinem EAM auftauchen, fängt das GAM an dazwischen zu reden.
    - es entsteht Datenmüll. Es kommt auch nix mehr an der Funke an.

    Ich habe schon verschiedene Delays probiert, von 1ms bis 5ms. Ändert nix, GAM quatscht dazwischen.

    Hab ich was übersehen?

    Wenn das GAM 0x80 und 0x8D empfängt, sollte es doch nix antworten, wenn innerhalb von 5ms weitere Byts empfangen wurden?

    In meinem Test kommen im Abstand von 2ms weitere Daten.

    Grüße
    MX-20 HOTT weil es Up-to-Date ist
    Pulsar P3+ und P3
    Like it!

  13. #118
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Da habe ich ja was ausgelöst..

    Na ja, ich sage mal so: Das Idle Line war eine Forderung von mir, die auch allen 3rd-Party-Implementatoren zuging in Form einer v4-Protokollbeschreibung, die ich fertigte. Ob das auch straight in der FW der Graupner-Sensoren landete, entzieht sich meiner Kenntnis, habe ich auch nicht explizit getestet.

    Das muss Ralf Helbing mal mit der Entwicklung checken.
    Der Ablauf war der, dass ich in Vorbereitung mehrerer paralleler Sensoren bereits in der v3 ein Idle Line vorschlug und in JLog2 einbaute. Die Protokollbeschreibung, die es in anderer Form auch immer von Graupner gab, machte ich später, in einer Zwischenphase der Version, die später "v4" getauft wurde. Erst hier kam das Idle Line beschreibungstechnisch zu Papier. Möglich, dass es auf dem Weg zur Entwicklung stecken blieb, es war bei denen ohnehin sehr stressig zum fraglichen Zeitpunkt, weil die mc32 in den Geburtswehen lag und der gleichzeitige Protokollwechsel, v4 auch noch im Debug, hier logistische Kopfschmerzen on top bereitete. Es war schon fast ein Wunderding, dass das alles noch so 100%ig vor Weihnachten aufging, da kann das Idle Line schlichtweg übersehen worden sein.

    Ansonsten kann man hoffen, dass der Zufall nicht eintritt, was ja wohl bisher auch nicht der Fall war, möglicherweise aufgrund der Daten nicht eintreten kann. Die 3rd-Party-Sensoren nehmen ja dieselben Datenrahmen, GEM/GAM, EAM, VARIO, GPS, wären also vom "glücklichen Zufall" mit abgedeckt. Du hattest es testweise provoziert, und bingo..

    Trotzdem muss das über alle Busteilnehmer implementiert sein, sonst wäre es ein tickendes Bömbchen, was vielleicht erst später, mit geänderten binären Displays (steht ja an) hoch geht.
    Lassen wir es mal bitte vorerst so stehen, das gibt Gelegenheit, es Graupner-intern zu überprüfen.

    Tom
    Like it!

  14. #119
    User
    Registriert seit
    26.09.2009
    Ort
    -
    Beiträge
    68
    Daumen erhalten
    1
    Daumen vergeben
    2
    0 Nicht erlaubt!

    Standard

    Hallo Tom,

    mit welcher Frequenz sendest Du die Openformat Daten?

    VG Michael
    Like it!

  15. #120
    User
    Registriert seit
    11.09.2009
    Beiträge
    869
    Daumen erhalten
    0
    Daumen vergeben
    0
    0 Nicht erlaubt!

    Standard

    Alle 100ms ein Datensatz. Der Master of Disaster ist der JIVE, seine Pakete und seine Timestamps in diesen. Also, schneller als 100ms wird es nicht.
    Like it!

Ähnliche Themen

  1. Probleme mit Graupner HoTT Telemetrie
    Von Aeddche im Forum Fernsteuerungstechnik
    Antworten: 27
    Letzter Beitrag: 08.01.2012, 19:26
  2. DX8 Telemetrie Sensoren - DIY
    Von JST im Forum Fernsteuerungstechnik
    Antworten: 1
    Letzter Beitrag: 05.11.2010, 17:21
  3. Telemetrie für Graupner-IFS ??
    Von rmmx im Forum Fernsteuerungstechnik
    Antworten: 9
    Letzter Beitrag: 31.05.2008, 10:21

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •