Beiträge von wend

    DIe Hauptroutine (main()) macht eigentlich nichts weiter als die Zeiten zwischen Pegelwechsel zu messen.

    Bei einem langen 1-Puls (>9000 Mikrosekunden kein Signal) wird synchronisiert. Wenn mehr als 10 Pegelwechsel (tcount) erkannt worden waren, dann wird das Timingmuster ausgegeben und decodiert. Glitches bzw.Prellen, oder auch Pulse kürzer als 5 Mikrosekunden werden ignoriert.

    Wenn also irgendwas sinnvolles erkannt wird, wird die Routine printout() aufgerufen. Ansonsten weiter empfangen.

    Printout analysiert dann nochmal die Zeiten zwischen den Pegelwechseln und versucht daraus zu erraten, welches Protokoll verwendet wurde, bzw. welche Protokoll-Klasse:

    timing[0] ist dabei die Länge des Sync-Pulses, den die meisten Sender als Beginn einer Nachricht senden. Hier konnte ich mal 4 verschiedene typische Längen ermitteln, je nach Sender. Aber da kann es natürlich noch mehr geben.Je nach Pulslänge wird dann die variable protocol gesetzt. und mint ist dabei glaube ich die Clock für das Protokoll, also das Raster in dem die Bits abgetastet werden. (in Mikrosekunden).

    Dann gibt es verschiedene Dekodsierungsmethoden: Länge der 1-Pegel, wobei jedes Bit mit einem 0->1 Wechsel anfängt, oder Wert in einem starren Raster, oder Manchester-decodierung (siehe Wikipedia). Mehr hatte ich glaube ich noch nicht implementiert.

    Nun, da ist nun etwas Kreativität gefragt. Zunächst gilt es die Bits korrekt zu demodulieren. Dafür sind die Timings und Anzahl der Pegelwechsel, ggf über Statistiken zu ermitteln. (Stichwort manchester). Das macht der Code auch schon zumindest zum Teil. Danach dann "nur" noch das Bitmuster zu entschluesseln (Stichwort rolling codes oder so). Den letzen Schritt kann man bei einfachen Tastern leicht machen, indem man sich das Bitmuster einfach merkt, wenn jede Taste immer dasselbe liefert.

    Ich glaube, es war gemeint:

    "Mein Programm ist aus verschiedenen (Anleitungen von Experten) zusammengebastelt" und nicht

    "Mein Programm ist (aus verschiedenen Anleitungen) von Experten zusammengebastelt"

    Dass der Python-Interpreter selbst memory holes, also schwerwiegende Bugs hat, ist zwar nicht ausgeschlossen, aber doch etwas unwahrscheinlich.

    versuch mal 0x3f003000 anstelle der 20003000 im timer.c. Ich hab gerade gelesen beim Pi2/3 hat sich das geaendert. Ich kanns aber leider nicht selbst testen. Hab nur Pi1

    #define ST_BASE (0x20003000)

    Also soweit ich das in der Tiefe nochmal anschaue liegt das Problem nicht an der library sondern in timer.c.

    Folgende Voraussetzungen muessen gegeben sein: 32bit betriebsystem und die Basis-Speicheradresse fuer den Timer muss passen.

    Ich bin nun nicht sicher, ob das für den Pi3 noch zutrifft. Deshalb muss in timer.c ggf etwas angepasst werden.

    FInde mal raus, was sizeof(int) sagt. und sizeof(void *). Beides sollte 4 ergeben.

    Hallo fsgu4, ich kann nicht wirklich weiterhelfen, denn der orginal-code funktioniert eigentlich ganz gut. Es haben auch schon Leute nachgemacht, also glaube ich nicht, dass ein Fehler in der Anleitung ist.

    Ich kann also nur nochmal empfehlen, erstmal keine Modifikationen am Code zu machen, und dann muss das gehen. Jede Modifikation verändert das Timing (ja, auch printf() braucht relativ viel CPU-Zeit). Aber wenn ich das so Deinen Schilderungen entnehme, dann ist irgendwas mit der bcm2835 library nicht in Ordnung, oder es geht nicht auf den neuen Raspis. Das wurde noch nicht getestet.

    Ein inkrementelles Backup läßt sich mit folgendem Script realisieren (was als cronjob jestartet werden kann, z.B. taeglihch):

    Man kann dann jeweils den Zustand eines jeden Tages rekonstruieren, dennoch werden nur neue und Veraenderte Dateien archiviert. Das ganze Platzschonend noch gebzipt. Ausserdem kann man eine Liste von Dateien, Ordnern etc. angeben, welche vom Backup ausgelassen werden sollen.

    Ich hab da z.N. noch folgende ausgeschlossen:

    [code]

    ...

    --exclude="$START/.xsession-errors*" \

    --exclude="*/Crash\ Reports/*" \

    --exclude="*.o" \

    --exclude="*/b.b" \

    --exclude="*/delme*" \

    --exclude="$START/tmp" \

    --exclude="$START/.cache" \
    ...

    [code]

    Das kannst Du dann noch an die eigenenen Wünsche anpassen.

    Soll beim nächsten mal wieder ein full-backup gemacht werden, dann musst Du einfach das File $START/.mybackup.snar

    löschen. Das kann ein anderes Cron-script machen, z.B. wöchentlich oder monatlich...

    Ich nehme mal an, Du setzt Blei-Gel Akkus ein. Dein Solarladeregler sollte dann unbedingt die Spannung (14.0V) einhalten. Hochdrehen (wenn das ueberhaupt geht) würde ich nicht machen. Wenn Die Spannung (an den Batterieklemmen gemessen) stark absinkt, wenn die Last an ist, dann bedeutet das, der Innenwiderstand des Akkus ist (zu) hoch. Dann ist entweder der Akku schon alt oder kaputt oder seine Kapazität ist für den Zweck zu klein.

    Bei einer Last von ca 100W schaetze ich mal, dass Du bei 12V Systemspannung mindestens 50Ah Akkus einsetzt. Wenn dann Der Kühlschrank nicht mehr funzt, dann liegt es (sofern der Akku nicht kaputt ist) an der Zuleitung zum 230V Wandler. Die Kabel sind nicht dick genug oder zu lang, oder aber Du hast Ihn nicht direkt an der Batterie angeklemmt, sondern am Last-Ausgang des Laderegglers. Letzteres ist keine Gute Idee, denn die 10A muss der erstmal abkönnen, und wenn das so grad an der Grenze ist, dann gibt es auch dort Spannungsabfall.

    Also:

    1. Spannungswandler auf 230V direkt an der Batterie anklemmen.

    2. Dickere und kürzere Kabel verwenden.

    3. Spannung des Solarladereglers nicht verändern, sonst kochen die Akkus und gehen kaputt.

    Ich printf mir auch Dein tcount und was mich wundert ist, dass tcount bei mir immer 0 ist und *timer auch immer den gleichen Wert hat.

    Das soll definitiv nicht sein. Könnte es sein, dass Du mit -O -O2 oder -O3 kompiliert hast? Dann optimiert der compiler evtl. das erneute lesen der Speicherstelle weg (volatile).

    Nochmal zur Erinnerung:


    Nochwas: Das Programm muss mit sudo gestartet werden, da sonst der 1MHz Timer nicht funktioniert.

    Wenn ich meinen Empfänger abziehe, kommen nur 00000. Wenn ich den Empfänger dran habt, kommt seeeehr viel durcheinander mit 0 und 1. Sieht ziemlich nach Rauschen aus, daber daher weiss ich auch, dass ich am richtigen PIN dran bin.

    Ja, das muss so sein. Die zufaellig erscheinende Folge von 0 und eins ist das Empfaengerrauschen. Mein Programm findet darin ja den Strat der Sendefolge. Dein Empfaenger ist also schonmal korrekt angeschlossen. Was nicht geht, ist offenbar der interne Timer des Raspberrys.

    Das Problem hab ich auch. Allerdings aufhaengen erst nach ca. 4 Tagen, manchmal erst nach ner Woche.

    Ich vermute Störungen über die (langen) Signalleitungen zum und von den Sensoren. Oder Spikes auf der Stromversorgung. Softwareprobleme konnte ich ausschliessen (Speicher bis 1 Minute vor Ausfall normal leer, keine ungewöhnlichen Prozesse, keine Kernel-Panik oder ähnliches.) Der Pi stellt einfach den Betrieb ein und macht dann gar nix mehr. Der Watchdog geht dann übrigens auch nicht, was sehr ungewöhnlich ist. Also ist es wohl ein Hardware-problem (Raspi B+).