Arduino Asksin library

Begonnen von trilu, 06 August 2013, 10:02:17

Vorheriges Thema - Nächstes Thema

unimatrix

Hallo trilu,

danke für die Rückmeldungen. Das mit der Planung für den Batteriebetrieb klingt ganz gut. Wenn der ATMega zu klein ist, stört mich das weniger. Ich kann das Puppenhausboard auch neu machen. Wäre halt eine mal ganz andere lustige Anwendung dachte ich mir. Außerdem steht das bei uns an einer zentralen Stelle, ich könnte es auch als Fertigmelder für Waschmaschine/Trockner nehmen (also Licht blinken lassen), der MP3 Gong ist in einer anderen Etage verbaut...wäre jedenfalls eine lustige Sache für Besucher ein Puppenhaus zu haben, das blinkt, wenn der Trockner fertig ist *G*

Gibt es denn jetzt eine klare Referenzschaltung - die man sich selbst aufbauen muss?

VG

Dirk

Hi Horst,

Zitat
Ich möchte einen Mode für Batteriebetrieb implementieren der über den Watchdog läuft. Bei Nichtbenutzung gehen dann der Atmel und das Funkmodul in einen Tiefschlaf mit einigen uA. Wachen aber alle 300 ms wieder auf. Ziehen dann für einige ms etwa 20ma, wenn in der Zeit keine Übertragung rein kommt, dann wird weiter geschlafen.

Ich meine der CC110x kann den Atmega auch per Interrupt aufwecken wenn er eine bestimmte Bytesequenz empfängt. Und ich denke, das ist bei den fertigen HM-Geräten die mit Batterie laufen so implementiert.

Gruß
Dirk

Stefan M.

Hallo zusammen,

habt Ihr schon mal einen Test mit

1 Digitalen Eingang
1 Digitaler Ausgang
1 Analoger Eingang
1 Analoger Ausgang

gemacht. Was muss ich dabei beachten ?

lg
Stefan

FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

trilu

Hi Peter,

eine Message 40 sieht so aus :-)
-> 0B 11 A4 40 22 66 08 2F B7 4A 01 06 (l:12)(1951)

Remote_Event; cnl: 01, data: 06

S- 0A 11 80 02 2F B7 4A 22 66 08 00 (l:11)(1961)
<- sendStr (1988)

Wird von Fernbedienungen und Wandschaltern verschickt wenn das Device gepeert ist...

Mit Reset mach ich eigentlich nichts Anderes als den Watchdog starten. Vielleicht muss der erst irgendwie initialisiert werden. Ich schau mir das mal an.

Viele Grüße
Horst

trilu

Hi Dirk,

Zitat von: Dirk am 29 Oktober 2013, 12:55:17
Ich meine der CC110x kann den Atmega auch per Interrupt aufwecken wenn er eine bestimmte Bytesequenz empfängt. Und ich denke, das ist bei den fertigen HM-Geräten die mit Batterie laufen so implementiert.

ich glaube nicht das es HM so macht. Der CC1101 zieht etwa 17ma in Empfangsmodus und er muss was empfangen um einen Interrupt auszulösen.
Das was es im CC1101 noch gibt ist ein Wake on Radio. Den werde ich mir mal anschauen.
Ich vermute aber, da es diesen Burst Modus gibt - im Burst wird 350ms ein Signal übertragen - dass HM einfach nur den Watchdog vom Arduino zum schlafen verwendet und das Funkmodul alle 300ms aufwachen lässt.
Ich muss mir das aber noch einmal genauer anschauen...

Viele Grüße
Horst


Dirk

Zitat
Das was es im CC1101 noch gibt ist ein Wake on Radio. Den werde ich mir mal anschauen.
Der Burst wird gebraucht damit der CC1101 aufwacht. Erst wenn die  gesendete Bytefolge stimmt, wird der AVR geweckt.

Gruß
Dirk.

trilu

sehe ich so nicht!

wenn der cc1101 schläft, dann empfängt er auch keinen burst.
zumindest steht das so im datenblatt...
aber wenn du andere infos hast, dann her damit

The optional Wake on Radio (WOR)
functionality enables CC1101 to periodically
wake up from SLEEP and listen for incoming
packets without MCU interaction.
When the SWOR strobe command is sent on
the SPI interface, the CC1101 will go to the
SLEEP state when CSn is released. The RC
oscillator must be enabled before the SWOR
strobe can be used, as it is the clock source
for the WOR timer. The on-chip timer will set
CC1101 into IDLE state and then RX state. After
a programmable time in RX, the chip will go
back to the SLEEP state, unless a packet is
received. See Figure 28 and Section 19.7 for
details on how the timeout works.

