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

flying-doctor schrieb:

Ja, das wäre dann eine komplette Protokollsequenz.
Der Code funktioniert aber wunderbar!

Offenbar verarbeitet der Empfänger zuerst die Antwort,
bevor er einen neuen Request.
Es klappt und daher würde ich jetzt ungerne mit Interrupts arbeiten.
Außerdem ist der aktuelle Code rechtlich einwandfreier (nur "antworten")

Zum Vergrößern anklicken....

Hi,

V4 arbeitet aber mit mehreren Sensoren und Request.
"Zuhören" ist nicht nur für den Request notwendig, sondern auch für Kollisionsvorsorge.

Bei V4 können mehrere Sensoren gleichzeitig online sein. Zwar wird jeder Sensor einzeln mit einem Request abgefragt, aber wenn ein anderer Sensor Daten sendet die wie ein "Request" vom Empfänger aussehen, kann es zur Kollision kommen.

Das heist, man muss nicht nur auf den Request hören, sondern auch "hören" ob es wirklich ein Request ist oder eben Daten von anderen Sensoren.

Ich weis, arbeiten mit Interrupts ist kompliziert, aber es geht eigentlich nix an Interrupts vorbei.

PS: mit Interrupts kann man den den Ablauf sehr viel schneller machen

Grüße

Hallo,

habe mir die Checksummenberechnung angesehen. In der verlinkten V3 Spec besteht das Prüfbyte aus den letzten 8 bit der Summe aller Datenbytes (inkl. Start- und Endekennung).

Mit den hier geloggten Daten kann ich das bestätigen. Warum verwendet Tecdino eine ganz andere Berechnung?

#include <stdio.h>

typedef unsigned int uint16_t; // 16 bit unsigned
typedef unsigned char uint8_t; // 8 bit unsigned

uint8_t daten1[] = { 0x7c, 0x8d, 0x00, 0xd0, 0xcf, 0xcf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0xf2, 0x01, 0x30, 0x75, 0x78, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x80, 0x7d, 0x84 };


uint8_t daten2[] = { 0x7C, 0x89, 0x00, 0x90, 0x00, 0xF3, 0x01, 0xF4, 0x01, 0xF3, 0x01, 0x3A, 0x75, 0x30, 0x75,
0x08, 0x75, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x7D, 0xc0 };

uint8_t daten3[] = { 0x7C, 0x89, 0x00, 0xF4, 0x01, 0xF4, 0x01, 0xF4, 0x01, 0x58, 0x75, 0x30, 0x75, 0x30, 0x75,
0x00, 0x7D, 0x78 };


uint8_t crc(uint8_t *sensordaten, uint8_t startbyte, uint8_t endbyte)
{
uint16_t sum = 0;

for (uint8_t i = startbyte; i < endbyte; i++) {
sum = sum + sensordaten;
}

return sum & 0xff;
}

int main()
{
printf("CRC expected = %2x, CRC calculated = %2x\n", daten1[sizeof(daten1)-1], crc(daten1,0,sizeof(daten1)-1));
printf("CRC expected = %2x, CRC calculated = %2x\n", daten2[sizeof(daten2)-1], crc(daten2,0,sizeof(daten2)-1));
printf("CRC expected = %2x, CRC calculated = %2x\n", daten3[sizeof(daten3)-1], crc(daten3,0,sizeof(daten3)-1));

return 0;
}

Ergebnis:
CRC expected = 84, CRC calculated = 84
CRC expected = c0, CRC calculated = c0
CRC expected = 78, CRC calculated = 78

mha1 schrieb:

Hallo,

habe mir die Checksummenberechnung angesehen. In der verlinkten V3 Spec besteht das Prüfbyte aus den letzten 8 bit der Summe aller Datenbytes (inkl. Start- und Endekennung).

Mit den hier geloggten Daten kann ich das bestätigen. Warum verwendet Tecdino eine ganz andere Berechnung?
...

Zum Vergrößern anklicken....

Hi,

Summe aller Bytes, dann die letzten 8 Bit funktioniert mit V3 und V4, im Binär und Textmodus.

Grüße

CRC

CRC

