Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Begonnen von trilu, 23 Februar 2014, 12:23:22

Vorheriges Thema - Nächstes Thema

vbs

Getestet hab ich das ja schon. Mit 10 ms wird es wie gesagt etwas besser, aber löst (zumindest bei mir) das Problem nicht. Selbst mit 3 Retries hab ich dann immer noch fehlgeschlagene Übertragungen. Selbst bei 30 ms schlagen ab und zu noch welche fehl. Ich habe jetzt seit ein paar Stunden mit 40 ms am Laufen und habe jetzt 3500 Nachrichten fehlerfrei übertragen.
Alle Tests eben inklusive der 3 Retries.

Übrigens denke ich, dass du momentan im nicht-Burst-Modus das Trägersignal bzw. Präambel gar nicht setzt (eben nur die Standard 4-Bit-Präambel, die immer kommt), da vor dem delay(1) der TX-Mode gar nicht gesetzt wird, oder?
Bei mir sieht das im Moment so aus. Also TX-Mode wird gesetzt und dann je nachdem ob Burst oder nicht, eine 360 bzw 40 ms Präambel gesendet:
cmdStrobe(CC1101_STX  );
if (burst) {
_delay_ms(360);
} else {
_delay_ms(40);
}

trilu

#601
vielleicht kenne ich mich mit dem cc1101 zu wenig aus, aber ich schalte nur den übertragungsmodus ein, eine präambel wird zu diesem zeitpunkt nicht gesendet.
ich komme aus dem IDLE und sende STX an den chip, d.h.
Frequency synthesizer is turned on, can optionally be calibrated, and then settles to the correct frequency. Transitional state. Typ. current consumption: 8.4 mA.

wenn ich dann was in den fifo rein schreibe, werden die preamble bytes gesendet, zumindest mein verständnis.
ich glaube viel eher, dein sendemodul oder dein empfänger haben ein frequenzproblem.
der synthesizer muss sich ja auf die richtige frequenz einpendeln - welche hardware nutzt du?

vbs

Zitat von: trilu am 05 Juli 2014, 19:03:43
vielleicht kenne ich mich mit dem cc1101 zu wenig aus, aber ich schalte nur den übertragungsmodus ein, eine präambel wird zu diesem zeitpunkt nicht gesendet.
ich komme aus dem IDLE und sende STX an den chip, d.h. wenn ich dann was in den fifo rein schreibe, werden die preamble bytes gesendet, zumindest mein verständnis.
Ich bin Anfänger, also kein Anspruch auf Richtigkeit  8) Aber meiner Meinung nach passiert folgendes, wenn man in den TX-Mode schaltet:

  • Wenn Daten im TX-FIFO sind, dann werde diese gesendet (vorangestellte wird die konfigurierte 4-Bit-Präambel)
  • Wenn keine Daten im TX-FIFO sind, dann sendet der Chip Präambeln bis Daten in den TX-FIFO geschrieben werden

Aus der CC1101-Doku:
ZitatWhen enabling
TX, the modulator will start transmitting the
preamble. When the programmed number of
preamble bytes has been transmitted, the
modulator will send the sync word and then
data from the TX FIFO if data is available. If
the TX FIFO is empty, the modulator will
continue to send preamble bytes until the first
byte is written to the TX FIFO.

