Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

deimos
Beiträge: 3193
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 14 Mal
Danksagung erhalten: 83 Mal
Kontaktdaten:

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von deimos » 18.08.2018, 12:48

Hi,

ich dachte, dass der CC1101 ein Wake-On-Radio hat und die MCU dauerhaft schlafen kann und per Interrupt geweckt wird. Wenn ich den Code beim Überfliegen richtig gedeutet habe, wird dieser aktuell aber nicht verwendet. Weiß da jemand den Grund für, oder ist das einfach bisher nicht angegangen worden?

Viele Grüße
Alex

jp112sdl
Beiträge: 3759
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 69 Mal
Danksagung erhalten: 144 Mal
Kontaktdaten:

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von jp112sdl » 18.08.2018, 13:01

deimos hat geschrieben:
18.08.2018, 12:48
ich dachte, dass der CC1101 ein Wake-On-Radio hat und die MCU dauerhaft schlafen kann und per Interrupt geweckt wird.
Würde das jedoch nicht auch bedeuten, dass die MCU bei jedem Funkpaket geweckt werden würde?
Sonst könnte man sich ja die Burst-Geschichte sparen und auch Batterieaktoren mit Wake-on-radio laufen lassen.
Da ist Burst doch die energiesparendere Möglichkeit, oder?

VG,
Jérôme

jp112sdl
Beiträge: 3759
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 69 Mal
Danksagung erhalten: 144 Mal
Kontaktdaten:

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von jp112sdl » 18.08.2018, 14:05

Ich aktiviere "Wake On Radio" beim Temperaturdifferenzsensor (TDS).
Heißt für mich: Das Gerät kann geweckt werden.
Ändere ich Konfigurationsdaten und schicke diese ab, werden sie ohne Burst gesendet (was dann auch fehlschlägt).
Möchte ich die aktuelle Temperatur abfragen, erscheint

Code: Alles auswählen

<Error> HSSParameter::GetValue() id=TEMPERATURE failed getting physical value.
nachdem vom RFD auch keine Anfrage an das Geräte (weder mit noch ohne Burst) gesendet wurde.

Das Verhalten seitens der CCU (rfd-Log Level 0) ist immer dasselbe, egal ob WOR an oder aus ist.

Oder ist WOR nur für Direktverknüpfungen gedacht? Ich kann ja den TDS mit einem Heizkörperthermostat (HKT) peeren. Kann dann evtl. nur mit aktiviertem WOR das HKT die aktuelle Temperatur immer live beim TDS abrufen?

Anderes Beispiel: Heizkörperthermostat
Läuft es allein, ohne gepeerte TFK oder WT, ist WOR aus.
Wird Zubehör gepeert, wird WOR (zumindest bei Gruppenbildung) automatisch aktiviert - damit z.B. beim Öffnen des Fensters auch das HKT benachrichtigt wird.
Meines Wissens sendet der Fensterkontakt aber kein Bursttelegramm aus (um das HKT zu wecken).

Im RFD-Logging ist auch bei Datenpaketen zu sehen:
...BURST=0,WAKEUP=0,WAKEMEUP=0...
Öffne ich ein Fenster, sendet der TFK ein BURST=0,WAKEUP=0,WAKEMEUP=1 mit.
Das heißt, der WOR-Modus (am HKT) kommt ohne Burst aus!?

Warum nutzt man also nicht WOR am Batterieaktor?

Ich habe es noch immer nicht ganz verstanden.

VG,
Jérôme

deimos
Beiträge: 3193
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 14 Mal
Danksagung erhalten: 83 Mal
Kontaktdaten:

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von deimos » 18.08.2018, 14:39

Hi,

wir reden aneinander vorbei. Ich meine nicht WOR von der CCU oder Bidcos, sondern WOR innerhalb der Hardware vom CC1101.

Den Burst braucht man auch bei WOR im CC1101, wweil der intern nichts anderes macht, als der Code von AskSinPP. Aber der braucht massiv weniger Strom und die MCU kann in der Zeit weiterschlafen.

Ich hatte beim schnell drüberlesen den Eindruck, dass dieses Hardware WOR nicht genutzt wird, sondern das die BurstDetection das in Software nachbaut. Ich kann mich da aber auch komplett irren, weil es wirklich nur schnell drüberfliegen war. Und falls ich mich nicht irre, könnte es ja auch einen guten Grund dafür geben.

Viele Grüße
Alex

klassisch
Beiträge: 3496
Registriert: 24.03.2011, 04:32
Hat sich bedankt: 4 Mal
Danksagung erhalten: 9 Mal

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von klassisch » 18.08.2018, 15:53

Meine Spekulation zun dem Burst Thema: Der Burst ist nicht primär für den Prozessor da, sondern für den Empfänger. Empfangen ist "teuer", kostet Strom. Wäre der Empfänger immer hellwach, bräuchte es keinen burst, sondern nur eine normalkodiertes Signal, welches dann lediglich den Prozessor wecken müßte. Soviel Digitalelektronik geht in den Empfänger sicher rein. Der lange Burst macht nur Sinn, wenn der Empfänger den größten Teil der Zeit verschläft und nur ab und an (Delta-t < (t_burst + t_burstdetect)) aufwacht und reinhört. Wenn er dann den burst hört und als solchen detektiert, gehts in den 100% Mode.
Ich schaue jetzt mal ins Datenblatt vom C1101 umd meine Spekulation zu überprüfen und dann messe ich mal den Stromverbrauch eines HM-Moduls nach.

deimos
Beiträge: 3193
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Hat sich bedankt: 14 Mal
Danksagung erhalten: 83 Mal
Kontaktdaten:

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von deimos » 18.08.2018, 16:01

Hi,

deine Vermutung mit dem Burst ist richtig, siehe Datenblatt vom CC1101 Seite 53ff. Das ist auch eine Formel drin, wie lange der Burst sein muss, damit er als WOR sicher funktioniert.

Viele Grüße
Alex

klassisch
Beiträge: 3496
Registriert: 24.03.2011, 04:32
Hat sich bedankt: 4 Mal
Danksagung erhalten: 9 Mal

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von klassisch » 18.08.2018, 16:10

Ja, vielen Dank, bin auch gerade am chapter 19.5. auf S. 53 gelandet.
C1101 datasheet hat geschrieben: 19.5
Wake On Radio (WOR)
The optional Wake on Radio (WOR) functionality enables CC1101 to periodically
wake up from SLEEP and listen for incoming packets without MCU interaction
Jetzt schaue ich mal was so ein HM-Aktor an Ruhestrom braucht.

klassisch
Beiträge: 3496
Registriert: 24.03.2011, 04:32
Hat sich bedankt: 4 Mal
Danksagung erhalten: 9 Mal

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von klassisch » 18.08.2018, 16:26

ein HM-LC-Sw4-Ba-PCB liegt tatsächlich in der gleichen Größenordung. Schwankt ebenfalls, Spitzenwert bei 0.4mA, also vielleicht 0.1mA besser. Insgesamt enttäuschend schlecht.

jp112sdl
Beiträge: 3759
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 69 Mal
Danksagung erhalten: 144 Mal
Kontaktdaten:

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von jp112sdl » 18.08.2018, 17:17

@deimos: Dann hast du mich vorhin falsch verstanden.
Nun seid ihr ja jetzt schon ein Stück weiter.

Also momentan liegt die BurstDetection ja wie schon allseits festgestellt beim µC, wo zyklisch die Funktion detectBurst() aufgerufen wird:

Code: Alles auswählen

  bool detectBurst () {
    if( isIdle() == true ) {
      wakeup();
      // let radio some time to get carrier signal
      _delay_ms(3);
    }
    uint8_t state = spi.readReg(CC1101_PKTSTATUS, CC1101_STATUS);
    // DHEXLN(state);
    return (state & 0x01<<6) == (0x01<<6);
  }
 
Es war früher in der NewAskSin auch schon so implementiert.
Aber auch in der AskSin nicht anders gelöst.

Warum es grundsätzlich softwareseitig gemacht wird - keine Ahnung.
Könnte der GDO2 für Wake On Radio (also für den Aufwach-Interrupt) verwendet werden?
In einer früheren Version wohl auch mal GDO2 verwendet... https://wiki.fhem.de/wiki/HomeMatic_Asksin_Library:
TRX868-Pin 4 ist GDO2 und war anfangs mit Pin 3 des Arduino verbunden. GDO2 wird nicht mehr verwendet und Pin 3 (PWM) kann nun anderweitig genutzt werden.

VG,
Jérôme

papa
Beiträge: 376
Registriert: 22.05.2018, 10:23
Danksagung erhalten: 17 Mal

Re: Winziger Verbesserungswunsch vom HB-UNI-SenAct-4-4

Beitrag von papa » 18.08.2018, 17:37

Habe mich nicht mir Hardware WOR beschäftigt. Aber das CC1101 brauch auch ganz schön Leistung, wenn es an ist.
Das hier sieht auch ganz interessant aus http://www.ti.com/lit/an/swra126b/swra126b.pdf
Anfragen zur AskSin++ werden nur im Forum beantwortet

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“