JeeLink v3c/ESP8266 zur Einbindung von Davis Vantage

[Dippy98]

Meinst du bei der Bestellung? Da war es mehr Zufall. Aber ich denke wenn man bei Robin bestellt, kann man auch den Wunsch nach einem RFM69 äußern.

[pechnase]

Hallo,

ich habe mir einen JeeLink Nachbau zusammengelötet aus Arduino nano (China mit FTDI-Chip) + RFM69CW (Pollin) und wollte darauf die DAVIS Vantage Firmeware verwenden. Das funktioniert leider nicht.
Ich dachte erst, der JeeLink Nachbau funktioniert irgend wie nicht, aber nachdem ich die LaCrosse Firmeware geflasht habve läuft der JeeLink Nachbau tadellos und empfängt Signale von einem LaCrosse Außentemperaturfühler.

Mit der DavisVantage Firmeware wird noch nicht einmal der RF-Type ausgelesen. Sieht dann wie im beigefügten Screenshot aus. Ich habe schon mot dem Oszi gemessen und vermute, dass es am SPI Interface liegt, bzw. der PIN-Zuordnung.

Wenn ich das beim Überfliegen richtig gesehen habe, wird das SPI-Interface im LaCrosse Sketch anders angesteuert, als im DavisVantage-Sketch.

Hat schon jemand Erfahrung mit dem JeeLink Nachbau auf Basis nano + RFM69CW im Zusammenhang mit dem DV-Sketch. In der Diskussion weiter oben, wird doch auch ein nano verwendet.

Danke für einen Tip

Viele Grüße
Wolfgang

[Dippy98]

Hallo Wolfgang,

Also mein Arduino nano mit RFM69 und BMP180 läuft tadellos. Sowie der Lacrosse Sketch als auch der Vantage Sketch.

Viele Grüße
Christian

[habeIchVergessen]

LaCrosse unterstützt 2 RFM Chips. MOSI, MISO und SCK sind für jedes RFM-Modul gleich. Nur NSS/CS ist unterschiedlich.
Entspricht deine Aufbau dem u.g. Schema?

RFM              Nano Pin
NSS/CS        D10
MOSI             D11
MISO             D12
SCK              D13
DIO0             D2

Was steht in model vom JeeLink, wenn der LaCrosse-Sketch läuft?

[pechnase]

Hallo,

erst einmal Danke für die schnelle Antwort. Den Screenshot für den JeeLink mit LaCross Sketch habe ich beigefügt.

Den Davis Vantage Sketch habe ich selbst in der Arduino IDE compiliert und den hex-File dann über den RPI mit avrdude geflasht. Der Log sieht auch gut aus.
Wenn ich das richtig gesehen habe, erfolgt die Pin-Zuordnung zumindest für SPI_CS und IRQ in dem File Vantage.h (hier Ausschnitt):

Code Auswählen Erweitern


#ifndef VANTAGE_h
#define VANTAGE_h

#include <Arduino.h>            //assumes Arduino IDE v1.0 or greater

//#define _DEBUG 1 // enable debug per compile

// Davis specific
#define DAVIS_PACKET_LEN     10 // ISS has fixed packet lengths of eight bytes, including CRC and trailing repeater info
#define SPI_CS               10 // SS is the SPI slave select pin, for instance D10 on atmega328
#define RF69_IRQ_PIN          2 // INT0 on AVRs should be connected to DIO0 (ex on Atmega328 it's D2)
#define CSMA_LIMIT          -90 // upper RX signal sensitivity threshold in dBm for carrier sense access

#define RF69_MODE_SLEEP       0 // XTAL OFF
#define RF69_MODE_STANDBY     1 // XTAL ON
#define RF69_MODE_SYNTH       2 // PLL ON
#define RF69_MODE_RX          3 // RX MODE
#define RF69_MODE_TX          4 // TX MODE


Was mich gewundert hat war, dass der Wert für SPI_CS mit SS anstell der 10 vorbelegt war. Wie wurde der in dem 36_DavisVantage_v0.5.zip im Firmware-Verzeichnis enthaltene 36_DavisVantage.hex erzeugt?

Der Aufbau entspricht dem Schema, wie im Beitrag von habeichvergessen oben. Sonst würde aus meiner Sicht auch der LaCrosse Sketch nicht funktionieren.

Viele Grüße
Wolfgang

[pechnase]

Hallo,

ich habe jetzt noch etwas gemessen. Der LaCrosse Sketch verwendet wohl 'Software SPI', d.h. die SPI_CLK Impules usw. werden durch setzen der Ports mit low und high erzeugt. Eine SPI_CLK Periode beträgt ca. 12us.

Das DavisVantage Sketch verwendet 'Hardware SPI'. Zunächst habe ich mal die SPI Clock Frequenz auf SPI_CLOCK_DIV32 gesetzt. Leider finde ich in keinem Datenblatt die Spezifikation für die min. Clock Periode des RFM69.

Die SPI_CS Zustände im DavisVantage Sketch passen irgend wie nicht zu den Clock Impulsen. Normalerweise geht der SPI_CS kurz vor dem ersten SPI_CLK auf low und nachdem das Byte/Word gesendet wurde wieder auf high. Das kann ich so aber nicht messen.
Warum ist in RFMxx.cpp die Funktion RFMxx::select() und RFMxx::unselect() definiert, die aber nirgends aufgerufen wird?

Editiert: Oh, habe die Aufrufe von select() und unselect() doch gefunden

Irgend wie meine ich, hängt mein Problem mit dem SPI-Interface zusammen.

Viele Grüße
Wolfgang

[habeIchVergessen]

DIO0 ist auch verdrahtet? Kannst du ein Screenshot vom JeeLink posten? (ist erst interessant, wenn der RFM erkannt wurde!)

SS wird in pins_arduino.h (verschiedene Varianten unter hardware\arduino\avr\variants) definiert. Abhängig vom ausgewählten Board wird beim Compile automatisch der richtige GPIO gewählt. Welche Einstellungen verwendest du in der IDE? Welche Version der IDE?

Die DavisVantage.zip-Datei enthält die Sourcen, aus denen das hex-File generiert wurde.

[pechnase]

DIO0 ist auch verdrahtet. Habe zur Sicherheit auch einen Pull-up hinzugefügt.
Wenn Du mit Screenshot des JeeLink das Schaltbild gemeint hast, ist es beigefügt.

[pechnase]

Hallo,

ich habe den Fehler gefunden. In RFMxxx.cpp fehlt ein unselect(); gleich nach dem Umschalten des SPI_CS auf OUTPUT. Der SPI_CS Pin lag deshalb auf low beim ersten Aufruf von SPI.transfer() schon auf low.

Habe die Routine jetzt so abgeändert:

Code Auswählen Erweitern


  pinMode(SPI_CS, OUTPUT);
  pinMode(RF69_IRQ_PIN, INPUT);  //wkl: Zeile eingefügt
  unselect();                    //wkl: Zeile eingefügt
  SPI.setDataMode(SPI_MODE0);
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV64); //wkl: set to 64
  SPI.begin();


Ob schon alles geht und ich auch Daten von der Wetterstation empfangen kann weiß ich noch nicht ganz genau, aber da mache ich morgen weiter. Sieht aber glaube ich gar nicht schlecht aus, siehe Screenshot.

Danke für die Unterstützung.

VG Wolfgang

[habeIchVergessen]

so weit sieht es gut aus (Ausgabe FHEM).

bzgl. der Quellcode Änderung:
WriteReg ruft select auf und setzt damit CS auf LOW. Zwischen pinMode(SPI_CS, OUTPUT); und dem ersten WriteReg sind in beiden Sketches jeweils nur wenige Code-Zeilen. SPI schreibt lediglich einige Register in den Methoden vor begin.

ich habe v0.5 auf einem nano v3.3 (Atmel MEGA 328P) mit direkt angeschlossenen RFM69CW (ohne Widerstände) getestet.

[pechnase]

das Problem ist, dass vor dem WriteReg kein SPI_CS high in irgend einer Form erzeugt wird. WriteReg verwendet zunächst select() damit wird aber SPI_CS auf low gesetzt, wo es ja eigentlich initial schon ist. Es fehlt das initiale, eindeutige setzen von SPI_CS high, bevor ein WriteReg() aufgerufen wird. Das kann man, wie in meinem Beitrag oben, durch den Aufruf von unselect() oder durch digitalWrite(SPI_CS, HIGH); erzeugen

Code Auswählen Erweitern


  pinMode(SPI_CS, OUTPUT);
  pinMode(RF69_IRQ_PIN, INPUT);  //wkl: Zeile eingefügt
  digitalWrite(SPI_CS, HIGH);    //wkl: Zeile eingefügt
  SPI.setDataMode(SPI_MODE0);
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV64); //wkl: set to 64
  SPI.begin();


Bei mir läuft es auf einem nano 3.0 aber mit Widerständen, wie im Schaltbild gezeigt, um die Signalpegel in der Spezifikation des RFM69CW zu halten (Richtung nano -> RFM69CW). Hier im Forum findet man zwar viele Hinweise, dass ohne Widerstände gearbeitet wird, ist aber eindeutig außerhalb der Spezifikation. Wenigstens ein Längswiderstand zur Eingansstrombegrenzung sollte verwendet werden. Ein zusätzlicher Unterschied zwischen ohne und mit Widerständen ist aber die max. SPI_CLK Frequenz. Durch die Widerstände und die Eingangskapazität des RFM69CW entsteht ein Tiefpass, der die CLK Signale so 'verschleift', dass die Logikpegel außerhalb der Schwellen liegen und deshalb die SPI Übertragung nicht funktioniert. Ich habe zwar die Widersände schon auf 470Ohm/1kOhm reduziert, aber trotzdem ist SPI_CLOCK_DIV2 zu optimistisch. Ich denke an der Stelle ist eine niedrigere CLK-Frequenz vom Gesamttiming auch unkritisch. Im Moment verwendet ich SPI_CLOCK_DIV64. Wenn Du ohne WIderstände arbeitest, wird es mit SPI_CLOCK_DIV2 auch gehen. Bei SPI_CLOCK_DIV64 dauert die Übertragung von 16bit ca. 63usec mit SPI_CLK ca 250kHz.

[habeIchVergessen]

ergänzende UserReadings aktualisiert (5.7 Anpassungen)

[StefanStrobel]

Hallo,

ich würde den Sketch gerne für die Davis Wireless Leaf & Soil Moisture / Temperature Station erweitern. Bisher wird hier ja fest kodiert -1 weiter gegeben.
Die bisher fehlenden Details des Protokolls sind hier veröffentlich: https://github.com/cmatteri/CC1101-Weather-Receiver/wiki/Soil-Moisture-Station-Protocol
Allerdings sendet die Station nicht einfach nur einen Wert sondern beim Message Typ F gibt es weitere Unterwerte bzw. SubTypes (je bis zu 4 mal Soil Moisture, Temperature und Leaf Moisture).

Man bräuchte also passende Keys, die sich idealerweise ohne große Tabelle aus den im Protokoll gesendeten SubType und Port ergeben.
Wie wäre es mit 32 + 8*SubType+Port als Key?

Die gesendeten Werte sind auch nur roh gemessene Spannungen. Die Umrechnung in echte Temperatur / Feuchtigkeitswerte erfodert noch ein wenig Rechnen. Soll das in den Sketch oder eher in User-Readings?

Gruss
    Stefan

[habeIchVergessen]

Grundsätzlich habe ich kein Problem mit einer Erweiterung. Kannst du bitte die Rohdaten der betroffenen Daten posten, damit ich mir diese ansehen kann.

set jeelink raw 1p

[StefanStrobel]

Hallo,

anbei ein paar Rohdaten.

Ansatzweise habe ich mal folgendes in den Sketch eingefügt:

Code Auswählen Erweitern


byte subType;
byte port;

...

case VP2P_SOIL_LEAF:
  // https://github.com/cmatteri/CC1101-Weather-Receiver/wiki/Soil-Moisture-Station-Protocol
  subType = packet[1] & 0x03;
  port = (packet[1] >> 5) & 0x07;
  if (subType == 1) {
val = (packet[2] << 2) + (packet[4] >> 6);    // Soil Moisture
Serial.print((String)(32+port) + KEY_VALUE_DELIMITER + val + VALUE_DELIMITER);
val = (packet[3] << 2) + (packet[5] >> 6);    // Soil Temp
Serial.print((String)(36+port) + KEY_VALUE_DELIMITER + val + VALUE_DELIMITER);
  } else {
        val = -1;
Serial.print((String)(40+port) + KEY_VALUE_DELIMITER + val + VALUE_DELIMITER);
  }
  break;


Da fehlt das Dictionary handling etc. und ob die Werte tatsächlich korrekt sind ist auch noch nicht klar.
Ich habe mal testweise versucht das Dictionary sinngemäß zu erweitern, allerdings gab es dann bei 12 weiteren Einträge seltsame Effekte: SendDictionary hat nur noch einen Teil der Einträge ausgegeben und ich befürchte dass das daran liegt dass der Variablenspeicher meines Jeelink übergelaufen ist. Ähnliche Probleme hatte ich mal bei der Entwicklung von ArduCounter.

Gruss
    Stefan