Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

hermannk

Hallo Ansgar,

ZitatHast Du Dir einen eigenen Sensor gebaut und/oder eine eigene Firmware für einen WS Sensor geschrieben?

einen eigenen Sensor auf Basis eines Cortex M0+. Ich war über den SHT75 (Feuchte-/Temperatursensor) gestolpert und der versprach in dem Bereich, der in der Bauphysik interessant ist (Luftfeuchtigkeiten zwischen 85 und 100%: Gefahr der Kondenat-/ Schimmelbildung) wesentlich höhere Genauigkeiten (± 1.8 %) als die "üblichen" Sensoren. Die Schaltung kann auch den HYT 271 auslesen, der ist genau so gut. Die Genauigkeit im Bereich 50 % ist nicht relevant, da passiert nichts. In der Tat ist es so, dass der SHT75 derzeit 80% anzeigt, der ASH 2000 liegt bei 71.5% und ein HomeMatic HM-WDS10-TH-O zeigt 74 %. Der SHT75 zeigt den richtigen Wert an. Im Übrigen waren zwei der ASH2000 ausgefallen und ich wollte sie ersetzen.

Ein Nebenziel war die Verringerung des Stromverbrauchs.

Ich bin gerade dabei, den Sensor auf HM umzustellen. WS2000 ist Altlast.

Gruß

Hermann

noansi

#76
Hallo Hermann,

im Anhang eine neue Firmwareversion für CUL_V3. Teste bitte zusammen mit 00_CUL.pm in der original Fassung statt meiner, damit Du kein Problem mit CUNO und HM bekommst.

Ich habe mal den Versuch einer Spike Filterung eingebaut. Mal schauen, ob es gegen die überflüssigen bits hilft. Alles, was kürzer als 80µs high ist sollte nun nicht mehr durch kommen.
Bitte sens auch wieder auf 8 setzen.

Zu dumm, dass wir die Einzelpulszeiten nicht aufzeichnen können, um zu einer sinnvollen Filterzeit zu kommen. Länger kollidiert auch mit einem anderen Protokoll.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

hermannk

#77
Hallo Ansgar,

vielen Dank für die Spezialfirmware. Ich habe sie auf den CUL433 geflascht und die 00_CUL-pm restauriert.

Jetzt heißt es erst einmal beobachten und die Spezialversion mit der Standardversion für sens =4,8,12 zu vergleichen. Da die Empfangssituation im Tagesrhythmus schwankt, muss ich für eine belastbare Aussage wohl einige Tage Daten sammeln, um sie nachher auszuwerten. Ich melde mich dann.

Nochmals vielen Dank

Hermann

hermannk

#78
ZitatGut, dann hat das zu viel gesetzte Bit entweder eine andere Bedeutung, oder es ist einfach immer gesetzt. -> in 14_CUL_WS.pm zu berücksichtigen, aber erst, wenn die Adressfrage klar ist. CUL hat damit erst mal nichts zu tun.
Lass es mal mit Wasser ;) regnen und schau, ob sich was am Bit ändert. Natürlich könnte die Regen-Sofort-Erkennung, sofern in dem Sensor vorhanden, auch durch Verschmutzung oder Beschädigung daueraktiv sein. Das Bit wäre zumindest noch geeignet, um dafür gut zu sein.

Inzwischen hat es geregnet. Ob Sonne oder Regen, die Adresse des Regensensors bleibt immer auf 15. Auf dem Board befinden sich vier Lötbrücken, die zur Adresseinstellung dienen könnten. Das würde alles erklären.






hermannk

Zitatbleibt immer auf 15

Der Vollständigkeit halber habe ich die Funktion der Lötbrücken der Regenmesserplatine beschriftet. Die rechte Lötbrücke ändert weder die Adressierung noch ändert sie das Erscheinungsbild der Übertragung, wie sie von CUL im X27-Modus dargestellt wird. Um es noch einmal klarzustellen: Die Adresse lässt sich im Bereich zwischen 8 und 15 wählen.

noansi

#80
Hallo Hermann,

angehängt findest Du eine neue Version zum Testen von/mit SlowRF.

In der Firmware habe ich noch an der Filterung gefeilt. Eventuell ist es jetzt etwas scharf.

Beim X kommt nun auch bei Bit 7 der RSSI, wie ursprünglich.

