Fehlersuche bei Funk-Temperatursensoren

  • Mich irritiert die Bezeichnung ...
    Pins bei ICs werden üblicherweise von links oben nach rechts oben entgegen dem Uhrzeiger-Sinn durchgezählt.
    In der von dir weiter oben geposteten Belegung wird aber z.B. Pin Nr. 8 (PA5) als Pin 5 und er physikalische Pin Nr. 2 als Pin 10 angegeben. Das ist eine andere Zählweise (im Uhrzeiger-Sinn) die zudem Vcc und GND nicht mit einschliesst.
    Ich frage mich halt, ob und was das jetzt mit dem ATTiny resp. Funkmodul zu tun hat. Möglicherweise müssten andere Pin-Nummern im sketch verwendet werden.
    Mal meigrafd fragen ...



    cu,
    -ds-

  • Nicht so:


    #define rxPin 7 // D7, PA3
    #define txPin 3 // D3, PA7. pin der an RXD vom PI geht.


    sondern so


    #define rxPin 3 // D7, PA3
    #define txPin 7 // D3, PA7. pin der an RXD vom PI geht.


    und jetzt klappt es!



    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...
    ...Loop...



    Baue jetzt erstmal alles wieder zusammen...

  • ..ohne jetzt allles gelesen zu haben:


    Wenn man im Sketch eine Nummer angibt, bezieht sich das nicht auf die Pin#:

    Code
    #define rxPin 7 // D7
    #define txPin 3 // D3


    Was das ist steht auch extra dahinter.
    rxPin 7 ist = D7 / PA7 -> pin#6
    txPin 3 ist = D3 / PA3 -> pin#10


    Die pin# ist die Nummer des Beinchens. Diese Pins beziehen sich generell auf den ATtiny84, wie sie dort eben angeschlossen wurden. Oben links fängts mit 1 an, linke Seite runter bis 7 dann gegenüberliegend rechts #8 und rechts nach oben ans Ende...
    Das hat erst mal nichts mit dem PI zu tun, da sind die Nummerierungen freilich anders. Beim PI geht das aber im ZickZack: links oben 1, gegenüber 2, links unter 1 ist dann 3, rechts daneben 4 usw


    Wenn du das jetzt verdreht hast, hattest du vorher einfach nur die Kabel falsch am PI angeschlossen...

  • Moin


    Von den unterschiedlichen Bezeichnung der Pins wusste ich noch nichts.
    Zumindest was gelernt bei der Aktion :)


    Ich bin aber noch nicht ganz durch mit der Fehlersuche.


    Sender:
    ATt, DS18B20 und Funkmodul bekommen Strom.
    Kein Kurzschluss und alles richtig verschaltet.
    Ich habe alles mit dem Multimeter durchgemessen.


    Aber ich kann ja gar nicht wissen ob der Sender funktionier,
    wenn ich mir beim Empfänger auch nicht sicher bin...


    Empfänger:
    ATt, Funkmodul und LED bekommen Strom
    LED blinkt drei mall wenn ich den Empfänger anschließe,
    dann aber nicht mehr...
    Verbindungen sind auch alle überprüft und passen.


    Sollte die LED auch leuchten, wenn ich auf einer 433Mhz Funkfernbedienung rumdrücke?
    Und wenn die LED nicht leuchtet, wird wahrscheinlich auch nicht von minicom empfangen, oder?


    Gruß Kolja


  • Empfänger:


    LED blinkt drei mall wenn ich den Empfänger anschließe


    Wieso 3x? Innerhalb welches Abstands?


    Im Sketch ist vorgesehen das er 1x beim Setup für eine Sekunde an und wieder aus geht, also blinkt ein mal.


    Wenn etwas empfangen wird was OK ist, blinkt er 2x , mit einem blink-Abstand von 100ms. Wenn aber etwas empfangen wird was nicht OK ist, also BAD CRC, dann blinkt er nur 1x , auch wieder zwischen An/Aus = 1 Sekunde.


    So kann man dann halt auch optisch Unterschiede erkennen...


    Sollte die LED auch leuchten, wenn ich auf einer 433Mhz Funkfernbedienung rumdrücke?


    Nur wenn deine FB genau die selbe Frequenz nutzt, was aber unwahrscheinlich ist da es nicht einfach nur 433 MHz sind sondern der Bereich geht von 433,05 MHz bis 434,79 MHz ...


    Und wenn die LED nicht leuchtet, wird wahrscheinlich auch nicht von minicom empfangen, oder?


    Minicom hat erst mal nichts mit irgendeinem empfangen zu tun. Ob man über minicom etwas sieht hängt in erster Linie von der korrekten Verkabelung aber auch von der richtigen Baudrate ab, um über UART etwas zu empfangen. Der RFM12B Empfänger empfängt aber unabhängig etwas

  • Nabend


    Also die LED blinkt 1x lang und 2x kurz.
    Hab n Video gemacht, finde es jetzt aber nicht mehr bei Youtube...


    Danke für die Antworten bzgl. Fernbedinung und minicom


    Der ATtiny ist ja in Ordnung, kann es sein, das das Funkmodul defekt ist?


    Kolja


    edit:


    Video wieder gefunden:

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Edited once, last by kolja ().

  • So, gestern Abend/heute Nacht nochmal von Null angefangen und es funktioniert endlich.
    Ich habe nicht die Anleitung aus dem Forum hier benutzt,
    aber so wie ich das einschätzen kann, tut sich da nicht viel.
    Die Hardware ist exakt gleich.


    Es muss irgendwie am Flashen gelegen haben, da mit den "neuen" ATtinys auch die alte Sender und Empfängerplatinen funktionieren.


    Hier noch mal der Link zu der o.g. Anleitung:
    http://raspberry.tips/hausauto…auen-teil-1-projekt-info/


    Vielen Dank für eure Hilfe!


  • Hier noch mal der Link zu der o.g. Anleitung:
    http://raspberry.tips/hausauto…auen-teil-1-projekt-info/


    Quote

    Die Anleitung basiert auf den Infos von Meingraf und Nathan.


    ...der kann immer noch nicht meinen Namen richtig schreiben...


  • Hi,


    ich wärm diesen Thread einfach noch mal auf, um neben falscher Verkabelung und fehlerhafter Programmierung eine weitere Fehlermöglichkeit aufzuzeigen, warum das 'cat /dev/ttyAMA0' nichts anzeigt.


    Bei mir war das auch so und als ich auf diesen Thread gestossen bin, hab ich natürlich alle Tips befolgt. Doch es tat sich weiterhin nichts. Dann hab ich schließlich das kurze Progrämmchen aus Beitrag #5 genommen, noch ein LED-Blink mit "delay(500);" eingebaut, geflasht (mit Arduino IDE auf MacOS) - und siehe da: die LED blinkt. Doch am seriellen Port tat sich immer noch nichts.


    Alles zum x-ten mal kontrolliert, schien weiterhin ok. Aber dann fiel mir auf, daß die Diode sehr langsam blinkt - statt einer halben Sekunde mindestens zwei! Irgendwie lief wohl alles langsamer ab als programmiert.


    Das brachte mich in einem Geistesblitz auf die Idee, daß auch die UART-Baudrate langsamer sein könnte als auf dem Raspi eingestellt. Also mit stty die Baudrate jeweils halbiert und nach ein paar Versuchen ging es mit 'stty 1200 -F /dev/ttyAMA0' tatsächlich: ...Loop... ...Loop... ...!!! :s


    Ich hab schon schon einiges gegurgelt und könnte mir vorstellen, daß es an diesen Fuses liegt. Hat jemand von dem hier versammelten geballten Fachwissen eine Idee? Ich bin da wohl in eine böse Anfänger-Falle gelaufen.


    Gruß, Jürgen

  • Puuh,


    ich konnte diese Sache doch noch heute lösen, ich hatte schon echte Befürchtungen.


    Typischer Anfängerfehler: Flashen des Bootloaders für 8MHz/internal Oscillator vergessen :blush:


    Bzw. so ganz klar ist mir das noch nicht. Diese Attinys werden wohl mit Fuses für 1MHz ausgeliefert bzw. eventuell auch mit 8 MHz, doch der Takt wird durch 8 geteilt. Doch es sollten wohl trotzdem 9600 Baud möglich sein? Alles sehr merkwürdig, muss wohl doch noch ein wenig Grundlagen durcharbeiten :)


    Jedenfalls läuft die Schleife jetzt mit 9600 Baud, alles im grünen Bereich.


    Danke für eure Geduld.
    Jürgen

  • Hallo zusammen,


    wenn ich darf, würde ich den Thread auch nochmal gerne aufwärmen mit einem etwas anderen Problem, da dieses hier offenbar gelöst wurde...


    Ich habe Empfänger und Sender nach dieser Anleitung gebaut und programmiert.
    Die ATTinys sind mit dem RasPi direkt geflasht worden, hat auch alles geklappt, die Testprogramme laufen darauf. Der Sender sendet lediglich eine Testzeichenkette, der Empfänger gibt alles aus, was er empfängt.


    Jetzt beginnt das Problem:
    Ich bekomme beim Empfänger solche Ausgaben wie diese hier:


    Empfänger hat die NodeID 10, NetworkID 200, der Sender hat die NodeID 21, gleiches Network und Gateway die 10 vom Empfänger...
    Die ersten Ziffern, die ausgegeben werden, sind die ID des Senders. Das ist schon verwunderlich, da nie die eigentliche NodeID des Senders ausgeben wird, sondern immer andere. Zwischenzeitlich werden auch Daten empfangen, die nicht vom Sender stammen, vermutlich andere Geräte in der Nähe. Wenn mein Sender aber sendet, erscheint meist die "0" als ID, was ja eigentlich für Broadcast reserviert ist.


    Hier auch mal meine Sketches:
    Empfänger:


    Test-Sender:



    Ich verzweifel langsam!:@:wallbash: Was mache ich falsch??


    Gruß, Benny

  • necromundo: Hast du dein Problem gelöst? Ich habe auch zwei Sender mit unterschiedlichen NODE ID's und bekomme cryptische Zeichen bei dem DHT22!


    Empfänger

    Code
    #define NODEID            22  //network ID used for this unit
    #define NETWORKID        210  //the network ID we are on


    DHT22

    Code
    #define NODEID          1   // network ID used for this unit
    #define NETWORKID     210   // the network ID we are on
    #define GATEWAYID      22   // the node ID we're sending to[/php]


    DS18B20

    Code
    #define NODEID         2  // RF12 node ID in the range 1-30
    #define NETWORKID    210  // RF12 Network group
    #define GATEWAYID     22  // the node ID we're sending to


    Beide habe ich mit Watchdog Sketch kompiliert! Beide hängen noch an RasPI dran.



  • necromundo: Hast du dein Problem gelöst? Ich habe auch zwei Sender mit unterschiedlichen NODE ID's und bekomme cryptische Zeichen bei dem DHT22!


    Hallo,
    nur als Anmerkung: Ich hatte mir vom meigrafd-github
    https://github.com/meigrafd/TinyRX4
    für meinen DHT22 den Sketch
    Send_DHT22_Watchdog.ino
    geladen und anfänglich ebenfalls solchen "Müll" erhalten.
    Bis ich im Sketch auf Zeile 184 gestoßen bin und diese auskommentiert habe:


    radio.Encrypt((byte*)KEY); // comment this out to disable encryption


    Vielleicht hilft es....

  • Hallo zusammen,


    bei mir war das leider nicht der Grund!
    Oben in den Sketches sind die entsprechenden Teile vorsorglich komplett auskommentiert, kann also daran nicht liegen! Auch wenn der Datenmüll recht ähnlich aussieht.
    Ich bin auch noch nicht weiter bei dem Problem, mir sind die Ideen ausgegangen....


    LG, Benny


  • bei mir war das leider nicht der Grund!


    Neben der Verschlüsselung gibt es noch andere Gründe für den Datenmüll:
    Baudrate, Anzahl Daten- und Stoppbit sowie Parität. Auch die Spannungspegel der RX- und TX-Signale können durch Jitter solchen Müll erzeugen. Das sind aber Gründe aus der PC-Technik. Bin selbst (noch) zu wenig in der Tiefe der Sketche, um abzuschätzen, wo diese Parameter gesetzt oder auch nicht gesetzt werden. Wenn, dann kann das ja auch eigentlich nur im RasPI eine Falscheinstellung sein.
    Siehe Dir dazu mal den Eintrag 52 und 53 in diesem Thema an.


    Kurze Anmerkung zur Quelle deiner Bauanleitung:
    Der liebe Phillipp S. aus F ist wohl ein recht reproduzierenden Künstler. So stammt meines Erachtens sein gesamter Beitrag "Funksensoren.." im wesentlichen aus diesem Forum "Entwicklung: Temperatur Funk Sensor" von meigrafd. Und da die konsequente Durcharbeitung von inzwischen über 1300 Antwort etwas aufwendig ist, hat sich dort auch der eine oder andere Fehler eingeschlichen. :auslachen:
    Das Problem mit dem Datenmüll ist auf Philipps Forum auch zu finden. Die Antworten allerdings eher "dünn".
    Dem Forum ist es einfach wichtig, möglichst viele Leute auf seine Seiten zu locken, damit man denen dann möglichst viele Werbe-Cookies um die Ohren hauen kann. Ich empfehle, die Inhalte mit Vorsicht zu genießen. :angel:


    Meigrafd hat das Thema übrigens auch sehr gut nochmals kondensiert (und fehlerfrei ;))
    zusammengestellt:
    [Messen, Steuern, Regeln] Batteriebetriebene Funk Sensoren