stm32f103 und Frequenztest klappt nicht

[Horbi]

Gerade noch etwas getestet - wenn ich einen Aktiv Ping mache, geht es.

Code: Alles auswählen

AskSin++ V4.1.5 (Jun 10 2020 16:54:33)
detach isr
CC init1
CC Version: 14
 - ready
attach isr
Start searching ...
Freq 0x21656A 868.300 MHz:   0
Freq 0x2165BA 868.332 MHz:  * 10976
45FBFA.  1 / -80dBm
Search for upper bound
Freq 0x2165CA 868.338 MHz:  * 12004
45FBFA.  1 / -82dBm
Freq 0x2165DA 868.344 MHz:  * 13033
45FBFA.  1 / -81dBm
Freq 0x2165EA 868.351 MHz:  * 13093
AAA001.  1 / -95dBm
Freq 0x2165FA 868.357 MHz:  * 13221
4109F2.  1 / -42dBm
Freq 0x21660A 868.363 MHz:  * 13633
4109F2.  1 / -42dBm
Freq 0x21661A 868.370 MHz:  * 13783
4109F2.  1 / -42dBm
Freq 0x21662A 868.376 MHz:  * 14059
45FBFA.  1 / -81dBm
Freq 0x21663A 868.382 MHz:  * 14353
4109F2.  1 / -42dBm
Freq 0x21664A 868.389 MHz:  * 14763
4109F2.  1 / -42dBm
Freq 0x21665A 868.395 MHz:  * 14914
4109F2.  1 / -42dBm
Freq 0x21666A 868.401 MHz:  * 15273
4109F2.  1 / -42dBm
Freq 0x21667A 868.408 MHz:  * 15685
4109F2.  1 / -42dBm
Freq 0x21668A 868.414 MHz:   0
Search for lower bound
Freq 0x2165AA 868.325 MHz:  * 20747
4109F2.  1 / -42dBm
Freq 0x21659A 868.319 MHz:  * 21018
AAA001.  1 / -96dBm
Freq 0x21658A 868.313 MHz:  * 21179
AAA001.  1 / -95dBm
Freq 0x21657A 868.306 MHz:  * 23370
AAA001.  1 / -96dBm
Freq 0x21656A 868.300 MHz:  * 24652
AAA001.  1 / -95dBm
Freq 0x21655A 868.294 MHz:   0

Done: 0x21656A - 0x21667A
Calculated Freq: 0x2165F2 868.354 MHz
Store into config area: 65F2....stored!
 * 63067
 * 130733

Vielleicht könntet ihr das auch mal testen und Bescheid geben?

[Horbi]

Und noch etwas herausgefunden - wenn ich in Radio.h:.init am Schluss ein "spi.strobe(CC1101_SRX);" ergänze, scheint das cc1101 Modul auf Empfang geschalten zu werden und klappt sofort mit dem Frequenztest...

Radio.h - init() Funktion:

Code: Alles auswählen

    // Settings that ELV sets
    DPRINT(F("CC Version: ")); DHEXLN(spi.readReg(CC1101_VERSION, CC1101_STATUS));

    spi.strobe(CC1101_SCAL);                                // calibrate frequency synthesizer and turn it off

    _delay_ms(23);

    initReg(CC1101_PATABLE, PA_MaxPower);                        // configure PATABLE
    spi.strobe(CC1101_SRX);
 
    DPRINTLN(F(" - ready"));
  }

Wäre klasse wenn das jemand testen und bestätigen könnte.

[jp112sdl]

Gerade noch etwas getestet - wenn ich einen Aktiv Ping mache, geht es.

Ich nehme grundsätzlich nur den "active ping".
Meine Testreihe von heut morgen war auch damit erstellt.

[jp112sdl]

Und noch etwas herausgefunden - wenn ich in Radio.h:.init am Schluss ein "spi.strobe(CC1101_SRX);" ergänze, scheint das cc1101 Modul auf Empfang geschalten zu werden und klappt sofort mit dem Frequenztest...

