https://forum.aprs-dl.de/ Wed, 29 Apr 2026 01:30:07 +0000 MyBB https://forum.aprs-dl.de/showthread.php?tid=61 Thu, 10 Nov 2022 20:57:49 +0100 DGØCBP]]> https://forum.aprs-dl.de/showthread.php?tid=61
anscheinend ist eine Grundeinstellung vorhanden, die eine Bakenaussendung im 26sek-Takt vornimmt. Das sollte deutlich verlängert werden, wenn nicht die QRG bald genau so "überlastet" wird, wie im 2mtr-Bereich.

Einen OM im OV habe ich schon darauf hinweisen können, aber es gibt mehrere Beispiele.

73

  karte.png (Größe: 409,93 KB / Downloads: 1204)

  info.png (Größe: 311 KB / Downloads: 1166) ]]>
anscheinend ist eine Grundeinstellung vorhanden, die eine Bakenaussendung im 26sek-Takt vornimmt. Das sollte deutlich verlängert werden, wenn nicht die QRG bald genau so "überlastet" wird, wie im 2mtr-Bereich.

Einen OM im OV habe ich schon darauf hinweisen können, aber es gibt mehrere Beispiele.

73

  karte.png (Größe: 409,93 KB / Downloads: 1204)

  info.png (Größe: 311 KB / Downloads: 1166) ]]> https://forum.aprs-dl.de/showthread.php?tid=58 Thu, 25 Aug 2022 19:57:26 +0200 DF1KZ]]> https://forum.aprs-dl.de/showthread.php?tid=58
Ich lese hier schon eine geraume Zeit mit und beobachte gleichzeitig die Entwicklung und Verbreitung im LoRa-APRS-Bereich. Neben einem RX-only iGate nach OE5BPA (DF1KZ-10) betreibe ich auch LoRaWAN-Gateways für TTN in Kerpen und im Osten von Köln auf 868 MHz (EU868).
Als TX (auf 70cm) verwende ich den LilyGO TTGO-T-Beam V1.1 433 MHz, SX1278 mit APRS 434. 

Im Moment nutzt LoRa-APRS einen SF:12, BW:125kHz, CR4/5 was dazu führt, dass Aussendungen einige Sekunden lang werden können und damit die Störanfälligkeit und der Energiebedarf steigt. Es gibt bereits gute Ansätze, Kompressionsverfahren zu verwenden z.B. APRS 434.
Was haltet ihr davon, niedrigere SF als 12 z.B. SF7 (-13dB Empfindlichkeit) oder SF9 (-8dB Empfindlichkeit) zu verwenden?

Gut, das bedeutet, dass wir neue oder zusätzliche iGates benötigen oder wie währe die Idee, ein LoRa-Gateway für EU433 (im Moment leider schlecht lieferbar) entsprechend zu modifizieren? Diese LoRa(WAN)-Gateways empfangen auf bis zu 10 Frequenzen gleichzeitig mit unterschiedlichen SF und auch FSK. TX können diese Gateways mit bis zu 27dBm LoRa/FSK.

Wolfgang]]>
Ich lese hier schon eine geraume Zeit mit und beobachte gleichzeitig die Entwicklung und Verbreitung im LoRa-APRS-Bereich. Neben einem RX-only iGate nach OE5BPA (DF1KZ-10) betreibe ich auch LoRaWAN-Gateways für TTN in Kerpen und im Osten von Köln auf 868 MHz (EU868).
Als TX (auf 70cm) verwende ich den LilyGO TTGO-T-Beam V1.1 433 MHz, SX1278 mit APRS 434. 

Im Moment nutzt LoRa-APRS einen SF:12, BW:125kHz, CR4/5 was dazu führt, dass Aussendungen einige Sekunden lang werden können und damit die Störanfälligkeit und der Energiebedarf steigt. Es gibt bereits gute Ansätze, Kompressionsverfahren zu verwenden z.B. APRS 434.
Was haltet ihr davon, niedrigere SF als 12 z.B. SF7 (-13dB Empfindlichkeit) oder SF9 (-8dB Empfindlichkeit) zu verwenden?

Gut, das bedeutet, dass wir neue oder zusätzliche iGates benötigen oder wie währe die Idee, ein LoRa-Gateway für EU433 (im Moment leider schlecht lieferbar) entsprechend zu modifizieren? Diese LoRa(WAN)-Gateways empfangen auf bis zu 10 Frequenzen gleichzeitig mit unterschiedlichen SF und auch FSK. TX können diese Gateways mit bis zu 27dBm LoRa/FSK.

Wolfgang]]> https://forum.aprs-dl.de/showthread.php?tid=45 Tue, 02 Nov 2021 13:45:07 +0100 DL3DCW]]> https://forum.aprs-dl.de/showthread.php?tid=45 hier) experimentiert:

1. Übertragung von APRS-IS Paketen

Damit die Frequenz nicht übermäßig belastet wird muss man sehr stark filtern. Dadurch wird die Sinnhaftigkeit einer solchen Funktion jedoch fraglich. Zudem kann das Gateway während der eigenen Aussendung nicht mehr auf der 433.775 MHz hören. Die eigentliche Gateway-Funktion wird dadurch mitunter stark eingeschränkt. Das Ganze scheint also keine sehr gute Idee zu sein.

2. Gateway-Heartbeat

