Fehlerhafte CC1101 Module

Begonnen von gloob, 03 Oktober 2018, 21:25:21

Vorheriges Thema - Nächstes Thema

Jasimo

Hallo Zusammen,

ich hab hier auch ein CC1101 Module welches in Fhem sehr schlechte RSSI Werte liefert. Das Modul befindet sich auf einer HB-UNI-SENS-BATT Platine, als Sketch nutze ich HM-WDS40-TH-I-BME280.ino von Jerome

Nun hab ich auf den Arduino mal den FreqTest.ino geladen und bekomme als Ausgabe folgendes:
AskSin++ V3.1.7 (Mar 18 2019 16:12:41)
CC init1
CC Version: 14
- ready
Start searching ...
Freq 0x21656A: 345681.  1/79
Search for upper bound
Freq 0x21657A: 5D0534.  1/81
Freq 0x21658A: 471147.  1/75
Freq 0x21659A: 585D8C.  1/82
Freq 0x2165AA: 345682.  1/83
Freq 0x2165BA: 345686.  1/73
Freq 0x2165CA: 345683.  1/76
Freq 0x2165DA:   0/0
Search for lower bound
Freq 0x21655A: 585D8C.  1/79
Freq 0x21654A: 345681.  1/82
Freq 0x21653A: 5E86A9.  1/75
Freq 0x21652A: 471147.  1/72
Freq 0x21651A: 471147.  1/74
Freq 0x21650A: 5E86A9.  1/72
Freq 0x2164FA: 5E86A9.  1/74
Freq 0x2164EA:   0/0

Done: 0x2164FA - 0x2165CA
Calculated Freq: 0x216562
Store into config area: 6562


Anschließend flashe ich wieder den Sketch von Jerome und hatte die Hoffnung das sich die RSSI Werte bessern, aber leider nein.
Muss ich in dem Sketch von Jerome noch eine Anpassung vornehmen? Ich hatte es so gelesen bzw. verstanden das die Korrektur der Frequenz automatisch durch die AskSinPP zur Anwendung kommt.
Hab ich was vergessen, oder gar die falsche AskSinPP Version?

Gruß
Jan

Psi

Hallo zusammen,

leider hab ich auch etwaige Probleme weshalb sich mir folgende Fragen ergeben:


  • Wie komme ich an die Adressen der Devices ohne FHEM, ich bin RasperryMatic Nutzer
  • Da ich eine "CC1101 Testsation" habe bevor ich ihn verbaue teste ich mit einem anderen Pro Mini, wie bekomme ich die ermittelte Frequenz übertragen? Im Sketch definieren wäre eigentlich ganz elegant.

Danke für eure Arbeit!

jp112sdl

Zitat von: Psi am 18 März 2019, 23:50:37
Wie komme ich an die Adressen der Devices ohne FHEM, ich bin RasperryMatic Nutzer[/li][/list]

grep "^<device serial" /etc/config/rfd/ABCDEF0123.dev|awk -F 'address="0x' '{print $2}'|awk -F'"' {'print $1'}

wobei ABCDEF0123 die Seriennummer des Gerätes ist.

Zitat von: Psi am 18 März 2019, 23:50:37
Da ich eine "CC1101 Testsation" habe bevor ich ihn verbaue teste ich mit einem anderen Pro Mini, wie bekomme ich die ermittelte Frequenz übertragen?

