Denke auch, als der Downloadbereich bei SW noch ging konnte die man ja frei downloaden.Zitat:
Zitat von evos
Problem wird nur sein dass die ohne Dongle nur begrenzt taugt.
Druckbare Version
Denke auch, als der Downloadbereich bei SW noch ging konnte die man ja frei downloaden.Zitat:
Zitat von evos
Problem wird nur sein dass die ohne Dongle nur begrenzt taugt.
Ist so knapp 100MB groß.
PN Postfach ist wieder geleert, ich wäre dankbar!!
Meine uralte CD hat schon 454 MB, das passt eher in kein Postfach.
Hab nen FTP... wenns hilft...
Würde mich anschließen [emoji4]
Gesendet von iPhone mit Tapatalk
Ohne Dongle arbeitet die DigiCom NT Software IMMER im Demomode.
Geschützt ist die Commodul.exe, die Zentrale quasi.
DigiCom NT und Commodul unterhalten sich im TCP/IP Protokoll untereinander. Das Commodul spricht die verschiedenen Peripheriegeräte an; DAU, ISDN, ELR...,
Im Demomode erkennt die DigiCom, das das Commodul.exe läuft, aber keine Verbindung besteht. Daher kann auch kein Connect über das Commodul zum DAU hergestellt werden; noch nicht mal ne Initialisierung.
Man müsste entweder an den Dongle kommen, oder alles aus dem Logfile des Commodul studieren, vom Initialisierungsvorgang an beginnend.
Ich habe heute exakt das gleiche geschlussfolgert. Scheinbar sind wir beide gleich blöd :D
Ich denke auch, dass das TCP/IP-Log im ComModul interessant sein könnte. Das Initialisieren und auch Aussendungen werden ja im Klartext mitprotokolliert. Allerdings muss man dann immer noch wissen, wie das ComModul die Daten an die serielle Schnittstelle gibt...
Alles nicht einfach. Grr.
Mit meinen Frequenzen bin ich auch immer noch nicht viel weiter. Habe schon aus den 8 Kanälen 14 machen könnten (hatte ich dir schon gemailt), aber ja evtl für andere Interessant. Folgende Kanäle habe ich "geprommt":
(BOS-Kanäle 2m):
23
25
27
29
34
37
38
39
43
50
53
55
56
59
Also: Ich habe unseren Reserve DAG mal gestoppt und neu gestartet. Das Log welches er schreibt ist anbei. Es läuft erst mal eine Initialisierung "INI" dann irgendwelche krytischen Kommandos zum DAU, dann eine zyklische Aussendung "1398098". Ich habe dann mal einen Testalarm ausgelöst, der ist deutlich zu erkennen, und dann das ganze wieder beendet.
Die Telegrammstruktur ist auch gut zu sehen, alles beginnt mit STX (\02), die anderen Steuerzeichen sind genauso dargestellt (\0A, \0D). Nach STX kommt immer ein zweistelliger Zähler, danach das/die Kommando(s) und eine Prüfsumme (zweistellig).
Wenn man die entsprechenden Zeilen mit einem Terminalprogramm sendet sollte es schon gehen. Beim Terminalprogramm eine Zeilenverzögerung von ca. 1000ms einstellen.
Interessant wäre mal was z.B.
(BPL) "localhost"->DAG: \0204GIN5A;5B;5C;5D;5E;5F;60;61;62;63;6B;6C;6D;6E; 6F;70;71;78;79;7A;7B;7C;7D;82;9B\0D\0A"
bedeuten soll????
Könntest du noch das Logfile anhängen, das fehlt noch...
Dann würde ich mal etwas testen...
Gesendet von iPhone mit Tapatalk
Sorry, hatte ich eigentlich angehängt, weiß nicht wo es hin ist....
Muss es wieder suchen, vermutlich morgen.
Neuer Versuch, diesmal mit gültiger Dateiendung.....
Anbei noch mein Kommentierungsversuch zu den einzelnen Feldern (gekennzeichnet mit >> am Zeilenanfang), Originaltext zur besseren Lesbarkeit teilweise mit Leerzeichen separiert
Bin gerade am Basteln, die Stellen die du kommentiert hast werden wohl für die Kommunikation mit dem DAU irrelevant sein, da nur die DAG->DAU und umgekehrt die Kommunikation über die serielle Schnittstelle beschreiben.
Bin gerade dabei dein Beispiel in eine Python Klasse zu überführen...
Gesendet von iPhone mit Tapatalk
Oh ja, da hab ich mich etwas verannt.... Nach Deiner Ansicht wäre ja dann aber (fast?) nur noch
(27.07.2015 10:13:47) (DAU) DAG->DAU COM1:
"\02[ITC300AABCDEFGH]9874b[Technische Hilfe 0123456789 Testalarm]\04GI\0D\0A"
nötig und das Teil müsste loslegen....