ämä sivu ei ole vielä valmis! Anteeksi

Tältä sivulta löydät kaikki tarvittavat yhdyskäytävän asetukset. Valikon selkeyttämiseksi olen tiivistänyt kokoonpanotiedoston monet mahdolliset asetukset loogisiin lohkoihin ja lajitellut tarkoituksenmukaisuuden / taajuuden mukaan. Tällä on se etu, että sinun ei tarvitse selata koko kokoonpanoa vain siirtyäksesi palvelimen huoneeseen.

Vastaavia luokkia voidaan laajentaa klikkaamalla „ [+] “ -merkkiä tai, jos sitä ei tarvita, klikkaamalla „ [-] “ -symbolia uudelleen. Vastaavat muutokset hyväksytään vain klikkaamalla vihreää painiketta „Tallenna“. Lisäämään mukavuutta olen vaihtanut kentät, jotka edellyttävät vain kyllä ​​/ ei vastauksia, vastaavilla valintaruuduilla.

Napsauta „ Tallenna “, jos haluat lähettää kaikki asetukset, mukaan lukien muutokset „ Tallennukset “. Systeemi ottaa ne takaisin ja kirjoittaa ne takaisin web-käyttöliittymän tietokantaan. Sitten systeemi kutsuu „ pysäytyksen “, joka ensin pysäyttää vastaavan yhdyskäytävän, tuo sitten uuden kokoonpanon tietokannasta yhdyskäytäväkansioon ja aloittaa lopulta yhdyskäytävän uudet asetukset.

Tässä vaiheessa määritetään palvelin ja määritellän Huone joka toimii yhdyskäytävänä.

Täällä annetaan kohdepalvelimen osoite joka voisi olla muodossa (z.B. www.1a-funkfeuer.de). Vaihtoehtoisesti IP-Osoite palvelimelle (z.B.: 81.20.133.6).

Tässä on määritettävä portti, johon palvelin voidaan yhdistää.

Tämä määrittää huoneen, jossa yhdyskäytävän pitäisi toimia (z.B. Berghütte).

Tässä, kuten Windows-versiossa, näkyvyyden tila on asetettu. Mahdolliset arvot ovat: AV tai QRV, NA varattu ja AS tai poissa/QRT.

Se tapahtuu uudestaan ​​ja uudestaan, että palvelin ei ole tavoitettavissa ja / tai epäonnistuu. Tällaisissa tapauksissa FRN-protokolla sisältää varmuuskopiointipalvelimen , joka korvaa sen väliaikaisesti pääpalvelimen vian sattuessa. Jos tämä toiminto vastaa Kyllä, yhdyskäytävä jatkaa työskentelyä varmuuskopiopalvelimen kautta, jos pääpalvelin epäonnistuu. Muussa tapauksessa se yrittää ennalta määrätyn määrän uudelleenyhdistyksiä ja lopettaa sitten toiminnon, jotta se ei tarpeettomasti rasita näyttöpalvelinta uusilla pyynnöillä.

Täällä voit määrittää varmuuskopiointipalvelimen ja sen portin osoitteen.

Seuraavassa on FRN-tilin tiedot, koska ne on rekisteröity etukäteen Windows-koneessa. (Huomautus!)

ACC + „, joka on tunnettu PiGate 2.5 : sta ja PiGate 2.6beta : sta ei ole vielä toteutettu PiCQ: ssa .

Tällä rivillä voit luoda sen kutsumerkin (lisensoitu adioamatööri) tai hyppien yli tämä kohdan (varten CB-, Freenet- tai PMR-radisti) syötettävä vaihtoehtoisesti jonkun.

Tässä voi antaa etunimen yhdyskäytävän operaattorina. (Henkilökohtaisesti pidän kuitenkin eri merkintää mielekkäämmin (s. Huomautus!))

Anna tässä vaiheessa sähköpostiosoite, jota käytit FRN-tilin rekisteröinnissä (s. Huomautus!))

Sen paikan nimi, jossa yhdyskäytäväsi sijaitsee. (s. Huomautus!))

Anna Salasanasi jonka loit FRN-tilin rekisteröinnin yhteydessä ja sait sen antamaasi sähköpostiin.

