Neue Dekodiersoftware am Markt! - BosRadio

[sebi911]

win xp pro. scanner über diskri ausgang an line in

[5.01.MaD]

dann geh mal auf "nachrichten suchen" und gib nen sinnvollen zeitraum ein (standard ist innerhalb der letzten 2 stunden)
da zeigt er dann alles was reinkam. in der normalen liste zeigt er nur rics, die du für diese liste als erwünscht definiert hast

trotzdem würd mich interessieren warum er immer angibt "textnachricht ist verschlüsselt" wenn er sie in der db.log korrekt darstellt (nur umlaute und ß nicht)

[5.01.MaD]

die antwort hab ich jetzt selber:


nachrichten ohne umlaute (und in welcher alarmierung kommt mal kein "ß" von "straße" vor ? ) werden dargestellt.
selbst wenn ich programmintern nen alarm simuliere und umlaute in den text packe wird er als verschlüsselt angezeigt


aber bis auf die sache mit den umlauten funktioniert das teil recht zuverlässig und wertet wenig mist aus.

ich nehm mal an dass der fehler schnell zu beheben ist:

\u00df = ß
\u00fc = ü
\u00e4 = ä
\u00f6 = ö

[sebi911]

ne. klappt auch nicht. findet nix

[5.01.MaD]

scanner an richtige buchse angeschlossen?
scanner auf richtiger frequenz eingeschaltet?
eingangsquelle am PC ausgewählt/aktiviert?
richtigen kanal in BosRadio gewählt (ob das scannersignal auf dem linken oder rechten audiokanala ankommt)?
diskriminatorausgang am scanner verwendet?

geh mal in bosradio in die typenansicht (erstes symbol).
dann rechte maustaste auf einen der ordner -> "neuer pocsag typ"
da gibtst du dann einen namen ein oder auch nicht und lässt bei ric die "0" stehen, dann wertet er alle aus.

der neue typ sollte dann in dem ordner sichtbar sein. zieh ihn dann mit der maus per drag&drop in das feld in dem die alarmierungen angezeigt werden sollen. die typenansicht kannst du dann schließen.

bei rechter maustaste in das auflistungsfeld sollte unter "filter" dann der reingezogene pocsag-typ sichtbar sein.

er müsste dann eigentlich alles anzeigen was reinkommt, mit ausnahme des oben von mir beschriebenen umlautfehlers

[Bruno-FF12-EL]

Hi,

ist es geplant, codedateien z.B. von anderen Programmen (FMSCrusader, FMS32, BOSControl...) zu importieren?

[frontloop33]

was ich auch noch schön fänd, is, dass man z.B. auf eine nicht-zugeordnete Schleife rechtsklickt und dann diese gleich mit einem Namen versehen kann.
Also, sich den Umweg um den Editor mit Schleife und Name eingeben spart.

[jdi]

5.01.MaD hat die Sache richtig erkannt.
Auf einigen Systemen werden Nachrichten mit den Sonderzeichen äöü und ß fälschlicherweise als Verschlüsselt identifiziert. Die genaue Ursache ist noch unklar, aber spätestens am Mittwoch wird ein Patch erscheinen, der das Problem behebt.

Ansonsten freue ich mich, als einer der Entwickler von BosRadio, über das große Interesse am BosRadio. Natürlich werden wir so viele Erweiterungswünsche wie möglich in die nächste Version aufnehmen. Ganz oben auf der Liste stehen die folgenden:
- Import von RIC-, Fahrzeug- und ZVEI Listen
- Schleifen per Rechtsklick zu den Typen hinzufügen
- Programm bekommt beim ersten Start eine Konsole, die alles anzeigt.

Außerdem werden wir wie gewünscht einen Installer ohne Java zum Download anbieten.

gruss
jdi

[ElectricDreamBoy]

@jdi und Trollix
muß sagen der erste Test begeistert mich: tolle Auswertequalität.
Momentan werte ich mit FMSCrusader-Server und FMS32pro aus und lasse beides auf einem FMSCrusader-Client anzeigen.
BosRadio hat heute abend besser ausgewertet aus die anderen beiden zusammen; Respekt.
Wunsch: wie bereits von MiThoTyN: BosRadio als Server
Das Problem bei uns ist, dass wir z.T. sehr lange Fahrzeugnamen verwenden und nur der FMSCrusader das bisher zulässt z.B. "(Florian) Hinterholzwasweißich 42/1"
Wie sieht es mit der Auswertung beider Kanäle mit ZVEI und FMS aus?
Benötige 2 Kanäle (RD und FW) mit jeweils ZVEI und FMS.
Gruß
Reinhard

