2,4 Ghz Kommunikation

Christoph db1uq K. schrieb:
> Im Datenblatt finde ich keinen Pin namens SS
> https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf?cp=10_4_0_0
>
> Ist das vielleicht der Slave-Select der SPI-Schnittstelle? Der wird
> nicht benötigt, wenn nicht mehr als ein Slave dranhängt.

Der AVR SPI SS Pin entspricht dem /CS oder CSN Pin des Moduls.
Und natürlich kann das Modul nicht ohne diesen Pin betrieben werden.
Zwingend.
Das geht aus dem Datenblatt hervor.

OK, SS ist nicht zwingend, stattdessen kann man jeder anderen digitalen 
AVR Pin verwenden.
Aber auf /CS ganz verzichten?
No!

Torsten schrieb:
> Das Programm VisualNRF24 bringt mir keine Verbindung beim
> Transmitter(IRQ timeout) und bei Receive wartet er auf einen Wert den
> er, scheinbar auch nicht bekommnt.

Nicht schlecht dass du damit anfängst, dann hast du möglicher-
weise eine Fehlerquelle ausgeschlossen. Allerdings stehst du
weiterhin vor dem Problem dass auch die Hardware zum Programm
VisualNRF24 funktionsfähig sein muss was du ja nicht ohne
weiteres überprüfen kannst. Dann steht noch im Raum dass auch
die NRF24-Module ja mal defekt sein können.

Deswegen schlage ich vor dass du mal der Reihe nach deine
Schaltung(en) und Aufbau zeigst, wir schauen ob da nichts im Argen
liegt.

Dann wäre es gut wenn du ein komplettes Projekt postest (AVR Studio
oder Atmel Studio), dann wäre es einfach (für mich) auf einem
bei mir existierenden Controller deinen Code nachzuvollziehen.

Erste mögliche Fehlerquelle ausser Aufbau: Adressierung stimmt nicht.

Arduino Fanboy D. schrieb:
> Aber auf /CS ganz verzichten?
> No!

Tut er ja nicht. Ist alles in den Sourcen zu lesen. Z.B.:

1

// Definitions for selecting and enabling wl_module module

2

#define wl_module_CSN_hi     PORTB |=  (1<<CSN);

3

#define wl_module_CSN_lo     PORTB &= ~(1<<CSN);

4

#define wl_module_CE_hi      PORTB |=  (1<<CE);

5

#define wl_module_CE_lo      PORTB &= ~(1<<CE);

und

1

void wl_module_write_register(uint8_t reg, uint8_t * value, uint8_t len) 

2

// Writes an array of bytes into inte the wl-module registers.

3

{

4

    wl_module_CSN_lo;

5

    spi_fast_shift(W_REGISTER | (REGISTER_MASK & reg));

6

    spi_transmit_sync(value,len);

7

    wl_module_CSN_hi;

8

}

NRF Tester schrieb:
> Arduino Fanboy D. schrieb:
>> Aber auf /CS ganz verzichten?
>> No!
>
> Tut er ja nicht. Ist alles in den Sourcen zu lesen. Z.B.:
Ich meinte weder dich, den TE, oder seinen Code.

Sondern diese Aussage:
Christoph db1uq K. schrieb:
> Ist das vielleicht der Slave-Select der SPI-Schnittstelle? Der wird
> nicht benötigt, wenn nicht mehr als ein Slave dranhängt.
Denn das ist irgendwie Unfug.
Und genau diese Aussage habe ich auch zitiert.

Tipp:
Meist gibt es einen Zusammenhang, zwischen Zitat und darauf folgender 
Aussage.

Torsten M. schrieb:
> anbei die zwei Programme für Sender und Empfänger.

Ich werde das am Wochenende mal durchspielen.

Eines ist mir auf die Schnelle aufgefallen: Das Programm VisualNRF24
nutzt - soweit ich mich recht erinnere - immer eine Payload von 32
die auch nicht veränderbar ist.
Du hast aber 16 eingestellt. Wenn die Payloads nicht passen geht
meist gar nichts.

