AskSin++ Library

[papa]

Kannst Du mal Seine RSSI Werte mit ausgeben.

[Xent]

Hab ich jetzt mal eingebaut.
Der Empfang funktioniert so eigentlich.
Nur war der CC1101 gerade auf einmal im Idle-State.
Hatte aber auch was an den RX-Timeout Registern geändert.

EDIT:
Der RSSI bei den aktuellen Paketen ist 0x5D

[papa]

Hm - das sind ja -93 - das ist aber schon arg schlecht.

[Xent]

Vielleicht hab ich die Antenne doch nicht richtig wieder angelötet.
Leider ist mir der Lötpin mit Leiterbahn abgebrochen ...

Hab nochmal was CC1101_MCSM1 geändert, so dass auch bei RXOFF_MODE im RX bleibt und nicht in den IDLE geht.

EDIT:
Kann es sein, dass die Umrechnung in dbm bei dir fehlerhaft ist?

Code Auswählen Erweitern

rss = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI
        if (rss >= 128) rss = 255 - rss;
rss /= 2; rss += 72;

Habe sie jetzt umgebaut in:

Code Auswählen Erweitern

int8_t rssi = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI

        if (rssi >= 128) {
rssi = (rssi - 256) / 2 -74;
}
else {
rssi = rssi / 2 -74;
}

rss = rssi * (-1);

DPRINT("RSSI: -");DPRINTLN(rss);

So bekomme ich jetzt auf -48 dbm bei Paketen von meiner Zentrale.

[Xent]

Hab jetzt nochmal was umgebaut.
Der Cul-a prüft quasi bei jedem "read" ob der GD0 high ist, wenn ja, wird gelesen, wenn nein, wird der Status geprüft und wieder auf RX gesetzt wenn dem nicht so ist.
Dies habe ich nun auch so eingebaut, ich bin jetzt erstmal ziehmlich zuverlässig, dass es so funktioniert.


Es gibt ja noch das Timingproblem ...
Dem bin ich glaub ich auch auf der Spur.
Habe dazu beim Trigger für GD0 auch mal die Zeitausgabe eingebaut:

Code Auswählen Erweitern

* - 3974
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 3976
* - 4252
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4478
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4508
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4512
* - 4535
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4604
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4609

Wenn man das ganze aufschlüsselt komme ich auf folgenden Ablauf:

1. Paket kommt rein

Code Auswählen Erweitern

* - 3974
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 3976

2. Antwort dauert zu lange, CCU sendet Befehl erneut

Code Auswählen Erweitern

* - 4252

3. Aktor Antwortet auf den ersten Befehl (Dauer 500ms)

Code Auswählen Erweitern

<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4478

4. Aktor liest Paket von 2.

Code Auswählen Erweitern

-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4508

5. Aktor sendet Antwort (Dauer 260 ms)

Code Auswählen Erweitern

<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4512

6. CCU sendet nochmal den Befehl und diesmal klappt die Kommunikation (Dauer 74ms)

Code Auswählen Erweitern

* - 4535
-> 0E 1F A0 11 473071 FE3456 02 01 C8 00 00  - 4604
<- 0E 1F 80 02 FE3456 473071 01 01 C8 00 31  - 4609

Ist nur die Frage, warum dauert der Empfang bzw. die Verarbeitung und Antwort beim ersten mal so lange ...

[papa]

Kann es sein, dass die Umrechnung in dbm bei dir fehlerhaft ist?

Das kann schon sein, habe das eigentlich nur einfach übernommen. Aber Dein Code hat auch ein entscheidenes Problem:

Code Auswählen Erweitern


int8_t rssi = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI
if (rssi >= 128) {
  .....


kann niemals wahr werden, da rssi als "8bit signed" deklariert ist und somit maximal den Wert 127 annehmen kann.

Ich habe aber noch eine andere Idee wegen des Empfang-Problems. Könntest Du einfach mal den Power-Save-Mode deaktivieren. Dazu einfach mal die loop() Funktion den If-Block rausnehmen:

Code Auswählen Erweitern


void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
//  if( worked == false && poll == false ) {
//    hal.activity.savePower<Idle<>>(hal);
//  }
}


Vielleicht suchen wir ja auch an der falschen Stelle.

[papa]

Ist nur die Frage, warum dauert der Empfang bzw. die Verarbeitung und Antwort beim ersten mal so lange ...

Kann ich dir sagen - Deine switchState-Implementierung hat wartet 250 ms.

