Entwicklung: Temperatur Funk Sensor

Hätte da mal eine Frage an die Kollegen mit Durchblick,
ich würde gerne die Empfagsqualtät meines RX4 Boards verbessern. Dazu gibt es ja den Tipp den Sketch bei den Sendern und dem Empfänger anzupassen.
Kann man sonst noch was tun? OK vielleich eine bessere Antenne basteln, aber das meine ich nicht, sondern kann man am Board "hardwaremäßig" was verändern.
Mit den verdrillten Leitungen zum Raspi anstelle den RX direkt aufzustecken hat bei mir scheinbar nix gebracht.
Wäre es sinvoll unter dem RFM12BSP Modul Alupapier (natürlich mit Isolierband) zu plazieren? Will mir nicht die mühe des ablötens machen wenn das nicht sein muß .
Habt Ihr mit irgendetwas schon besondere Erfahrungen gemacht, sonst werde ich wohl tatsöchlich noch einen TX umfunktionieren müssen.

Gruß

Hallo nightflight,
ich habe sehr viel Zeit mit dem TinyRx4 Board verbracht... Das Problem dieses Boards ist dass das Layout HF-technisch betrachtet nicht ganz optimal ist. Da kann man leider nicht viel machen.
Auf der Software Seite kann man die Baud Rate auf 19200 Baud verringern, dabei muss man gleichzeitig die RX- Bandbreite auf 67 KHz verringern und den Frequenzhub von 90 kHz auf 45Khz verringern. Genau beschrieben ist das hier. Das bringt etwa 4dB mehr Empfindlichkeit zum Preis eines längeren Sende-Pulses. ich habe das egalisiert indem ich die Daten nicht als Text sondern binär sende.

4 dB mehr Empfindlichkeit sind zwar eine Marke aber jetzt nicht wirklich zufriedenstellend, weil man von gerade mal -89dBm auf -93dBm kommt. Das RFM12B Modul kann aber per se 10 dB besser.
Komischerweise ist das TinyTx4 Board HF-technisch ziemlich gut konstruiert (Zufall?). Ich habe daher mein TinyRx4 Board zu einem Sensor Node umgebaut und das frei gewordene TinyTx4 Board zum Empfänger gemacht (Booster ausbauen!). Damit kam ich unter optimalen Bedingungen auf ca. -105 dBm Empfindlichkeit.
Hier ein paar Tips:
1.) ich verwende einen Pi 1 Model B, dessen SoC erzeugt starkes hochfrequentes Rauschen. Das kann sowohl auf das Tiny Board selbst als auch in die Antenne eingestrahlt werden. Am einfachsten ist es das Tiny Board etwa 20 cm vom Pi entfernt zu betreiben, und den Pi auf den Kopf zu legen, also Unterseite nach oben. Ich weiss das ist bastel bastel, ärgert mich selbst aber ich hatte bisher keine Zeit eine echte Loesung zu erarbeiten.
2.) Alufolie: hab ich alles durchprobiert (mit Kupferfolie), beim TinyRx4 bringt das nichts. Da kann man echt nix machen.
3. Antenne absetzen. Entweder HF Kabel am Board direkt anloeten oder, wie ich das mache, eine SMA Buchse am TinyTX4 Board anbringen und eine Antenne mit Kabel daran anschliessen. Die besten Erfahrungen mache ich derzeit mit Dipol Antennen [Anzeige]. Alle anderen Typen von Antennen setzen eine hinreichend grosse Massefläche voraus, die in den allermeisten Fällen nicht vorhanden ist oder zumindest suboptimal sein dürfte. Wobei das TinyTx4 Board in dieser Hinsicht schon ziemlich gut funktioniert.
4.) Antenne von allem fern halten was strahlen koennte - Powerline Adapter, LCD TV, Pi, Notebooks...

BTW... arbeite z.Z. am RFM69W, angeschlossen an einem Pi Zero. Das RFM69W Modul meldet -111 dBm RSSI und empfängt Daten voellig problemlos. Der Pi Zero scheint auch nicht so sehr zu strahlen wie der Pi 1Model B. Aber Vorsicht, ich traue der RSSI Messung nicht wirklich.
Kennt jemand ein wirklich gutes Stück Software mit dem man den RFM69W optimal als Empfänger betreiben kann? Und das den RSSI zuverlässig genau misst?