Will allgemein heissen dass du sehr darauf achten musst dass im
Zusammenspiel wirklich alle wichtigen Parameter gleich sind bzw.
zusammenpassen müssen.

Torsten schrieb:
> Das Programm VisualNRF24 bringt mir keine Verbindung beim
> Transmitter(IRQ timeout) und bei Receive wartet er auf einen Wert den
> er, scheinbar auch nicht bekommnt.

Zeige doch mal einen Screenshot von den Betriebszuständen,
vielleicht kann ich dort auch etwas Signifikantes erkennen.

Ein Tip noch: ein Button "Parameters" gibt dir alle wichtigen
Betriebsparameter aus die notwendig sind mit diesem Programm
und dem daran angehängten NRF24 zu kommunizieren. Die müssen
eben auch von der Gegenstelle erfüllt werden damit eine
Verbindung klappt.

Torsten M. schrieb:
> Im Anhang ein Bild von dem Programm NRF24.

Dir ist nicht bekannt wie man eine saubere Kopie vom Bildschirm macht?
Ist sogar noch weniger umständlich als ein Foto vom Handy zu posten.

Torsten M. schrieb:
> Wenn ich mir die Parameters anzeige lasse kommt die Meldung "--Not yet
> implemented--"

Ja jetzt wo du es sagst fällt es mir wie Schuppen von den Haaren.

Torsten M. schrieb:
> Wenn ich mir die Parameters anzeige lasse kommt die Meldung "--Not yet
> implemented--"

Ich habe das nicht weiter verfolgt da sich alle Parameter
aus den Register-Inhalten direkt entnehmen lassen.

Torsten M. schrieb:
> Im Anhang ein Bild von dem Programm NRF24.

Ich habe mal mit meinem Setup ohne einen beteiligten Empfänger
den Transmit gestartet. Dabei kommt im Textfenster kein IRQ
Timeout. Also würde ich vermuten dass bei dir doch etwas falsch
verdrahtet ist, oder dein NFR24 reagiert fehlerhaft.

Ein IRQ tritt auf jeden Fall auf wenn nach 15 Retries kein
Acknowledge gemeldet wird. Bei dir kommt offensichtlich kein
IRQ, also wird IRQ Timeout gemeldet.

Versuche auch mal den SPI LoopBack Test, der sollte fehler-
frei durchlaufen, auch wenn das nichts mit dem IRQ direkt
zu tun hat. Aber dadurch wird der NRF beschrieben und wieder
gelesen und man bekommt dadurch eine Bestätigung ob die
SPI Kommunikation prinzipiell funktioniert.

Torsten M. schrieb:
> Der SPI LoopBack Test läuft
> ohne Fehlermeldung durch wobei es ab und zu vorkommt das er schon nach 4
> oder 19 eine fehler meldet, dass ist aber sehr sehr selten.

Es dürfen keine Fehler auftreten.

Versuche das Kabel vom Druckerport vor Einstreuungen zu schützen
oder einfach anders zu verlegen um zu sehen ob du die LoopBack
Fehler wegbekommst.

Es wird auch Zeit dass du deinen Aufbau zeigst. Da könnte einiges
im Argen liegen. Zunächst mal bitte den Drucker-Port-Testaufbau.

Torsten M. schrieb:
> Was mir noch Aufgefallen ist das beim  Bild vom NRF Tester in der Spalte
> Retries (0x04) mehr ausgewählt ist wie bei mir

Das könnte darauf hindeuten dass es sich um einen gringfügig anderen
Chip handelt, die Register werden geschrieben und gelesen, in diesem
Fall kommt wohl "weniger" zurück als das was das Programm schreibt.

Auch die Register RXPWP0...RXPWP5 sind bei dir nicht identisch
beschrieben, schaut alles ein bisschen anders aus ....

Torsten M. schrieb:
> und ebenso stehen in den
> PLOST und ARC Zahlen drin wo ich keine eingeben kann.