Dafür habe ich eine Timing Ausgabe der ersten 15 Daten- und Stopbits ergänzt. Die ist aktivierbar mit einer zusätzlichen 1 nach den bisherigen Codes, z.B. X211. Ausgegeben werden die ermittelten Timings für Low und High Bit und anschließend die Bit Timings, alle mit 16 zu multiplizieren.

Beispiel (allerdings noch die Ausgabe eines Syncs):
2015.02.01 17:00:20.822 2: CUL_0: unknown message C:51 23 21 54|51;25|51;24|51;25|51;24|51;24|51;24|51;25|51;25|21;54
2015.02.01 17:00:20.832 2: CUL_0: unknown message C|22;54|51;24|52;23|53;22|22;54|22;54#

Sollte CUL etwas überlastet sein und mehr als ein "bucket" genutzt werden, dann kann diese Timinginfo nicht gesammelt werden, bis das letzte "bucket" komplett mit Timingausgabe an den Host gesendet wurde, also dabei auf Fehlinterpretationsmöglichkeiten achten.

Wenn die beigepackte 00_CUL.pm genutzt wird (die Du wegen CUNO HM noch nicht nutzen kannst), dann wird das auch umgerechnet in us und in eine Logzeile gepackt, Beispiel:
2015.02.05 23:51:12.811 4: CUL_Parse: CUL_0 C:832 352 352 848 |352;848|848;368|832;368|848;368|352;848|848;368|832;368|848;368|848;368|352;848|352;848|848;368|352;848|864;352|368;848

Damit kannst Du also die Empfangstimings mit Deinen Sendetimings vergleichen.

Außerdem ist die BITs Ausgabe geändert, Beispiel:
2015.02.05 23:51:12.807 4: CUL_Parse: CUL_0 p 6  832  352  352  848  9  6 1 2C  52 886A1494B9AD80  368  176   0   0

Die 2C und 52 sind jeweils die RSSI Ausgabe, wobei die 52 als -52dB zu interpretieren sind. Am Ende hängen noch Anzahl Ansprechen Glitch Filter und Anzahl Ansprechen Pulszeitlimitunterschreitungsfilter (Spikefilter) an. Es werden dabei Low und High Zeit gefiltert/überwacht.

In der beigepackten 14_CUL_WS.pm ist der Regensensor nun drin (sofern ich nicht was übersehen habe). Testen kann ich es mangels Sensor leider nicht.

Wie sind Deine bisherigen Erfahrungen mit der letzten Firmware 99.73?

EDIT: Ich habe nun auch mal die Änderungen, insbesondere auch für Homematic Timestamp, bei CUNO und CUNO2 eingebaut und jeweils ein Firmware HEX File compiliert. Bei CUNO habe ich auf die Einzelbittimingausgabe ganz verzichtet, da ich die Speicherauslastung nicht kenne.
Da ich aber die Hardware nicht habe, kann ich leider nicht sagen, ob damit Komplikationen auftreten können. Mit Ethernet habe ich bisher gar keine Erfahrungen sammeln können.
Also in jedem Fall vor einem Test den vorherigen Firmwarestand und natürlich ein USB-Kabel bereit halten, um ggf. wieder zurück zu kommen!
00_CUL.pm ist nun angepasst, so dass alter Firmware Stand ohne Timestamp und Timestamp fähige Firmware genutzt werden können.

EDIT2: Eine Korrektur im Anhang für die Firmware, da ein Fehler bei der V1.1 Ausgabe wegen eines ungünstig verbliebenen ";" aufgefallen ist. Ich denke, nun sollte es richtig gehen. Danke Hermann.
Außerdem macht 14_CUL_WS.pm nun ein wenig Statistik zu den Empfangszeiten, die mit list <Sensorname> unter helper einzusehen ist.

