AskSin++ Library

[papa]

Funktioniert ohne den Hack leider nicht. Wieder AES Pendingmeldungen, die man per Configbuttondrücken für 20 Sekunden lösen kann.

Kannst Du bitte nochmal die Debug-Messages aufzeichnen. Und dabei bitte noch das "response.dump()" in waitResponse mit reinnehmen.

[CitationJet]

Code Auswählen Erweitern

2017.02.04 18:12:45.562 4: TSCUL_Parse: rf_nanocul_868  336109 A FF01 08421540 00 0B 01 A040 789012 42F0FF 0100 -47.5
2017.02.04 18:12:45.578 4: TSCUL_send:  rf_nanocul_868                         As 11 01 A002 42F0FF 789012 0470B4484E016902
2017.02.04 18:12:45.699 4: TSCUL_Parse: rf_nanocul_868  336248 A FF03 08421660 01 11 01 A002 42F0FF 789012 04 _CCAdly:4 -138
2017.02.04 18:12:45.935 4: TSCUL_Parse: rf_nanocul_868  336483 A FF03 08421896 01 11 01 A002 42F0FF 789012 04 _CCAdly:4 -138
2017.02.04 18:12:46.171 4: TSCUL_Parse: rf_nanocul_868  336719 A FF03 08422132 01 11 01 A002 42F0FF 789012 04 _CCAdly:4 -138
2017.02.04 18:12:46.375 1: TSCUL_ParseTsHM rf_nanocul_868 HM repeat failed sending to 789012/HM_789012: AFF0002A020F7001101A00242F0FF78901204
2017.02.04 18:12:46.376 4: TSCUL_Parse: rf_nanocul_868  336923 A FF00 08422364 00 11 01 A002 42F0FF 789012 04 _sfail -138


Code Auswählen Erweitern

AskSin++ V0.3.0
CC init12................................3 - ready
01 debounce
01 pressed
01 released
<- 0B 01 A0 40 78 90 12 42 F0 FF 01 00
11 01 A0 02 42 F0 FF 78 90 12 04 70 B4 48 4E 01 69 02
Process Challenge - Key: 02
<- 19 01 80 03 78 90 12 42 F0 FF 2F BD 59 C4 3F 5E 67 E3 7A 4C 6D F0 EB 18 3B C8
waitAck: 01
01
Key ist immernoch 01:11111111111111111111111111111111

[papa]

Und jetzt ? Hab noch ne kleine Anpassung gemacht.

[CitationJet]

Bingo - funktioniert einwandfrei. Vielen Dank!

[papa]

Sehr schön. Aber warum der TS_CUL einen Fehler signalisiert, wenn ich das letzte Ack nicht empfange, verstehe ich noch nicht ganz. Eine Antwort kriegt er darauf auf jeden Fall nicht. Egal - jetzt geht es ja.

[CitationJet]

Also jetzt wo es funktioniert sieht das TSCUL-Log so aus:

Code Auswählen Erweitern

2017.02.05 18:45:57.159 4: TSCUL_Parse: rf_nanocul_868  123034 A FF01 12976332 00 0B 0D A040 789012 42F0FF 0100 -53.5
2017.02.05 18:45:57.173 4: TSCUL_send:  rf_nanocul_868                         As 11 0D A002 42F0FF 789012 04B5021BED386302
2017.02.05 18:45:57.174 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:91 toms:33
2017.02.05 18:45:57.311 4: TSCUL_Parse: rf_nanocul_868  123187 A FF03 12976452 01 11 0D A002 42F0FF 789012 04 _CCAdly:4 _dhmSt:120 -138
2017.02.05 18:45:57.366 4: TSCUL_Parse: rf_nanocul_868  123234 A FF01 12976532 00 19 0D A003 789012 42F0FF 99A8464A39105F13291D612EA51F956F -52.5
2017.02.05 18:45:57.386 4: TSCUL_send:  rf_nanocul_868                         As 0E 0D 8002 42F0FF 789012 0047e6f2f0
2017.02.05 18:45:57.387 3: TSCUL_XmitDlyHM:  rf_nanocul_868  id:789012 dDly:78 toms:33
2017.02.05 18:45:57.505 4: TSCUL_Parse: rf_nanocul_868  123381 A FF03 12976652 01 0E 0D 8002 42F0FF 789012 00 _CCAdly:4 _dhmSt:120 -138

Er scheint also im letzten Schritt noch eine Nachricht zu bekommen, die ihm vorher gefehlt hat.

