Themabewertung:
  • 2 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
APRScube von DL3DCW
Die Version 1.3 läuft auf meinen beiden Cubes einwandfrei.

Zur Diskussion:
Macht es bei den neuen Funktionen Gateway/Node nicht Sinn, einen APRS-Path zu definieren (WIDE1-1), damit man dann auch von einem Digi mit Gateway2Node Funktionalität übertragen wird? Ich habe hier im Testbetrieb bei meinem Gateway (dxlAPRS) diese Funktion mal aktiviert, RX 433.775 TX 433.900. Klappt bis jetzt prima, Messages und Positionsdaten werden jetzt an meine Tracker auf der 433.900 übertragen. Jetzt wird auch der Empfänger der Tracker mal richtig munter...
Bislang klappt das aber nur mit anderen Derivaten, APRScubes werden aufgrund des Path (APLC13) noch nicht geforwardet.

73
Michael
[-] Folgende 2 Mitglieder gefällt DL5OCD's Beitrag:
  • dh9zig, dj7oo
Zitieren
Hallo Michael,

bisher habe ich Digipeating erst einmal vermieden da damit die Frequenzen sehr stark belegt werden. Allerdings verstehe ich Deinen Vorschlag auch noch nicht so ganz. Helfe mir mal etwas auf die Sprünge Wink

Das "APLC13" ist das Destination-Call, hat also mit Digipeating erst einmal nichts zu tun. Ein eventuelles WIDE1-1 käme dahinter.

Schönen Gruß
Frank, DL3DCW

Nachtrag: Möchtest Du vielleicht die vom Gateway lokal per HF auf der 433.775 MHz empfangenen Pakete auf der 433.900 MHz auch wieder lokal aussenden? An so eine Funktion habe ich tatsächlich mal gedacht. Allerdings kann in dem Fall das Gateway ja nicht gleichzeitig hören und verpasst damit dann wieder Pakete auf der 433.775 MHz. Daher macht es Sinn diese "Abwesenheitszeit" zu minimieren. Der Heartbeat einmal pro Minute ist da nur wenig störend. Wenn aber 2-3 Stationen mobil unterwegs sind und in kurzen Intervallen senden wird es deutlich enger. Durch "Kollisionsverhütungsmaßnahmen" kann man das zwar etwas eindämmen, aber so richtig perfekt wird es vermutlich nicht.

Grundsätzlich denke ich daher im Moment die 433.900 MHz besser nicht mit "geforwardeten" Positionsdaten zu belegen sondern wirklich nur für besondere Zusatzfunktionen zu verwenden und möglichst "sauber" zu halten. Das wären zum einen der Heartbeat und in Zukunft vielleicht auch eine Ping-Funktion und natürlich Messages etc. ...
[-] Folgendes 1 Mitglied gefällt DL3DCW's Beitrag:
  • DC5WT
Zitieren
Moin Frank, ja, genau das meine ich. Mein Tracker sendet auf der 433.775 etwas aus und ein Gateway/iGate sendet das dann auf der 433.900 wieder aus und gleichzeitig ins Internet. Ich habe DL5OCD-10 mal genauso eingestellt. Messages, Positionsdaten und was auch immer werden dann auf der .900 übertragen und andere Tracker im Einzugsgebiet des Gateways sehen dann auch andere Stationen im Umfeld. Und das mal ein Packet verpasst wird wenn eine Aussendung läuft...da wird die Welt schon nicht von unter gehen. Ich finde die Idee des Gateway2Node grundsätzlich erstmal interessant. Wie sich das dann mal etabliert und ob überhaupt, bleibt abzuwarten. Die Möglichkeit aber erstmal zu schaffen ist denke ich ein guter Ansatz. Wichtig ist hierbei, dass vor allem die .775 für Tracker frei bleibt und nicht durch was auch immer zugemüllt wird.

73
Michael
Zitieren
Ok, dann habe ich das richtig verstanden. Wie gesagt, so eine Funktion kam mir tatsächlich schon in den Sinn. Hat aber eben zur Folge das die 433.900 MHz deutlich stärker belegt wird. Und das mit Daten die schon auf der 433.775 MHz vorhanden sind. Also eigentlich doppelt gemoppelt, hi.