EDIT3: Ich hab in der Firmware den Reboot (raw B00 oder raw e) deutlich verlängert (8s über den Watchdog). Damit klappt nun auch Disconnect/Reconnect. Zuvor mit schnellem Reboot ist es auf meinem RasPi beim Disconnect geblieben, und nur durch Reboot RasPi oder manuelles USB Ab- und Anmelden war ein Reconnect hin zu bekommen.
In 14_CUL_WS.pm habe ich beim Parsen aufgeräumt (hoffentlich nicht zu viel) und die Empfangsstatistik auf den RSSI ausgeweitet. Und...
In 00_CUL.pm kann man diese Statistik über "get dispWSStat" bequem für diesem CUL zugeordneten WS Sensoren anzeigen und über "set clearWSStat" auch bequem löschen. Bei "get ccconf" wird nun auch die AGC Einstellung und eingestellte Datenrate angezeigt. Beispiel (das nicht eine optimale Einstellung sein muss):

CUL_0 ccconf => freq:868.350MHz bWidth:325kHz rAmpl:42dB sens:8dB drate:6.868kBit/s agcprio:1 agcwait:16 agchyst:1

drate -> Datenrate (für SlowRF Empfang relevant für die übrigen Einstellungen und vermutlich auch die zeitliche Auflösung mit der der Pegel 0/1 übermittelt wird)
agcprio -> 0=LNA 2 Verstärkung wird vor LNA Verstärkung verringert, 1=LNA Verstärkung wird vor LNA 2 Verstärkung verringert (AGCCTRL1: AGC_LNA_PRIORITY)
agcwait -> Anzahl Kanal Filter Samples nach denen erneut AGC aktiv wird (AGCCTRL0: WAIT_TIME)
agchyst -> AGC Hysterese Einstellung (AGCCTRL0: HYST_LEVEL)

Diese Parameter können für SlowRF dann auch mit set jeweils bequem angepasst werden. Damit lässt sich hoffentlich noch eine bessere Einstellung für den SlowRF Empfang finden als bisher, vgl. auch cc1101 DN022 Design Note und cc1101 Doku. Jede Änderung geht über das EEPROM des AVR Controllers (>100000 Schreibzyklen laut Spec), wie auch die übrigen Einstellungen.

Edit5: kleine Korrektur in 14_CUL_WS.pm für die Statusausgabe Windsensor. Es fehlte jeweil ein Leerzeichen zwischen den Werten.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

Tobias

ohne jetzt alles gelesen zu haben, ist mit dieser Erweiterung jetzt auch HM auf einem CUNO sauber möglich?
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

noansi

#82
Hallo Tobias,

da ich mittlerweile mit einem CUNO2 testen kann, kann ich sagen, dass es über Netzwerk noch nicht sauber geht. Da gibt es noch ungeklärte Disconnects.
Über USB Anbindung sollte es gehen, sofern der CPU Takt nicht nach dem Mond geht. Die dafür nötige Korrektur ist im letzten Beitrag nicht drin.

Allerdings bin ich derzeit noch mit SlowRF beschäftigt. Da sehe ich noch rätselhafte Empfangsaussetzter (alle Sensoren), die sich teilweise erst nach mehreren Stunden erholen. Und dabei verhält sich nicht jedes Gerät gleich?!? Mache haben das Problem, manche empfangen durchgehend.

Gruß, Ansgar.

Fritz R.

Hallo,

ist es denkbar die Firmware auch für den nanoCUL zu bauen. Leider bin ich nicht so fit, dass ich das selber übernehmen könnte (würd ich aber mit Unterstützung probieren)
Konkret geht es mir darum das alte WS2000 Protokoll V1.1 mit einen nanoCUL empfangen zu können, die V1.2 gehen schon.
Was müsste ich von der Firmware hier alles in die nanoCUL Version übernehmen? Oder ist es einfacher diese Firmware für den nanoCUL passend zu machen?

Hab ich das richtig gesehen, dass es jetzt 3 verschiedene Zweige der Firmware für CUL gibt ?

noansi

#84
Hallo Fritz und Testwillige,

ich habe mal aus dem TRUNK 499 nanoCUL genommen und angepasst, so dass es mit meinen Änderungen compilierbar ist. Mangels Hardware kann ich aber nicht testen, ob es läuft, insbesondere, wie es mit dem freien Speicher aussieht. Das makefile und board.h sind für atmega328p konzipiert. Für die ältere Version mit kleinerem Prozessor sind Anpassungen nozwendig.
EDIT 1: Korrektur für NanoCUL. Es fehlte der uart_task, in der Hauptschleife. Deswegen konnte nichts mit der Kommunikation gehen.

Weiterhin habe ich SCC (STACKABLE CC) angepasst und getestet.