[plombe]

Folgender Testaufbau:
Arduino Pro Mini 8MHz 3,3V mit CC1101
HM-WDS10-TH-O  Testmesswerte alle 60 Sekunden.
Stromaufnahme im Sleep Modus  in den ersten  8 Sekunden 4,65µA, dann beim nächsten Durchlauf der Schleife 1,73 mA.
Das wechselte so bis die Zeit abgelaufen war.

Der Grund liegt in Radio.cpp. Hier die Lösung:

Code Auswählen Erweitern


void    CC1101::setIdle() { // put CC1101 into power-down state
// strobe(CC1101_SIDLE); // coming from RX state, we need to enter the IDLE state first
// strobe(CC1101_SFRX);
        uint8_t cnt = 0xff;
        while(cnt-- && (strobe( CC1101_SIDLE ) & 0x70) != 0) _delay_us(10);
strobe(CC1101_SPWD); // enter power down state
//dbg << "pd\n";
}

Code Auswählen Erweitern

uint8_t CC1101::strobe(uint8_t cmd) { // send command strobe to the CC1101 IC via SPI
ccSelect(); // select CC1101
waitMiso(); // wait until MISO goes low
//        ccSendByte(cmd); // send strobe command
uint8_t ret = ccSendByte(cmd); // send strobe command
  ccDeselect(); // deselect CC1101
        return ret;
}

In Radio.h

Code Auswählen Erweitern


//void    strobe(uint8_t cmd);                              // send command strobe to the CC1101 IC via SPI
uint8_t    strobe(uint8_t cmd);                              // send command strobe to the CC1101 IC via SPI



Die Lösung ist aus culfw.
Ich hoffe, damit Anderen langes Suchen zu ersparen.

Hans-Georg

[papa]

Danke - werde ich einbauen.

[plombe]

Der Watchdog Timer im Tiefschlaf des Arduino's  ist bekannlich nicht so genau. Im Nachbau des Universalsensors von Dirk nutze ich eine Möglichkeit, die Genauigkeit der Zeitmessung  zu verbessern. Damit ergibt sich auch im Tiefschlaf eine Genauigkeit, die annähernd der des Timer1 entspricht, und zwar unabhängig von Temperatur und Versorgungsspannung.
Einschränkung: Interrupt durch Tastendruck.
Um diese Verbesserung nutzen zu können, muß in der Datei Activity.h folgendes geändert werden:

Code Auswählen Erweitern

//      LowPower.powerDown(SLEEP_8S,ADC_OFF,BOD_OFF);
      LowPower.delay(8000);
........
//      LowPower.powerDown(SLEEP_1S,ADC_OFF,BOD_OFF);
      LowPower.delay(1000);


Die angehängte Datei statt der Low-Power Bibliothek benutzen.
Viel Erfolg beim Ausprobieren.
Hans-Georg

[Linef]

Stromaufnahme im Sleep Modus  in den ersten  8 Sekunden 4,65µA, dann beim nächsten Durchlauf der Schleife 1,73 mA.
Das wechselte so bis die Zeit abgelaufen war.

Ja, das grundsätzliche Problem ist aber, daß durch eine ungünstige Konstellation ein bereits im Idle-Mode befindlicher CC1101 nochmals in Idle geschickt wird. Dabei wacht er dann aber auf - bekommt aber nicht mehr mit, daß jetzt doch wieder ein Idle-Command kommt und bleibt deshalb eine Periode lang wach.
Der Fehler liegt in der alten AskSin-Lib (fehlerhafte Auswertung des CC1101-Status sowie ungünstige Abarbeitungsreihenfolgen, die letztendlich zu dem Verhalten führen)

Code Auswählen Erweitern


void    CC1101::setIdle() { // put CC1101 into power-down state
// strobe(CC1101_SIDLE); // coming from RX state, we need to enter the IDLE state first
// strobe(CC1101_SFRX);
        uint8_t cnt = 0xff;
        while(cnt-- && (strobe( CC1101_SIDLE ) & 0x70) != 0) _delay_us(10);
strobe(CC1101_SPWD); // enter power down state
//dbg << "pd\n";
}

Der Code dürfte ebenfalls zum Aufwecken des CC1101 führen, legt ihn dann aber gleich wieder erfolgreich schlafen - trotzdem unnötiges Aufwecken.
Günstiger ist ein Wrapper um setIdle, der dafür sorgt, daß ein schlafender CC1101 erst gar nicht schlafen gelegt wird (und damit zunächst aufwacht).
In den aktuellen Lib-Versionen sind die Bugs behoben.

