Ja, sowas ähnliches ist angedacht. Wobei es eigentlich nicht unbedingt üblich ist einen APRScube der zuhause als iGate arbeitet zwischendurch abzubauen und dann unterwegs zu benutzen. Denn zuhause fehlt der dann eventuell. Da sollte man vielleicht darüber nachdenken ein separates System benutzen. Zuhause braucht man ja auch kein GPS und nicht unbedingt QRO. Ein iGate würde ich immer 24/7 betreiben und fest installiert lassen ...
Hallo zusammen,
ich bin ebenfalls neuer Nutzer des APRScube und erst einmal total begeistert. Ein tolles Projekt und Danke an Frank für die Unterstützung mit dem QRO- und GPS-Modul.
Bei meinen ersten Runden beobachte ich genau wie von Jürgen DC5WT in einem der vorherigen Beiträgen erwähnt, zu häufige Baken im Mobilbetrieb. Ich hatte 120, später testweise 240 Sekunden Intervall eingestellt. Die meisten Baken liegen aber häufig nur um die 23-27 Sekunden auseinander, Bsp:
2022-05-03 09:06:27 CEST: DL3YEB-9>APLC13,qAO,DF7PN-16:!/57rCP^R,>A]QLoRa
2022-05-03 09:06:52 CEST: DL3YEB-9>APLC13,qAR,DB9SR-10:!/57b/P^S!>AfQLoRa
2022-05-03 09:07:18 CEST: DL3YEB-9>APLC13,qAR,DF0HRB-14:!/57R^P^TD>AgQLoRa
2022-05-03 09:07:44 CEST: DL3YEB-9>APLC13,qAR,DF0HRB-14:!/57CMP^U]>AXQLoRa
2022-05-03 09:08:10 CEST: DL3YEB-9>APLC13,qAR,DF0HRB-14:!/575VP^Vt>AmQLoRa
2022-05-03 09:08:37 CEST: DL3YEB-9>APLC13,qAR,DF0HRB-14:!/571FP^Y.>B%QLoRa
2022-05-03 09:09:03 CEST: DL3YEB-9>APLC13,qAR,DF0HRB-14:!/573oP^_c>BOQLoRa
2022-05-03 09:09:26 CEST: DL3YEB-9>APLC13,qAR,DF0HRB-14:!/575>P^eI>B2QLoRa
Die Rohpakete im Beitrag von DC5WT zeigen ein ähnliches Muster und damit meine ich die Pakete, die nicht vom Gateway durch angehängte RSSI-/SNR-Werte manipuliert sind und dadurch die Duplikatsfilterung aushebeln. Bei mir kommen ebenfalls "saubere" Pakete im 23-27 Sekunden Takt, obwohl in der .INI-Datei viel höhere Werte eingestellt sind.
Hat jemand eine Idee, woran es liegt oder funktionieren bei Euch die Intervall-Einstellungen?
73, Thomas
Hallo Thomas,
die Standardeinstellung in der APRScube.ini beträgt ganz bewusst 900. Das sind 15 Minuten. Diese gelten zunächst für einen feststehenden APRScube - die Zeiten des SmartBeaconing (also bei Bewegung) werden allerdings davon abgeleitet. Eine Veränderung dieses Wertes beeinfusst also auch alle anderen Baken.
Im Prinzip sollte man den APRScube daher immer auf den 900 stehen lassen. Damit sind alle gewöhnlichen Anwendungszenarien abgedeckt. Als "Feststation" sendet der APRScube damit alle 15min, bei schneller Fahrt automatisch alle 30 Sekunden. Wem das zu kurz ist der stellt den Wert einfach höher, also z.B. auf 1800.
In der aktuellen Firmwareversion 1.3 wird ein zu kleiner Wert automatisch abgefangen und intern immer mit mindestens 900 gearbeitet. Aber es gibt auch da einen Grund warum die Zeit zwischen zwei Baken ggf. trotzdem kürzer ist: Um ständig wiederkehrende Kollisionen mit anderen Stationen zu vermeiden gibt es noch einen Zufallsfaktor von +-5 Sekunden. Damit liegt der Sendeintervall bei schneller Fahrt also immer im Bereich zwischen 25-35 Sekunden.
Wenn der APRScube fest installiert ist - also z.B. als iGate - würde ich diesen zudem komplett ohne GPS betreiben. Denn springende GPS-Positionen führen immer zu häufigeren Aussendungen.
Schönen Gruß
Frank, DL3DCW
Hallo Frank,
danke für die schnelle Info. Ich bin tatsächlich davon ausgegangen, dass ich die gewünschte Intervallzeit von bspw. 120 Sek. für den Mobilbetrieb in der INI-Datei auch genau mit diesem Wert eintragen muss. Ich werde mit dem Standardwert 900 bzw. mal mit 1800 testen und berichten, in welchen Intervallen der Cube dann im Mobilbetrieb sendet.
Danke und 73
Thomas
Im Prinzip macht der APRScube das alles automatisch. Der Wert braucht also nun in Ausnahmefällen geändert zu werden. Mit 900 wird Dein kürzestes Intervall bei 25..35s liegen, mit 1800 bei 55..65s
Funktioniert genau so wie von Dir beschrieben, Frank. Mit 1800 und 55-65 Sek. kürzestem Intervall im Mobilbetrieb fühle ich mich wohl und belege die Frequenz nicht so stark. Gefällt mir sehr gut!
73, Thomas
Eine
Frage zum M002 Akku (also nicht direkt zum APRScube):
In der Beschreibung steht:
Zitat:Wenn die BATTERIE unter den M5-Controller gestapelt wird, wird der Pluspol der Batterie mit dem VBAT-Pin an IP5306 verbunden
Auf dem M002-Modul ist der Akku auf die Platine mit Klebeband aufgeklebt. Das Akku-Kabel ist mit einer Buchse auf der Platine verbunden. Dieselbe Buchse gibt es auch auf der Core-Platine in der Nähe des IP5306.
Ist mit der oben genannten Anweisung gemeint, dass auf der M002-Akkuplatine das Kabel ausgesteckt und mit der Core-Platine verbunden werden muss oder ist das nur ein technischer Hinweis, dass durch die Buchsenleiste diese Verbindung automatisch hergestellt ist?
Ich hatte bereits ein Akkumodul gekauft und versucht, den Mini-Stecker aus der Buchse herauszuholen. Dabei ist der Plastikstecker zerbröselt, auch die Buchse war am Ende Schrott. Auch habe ich mich gefragt, ob das Kabel überhaupt ausreichend lang ist für die Verbindung zum Core. Außerdem müsste das Kabel zwischen Platine und Rahmen durchgeführt werden; das könnte mit der Zeit zum Durchscheuern und Brandgefahr führen...
Schade um das Akku-Modul, denn ich habe bisher nicht herausgefunden, mit welchen beiden Pins auf der Buchsenleiste die Batteriepole Plus und Minus verbunden werden.
Wenn das Umstecken wirklich notwendig ist: Wer kann einen Tipp geben, wie der Mini-Stecker am besten aus der Buchse entfernt wird?
Ich selbst habe bisher für Akkubetrieb nie etwas umgesteckt. Wichtig ist aber das der Akku des Bottom-Moduls in dem Fall unbedingt entfernt werden muß da man Akkus mit unterschiedlicher Kapazität nicht parallel schalten sollte. Gerade bei LiPos würde ich immer sehr vorsichtig sein. Denn damit ist nicht zu spaßen ...
Hallo Frank, für den Tipp, ich habe gleich welche bestellt, dann bin ich mal gespannt, die von DELOCK sind um das zweifache teuerer
(08.05.2022, 19:27)DL3DCW schrieb: [ -> ]Ich selbst habe bisher für Akkubetrieb nie etwas umgesteckt. Wichtig ist aber das der Akku des Bottom-Moduls in dem Fall unbedingt entfernt werden muß da man Akkus mit unterschiedlicher Kapazität nicht parallel schalten sollte. Gerade bei LiPos würde ich immer sehr vorsichtig sein. Denn damit ist nicht zu spaßen ...
ich habe das anfänglich auch nicht bedacht, und habe beide Akkus parallel betrieben, Folge war ein höherer Ladestrom im Bottom-Akku, der dann den Deckel des Bottom-Moduls stark erhitzt und gewölbt hat. Also vom Parallelbetrieb ist abzuraten, der Bottom-Akku ist leicht zu entfernen.
Hallo zusammen,
kann mir jemand eine Powerbank für dieses Gerät empfehlen, sollte relativ klein sein und eine Kapazität von ca. 2800 mAH haben.
(08.05.2022, 21:11)DL3DCW schrieb: [ -> ]Zum Thema MCX/SMA-Adapter habe ich inzwischen weiter nachgeforscht. Dieser Adapter sitzt auf meinem APRScube sehr schön fest und wackelt auch nicht: https://www.amazon.de/gp/product/B07C2QWJ4Z
Hallo Frank, ich habe heute die beiden MXC/SMA-Adapter bekommen, sie sitzen gut fest, auf den originalen LoRa-Modul sowie auf deinem LoRa-Modul. Sie sind nur zu empfehlen.
hallo ich bin Tom und bin jetzt auch stolzer Besitzter eines Cubes
ich werde mich in den nächsten Tagen damit ausgiebig beschäftigen ..
LG aus Wien
Servus!
Da in unserem ADL jetzt einige auf den APRScube umgestiegen sind und damit sehr zufrieden sind, möchte ich ebenfalls darauf wechseln. Aktuell hab ich das eher umständlich mit den ESP32 TTGO Modulen gemacht.
Jetzt wollte ich fragen, ob das U001-C Modul unterstützt wird.
Besten Dank schon mal!!!
Beste 73 aus dem nördlichen Österreich!
Die Unterstützung des extenen Sensor U001-C (ENV-III) befindet sich in Vorbereitung. Wird also kommen.
(15.05.2022, 18:09)DL3DCW schrieb: [ -> ]Die Unterstützung des extenen Sensor U001-C (ENV-III) befindet sich in Vorbereitung. Wird also kommen.
Danke für die Info!
Gibt es eigentlich auch die Möglichkeit, ein Anemometer anzuschließen, wodurch man eine mobileWetterstation hätte?!?
Nein, bisher leider nicht.
Hallo Frank,
Grüße aus Hasslinghausen von DG1EIR und einen ganz herzlichen Dank für dieses tolle Projekt. Es ist immer wieder eine Freude die von Dir vorbereiteten Projekte nachzubauen und erfolgreich in Betrieb zu nehmen. Dein pragmatischer Ansatz die Dinge einfach und robust zu halten gefällt sehr. Inzwischen läuft hier seit ein paar Wochen ein Gateway und ein mobiler Cube im KFZ.
Zwei kleine Auffälligkeiten die ich in den letzten Tagen Betrieb wahrgenommen habe:
1. Gateway: So ab und an (vielleicht 1-2 mal am Tag) ist die Verbindung zum APRS Server mal für ein paar Minuten weg. (Anzeige GATE wird grau, WLAN ist blau...) Empfängt der Cube in diesem Zustand eine Bake über die Luftschnittstelle, wird einige zig Sekunden lang der grüne RX Balken angezeigt und ebenso lang gebeept. Soll das so?
2. Tracker: Ich habe es inzwischen mehr als einmal gesehen, dass wenn ich das Fahrzeug in der Garage starte die GPS Position noch nicht da ist (Anzeige GPS ist grau). In diesem Zustand haben ich ihn aber schon beim Senden "erwischt". Der rote TX Balken wird angezeigt. Kommt die GPS Anzeige vielleicht verzögert oder was sendet er in diesem Moment für eine Bake?
Dass GPS erst verzögert kommt wenn der CUBE aus und der Wagen in der Garage war ist ja klar. Ich wundere mich, warum er in diesem Status schon sendet.
Nichts Großes, aber vielleicht gibt es ja eine Erklärung.
vy 73 aus Hasslinghausen
Dirk, DG1EIR Sysop DB0EIR
Hallo Dirk,
schön von Dir zu hören und vielen Dank für die nette Rückmeldung! Ich bin gerade unterwegs, daher nur eine kurze Antwort:
Zu 1. Das soll nicht so sein; in dem Moment hängt das Programm wohl etwas. Ist mir aber bekannt und werde ich mich bei Gelegenheit drum kümmern. Tritt zum Glück nur sehr selten auf und hat ansonsten keine weiteren negativen Auswirkungen.
Zu 2. Das ist völlig ok so. Wenn keine GPS-Position vorhanden ist wird trotzdem manchmal ein Statuspaket (ohne Position) gesendet. Das erfolgt kurz nach dem Start und danach 1x pro Stunde.
Schönen Gruß
Frank, DL3DCW