AskSin++ Library

[Tom Major]

Danke für die Klarstellung Jerome, habe es verstanden glaub ich.
D.h. ein jungfräulicher EEPROM mit FF erzeugt beim ersten Start mittels "Init Storage" eine gültige chksum für den ganzen Bereich, darin enthalten ist auch die eigentlich noch ungültige Frequenz (21)FFFF.
Jetzt verstehe ich warum du nach dem Aufschrei gefragt hast 

[papa]

Ein Bild sagt mehr als 1000 Worte.

Bei Adresse 0x00 befinden sich 2 Byte Magic & 2 Byte CRC16 Checksumme der Device-Struktur. Damit ist gemeint, die Register der unterschiedlichen Listen, die Anzahl der Channels & der Peers. Damit soll sichergestellt werden, dass wenn sich im Code etwas ändert, was Einfluß auf die Position der Daten im EEProm hat, die Daten neu initialisiert werden. Es wird dann der "Device Data" Bereich neu initialisiert und die Checksumme aktualisiert. Das passiert natürlich auch nach dem erstmaligen Flashen. Ein RESET löscht die Magic und damit wird alles neu aufgebaut.
Der Start der "Device Data" wird im Konstructor angegeben - default 0x20. Der Bereich zwischen dem Magic und den "Device Data" war anfangs ungenutzt. Als das Frequenz-Thema auf kam, wurde der Bereich in das "Config Area" gewandelt. Daten die hier liegen, werden bei der Initialisierung niemals angefasst. Das letzte Byte im "Config Area" ist eine einfache XOR-Checksumme, mit welcher herausgefunden wird, ob die Daten gültig sind. Diese muss expliziert nach dem Ändern der Daten neu geschrieben werden.

[Xent]

Also ich hab gerade einen jungfräulichen Pro Mini programmiert und siehe da 0x21FFFF

Code Auswählen Erweitern

AskSin OTA Bootloader V0.7.0

Start App
AskSin++ V4.1.1 (Oct  7 2019 21:51:00)<\n>
Address Space: 32 - 258
CC init1
CC Version: 14
- ready
Config Freq: 0x21FFFF
iVcc: 3332

[jp112sdl]

Habe mal mit

Code Auswählen Erweitern


  for (int i = 0 ; i < EEPROM.length() ; i++) {
    EEPROM.write(i, 0xFF);
  }

mein EEPROM mit FF beschrieben.

Anschließend den HM-LC-Sw1-BA-PCB geflasht und es kommt

Code Auswählen Erweitern


AskSin++ V4.1.1 (Oct  7 2019 22:05:41)
Address Space: 32 - 258
FFFFFFFF
Init Storage: CAFEA52E
CC init1
CC Version: 04
- ready
iVcc: 3372


Mit Standard Optibootloader.

Da kommt nix mit Config Freq: 0x21FFFF

Ob der OTA Bootloader da nicht doch irgendwo reinspielt!?



EDIT:
Beim 2. Start kommt jetzt bei mir auch  Config Freq: 0x21FFFF

[Xent]

Auf welcher Frequenz arbeitet der CC1101 eigentlich standardmäßig?
Lohnt es sich den FrequenzSketch auch bei richtigen CC1101 anzuwenden?

[jp112sdl]

Das CC1101 hat keine "Standardfrequenz".
Es arbeitet (sollte zumindest) auf der Frequenz, mit dem du es initialisierst.
Homematic arbeitet auf 868.3 MHz. Die default Freq Parameter sind diese hier:

Code Auswählen Erweitern


      // 868.299866 MHz - if other values are found in EEPROM, these are overwritten later
      CC1101_FREQ2,     0x21,   //  0x1E
      CC1101_FREQ1,     0x65,   //  0xC4
      CC1101_FREQ0,     0x6A,   //  0xEC


Wenn du nun z.B. mithilfe eines SDR siehst, dass trotz eingestellter 868.3MHz die Funksignale bspw. auf 868.2 MHz gesendet werden, kannst du diese 100kHz Offset durch die angepassten FREQ Definitionen ausgleichen.

[jp112sdl]

Ja - 0 ist da sicherlich falsch. Da muss 0xff hin.

Nur auf 0xff oder lieber 0x00 && 0xff prüfen?

[papa]

Beim 2. Start kommt jetzt bei mir auch  Config Freq: 0x21FFFF

Weil beim ersten Start der ResetOnBoot-Code die Checksumme schreibt. Damit sind dann auch die beiden Frequenzbyte aktiviert.

[Tom Major]

Ein Bild sagt mehr als 1000 Worte.

Danke für die Erläuterungen. So langsam fügt sich das Bild zusammen. 

Vorschlag
a) die 21 mit schreiben durch den Test sketch und nur wenn die da ist die Freq. nehmen oder
b) range check beim Freq. lesen einführen, HM Freq +- 500kHz oder was auch immer

[jp112sdl]

500kHz sind schon mega viel.
Aber letztlich gehts ja nur um die Plausibilität.
Mein Vorschlag:
if (f1 >= 0x60 && f1 <= 0x6F)
oder kompakter?
if ((f1 >> 4) == 0b0110)

Ich mach mal einen PR zur Diskussion (oder zum Mergen^^)

[papa]

Naja kompakter ist das nicht. Ich habe mal den Compiler drauf geschickt:

Variante 1:

Code Auswählen Erweitern

Program:   26576 bytes (81.1% Full)
Data:       1088 bytes (53.1% Full)


Variante2:

Code Auswählen Erweitern

Program:   26588 bytes (81.1% Full)
Data:       1088 bytes (53.1% Full)


Also Variante 1 benötigt 12 Byte weniger Code und man kann es sogar noch besser verstehen

[jp112sdl]

Das ja mal interessant... Ok, bau ich um auf Var.1

[Tom Major]

500kHz sind schon mega viel.
Aber letztlich gehts ja nur um die Plausibilität.
Mein Vorschlag:
if (f1 >= 0x60 && f1 <= 0x6F)
oder kompakter?
if ((f1 >> 4) == 0b0110)

Ich mach mal einen PR zur Diskussion (oder zum Mergen^^)

Die +-500kHz waren auch gestern nach Mitternacht nur schnell hingeschrieben 
+-300 sind sicher besser und praktikabel.

Dein range 60..6F ist aber nicht mittig zur Centerfrequenz.
Besser wäre z.B. 62..69, das ergibt ca. 350kHz in beide Richtungen.

[jp112sdl]

Aber letztlich gehts ja nur um die Plausibilität.

Hmm

Besser wäre z.B. 62..69, das ergibt ca. 350kHz in beide Richtungen.

Am besten nen neuen PR machen.

[Tom Major]

Das stimmt, für den Plausibilität check reicht dein range allemal.
Wenn man es einmal anfasst hatte ich es halt nur so gemacht dass es auch noch Sinn macht wenn man mal 1 Jahr später draufschaut. 
Denn für -500kHz +1MHz Asymmetrie gibt es ja keine Erklärung/Grund.