APRScube von DL3DCW

[DL4EAX]

Frage zu Firmware Version 1.3:

Meine APRScubes piepsen sobald ich ein Taste drücke bzw. ein Signal empfangen wird.

Der betreffende Teil der ini Datei sieht wie folgt aus:

[buzzer]
buttons = off
receiver = off


Ist das ein bekanntes Problem?

73,

Michael - DL4EAX

P.S.:
Das Umschalten anderer Funktionen wie z.B.
[radio]
output = on / off
funktioniert.

[DL3DCW]

Danke für die Info. Ist behoben. Bitte die Firmware noch einmal herunterladen und auf den APRScube übertragen. 73 Frank

[DL4EAX]

Danke für die Info. Ist behoben. Bitte die Firmware noch einmal herunterladen und auf den APRScube übertragen. 73 Frank

Danke für die schnelle Behebung, ich kann den Fix bestätigen!
Dir ein frohes Fest und 73!

[DG6DXG]

[attachment=88]

---

Ich habe heute eine signal von N6MXG erhalten ... ist das möglich?  Über 4000km?

[DL4EAX]

   

Was möchte mir die Nachricht "WAIT" bei einem funktionierenden RX-Only iGate mitteilen?

Die Nachricht verschwindet erst nach einen Neustart des Gerätes.

[DL3DCW]

Die Anzeige "WAIT" bedeutet das die Frequenz belegt ist/war und der APRScube die eigene Aussendung zurück hält um Kollisionen zu vermeiden. Bei "Rx-Only iGates" sollte diese Anzeige aber eigentlich gar nicht erscheinen. Macht sie aber wohl doch (habe ich gerade getestet). Es hat sich also ein "Schönheits"-Fehler eingeschlichen den ich möglichst zeitnah beheben werde. Vielen Dank für die Info!

Nachtrag: Habe den Fehler mal "quick-and-dirty" behoben und die Firmwaredatei auf www.APRScube.de entsprechend angepasst.

[DL4EAX]

Hallo Thomas,

die Höhendaten werden automatisch übertragen sobald die Daten im "compressed" Format ausgesendet werden (z.B. bei Mobilstationen). Das ist abhängig vom eingestellten Symbol. Beim LoRa "L" wird im normalen APRS-Format gesendet. Dort ist die Höhenangabe nicht enthalten um Übertragungszeit zu sparen.

Schönen Gruß
Frank, DL3DCW

Hallo Frank,

ich nutze im Mobilbetrieb das Symbol des blauen Van mit dem L drin:
table = L
symbol = v
Gehe ich recht in der Annahme, dass das "L" das Entscheidungskriterium ist ob die Daten im "compressed" Format ausgesendet werden?

73,
Michael - DL4EAX

[DL3DCW]

Hallo Michael,

das "compressed"-Format wird immer bei den Standard-Symboltabellen (also table = "/" oder "\") verwendet. Sobald es sich nicht um Standard-Symbole handelt (das sind meistens Symbole mit Overlay) wird auf das normale APRS-Format umgeschaltet. Ich musste das so einbauen weil z.B. APRS.fi ansonsten keine iGate-Statistiken anzeigt. Warum auch immer ...

Schönen Gruß
Frank, DL3DCW

[DL4EAX]

Hallo Frank,

das ist gut zu wissen, es wäre schön wenn dieses Thema auch in der Dokumentation angesprochen wird.
Ich wünsche Dir einen guten Übergang ins Jahr 2022.

73,
Michael DL4EAX

[DL3DCW]

Im Moment gibt es ja nur die "Kurzanleitung". Bei Gelegenheit mache ich aber vielleicht einmal eine etwas ausführlichere Version ...

Danke für die netten Wünsche und Dir auch einen guten Rutsch! 73 Frank

[DL5OCD]

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

[DL3DCW]

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

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. ...

[DL5OCD]

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

[DL3DCW]

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 ...

[DL5OCD]

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... 

73
Michael

[DL3DCW]

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

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

[DL5OCD]

Super, das teste ich mal, TNX!

73
Michael

[DL5OCD]

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:L5OCD-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:L5OCD-13ARM.Temp,Humi,Baro


Ist das ein neues Feature?

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

73
Michael

[DL3DCW]

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.

[dl8ro]

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 zur Anzeige!