monitor 1.9.0 - aber richtig :)

[Dove]

thx habs an PROGS dran gehangen nu gehts.

[PolyMorPhisMus]

Das ist echt ein tolles Projekt, ich bin begeistert! Weiter so!

FMS und ZVEI dekodiert er bei mir ohne Probleme, nur POCSAG 512 geht irgendwie nicht...

Da ist immer noch ein kleiner Syntax-Fehler:
base64.cpp: In function »std::string base64_encode(const std::string&)«:
base64.cpp:60: Fehler: expected unqualified-id before »;« token
> unsigned int in_len = in_string.length() ,;

[Buebchen]

Danke im Namen des Teams.

Den Fehler im base64 kannst Du leicht beheben. Das Komma vor dem Semikolon gehört da nicht hin. Loeschen. Danach sollte es sich kompilieren.

Die POC512 Auswertung habe ich bisher nur mit dem BOS-Tool getestet. Aber wenn er so garnichts auswertet finde ich das schon seltsam. Du könntest als Test mal den Kanal fest im Scanner auswählen. Bleibt der Scanner recht spät auf dem POCSAG Signal stehen und die Sync kommt nicht mehr mit. Einige Werte werden noch nicht als dem XML ausgelesen.

Andere Frage, wäre was in Deiner monitord.xml drin steht. Ich werte bei mir nur den linken Kanal aus. Ggf hast Du POCSAG auf dem rechten Kanal ?

Wobei POCSAG auch gerne mal ein paar Fehlauswertung noch einer korrekten ausgibt. Das muss ich mich auch nochmal angucken.

[Medic]

Was steht eigentlich in der Kanalbezeichnung drin?
Ist das Links oder Rechts für den Audiokanal wo es rein kam oder wie muß ich mir das vorstellen?

[funkwart]

[...]
Ist das Links oder Rechts für den Audiokanal wo es rein kam[...]?

Exakt!

Gruß,
Funkwart

[Buebchen]

Du kannst auch statt "Links" und "Rechts" auch z.B. keine Kanalnummer oder einen Namen "Leistelle BlaBlaBla" nehmen.

Sofern du diesen Teil hier meinst: (Spitze Klammern durch eckige ersetzt). Ich habe hier Kanal1 und Kanal2 drin.

monitord.xml:

[channel part="left"]
[name]Kanal 1<[/name]
[/channel]

[channel part="right"]
[name]Kanal 2[/name]
[/channel]

... bin mir aber gerade nicht sicher, ob ich das überhaupt schon mit ausgeben :-)

[Medic]

Ok, dann sollte ich die funktion für die Nutzung doch drin lassen. Hatte sie nämlich gerade auskommentiert ;)

Wie sieht eigentlich die Übertragung von FMS-Text aus im neuen Kommprotokoll aus?

[Buebchen]

... bin mir aber gerade nicht sicher, ob ich das überhaupt schon mit ausgeben :-)

jetzt schon. SVN geupdated (Nur unter Win32 getestet. Sollte unter linux aber genauso compilieren).

[PolyMorPhisMus]

Andere Frage, wäre was in Deiner monitord.xml drin steht. Ich werte bei mir nur den linken Kanal aus. Ggf hast Du POCSAG auf dem rechten Kanal ?

Wobei POCSAG auch gerne mal ein paar Fehlauswertung noch einer korrekten ausgibt. Das muss ich mich auch nochmal angucken.

{soundcard num=0}
{status}1{/status} {!-- 1=aktiv, 0=deaktivert --}
{baud}22050{/baud}
{name} Erste Sondkarte {/name}
{!-- Linker Kanal --}
{channel part="left"}
{name}Kanal 1{/name}
{module type="fms"}
{vorlaufbits} 8 {/vorlaufbits}
{crc-check} 1 {/crc-check}
{/module}
{module type="poc512"}
{crc-check} 1 {/crc-check}
{ecc} 0 {/ecc}
{/module}
{/channel}

{!-- Rechter Kanal --}
{channel part="right"}
{name}Kanal 2{/name}
{module type="zvei"}
{/module}
{/channel}
{/soundcard}