CUNO2 ist ebenfalls angepasst und getestet. Es sind mir nur gelegentliche Disconnects mit Reconnect aufgefallen. Der Ethernet Treiber ist noch Baustelle, denke ich.
CUNO ist ebenfalls dabei, aber mangels Hardware ungetestet.

Und natürlich ist CUL_V3 aktualisiert.

Die RF Tests beziehen sich auf SlowRF WS Sensoren mit Sendetest, TX3 Empfang und ASKSIN Empfang/Senden. Andere Protokolle kann ich nicht testen.

Wichtig: 00_CUL.pm, 16_STACKABLE_CC.pm werden für den ASKSIN Timestamp benötigt. 14_CUL_WS.pm ist angepasst/korrigiert für die WS-Sensor Auswertung. DevIo.pm enthält eine kleine Änderung zur Timeout Behandlung bei Disconnects.
Ob es mit dem aktuellen FHEM Versionsstand harmoniert, habe ich nicht getestet. Also erst die vorhandenen Dateien im FHEM Verzeichnis sichern und dann erst austauschen und testen.

Für ASKSIN Timestamp ist in 00_CUL.pm ein Scew-Faktor für die Zeitmessung ergänzt, der mit Pings in zunehmenden Abständen ermittelt wird. Hintergrund ist, dass die Taktfrequenz der CULs deutlich schwanken kann. 0.6% Abweichung zum Host ist keine Seltenheit (nur meine ersten Testlinge waren deutlich besser im Takt, daher ist mir das erst später störend aufgefallen. Martin kennt das Thema schon...).

Für Slow_RFgibt es nun auch eine Empfangs Statistik für die Sensoren. Das hilft ungemein für die Empfangsparameteroptimierung. Hermann hat mich auf den Gedanken gebracht, dass mal einzubauen. Beim Receiver (CUL) mit dispWSStat anzuzeigen und mit clrWSStat kann die Statistik gelöscht werden. Kann auch per Atrribut als Webkommando konfiguriert werden, ebenso wie ccconf, credit10ms und uptime.
Beispiel: attr CUL_0 webCmd credit10ms:uptime:ccconf:dispWSStat:clrWSStat

Die Umschaltung der RF-Modi habe ich in der Firmware umgebaut. So ist es möglich, in ASKSIN normal zu Emfangen und zu Senden und dann mal eben ein K-Kommando abzusetzen, um eine WS Testnachricht auf den Weg zu schicken. Die Firmware schaltet dann wieder zurück auf den vorherigen Empfangsmodus. Diese Variante habe ich jedenfalls erfolgreich getestet. (Natürlich ist während dieses Sendens kein Empfang möglich, so dass es natürlich ein gewisses Störverhalten gibt).

Wer mit REP_LCDMON (Bit 7 beim X Kommando) die RSSI-Ausgabe benötigt, muss sie mit #define HAS_RSSI_DISPLAY_NONLCD in board.h rein compilieren. Ich habe das rausgenommen und auch den pll-check auf alle 8s umgestellt, um nur noch selten während des Empfangs Transceiver Register abzufragen und damit den Empfang weniger zu stören.

Aufgefallen ist mir, dass einzelne meiner Testlinge schon mal im SlowRF lange Empfangsaussetzter (über 2 Stunden habe ich schon beobachtet) haben. Das fängt dann von alleine wieder (nein, nicht durch den Watchdog). Bisher habe ich aber keine Ursache dafür finden können (auch nicht im Code, aber vielleicht überseh ich da noch was). Da ich aber mehrere gleichzeitig auf Empfang der selben Sensoren habe und es nur bei bestimmten CULs/SCCs und nicht gleichzeitig Auftritt, hat es nichts mit den Sendern zu tun und es ist auch nichts Systematisches. Den Empfang erneut zu aktivieren hilft nicht und ein Reset des cc1101 Chips ebenfalls nicht. Nur die Empfangsparameter scheinen einen Einfluss zu haben (rAmpl, agcwait, agchyst).
Dafür gibt es dann einen Log Eintrag mit Komplettregisterausgabe, wenn länger nichts empfangen wird (hat aber auch keine neue Erkenntnis gebracht).
Der weitere zusätzliche Parameter dcBlockingoff funktioniert in SlowRF nur mit Einstellung 0, bei 1 habe ich noch nichts Empfangen können, vermutlich mache ich da was falsch.