Der Testsketch schreibt den Wert ins EEPROM.
Mit avrdude lässt sich der EEPROM Inhalt lesen/schreiben (https://logbuch.dmaertens.de/elektronik-hardware/microcontroller/eeprom-eines-microcontrollers-mit-avrdude-auslesen-und-beschreiben).

Wenn ich es richtig interpretiere, stehen die beiden Werte am Anfang vorn an (https://github.com/pa-pa/AskSinPP/blob/4ad8f147f07634b875e380085d14ae042cf19c82/AskSinPP.h#L14)

papa

Die Werte werden aber nur genommen, wenn die Checksumme am Ende des Speicherbereiches stimmt. Die Implementierung ist in Storage.h Zeile 457 - einfaches XOR mit 0x5e als Startwert.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Jasimo

Moin, und das ist im Master und V3 implementiert, oder nur im V3?
Gruß
Jan

jp112sdl

Zitat von: Jasimo am 19 März 2019, 13:45:18
Moin, und das ist im Master und V3 implementiert, oder nur im V3?
nur im Master

Jasimo


Psi

So, ich hab mich mal mit dem FreqTest beschäftigt. Hat tatsächlich ein paar CC1101 zur (scheinbar) sauberen Funktionalität verholfen.

Was mir aber jetzt "passiert" ist: RESET und damit natürlich auch CONFIG_FREQ1/2 gekillt. Wo/wie wäre einige gute Stelle um die Frequenz im Sketch zu setzen?

Im Setup?

void setup() {
  hal.radio.initReg(CC1101_FREQ2, 0x21);
  hal.radio.initReg(CC1101_FREQ1, 0x65);
  hal.radio.initReg(CC1101_FREQ0, 0xCA);
  DPRINT("Config Freq: 0x2165CA");

jp112sdl

Zitat von: Psi am 20 März 2019, 17:09:59
Was mir aber jetzt "passiert" ist: RESET und damit natürlich auch CONFIG_FREQ1/2 gekillt.
Was meinst du mit RESET?
Die Werte vom FreqTest werden ins EEPROM geschrieben und überleben einen Reset.

Man muss jedoch beim Setzen der Fuses darauf achten, dass "Preserve EEPROM on Chip Erase" aktiviert ist.

Psi

Die Fuses hab ich nicht verändert. Ich sehe nur im Monitor, dass u.A. "Config Freq: 0x2165CA" ausgegeben wird.

Nen very-long-press auf den Config Taster startet das Ding durch und ab dann seh ich kein "Config Freq: 0x2165CA" mehr also würde ich davon ausgehen, dass es gelöscht wurde.

jp112sdl

Zitat von: Psi am 20 März 2019, 17:22:28
Die Fuses hab ich nicht verändert. Ich sehe nur im Monitor, dass u.A. "Config Freq: 0x2165CA" ausgegeben wird.

Nen very-long-press auf den Config Taster startet das Ding durch und ab dann seh ich kein "Config Freq: 0x2165CA" mehr also würde ich davon ausgehen, dass es gelöscht wurde.
Ach den RESET meinst du :)
Ja, der initialisiert den EEPROM Inhalt neu

Psi

Dank Jerome scheint es nun zu gehen:

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  if( control.init(hal,DIMMER1_PIN,DIMMER2_PIN) ) {
    // first init - setup connection between button and first channel
    sdev.channel(1).peer(cfgBtn.peer());
  }
  // Init the hw button
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);

  // Set frequency for CC1101
  hal.radio.initReg(CC1101_FREQ2, 0x21);
  hal.radio.initReg(CC1101_FREQ1, 0x65);
  hal.radio.initReg(CC1101_FREQ0, 0xCA);
  DPRINTLN("Config Freq: 0x2165CA");

  sdev.initDone();

  // Output ID and Serial in serial console
  DDEVINFO(sdev);
}

papa

Zitat von: jp112sdl am 20 März 2019, 17:24:02
Ach den RESET meinst du :)
Ja, der initialisiert den EEPROM Inhalt neu
Das ist aber eigentlich blöd :-(
Der RESET sollte nur die Gerätedaten betreffen - die Frequenz ist ja eher ein Hardware Setting, was unabhängig vom logischen Gerät ist.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

gloob

#178
Kann es sein, dass die Werte für die Frequenzanpassung jetzt nicht mehr durch einen LongPress Reset überschrieben werden?

Ich nutze den Master Stand von heute.

Zitat11:41:18.492 -> AskSin++ V3.1.7 (Mar 24 2019 11:34:52)
11:41:18.526 -> Address Space: 32 - 73
11:41:18.526 -> CC init1
11:41:18.526 -> CC Version: 14
11:41:18.559 ->  - ready
11:41:18.903 -> Bat: 34
11:41:18.903 -> Config Freq: 0x21653A
11:41:18.903 -> Measure...
11:41:18.903 -> T/H = 273/33
11:41:20.237 -> <- 0C 01 A0 70 345681 00FFFF 01 11 21  - 1710
11:41:20.343 -> -> 0A 01 80 02 00FFFF 345681 00  - 1847
11:41:20.378 -> waitAck: 01
11:42:50.923 ->  debounce
11:42:50.996 ->  pressed
11:42:54.450 ->  longpressed
11:42:58.215 ->  longpressed
11:42:58.215 -> RESET
11:42:58.252 -> AskSin++ V3.1.7 (Mar 24 2019 11:34:52)
11:42:58.252 -> Address Space: 32 - 73
11:42:58.252 -> 00000000
11:42:58.252 -> Init Storage: CAFE6189
11:42:58.392 -> CC init1
11:42:58.392 -> CC Version: 14
11:42:58.425 ->  - ready
11:42:58.770 -> Bat: 34
11:42:58.770 -> Config Freq: 0x21653A
11:42:58.770 -> Measure...
11:42:58.770 -> T/H = 273/33
11:43:00.105 -> <- 0C 01 84 70 345681 000000 01 11 21  - 1871
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

papa

Das ist das von mir erwartete Verhalten. Hatte noch keine Zeit selbst zu testen. Weitere Einzelheiten im AskSin++ Beitrag.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire