LaCrosseGateway und BME680

[PeMue]

Batterie würde ich auch weglassen, LGW mit Batterie ist nix 

Stattdessen würde ich (falls machbar) ein Feld für die Firmwareversion mit einbauen ...

Gruß PeMue

[HCS]

Das wäre eine super Lösung finde ich 

Cool, schon zwei, die das so sehen

Hier mal ein Grobentwurf (angelehnt an LaCrosse und WS...) wie das HF-Protokoll für den "UniversalSensor" aussehen könnte:

Code Auswählen Erweitern

  US ID TT TT HH RR RR DD DD SS SS GG GG FF PP PP GA GA GA LU LU LU VV xx xx xx CR
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |------- CRC
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------- additional data
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ------------ additional data
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------------- additional data
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |------------------- Version*10       V3.5 == 35
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------------------- LUX              1er
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |------------------------- LUX              256er
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------------------------- LUX              65536er
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |------------------------------- GAS              1er
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------------------------------- GAS              256er
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |------------------------------------- GAS              65536er       
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------------------------------------- Pressure*10      1er       hPa
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |------------------------------------------- Pressure*10      256er     
  |  |  |  |  |  |  |  |  |  |  |  |  |  |---------------------------------------------- Flags            see below
  |  |  |  |  |  |  |  |  |  |  |  |  |------------------------------------------------- WindGust*10      1er       m/s
  |  |  |  |  |  |  |  |  |  |  |  |---------------------------------------------------- WindGust*10      256er     
  |  |  |  |  |  |  |  |  |  |  |------------------------------------------------------- WindSpeed*10     1er       m/s
  |  |  |  |  |  |  |  |  |  |---------------------------------------------------------- WindSpeed*10     256er     
  |  |  |  |  |  |  |  |  |------------------------------------------------------------- WindDirection*10 1er       0.0 ... 365.0 Degrees
  |  |  |  |  |  |  |  |---------------------------------------------------------------- WindDirection*10 256er     
  |  |  |  |  |  |  |------------------------------------------------------------------- Rain*10          1er       mm               
  |  |  |  |  |  |---------------------------------------------------------------------- Rain*10          256er     mm
  |  |  |  |  |------------------------------------------------------------------------- Humidity         plain     %
  |  |  |  |---------------------------------------------------------------------------- Temp*10+1000     1er       °C
  |  |  |------------------------------------------------------------------------------- Temp*10+1000     256er     °C
  |  |---------------------------------------------------------------------------------- Sensor ID        1 ... 255
  |------------------------------------------------------------------------------------- fix "US"

Missing values shall be set to 0xFF
Example: US 01 FF FF 57 FF FF ... 44(CRC) if only humidity is available


 
Flags: 128  64  32  16  8   4   2   1
        |   |   |
        |   |   |-- New battery
        |   |------ ERROR
        |---------- Low battery


[hdgucken]

Hallo HCS,

dein Entwurf gefällt mir gut, könnte man durchaus so machen 
Außerdem würde ich dadurch das Modul "CustomSensor" gar nicht mehr benötigen, cool 
Als "additional data" könntest Du noch IAQ mit rein nehmen, z.B. für meinen oder einen anderen BME680 Sensor.
Dann würde es mir an nichts fehlen 

Gruß Thomas

[HCS]

Außerdem würde ich dadurch das Modul "CustomSensor" gar nicht mehr benötigen, cool 

Das war der Plan.

Als "additional data" könntest Du noch IAQ mit rein nehmen, z.B. für meinen oder einen anderen BME680 Sensor.

Ich dachte GAS als universelles Reading für Sensoren, die so etwas liefern, das könnte CO2, IAQ, usw. sein.
Aber eventuell sollte ich GAS1 und GAS2 vorsehen, für Sensoren wie den CCS811, die zwei solche Werte liefern (eCO2 und TVOC)
Für Test-Daten wie z.B. den Widerstand des BME680 hatte ich dann "additional data" vorgesehen, wo man so was mitschicken kann.
Ich würde das gerne so universell (drum UniversalSensor) machen, wie möglich und es nicht genau auf einen BME680 ausrichten, der anders als andere Sensoren eine IAQ liefert.
Und vielleicht nehme ich doch eine Voltage mit rein, für Sensoren, die das liefern wollen. Da sollte ein Byte (voltage *10) reichen, was dann 0 ... 25,5V abdeckt?

[hdgucken]

Hallo HCS,

Ich dachte GAS als universelles Reading für Sensoren, die so etwas liefern, das könnte CO2, IAQ, usw. sein.
Aber eventuell sollte ich GAS1 und GAS2 vorsehen, für Sensoren wie den CCS811, die zwei solche Werte liefern (eCO2 und TVOC)
Für Test-Daten wie z.B. den Widerstand des BME680 hatte ich dann "additional data" vorgesehen, wo man so was mitschicken kann.
Ich würde das gerne so universell (drum UniversalSensor) machen, wie möglich und es nicht genau auf einen BME680 ausrichten, der anders als andere Sensoren eine IAQ liefert.
Und vielleicht nehme ich doch eine Voltage mit rein, für Sensoren, die das liefern wollen. Da sollte ein Byte (voltage *10) reichen, was dann 0 ... 25,5V abdeckt?

So gesehen, hast Du natürlich recht, wenn der Wertebereich von "GAS" so von 0 bis ungefähr 500 geht, ist das ok.
Werte bis 500000 (Ohm) müssen eigentlich nicht sein, dann sendet man das halt in kOhm, Spannung wäre auch völlig ok so 

Gruß Thomas

[HCS]

wenn der Wertebereich von "GAS" so von 0 bis ungefähr 500 geht, ist das ok.
Werte bis 500000 (Ohm) müssen eigentlich nicht sein, dann sendet man das halt in kOhm, Spannung wäre auch völlig ok so 

Der maximal übertragbare Wert für Gas wäre aktuell rund 16,7 Millionen.

[hdgucken]

Hallo HCS,

Der maximal übertragbare Wert für Gas wäre aktuell rund 16,7 Millionen.

Natürlich, wer lesen kann ... (1er, 256er, 65536er)
Also alles bestens, das Universalsensor Protokoll kann kommen 

Gruß Thomas

[HCS]

Also alles bestens, das Universalsensor Protokoll kann kommen 

Ja, wird kommen, bin dran.

[HCS]

Also alles bestens, das Universalsensor Protokoll kann kommen 

Und hier kommt es.

Anbei ein LaCrosseGateway V1.31, das den UniversalSensor kann und ein 36_LaCrosse.pm, das ihn auch kann.
Deinen BME680_cc_sensor habe ich auf UniversalSensor umgebaut (auch anbei), meine sonstigen kleinen Änderungen daran darfst Du natürlich auch ignorieren.

Alles im Prototyp-Stadium. Kannst ja mal ein wenig mit experimentieren. Wenn wir es rund haben, checke ich es offiziell ein.

Die peaks im Chart sind Pakte, die es auf der HF-Strecke so unglücklich gekippt hat, dass CRC wieder stimmt. Evtl. sollte ich zwei CRC einbauen, die unterschiedlich rechnen, um die Übertragung besser abzusichern.

[hdgucken]

Als erstes wünsche ich allen hier ein gesundes neues Jahr !!!

Hallo HCS,

hab gerade Deinen Beitrag gesehen und musste natürlich sofort mal reinschauen 
Super Arbeit ! Deine Änderungen sind klasse, endlich mal ein vernünftiges Sendarray 
Hatte auch kurz mit dem esp internal vcc probiert, geht aber wegen des Onboard Spannungsteilers
auf den NodeMCU's nicht so gut, hab das dann verworfen.

Die peaks im Chart sind Pakte, die es auf der HF-Strecke so unglücklich gekippt hat, dass CRC wieder stimmt. Evtl. sollte ich zwei CRC einbauen, die unterschiedlich rechnen, um die Übertragung besser abzusichern.

Das Problem mit den peaks hatte ich auch vereinzelt, es fehlten dann Daten und der Rest hat sich dadurch verschoben, gab viele crc Fehler im Log.
Hatte daraufhin mit dem SPI Takt für den RFM etwas experimentiert und siehe da, mit 400kHz sind die Spikes und crc Fehler weg !
Standardmäßig sollte der Takt bei 1 MHz liegen (laut ESP SPI Lib), hab ich jetzt aber noch nicht nachgemessen. Der RFM kann eigentlich 10 MHz, eigenartig.
Hab meine letzten Änderungen (Vcc Messung abwählbar und Anzeige der BSEC Version beim Start und SPI 400 kHz Takt) mit eingefügt,
das ganze mal übersetzt, keine Fehler. Ich teste dann nachher mal, falls ich dazu komme und berichte hier ...

Gruß Thomas

[HCS]

Das Problem mit den peaks hatte ich auch vereinzelt, es fehlten dann Daten und der Rest hat sich dadurch verschoben, gab viele crc Fehler im Log.
Hatte daraufhin mit dem SPI Takt für den RFM etwas experimentiert und siehe da, mit 400kHz sind die Spikes und crc Fehler weg !

Das ist ja interessant.
Ich hatte zu Beginn den BME680_cc_sensor auf einem NanoLGW laufen, da kam so gut wie nie ein Paket heil rüber, die waren fast immmer irgendwo defekt.
Beispiel (sinngemäß):
Geschickt: 1 2 3 4 5 6 7 8 9
Angekommen: 1 2 3 91 5 6 35 8 9

Ich hatte das dann erst mal auf die total unglückliche Antenneverlegung im NanoLGW geschoben und auf der Breadboard-Variante (die auch ein OLED drauf hat), war es dann deutlich besser.

Das muss ich gleich mal auf dem Nano mit 400kHz probieren.
Das würde ja bedeuten, dass das nicht auf der HF-Strecke kippt sonder auf dem Weg in den Sende-FiFo 

Ein gutes neues Jahr mit guter frischer Luft unter IAQ 100 an alle 

[HCS]

400kHz SPI hat die Situation auf dem NanoLGW nicht verbessert, es wollte einfach nicht vernünftig senden.
Dann ist mir eingefallen, dass ich früher schon mal ähnliche Problem beim RFM69 hatte und habe mal die Ramp-Up-Time länger gemacht (vom default 40 uS auf 1 ms verlängert), und siehe da, er sendet wunderbar.
Scheinbar ist der Einschaltstrom, wenn die PA hoch kommt, für den Spannungsregler zu heftig.

void RFMxx::InitializeLaCrosse() {
    /* 0x01 */ WriteReg(REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY);
    /* 0x02 */ WriteReg(REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00);
    /* 0x05 */ WriteReg(REG_FDEVMSB, RF_FDEVMSB_90000);
    /* 0x06 */ WriteReg(REG_FDEVLSB, RF_FDEVLSB_90000);
    /* 0x11 */ WriteReg(REG_PALEVEL, RF_PALEVEL_PA0_ON | RF_PALEVEL_PA1_OFF | RF_PALEVEL_PA2_OFF | RF_PALEVEL_OUTPUTPOWER_11111);
    /* 0x12 */ WriteReg(REG_PARAMP, RF_PARAMP_10);
    /* 0x13 */ WriteReg(REG_OCP, RF_OCP_OFF);
    /* 0x19 */ WriteReg(REG_RXBW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2);
    /* 0x28 */ WriteReg(REG_IRQFLAGS2, RF_IRQFLAGS2_FIFOOVERRUN);
    /* 0x29 */ WriteReg(REG_RSSITHRESH, 220);
    /* 0x2E */ WriteReg(REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0);
    /* 0x2F */ WriteReg(REG_SYNCVALUE1, 0x2D);
    /* 0x30 */ WriteReg(REG_SYNCVALUE2, 0xD4);
    /* 0x37 */ WriteReg(REG_PACKETCONFIG1, RF_PACKET1_CRCAUTOCLEAR_OFF);
    /* 0x38 */ WriteReg(REG_PAYLOADLENGTH, PAYLOADSIZE);
    /* 0x3C */ WriteReg(REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE);
    /* 0x3D */ WriteReg(REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF);
    /* 0x6F */ WriteReg(REG_TESTDAGC, RF_DAGC_IMPROVED_LOWBETA0);
  ClearFifo();
}

[hdgucken]

Hallo HCS,

400kHz SPI hat die Situation auf dem NanoLGW nicht verbessert, es wollte einfach nicht vernünftig senden.
Dann ist mir eingefallen, dass ich früher schon mal ähnliche Problem beim RFM69 hatte und habe mal die Ramp-Up-Time länger gemacht (vom default 40 uS auf 1 ms verlängert), und siehe da, er sendet wunderbar.
Scheinbar ist der Einschaltstrom, wenn die PA hoch kommt, für den Spannungsregler zu heftig.

Das ist ja mal ein genialer Einfall  , das teste ich mal, denke nämlich auch, das der RFM mit 1MHz SPI locker zurecht kommen müßte.
Den Test vom Universalsensor hab ich noch nicht gemacht, probiere erst mal das kurz 

[hdgucken]

Läuft seit ca. 40 Minuten, 1 mal crc Fehler, da waren aber alle Werte durcheinander, könnte ein eingefangenes Fragment von etwas anderem im Äther sein 
SPI Clock wieder ohne Begrenzung, PA_RAMP time 1ms.
Sonst sieht es gut aus, ich beobachte das mal ... 

[HCS]

CRC-Fheler können schon mal vorkommen, bei mir laufen genug 868-Sensoren, die da mal dazwischenhauen können.
Das Problem mit der urprünglichen Ramp war, dass das NanoLGW eigentlich so gut wie nie ein korrektes Paket ans Zile bekommen hat.

Ich hatte auch mal vor längerer Zeit mit mit einem rtl-sdr geschaut, was da eigentlich rauskommt und da war es so, dass kurz ein Signal kam und dann schlicht das Trägersignal abgesoffen ist.
Das passt auch zu meinem Test heute morgen, da habe ich einfach mal die Sendeleistung um 4dB runter genommen, da ging es dann auch.
Und als ich im Datenblatt das Register für die Sendeleitung nachgelesen habe, ist mir dann die Ramp-Time ins Auge gesprungen ...

Trotzdem überdenke ich das CRC nochmal, da kommt aktuell recht einfach ein Müll durch, bei dem es aufgeht.
Eventuell packe ich auch noch einen treshold rein, Dinge wie IAQ und Luftdruck ändern sich ja nur langsam.