CRC:

Alle Bytes ab Byte 1 eines Message Blocks und inklusive des Endezeichens (also alles außer CRC, logischerweise) in einer unsigned 16Bit-Variablen addiert, und davon das Low-Byte.

Identisch für Textmode (173 Bytes inkl. CRC) und sensorbezogenen Binärmode (45 Bytes inkl. CRC) und SmartBox-bezogenen Binärmode (55 Bytes inkl. CRC), also SmartBox an einem Tx-Modul, wobei es ja noch einen Header mit Rx-Daten gibt.

(Das war eben v4 da oben, also die Message-Block-Längen. Das CRC wird ansonsten in v3 identisch berechnet. Übrigens schert sich die SmartBox einen Feuchten um stimmendes CRC, via Rx-Tx muss es aber stimmen.)

MeiT hatte es schon.

----------

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:

Es können sich mehrere Sensoren (Slaves) parallel auf dem 1-Wire-Bus befinden.
Um insbesondere im Binärmodus zu verhindern, dass ein Sensor n+1 die gerade gesendeten Daten
eines Sensors n versehentlich als seine Adressierung mißversteht, muss ein Idle-Line-Protocol
definiert werden:
Ist ein Sensor der Meinung, er wurde gerade angesprochen (0x7F sensorID (Text) oder 0x80
binäreSensorID), prüft er nach einer Pause von 5ms+, ob nicht inzwischen ein anderer
Sensor gesendet hat (prüft seinen UART-Buffer oder wie auch immer). Hat ein anderer Sensor
gesendet, handelte es sich nicht um eine Adressierungssequenz, sondern einen binären Byte-
String der Daten eines anderen Sensors, der zufällig so aussah. Somit wird Kollision auf dem
Bus verhindert, oder, andersherum, Koexistenz per serieller Adressierung auf dem Bus
ermöglicht.

Das HoTT-Idle-Line-Protocol schreibt 5ms Wartezeit nach (vermeintlichem) Empfang der
eigenen ID und danach prüfen auf Busaktivität zwingend für alle Busteilnehmer vor!

Ein Sensor muss seine Antwort-Bytes im Abstand von nicht weniger als 2ms senden, aber auch
nicht mit viel größerem Abstand, um die Anzahl der Bytes im jeweiligen Zeitfenster übertragen zu
können (Textmode: -->2 Bytes <--3+168+2 Bytes, Binärmode: -->2 Bytes <--45 Bytes).

Zum Vergrößern anklicken....

Mehr verrate ich nicht, sonst bin ich noch schuld an Eurer Langeweile.

Tom

Danke Tom,

bin beruhigt, Du liest mit. Dann kann nichts schiefgehen.

Wurden die Datenstrukturen, außer mit Nullbytes Auffüllen auf die neuen Framelängen geändert?

Und kannst Du ein paar Worte zur Smartbox sagen? Habe bisher nur Textmode und Binärmode verstanden.

VG Michael

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 ...

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 ...

Zum Vergrößern anklicken....

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.

Zum Vergrößern anklicken....

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?

Zum Vergrößern anklicken....

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..

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

mha1 schrieb:

...Hast Du zufälligen einen JLog1 Openformat log rumliegen?

VG Michael

Zum Vergrößern anklicken....

Hi,

interessanter wäre das, was aus dem Jive kommt

Damit ich ohne JLog .....

Grüße

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

dl7uae schrieb:

...
Falls Du nicht fit genug sein solltest seitens Software-UART, denke dran, Du brauchst 2 serielle Interfaces,..

Zum Vergrößern anklicken....

Hi dl7uae,

Bin HardWärker.

also lieber Hardware UART mit INTs als Software

Grüße

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 .....

Zum Vergrößern anklicken....

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.

Hi,

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

Grüße

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...".

dl7uae schrieb:

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...".

Zum Vergrößern anklicken....

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

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?

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?

Zum Vergrößern anklicken....

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

dl7uae schrieb:

...
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:.

Zum Vergrößern anklicken....

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

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

Hallo Tom,

mit welcher Frequenz sendest Du die Openformat Daten?

VG Michael

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.