Täällä on määriteltävä maa, jossa yhdyskäytävä on. -Ja täsmälleen oikeinkirjoitus , kuten se on kirjoitettu FRN: n Windows-versioissa. Jos tätä ei noudateta tiukasti, FRN- listaus monitoripalvelimelle ei valitettavasti luoda mitään yhteyttä , mikä tarkoittaa, että yhdyskäytävä ei mene verkossa. (esimerkiksi Finland) VIHJE: Jos et ole varma, miten kyseinen maa on kirjoitettu, käytä Finland toistaiseksi ja kysy myöhemmin.

Yhdyskäytävän kuvaus. (z.B. Käytetty radio, antenni jne. Tätä kenttää ei kuitenkaan näytetä muissa PiCQ-yhdyskäytävissä,mutta esim. alkuperäisessä FRN-Windows-ohjelmisto)

Riippumatta siitä, mikä on jo rekisteröitynyt, on äänikortti, jonka PiCQ löytää järjestelmässäsi!

Valikon vastakkaisella puolella on laatikko PiCQ-luettelo, josta näet mitä audiolaitteita se on löytänyt. Riippuen käytettyjen äänikorttien määrästä (1 tai 2) löydät ne muodossa „AUDIO INPUT DEVICES“ 1 tai 2 , lopussa suluissa „hw:0,0“ tai „hw:1,0“. Linux alkaa aina nollasta sen numeroinnilla.

Kopio tämä rivi nyt (kahdella äänikortilla yksi näistä kahdesta) hiirellä napsauttamalla hiirtä hiiren oikealla painikkeella ja valitset „kopio“. Sitten napsautat kentän valikkoa „syöttölaite“ (myös hiiren oikealla painikkeella) ja valitse „liitä“.

Voit tietysti myös kirjoittaa sen, mutta kirjain kirjaimella, välilyönnillä ruutuihin ja ruuduissa on oltava samat.

Vihje: Laatikossa on „AUDIO INPUT DEVICES“ näytössä näkyy vain yksi äänikortti, jota yhdyskäytävä ei tällä hetkellä käytä aktiivisesti. Tämä tarkoittaa: Jos yhdyskäytävä on käynnissä ja käyttää äänikorttia, tämä „AUDIO INPUT DEVICES“ EI ole käytössä, mutta „Output Devices“. Kuten näette esimerkissäni, Yhdyskäytävä 1 ja „AUDIO INPUT DEVICES“ kortti “…HW:0,1„ ei näy. jos yhdyskäytävä 2 on deaktivoitu (Kuvake on harmaa), siksi äänikortti tulee “…HW:1,0„ näkyy myös.

Tässä on näytetty, johon näytteenottotaajuuteen äänikortti pystyy. Tässä ei kuitenkaan voida ennustaa tarkkaa arvoa. Ihannetapauksessa syötä arvo 8000 täällä, koska silloin PiCQ: n ei tarvitse ylittää FRN: n näytteenottotaajuutta. Kokeile kerran 48000 : lla. Joissakin tapauksissa (hyvin vanhoja äänikortteja) voit jopa yrittää arvoa 44100.

Kuten edellä on kuvattu, PiCQ muuntaa näytteenottotaajuuden todellisesta näytteenottotaajuudesta (asetettu äänikortille) FRN: n edellyttämään arvoksi 8000 näytteenottotaajuuteen. Tässä voidaan nyt määrittää, missä laadussa tämä tapahtuu. Raspberry Pi2: n pitäisi jo käsitellä „ H “ korkeaa. Raspberry Pi1: n tai Zero: n kanssa jätän sen „ M “ keskelle. Ja jos lataat Pi1 tai Zero 2 yhdyskäytävällä, menisin jopa „ L “ matalalle.

Tällä kertaa määritetään pieni puskurin koko. PiCQ tarvitsee jonkin aikaa ( VOX-tilassa, esimerkiksi signaalitason arvioimiseksi ja reagoimiseksi tai COS-signaalin arvioimiseksi ja reagoimiseksi ). Siksi äänisignaali ladataan täten tähän puskuriin tämän ajan sallimiseksi. Jos tämä on liian pieni, voi tapahtua, että lauseet voi pätkiä lähetyksen aikana. - sinun ei pitäisi valita liian suurta, muuten yhdyskäytävä on liian hidas aktivoitumaan. Paras 500 ms: n arvo.

