Themabewertung:
  • 2 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
APRScube von DL3DCW
(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.
Zitieren
(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.

Ich habe Dir eine PN geschickt.
Zitieren
(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 ... Wink

   
[-] Folgendes 1 Mitglied gefällt DL3DCW's Beitrag:
  • df4kj
Zitieren
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.


Angehängte Dateien Bild(er)
   
[-] Folgende 4 Mitglieder gefällt DL2YCP's Beitrag:
  • DL4YCG, DK3QA, DL6UM, DL3DCW
Zitieren
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.

Danke!
73 Hans-Jürgen DL5DI
Zitieren
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 ... Wink

   

   

In Microsoft Edge funktioniert der Download bei mir sogar ohne Warnung/Freigabe. Mag aber sein das ich dies dort irgendwann mal erlaubt habe.
Zitieren
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!

73
Hans-Jürgen DL5DI
Zitieren
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: 

2023-01-13 17:41:33 CET: DL5DI-10>APLC13,qAO,DB0MYK-10:!/5#-FP@n!>BoQLoRa-System - https://qrz.com/db/dl5di
2023-01-13 17:41:33 CET: DL5DI-10>APLC13,qAO,DB0MYK-10:!/5#.2P@mw>C2QLoRa-System - https://qrz.com/db/dl5di [Rate limited (< 5 sec)]

2023-01-13 17:50:34 CET: DL5DI-10>APLC13,qAO,DB0MYK-10:!/5#-`P@n<>CoQLoRa-System - https://qrz.com/db/dl5di
2023-01-13 17:50:34 CET: DL5DI-10>APLC13,qAO,DB0MYK-10:!/5#.$P@mz>CmQLoRa-System - https://qrz.com/db/dl5di [Rate limited (< 5 sec)]

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?

Vy 73

Hans-Jürgen DL5DI
Zitieren
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:

2023-01-16 12:29:07 CET: DL5DI-10>APLC13,qAO,DB0ZK-10:Big GrinL5DI-10 TongueARM.Temp,Humi,Baro
2023-01-16 12:29:12 CET: DL5DI-10>APLC13,qAO,DB0ZK-10:Big GrinL5DI-10 :UNIT.deg C,%,hPa
2023-01-16 12:29:18 CET: DL5DI-10>APLC13,qAO,DB0ZK-10:Big GrinL5DI-10 :EQNS.0,0.1,0,0,0.1,0,0,0.1,0
2023-01-16 12:29:22 CET: DL5DI-10>APLC13,qAO,DB0ZK-10:T#001,215,437,9852,000,000,00000000
2023-01-16 12:29:29 CET: DL5DI-10>APLC13,qAO,DB0ZK-10:!/5#-QP@nG>ChQLoRa-System - https://qrz.com/db/dl5di

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.

dl5di
Zitieren
(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.
Zitieren


Gehe zu:


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