Entwicklung: Temperatur Funk Sensor

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Nicht niedrigen Strömen sondern Spannungen :fies: Aber ja, das ist ein allgemeines Problem..

    DerMega: Vermutlich haben wir diesmal sogar 2 SMD fähige. Aber wie auch beim letzten mal sinkt der Preis um so mehr sich daran beteiligen - um also überhaupt zu wissen wie viel ein Module kosten würde muss man erst wissen ob 100 oder 200 Stück "produziert" werden sollen.


    Ich hab mal einen neuen Thread zur 2.Sammelbestellung sowie eine Umfrage gestartet:
    2.Sammelbestellung Tiny(R/T)X4

    Bitte alles weitere diesbezüglich dort in dem Thread abhandeln!

  • keulemaster
    Vielen Dank für die Bereitstellung des Sketches für den DS18B20 mit Watchdog (Beitrag #1096). Habe jetzt versucht, den Sketch mit meinem Raspi auf den Attiny84 zu schreiben; bekomme jedoch beim Kompilieren folgende Fehlermeldung:

    Send.cpp:79:1: error: stray '##' in program

    Kann damit leider gar nichts anfangen.

    Wäre für Hilfe dankbar.
    immergut


  • An dieser Stelle noch mal zur Erinnerung:
    Der ATtiny Chip verträgt maximal 5,5V.
    Das RFM12B Modul verträgt maximal 6V.
    Der LTC3525 boost regulator chip verträgt maximal 5,5V.
    Die anderen Bauteile (Kondensatoren und Spule) vertragen afaik maximal 6V.

    Das RFM69CW Modul, welches ja baugleich mit dem 12b ist
    und lt. Hoperf der Nachfolger sein soll,
    verträgt nur 3,9V!
    http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf

    Nur falls das für eure Stepper wichtig ist.

    Kolja

  • immergut
    also wegen sketches komplieren... wenn man dir helfen soll, wäre besser, wenn man sähe was du wirklich kompilieren willst. Ich vermute du hast beim sketch file anlegen, irgend etwas verhunzt. :lol:

    meigrafd
    nein! :fies: egal ob eingangsspannung niedrig oder hoch, je weniger strom du "entnimmst" umso schlechter der wirkungsgrad. natürlich ist bei niedriger spannung ist der wirkungsgrad noch schlimmer, aber auch bei hoher eingangspannung dürfte der wirkungsgrad bei so kleinen Strömen (<1mA) unter 50% liegen.

    Einmal editiert, zuletzt von keulemaster (9. Januar 2015 um 19:30)

  • keulemaster: ..ich hab das mit dem wirkungsgrad schon verstanden.. beim ltc3525 ist der wirklungsgrad auch bei niedrigem bedarf oder einspeisung recht gut.

    Aber kannst du deine Sketches bitte bearbeiten und mit CODE umschließen?

  • I2C existiert da zwar nicht als "build in" aber ein sog. "Universal Serial Interface" (USI) welches für I2C und SPI verwendet werden kann. Hierzu würde man nicht die Wire.h wie für normale Arduino's benötigen, sondern TinyWire

    Hier mal das entsprechende Pinout was hierfür wichtig ist:

    Code
    //                     +-\/-+
    //               VCC  1|    |14  GND
    //          (D0) PB0  2|    |13  AREF (D10)
    //          (D1) PB1  3|    |12  PA1 (D9)
    //               PB3  4|    |11  PA2 (D8)
    //      PWM (D2) PB2  5|    |10  PA3 (D7)
    //      PWM (D3) PA7  6|    |9   PA4 (D6) SCK
    // SDA  PWM (D4) PA6  7|    |8   PA5 (D5) PWM
    //                     +----+
    &quot;beispiel Sketch&quot;

    Wie man sieht muss man D4 für SDA und D6 für SCK verwenden.

    Nun gibts allerdings das Problem das bei unseren TinyTX4 PCB's genau diese Pins nicht als Lötauge ausgeführt sind, sondern nur:

    Lötauge # 0 auf der TinyTX4 Platine geht an pin#2 vom ATtiny und trägt die Bezeichnung: D0 / PB0
    Lötauge # 3 auf der TinyTX4 Platine geht an pin#6 vom ATtiny und trägt die Bezeichnung: D3 / PA7
    Lötauge # 7 auf der TinyTX4 Platine geht an pin#10 vom ATtiny und trägt die Bezeichnung: D7 / PA3
    Lötauge # 8 auf der TinyTX4 Platine geht an pin#11 vom ATtiny und trägt die Bezeichnung: D8 / PA2
    Lötauge # 9 auf der TinyTX4 Platine geht an pin#12 vom ATtiny und trägt die Bezeichnung: D9 / PA1
    Lötauge # 10 auf der TinyTX4 Platine geht an pin#13 vom ATtiny und trägt die Bezeichnung: D10 / PA0

    Bei genauerer Betrachtung des TinyTX4 Schaltplans sieht man das D4 und D6 anderweitig verwendet werden:

    ATtiny pin#7 geht auf ICSP pin#1 (MOSI) und auf RFM12B pin SDO
    ATtiny pin#9 geht auf ICSP pin#3 (SCK) und auf RFM12B pin SCK

    Man könnte diese Pins also auch vom ICSP Sockel abgreifen. Allerdings weiß ich nicht inwiefern das beim späteren Betrieb Probleme machen könnte da diese Pins bereits vom RFM12B verwendet werden...

    Ich glaube allerdings dass das nicht funktionieren würde da diese Pins bereits als SPI fürs RFM12B verwendet werden!

    Inwiefern man andere Pins für I2C verwenden kann, weiß ich nicht :s

  • Ich versuche gerade meine TinyTX3 Sensoren zum leben zu erwecken. Wenn ich beim Pi die UART-Schnittstelle freigebe:


    [an=UART][/an]UART:

    Die UART-Schnittstelle wird bei Raspbian wheezy standardmässig als serielle Konsole genutz. Damit die UART-Schnittstelle anderweitig genutzt werden kann, ist diese Funktion zu deaktivieren...

    Dazu in der Datei /boot/cmdline.txt folgende Parameter löschen:

    Code
    console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

    Anschliessend sollte die Zeile wie folgt aussehen:

    Code
    dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

    startet mein Pi nicht mehr - was läuft da falsch?
    Installiert ist NOOBS mit Wheezy 3.12.26+ #7

    OK - Mit einem frischen Raspian geht es dann :)

    Bei mein TinyTX3 Sender mit einem DHT22 und LED habe ich beim senden ein fröhliches Blinken - aber am TinyTX3 Empfänger mit dem Receive_PI Sketch aus meigrafd's Sketchbook blinkt nix. Die Network ID's passen zusammen, die Node ID des Empfängers ist 22, die Gateway ID des Senders ist auch 22. Ist das der richtige Sketch?

    Einmal editiert, zuletzt von doing (13. Januar 2015 um 17:00)

  • ist es möglich damit füllstandamesser(heizöltank), Temperatursensoren, Helligkeitssensoren, Bewegungssensoren, aber auch Sensoren fürs Wetter oder für Magnetsensoren(Fenster offen/zu) zu verwenden, bzw damit auch relais(über funk) (für zb licht) zu steuern oder die ergebnisse graphisch wieder zu geben

  • Jetzt habe ich den Receive.ino und den Receive_Pi.ino Sketch aus dem Sketchbook probiert - ich bekomme nix vom Empfänger rein, wenn ich Minicom aufmache. Auch ein

    Code
    void setup() {
      mySerial.println("Blubber");
      ...
    }

    im Sketch für den Empfänger bringt keine Ausgabe in Minicom, wenn ich den Empfänger bei geöffnetem Minicom mit Strom versorge. Bootloader und Sketch(es) ließen sich aber Problemlos auf den Attiny flashen. Hat jemand noch einen Tipp wo mein Fehler liegen könnte?

    Wie gesagt, ich versuche den TinyTX3 als Empfänger am Pi zu betreiben, was ja gehen sollte...

  • Nachdem ich UART in meiner NOOBS Installation nicht wie beschrieben freigeben konnte habe ich ein frisches Raspbian aufgespielt - dort konnte ich UART wie von dir beschrieben freigeben.
    RX vom Pi hängt an Lötauge 3 des TinyTX3 / Pin 6 vom ATtiny wie auf deinem Stripboard angegeben.

    Einmal editiert, zuletzt von doing (14. Januar 2015 um 10:58)


  • RX vom Pi hängt an Lötauge 3 des TinyTX3 / Pin 6 vom ATtiny wie auf deinem Stripboard angegeben.

    Bei sowohl TinyTX3 als auch TinyTX4 geht der pin#6 vom ATtiny oben auf das 2.Lötauge von links welches mit einer 3 beschriftet ist, was für D3 steht. Dieser Pin wird im Sketch als txPin verwendet und muss also auf 3 gestellt sein...
    Das 3.Lötauge wäre aber D7 und somit müsste im Sketch txPin auf 7 gestellt werden.

    Stelle also bitte sicher das du das richtige Lötauge verwendest ;)

  • Ich meine schon das 2. Lötauge von links, beschriftet mit 3 und im Sketch mit #define txPin 3 eingestellt...

    Trotzdem komme ich nicht weiter, mir kommt das gerade irgendwie 'Spanisch' vor. Die Lötstellen habe ich überprüft, die sehen alle gut aus. Wie schon geschrieben habe ich Testweise auch den Receive Sketch aus deinem Sketchbook verwendet. Dort gibt es ja folgenden Block:

    Code
    char helpText1[] PROGMEM = 
        "\n"
        "Available commands:" "\n"
        "  <nn> gd     - Get Data from nodeID" "\n"
        "  <n> l      - turn activity LED on or off" "\n"
    ;

    Wenn ich Minicom starte und danach erst den Empfänger mit Strom versorge bekomme ich, sobald GND verkabelt ist die Ausgabe aus dem Code Block fortlaufend in Minicom ausgegeben. Wenn VCC dazu kommt bleibt die Ausgabe stehen. Daher gehe ich ersteinmal davon aus, dass die Kommunikation mit dem Pi richtig verkabelt ist.

    Jetzt habe ich eine LED am 4. Lötauge, beschriftet mit 8, und natürlich #define LEDpin 8 im Sketch. Ziehe ich das Kabel der LED von dem Pfostenstecker ab, dann fängt die Ausgabe wieder an zu laufen. Da kann ich mir echt keinen Reim drauf machen?!

    -------------------------------------------

    Update : Es lag an einem Fehler in meiner manuellen Zusammenstellung der Libraries und der Umstellung des Programmers auf einen Arduino Micro as ISP. Jetzt funktioniert alles wie erwartet :)

    Einmal editiert, zuletzt von doing (15. Januar 2015 um 15:04)

  • Eine Frage habe ich doch noch. Wenn ich die sensor.pl in der Konsole aufrufe bekommen ich haufenweise

    Code
    Use of uninitialized value $line in print at /mein_pfad/sensor.pl line 60.
    Use of uninitialized value $line in split at /mein_pfad/sensor.pl line 61.
    Use of uninitialized value $string in substitution (s///) at /mein_pfad/sensor.pl line 88.
    Use of uninitialized value $string in substitution (s///) at /mein_pfad/sensor.pl line 89.

    Werd ich das noch irgendwie los?

    Ansonsten funktioniert das Ganze bei mir jetzt auch :bravo2:

  • Kann es sein das bei dir in Zeile 59 nicht das steht: my $line = trim(<SERIAL>);

    Ansonsten sicherstellen das die Datei über nano erzeugt, oder zumindest unter Windows mit einem Linux kompatiblen Editor und dann richtig übertragen wurde

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!