Die Kommandos an das CC1101 sind ja egal welcher µC verwendet wird, immer die selben.
Von daher sollte sich auch das CC1101 unabhängig vom µC gleich verhalten.

Dass Daten im RX-Puffer bereit stehen, wird über den GDO0-Pin signalisiert.
Und da scheint es zu Problemen zu kommen.

Meine Vermutung:
Irgendwas schaltet den Interrupt ab? Ich kenne mich dabei aber auch 0,0 mit STM32 aus.
Ist es ein Hardware-INT-Pin, an dem der GDO0 angeschlossen ist?
Oder erfolgt hier nur Polling?
Liegts evtl. an einem Pullup/Pulldown?

[Horbi]

Pullup und down habe ich schon getestet, daran liegt es aus meiner Sicht nicht.
Es muss irgendwas mit dem SPI sein. Das ist ja der einzige Unterschied, der cc1101 wird ansonsten für AVR wie auch für Stm32 gleich initiert.
Offensichtlich ist aber der cc1101 beim Stm32 nach dem init nicht im Empfangsmodus...

[papa]

Beim AVR wird normalerweise das SPI direkt mit der Hardware gemacht -> AvrSPI. Es gibt noch die alternative Implementierung mit der SPI-Library -> LibSPI. Diese wird beim STM genutzt. Vielleicht hat es ja auch damit was zu tun. Beim AVR können wir auch die Lib nutzen -> siehe HM-RC-4 Example. Wenn der Fehler dann auch mit dem AVR auftritt - liegt es an der Implementierung mit der SPI LIbrary.

[jp112sdl]

Und noch etwas herausgefunden - wenn ich in Radio.h:.init am Schluss ein "spi.strobe(CC1101_SRX);" ergänze, scheint das cc1101 Modul auf Empfang geschalten zu werden und klappt sofort mit dem Frequenztest...

Offensichtlich ist aber der cc1101 beim Stm32 nach dem init nicht im Empfangsmodus...

Ich hänge immer noch am GDO0

Der GDO signalisiert: "Neue Daten sind da"
Es erfolgt der Aufruf der Methode rcvData in Radio.h:610
Am Ende der Methode wird auch das CC1101 wieder in den SRX gesetzt.

Also das was du manuell gemacht hast, erfolgt eigentlich durch den GDO0 getriggert.
Meiner Meinung nach.

[jp112sdl]

Beim AVR wird normalerweise das SPI direkt mit der Hardware gemacht -> AvrSPI. Es gibt noch die alternative Implementierung mit der SPI-Library -> LibSPI. Diese wird beim STM genutzt. Vielleicht hat es ja auch damit was zu tun. Beim AVR können wir auch die Lib nutzen -> siehe HM-RC-4 Example. Wenn der Fehler dann auch mit dem AVR auftritt - liegt es an der Implementierung mit der SPI LIbrary.

Der AskSinSniffer nutzt auch LibSPI und macht nix weiter als nur empfangen... da gibt auch keine Probleme.
Ansonsten nutze ich bei 6 oder 7 weiteren Projekten die LibSPI mit dem 328P.

[jp112sdl]

Wäre klasse wenn das jemand testen und bestätigen könnte.

Habe ich gerade mal ausprobiert und kann ich auch so bestätigen.

wakeup() macht ja eigentlich das selbe... aber nur wenn idle==true ist.

Wenn man aus dem Sketch heraus setIdle(), wakeup() ausführt, bleibt der Empfang trotzdem stumm.

Ohne setIdle(), also nur wakeup() (und ohne die idle==true Prüfung), da geht es dann wieder.

Jetzt bin ich mehr als verwirrt

[papa]

Hm - mach mal in das Radio::init() nach dem HWRADIO::init() noch ein HWRADIO::wakeup(true) rein. Dann stimmt der Status der idle Variablen auch mit dem Hardwarestatus.