Also im Moment läuft das in der Lib so (im Burst-Modus):

  • TX-Mode einschalten (da noch keine Daten im TX-FIFO sind, fängt der Chip an, Präambeln zu senden
  • 360 ms warten (Chip sendet weiter Präambeln)
  • Nutzdaten in den TX-FIFO schreiben, die sofort versendet werden
  • TX-Mode verlassen

Zitat von: trilu am 05 Juli 2014, 19:03:43
ich glaube viel eher, dein sendemodul oder dein empfänger haben ein frequenzproblem.
der synthesizer muss sich ja auf die richtige frequenz einpendeln - welche hardware nutzt du?
Durchaus möglich. Aber ich würde dann eigentlich erwarten, dass ich dann immer mal wieder Übertrangungsprobleme hätte, wenn da etwas mit den Frequenzen nicht stimmt, oder? Das Problem hätte ich doch nicht lösen können, indem ich eine längere Präambel sende? Ich würde dann immer mal wieder CRC-Fehler oder so erwarten.

Ich nutze den Außensensor von Dirk und einen HMLAN als Empfänger.
Gibt es denn jemanden, bei dem diese Kombination ohne Übertrangungsfehler (bzw. Erfolgsquote jenseits 90%) out-of-the-box funktioniert. Also Dirk sagte, dass er auch ab und zu Aussetzer hat. Ich weiss aber nicht, ob das bei ihm so schlimm ist wie bei mir.


Dirk

Zitat von: vbs am 05 Juli 2014, 19:56:46
Ich nutze den Außensensor von Dirk und einen HMLAN als Empfänger.
Gibt es denn jemanden, bei dem diese Kombination ohne Übertrangungsfehler (bzw. Erfolgsquote jenseits 90%) out-of-the-box funktioniert.
Ob Außen oder Innensensor sollte eigentlich egal sein. Bis auf die Sensorbeschaltung und die mechanischen Abmessungen sind die im Prinzip identisch.

Ich werde die Tage auch noch mal ein paar Versuche machen.
Bei meinem Sensor auf dem Balkon kamen in den letzten Stunden etwa 50-70 % der Messages an, wenn ich davon ausgehe dass diese etwa alle 2,5 - 3 Min. Gesendet werden.
Somit sollten bei 100% etwa 22 Nachrichten pro Stunde ankommen.

Allerdings habe ich hier noch kein Retry aktiviert.
Die Sensoren empfange ich aktuell mit der CCU und leite die per XML-RPC an FHEM weiter.

Gruß
Dirk

vbs

Ahh, hi Dirk! :)
Sehr interessant, 50-70% ist das, was ich normalerweise auch so habe im Urzustand. Falls du mal dazu kommen solltest, wäre es interessant, ob sich das bei dir auch so wesentlich verbessert, wenn du den Burst-Mode erzwingst beim Senden. Ich komme dann auf irgendwas nahe 100% (99,irgendwas). Also ohne Retry.
Aber ich weiss, dass du im Moment sehr busy bist... also wenn du das im Moment nicht hinkriegst, ist das natürlich verständlich...

frank

hallo vbs,
Zitat von: trilu am 05 Juli 2014, 19:03:43
vielleicht kenne ich mich mit dem cc1101 zu wenig aus, aber ich schalte nur den übertragungsmodus ein, eine präambel wird zu diesem zeitpunkt nicht gesendet.
ich komme aus dem IDLE und sende STX an den chip, d.h.
Frequency synthesizer is turned on, can optionally be calibrated, and then settles to the correct frequency. Transitional state. Typ. current consumption: 8.4 mA.

wenn ich dann was in den fifo rein schreibe, werden die preamble bytes gesendet, zumindest mein verständnis.
ich glaube viel eher, dein sendemodul oder dein empfänger haben ein frequenzproblem.
der synthesizer muss sich ja auf die richtige frequenz einpendeln - welche hardware nutzt du?
versuch doch mal an der stelle den synthesizer zu kalibrieren. 868,3 mhz oder etwas mehr. vielleicht ist die versorgungsspg für die funkmodule grenzwertig oder sie sind auf 868,0mhz voreingestellt. 
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

vbs

#606
Ok, habe mir mal die Frequenzen näher angesehen. Also die schlechte Nachricht zuerst: Meiner Meinung nach stimmt das (leider) erstmal alles so. Die Frequenz ist eingestellt auf 868,2998657 MHz. Beim Initialisieren wird einmal per Hand die Kalibration angestartet. Weiterhin wird die Option genutzt, die bei jedem Wechsel in den TX-Mode erneut eine Kalibration durchführt. Also meiner Meinung nach erstmal alles so, wie es sein sollte.

Aber: Ich hab mal etwas an der Frequenz rumgedreht und es stellte sich raus, dass wenn ich die Frequenz leicht absenke, dann verschwindet das Problem und es kommen ca. 99% der Nachrichten an!! Die Frequenz zu erhöhen hat jedoch den Fehler sofort noch weiter verstärkt. Da war auch bei kleinsten Erhöhungen praktisch keine Kommunikation mehr möglich.

Also ich hab jetzt die besten Ergebnisse mit einer Frequenz von 868,2895508 (anstatt 868,2998657) MHz. Bei 648 Übertragung gab es da 5 Retries. Das Beste: die anderen Änderungen (Senden einer längeren Präambel bei Nicht-Burst-Geräten) können damit scheinbar komplett entfallen. Benutze im Moment wieder den Original-Firmware Code nur mit der geänderten Frequenz. Wie es sein soll ;)

Also ich bin erstmal happy :D Erstmal großen Dank an alle Beteiligten (vor allem trillu und frank) für den Tipp mit der Frequenz!! ;)

