Ohne eigenes Auto gehöre ich ja scheinbar nicht so zur Kernzielgruppe der Cube und bin ein ungewöhnlicher Nutzer...
Ursprünglich wollte ich die Cube auch als Tracker im Rucksack in den Bergen nutzen. Tracker im Rucksack beim Wandern in den Bergen oder in der Stadt ist aber derzeit mit dem wackeligen Antennenstecker nicht praktikabel.
Batteriemodul hatte ich mir schon besorgt, aber auch mit dem empfohlenen Stecker-Adapter ist die Antennenverbindung nicht stabil.
Zu Fuss wäre vielleicht ein Winkelstecker zusammen mit ner Wendel-Antenne in so ner Bauform, wie sie auf vielen Handfunk-Geräten sitzt praktikabel. Und n Gummiband um den Winkel-Stecker am Gerät fest zu halten. Wenn da jemand ne praktikable Idee/Erfahrung hat, täte ich mich dann auch fürs QRO-Modul interessieren. Oder hält bei letzteren die Feder in der Buchse den Stecker besser?
Mich interessiert als Funkamateur aber u.a. auch die Beobachtung der Ausbreitungsbedingungen (welche Stationen in welcher Entfernung aus welcher verwinkelten Häuserschlucht über welche vermuteten Reflexionspunkte noch mein Küchenfenster erreichen). Und ich nutze die Telemetriedaten quasi als Wetterstation-Ersatz.
Bei Festmontage oder ortsfest z.B. wie bei mir auf dem Küchenfensterbrett ist die Steckererverbindung ausreichend stabil. Derart nutze ich die Cube seit nem knappen Jahr überwiegend als IGate. Die 433MHz-Magnetfußantenne auf dem Fensterbrettblech funktioniert gut in meiner suboptimalen Empfangslage.
Da sind nun einige Nice2Have-Wünsche aufgekommen, einige hatte ich hier schon mal früher geäußert. Die folgenden beiden sind mir für die Nutzung am Küchenfenster am wichtigsten:
1) Der momentan für mich wichtigste wäre ein Log der an APRS-IS gesendeten Daten, das ab einer definierbaren Größe bzw. abhängig von SD-Karte automatisch im Rolling Modus überschrieben wird. Am besten Rohdaten mit S-Wert und Uhrzeit.
Weil:
Es kommen nur selten Stationen vorbei und wenn die nach einer Stunde oder so aus der Anzeige verschwunden sind, weiß ich nicht, von wo mich Pakete erreicht haben, sitze ja nicht dauernd vor der Cube.
Das störte solange nicht, solange kein anderes iGate die Pakete zum APRS-IS übertrug. Aber seit drei Wochen werden auf aprs.fi und auf den aprsdirekt-Seiten ca 80% der weitergeleiteten Pakete als Dupes rausgeworfen, da ein neues, anderes LoRa-WAN-APRS-Gate in 5-10 km Entfernung einen deutlich besseren Antennenstandort hat und meinen Bereich z.T. mit abdeckt.
Das andere Gate ist keine AprsCube sondern basiert auf dem OpenSource-Projekt. Ich vermute, das deren Prozessor und Internetanbindung schneller ist oder bei mir Empfang über Reflexionen die Laufzeit der Pakete erhöht.
Wenn ich nicht innerhalb ner Stunde aufs Display geschaut habe, kann ich nur raten, welche Pakete empfngen wurde.
Außerdem kommen auch mal Statuspakete oder Telemetriedaten, wo keine Entfernungsangaben drin sind, da zeigt die Cube Unsinn an (5xxx km) und ich kann nur raten, wo die her waren und was da durch lief.
Helfen würde mir alternativ schon, wenn das letzte empfangene Paket nicht aus der angezeigten Liste gelöscht würde, sondern zusätzlich mit Datum/Uhrzeit (idealerweise auch S-Wert) sichtbar bliebe. Und bei sonstigen Paketen (also die keine Position enthalten) statt der Enfernung ein Marker für "Status" oder "Telemetrie" (ein Buchstabe als Symbol täte da reichen).
2) Über VHF empfangene Pakete werden im Peer-Modus zwar weiter geleitet, aber der eigene Standort wird nicht wie im IGate-Modus an APRS-IS gesendet. Da werden dann auf den Webseiten keine Entfernungen zu mir Angezeigt, wenn das letzte Positionspaket zu lange her ist.
Könnte da nicht im Peermodus im Falle des Empfangs eines Paketes on Air eine eigene Positionsbake an APRS-IS mit gesendet werden (aber nur dann), so dass die Entfernungsangaben auf aprs.fi usw. korrekt dargestellt werden können?
Vieen Dank für die nette und ausführliche Rückmeldung. Auch wenn Dein Einsatzzweck in der Tat recht ungewöhlich ist werde ich mal schauen was man daraus machen kann. Zum Antennenadapter: Vielleicht ist die Buchse an Deinem LoRa-Modul etwas ausgeleiert oder der verwendete Adapter nicht optimal? Das QRO-Modul ist übrigens mit einer hochwertigen MCX-Buchse von Telegärtner ausgestattet. Da sitzt alles sehr fest. Und mit dem weiter oben vorgeschlagenen SMA/MCX-Adapter von Amazon (https://www.amazon.de/gp/product/B07C2QWJ4Z) hält auch eine kleine SMA-Aufsteckantenne sehr gut.
Den oder einen (optisch) baugleichen habe ich ja im Einsatz. Aber evtl. doch nicht exakt, und da kommts wahrscheinlich auf µm an... (aus dem Paket https://www.amazon.de/gp/product/B08DKQNBX3)
Wenn die MCX-Buchse im QRO hochwertiger ist, wäre es vielleicht einen Versuch wert. Hast Du aktuell ein fertig zusammengelötetes anzubieten? Bzw. im Januar (früher werde ich eh nicht zu weiteren Experimenten kommen)?
Ja, ich habe einige Adapter getestet. Viele sehen auf den ersten Blick gleich aus - sie unterscheiden sich aber trotzdem im Detail wenn man ganz genau vergleicht. Der von mir oben genannte sitzt sehr schön fest. Bezüglich des QRO-Moduls dann bitte Mail oder PN. Ist alles kein Problem.
ich will nochmal meine Begeisterung kundtun
der QRO Cube ist ein Traum
mit der kleinen Außenantenne und der externen GPS Antenne (ich habe in meinem neuen Dienstauto leider sehr stark bedampfte Scheiben > siehe frühere posts mit meinen Antennenbau ) macht sehr viele Punkte (obwohl der Wert auf 1200 gestellt) OE1TKS-11
dankeschön für die tolle Arbeit
einen guten Rutsch
Tom
LG Tom OE1TKS
____________________
Folgendes 1 Mitglied gefällt OE1TKS's Beitrag:1 Mitglied gefällt OE1TKS's Beitrag • DL3DCW
Hallo Frank ...
Nachtrag ,
ich habe jetzt mal den Cube mit dem mobilen WLAN-Hotspot meines Mobilfunktelefones verbunden.
Hat sofort funktioniert.
Liegt wohl an der Beziehung zwischen cube und O2 Router.
Ich hatte bei anderen Geräten aber bis jetzt noch keine Probleme mit der WLAN Verbindung zum O2 Router.
Jetzt muß ich noch zwei M3 x 35 Schrauben besorgen, ich habe noch so ein rotes Akku Modul dran,
da sind die mitgelieferten Schrauben zu kurz.
Hallo
Ich habe einen Cube mit dg6dxg-15 konfiguriert. Vor ein paar Tagen bin ich von Polen nach Deutschland gefahren, und ich habe nichts empfangen. Ich sehe nur NO SIGNAL auf dem Bildschirm. Aber ich sende, denn ich kann mich auf der aprs.fi-Karte sehen. Ich habe PEER und NODE ausprobiert. Jetzt bin ich wieder zu Hause, konfiguriert als GATE, und empfange immer noch nichts.
Hast Du vielleicht ein weiteren LoRa-Tracker zur Verfügung mit dem Du mal ausprobieren kannst ob der APRScube grundsätzlich empfängt? Er muß dazu entweder auf GATE oder auf PEER stehen. Falls nicht einfach per PN melden.
Ich habe schnell aprs lora mit ttgo board gebaut, und aus 1m Entfernung kann ich Signal empfangen. Aber keine einzelnen Stationen um mich herum. Habe Antenne, Kabel, etc. gewechselt.
(07.12.2022, 22:21)dh9zig #545 schrieb: Ursprünglich wollte ich die Cube auch als Tracker im Rucksack in den Bergen nutzen. Tracker im Rucksack beim Wandern in den Bergen oder in der Stadt ist aber derzeit mit dem wackeligen Antennenstecker nicht praktikabel...
APRS mit dem Cube beim Wandern oder Fahrradfahren war auch meine Motivation.
Um beim Hüttentouren nicht auf ständiges Nachladen des Akkus angewiesen zu sein, betreibe ich den Cube mit einer kleinen Powerbank (und nicht mit dem Akku-Modul) - Kabelverbindung Nr. 1.
Als Antenne nutze ich eine Aufsteckantenne eines Handfunkgeräts mit einem ca. 20 cm langen Adapterkabel auf BNC.
Den Cube mit Powerbank transportiere ich in einer ZIP-Tüte regengeschützte im Deckelfach des Rucksacks - dort ist guter GPS-Empfang garantiert. Aus der ZIP-Tüte hängt das Kabel mit Antenne heraus. Die Antenne ist mit 2 Strips an zwei Laschen auf dem Rucksackdeckel montiert = "horizontale" Polarisation, funktioniert trotzdem.
Beim Fahrradfahren landet die ZIP-Tasche in der Fahrradtasche am Gepäckträger. An der BNC-Buchse hängt dann ein 50 cm langes Antennenkabel, das mit der am Fahrrad befestigten Rundstrahlantenne verbunden ist.
Generell kann ich die Sorge um eine Unterbrechung der Antennenverbindung verstehen - geht mir auch so.
Auch hatte ich einmal einen Displayschaden des M5stack, vermutlich durch äußeren Druck. Deswegen nutze ich jetzt eine genähte Schutztasche, in der vor dem Display eine Kunststoffscheibe integriert ist.
Eine wirklich praktikable Lösung für den manchmal harten Outdoor-Einsatz ist der Cube halt nicht.
Folgendes 1 Mitglied gefällt df4kj's Beitrag:1 Mitglied gefällt df4kj's Beitrag • dh9zig
(08.01.2023, 14:35)DG6DXG schrieb: Ich habe schnell aprs lora mit ttgo board gebaut, und aus 1m Entfernung kann ich Signal empfangen. Aber keine einzelnen Stationen um mich herum. Habe Antenne, Kabel, etc. gewechselt.
(08.01.2023, 15:30)df4kj schrieb: Eine wirklich praktikable Lösung für den manchmal harten Outdoor-Einsatz ist der Cube halt nicht.
Na, für den "harten Outdoor-Einsatz" ist der APRScube ja auch eigentlich nicht gedacht. Eher für den Einsatz im Fahrzeug oder als Gateway für den Stationstisch zuhause. Obwohl - auf den Schneemobilen bei DP0GVN in der Antarktis ist der APRScube auch manchmal unterwegs ...
Folgendes 1 Mitglied gefällt DL3DCW's Beitrag:1 Mitglied gefällt DL3DCW's Beitrag • df4kj
Ich bin wirklich begeistert vom APRScube. Aber auch ich hatte Probleme mit dem Antennenanschluß. Daher habe ich eine SMA-Buchse eingebaut und seit dem ist das ein anderes Gerät. Kein Abrutschen des Adapters mehr und auch in der Jackentasche gibt es keine Probleme mehr. Ich bin in den letzten Tagen im Norden herumgefahren und konnt hier erstmals auch Stationen empfangen, das hat hier im Münsterland und auch im Ruhrgebiet nie funktioniert. Der APRScube stand dabei auf dem Amaturenbrett meines Wohnmobils. Keine Außenantenne nur eine Gummiwurst für Handfunken. Damit die SMA-Buchse passt, musste ich nur von dem roten Akkumodul etwas abfeilen. Ich kann den kleinen Umbau jedem empfehlen.
Hallo zusammen.
Ich würde an meinen APRSCube gerne den ENV-III Sensor anschließen, bräuchte dazu aber die Beta-Firmware.
Die Links http://APRScube.de/firmware und http://APRScube.de/beta funktionieren leider beide nicht.
Ich hab schon einen anderen Browser und auf dem Tablet probiert, da einige Browser unverschlüsselte http-Seiten ablehnen, aber in dem Fall kommt keine Sicherheitswarnung, gar nichts, der Server scheint wirklich weg zu sein.
Kann mir bitte jemand eine andere Quelle nennen oder das bin der Beta per Email schicken?
Die normale Fw 1.30 hab ich, falls ich wieder zurück muss.
Bei ZIP-Dateien warnen einige Browser - dort muß man dann manuell die Erlaubnis zum Download erteilen. Habe es gerade mit dem Firefox getestet, das funktioniert. Der Server und die Datei ist also da ...
In Microsoft Edge funktioniert der Download bei mir sogar ohne Warnung/Freigabe. Mag aber sein das ich dies dort irgendwann mal erlaubt habe.
Alles klar, Danke für das Feedback!
Ich hab es weder mit Edge, noch mit Chrome unter Win11 geschafft überhaupt irgendeine Rückmeldung zu bekommen, außer nach ewig langer Zeit ein Timeout.
Aber wenn ich weiß, dass es nicht am Server liegt gönn ich mir schonmal einen kleinen Umweg.
Ich habe beide Files auf einen meiner Linux-Cloud-Server runtergeladen und von dort auf den Win11-Rechner gezogen.
Alles da, Ziel erreicht, ich kann testen!
Hallo zusammen.
Hier ein Feedback von meinen Tests mit der Beta-Firmware:
Der APRScube mit ENV-III-Sensor läuft bei mir im Peer-Mode, liegt am Fenster, freie Sicht zum Himmel, sieht normal 8-9 GPS-Satelliten.
- Mir ist aufgefallen, dass er mit der Beta-Fw direkt nach dem Start, noch bevor er GPS hat, 5 mal im Abstand von jeweils etwa 3 Sekunden sendet.
Bei aprs.fi finde ich dann diese Meldung:
Es sieht so aus, als wenn diese Folge beim Start etwas zu schnell ist.
Ist es so gewollt, dass noch bevor GPS-Daten da sind so viele Baken gesendet werden?
Später passiert das scheinbar nicht mehr.
- Das GPS-Modul wird bei mir offenbar nicht mehr zuverlässig erkannt.
Ich sehe oft nach dem Start, dass die GPS-Anzeige nicht aufleuchtet, keine Satelliten gesehen werden.
Ich warte 30min, keine Änderung, kein GPS, keine Satelliten.
Dann mache ich einen Reset, sofort geht die GPS-Anzeige an und zeigt sofort 8 Satelliten, ohne jede Wartezeit.
Es sieht so aus, als wenn der GPS-Empfänger schon arbeitet, die Firmware das aber nicht erkennt.
Der Fehler ist reproduzierbar, habe gerade beim Einschalten wieder kein GPS, das mit dem Reset klappt aber nicht immer, ich muss manchmal 5 mal oder öfter resetten bis GPS kommt.
Heute habe ich es noch gar nicht geschafft.
Es ist an dem Standort ausgeschlossen, dass der Empfänger über 30min keinen Fix bekommt.
Ich hab an gleicher Stelle einen TTGO und ein PicoAPRS liegen, die sehen beide 8-9 Satelliten, wie der Cube mit Fw 1.3 auch.
- Dann noch eins zu den Sensor-Daten:
Ich hab gelesen, dass der Luftdruck mit den Höhendaten vom GPS korrigiert wird.
Wird das für die Daten der APRS-Baken und auch für die angezeigten Daten gemacht?
Die Druck-Daten stimmen nicht überein. Das guck ich mir aber noch genauer an, evtl. hängt das an dem fehlenden GPS.
- Wie oft werden die Sensordaten gelesen?
2023-01-14 16:44:38
1 km/h alt 155 m
Telemetrie 2023-01-14 17:24:27: Zeige Telemetrie
Temp: 24.700 deg C, Humi: 42.700 %, Baro: 997 hPa
LoRa-System - https://qrz.com/db/dl5di
[APLC13 via qAO,DB0ZK-10]
Der erste Zeitstempel oben drüber ist von aprs.fi (in UTC), also 17:44 MEZ, die Telemetriedaten waren 20min alt beim Aussenden.
2023-01-14 17:22:59
alt 104 m
Telemetrie 2023-01-14 17:24:27: Zeige Telemetrie
Temp: 24.700 deg C, Humi: 42.700 %, Baro: 997 hPa
LoRa-System - https://qrz.com/db/dl5di
APRScube (GPS, Baro, 30dBm)
[APLC13 via qAO,DB0ZK-10]
40min später (18:22 MEZ) gehen noch die gleichen Daten raus, inzwischen mehr als 1h alt.
Würde es nicht Sinn machen, die Daten vor dem Aussenden einer Telemetrie-Bake upzudaten?
Kurzer Zusatz:
Das mit der Bakenfolge scheint einfach nur etwas knapp zu sein, so dass es beim Funkweg angemeckert wird wenn die Daten mit weniger als 5sec Abstand ankommen:
Je nachdem wie genau es aprs.fi nimmt, von 12 bis 18 sind es hier 6sec, von 18 bis 22 nur 4.
Meine 3 sec waren das "Spacing" zwischen 2 Baken, 5 sec sind es laut aprs.fi von Anfang bis Anfang, mit etwas Variation wenn es über längere Wege geht, bei mir z.B. oft über Repeater, die über Hamnet/Hamcloud angebunden sind.
(16.01.2023, 13:59)DL5DI schrieb: Das mit der Bakenfolge scheint einfach nur etwas knapp zu sein, so dass es beim Funkweg angemeckert wird wenn die Daten mit weniger als 5sec Abstand ankommen:
Ich sehe da erst mal kein grundsätzliches Problem drin wenn die Pakete des Telemetrie-Headers kurz hintereinander gesendet werden. Lediglich für Digipeating mögen 5 Sekunden (also mit einer Lücke von 2-3 Sekunden zwischen den Paketen) etwas kurz sein. Aber Digipeating findet bei LoRa ja eher nicht statt. Der APRScube unterstützt das ganz bewusst auch gar nicht. Denn wenn alles auch noch über einen Digi laufen würden wäre die Frequenz übermäßig stark belastet. Der Header mit den Telemetrie-Definitionen wird auch nur einmal pro Stunde gesendet. Man könnte die Zeit zwischen zwei Aussendungen natürlich etwas verlängern - für zwingend erforderlich halte ich das aber eigentlich nicht.
![[-]](https://forum.aprs-dl.de/images/collapse.png)
![[Bild: caddycube70cmgpskgi8y.jpg]](https://abload.de/image.php?img=caddycube70cmgpskgi8y.jpg)
L5DI-10 
ARM.Temp,Humi,Baro