Code Auswählen Erweitern


  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
    uint8_t pin = SwitchPin(BaseChannel::number());

    if(BaseChannel::number() == 1) {
      if( newstate == AS_CM_JT_ON ) {
         PORTC &= ~B00000011;
         PORTD |= B11000000;
         delay(250);
         PORTD &= ~B11000000;
      }
.......


Du solltest hier einen Alarm nutzen, der zeitverzögert wieder abschaltet.

Code Auswählen Erweitern


class PortDOffAlarm : public Alarm {
public:
  PortDOffAlarm () : Alarm(0) { async(true); }
  virtual void trigger (AlarmClock& clock) {
    PORTD &= ~B11000000;
  }
}


Und dann im SwitchChannel

Code Auswählen Erweitern


  PortDOffAlarm dalarm;

  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
    uint8_t pin = SwitchPin(BaseChannel::number());

    if(BaseChannel::number() == 1) {
      if( newstate == AS_CM_JT_ON ) {
         PORTC &= ~B00000011;
         PORTD |= B11000000;
         dalarm.set(millis2ticks(250));
         sysclock.add(dalarm);
      }
.......


Da Du nur ein Register änders, kannst Du den Alarm ruhig "async" machen - sprich er wird direkt im TimerInterrupt ausgeführt.

[Xent]

Ach jau, war wohl schon etwas zu spät gestern abend xD
Hab jetzt nen int16 draus gemacht.
Habe mir aber zum überprüfen der Rechenwege den ausgelesenen Wert vor der Umwandlung ausgeben lassen.
Da kam der nicht über 128.

Hier der Auszug aus dem Datenblatt:

Code Auswählen Erweitern

The RSSI value read from the RSSI status
register is a 2's complement number. The
following procedure can be used to convert the
RSSI reading to an absolute power level
(RSSI_dBm)
1) Read the RSSI status register
2) Convert the reading from a hexadecimal
number to a decimal number (RSSI_dec)
3) If RSSI_dec ≥ 128 then RSSI_dBm =
(RSSI_dec - 256)/2 – RSSI_offset
Note: It takes some time from the radio
enters RX mode until a valid RSSI value is
present in the RSSI register. Please see
DN505 [12] for details on how the RSSI
response time can be estimated.
CC1101
SWRS061I Page 45 of 98
4) Else if RSSI_dec < 128 then RSSI_dBm =
(RSSI_dec)/2 – RSSI_offset

Ich teste jetzt noch etwas meine Variante.
Ich glaub irgendwie nicht so recht daran, dass es am Powersave liegt.
Habe ja ne Ausgabe des Status eingebaut und über nen anderen Buchstaben den Reset.
Wenn ich den Status Ausgeben lasse, dann liest der ja auch vom SPI usw und danach gehts dann immer noch nicht.
Erst wenn ich den flushrx() ausführe gehts wieder.

EDIT:
Ahh, ok.
Werd ich mal umbauen ...

[Xent]

Vielleicht kämpfe ich hier auch mit einem CC1101 der einen weg hat ...
Auch ohne das Powersave macht er die Probleme.

Der der die Probleme macht, hängt an einem Ardunio Nano, direkt an den IOs also ohne Spannungsteiler.
Aber eigentlich sollte es daran ja nicht liegen, da beim Nano CUL auch bei steht, dass es auch so funktioniert.

Hatte jetzt noch einen Arduino Pro Mini 3,3v mit dem gleichen Sketch bespielt und hab den mal mit laufen lassen.
Dieser scheint sich nicht aufzuhängen ...

Ich hab jetzt noch nen Alarm eingebaut, der einmal pro Minute die Funktion flushrx aufruft.
Somit sollte es erstmal laufen ...
Aufjedenfall hab ich wieder was über den CC1101 und die AsksinPP Lib gelernt xD.

Vielleicht könntest du ja noch die korrigierte Berechnung des RSSI einbauen, falls das wiedermal gebraucht wird.

[Linef]

Schaut mal in die Errata-Notes des CC1101.
Trilu musste da auch was einbauen, da bei ihm der CC1101 immer mal wieder hing...

Martin

[Xent]

Ich denke du meinst diesen Bug:

RXFIFO_OVERFLOW Issue —Radio stays in RX state instead of entering RXFIFO_OVERFLOW state

Deswegen hatten wir auch schon die max Paketlänge auf 61 gesetzt.
Außerdem war GD0 nicht auf High, so wie es in der Fehlerbeschreibung sein sollte.

[Linef]

Ja, könnte der Bug gewesen sein.
Jedenfalls ist im aktuellen Code ein Hinweis drin, daß noch Bytes im Puffer stehen könnten und die zu löschen sind.

Deshalb wird nach dem regulären Auslesen des Empfangsbuffers in den Idle-Modus gewechselt (SIDLE), der Puffer gelöscht (SFRX), und dann wieder in den Empfangsmodus gewechselt (SRX).

Martin

[Xent]

Könnte sein, dass ich das Problem mit dem Empfang nun richtig gelöst habe.

Habe mir 3 meiner Homematic Geräte vorgenommen und dort den SPI-Verkehr mitgelesen.
Es gibt leichte Unterschiede bei der Art wie der CC1101 genau angesprochen wird.
Liegt wohl daran, dass die Geräte in verschiedenen Jahren auf den Markt gebracht wurden und daher immer nen etwas anderen Firmwarestand haben.

Ich habe nun die Init-Sequenz und die Register angepasst.
Außerdem habe ich das Schreiben der Register optimiert, indem diese nochmal ausgelesen werden so wie es die Homematic Geräte machen.
Ich werd das ganze noch etwas testen ob es wieder ausfällt, dann mach ich aus den einzelnen Schritten der Optimierung mal Commits.

[papa]

Das wäre ja wirklich super. Womit hast Du die SPI Kommunikation mitgelesen ?

[Xent]

Mit diesem Teil hier: http://www.ebay.de/itm/24MHz-8CH-USB-Logic-Analyzer-8-Channel-Logic-Analyzer-Compatible-to-Saleae-/171202927182?hash=item27dc7d5a4e:g:M-8AAOSwyQtV6XEJ

Will auch nochmal den Differenz Tempsensor mitlesen, wie der das mit dem Aufwachen macht.
Der 6-Fachtaster macht nen komplettes init in nen paar ms, wenn man ne Taste drückt.
Die Lib macht ja nur nen Aufwecken.
Man müsste bei der Lib zumindest noch die Testregister nach dem Aufwecken schreiben, da diese wieder auf Default sind nachm Sleep.

Auch will ich nach den Optimierungen mal den SPI-Verkehr der Lib mitlesen, und die Timings vergleichen.

Ich kann nacher ja mal die gespeicherten Sequenzen anhängen, dann kannst du dir die auch mit dem kostenlosen Programm anschauen.