Was ich allerdings nicht weiß ist, wie sehr die Frequenz zB beim HMLAN von Gerät zu Gerät schwankt. Nicht das ich jetzt mit dem Wert von 868,2895 MHz genau für mein Geräte optimiert habe und bei anderen machts das vielleicht schlimmer. :(

Im Anhang mal die gepatchte Firmware. Entspricht 1:1 dem aktuellen Master aber eben mit der genannten Frequenzänderung. Vielleicht mag das mal jemand testen. Interessant wäre, ob Leute, die vorher keine Probleme hatten, weiterhin keine Probleme haben und ob bei Leuten, die das Problem haben, es damit gelöst/besser wird. Ich werde natürlich auch noch etwas weiter testen...
Achso: Retries sind in der Firmware auf 3 eingestellt.

marc2

Hallo Dirk !

ZitatDie Tests sind bisher alle positiv verlaufen. Der Funk-Teil funktioniert wir in den vorhergegangenen 2 Versionen.
Auch der RS485-Teil funktioniert nun. Siehe hier:

Bedeutet das, dass man die RS485 Version jetzt bei Dir per PM ordern kann ?

Gruß, Marc

trilu

freut mich das es jetzt ohne burst so gut klappt. mir ist noch eine weitere idee eingefallen :-)

in der cc1101 init setze ich den funk auf volle power
   writeReg(CC1101_PATABLE, PA_MaxPower);                                    // configure PATABLE


vielleicht verändert das auch die frequenz oder es gibt interferenzen....

Dirk

@vbs.
Das sollten wir nochmal weiter beobachten.
Ich werde auch mal verschiedene Empfänger vergleichen.
CCU, HM-LAN, CUL
Und mir mit dem SRD mal ansehen auf welcher Frequenz da wirklich gesendet wird.

@Marc
Die Hardware für RS485 ist fertig, und ja, Ich kann dir so eine Platine fertig machen.
Die Firmware ist aber noch im Entstehen. Da ist Thorsten aktuell grade drann. Aktuell gibt es eine Firmware wo man an die Platine 1-Wire Temperatursensoren anschließen kann.
http://forum.fhem.de/index.php/topic,22952.msg176991.html#msg176991

Gruß
Dirk

marc2

Hi !

Zitat von: Dirk am 06 Juli 2014, 17:18:06
@Marc
Die Hardware für RS485 ist fertig, und ja, Ich kann dir so eine Platine fertig machen.

Wunderbar, Bestellung ist per PM raus  :)  Hat es eigentlich einen Grund, dass Du die
HM485 Module nach wie vor in einem eigenen GIT pflegst und nicht im normalen FHEM
Development Trunk ?

Gruß, Marc

Dirk

Zitat von: marc2 am 06 Juli 2014, 23:34:30
Hat es eigentlich einen Grund, dass Du die HM485 Module nach wie vor in einem eigenen GIT pflegst und nicht im normalen FHEM
Development Trunk ?
Eigentlich nur, weil die Module immer noch nicht ganz fertig sind.

marc2

Naja, das Modul, das ganz fertig ist, und an das nie wieder Hand angelegt werden muss, gibt es ja auch nicht  ;)

Gruß, Marc

vbs

Also bei mir läuft der Sensor nun mit der leicht abgesenkten Frequenz wie geschnitten Brot seit ein paar Tagen. Alle Nachrichten kommen an...

Mal ne Frage zu Innen-/Außensensor:
Welchen Vorteil hat eigentlich der Innen- ggü. dem Außensensor? Sensormäßig können die ja offensichtlich beide Lufdruck/Temperatur/Helligkeit und Luftfeuchtigkeit. Aber der Außensensor ist ja obendrein wasserdicht...

Dirk

Zitat von: vbs am 10 Juli 2014, 01:20:51
Also bei mir läuft der Sensor nun mit der leicht abgesenkten Frequenz wie geschnitten Brot seit ein paar Tagen. Alle Nachrichten kommen an...
Das klingt ja gut.
Dann kann ich das am WE ja in die Firmware mit einbauen.


ZitatWelchen Vorteil hat eigentlich der Innen- ggü. dem Außensensor? Sensormäßig können die ja offensichtlich beide Lufdruck/Temperatur/Helligkeit und Luftfeuchtigkeit. Aber der Außensensor ist ja obendrein wasserdicht...


  • Vom Design her würde ich mir den Inensensor auch an die Wand hängen.
  • Der Außensensor kann nur mit einem externen SHT10 auch Feuchte messen. Im abgedichteten Gehäuse währen Temperatur und Feuchte wohl nicht so interessant. Für Luftdruckmessung muss in das Gehäuse ein kleines Loch gebohrt, oder die Dichtung weggelassen werden.
  • Die Batterielaufzeit vom Innensensor ist länger, da AA- anstelle AAA-Zellen

Gruß
Dirk