shaddi

Ich bekomme beim compilen mit Arduino 1.0.1 folgende Fehlermeldung:


In file included from AskSin.cpp:7:0:
AskSin.h:298:39: error: variable 'cmdTab' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
AskSin.cpp: In member function 'void CC::init()':
AskSin.cpp:42:9: error: 'prog_uint8_t' does not name a type
AskSin.cpp:69:29: error: 'initVal' was not declared in this scope


Was mache ich falsch?

trilu

mhh, mir sagt die Fehlermeldung rein gar nichts.
Bei mir läuft das Kompilieren ohne Probleme - allerdings nutze ich Arduino 1.0.5
Versuch mal mit einer aktuelleren Version...

Dirk

Zitat von: trilu am 29 Oktober 2013, 16:07:14
The optional Wake on Radio (WOR) ...

wie du schon geschrieben hast. WakeOnRadio. Der CC1101 schläft bis er durch den burst geweckt wird. Prüft die ersten Bytes und weckt bei Übereinstimmung den AVR. Wenn ich wieder zu Hause bin schau ich mal nach.

Gruß
Dirk

Dirk

ZitatDer CC1101 schläft bis er durch den burst geweckt wird.
Das ist natürlich nur "bildlich" gemeint.

In Wirklichkeit wird der cc1101 im WOR nicht per Funk aufgewacht, sondern der wacht selbstständig z.B. alle 300ms auf um kurz zu lauschen ob Daten zu empfangen sind.
Daher muss der Sender dann auch einen Burst schicken, damit das Packet sicher in das Zeitraster passt.

Der CC1101 hat dafür so ein Feature namens Sync-Word-Check.
Zitat... On-chip  support  for  sync  word
detection, ...
The  sync  word is a 16 bit configurable field (can be repeated to get a 32 bit) that is automatically inserted at the  start  of  the  packet  by  the  modulator  in transmit  mode.
Der Burst wird also ein entsprechendes Syncword senden.

Wenn das Syncword stimmt, dann weckt der Chip den AVR über GDO0, GDO1 oder GDO2
ZitatCC1101 can be set up to signal the MCU that a packet  has been received by using the GDO pins.

Alles andere währ bei Batteriebetrieb auch "Energieverschwendung" Der AVR muss nur aktiv werden wenn es was zu tun gibt. Der bekommt schon die fertigen Daten und muss hier auch nix mehr decodieren. Der muss nur noch das Protokoll interpretieren.

Gruß
Dirk

PeterS

Hallo trilu

Die events aus dem s_jumpTable jumpTable[] werden bei mir nicht angesprungen.
Weder dein genanntes Beispiel noch die 0x70 Ereignisse meiner Temperatursensoren führen hier zu serial log ?!

PS: Meine Paired-ID steht noch komischerweise auf "Paired: 00 00 00" ? Wurde schon mehrfach gepaired.

Gruss Peter

trilu

Mhh, mach mal bitte einen eeprom dump, schalte das debuggen für AS ein und poste die pairing sequenz.
Ach ja, und drücke t und zeig das ergebnis...

trilu

ich habe mich die letzten zwei tage mal ein wenig mit der burst geschichte und dem strom sparen gespielt, aber irgendwie bekomme ich die register settings für das cc1101 nicht hin.
hat jemand zufällig einen bus pirate und kann mal den spi port von einem batterie betriebenen aktor belauschen?

was ich bis jetzt rausgefunden habe läuft die kommunikation wohl so ab:

der master schaltet um auf transmit, wenn das anzusprechende device keinen burst braucht, wird 10ms gewartet, wenn der receiver ein burst device ist, dann wird 360ms in diesem zustand gewartet.
auf der receiver seite wacht wohl das funkmodul alle 300ms für ein paar ms auf und lauscht ob auf der hm frequenz ein burst signal gesendet wird, wird eins erkannt dann bleibt das funkmodul wach, wenn nicht legt es sich wieder schlafen.

leider werde ich aus dem datenblatt nicht wirklich schlau und für "trial and error" fehlt mir das mess equipment.

viele grüße
horst

Dirk

Hi Horst.

ich habe zwar nur ein Logicanalyzer, aber ich meine die Software kann auch SPI decodieren. Ich schaue mir das mal an. Das wird aber erst Sonntag Abend.

Gruß
Dirk