J-Log.eu - Forum

Hallo Tom,

bei der neuen MZ-24 muss ich vor jedem Flug die Ansage für den ESC (Jlog) neu auswählen, damit ich die Daten angesagt bekomme.
Die Warnungen funktionieren trotzdem.
Im Graupner Forum wurde dies bereits diskutiert, dort wurde allerdings auch bestätigt, dass der "Fehler" bei den originalen Graupner Reglern nicht auftritt.

Hast du eine Idee woran es liegen könnte?

Danke und Gruß
Peter

Moin!

Nee, Du, kann ich mir absolut keinen Reim darauf machen, weil das Setup des Senders für fortlaufende Ansagen überhaupt nicht durch Sensoren beeinflussbar ist.

Es gibt nur eine Adresse, auf die ein Sensor reagiert, und Daten von ihm.
In diesen Daten gibt es Invertierungsmarker (im pseudografischen Display verwendbar, also im Binärmode, z.B. bei Alarm) und es gibt Alarme 'A'-'Z', die jeder Sensor senden kann, die aber teilweise (seit "ESC") unterschiedliche bzw. keine Interpretation erfahren.

Letzteres ist die einzige (indirekte) Schnittstelle zum Voice Module, - alles andere geht allein im Sender ab, in dessen Setup.

Da wird wohl ein Bug in der Senderfirmware sein.

Als was läuft JLog, als "GAM" oder "ESC"?
Wurde dann entsprechend mit einem Graupner/SJ "GAM" bzw. "ESC" (BLC+T) getestet?

_________________
Tom

HI.

hm... der Meinung bin ich eigentlich auch, aber da sich im Graupner Forum keiner so richtig äußert, außer die Info, dass der originale ESC die Probleme nicht hat, dachte ich, ich frage zumindest mal um Rat.