Hi nurazur,
vielen Dank für Deine Ausführungen! Die Idee mit der Verwendung des Empfängers als Node ist super!
Ich hätte noch ein paar TinyTX3 Platinen über, da müsste ich den Step Up Regler nicht killen. Spricht aus Deiner Sicht
was gegen die Verwendung der "alten" TX3 Platine als Empfänger? Würde diesen dann mittels USB - UART an den RASPI
(habe auch noch den B1 im Einsatz) anschließen und bekomme so ausreichend Abstand. Als Antenne werde ich mir mal Deine Dipol - Empfehlung zulegen. Hinsichtlich des RFM69 habe ich keine Erfahrungen, weiß nur das es eine HW Version mit extremer Sendeleistung aber auch mit hoher Stromaufnahme gibt (also nix für die Sender). Im Bereich "mysensors" wird der gerne genommen, aber die setzen ja auf den Arduino mini pro und haben keine Sorgen mit Speicherplatz
Danke & Gruß

Zum TinyTx3 kann ich leider nichts sagen weil ich nie einen in der Hand gehabt habe. Immerhin führt die VCC Leitung für den ATtiny direkt unter dem RFM Modul entlang, aussen herum wäre besser (umd moeglich) gewesen. Aber einen Versuch ist es allemal wert.

zur Zeit beschäftige ich mich mit einer Weiterentwicklung der TinyTx Nodes.
Dazu habe ich folgende Fragen an die Gemeinde:

1. ich habe mich mit dem Booster befasst, habe eine Reihe von Messungen durchgeführt und kam zu dem Ergebnis, dass es - vom Energieverbrauch her - besser wäre den TinyTx mit 3V direkt zu speisen. Dabei soll die Batterie bis zu einer Spannung von ca. 2V ausgenutzt werden. Energetisch optimal betreibt man ATtiny, das RFM69 Modul und den Sensor bei 1.8V. Gibt es einen LDO oder DCDC Buck Konverter der im Stillstand nur einige µA verbraucht?

2. Das Datenblatt des ATtiny84 erlaubt bei 1.8 V nur 4MHz Takt. Kann man den internen Clock auf 4MHz einstellen, und wenn ja, wie? Im Arduino IDE sehe ich nur intern 8MHz oder 1 MHz.