HpF tarkoittaa „High pass Filter“. Sen myötä ei-toivotut äänet vaimenevat.

Järjestys määrittää suodattimen kaltevuuden. 5 arvo on osoittautunut suotuisaksi.

Jos kyllä, vaikutus olisi kaksinkertaistettava. ( hmm, hyvin )

AGC tarkoittaa „automaattista vahvistuksen ohjausta“. Näin varmistetaan, että eri äänekkäitä asemia, mutta aivan samanlaista ääntä välitetään yhdyskäytävän kautta. Tämä ominaisuus aiheuttaa kuitenkin paljon „tilavuutta“ pumppausta joissakin kokoonpanoissa. (Erityisesti vuorovaikutuksessa sisäisen äänikortin AGC ( katso mikseri ) kanssa.)

Tämä on prosenttiosuus teoreettisesti ihanteellisesta signaalista. ( Sanotaan 0db) Kuitenkin, vaikka olisin kirjoittanut prosenttiosuuden, sen ei pitäisi olla 99.

AGC yrittää aina saavuttaa määritetyn prosenttiosuuden. Se ei kuitenkaan välttämättä ole järkevää vahvistaa äärettömän pehmeää signaalia äärettömästi 0 db: n tasolle. Sitten olisi mukavaa, mutta täysin vääristynyt. Siksi voit syöttää tähän maksimivahvistuksen, jota AGC voi käyttää yrittäessään päästä 0 db: een.

Kaikki kuvaukset katso äänikortti .

Hier wird nun angegeben, wie der Raspberry euer Funkgerät steuert. Am einfachsten funktioniert dies mit einem Relais, welches man an den GPIO-Port anschließt. Habt ihr jedoch bereits ein Interface von anderen Anwendungen, solltet ihr auch in der Lage sein, dieses weiter zu verwenden.

Inzwischen habe ich von 2 Leuten die Rückmeldung erhalten, dass das Sturzvogel-Interface v.2 erfolgreich mit PiCQ funktioniert.

Wenn ihr gerne über den GPIO schaltet, so müsst ihr leider strikt die von mir vorgegebenen GPIO-Ports, für das entsprechende Gateway benutzen, da ich nur diese dem System für die Verwendung durch den Clienten abgerungen habe.

Beim Schalten über GPIO sind hier folgende Werte einzutragen:

