Nachdem ich mich gestern mal wieder über die verschiedenen APRS-Clients für Windows und Linux geärgert habe, hatte ich eine Idee. Als ich vor ein paar Jahren noch viel im IRC unterwegs war, verwendete ich zum Chatten den IRC-Client Irssi. Da ich damals auch gern ICQ und andere Messenger mit meinem favorisierten IRC-Client nutzen wollte, habe ich mir BitlBee installiert. BitlBee ist ein lokal installiertes Gateway, welches sich gegenüber einem IRC-Client als IRC-Server verhält. Nach außen hin verhält es sich hingegen wie ein normaler Instant-Messenger.
Wenn man das Gateway-Konzept, das hinter BitlBee steht auf APRS anwendet, dann könnte das in etwa so aussehen: Eine lokal installierte Gateway-Software (die es bisher nicht gibt) verbindet sich mit einem KISS-TNC. Dies kann über eine serielle Schnittelle, über Bluetooth oder via TCP/IP erfolgen. Konfiguriert wird das ganze über eine Konfigurationsdatei. Um die die APRS-Hardware anzusprechen muss man sich mit einem beliebigen IRC-Client auf das lokale Gateway verbinden. Danach kann man APRS-Pakete senden und empfangen. So ähnlich wie in einem normalen Chat.
Mir ist klar, dass diese Idee nicht tauglich für die meisten Anwender ist. Aber für die meisten Anwender gibt es ja auch die bisher verfügbaren APRS-Clients. Diese Idee ist nur was für Menschen, die sich erst auf der Kommandozeile so richtig wohl fühlen.
Ich bin kein guter Programmierer, ich werde so etwas daher nicht selbst entwickeln. Aber ich würde das Projekt auf anderem Wege mit Infrastruktur und weiteren nötigen Ressourcen unterstützen. Wer Lust und Zeit auf so ein Projekt hat, kann gern auf mich zukommen.
Hi Silvio,
hast Du eigentlich jemanden gefunden für Dein APRS-Projekt?
So ganz war mir nicht klar, was Du exakt wolltest. Denn “danach kann man APRS Pakete senden und empfangen”… kennst Du den Aufbau von APRS-Paketen? Die haben teilweise sehr seltsame Kodierungen für Inhalte. Ich weiss das, da ich der Autor von QAPRS bin (ein in C++ mit Qt geschriebener Dekodierer für APRS-Messages) bin, siehe https://www.gitorious.org/qaprstools/qaprstools. Einfach wird es natürlich, wenn man sich beim Senden auf APRS-Messages (mit “:”) beschränkt.
Ich selbst mache derzeit gar nichts mehr mit APRS. Weil meine Tochter das Zimmer brauchte, ist mein Technik/Computerraum nun im Keller, und von dort funkt sich’s bekanntlich schlecht. Auch habe ich für 2m nur eine China-Handfunke (APRS Empfangen geht allerdings mit einem SDR-DVBT-Stick ganz gut …).
Grüße,
Holger, DH3HS
Hi Holger,
danke für deinen Kommentar. Sorry, für meine späte Antwort. Es gab bisher – bis auf die Kommentare unter diesem Beitrag und etwas Feedback auf Twitter – keine weiteren Reaktionen.
Die Rohdaten der APRS-Pakete sind mir geläufig, wenn ich auch nicht jedes Symbol im Kopf entziffern kann, ist mir dennoch der grundsätzliche Aufbau klar. Den Aufbau AX.25 Pakete müsste ich in der Doku nachlesen.
Mir geht es tatsächlich vorwiegend um das Senden (und natürlich Empfangen) von APRS-Nachrichten. Baken und Objekte wären eher Nebensache für den von mir angedachten Chat-Client.
APRX sieht vielversprechend aus – obwohl es für einen anderen Zweck entwickelt woprden ist. Im Prinzip bräuchte man dort “nur” etwas Funktionalität erweitern. APRX bräuchte eine zusätzliche Schnittelle für die Eingabe und Ausgabe.
Dass du Augenblicklich nichts mit APRS machst ist schade. Selbst mit einem chinesischen Handfunkgerät kann APRS viel Spaß machen.
Diesen Beitrag hier kennst du? https://www.hamspirit.de/5767/aprs-via-iss-mit-einfachem-equipment/
Hast du zu QAPRS noch eine Dokumentation für Anwender? (Was brauche ich zum kompilieren alles)
73 de Silvio
hi
interessante Idee
das Thema hab ich auf einer andere “Ebene” mal angepackt:
=> http://www.dl8ma.de/Arduino/APRS-Terminal/index.php
Nach längerer Pause beschäfige ich mich mometan wieder mehr mit APRS und will da weitermachen.
73 de Jürgen, DL8MA
Noch eine Idee: ich habe einen RasPi 2 und einen RTL-SDR Stick. GNU-Radio mag ich nicht soooo sonderlich, das ist ziemlich kompliziert zu kompilieren. Außerdem ist die Dokumentation davon …
Aber LuaRadio ist interessant, super dokumentiert und der RasPi 2 kann das locker. Und ein AX.25 Beispiel existiert ebenfalls schon: http://luaradio.io/examples/rtlsdr-ax25.html
Hallo,
muss das Gateway denn zwingend ein Kiss-Modem oder ähnliches ansprechen und die Bake über HF-Senden? Man könnte die Bake doch auch direkt an den Aprs-IS Server schicken oder? Ich schreibe mir gerne kleinere Software mit Visual Basic (ich weiss ist veraltet) und da verbinde ich mich auch direkt mit dem Aprs-Server um z.B. zu sehen, welche Pakete über mein Aprs-iGate geht. Zum anderen kann ich auch darüber Baken absetzen. Auch für PHP gibt es Scripte um Aprs-Baken abzusetzen.
hallo,
ich denke das wir schon über Funk arbeiten sollten. Wenn ich dafür APRS-IS-Server verwende mache ich im Grunde das selbe wie WhatsApp & Co 🙁
Wenn ich was programmiere dann verwende ich ein Funkgerät und ein TNC …
73 de Jürgen, DL8MA
der grad wieder einen Arduino an ein TH-D7 angeschlossen hat …
Jürgen hat vollkommen recht. Es braucht zwingend eine Verbindung zum TNC und TRX. APRS-IS ist nett, aber APRS ist mir am nützlichsten, wenn ich kein Internet habe.
Etwas Offtopic: Es gab früher zu Packetzeiten mal einen ICQ-Client mit Flexnet im Hintergrund. Damit ließen sich Nachrichten als UI-Frames versenden und empfangen. Wenn man damit online ging wurde ein Status ausgesendet und alle Nutzer die qrv waren und dich in ihrer Kontaktliste hatten konnten sehen dass du online warst. Ich fand das eine tolle Idee, die Digibetreiber jedoch weniger die ihre Digis später so konfigurierten dass UI-Frame nicht mehr weitergereicht wurden.
[…] etwas über zwei Jahren habe ich in diesem Blog über eine Projektidee geschrieben. Einen quelloffenen APRS-Client für die Kommandozeile sollte es meiner Meinung nach geben. Was ich mir genau darunter damals vorgestellt habe, könnt […]
[…] over two years ago, I wrote about a project idea in this blog. An open source APRS client for the command line (German) should be there in my opinion. What exactly I imagined at that time, you can read in this […]