Durch das regelmäßige Aussenden einer (Positions-)Bake kann das Gateway dem Empfänger signalisieren das sich dieser voraussichtlich im Abdeckungsbereich befindet. Selbst wenn das Gateway regelmäßig jede Minute sendet wird dadurch die RX-Funktion nur wenig eingeschränkt. Auch mehrere Gateways dicht beieinander dürften sich nicht allzu sehr stören. Ich habe einen solchen Heartbeat mal praktisch auf einer Testfahrt ausprobiert. Es war dabei sehr angenehm informiert zu sein ob man sich im Abdeckungsbereich eines Gateways befindet oder nicht.

3. Ping-Funktion

Dies könnte eine Erweiterung des Gateway-Heartbeat sein. Der Empfänger erhält damit die Möglichkeit auf Tastendruck das (zuletzt empfangene) Gateway gezielt mittels APRS-Querie „anzupingen“. Als Antwort erhält man vom Gateway einen Rapport in Form von RSSI und SNR-Wert.

4. Messages

Diese habe ich bisher noch nicht getestet; es wäre aber ebenfalls eine sehr sinnvolle Anwendung. Und genau für diesen Zweck ist die Frequenz ja eigentlich auch gedacht.

Mein bisheriges Fazit: Ich denke man sollte die LoRa-APRS Gateway-Frequenz 433.900 MHz auf keinen Fall mit normalem Traffic aus dem APRS-IS belasten sondern möglichst „sauber“ halten und lieber gezielt für interessante Dienste/Funktionen zwischen Gateway und Node (Tracker) verwenden.

Ebenso sollte natürlich auch die 433.775 MHz für Nodes (Tracker) freigehalten werden. Das Aussenden von Traffic aus dem APRS-IS sowie ein Digipeating macht auch hier - wenn überhaupt - nur in ganz wenigen Ausnahmefällen Sinn. Denn beides belastet die Frequenz sehr stark womit der Vorteil der schönen Reichweiten und der geringen erforderlichen Sendeleistungen ganz schnell wieder verloren gehen kann. Aus gleichem Grund sollte man diese Frequenz vorzugsweise für beweglichliche Stationen (Tracker) verwenden und dort lieber keine festen Stationen mit 24/7-QRO-Dauerfeuer betreiben. Darüber hinaus wäre dafür dann ja auch eine gesonderte Rufzeichenzuteilung (automatische Station) erforderlich ...

Über eine Diskussion zum Thema und natürlich auch weitere Ideen würde ich mich sehr freuen!]]> hier) experimentiert:

1. Übertragung von APRS-IS Paketen

Damit die Frequenz nicht übermäßig belastet wird muss man sehr stark filtern. Dadurch wird die Sinnhaftigkeit einer solchen Funktion jedoch fraglich. Zudem kann das Gateway während der eigenen Aussendung nicht mehr auf der 433.775 MHz hören. Die eigentliche Gateway-Funktion wird dadurch mitunter stark eingeschränkt. Das Ganze scheint also keine sehr gute Idee zu sein.

2. Gateway-Heartbeat

Durch das regelmäßige Aussenden einer (Positions-)Bake kann das Gateway dem Empfänger signalisieren das sich dieser voraussichtlich im Abdeckungsbereich befindet. Selbst wenn das Gateway regelmäßig jede Minute sendet wird dadurch die RX-Funktion nur wenig eingeschränkt. Auch mehrere Gateways dicht beieinander dürften sich nicht allzu sehr stören. Ich habe einen solchen Heartbeat mal praktisch auf einer Testfahrt ausprobiert. Es war dabei sehr angenehm informiert zu sein ob man sich im Abdeckungsbereich eines Gateways befindet oder nicht.

3. Ping-Funktion

Dies könnte eine Erweiterung des Gateway-Heartbeat sein. Der Empfänger erhält damit die Möglichkeit auf Tastendruck das (zuletzt empfangene) Gateway gezielt mittels APRS-Querie „anzupingen“. Als Antwort erhält man vom Gateway einen Rapport in Form von RSSI und SNR-Wert.

4. Messages

Diese habe ich bisher noch nicht getestet; es wäre aber ebenfalls eine sehr sinnvolle Anwendung. Und genau für diesen Zweck ist die Frequenz ja eigentlich auch gedacht.

Mein bisheriges Fazit: Ich denke man sollte die LoRa-APRS Gateway-Frequenz 433.900 MHz auf keinen Fall mit normalem Traffic aus dem APRS-IS belasten sondern möglichst „sauber“ halten und lieber gezielt für interessante Dienste/Funktionen zwischen Gateway und Node (Tracker) verwenden.

Ebenso sollte natürlich auch die 433.775 MHz für Nodes (Tracker) freigehalten werden. Das Aussenden von Traffic aus dem APRS-IS sowie ein Digipeating macht auch hier - wenn überhaupt - nur in ganz wenigen Ausnahmefällen Sinn. Denn beides belastet die Frequenz sehr stark womit der Vorteil der schönen Reichweiten und der geringen erforderlichen Sendeleistungen ganz schnell wieder verloren gehen kann. Aus gleichem Grund sollte man diese Frequenz vorzugsweise für beweglichliche Stationen (Tracker) verwenden und dort lieber keine festen Stationen mit 24/7-QRO-Dauerfeuer betreiben. Darüber hinaus wäre dafür dann ja auch eine gesonderte Rufzeichenzuteilung (automatische Station) erforderlich ...

Über eine Diskussion zum Thema und natürlich auch weitere Ideen würde ich mich sehr freuen!]]> https://forum.aprs-dl.de/showthread.php?tid=38 Tue, 20 Apr 2021 11:49:48 +0200 DO5DHA]]> https://forum.aprs-dl.de/showthread.php?tid=38 73 Dieter]]> 73 Dieter]]>