Martin

[plombe]

Hallo,

@Linef: Ganz so wie du schreibst, ist es nicht. Um den Fehler zu finden, hatte ich HM-WDS10-TH-O.ino so abgeändert, daß in loop() nur stand:

Code Auswählen Erweitern

  radio.setIdle
_delay_ms(8000);
radio.wakeup;
Den Interrupt hatte ich abgeschaltet. Da konnte ich eine Stromaufnahme von 5,7mA und 4,0 mA im Wechsel messen. Ebenso etwa 4mA ohne CC1101.
Da lag es nahe, daß die 1,7mA entsprechend Datenblatt

1.6 mA Only voltage regulator to digital part and crystal oscillator running (IDLE state)

vom fehlerhaften Power down Status kamen.  Andere Einflüsse waren da meines Wissens ausgeschlossen.
Wenn CSn auf Low geht, ist es natürlich klar, daß power-down mode beendet wird.
H-G.

[Linef]

Code Auswählen Erweitern

  radio.setIdle
_delay_ms(8000);
radio.wakeup;

Hatte der wakeup auch gewartet, bis der Chip wieder komplett oben und für neue Kommandos bereit war?
(Im Wettersensor-Code von Dirk scheint mir nicht entsprechend gewartet zu werden)
Ansonsten läuft der unmittelbar in der Loop folgende setIdle ins Leere und wir haben den alternierenden Effekt...

Im Code von papa ist der Wrapper schon drin - dort sollte der Fehler also nicht mehr auftreten.

Martin

[papa]

Im Code von papa ist der Wrapper schon drin - dort sollte der Fehler also nicht mehr auftreten.

Die derzeitige Implementierung schickt den CC1101 schlafen und weckt ihn nach dem Watchdog sofort wieder auf. Wenn dann aber nicht passiert ist, geht es sofort wieder in den Idle. Ich wollte das mal so ändern, dass das Wakeup erst erfolgt, wenn wirklich was gesendet oder empfangen werden soll.

[papa]

Der Watchdog Timer im Tiefschlaf des Arduino's  ist bekannlich nicht so genau. Im Nachbau des Universalsensors von Dirk nutze ich eine Möglichkeit, die Genauigkeit der Zeitmessung  zu verbessern. Damit ergibt sich auch im Tiefschlaf eine Genauigkeit, die annähernd der des Timer1 entspricht, und zwar unabhängig von Temperatur und Versorgungsspannung.
Einschränkung: Interrupt durch Tastendruck.
Um diese Verbesserung nutzen zu können, muß in der Datei Activity.h folgendes geändert werden:

Code Auswählen Erweitern

//      LowPower.powerDown(SLEEP_8S,ADC_OFF,BOD_OFF);
      LowPower.delay(8000);
........
//      LowPower.powerDown(SLEEP_1S,ADC_OFF,BOD_OFF);
      LowPower.delay(1000);


Die angehängte Datei statt der Low-Power Bibliothek benutzen.
Viel Erfolg beim Ausprobieren.

Um das Power-Down-Verhalten zu beeinflussen, kann einfach die Sleep-Klasse überladen und dann als Template-Parameter in activity.savePower() übergeben werden.

Für exakte Timer plane ich noch die Unterstützung eines 32kHz Quarz am Timer2. Damit kann man dann auf die ganzen Tricks verzichten und den Power-Save Mode verwenden. Die 32kHz Quarze liegen hier schon in der Bastelkiste.

[Linef]

Für exakte Timer plane ich noch die Unterstützung eines 32kHz Quarz am Timer2. Damit kann man dann auf die ganzen Tricks verzichten und den Power-Save Mode verwenden. Die 32kHz Quarze liegen hier schon in der Bastelkiste.

Wegen des Powersave-Modus habe ich meine letzten 2 Sensoren auch mit 32KHz-Quarzen aufgebaut. Funktioniert prima.
Es war nur einiges an Rechnerei, einen einigermaßen 1ms-Timer hinzubekommen, da eine Frequenz von 1 KHz durch Teilung aus 32.768Hz nicht hinzubekommen ist. Durch einen Korrekturzähler geht's dann aber, so daß man nie mehr als 1ms "daneben" ist. Und alle 125 Sek. geht's dann sogar wieder glatt auf, so daß man über lange Zeit gesehen dann doch wieder Quarzgenauigkeit hat.

Martin