• GPIO:24:gpio24:NORMAL (Bei Gateway1 wenn die PTT an den Schließerkontakt des Relais angeschlossen ist (empfohlen)
• GPIO:24:gpio24:INVERTED (Bei Gateway1 wenn die PTT an den Öffnerkontakt des Relais angeschlossen ist (nicht empfohlen aber machbar)
• GPIO:4:gpio4:NORMAL (Bei Gateway2 wenn die PTT an den Schließerkontakt des Relais angeschlossen ist (empfohlen)
• GPIO:4:gpio4:INVERTED (Bei Gateway2 wenn die PTT an den Öffnerkontakt des Relais angeschlossen ist (nicht empfohlen aber machbar)

Bei Schaltung über ein USB→RS232 Interface nutzt bitte folgende Werte:

• COM:/dev/ttyUSB0:RTS:I (Wenn das Interface mittels RTS-Leitung schaltet)
• COM:/dev/ttyUSB0:DTR:I (Wenn das Interface mittels DTR-Leitung schaltet)

Auch hier kann mit dem Schalter „N“ (für NORMAL) oder „I“ (für INVERTED) die Schaltlogik gewechselt werden. Linux beginnt bei der Nummerierung grundsätzlich bei „0“. Wenn also 2 Interfaces zum Einsatz kommen hat das erste Gerät die Adresse ttyUSB0 und das zweite die Adresse ttyUSB1. Leider kann nicht immer genau vorausgesagt werden, welche Nummer nun welches Interface nach dem Boot bekommt. Daher ist es empfohlen nur ein solches Interface zu verwenden und das zweite Gateway mittels GPIO zu schalten. -Klingt jetzt doof, ist aber so. Gerne könnt ihr mir aber eure Erfahrungen beim Einsatz dieser Interfaces schreiben, denn da ich ausschließlich mit GPIO schalte, kann ich daher keine eigenen Experimente machen.

Hier gilt im Grunde das Gleiche wie auch bei PTT. -Zusätzlich gibt es hier jedoch auch noch die Möglichkeit mittels VOX zu schalten. (Nutze ich persönlich sehr gerne da es den Schaltungsaufwand verringert)

Die entsprechenden Werte für GPIO sind folgende:

• GPIO:17:gpio17:NORMAL (Bei Gateway1)
• GPIO:27:gpio27:NORMAL (Bei Gateway2)

Sollte die Schaltlogik bei euch nicht stimmen, kann diese auch hier mit „NORMAL“ oder eben „INVERTED“ umgeschaltet werden.

Die entsprechenden Werte für die Verwendung eines USB→RS232 Interfaces sind:

• COM:/dev/ttyUSB0:CTS (Wenn die CTS-Leitung verwendet wird)

Nutzt ihr anstelle dessen lieber die VOX-Funktion, so lautet der entsprechende Eintrag:

• VOX:1200 (1200 ist ein erster Richtwert)

Die 1200 in diesem Beispiel ist ein erster Richtwert, mit dem die Vox grundsätzlich einmal funktionieren sollte. Je nach verwendeter Soundkarte, Beschaltung und Lautstärke eures Funkgerätes, muss diese jedoch angepasst werden. Hierbei gilt: Je höher der Wert, desto höher die benötigte Lautstärke zum Schalten.

Verschiedene, wie auch der alterFRN Client, bieten weitere Einstellungen (Static & Light) an. Um ehrlich zu sein, habe ich diese bisher noch nicht gebraucht und kann mir daher auch keinen Reim daraus machen, wozu sie gut sind. Der Vollständigkeit halber habe ich sie jedoch ins Web-UI übernommen. Werte die ihr hier eintragt, werden also auch in die Konfiguration übernommen. Vielleicht kann mir ja jemand von Euch einmal schreiben, was hier genau eingestellt wird.

Verschiedene, wie auch der alterFRN Client, bieten weitere Einstellungen (Static & Light) an. Um ehrlich zu sein, habe ich diese bisher noch nicht gebraucht und kann mir daher auch keinen Reim daraus machen, wozu sie gut sind. Der Vollständigkeit halber habe ich sie jedoch ins Web-UI übernommen. Werte die ihr hier eintragt, werden also auch in die Konfiguration übernommen. Vielleicht kann mir ja jemand von Euch einmal schreiben, was hier genau eingestellt wird.

Betätigt ihr bei eurem Funkgerät die PTT-Taste, so benötigt der Sender eine gewisse Zeit, bis das Trägersignal steht und euer Audiosignal aufmoduliert werden kann. Damit also beim Senden in dieser Zeit nicht der Anfang eures Satzes abgeschnitten wird, wartet PiCQ eine gewisse Zeit nach betätigen der PTT bis es das Audio an das Funkgerät sendet. Diese Verzögerung kann hier (in Millisekunden) eingetragen werden.

200 ist hier ein recht guter Ausgangswert.

Es kommt immer wieder einmal vor, dass euer Funkgerät kurze Störungen empfängt. Damit jetzt nicht jedes Knistern und Knacken beim Empfang als Nutzsignal erkannt und in das FRN-Netz weitergeleitet wird, kann hier ein Schwellwert (in Millisekunden) eingetragen werden, ab welchem ein Signal als sinnvolles Nutzsignal behandelt wird. (Trägt man hier also 200 ein, werden alle empfangenen Signale die kürzer als 200ms dauern einfach ignoriert)

200 ist hier ein recht guter Ausgangswert.

Gerade bei Verwendung der VOX, kommt es hin und wieder einmal vor, dass wenn jemand einmal leiser spricht, oder eine Atempause macht, die VOX schon wieder schließt. Dies kann jedoch auch bei Verwendung von COS vorkommen, wenn etwa ein Mobil durch Häuserschluchten fährt und ganz kurzzeitig nicht mehr über eure Squelch (Rauschsperre) kommt. Auch hier würde euer Gateway sofort umschalten, Quittungstöne senden und sich bereit machen wieder etwas von HF oder auch FRN weiterleiten zu können. Dabei können jedoch Wortfetzen oder ganze Worte verloren gehen. Um dieses etwas zu entschärfen kann hier also eine Wartezeit (in Millisekunden) eingetragen werden, während der das Gateway auf eine Fortsetzung des Satzes wartet, wenn eine Unterbrechung stattfand. Dieser Wert sollte jedoch nicht zu groß gewählt werden, da das Gateway bei jedem Empfang über HF, diese Zeitspanne wartet. Bei zu großen Werten wird das Gateway daher also zu träge und schwehrfällig im Ansprechverhalten.

500 bis 600 Millisekunden haben sich bei mir hier als recht guter Ausgangswert herausgestellt.

Bei vielen Funkgeräten wirkt die Rauschsperre (Squelch) nach Loslassen der PTT-Taste nicht wieder sofort. Daher ist nach Loslassen der PTT-Taste manchmal auch sofort ein ganz kurzes Rauschen zu hören. Dieses kurze Rauschen würde jedoch dafür sorgen, dass die VOX zum Beispiel sofort wieder anspricht, weil sie denkt es würde ein Nutzsignal empfangen. In einem solchen Fall spricht man auch gerne von einem „Nachtasten“ des Gateway. Um diesem entgegen zu wirken, kann hier eine Wartezeit (in Millisekunden) eingetragen werden, in der sich das Gateway direkt nach dem Senden taub stellt. Somit wird das kurze Rauschen wirkungsvoll ausgefiltert. Der Wert sollte hier jedoch auch nicht zu groß gewählt werden, da das Gateway sonst zu träge wird. Jedoch auch nicht zu klein, da es sonst nachtastet.

200 hat sich bei mir und meinen Geräten als brauchbarer Ausgangswert herausgestellt.

Hier könnt ihn nun festlegen mit welchem Monitorserver sich euer Gateway verbinden soll.

Hier wird die URL des zu verwendenden Monitorservers eingetragen. Ihr habt hier die Wahl zwischen:

sysman.freeradionetwork.eu Das ist der originale FRN Monitorserver von Edwin

oder

sysman.freeradionetwork.de Das ist der alternative FRN Monitorserver —-

Der Port ist bei beiden Monitorservern gleich 10025

Sollte eure Verbindung mit dem Internet über einen sogenannten Proxy-Server erfolgen, so kann dieser hier eingetragen werden. Verwendet ihr soetwas nicht, tragt einfach NONE in das Typ Feld. Ich verzichte hier auf eine detailierte Beschreibung der Felder, da sie perse schon selbsterklärend sind.

ProxyCharsetName gibt die Codierung an, in der euer Proxyserver Fehlermeldungen zurücksendet. Der Standartwert hier lautet UTF-8 und greift auch, wenn man nichts eingibt.

HINWEIS: Manche Proxyserver haben Zugriffsbeschränkungen auf manchen Ports. Dies kann dazu führen, dass über diesen keine Verbindung zum FRN-Zielserver aufgebaut werden kann. Befragt im Einzelfall den Administrator eures Proxyservers danach, wenn es hier zu Problemen kommt.

Hier könnt ihr eine Standartantwort eingeben, die das Gateway automatisch nach FRN zurücksendet, wenn jemand dem Gateway eine Privatnachricht schickt.

Da Valery nun auch die DTMF-Funktion in seinem alterFRN-Klienten integriert hat, auf den PiCQ aufbaut, ist PiCQ nun endlich auch mit der sehr praktischen DTMF-Funktion bedienbar. Durch diese kann ein Gateway nun auch über HF (also von einem Funker der darüber funkt) in einen anderen Raum oder einen anderen Server geschickt werden. Ebenfalls ist es möglich hiermit ein Action-Skript von PiCQ zu starten, und somit weitere Funktionen auszulösen (z.B. einen GPIO-Pin zu schalten, oder was man eben in diesem Action-Skript so programmiert).

Hier legt man fest, ob das Gateway überhaupt empfangene DTMF-Töne auswerten soll.

Hier legt ihr die verschiedenen DTMF-Kommandos fest, die euer Gateway befolgen soll. Dies folgt jedoch einer strikten Syntax. Ich versuche es einmal an einem Beispiel zu erklären wie sich das ergibt. Ich beschreibe es mit meinen eigenen Worten, der Programmierer hat es sicher anders benannt, jedoch kann ich es nicht ordentlich aus dem Russischen übersetzen und auch noch erklären. Ich bitte daher um Nachsicht.

Die Komandozeile, wie ich sie nenne, setzt sich aus den einzelnen Kommandoblöcken zusammen. (Wenn mehrere Befehle programmiert werden sollen.) Die einzelnen Kommandoblöcke werden durch ein „;“ (Semikolon) voneinander getrennt. Alles wird in einem Rutsch, ohne Leerzeichen, geschrieben.

<Kommandoblock>;<Kommandoblock>;<Kommandoblock>

Die Kommandoblöcke setzen sich aus dem DTMF-TEXT, der AKTION und den ATRIBUTEN zusammen und werden durch „:“ (Doppelpunkte) voneinander getrennt. Auch einzelne Atribute werden wieder durch Doppelpunkte getrennt, wie

z.B. Server-Adresse:Server-Port:Raum-Name.

DTMF-TEXT meint die Tastenfolge bei der das Gateway eine Aktion ausführen soll. (z.B. *01#)

AKTION meint die Aktion, die das Gateway ausführen soll, wenn es die Tastenfolge empfängt. Hier gibt es 3 unterschiedliche Aktionen.

• NET wechselt auf dem selben Server lediglich in den angegebenen Raum. (Bleibt aber auf dem Server)
• CONN wechselt zu einem angegebenen Server in einen angegebenen Raum
• EXEC führt ein Action-Skript aus

ATRIBUTE benennen den Server, Port und Raum oder das auszuführende Skript.

Im obigen Beispiel bewirkt also „*01#“, dass das Gateway wegen „NET“ in den Raum Berghütte, auf dem gleichen Server wechselt.

Durch „*11#“ verbindet sich das Gateway wegen „CONN“ mit dem Server www.1A-funkfeuer.de an Port 10024 auf Raum Test.

Und „#99#“ läßt das Gateway wegen „EXEC“ das Skript /opt/PiCQ/action/ftmf.sh ausführen.

Der Pfad “/opt/PiCQ/action/„ sollte einfach immer für die Action-Skripts genutzt werden, weil ihr auf diesen über die Samba-Freigabe zugreifen und bequem euer Skript dort hochladen könnt. (Siehe Samba)

In der Praxis zeigt sich, dass es weniger von Vorteil ist einen einzelnen DTMF-Ton als Kommando zu programmieren (Stöhranfälligkeit). Vielmehr macht es Sinn ein Kommando als eine Kombination zu definieren (z.B. *10#). Nachdem der DTMF-Decoder nun einen Ton erkannt hat, wartet er eine definierte Zeit auf die folgenden Töne, die das Kommando vervollständigen. Das DTMF Timeout bestimmt nun die Zeit, die der Decoder wartet, bis er den Versuch verwirft.

PiCQ kennt eine ganze Reihe von Tönen, die es zu gegebenem Anlass über HF aussendet. Rogerpiep, Quittungstöne, Fehlertöne u.s.w.. Um euch die Bearbeitung der Töne so einfach zu machen wie es eben nur geht, habe ich PiCQ dafür den Samba-Server spendiert. Er erstellt in eurem Netzwerk eine Windows-Freigabe in deren Ordner „sounds“ ihr die entsprechenden Töne ganz einfach speichern könnt. (Es ist sogar möglich mit einem Audio-Bearbeitungsprogramm direkt auf die Dateien in der Freigabe zuzugreifen.) Im Linux-Dateisystem eures Raspberry liegt dieser Ordner dann hier: “/opt/PiCQ/sounds/„.

Wie bereits oben beschrieben gehören die Soundfiles also in den Ordner “/opt/PiCQ/sounds/„.

Diesen Ton bekommt ein Funker von eurem Gateway als Bestätigungston gesendet, wenn euer Gateway seinen Funkspruch erfolgreich an den FRN-Server weiterleiten konnte.

Als Standart wählte ich eot.wav. (end of transmission)

Diesen Ton hängt euer Gateway an jeden Funkspruch an, den es vom FRN-Server an euren Funker per HF weitergesendet hat.

Als Standart wählte ich eot.wav. (end of transmission)

Dieser Ton wird an einen Funker per HF gesendet, wenn das Gateway seinen Funkspruch zwar empfangen hat, ihn jedoch nicht weiterleiten konnte, da es mit keinem Server verbunden ist.

Als Standart wählte ich error.wav. (Ein „Oh, ohhhh“ welches Ältere von Euch vielleicht noch vom ICQ-Messager her kennen)

Dieser Ton wird von eurem Gateway an euren Funker per HF gesendet, wenn sein Funkspruch vom Server zurückgewiesen wurde. Dies kann mehrere Ursachen haben. Entweder euer Gateway wurde von einem Serveradmin gemuted (stumm geschaltet) oder aber es hat zum Zeitpunkt des Sendebeginns eures Funkers jemand anderes Über FRN gesprochen und er hätte so also “gedoppelt„ oder „stereo gedrückt“.

Als Standart wählte ich busy.wav. (Das „Besetzt“-Zeichen was wir vom Telefon her kennen, aus Zeiten in denen noch kein Schwachsinniger das „Anklopfen & Makeln“ erfunden hatte)

Dieser Ton wird vom Gateway über HF gesendet wenn ein, nicht näher deklarierter, Fehler auftritt.

Als Standart wählte ich error.wav. (Ein „Oh, ohhhh“ welches Ältere von Euch vielleicht noch vom ICQ-Messager her kennen)

Diesen Ton sendet euer Gateway über HF aus, wenn es zwar einen Funkspruch von eurem Funker empfangen hat und auch mit einem Server verbunden ist, jedoch außer eurem Gateway niemand anderes im Raum ist, der es empfangen könnte.

Als Standart wählte ich roger.wav. (Ein ganz normales „Piep“)

Diesen Ton sendet euer Gateway (über HF) bevor es mit der Aussendung eines Funkspruches aus FRN beginnt.

Als Standart wählte ich bot.wav. (begin of transmission)

Hinweise: Die Töne für BOT und EOT haben eine Bewandniss. Es gibt einige Rauschsperre-Mechanissmen oder auch HF-Relais-Steuerungen, die mit solchen Tönen arbeiten um umzuschalten. Bei manchen PMR-Geräten kann z.B. eine DTMF-Tonfolge geschickt werden, damit die Squelch aufmacht, und nach dem Durchgang wird wieder eine Tonfolge gesendet, damit die Squelch wieder zu macht. Natürlich könnt ihr auch solche Töne hier entsprechend speichern.

Und noch etwas zu den von mir gewählten Tönen bot.wav und eot.wav: Ich entschied mich hier für die Quindar Töne. Diese Töne führte die NASA damals bei den Apolloflügen ein, um damit Relais-Stationen auf dem Boden schalten zu können. (Zitat aus Wikipedia: Der Startton hat 2.525 Hz und signalisiert das Drücken der PTT-Taste. Der Endton ist mit 2.475 Hz geringfügig tiefer und signalisiert das Freigeben der PTT-Taste.)

Hier könnt ihr eine automatische Zeitansage für euer Gateway definieren. Genau wie die Sounds können auch die Zeitansagen in der Freigabe „sounds“, jedoch in dem Unterordner „hours“ gespeichert werden.

Das Vorgehen ist vergleichbar mit dem des FRNClient.exe von Edwin.

Für später habe ich noch ein „externes Script“ vorgesehen, was Zeitansagen auf die Minute möglich macht. Dazu aber zu gegebener Zeit mehr.

Hier wird der Ordner angegeben, in dem die Soundfiles für die Zeitansage liegen. Habt ihr diese mit der Freigabe hochgeladen, befinden sie sich in /opt/PiCQ/sounds/hours/.

Hier könnt ihr festlegen ob euer Gateway die Zeit überhaupt ansagen soll

Hier wird das Intervall angegeben, in welchem eine Ansage der Zeit erfolgt. Die Berechnung beginnt bei 0 Uhr. Möchtet ihr also zu jeder vollen Stunde die Uhrzeit ansagen lassen, so beträgt die Intervall-Zeit 60 Minuten.

Bedenkt, wenn ihr z.B. alle 30 Minuten eine Ansage machen möchtet, benötigt ihr auch die nötigen Soundfiles dazu. Diese werden dazu nach folgendem Muster, im 24h Format, benannt: hh_mm.wav. Also zum Beispiel für 20:30 Uhr muss das Soundfile 20_30.wav benannt werden.

Da ich das Image für den Betrieb in Mitteleuropa vorgesehen habe, ist es eben nötig die Zeitzone entsprechend zu korrigieren. Der Raspberry verfügt im Gegensatz zu einem normalen Rechner über keine eigene Uhr. Er entnimmt die aktuelle Zeit und Datum einem Zeitserver im Internet. Dadurch läuft die Uhr in PiCQ immer mit der deutschen Zeit, egal wo das Gateway auch gerade ist.

Hier kann ein externes Script aktiviert werden, welches die nötigen Soundfiles für die Zeitansage jeweils zum benötigten Zeitpunkt selbst erstellt (mit künstlicher Stimme) und nach der Durchsage später wieder löscht um Platz zu sparen. Dieses habe ich jedoch derzeit noch nicht integriert.

Hier wird der Name des externen Skriptes eingegeben, sobald es verfügbar ist.

Hier wird der Pfad des externen Skriptes angegeben, sobald es verfügbar ist.

Bestimmt den Pfad, in dem das Skript die vorübergehenden Soundfiles zum Abspielen ablegt und nach Abspielen wieder löscht. (Auch erst notwendig, sobald verfügbar)

Hier habt ihr die Möglichkeit Ansagen zu platzieren, die von Zeit zu Zeit ausgesendet werden, um die QRG auf dem Kanal über euer Gateway zu informieren. Hier könnt ihr zum Beispiel auch mitteilen welchen CTCSS-Ton ein Funker verwenden muss, um über euer Gateway sprechen zu können, u.s.w.

Die Netzagentur schreibt beim Betrieb eines unbemannten CB-Gateways zum Beispiel die Nennung der KENNUNG die eurem Gateway bei seiner Anmeldung zugewiesen wurde, alle 10 Minuten. Glücklicherweise wird dort kein Wort verloren auf welche Art und Weise dies zu geschehen hat. Also könnt ihr euch nun selbst überlegen ob ihr alle 10 Minuten einen halben Roman per Sprache ansagen lasst, die Kennung eben per flotten Morsecode durchheizt oder eben auch per AFSK Nachricht in unter einer Sekunde. Oder ob ihr es auch gleich bleiben lasst

Ich glaube das erklährt sich von selbst, oder?

Das Verzeichnis in dem die Soundfiles für den Informer liegen. Wenn ihr sie mit der Freigabe hochgeladen habt, liegen sie bei den Sounds im Unterordner Informer. Also bei /opt/PiCQ/sounds/informer.

Die Zeitspanne in Sekunden in der eine Ansage erfolgt. (Beispiel für Rechenkünstler 15 Minuten sind 900 Sekunden)

Es gibt 2 Wiedergabe-Modi. Sequenz (die Files werden der Reihe nach wiedergegeben wie sie im Ordner liegen) und Zufällig (es wird per Zufall ein Soundfile ausgewählt, welches in dem Ordner liegt.)

Manchmal macht es Sinn, das Intervall zu ändern, wenn gerade Betrieb auf dem Gateway ist, und wenn wieder Stille herrscht. Daher kann das Gateway die Stille erkennen und dann eben ein anderes Intervall nutzen.

Hier wird nun also die Intervall-Zeit eingestellt, in welcher das Gateway die Infos sendet, wenn Stille herrscht.

Hier wird die Zeitspanne angegeben, in der kein Betrieb stattgefunden haben soll, bis das Gateway es als Stille erkennt.

Ich arbeite zu einem späteren Zeitpunkt ein Skript aus, welches die Ansage auch durch eine Text2Speach-Engine selbst generieren kann. Oder aber die Ansage selbst als Morsecode oder AFSK Nachricht erstellen kann. Wenn es soweit ist, kann dies hier ein- oder ausgeschaltet werden.

Der Dateiname den das Skript dann haben wird.

Der Datei-Pfad in dem das Skript dann liegen wird.

Der Datei-Pfad in den das Skript das auszusendende Soundfile vorübergehend ablegt, bis es gesendet wurde und anschließend aus Platzgründen wieder löscht.

Hier kann ausgewählt werden ob ein LCD-Display am I2C-Bus angeschlossen ist und benutzt werden soll.