3. Was passiert wenn ich die einschlägigen Sketches mit "intern 1MHz" kompiliere? Funktioniert das, und wenn nein warum nicht? Wir machen ja nichts zeitkritisches, sollte also funktionieren oder übersehe ich da was? (meine Erfahrung mit den AVR's ist leider etwas begrenzt).

4. Eine andere Sache die mich mit wachsender Anzahl von TX Nodes immer mehr nervt, ist dass ich viele Parameter eines individuellen Nodes im Sketch eintragen und dann kompilieren muss. Dazu zählen: NodeId, Watchdog Timer Delay, Vref Kalibrierung, AFC...
Ich denke man könnte solche individuellen Parameter in das EEPROM schreiben, nur brauche ich dazu eine Möglichkeit eine Kommunikation zwischen dem Raspi und dem TX Node zu etablieren. UART scheidet aus, der Treiber passt einfach nicht in den Speicher. Bleiben I2C oder HF (over the air). Bei I2C habe ich das Problem, dass ich für den Raspi keine Bibliothek finde bei der der Raspi als Slave arbeitet. Umgekehrt, eine I2C Bibliothek für den ATtiny die es erlaubt den ATtiny wahlweise als Master oder als Slave zu betreiben habe ich auch nicht gefunden. Hat jemand eine Idee?

Quote from meigrafd

Der Forumbewohner doing äußerte sich zum Beispiel erst kürzlich, das seine TinyX4 Module bereits seit 2 Jahren problemlos und sogar noch mit dem ersten Satz Batterien funktionieren würde

Um den (in diesem Fall TinyTX3) mal extrem zu stressen habe ich am 08.12.2014 einen in den Kühlschrank gesteckt. Der läuft (allerdings mit einem Pololu U1V11F3 StepUp Converter) bis heute mit dem ersten Satz Batterien (2x Varta 1,5 V AA)... :thumbs1:

Quote from nurazur

Ich denke man könnte solche individuellen Parameter in das EEPROM schreiben, nur brauche ich dazu eine Möglichkeit eine Kommunikation zwischen dem Raspi und dem TX Node zu etablieren. UART scheidet aus, der Treiber passt einfach nicht in den Speicher. Bleiben I2C oder HF (over the air).

Könntest Du die Parameter nicht per avrdude ins EEPROM schreiben? Oder muss es im laufenden Betrieb gehen?

Quote from elmicha

Könntest Du die Parameter nicht per avrdude ins EEPROM schreiben? Oder muss es im laufenden Betrieb gehen?

Kann ich natuerlich. Dazu muss ich aber erst die Parameter alle beieinander haben. Dazu brauche ich eine Kommunikation zwischen TX Node und Raspi.
Ich stelle mir das in etwa so vor:
TX node Start - sind gueltige Daten im EEPROM? - Nein, gehe zu Kalibrierroutine / Ja, gehe in Normalbetrieb.
Kalibrierroutine:
1. TX node misst VCC, bekommt vom Raspi mitgeteilt welche Spannung tatsaechlich anliegt und schreibt den Korrekturwert ins EEPROM. Damit misst der TX Node die VCC dann sehr genau.
2. Raspi sendet GATEWAYID und NODEID, TX node kopiert die Werte ins EEPROM.
3. TX node sendet was, Raspi empfaengt und wertet den FEI aus. Raspi sendet Korrekturwert zu TX node, der traegt den Wert ins EEPROM ein.
4. Watchdog -Intervall: Raspi sendet die gewuenschte Schlafzeit, TX node misst die Zeit zwischen Einschlafen und Aufwachen und traegt das daraus errechnete Intervall im EEPROM ein. Bei allen meinen Nodes zum Beispiel ist das Schlaf-Intervall ca. 9.1s (nicht 8), schwankt aber stark zwischen verschiedenen Nodes. Wenn ich alle 30 Minuten einen Wert senden moechte, muss ich den SENDDELAY Parameter individuell auf ca. 1592000 ms einstellen, nicht auf 1800000.

Quote from meigrafd

Damit sowas funktioniert muss beim TX ein RFM Module verbaut sein was sowohl Senden als auch Empfangen kann. Zumindest beim TX-Module gab es ja die Option ggf auch etwas billiger wegzukommen wenn man nur ein RFM02 verbaut...

Na ja, RFM02 ca. 3 EUR, RFM69CW ca. 2.50 EUR. Moechte ich ehrlich gesagt nicht mehr weiter vertiefen / verfolgen... Für mich wäre das RFM69CW Modul erst einmal die Referenz wenn es sich um eine echte Weiterentwicklung handeln soll. Das bedeutet auch dass man - wo notwendig - auch mal mit der Rückwärtskompatibilität brechen muss. Wobei ich hardwarseitig das RFM12B Modul immer noch toll finde und unterstützen moechte.

Quote from meigrafd

Zum ansprechen eines TX-Nodes muss zumindest ein Default NODEID gesetzt sein und das Teil muss im selben "Network" sein.

Das ist mir klar, habe mir darüber aber noch keine detailierten Gedanken gemacht. Ich denke an eine reservierte Node ID, z.B. 127.

Quote from meigrafd

Ich weiß nicht mehr wieso aber ich meine mich gaaanz dunkel daran zu erinnern das es 8 MHz sein mussten, mit 1 MHz funktionierte irgend etwas nicht, ob es stattdessen mit 4 MHz auch noch ginge weiß ich absolut nicht - sorry. Das müsste wenn dann irgendwo in den ersten 20-30 Seiten dieses Threads zu finden sein

Hab die ersten 15 Seiten durch, nix gefunden. Such morgen weiter. Leider hab ich dieses Projekt nicht von Anfang an verfolgt.

Quote from meigrafd

'orb' hatte mein ich auch mal vorgeschlagen eine 10µH Spule zu verbauen um die Spannung für Messungen zu glätten - aber selbst den Beitrag finde ich grad nicht :s

Den Beitrag hab ich gefunden, die 10µH Spule brauchts hier aber nicht. Ich kalibriere den Offset der tatsächlichen Referenzspannung des ATtiny's zur nominellen Referenzspannung von 1.1V. Mit der Kalibrierung ist die Vcc Messung auf < 1% genau. Das wird wichtig wenn man eine 3V Batterie bis auf 2V ausnutzen will.

Quote from nurazur

Kann man den internen Clock auf 4MHz einstellen, und wenn ja, wie? Im Arduino IDE sehe ich nur intern 8MHz oder 1 MHz.

Das Datenblatt sagt: ja!
Dann hab ich noch das da gefunden: https://harizanov.com/2012/06/runnin…nal-oscillator/
Anders als bei dem Autor der Seite hat der Code bei mir sofort kompiliert, komisch bleibt es trotzdem warum das 'Serial' Modul mit kompiliert werden muss obwohl es nicht verwendet wird.

Der TX node hat mit angeschlossenem HTU21D (I2C Bus) und RFM69CW auch sofort funktioniert, die VCC wird genau gemessen, aber die delay() Funktion braucht jetzt genau doppelt so lang. Kurze Inspektion des Tiny Cores, aber ich habe keinen Fehler gefunden. Ich denke aber dass die Arduino IDE das Problem ist. Beim Kompilieren wird , der -DF_CPU=8000000L Parametrer uebergeben, das heisst die ganze Bibliothek wird fuer 8MHz uebersetzt, dann erst wird F_CPU in meinem Sketch umdefiniert. Wie bekomme ich das jetzt gebacken??

Hab das mit den 4MHz hingefrickelt bekommen.
In Wahrheit ist der ATTinyCore nicht für Taktfrequenzen ungleich 16, 8 oder 1MHz gemacht.
Im Wesentlichen habe ich die Datei "boards.txt" bearbeitet und einen Menüpunkt "ATtiny84 @ 4 MHz (internal oscillator; BOD disabled)" hinzugefügt, alle Einstellungen aus der Abteilung 8MHz übernommen ausser der Taktfrequenz. Jetzt sieht man unter Tools/Micro den Menüpunkt "ATtiny84 @ 4 MHz" (siehe Bild). Kompiliert man den Code, wird die Option -DF_CPU=4000000L verwendet, es kommen aber eine Reihe von Kompilierfehlern weil im ATTinyCore der Fall "4MHz Takt" einfach nicht abgefangen wird. Ich hab mich da durchgewurstelt, aber mehr als eine quick-and-dirty Loesung ist das natürlich nicht. Und das Serial Modul funktioniert wahrscheinlich nicht bei 4MHz, macht in diesem Fall aber nix.
Wenn sich jemand meldet und genau wissen will was ich da gemacht habe, kann ich das gerne posten.

Der TX Node werkelt im Moment voellig problemlos, auch bei 1.8V. Wenn wach verbraucht der Node etwa 1mA weniger als mit 8MHz. Das ist nicht viel, aber mir kommt es ja darauf an den Node innerhalb der Spezifikationen mit 1.8V betreiben zu koennen.

OT:
Nachdem für mich der Arduino nur Mittel zum Zweck ist habe ich keine Lust am ATTinyCore herumzuprogrammieren, obwohl das bitter noetig wäre. Ich versteh einfach nicht warum das "Serial" Modul kompiliert werden muss obwohl es nicht benutzt wird und nichts, absolut nichts mit meinem TX Node zu tun hat.
Ich habe meine Kollegen immer gehasst wenn sie ewig lange Bloecke von ausführbarem Code in Header Dateien geschrieben haben. Das führt dann dazu dass man in Header Dateien andere Header braucht, und am Ende hat man - wie hier - ein unübersichtliches Durcheinander so dass man eigentlich immer das gesamte Projekt kompilieren muss auch wenn man nur an einer einzigen Datei gearbeitet hat.

Quote from nurazur

3. Was passiert wenn ich die einschlägigen Sketches mit "intern 1MHz" kompiliere? Funktioniert das, und wenn nein warum nicht? Wir machen ja nichts zeitkritisches, sollte also funktionieren oder übersehe ich da was? (meine Erfahrung mit den AVR's ist leider etwas begrenzt).

Tja, offensichtlich muss ich alle meine Fragen mit der Zeit selber beantworten, der Thread ist ja nicht mehr sehr frequentiert - verpasse ich da was?
Also, das mit dem 1MHz Takt funktioniert. Ich habe das derzeit nur mit meinem HTU21D Sketch probiert, aber es funktioniert problemlos mit RFM12B oder RFM69CW.
[Edit] Die RFM12B Module zicken bei 1 MHz, bei 4 MHz habe ich jetzt mehrere Nodes im Einsatz, bisher alles OK.

Die Taktfrequenz waehle ich jetzt im Arduino IDE aus, im setup() des Sketches steht folgender Code:

#if F_CPU == 4000000L
   // Change to 4 MHz by changing clock prescaler to 2
   cli(); // Disable interrupts
   CLKPR = (1<<CLKPCE); // Prescaler enable
   CLKPR = (1<<CLKPS0); // Clock division factor 2 (0001)
   sei(); // Enable interrupts
 #endif


 #if F_CPU == 1000000L
 // Change to 1 MHz by changing clock prescaler to 2 - this is required only when fuse settings are on 8MHz! comment out if fuses are set to 1MHz!
   cli(); // Disable interrupts
   CLKPR = (1<<CLKPCE); // Prescaler enable
   CLKPR = (1<<CLKPS0) | (1<<CLKPS1); // Clock division factor 3 (0011)
   sei(); // Enable interrupts
 #endif

Der 1MHz Node ist noch ueber einen laengeren Zeitraum zu testen. Bei einem habe ich den ATtiny84 auf 1MHz "gefused". Dann muss man den Code oben aber weglassen (also den Sketch so lassen wie er ist!), klar.
Das mit den Fuses war aber nur ein Test. Im Allgemeinen werde ich wohl die Fuses aller meiner Nodes mit 8MHz brennen, und den oben gezeigten Code in meine Sketches einbauen, dann mit IDE mit "1MHz" flashen.
Der 1MHz Takt ist dem 4MHz Takt vorzuziehen, der ATtiny braucht bei 1MHz etwa 1/3 des Stroms, der Burst ist nur ein paar Microsekunden laenger als bei 8MHz. Ausserdem braucht man nicht am ATtinyCore herumzuschrauben.

Ich bin jetzt bei ca. 0.5mAs pro Burst, das ist so gut dass eine CR2032 (ca 200mAh) locker 3 Jahre halten sollte (2 Messungen pro Stunde vorausgesetzt).

Hallo, hab mich vor langer Zeit mal hier Hilfe geholt, danke für die Antworten. Hatte einen Fehler in der Verkabelung.

Stand ist im Moment so: Sender und Empfänger blinkt die LED und ich kann Temperaturwerte über die serielle Schnittstelle des Raspi auslesen.

Wie geht es nun aber weiter. Leider habe ich keine Linux-Erfahrung und tue mich mit dem Raspi etwas schwer.

Habe es aber hinbekommen den Apache2 - Webserver zu installieren.

Wohin müssen nun aber die Scripte? Es ist da die Rede von DocumentRoot vom Apaches2. Welches Verzeichnis ist das?

Ach so, bin im Moment als Benutzer pi angemeldet, ist das ok?

Als OS ist Jessie drauf.

Mfg Flint

Hallo Flint,

warum stellst Du die Frage doppelt? in dem anderen Thread habe ich Dir geantwortet.

Beste Grüße

Andreas

Danke für die Info Andreas. Habe nur gedacht hier passte es im Kontext besser.

Sorry.

Hi, Habe jetzt soweit alles am laufen, bin dabei ein 3.5 Zoll-Display mit anzubinden.

Beim Ausführen des TouchTiny.py - Scriptes kommt leider eine Fehlermeldung:

File "./TouchTiny.py", line 8
import pygame, sys, os, time, string, sqlite3
^
IndentationError: unexpected indent

Kann mir da jemand helfen?

Danke

Quote from Flint

File "./TouchTiny.py", line 8
import pygame, sys, os, time, string, sqlite3
^
IndentationError: unexpected indent

Der Fehler besagt, dass die Einrückungen in deinem Source falsch sind. Geh mal in Zeile 8 und vergleich sie mit der nächsten Zeile darüber, die nicht mit einem # beginnt.