Neue Beta Images für den BelgienSpot, SHARI und DJ-Spot - Stand 4. Dezember 2024

[DD7ZY]

Hallo Peter, habe das letzte Guru Image vom 9.1.2025 auf dem neuen CE Guru installiert und folgende Probleme.
Login als Admin zeigt im Dashboard links auch RX im Balken, ohne Admin TX wie es sein sollte.
Nach einigen Minuten Betrieb kommt im RX Balken Squelch Open obwohl kein Signal vorhanden ist, aber er sendet zum Glück nicht ins Netz. Gehe ich mit dem Funkgerät auf Sendung geht danach der Squelch zu und der Guru empfängt auf der eingestellten TG wie es sein sollte bis nach einigen Minuten der Squelch wieder auf Open springt.
Das Github Image funktioniert ohne Probleme.
Irgendeine Idee was das sein könnte?
Vy 73 Juergen

[DG7AA]

Moin,

Ich selber habe dies Problem noch nicht gehabt. Aber ein OM hat mir folgendes dazu mitgeteilt:


>Der Guru CE lief ja mit dem Github Bookworm Image ohne Probleme und mit drei anderen Images hier,
>unter anderm mit Deinem Image gab es den >von mir beschriebenen Effekt, unter Anderem „antippen“ der PTT Taste.

>Soweit so gut. Da es aber bei vielen Usern des Guru CE auch mit der Squelch über die GPIOD zu funktionieren scheint, muß es ja eine Ursache dafür
>geben.

>Also habe ich weiter experimentiert und herausgefunden, dass der Guru CE Hotspot mehr als jeder andere Hotspot Spannungsempfindlich ist. Ich
>habe etliche Netzteile inkl. USB Kabel probiert und auch unter Last am Mikro USB-Stecker gemessen…auch welche, die am Guru 1 ohne Probleme
>funktionieren! Lange Rede kurzer Sinn: Alle drei Images laufen jetzt auch über SET_DET GPIOD einwandfrei.

>Man muß mit dem Netzteil aber echt Glück haben. Kein Vergleich zum Guru 1 oder sonst wie bekannten Problemen bei Raspi.

>Bei ihm gab es den gleichen Effekt. Ebenso war der Fehler nach Umstellung der Squelch weg. Und ebenso war der Fehler nach Netzteilwechsel weg.
>Er mußte auch mehrere Netzteile probieren, der Fehler war sogar an einen Powerbank vorhanden! Am Ende hat er ein Netzteil gefunden, mit dem
>Dein Image funktioniert. Wobei das Ganze nicht am Image liegt sondern am Guru CE.

>Hallo Peter, ich habe gerade mal eben am SA818 am Pin 8 gemessen. Die Betreiben den mit 3,3 Volt. Die sind es im Leerlauf auch. Wenn das Modul
>sendet sind 3,283 Volt.


Das sind die Infos die ich von dem OM dazu habe, alles ohne Gewähr. Ich kann das nicht nachvollziehen da ich keinen von den neuen BelgienSpots habe.

73 de Peter, DG7AA aka PA7PF

[DO1IP]

Moin zusammen,

ich habe seit gestern wieder einen neuen CE Guru in Betrieb und kann die o.g. Probleme weder nachvollziehen noch bestätigen! Sowohl das Image von Peter, als auch das von DG5NEK, laufen fehlerfrei. Getestet habe ich mit verschiedenen Netzteilen (auch ausnahmslos ALLE ohne Probleme ) sowie mit einer Powerbank. Ebenfalls keine Probleme.

73, de DO1IP
Udo

[DO1IP]

Moin,

was ist denn nun aus der Sache hier geworden? Gibt es neue Erkenntnisse?

73, de DO1IP

[DG0CCO]

Beim DJ Spot Image ist RF Kill aktiviert.
Trotz richtigem Eintrag country=DE (warum auch immer das nicht will)
Folgender Workarround funktioniert aber gut.

Mittels Ethernet und SSH Connecten (z.B. usb2eth adapter) und dann

sudo rfkill unblock wifi
eingeben.
Dann am besten im Dashboard noch die Wifi Settings und beim nächsten Start läuft er im Wifi.

[DG3KCW]

