Kurzwellen Chat System

[zauberkopf]

Seit ein paar Tagen schwirrt mir ne Idee durch den Kopf :
Ein Chat System mit mehreren Teilnehmern, über Furzwelle.

Das Problem : Manche haben grosse Stationen und manche haben kleine Stationen.
d.H. 2 kleine und oder entfernte Stationen können sich u.U. nicht hören.
d.H. irgendeine Station muss als Vermittler fungieren.
Der Datenverkehr über Funk muss auf das Minimum reduziert werden.

Folgende Idee :
Man kann FLDIGI ein KISS Interface verpassen.
Daraufhin kann am AX25 mit FEC drauf laufen lassen.
Ein AX25 packet kann 255Bytes lang sein, aber dadurch das Der chat noch steuerzeichen hat, wird das weniger.
Hier mal eine Idee für den aufbau :

FCCCCCCNIIII TEXT

F=Flag... was ist das für ein Typ von Message
C=Call
N=Chat Kanal ( so sind mehere Channels möglich
I = Forlaufende nummer
Optional T = Vielleicht wäre es noch hilfreich, später für die Lesbarkeit, einen Timestamp hinzuzufügen.

Idee : Jede Message ist einzigartig. C+N+I heist,, das diese dann wirklich einzigartig ist.

Folgendes stelle ich mir vor :
QRP-Stationen: A und C
QRO Big Gun : B und G

Möglicher ablauf :

Station A Sendet einen Text :
MAA0XXX01Hallo Leute

Nun erwartet A von irgendwo her eine bestätigung
B denkt sich ... warum nicht ? und bestatigt den korrekten empfang.
AAA0XXX01

Station A ist zufrieden... sonst würde die Station noch mal versuchen das packet loszuwerden.

Station C hat A gar nicht gehört, hat aber die bestatigung von B mitbekommen.
Und jetzt ist natürlich C neugierig, und will von B wissen, was A gesagt hat .
RAA0XX01
Auch G hatte ne atmosphärische Störung... aber der timer hält ihn etwas zurrück, und dann sieht er, das schon B Sendet.
Daraufhin sendet B wieder :
MAA0XXX01Hallo Leute
Daraufhin bestätigt C
AAA0XXX01
G hat in der zwischenzeit aber das Packet von B korrekt empfangen und ist mit sich und der Welt zufrieden, hält sich daher zurrück.

Noch eine Idee :
Die Stationen speichern jede Message in eine Temporäre Datenbank.
Wenn also... z.B. eine Station Z neu hinzukommt, oder länger was nicht mitbekommen hat, könnte es an hand der fortlaufenden ID´s Request senden, und eine Station könnte Antworten.

Was haltet Ihr davon ? Wenn ich mich hinsetze und ne lösung unter Linux hinrotze... würdet ihr sie mit mir testen ?
Idee : Virtuelle Maschinen.

[Chemnitzsurfer]

Ob man eine klassische Mailbox per Packet Radio/ Winlink betreiben könnte?
Was über ein Datenklo übertragen werden konnte, muss doch auch per AFU gehen?

[zauberkopf]

Sehr wahrscheinlich.
Also eine PR-Box per FLDIGI und Furzwelle.

Ich dachte da aber an ein P2P system...

[D2O]

Ich finde die Idee sehr spannend.
Um beim Programmieren mit zu machen, fehlt mir vermutlich das Fachwissen, aber beim Testen bin ich gerne dabei.

[zauberkopf]

Och.. das Fachwissen wollte ich mir im Park aneignen...
Die Idee war mal, endlich mal Python zu lernen, nachdem man mir dauernd klar macht, das Perl....

[Stefan]

Hab vor kurzem einen ähnlichen Ansatz mit LoRa gelesen:

https://hackaday.io/project/174019-lora ... -messenger

[zauberkopf]

Ich habe mal ein bisschen gelesen.
Ich denke, damit es wirklich problemlos wird, werde ich die Soundmodemseite so angehen :
KEIN FLDIGI, aber 300Baud HF Packet mit Direwolf.
Das läuft sowohl unter Linux wie unter Windows, und er kann Fx.25 das ist AX25 mit bis zu 32 Bytes extra für die Datenrettung.
Ist sogar zu AX25 100% kompatibel. Die bis zu 32 Bytes hängen nämlich hinter dem offiziellen AX25 Packet.
Und, das Modem kann auch etwas drift bei SSB ab.. also sollte kein Problem sein. Nur der Wasserfall... den müsste man sich mit einer anderen Applikation basteln.

Direwolf kann mit Applikationen über das AGWPE network protocol sprechen.. darüber suche ich gerade Informationen.

Aber falls wer bock hat.. wir könnten mal versuchen die Tage mal eine "normale Verbindung" via FX25 zu realisieren.

[zauberkopf]

Informationen über das AGWPE Protokoll gerade gefunden :
https://on7lds.net/42/sites/default/files/AGWPEAPI.HTM

Sieht auf den ersten Blick sogar richtig nett aus !

[Asko]

@Zauberkopf

Irgendwie liest sich das für mich wie "Konvers".
Gabs ende der 90er Jahre, kam von Konversation und konnte jeder bessere Knoten.
zB. DB0EAM-3. Keine Ahnung ob das noch funktioniert.
Aber warum was neues erfinden, wenn es das schon gibt?

[zauberkopf]

Natürlich kenne ich das System !
Das Problem ist nur :
1. Du brauchst einen Server. Der muss dann auch noch online sein.
2. wird eine Verbindung gebraucht von jedem Chat Teilnehmer zum Server.
d.h. mit all den Bestätigungspacketen... etc.
3. Reduntante Transmissionen. Eine Nachricht wird vom Server mehrmals in den Äther gejagt.
Nachricht von A, wird einmal an B verschickt danach auch noch mal an C obwohl C die Nachricht fehlerfrei mitlesen konnte.
Denk dran, bei Furzwelle, reden wir von bestenfalls 300Baud.

Zu der Idee hatte mir dpbox und tnt inspiriert.
Die kombination erlaubte es, fehlerfrei mitgelesene Artikel die irgendwer von einer Mailbox heruntergeladen hat, in die eigene Box abzuspeichern.

Wenn das funktioniert, was ich mir da so aus dem Kopf gezogen habe, dann funktioniert das sobald 2 Teilnehmer sich hören können .

[Chefbastler]

Interessantes Thema.

Aber falls wer bock hat.. wir könnten mal versuchen die Tage mal eine "normale Verbindung" via FX25 zu realisieren.

Das könnte sich einrichten lassen.

[zauberkopf]

Cool... halten wir Mittwoch fest ? Da müsste es vom Wetter her so heiß werden, das ich flüchten muss !
Ab wann kannst Du ?

[b0n3]

Interessante Idee.
Hört sich irgendwie nach PeertoPeer an.
quasi eine Art Komunikation ohne bekannte Server.

Könnte man nicht sowas wie Retroshare oder Tox benutzen?
beide OpenSource, könnte man also anpassen, und verschlüsselt.

https://de.wikipedia.org/wiki/RetroShare
https://de.wikipedia.org/wiki/Tox_(Protokoll)

Weiss nur nicht ob das Funk klappt.

[zauberkopf]

Also erst mal : Über funk ist Verschlüssung und Anonymisierung Essig.
2. Das Ziel ist es, möglichst datensparsam zu arbeiten.
Weil, bei 300Baud braucht es schon ein paar sek, bis ne nachricht rübergeschickt worden ist .
wenn die dann nochmal zig mal kopiert und versendet werden muss.. wird das bei N teilnehmern interessant .

z.B.
A schickt ne nachricht, B und C empfangen sie.
Per Zufall entscheidet sich C sie sofort zu bestätigen.. B bekommt das mit und unterlässt es.
A weis , aha, sie kam durch.
Aber D hat gar nicht mitbekommen, das A was geschickt hat, sieht aber eine bestätigung.
Also fragt D mal kurz in die Runde : Was hat A gesagt ? und bekommt von C eine Antwort.

In dem Fall geht eine Message 2 mal über den Äther weil eine von 3 Stationen sie nicht erhalten hat.

Im prinzip schwebt mir sowas vor, wie ein "verteilte Datenbank" die per Funk Synchronisiert wird.
Also jeder kann einen Datensatz hinzufügen, und dieser wird an die anderen Datenbanken ausgeliefert.

[b0n3]

Naja, Anonymisierung war bei mir ned beabsichtigt, bei der "überschaubaren" Menge an Teilnehmern ist das
sowieso doof.
Bei der Bandbreite is aber mit P2P sowiso eher Sportlich.
Ab einer gewissen Anzahl Teilnehmer ist das platt.
würde eher von einer verteilten Serverinfrastruktur ausgehn um nur ein Paar Bereiche zu überlasten als das
ganze netz mit "wer hat Post für mich?" und an Alle "hier ist nachricht xy"

Wie händelst du Problem a hat nachricht für c, erreicht aber nur b, sieht aber sonst keinen, übermittelt an a alles empfangen, geht offline bevor er mit c oder d verbindung aufbauen kann.
b kommt nie wieder weil Exfrau ihn mitn Hammer hardformatet

deine tempDB wird das netz zum syncen ab einer gewissen anzahl von teilnehmern in p2p einfach zuscheissen.
Ohne Server denke ich wird das nur in sehr kleinem/lokalen Bereich nutzbar/sinvoll sein.

Gruß Andi

[zauberkopf]

Naja.. das Problem ist folgendes :
Rechtlich : Ein "Server" der 24h erreichbar sein will, braucht eine eigene Lizenz.
Technisch : Die Ausbreitung der Funkwellen bei Kurzwelle, kann interessant sein . Und sich dauernd ändern.
d.H. z.B.
A B und C wohnen auf einer Linie.. d.H. B in der Mitte.
Klappt alles, hören sich alle.
Aber es kann auch passieren, das ich die Ausbreitungsbedingungen ändern, und plötzlich hören sich nur noch A und C ... Und vielleicht noch C und B.

Wie händelst du Problem a hat nachricht für c, erreicht aber nur b, sieht aber sonst keinen, übermittelt an a alles empfangen, geht offline bevor er mit c oder d verbindung aufbauen kann.
b kommt nie wieder weil Exfrau ihn mitn Hammer hardformatet

Also : Das ganze soll ein Chat System sein. Kein Mail System.
A hat eine Nachricht für eine Gruppe.
A Sendet . B Empfängt. C und D nicht.
B bestätigt.
C oder D oder beide bemerken : Was ? B bestätigt für A ?
Und fragt bei B nach, was A gesagt hat.
B sendet das was A an die Gruppe geschickt hat.
C und oder D warten per zufall, und bestätigen den erhalt der der Nachricht von B.
Wenn C bestätigt, und D kriegt das mit, ist D fein raus, und bestätigt NICHT ! warum auch ?
(per zufall deshalb, weil wenn C und D gleichzeitig bestätigen, dann kommt bei B nur grütze an. )

Das Prinzip könnte auch dann noch funktionieren, wenn D nur C hört... C bestätigt den erhalt einer Nachricht ? Welche nachricht.. und fragt nach..

Chefbastler : Mir ist gerade aufgefallen : Wenn Du FX.25 nutzen willst, brauchst Du Direwolf in der Version 1.6 aus dem Entwicklungszweig.
grmpf...

[Joschie]

Hallo Jan,

ich hab über deine Idee heute Nacht mal gegrübelt.

Im Ansatz verstehe ich was du willst.

Nur mal ein Gedanke der mir gekommen ist.
Angenommen wir haben die Teilnehmer A, B, C und D.
A und C haben direkten Kontakt
B und C haben direkten Kontakt
und D kann nur A empfangen und zu B senden.

So, mein Gedanke lief in Richtung Relaisfunktion.

Erklärung: Jede Nachricht erhält neben den Daten noch eine Zeitmarke. Alle Empfänger senden mit ihrer nächsten Nachricht die empfangenen Nachrichten der letzten X Minuten wieder mit aus, so wäre gewährleistet das alle alle Nachrichten empfangen.

Beispiel:
A sendet die Nachricht $A:10:01-> Tolles Wetter$
Diese wird von C und D empfangen.
Jetzt antwortet D: $D:10:02-> Ja, regnet Bindfäden$A:10:01-> Tolles Wetter$
Diese wird von B Empfangen der nun die Nachricht von A und D erhält.

Ich hoffe du verstehst was ich meine.

Ein weiterer Gedanke der mir noch gekommen ist, es müsste doch möglich sein die Daten mit mehr Informationsgehalt zu übertragen.
z.B. 900Hz = 0, 1200Hz = 1, 1600Hz = 01, 2000Hz = 10
Damit könnte man pro Zeiteinheit mehr Informationen packen.

Aber was weiß ich schon.

Grüße
Josef

[Roehricht]

hallo,
wozu muss man das neu erfinden. Es gibt doch Packet Radio und PSK31. Viele HF Transceiver haben das Modem bereits an Bord. Braucht man nur noch ein serielles Kabel vom Transceiver zum PC + Software.

73
Wolfgang

[Chefbastler]

Chefbastler : Mir ist gerade aufgefallen : Wenn Du FX.25 nutzen willst, brauchst Du Direwolf in der Version 1.6 aus dem Entwicklungszweig.
grmpf...

Ich muss das ganze Direwolf erstmal einrichten. Schätze dass ich Donnerstag Abend oder Wochende soweit bin....

[Chefbastler]

hallo,
wozu muss man das neu erfinden. Es gibt doch Packet Radio und PSK31. Viele HF Transceiver haben das Modem bereits an Bord. Braucht man nur noch ein serielles Kabel vom Transceiver zum PC + Software.

73
Wolfgang

Weil mit dem bisherigen System tote Zonen nicht abgedeckt werden.

[Gernstel]

Sehr interessant. Mir gefällt vor allem auch der Mesh-Ansatz ohne zentralen Server/Mailbox usw.

Ein ähnliches Konzept gibt es beim Messenger Brian. Da werden die Mitteilungen auch auf Geräte verschoben, wenn sie ganz lokal über Bluetooth oder WLAN direkt verbunden sind, dann bei Kontakt mit dem Web übers Internet weitergeleitet und notfalls eben auch mit einem Gerät in der Hosentasche physisch transportiert bis zur nächsten Weitergabemöglichkeit.
Da hat sich also schon einmal jemand Gedanken gemacht, wie man solche Mitteilungen indiziert, speichert, verteilt. Und nach welcher Lebensdauer ggf. wieder löscht.

https://de.wikipedia.org/wiki/Briar_(Instant_Messenger)
https://briarproject.org/how-it-works/

Modulationsverfahren, optionale Verschlüsselung usw. kann man für den Kommunikationsweg nach dem OSI-7-Schichten-Modell bedarfsweise hinzufügen, anpassen, weglassen. Oder gar automatisch aushandeln je nach Übertragungsstreckenqualität und Anforderung, als Sahnehäubchen.

Ein freilich sehr anspruchsvolles Pojekt, trotz aller verfügbaren Software-Bausteine.

[zauberkopf]

Joschi :
Also ich wollte versuchen, redudante Informationen, über den Äther so weit wie möglich zu vermeiden.
Auch ist die Packetlänge eines (FX)AX25 Packets begrenzt. Wir reden hier von 239 Bytes. Ein paar Bytes werden ja von dem Chat System gebraucht. d.H. eine Message wird nicht viel grösser als rund 200 Bytes sein.
Bei so einem grossen Packet reden wir schon von rund 3-4 Sekunden übertragungsdauer ( bei dem geilen alten FSK Sound ).

Übrigens, man kann später noch hingehen, und eine Kompression implementieren. Gerade bei nur Text geht da einiges.

Ein weiterer Gedanke der mir noch gekommen ist, es müsste doch möglich sein die Daten mit mehr Informationsgehalt zu übertragen.
z.B. 900Hz = 0, 1200Hz = 1, 1600Hz = 01, 2000Hz = 10
Damit könnte man pro Zeiteinheit mehr Informationen packen.

Das nennt sich 4 FSK.
Und hier kommt Shannon ins Spiel : Doppelte Datenrate, bedeutet, das Du ein besseres S/N verhältnis brauchst (Leistung). Oder mehr Bandbreite... von nix kommt nix..
FlDIGI hat übrigens auch ein KISS Interface...und FLDIGI kann extrem viele Modulationsverfahren.
Die Kunst wird nur sein, das ggf auch unter Windows, und mit FEC zum laufen zu kriegen.

Chefbastler :
Ja.. ich muss das auch noch einrichten..als ich gestern den Dev zweig herunterladen wollte, wurde die Kiste auf einmal Stromlos....
Grund war, das ich meine "Laptop-Powerbank" ausgiebig getestet hatte....

[zauberkopf]

Joschi :
Also ich wollte versuchen, redudante Informationen, über den Äther so weit wie möglich zu vermeiden.
Auch ist die Packetlänge eines (FX)AX25 Packets begrenzt. Wir reden hier von 239 Bytes. Ein paar Bytes werden ja von dem Chat System gebraucht. d.H. eine Message wird nicht viel grösser als rund 200 Bytes sein.
Bei so einem grossen Packet reden wir schon von rund 3-4 Sekunden übertragungsdauer ( bei dem geilen alten FSK Sound ).

Übrigens, man kann später noch hingehen, und eine Kompression implementieren. Gerade bei nur Text geht da einiges.

Ein weiterer Gedanke der mir noch gekommen ist, es müsste doch möglich sein die Daten mit mehr Informationsgehalt zu übertragen.
z.B. 900Hz = 0, 1200Hz = 1, 1600Hz = 01, 2000Hz = 10
Damit könnte man pro Zeiteinheit mehr Informationen packen.

Das nennt sich 4 FSK.
Und hier kommt Shannon ins Spiel : Doppelte Datenrate, bedeutet, das Du ein besseres S/N verhältnis brauchst (Leistung). Oder mehr Bandbreite... von nix kommt nix..
FlDIGI hat übrigens auch ein KISS Interface...und FLDIGI kann extrem viele Modulationsverfahren.
Die Kunst wird nur sein, das ggf auch unter Windows, und mit FEC zum laufen zu kriegen.

Chefbastler :
Ja.. ich muss das auch noch einrichten..als ich gestern den Dev zweig herunterladen wollte, wurde die Kiste auf einmal Stromlos....
Grund war, das ich meine "Laptop-Powerbank" ausgiebig getestet hatte....

Gernstel :

Ein freilich sehr anspruchsvolles Pojekt, trotz aller verfügbaren Software-Bausteine.

Naja... ich denke, das ist machbar.
Was für mich die sache anspruchsvoll macht : Ich wills in Python nicht in Perl machen ! Und Python kenne ich noch nicht.
Soll also Learning by Doing sein...
Die Idee zum realiiseren :
Ich lese den "Monitor" da wo alle AX25 packete auflaufen aus, filter den A Output, und schreibe das alles mit einem Eingangszeitstempel in eine "Datenbank".
Jetzt bin ich in meinem Element !
Weil ich durchsuche gerne Datenbanken.. hier würde ich dann z.B. Suchen, nach Bestätigungen, wo die Message fehlt...
Oder nach fehlenden Bestätigungen.

[zauberkopf]

Ich habe mal gemessen : Also ein Datenfurz mit einer Payload von rund 210Bytes als FX.25 mit 32 Bytes extra (ich habs also hinbekommen) dauert bei 300Baud ganze 8 Sekunden.
Ein paar Steuerinformationen für das CHAT system.. und wir sind bei rund 160Zeichen..

[zauberkopf]

Ich muss mich gerade mal auskotzen...
Ich sitze hier gerade im Waldoffice (Das ist definitiv cooler als Homeoffice... bis auf die Getränke)

Und ich habe mir ja vorgenommen, Pyhton zu lernen... Das Ding soll ja mein erstes Python projekt werden.
Und jetzt fange ich schon an zu kotzen.. die dämlichen stringobjekte.... alles in UTF.. das ganze in Bytes zu verwandeln, und dann wieder umgekehrt...
Überhaupt ist Pyhton ne zicke.
In Perl frei nach schnauze runterschreiben, und dann wenn man einem im Tee hat, schön formatieren und lesbar gestalten...
Ist hier nicht.
grmpf

[nero]

b'string'

[zauberkopf]

So.... Ich bin fleissig am lernen...

z.Z. wurmt mich ein problem :
Ich kann Unproto Packete jetzt via Direwolf versenden.
Allerdings kommt immer diese komische Fehlermeldung, obwohl das Frame astrein raus geht :

Code: Alles auswählen

Error getting message header from AGW client application 1.
Tried to read 36 bytes but got only 0.
Closing connection.

[0L] DG0JAZ>WDCHAT:Hoffentlich funktionierts

Ich weis nicht was da schief läuft...
Hier die 2 Funktionen die ich dafür verantwortlich halte :

Code: Alles auswählen

#Hilfsfunktion, die ein Call auf 10Bytes aufbläht
def CallToBytesFillup (Mycall):
    for i in range(10-len(Mycall)):
        #print("test\n")
        Mycall=Mycall+"\x00"
    Mycall=bytes(Mycall,'ascii')
    return(Mycall)

#Hilfsfunktion die aus den parametern einen Bytestring generiert, der Direwolf 
#zum Senden eines M Packets animieren soll. 
def MFrameGen (Mycall,Destcall,MSG):

    Port        = 0
    Datakind    = 'M'
    Pid         = 0
    Datalen     = 0
    Mycall=CallToBytesFillup(Mycall)
    Destcall=CallToBytesFillup(Destcall)

    Sendstr=bytes([0])                                    #AGWPE Port
    Sendstr=Sendstr+bytes([0,0,0])                        #Reserved    
    Sendstr=Sendstr+bytes("M",'ascii')                    #DataKind    
    Sendstr=Sendstr+bytes([0])                            #Reserved    
    Sendstr=Sendstr+bytes([0])                            #PID    
    Sendstr=Sendstr+bytes([0])                            #Reserved        
    Sendstr=Sendstr+Mycall                                #MyCall
    Sendstr=Sendstr+Destcall                              #Destcall
    Sendstr=Sendstr+bytes([len(MSG)])+bytes([0,0,0])      #DataLen
    Sendstr=Sendstr+bytes([0,0,0,0])                      #Reserved
    Sendstr=Sendstr+bytes(MSG,'ascii')                    #Daten
    return(Sendstr)

Beschrieben wie das Frame aussehen soll, das ich zu Direwolf über das AGWPE Protokoll senden soll kann man hier nachlesen :
https://on7lds.net/42/sites/default/fil ... c500723791

Irgendwelche Ideen ?

[virtexultra]

Die Fehlermeldung kommt von Direwolf wenn es weniger Daten als erwartet (mind. die Länge des Headers, 36 Byte) über seinen Socket lesen kann. Um was weiteres sagen zu können, wäre wichtig zu wissen wie du die Daten an Direwolf übermittelst. Evtl. mal mit Wireshark in die Übertragung schauen.

[zauberkopf]

Ah, danke für den Hinweis !
Jetzt kann ich das eingrenzen. Also den Monitor abzufragen, funktioniert ohne probleme.
Was ganz nett wäre : Kann man die DCD abfragen ?