(ww.gh-lounge.de -> http://www.gh-lounge.de/index.php?optio ... Itemid=516)

Kann es denn sein, dass die "Ansagen" per Telemetrie mit nem Flag zurück an den Sensor geschickt werden und dieser die Flags bei jedem erneuten kommunizieren überträgt?

GAM konnte ich noch nicht testen, werde ich aber ausprobieren.

Danke.

Gruß Peter

Ich habe keinen Account in der Lounge (mehr). Der Stolz des lokalen Blockwarts, der mir aufzwingen will, meinen realen Namen als Nick zu verwenden, war viel größer als der Respekt vor bzw. der Bedarf an Know How. Auf so was kann ich auch gut verzichten.

Wie gesagt, der Sensor kann das nicht beeinflussen. Es könnte aber gut sein, dass ein Bug in der Senderfirmware irgendwie ausgelöst werden könnte. Mein Eindruck ist eh, dass die Implementierung des ESC im Sender buggy ist. Wie kann es z.B. sein, dass nur dieser Sensortyp einfach verweigert, bestimmte Alarme auszugeben?! Das Protokoll definiert Alarmtypen als GLOBAL, wie kann man es also als normal betrachten, dass dem plötzlich mit einem weiteren Sensor "ESC" zuwider gehandelt wird!

Das ist alles ein Pfusch, und meinereiner soll es immer ausbaden, inzwischen für 8 Telemetriesysteme. Und dabei sehe und weiß ich ja, was für "Professionalität" dahinter steckt...

_________________
Tom

Es hört sich so an, als ob du das Protokoll kennst. Gibt es Unterlagen dazu? Weißt du wo?

Ich bin mir ziemlich sicher, dass Du es nicht ausbaden musst und ich denke ich spreche im Namen vieler, dass Du hier einen Hammer Job machst und viele Hersteller, nicht nur Kontronik, Dank zeigen könnten.

Mein Dank hast du auf jeden Fall.

Gruß
Peter

Ich weiß ja nicht, wie es heute ist, aber über eine sehr lange Zeit war die Protokollbeschreibung, die Graupner auf Anfrage raus gab, von mir. Inzwischen gibt es den "ESC" (erst den "alten", dann den "neuen", wobei Ralf bzgl. des "alten" dann einen auf Altzheimer machte, der wäre nie offiziell gewesen. Komisch nur, dass TelMe HoTT Ewigkeiten nicht funktionierte, weil Kontronik den angeblich "inoffiziellen" "ESC" implementerte.), den habe ich nicht nachgepflegt in dem Pamphlet, das is seit Langem statisch.

Erstausgabe vom 21.12.2011, letzte Änderung 1.3.2012.

Das waren damals gewisse Akte der Freundschaft gegenüber Ralf und Graupner, war ja auch 'ne heiße Nummer Weihnachten 2011, HoTTv4 und MC32 gleichzeitig. Der Name "v4" kam dann auch von mir, nachdem wir mal innerhalb eines Tages von v2 auf v8 landeten. Das Kind will schließlich einen Namen haben, egal welchen.
Na ja, und wen wundert's, SJ's Entwicklung hatte ein ziemliches Eigenleben, und jetzt sicherlich erst recht. Was soll's, auf meine Pfeife hören die leider nicht, sonst hätte z.B. auch nicht der Blödsinn mit dem Sensor Scan stattgefunden, jedenfalls nicht in der Form. Unser wahrer Held ist Ralf, damals und heute, bloß sind dem auch oft die Hände gebunden. Immerhin hatte und hat das System ja Erfolg, mehr, als ich ihm je zugetraut hätte.

_________________
Tom

Ich krieg'n Kicherkrampf, was für eine messerscharfe (Un-)Logik.

So was hört man sich auch als Funkamateur an, wenn sich etwas gestört fühlt. Nur gehören dazu immer zwei. Wenn z.B. Kabel-TV terristrische Frequenzen exklusiver Bandnutzer verwendet, dann ist das Unrecht eigentlich auf deren Seite, und sie stören auch immens, nicht nur den Amateurfunk, sondern auch z.B. die Polizei im 2m Band.

Falls dann überhaupt noch die ausführende Firma im Preisdruck des Konkurrenzkampfes doppelt geschirmtes Koaxkabel verlegte (vom Übergabepunkt durch das Haus zur Mietpartei), kommt am Ende der TV-User, Oma Freudenreich, - und der zieht lustig irgendwelche Strippen durch die Bude, die sich als Antennen betätigen. Der Müll wird nicht nur zum Störsender, er fängt sich auch die Ausstrahlungen der exklusiven Bandnutzer ein, Streifen und schwarzes Bild als Folge.

Tja.., Leo, und dann kommt so eine Logik, wie Du sie vorträgst: "Wenn Du nicht sendest, ist alles ok. Also bist allein Du schuld, - hör' auf zu senden!"

Mannomann... Leo!

-------
Meine Logik sieht anders aus: JLog als "ESC" an einem anderen HoTT Sender, nicht MZ, gibt's da auch diesen Effekt? ...

Der BLC+T ist übrigens ein ziemlich schaumgebremstes Ding, was Telemetrie betrifft. Er liefert nur sehr wenige Daten, er bedient den Text Mode nicht, während er kommutiert, das schafft dann dessen Prozessor nicht. Ich weiß das, weil ja bekanntlich JLog den BLC+T auch als ESC bedient, als Logger und Gateway in die anderen 7 Telemetrien, sogar wieder in HoTT, wodurch es dann doch Text Mode gibt, oder man den BLC+T als GAM sehen kann, wenn man will.

Ich weiß, dass die Senderfirmware hoch und runter buggy ist. Ich weiß, dass bestimmte Bugs erst in Erscheinung treten,
- wenn ein Sensor alle Data Items bedient, oder,
- wenn viele verschiedene Sensortypen gleichzeitig auf dem Bus sind, oder,
- wenn ein Sensor bzw. Sensoren mehrere Alarme senden.

Daher hatte ich im vorigen Jahr Graupner ein Gerät zur Verfügung gestellt (HTI + Live Data Emulator), was alle 5 Sensoren gleichzeitig bedienen kann (1..5), und dann richtig, alle Data Items (Sub Displays), alle Alarme, mehrere Alarme gleichzeitig. Da kann dann die Welt plötzlich nicht immer so rosig aussehen.

_________________
Tom

Hab's mal eben mit einer mx-16 ausprobiert. Ständige Ansage der Spannung aktiviert, den zum Einschalten definierten Schalter umgelegt.

Dann Sender aus/an: Quatscht immer noch.

Ich entschuldige mich, dass ich über keine MZ verfüge, dass ich nicht alles Geld in Sender investiere.

_________________
Tom

wir wollten vor einiger Zeit mal wegen dem Thema hallofonieren...
mein Eindruck eines "nichtwissenden" ist das die MZ sich irgendwie den/die Sensoren merkt... (id, was weiß ich...) und aufgrund dessen die entsprechenden Settings aus dem Speicher abruft...

offensichtlich beim Jlog aber nicht in der Lage ist das zu tun... warum .... das wollen alle wissen...

Ich habe damals alle möglichen Kombinationen ausprobiert, also Sender ein lassen, Jlog/Regler neustart.... Sender ausschalten/einschalten, JLog eingeschaltet lassen... die "Sprachausgabeeinstellung" bleibt... erst wenn beides Stromlos gemacht wird vergißt der Sender was er tun soll..

Lasst uns man noch die nächsten 15 Updates der MZ Sender abwarten. Wer weis was da noch alle bei raus kommt

Wer weis was die da noch alles rumproggen. Ich bin ja schon froh das die Telemetrie überhaupt so unkompliziert gut läuft.

Gruß Olli