Hallo zusammen, ich hatte ebenfalls die Squelch-Problematik bei meinem Belgienspot2 (100mW). Als Image benutze ich das von Peter, DG7AA. Ich habe in der Adv.Config. die Werte für "SQL_DELAY" und "SQL_HANGTIME" jeweils von "0" auf "1" gesetzt. Danach lief der Hotspot soweit ich und meine QSO-Partner es beurteilen konnten einwandfrei, auch im längeren Testbetrieb. Vielleicht könnt ihr mal mittesten, wie immer auf eigene Gefahr, und hier ein Feedback posten. Dann sehen wir, ob der Weg valide ist und das Problem auch bei anderen Anwendern gelöst werden konnte.

[DO1IP]

Danke für den Hinweis. Ich beobachte das mal mit diesen Einstellungen.

73, de DO1IP

[DG7AA]

Moin,

nachdem ich nun endlich einen Guru2 leihweise mit dem CE-Modul in die Finger bekommen habe, konnte ich testen, was an dem Ding nicht ganz rund läuft.

Zunächst: Das SA818S hat einen LNA (Vorverstärker) integriert. Das kann die bekannten SQL-“Anti-Trip”-Effekte auslösen. Mit der Standard-SQL-Einstellung war das Verhalten auffällig; da das Modul insgesamt empfindlicher ist, habe ich den Squelch auf 5 gesetzt. Damit war der Effekt weg – und auch das Problem, dass man erst einmal senden muss, damit überhaupt etwas läuft. Hintergrund: SvxLink sieht beim Start sonst bereits einen offenen Squelch und geht dann natürlich nicht auf Sendung. Ebenso stehen dann gewissermaßen "Dauerträger" in Richtung FM-Funknetz, die bei sofortiger Aktivierung der ReflectorLogic natürlich dann auch übertragen werden. Haben wir ja schon oft genug erlebt... Kleine Anmerkung dazu noch, der Eintrag in [Rx1] kann auch nicht Schaden:

SQL_START_DELAY=50
SQL_DELAY=50

Außerdem ist mir aufgefallen, dass sich das SA818S nach einem Neustart immer wieder resettet: Die Frequenz fällt auf den Auslieferungszustand zurück, die Audio-Filter sind aus, und der Squelch steht wieder auf Standard. Nach meiner Einschätzung reagiert dieses Modul beim Boot auf Datenmüll auf der seriellen Schnittstelle und setzt sich dadurch zurück. Das ursprüngliche SA818 (ohne “S”) macht das nicht. Kann ich aber auch nicht zu 100% verifizieren denn ich möchte nicht auf dem Guru drauf rumlöten, weil das ja nicht meiner ist....

Ob das auf Dauer gesund für das Modul ist, wage ich zu bezweifeln – ich gehe davon aus, dass sich der Speicher nicht beliebig oft beschreiben lässt. Einen sauberen softwareseitigen Gegenentwurf habe ich bislang nicht gefunden. Das Deaktivieren von Bluetooth usw. hat bei mir leider nichts gebracht.

Im Datenblatt habe ich eben noch folgendes gefunden:

RXD of the module and connect to external TXD *Before enter sleep mode, user need to pull low RXD Pin to prevent current leakage or poor reset in the next time.

Vielleicht könnte man da per Software etwas machen... sehe ich aber eher kritisch denn das Timing wird vermutlich nicht passen...

Langfristig wäre vermutlich sinnvoll, das Modul einmal korrekt zu programmieren und die Pins der seriellen Schnittstelle anschließend abzulöten oder über einen Jumper/Schalter trennbar zu machen.

Warum das Problem nicht bei allen auftritt, dazu habe ich zwei Theorien:

Schwankende Modulqualität (Serienstreuung).

Unterschiedliche Stromversorgungen (Spannungseinbrüche/Noise).

Ich kann das leider nicht umfassend verifizieren. Als Workaround habe ich mir daher ein Script geschrieben, das die Werte aus der freq.conf ausliest und das Modul bei jedem Neustart erneut programmiert. Das funktioniert zuverlässig – ich habe es eben mehrfach getestet. Die RF-Guru Leute machen da übrigens etwas ganz ähnliches wenn ich das richtig in deren Image gesehen habe...