@Hermann: Siehst Du auch diese längeren Empfangsaussetzer?

EDIT2: Korrektur für nextSend in 00_CUL.pm und 16_STACKABLE_CC.pm, um mit 10_CUL_HM.pm zu harmonieren.
Ausserdem ist in der Firmware für CUL_V3 die Initialisierung, sowie der B00 und B01 im Watchdog Timing geändert, um einen sicherern reconnect beim Ansprechen des Watchdog zu erreichen. Bei CUL_V3 kann der Watchdog Reset mit Raw BFF getestet werden, um das zu kompilieren dient der #define HAS_WATCHDOG_TEST.
Weiterhin ist in der Firmware das C Kommando um C0 erweitert und liefert mit "raw CC0" dann Cixxxxxxxx einen 32-bit Hex-Zähler für die seit Start aufgetretenen Interrupts von cc1101 (ISR(CC1100_INTVECT)). Das ist nützlich für SlowRF, wenn man Empfangsparameter sucht. Im aktualisierten 00_CUL.pm wird der zyklisch im Minutentakt abgefragt und daraus ein Reading "Ints_per_sec" beim CUL generiert. Unverhältnismässig viele Interrupts/s deuten auf instabile Empfangsparameter (AGC schwankt zu stark, sens ungünstig...) oder umgekehrt auf zu konservative Paramter.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

Fritz R.

#85
So, erster Test mit nanoCul leider nicht erfolgreich.

1. Versuch mit WinAVR (auf Windows 7)  selber zu kompilieren (Schnittstelle im makefile geändert) gibt folgende Fehler

Compiling C: nanoCUL.c
cc1.exe: error: unrecognized command line option "-maccumulate-args"
cc1.exe: error: unrecognized command line option "-mstrict-X"
make.exe: *** [nanoCUL.o] Error 1


Leider fehlt mir hier das Wissen, es handelt sich um Fehlermeldungen im Bereich Setzten von Kompilereigenschaften ?
In der letzten von mir selber kompilierten Version für nanoCul waren diese Zeilen nicht drin (und einige andere naturlich)

2. Versuch mitgeliefertes hex File direkt draufbügeln.

Funktioniert ohne Fehlermeldung, aber die LED am nanoCul die normalerweise nur beim programmieren flackert, hört nicht mehr auf zu flackern. Kurz ausgesteckt und wieder eingesteckt. Flackern weg und Sende LED blinkt im Sekundentakt. Soweit OK. Gehe ich aber mit einem Konsolenprogramm drauf kommt zwar
ReadyNanoCul
leider reagiert das Ding dann aber auf keine Eingaben. Ich weis nicht ob mit der Firmware auf "V" auch die Versionsnummer kommen sollte etc.
In FHEM eingebunden geht der Status auf opened aber dann geht auch nichts mehr.

Teste erst mal weiter, werde berichten.

Edit. Auskommentieren der beiden Fehlermeldungen bringt einen auch nicht weiter aber:
es scheint die cpufunc.h zu fehlen

Edit2: so testweise wieder die V1.63 draufgebügelt (499-trunk) . Geht wieder. Allerdings scheint es normal zu sein dass das Flackern der LED nicht aufhört, war mir vorher nicht aufgefallen. Jetzt kommt über Terminal kein ReadyNanoCul mehr, dafür kommt nach Eingabe von "V" die Version etc.
Kann das sein, dass mit dem zip-File was  altes gepackt wurde, bei mir steht da culfw-code 459... als Unterverzeichnis?

Edit3: evtl. auch ein Problem in meinem FHEM, die V1.63 bleibt jetzt auch auch opened stehen, erst nach shutdown kommt initialized. Probiere das morgen nochmal mit der .hex

noansi

Hallo Willi,

danke für das Feedback un Asche über mein Haupt, siehe Edit 1 im letzten Betrag. Da konnte ausser "ReadyNanoCUL" nichts kommen, weil keine Kommandos bearbeitet wurden. Lad es bitte nochmal runter.

Die LED sollte einfach nur vor sich hin blinken. Das ist die Default Einstellung. Das EEPROM wird bei Versionsnummerwechsel immer komplett neu mit Defaults beschrieben.
Mit dem LED Kommando kann man das Blinken abschalten, wenn es stört.

Die beiden Compiler Optionen sind im Makefile auch mit Kommentar beschrieben (ich benutze gcc).
Wenn der Compiler sie nicht versteht, dann Kommentier sie einfach mit einem "#" am Zeilenanfang aus.

Gruß, Ansgar.

noansi

Hallo zusammen,

nur damit es bemerkt wird, mein letzter Beitrag mit Anhang http://forum.fhem.de/index.php/topic,24436.msg283515.html#msg283515 ist aktualisiert.

Gruß, Ansgar.

Fritz R.

#88
Hi,

sorry für die verspätete Antwort, war leider als Standpersonal auf der Hannovermesse eingeteilt. Ausser Kugelschreibersammlern nichts gewesen.
Danke für die Überarbeitung.
So ich hab jetzt mal die hex drauf, Konsolenfuktion sieht gut aus. FHEM meldet initialised.

Edit:

Ich habe scheinbar noch ein paar Probleme mit den alten Sensoren:

so habe ich im Log viele Eintrage mit

CUL_WS_Parse: CUL_WS_1 Error: temp/hum Cannot decode K01AA0A00 (sanitycheck). Malformed
Was kann das sein ?

noansi

#89
Hallo Fritz,

erste Frage, empfängst Du nun überhaupt Deine Sensoren? Hast Du schon Werte gesehen?

ZitatWas kann das sein ?
Offenbar hast Du Bitfehler beim Empfang. Gelegentlich habe ich auch diese verkrüppelten Pakete im Log, in CUL_WS habe ich die Sinnhaftigkeitsprüfung noch etwas verfeinert und von da kommen diese Log Einträge. Die Checksummenprüfung, die schon in CUL läuft, ist zu schwach, um solche fehlerhaft empfangenen Daten auszufiltern, erst recht bei Protokoll V1.1.

Was geholfen hat, ist die Empfangssitutation durch Optimierung der Antenne zu verbessern und an den Empfangsparametern für SlowRF zu spielen.

Das Reading Ints_per_sec gibt ggf. einen Hinweis auf viele kurze (Stör-)Pulse vom Empfangsbaustein. Bei guter Einstellung sind es dann bei mir etwa 20 Interrupts pro Sekunde (bei einer 868er CUL). "Kurzzeitig" gehen die aber auch mal auf 1000 hoch.
Viele Interrupts bedeuten entweder, dass viel Rauschen empfangen wird oder die AGC Regelschleife zu heftig schwankt/instabil läuft. Dann gibt es in der Doku zum cc1101 Tranceiver für den gewählet Empfangsmodus noch Spikes, die unregelmäßig auf dem Signal auftauchen können. Eventuell kommen die bei nanoCUL wegen der höheren Taktfrequenz besser durch?!?
Wie häufig die sein können wird von TI aber nicht genauer angegeben. Nur die Länge passt +/- gerade noch so in die Eingangdfilterung des Atmel rein. Ein Tiefpassfilter soll helfen, die los zu werden. In der Firmware habe ich aber auch eine Filterung drin, die funktionieren sollte, wenn die nur gelegentlich mal kommen.

Das Reading TO_Ints_per_sec gibt an, wie viele Empfangspakete pro Sekunde CUL intern zur Auswertung kommen, sprich überhaupt als Datenpakete in Frage kommen. Hängt natürlich von der Anzahl der Sensoren ab, aber muss schon deutlich unter 1 liegen (je nach Typ und Adresse senden die nur ja alle etwa 170s ein Paket).

Eine Beispielhafte Einstellung meiner 433er CUL:
CUL_WS433 ccconf => freq:433.920MHz bWidth:325kHz rAmpl:40dB sens:8dB drate:1.637kBit/s agcprio:0 agcwait:32 agchyst:1 dcBlockingoff:0
Die 433er CUL rennt mit etwas 200 Interrupts pro Sekunde. Die habe ich noch nicht ruhiger bekommen können, ohne auch deutlich Empfangspakete zu verlieren.
Leider musst Du mit den Parametern spielen, um das zu optimieren. Scheint Empfängerabhängig zu sein. Die goldene Einstellung habe ich noch nicht finden können.

Gruß, Ansgar.