Weiteres Problem: Gibt es mehrere solcher TX-Gateways im Einzugsbereich wird die 433.900 MHz noch stärker belegt. Also mehrfach doppelt gemoppelt. Daher überzeugt mich das im Moment noch nicht so richtig. Auch wenn es natürlich nett wäre Stationen in der Nähe auf dem eigenen Tracker zu sehen. Vielleicht sollte man diesem dafür lieber einen zweiten RX gönnen?

Muss man aber noch mal genauer drüber nachdenken. Grundsätzlich bin ich mit sowas eher vorsichtig. Denn LoRa funktioniert im Moment nicht zuletzt auch so gut weil es eben recht freie Frequenzen, viele Gateways und kein bzw. kaum Digipeating gibt. Da sollten wir genau abwägen was nützlich ist und was eher schadet ...
Zitieren
So richtig doppelt gemoppelt ist das nur bedingt. Wenn ich mit meinem Cube so im Auto durch die Lande fahre, ist auf dem Display tote Hose, HI. Sinn macht das vor allem dann, wenn nicht jedes Gateway sinnlos drauf los sendet, wie das auf anderen Frequenzen so der Fall ist. Aber einige in exponierten Lagen...das hätte schon was. Ich bin hier IM MOMENT der Einzige, der die .900 mal aktiviert hat. Und wer weiß was du mit der Firmware noch so alles vor hast...  Wink

73
Michael
Zitieren
(29.12.2021, 23:28)DL5OCD schrieb: Sinn macht das vor allem dann, wenn nicht jedes Gateway sinnlos drauf los sendet, wie das auf anderen Frequenzen so der Fall ist.

Ja, und genau das möchte ich unbedingt vermeiden. Daher sollte man sehr überlegt vorgehen. Nicht das wir uns die Vorteile die wir im Moment haben wieder kaputt machen. Die IARU-Empfehlung sagt zur 433.900 MHz zudem: "from Gateway to Node, for messages". Also eher weniger für "geforwardete" Positionsdaten Wink

Andererseits kann man den APRScube ja immer noch auf PEER schalten. Dann empfängt er auf der 433.775 MHz ...

P.S. Wenn Du magst kannst Du bei der neuen Firmware mal die herausgeführte PTT an GPIO2 testen. Wird HIGH beim Senden. Aber auf eigene Gefahr Wink
Zitieren
Super, das teste ich mal, TNX!

73
Michael
Zitieren
Was mir bei der 1.3 aufgefallen ist:

Scheinbar hat sich das Handling der Aussendungen geändert, es werden jetzt 3 Pakete kurz nacheinander ausgesendet:

DL5OCD-13>APLC13:Big GrinL5OCD-13:EQNS.0,0.1,0,0,0.1,0,0,0.1,0

DL5OCD-13>APLC13:T#132,080,865,10115,000,000,00000000

DL5OCD-13>APLC13:Big GrinL5OCD-13TongueARM.Temp,Humi,Baro


Ist das ein neues Feature?

PS: Die Smileys werden natürlich so nicht ausgesendet, ist nen Darstellungsfehler im Forum.

73
Michael
Zitieren
Das sind neben den Telemetrie-Daten die Telemetrie-Header (Bezeichungen, Einheiten etc.) welche grundsätzlich einmal pro Stunde zusätzlich ausgesendet werden damit die Empfänger wissen um was für Daten es sich handelt.

Sollte also normal sein und war vorher auch schon so. Dadurch das der APRScube nun bei belegter Frequenz mit dem Senden abwartet und zusätzlich noch eine Zufallszeit dazu rechnet läuft das Ganze mit der Zeit etwas auseinander.
Zitieren
(30.12.2021, 03:00)DL5OCD schrieb: PS: Die Smileys werden natürlich so nicht ausgesendet, ist nen Darstellungsfehler im Forum.

Darstellungsfehler im Forum?

Mitnichten, Smilies werden adressiert, wie man weiß. Wenn du also ": D ohne das Leerzeichen" eingibst (was in deinen Zeilen enthalten ist), kommt zwangsläufig Big Grin zur Anzeige!
73 de Uli, DL8RO
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 8 Gast/Gäste