[Trollix]

Hallo ElectricDreamBoy!

Danke für Dein Kompliment. Schön das auch ein "neutraler" die Auswertequalität so positiv bewertet wie wir das prophezeihen ohne das es gleich nach "Werbung" aussieht ;-) Auch wenn ich an dieser Stelle nocheinmal ohne Selbstüberschätzung aber mit bestem Wissen und Gewissen sagen kann das die Art und Weise unserer Decodierung unübertroffen seines gleichen suchen wird.

Die Auswertung von ZVEI+FMS bzw. für einige andere dann wohl auch POCSAG auf beiden Kanälen nehmen wir in unsere ToDo-Liste mit auf, ebenso die Darstellung von langen Fahrzeugnamen.

Die bereits mehrfach gewünschte Netzwerkfähigkeit ist sicherlich kein großes Problem. Rückt aber in der Realisierung ersteinmal auf die hinteren Plätze.

Kann mir eigentlich jemand ein überzeugendes Argument liefern wofür man diese Funktion benötigt? Innerhalb unserer Stadtfeuerwehr - und die ist nicht klein - würde das z.B. keine Verwendung finden bzw. gefordert sein. Die Bereitstellung von dekodierten Funksignalen im Netzwerk ob lokal oder, dann ja auch ein leichtes, dezentral im Internet, läßt mich ohnehin an der Legalität im Rahmen des TKG zweifeln...

Gruß
Trollix
www.bosradio.de

[5.01.MaD]

die auswertung ist wirklich top.
fms32 kommt bei pocsag nur müll, poc32 kriegts ziemlich sauber hin (zumindest bei eingeschaltetem filter) und bosradio ist noch besser (wenn er die auswertungen dann bald auch anzeigt...)

was ich auch noch gut fände:
in der anzeige nicht eine durchgehende textzeile sondern in tabellenform mit einstellbarer spaltenbreite, dann wirds übersichtlicher. weil nicht alle ric-aliases gleich lang sind und so die nachricht auf unregelmäßige position nach hinten verschoben wird

und ne einstellmöglichkeit für die "standard stati" wäre toll, denn F0 ist kein probealarm, und ich wills nicht noch bei jeder ric löschen müssen, die eingabe ist schon aufwändig genug (bei tabellenform könnt ich die spalte dann auch ganz außer sicht nehmen)

und der schönheit halber nach den kommata (bei der auflistung von verschachtelten ordnern) noch ein leerzeichen bevor der nächste ordnername oder der ric-alias kommt

[MiThoTyN]

... läßt mich ohnehin an der Legalität im Rahmen des TKG zweifeln...

Auch ohne die Netzwerkfähigkeit bewegt sich die Software schon lange nicht mehr im legalen Bereich. Das ist also kein Grund GEGEN eine Netzwerkfähigkeit.

Es geht auch bei der TCP/IP Schnittstelle weniger darum das Signal über weitere Strecken zu transportieren, als das Bosradio erweiterbar zu machen.
Ich habe mir hier einige kleine Programme selbst geschrieben, die u.A. eine SMS Alarmierung vornehmen, oder automatisch meine Codedatei pflegt. Diese Programme docken per TCP/IP bisher am Crusader an. Das ganze über Aktionen zu machen ist keine akzeptable Lösung.

Weiterhin bestünde dann die Möglichkeit verschiedene Clients zu benutzen zur Anzeige. Jeder hat hier ja einen "LieblingsClient". Das muss man den Usern zugestehen.

Und zu guter Letzt ist es bei mir so, dass der Auswerterechner bei mir im Keller steht und 24/7 läuft (wegen SMS-Alarm). Mein ArbeitsPC steht aber 2 Etagen weiter oben. Trotzdem würde ich gerne bei mir am PC die Statis sehen. Und dazu bräuchte man eben Netzwerkfähigkeit.

Ich an eurer Stelle würde den Sprung zu einer Schnittstelle nicht verpassen. Man hat jetzt an FMS32 gesehen wie sehr so eine Schnittstelle gefragt ist. Ich für meinen Teil kann ohne TCP/IP mit dem Programm nix anfangen und würde es mir auch nicht kaufen.

Gruß Joachim

[Bluebird145]

Hallo!

Leider bekomme ich, wie auch ein Kollege das Programm garnicht ans laufen. Es wird weder FMS noch POCSAG decodiert.

Ich starte BOS-Radio und habe entsprechend die Kanäle auf links / rechts aufgeteilt. Es wird aber nichts empfangen. Habe dann den Tipp mit der Suche und den Logs versucht, da erziehel ich aber ebenfalls keinerlei Ergebnis.