Das sind Ergebnisse die nur vom Chip lesbar sind.

Torsten M. schrieb:
> Es ist auch keine LED an von den 2 verbauten.

Bei den Modulen die ich besitze sind keinerlei LEDs verbaut, auch
ein Hinweis auf abweichende Chips und/oder Defekte. Zeig doch mal
die Module und/oder einen Link zum Verkäufer um zu sehen was es
für Module sind.

Torsten M. schrieb:
> so der SPI LoopBack Test läuft ohne Fehlermeldungen jetzt durch.

Sehr schön. Und was hast du geändert?

Auch die Transmit-Versuche aus der Message-Box schauen jetzt so
aus wie sie sollen.

Also irgendetwas Entscheidendes musst du ja geändert haben!

Torsten M. schrieb:
> Im Anhang habe ich mal zwei Bilder von dem Drucker-Port-Testaufbau

Schaut vernünftig aus. Aber wehe du hast C2 und C3 nicht eingebaut.
Dann aber ..... ! Und wehe du hast C1 am NRF24 nicht bestückt! Dann
aber ..... ! Das muss ein keramisches C sein, für "gute" HF-Eigen-
schaften.

Versuche noch die Masse auf der Unterseite auf mehreren Wegen
miteinander zu verbinden. Das verbessert das Masse-Potential der
Teile zueinander und bildet ein (besseres) Masse-Gegengewicht zur
NRF24-Antenne.

Mit welcher Versorgungsspannung gehst du an die Eingangsbuchse?

Ich reite so auf dem Thema Spannungsversorgung herum da die
Module schon ohne Verstärker recht anspruchsvoll in der
Versorgungs-Stabilität sind, mit Verstärker wird das nochmal
schlimmer. Man kann da gar nicht gut genug aufpassen, die
Streubreite bei den einzelnen Usern ist da sehr gross.

Torsten M. schrieb:
> C2 & C3 sind 47nF und C1 sind 100nF aber das dürfte ja kein Problem sein.

Und was stehen da für Werte in meinem Schaltplan? Ist es überflüssig
den Wert einzuhalten? Auf meinen Fotos zum Aufbau habe ich die
Kondensatoren direkt an der Steckbuchse des NRF24 angebracht und
den Spannungsregler dort auch nahe positioniert. Was mag das wohl
für ein unsinniges Vorgehen sein?

Wenn du mit drei Dioden nach dem Spannungsregler arbeitest hast du
im Extremfall schon nur 2.9 Volt am NRF24 (ich nehme an du hast
einen 5V Regler) die dazu noch schwanken können (die Diodenfluss-
Spannung verändert sich mit dem Strom). Das ist schon wieder
so ein Schwachpunkt der das Ganze zum Scheitern bringen kann bzw.
die Anordnung unzuverlässig(er) macht. Die möglicherweise durch
Belastungsänderungen hervorgerufene Spannungsschwankung kann die
Frequenz des NRF24 geringfügig verschieben und damit ein
Verbindungsproblem verursachen.

--> Sorge für eine saubere und stabile 3.3 Volt Versorgung. <--

Die Verstärker-Module brauchen das und ziehen mächtig Strom, wenn
auch nur sehr kurz (gepulst).

Sorge auch auf deinen Controllern für entsprechende Stabilität.
So wie hier vorgebetet.

Bevor ich (das war meine erklärte Bereitschaft) mir deinen Code mal
durchspiele würde ich dann schon gerne vorher die Schaltung der
Controller und die Aufbauten dazu sehen.

Torsten M. schrieb:
> Ich habe mir neue Antennen bestellt

An den Antennen kann es eigentlich nicht liegen, nur indirekt
wenn sie durch ihre schlechte Abstrahl-Eigenschaften den
Ausgangsverstärker zu starken Schwankungen der Stromaufnahme
bringen könnten. Kann ich mangels "schlechter" Antennen nicht
nachvollziehen. Meine Module mit Verstärker funktionierten
sofort out-of-the-box.

Zu den Bildchen:

Ok das schaut zumindest dahingehend gut aus dass du noch ein
(käufliches) Spannungsregler-Modul am NRF24 hast.

Dem STK600 Board sollte man von der Stabilität her Vertrauen
schenken können.

Torsten M. schrieb:
> Ich habe mir das Spannung auch mal mit dem Oszilloskop angeschaut und es
> sind saubere 3,3V Versorgung und es ist kein Einbruch zu sehen.

Einen Einbruch in der Versorgungsspannung der ein paar Mikrosekunden
dauert und vergleichsweise "gering" einbricht kann man nicht ohne
weiteres erkennen.

Nachdem du dich einigermassen verlassen kannst dass dein Druckerport-
NRF24 senden kann, kannst du ja mal beginnen zu testen ob du mittels
STKxxxx und Mikrocontroller das empfangen kannst was dein PC sendet.

Torsten M. schrieb:
> Ich hab da jetzt noch ein wenig geteste und "gespielt" und die
> Kommunikation scheint jetzt fast zu stehen

Gut.

Torsten M. schrieb:
> Auf dem Mikrocontroller empfange ich immer ein 78.

Für dieses Testprogramm VisualNRF: im Emfangsbuffer deines
Controllers (falls erfolgreich empfangen) steht ein ASCII String
den du mit (exemplarisch)

1

char  printbuffer[40];

2

sprintf (printbuffer, "%s", receive_buffer)

3

putstr (printbuffer);

ausgeben kannst. Das ist genau der String der im Xmit Buffer
des VisualNRF aktuell angezeigt wird (mit Durchnumerierung 0-99).

Torsten M. schrieb:
> Auf dem Mikrocontroller empfange ich immer ein 78.

Nein, du empfängst für diesen Testfall immer einen kompletten
Buffer mit Payload 32.

78 entspricht Hex 0x4E entspricht dem ASCII Character N, das ist
der erste des gesendeten Strings "NRF24dat from VisualNRF #xx -"

Christian S. schrieb:
> Wie soll man eigentlich das im Fenster des VisualNRF angezeigte Wort
> "packacke" betonen?

Meinst du jetzt den Dreckfuhler (ja, es muss package geschrieben
sein), oder wie sollte ich deine Frage sonst verstehen?

Torsten M. schrieb:
> Port_Platine1.jpg

Wenn ich mir das Bild anschaue sehe ich da am DC Connector noch
4 Dioden, was sollen die bezwecken? Gehst du da mit Wechselspannung
in den DC Eingang? Und dann noch ohne Glättungs-Elko nach den Dioden?
Das wäre ganz beträchtlicher Pfusch.

Christian S. schrieb:
> wobei nicht alle Zeichen aus dem Fifo geholt werden

Nur zur Klarstellung: wenn ein NRF Sender ein ACK vom Empfänger
bekommt bedeuted das dass der Empfänger den Datenpuffer voll-
ständig und fehlerfrei erhalten hat so wie ihn der Sender
abgeschickt hat.

Alle Fehler darüber hinaus liegen beim Programm des Empfängers.

Torsten M. schrieb:
> endlich bin ich mal wieder dazu gekommen etwas weiter zumachen.

Ja vielen Dank auch dass ich dir mit ein paar Dingen helfen
durfte. Gegendank darf man ja nicht erwarten, das wäre zuviel
verlangt.

Torsten M. schrieb:
> Als Payload habe ich noch die 32kByte stehen.

Das halte ich für stark (etwa 3 Zehnerpotenzen) übertrieben.

Torsten M. schrieb:
> Da würde mir eine Paketlänge von 16kByte genügen.

Auch das halte ich für stark (etwa 3 Zehnerpotenzen) übertrieben.

Der Rest deinenes Beitrages ist doch einigermassen verwirrend
sodass man eigentlich nicht darauf anworten kann ohne längliche
Romane zu schreiben.

Aber nachdem hier soviele Dankesschreiben eintrudeln brauch ich
ja gar nichts mehr schreiben, das dürfen andere tun.