Ja,natürlich habe ich das Problem auch festgestellt. Der RXB6 ist ja wesentlich empfindlicher und daher hat man eigentlich immer ein Signal auf der Leitung, da kommt der Raspberry nicht mehr hinterher (Der Overhead ist durch das Linux schon ziemlich groß und Python ist nun mal nicht Quasi-Assembler wie C auf dem ATmega.) Aber zum Glück gibt es Lösungen dafür:
a) Keine Pinchange Interrupts machen
Das würde für jedes Signal am GPIO x Kontextwechsel, warten aufs Multitasking etc. bedeuten. 100% CPU garantiert, das hat schon mit dem schlechteren Empfänger nicht funktioniert. Also nehme ich dafür pigpiod, der sampelt die GPIOs mit DMA-Code und wertet dann in Software aus. Die Kommunikation Daemon->Skript läuft dann über Sockets, also ein wenig Overhead, aber vertretbar für diesen Fall.
b) Rauschfilter
Das hat dann zwar für den alten Empfänger funktioniert, aber mit dem neuen Empfänger kommt das ganze Konstrukt nicht mehr hinterher. Es wird halt jeder Müll empfangen, und das Signal wechselt alle paar µs. Aber pigpiod kann zusätzlich einen Rauschfilter abbilden (set_noise_filter). d.h. erst wenn x µs ein konstanter Pegel auf dem GPIO lag werden für y µs Signalwechsel berichtet. Und da das Maverick eine dafür geeignete Preamble hat funktioniert das bei mir ganz hervorragend. Falsche Preamble mit einem höherfrequenten Signal danach sind noch ein kleines Problem, da verschluckt pigpiod dann Signalwechsel etc. Aber wenn der Rauschfilter beim nächsten Mal anspricht hat sich die Situation wieder beruhigt. Da habe ich auch schon eine Idee, aber das dann später wenn der Empfänger wirklich ins Projekt wandert.
