Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

[Reinhard.M]

Ich arbeite mit einem Raspi 4B und folgender Linux Version:

Linux raspi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Nachtrag:
Das von dir unten angegebene "upload-reset" erzeugt genau das von mir angehängte Ergebnis.

[juergs]

Bei mir zu finden unter:
"C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win\src\upload-reset\upload-reset.c"

muss aber auf dem Raspi compiliert werden:
https://raspberrypi.stackexchange.com/questions/5599/how-to-compile-c-files-in-terminal

[Reinhard.M]

Wenn ich als "pi" die Datei aufrufe kommt als Antwort "Binärformat fehlerhaft". Werde gleich mal kompilieren...

[Reinhard.M]

Bei mir zu finden unter:
"C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win\src\upload-reset\upload-reset.c"

muss aber auf dem Raspi compiliert werden:
https://raspberrypi.stackexchange.com/questions/5599/how-to-compile-c-files-in-terminal

Perfekt, das war der richtige Hinweis. Die Binaries von Roger passten nicht zum Raspi.

[Ralf9]

Hatte jetzt nach 1 Tag und ca  18 Stunden auch einen Absturz bei der USB Version.

Habe dann das upload-reset.c compiliert,

Code Auswählen Erweitern

pi@banaNAS:~/prog$ gcc upload-reset.c -o upload-reset
upload-reset.c:121:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(int argc, char *argv[])
^~~~
upload-reset.c: In function 'main':
upload-reset.c:127:3: warning: 'return' with no value, in function returning non-void
   return;
   ^~~~~~
upload-reset.c:121:1: note: declared here
main(int argc, char *argv[])
^~~~

Das reseten mit  upload-reset hat dann funktioniert.

[killah78]

Einfach mal kurz eingeworfen:
Mein maple Sduino läuft seit letzten Donnerstag.
Die letzte größere "Empfangsschwäche" war am Samstag. Danach nur einmal am Montag einen Aussetzer für 20 Minuten. In allen anderen Zeiten ein vorbildlicher Empfang.
Warum auch immer das bei mir mit Lacrosse Mode2 so ist.
Ein Absturz im Sinne von keine Antwort mehr hatte ich bisher noch nie.
Gruss

[Reinhard.M]

Einfach mal kurz eingeworfen:
Mein maple Sduino läuft seit letzten Donnerstag.
Die letzte größere "Empfangsschwäche" war am Samstag. Danach nur einmal am Montag einen Aussetzer für 20 Minuten. In allen anderen Zeiten ein vorbildlicher Empfang.
Warum auch immer das bei mir mit Lacrosse Mode2 so ist.
Ein Absturz im Sinne von keine Antwort mehr hatte ich bisher noch nie.
Gruss

So rund läuft es bei mir nicht. Im Lacrosse Mode1 habe ich Aussetzer die über Stunden gehen. Mit einem raw WS36, raw WS34 lässt sich bis jetzt der CC1101 aber sofort wieder zum Arbeiten bringen. Der Watchdog, den ich aktiviert habe, hat inzwischen schon 2 Mal einen Reset ausgelöst und den Maple wieder auf die Beine gestellt. Da muss ich noch schauen ob ich die Triggerzeit hochsetzen muss.

[Ralf9]

So rund läuft es bei mir nicht. Im Lacrosse Mode1 habe ich Aussetzer die über Stunden gehen. Mit einem raw WS36, raw WS34 lässt sich bis jetzt der CC1101 aber sofort wieder zum Arbeiten bringen.

Ich habe hier das Problem, daß ich dies bei mir überhaupt nicht nachvollziehen kann.
Ich habe hier ein TX29 DTH-IT (Mode 1) und 3 PCA301 (Mode 3) bei denen ich bis jetzt noch keine Aussetzer hatte.

Ist Dir bekannt, daß bei LaCrosse der state nur bei Änderungen geschrieben wird.

Hast Du schon mal den neuen ccmode 4 getestet? Da wird zum Auslesen des FIFOs des cc1101 genauso wie bei der a-culw gemacht,
get raw CSccmode=4

[Reinhard.M]

Werde ich testen 

[Reinhard.M]

Werde ich testen 

Wenn ich auf ccmode=4 umstelle reagiert anschließend der Maple so gut wie überhaupt nicht mehr. Egal welchen get Befehl ich danach sende, es kommt keine Antwort. Ob der ccmode richtig eingestellt ist kann ich ebenfalls nicht auslesen.
Nachtrag:
Anscheinend mag mein Maple den ccmode=4 überhaupt nicht. Ich habe jetzt permanent RX-FIFO overflow und komme aus diesem Zustand auch mit Reset nicht mehr heraus. CSccmode=0 hat auch nichts gebracht.

[killah78]

Also ich laufe auf ccmode=4 und ich habe das Gefühl, je länger der am Stück läuft, um so weniger Aussetzer gibt es. Aber ich bin etwas beruhigt, dass noch weitere diese Aussetzer haben. Wie gesagt, komplette Abstürze hatte ich bisher noch nicht.

[Ralf9]

Wenn ich auf ccmode=4 umstelle reagiert anschließend der Maple so gut wie überhaupt nicht mehr.

Das ccmode 4 funktioniert erst ab 4.1.0-dev200501
https://github.com/Ralf9/SIGNALDuino/commit/aec52b7d62134d1d8f48b9ef3601f76ade2e0217

[Reinhard.M]

Das ccmode 4 funktioniert erst ab 4.1.0-dev200501
https://github.com/Ralf9/SIGNALDuino/commit/aec52b7d62134d1d8f48b9ef3601f76ade2e0217

Wie komme ich da jetzt wieder raus? Wie gesagt, der Baustein hat komplett die Arbeit eingestellt und erzeugt nur noch Fehler, Overflows.

[Ralf9]

Wenn sich dies ändert wird die config im EEPROM zurückgesetzt

Code Auswählen Erweitern

#define VERSION_1               0x41
#define VERSION_2               0x0d
Entweder eine Version mit geänderten VERSION_x Werten compilieren oder eine a-culw flashen

[Ralf9]

Anscheinend mag mein Maple den ccmode=4 überhaupt nicht.

Hattest Du beim umstellen des ccmode evtl das Radio B mit Bank 0 selektiert.

Du musst vor dem umstellen des ccmode erst das RadioA selektieren (mit Befehl bA)