{soundcard num=1}
{device}/dev/dsp1{/device}
{status}0{/status} {!-- 1=aktiv, 0=deaktivert --}
{baud}22050{/baud}
{name} Zweite Sondkarte {/name}
{!-- Linker Kanal --}
{channel part="left"}
{name}Kanal 1{/name}
{module type="fms"}
{vorlaufbits} 8 {/vorlaufbits}
{crc-check} 1 {/crc-check}
{/module}
{module type="poc512"}
{crc-check} 1 {/crc-check}
{ecc} 0 {/ecc}
{/module}
{module type="zvei"}
{/module}
{/channel}

{!-- Rechter Kanal --}
{channel part="right"}
{/channel}
{/soundcard}

Ich habe es auf beiden Kanälen ausprobiert, werde mir nachern nochmal den Code reinziehen...

EDIT1:
Achso, bei meckert der Compiler auch noch ntserv.cpp:1729 an, da fehlt noch ein int, da das noch nicht deklariert wurde (ausser in der for Schleife davor, wa ja nach C++ Standard nicht zählt)

EDIT2:
Könnte es wohl daran liegen, das demod_mg noch nicht wirklich implementiert ist?
void MonitorModulePocsag::demod(float *buffer, int length)
{
switch (m_iAlgorithmus)
{
case 0:
demod_mg(buffer, length) ; // war demod_se ...
break ;
case 1:
default:
demod_mg(buffer, length) ;
} ;
}

void MonitorModulePocsag::demod_mg(float *buffer, int length)
{

}

EDIT3:
Wäre es nicht besser Threads als neue Prozesse und Linux zu nehmen?
Möglich währe der Einsatz der Posix libpthread die auch unter Windows funktionieren sollte...

[Buebchen]

EDIT1:
Achso, bei meckert der Compiler auch noch ntserv.cpp:1729 an, da fehlt noch ein int, da das noch nicht deklariert wurde (ausser in der for Schleife davor, wa ja nach C++ Standard nicht zählt)

Seltsam. Das ist dem Compiler von VC 7.1 egal und er findet's ok. Ich glaube VC 6.0 hatte damals sogar sonst nen Fehler gemeldet. Wobei das schon stimmt. Die Initialisierung gilt eigentlich nur innerhalb der for-Schleife. Werde das SVN beim nächsten mal dahingehend updaten.

Welchen Kompiler nutzt du ?

EDIT2:
Könnte es wohl daran liegen, das demod_mg noch nicht wirklich implementiert ist?
void MonitorModulePocsag::demod(float *buffer, int length)
{
switch (m_iAlgorithmus)
{
case 0:
demod_mg(buffer, length) ; // war demod_se ...
break ;
case 1:
default:
demod_mg(buffer, length) ;
} ;
}

void c::demod_mg(float *buffer, int length)
{

}

Hmm.Die demod_se() Funktion war mal so ein Test. Hatte aber nicht so richtig geklappt (bisher). Deshalb erstmal fest die demog_mg().

Die Funktion ist für POC512 in MonitorModulePocsag512.cpp definiert. die demod_-Funktion sind als virtual definiert. Ggf. ein Problem, wenn im std::vector Zeiger auf die Basisklasse definiert sind, daß zur Laufzeit dann der Klassentyp nicht korrekt erkannt wird ? Dann genau würde er nämlich die leere demod_ Funktionen aufrufen.

class MonitorModule ;

typedef std::vector MonitorModuleArray ;

Die Auswerter sind aber abgeleitete Klassen. Aber eigentlich sollte das gehen...

EDIT3:
Wäre es nicht besser Threads als neue Prozesse und Linux zu nehmen?
Möglich währe der Einsatz der Posix libpthread die auch unter Windows funktionieren sollte...

Eigentlich hätte ich jetzt gedacht, daß ich statt Prozesse Threads bildet. Unter linux habe ich noch nicht nachgeschaut. Aber unter Windows wird CreateThread aufgerufen. aber ein pthread_t als Datentyp für linux würde doch auf die pthreads hinweisen, oder ?