2,4 Ghz Kommunikation

[Torsten (Gast)]

Hallo zusammen,

ich weiß das dieses Thema schon oft gibt und ich mich schon durch alle 
Durchgelesen habe und ich es trozdem nicht zum laufen bekommen.

In der 2,4 Ghz Funktechnik bin ich gerade am Einsteingen und bin am 
verzweifelen. Ich Arbeite schon über Wochen an einem Programm welches 
eine 2,4 Ghz Verbindung aufbauen soll(te).

Verwendete Bauteile:

Funkmodule: NRF24L01+PA+LNA
Sender IC: Atmega 8
Empfänger IC: Atmega 16
Adressevergabe 2 bei beiden IC's

Verkabelung:
V+ = 3,3 V
GND = GND
CE = = Atmega8 -> PB0 / Atmega16 ->PB0
CSN = = Atmega8 -> PB1 / Atmega16 ->PB1
MOSI = Atmega8 -> PB3 / Atmega16 ->PB5
MISO = Atmega8 -> PB4 / Atmega16 ->PB6
SCK = Atmega8 -> PB5 / Atmega16 ->PB7
IRQ = Atmega8 -> PD2 (INT0) / Atmega16 -> PD2 (INT0)

Als Projekt vorlage habe ich das Bsp. von Ernst Buchmann Stand 
06.01.2012 genommen. Habe die Pin belegungen bei den IC's entsprechend 
angepasst.

Was mir auffällt ist die Pin-Bezeichnung SS im Programm deklariert wurde 
er jedoch nicht angeschlossen ist.

Im Anhang habe ich mal das Programm angehängt sowohl vom Empgänger als 
auch vom Sender.

Ich lass mir über den Seriallen Port auch die Signale vom INT0 
Übertragen, da sagt er mir das die Datenübertragung fehlgeschlagen ist.

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.

Hat jemand eine Idee woran das noch liegen kann.

Schon einmal ein ganz großen Danke im vorraus.

Gruß

[Christoph db1uq K. (christoph_kessler)]

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.

[Einer K. (Gast)]

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!

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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

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

// Definitions for selecting and enabling wl_module module
#define wl_module_CSN_hi     PORTB |=  (1<<CSN);
#define wl_module_CSN_lo     PORTB &= ~(1<<CSN);
#define wl_module_CE_hi      PORTB |=  (1<<CE);
#define wl_module_CE_lo      PORTB &= ~(1<<CE);

und

void wl_module_write_register(uint8_t reg, uint8_t * value, uint8_t len) 
// Writes an array of bytes into inte the wl-module registers.
{
    wl_module_CSN_lo;
    spi_fast_shift(W_REGISTER | (REGISTER_MASK & reg));
    spi_transmit_sync(value,len);
    wl_module_CSN_hi;
}

[Torsten M. (knoddelpusch)]

Hallo,

anbei die zwei Programme für Sender und Empfänger.
Ich habe auch noch ein Bild von meinen Beobachtungen vom usb oszilloskop 
angehängt.

Für das VisualNRF24 Programm habe ich den aufbau nach dem Plan gemacht.
Schon gefühlte Tausendmal kontrolliert und die Durchgänge bzw. 
Wiederstände gemessen.

Rot = INT0 / Gelb = PB0(CE) / Blau = PB1 (CSN).

Zum Programmieren verwende ich AtmelStudio 7.0
Sowie einmal STK 500 und STK 600.

[Einer K. (Gast)]

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.

[Christian S. (roehrenvorheizer)]

Hallo,

lassen sich denn wenigstens die Register beschreiben und der Reihe nach 
auslesen mit den gleichen Werten?
Ist das Statusregister lesbar?

ist das schon bekannt?
Beitrag "nRF24L01+ und PA Kombi gibt kein Acknowledge"

MfG

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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. (knoddelpusch)]

Im Anhang ein Bild von dem Programm NRF24.

Wenn ich mir die Parameters anzeige lasse kommt die Meldung "--Not yet 
implemented--"

Im Programm habe ich die Payload Signal auch schon auf 32 erhöt.

[NRF Tester (Gast)]

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. (knoddelpusch)]

NRF Tester schrieb:
> 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.

Ist mir bekannt, Arbeite aber gerade mit 2 PC's wegen dem Seriellen Port 
und da geht die Netzwerkkarte nicht mehr... hab schon eine bestellt für 
rein.
Der PC war eigentlich aber auch schon auf dem Weg zum Schrott.

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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.

[Christoph db1uq K. (christoph_kessler)]

>Aber auf /CS ganz verzichten?

Das kommt öfter vor, hängt aber vom Chip ab. Oft kann man darauf 
verzichten, den CS zu bedienen sondern kann ihn immer selektieren. Wenn 
allerdings der Chip eine Flanke zur Datenübernahme erwartet geht das 
nicht.

Irgendwoher muss der Chip wissen, wann eine Dateneingabe anfängt und 
aufhört.
Spezielle Protokolle wie I2C und 1-wire haben das gelöst. Bei I2C durch 
besondere Start/Stop-Bedingungen und 1-wire durch Timeout.

[Torsten M. (knoddelpusch)]

Hallo,

also ich habe das ganze nochmals komplett neu aufgebaut und zusammen 
Gelötet und habe noch immer dieses Problem. 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.

Auch die Verkableung an das STK 600 Board ist neu aufgelegt worden.

Was mir noch Aufgefallen ist das beim  Bild vom NRF Tester in der Spalte 
Retries (0x04) mehr ausgewählt ist wie bei mir und ebenso stehen in den 
PLOST und ARC Zahlen drin wo ich keine eingeben kann.
Es ist auch keine LED an von den 2 verbauten.

Die NRF24 Module habe ich auch schon gewechselt, war ein 3 Paket wo ich 
mir bestellt hatte.

Am IRQ Pin liegen dauerhaft 3,34V an (Gemessen mit einem alten 
Drehspulmesswerk).

Was mir noch Aufgefallen ist, ich hatte die ganze Zeit die 3 NRF24 an 
Spannung hängen, wenn ich einen Trenne sehe ich mit meinen Oszilloskop 
auch kein Flanken mehr.

[Christian S. (roehrenvorheizer)]

Was genau möchte dem geneigten Betrachter das Bild TX_1.png zeigen?


mfG

[Torsten M. (knoddelpusch)]

Das ist  versehentlich dazu gekommen.

Aber kurz zur Farblichen bezeichnung.

Rot = INT0 / Gelb = PB0(CE) / Blau = PB1 (CSN).

Zum Vergleich zu weiter oben wo ich die 3 NRF24 an Spannung hatte sind 
es hier nur 2.

[Christian S. (roehrenvorheizer)]

Hallo,

weshalb schließt Du alle drei Funkmodule gleichzeitig an Spannung an? 
Aber die SPI- nud Steueranschlüsse sind nicht parallel geschaltet 
währenddessen?

mfG

[Torsten M. (knoddelpusch)]

Hallo,

die 3 Funkmodulle waren nicht Absichtlich angeschlossen und es ware jede 
an einem eigenen IC bzw PC.
Ich habe am Anfang mit zwei Mikrocontroller gearbeitet, also waren die 
Module getrennt an den IC's verkabelt, nur die Spannungsversorgung geht 
von einer Stromquelle aus. Jetzt sind zwei Modulle angeschlossen eins am 
Atmega8 und eins am PC.

[NRF Tester (Gast)]

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. (knoddelpusch)]

Hallo,

so der SPI LoopBack Test läuft ohne Fehlermeldungen jetzt durch.

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

Die Verkabelung geht mit einem Druckerportkabel weg vom PC und liegt in 
keiner nähe von 230V bzw eines Handys.

Im Anhang habe ich mal zwei Bilder von dem Drucker-Port-Testaufbau die 
schwarze Punkten zeigen Unterbrechungen in der Leiterbahnen auf der 
Unterseite.
Der Stecksockel ist etwas größer als benötigt, die ersten 3 Reihen von 
der Spannungsseite aus gesehen sind nicht belegt (schwarz -, rot +)

Heute habe ich auch zwei neue Antennen bekommen 
(https://www.amazon.de/dp/B07P95X6HM/ref=pe_3044161_185740101_TE_item). 
Mit diesen Antennen läuft auf dem PC der Transmitter schon mal ganz 
anderes (Bild beigefügt).

[Christian S. (roehrenvorheizer)]

Die 10uF-Kondensatoren sind gar nicht zu sehen. Sind sie unten am 
Spannungsregler?

MfG

[Torsten M. (knoddelpusch)]

Ja die sitzen unten auf der anderen Seite der Platine.
Mal schauen vllt bekomme ich die oben auch noch hin.

[NRF Tester (Gast)]

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?

[NRF Tester (Gast)]

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. (knoddelpusch)]

NRF Tester schrieb:
>> so der SPI LoopBack Test läuft ohne Fehlermeldungen jetzt durch.
>
> Sehr schön. Und was hast du geändert?

Ich habe mir neue Antennen bestellt (siehe link, zuvor waren es 
https://www.amazon.de/gp/product/B06WD17WLS/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 
diese)


So habe jetzt die Kondensatoren oben auf die Platine aufgelötet (Bild im 
Anhang) es gibt jedoch kleine Unterschiede was die größe betrifft. C2 & 
C3 sind 47nF und C1 sind 100nF aber das dürfte ja kein Problem sein.

Ich komme mit 7,5V an die Eingangsbuchse und dann über den 
Spannungsregler auf 5V und dann noch über 3 Dioden.

Habe die Antenne jetzt nochmals mit einem Kabel weiter von der Platine 
entfert.

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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.

[Torsten M. (knoddelpusch)]

NRF Tester schrieb:
> Und was stehen da für Werte in meinem Schaltplan? Ist es überflüssig
> den Wert einzuhalten?

Nein den Wert sollte man einhalten... habe aber zur Zeit leider kein 
passender im Haus und die neuen, wo ich bestellt habe sind schon 
überfällig da sind dann auch die entsprachenden größen dabei.

Das Gegenstück dazu ist auf keiner Platine aufgelötet.
Der Atmega8 ist auf einem STK600 Board Platziert wo auch die Antenne 
angeschlossen ist (Bild beigefügt, Controller 1 mit Abdeckung vom 
STK600, Controller 2 ohne Abdeckung).
Außer der Antenne ist noch der Serielle Port angeschloassen.

NRF Tester schrieb:
> --> Sorge für eine saubere und stabile 3.3 Volt Versorgung. <--

Ich habe jetzt die 3,3V direkt von einem stabiliseierten Netzteil ohne 
zwischen Regler auf die Platine aufgelegt. Diese habe ich auch schon die 
ganze Zeit am STK600 verwendet (hätte ich ja auch gleich nehmen können).

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.

Änderung:
Ich habe jetzt den Step-Down ASM117 mit eingebaut wo bei den Antennen 
dabei war.

NRF Tester schrieb:
> An den Antennen kann es eigentlich nicht liegen,

Vielleicht hatten die auch einen kleinen schuß gehabt. Wenn es mit den 
anderen zwei funktioniert kann man sie ja nochmals Probieren.

[NRF Tester (Gast)]

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. (knoddelpusch)]

Ich hab da jetzt noch ein wenig geteste und "gespielt" und die 
Kommunikation scheint jetzt fast zu stehen ab und zu kommt noch ACK 
failed, das wird aber an dem Aufbau liegen. Auf dem Mikrocontroller 
empfange ich immer ein 78.

[NRF Tester (Gast)]

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)

char  printbuffer[40];
sprintf (printbuffer, "%s", receive_buffer)
putstr (printbuffer);

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

[NRF Tester (Gast)]

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. (roehrenvorheizer)]

Hallo,

dann scheint ja der Empfang zu funktionieren, wobei nicht alle Zeichen 
aus dem Fifo geholt werden. Das kann an falsch übertragener Paketlänge 
liegen, falscher Einstellung ob feste oder variable Paketlänge. Oder ein 
Zeiger läuft nicht mit. Die Pipe scheint die Richtige zu sein, aber jede 
läßt sich konfigurieren.

wl_module.c dürfte erste Anlaufstelle sein zusammen mit der h Datei.

Wie soll man eigentlich das im Fenster des VisualNRF angezeigte Wort 
"packacke" betonen?


MfG

[NRF Tester (Gast)]

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.

[NRF Tester (Gast)]

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.

[Christian S. (roehrenvorheizer)]

Hallo,

ja richtig. Ich meine den Dreckfuhler und einen Fehler im 
Empfängerprogramm, das die Daten, die bereits im FiFo enthalten sind, 
nicht richtig abholt. Den genauen Grund des Fehlers findet man nur, 
indem man das Empfängerprogramm im Einzelnen nachvollzieht. Dazu müßte 
ich es mir erst mal ausdrucken...

Die vier Dioden am Stecker ohne Elko haben mich auch schon gewundert. 
Können natürlich auch als Verpolungsschutz dienen.


MfG

[Torsten M. (knoddelpusch)]

Hallo,

hatte gersten leiter keine Zeit weiter zu machen.


NRF Tester schrieb:
> Wenn ich mir das Bild anschaue sehe ich da am DC Connector noch
> 4 Dioden, was sollen die bezwecken?

Diese 4 Dioden sollen nur einen Verpolungsschutz bezwecken habe schon 
"schlechte" erfahrungen gemacht. Die 4 Dioden sind günstiger als mancher 
IC oder andere Hardware.

Ich habe jetzt mal beide Module jeweils an einen Atmega 16 angeschlossen 
diese zwei Kommunizieren auch miteinander ohne Problem. Ich lasse den 
payload immer eins hochzählen bis 250 wenn diese erreicht sind fange ich 
wieder bei null an.
Vom Empfänger lasse ich mir diesen Werte über die Serielle-Schnittstelle 
auf meinem PC Anzeigen und sehe das die Werte so kommen wie sie sollen.

Die Antennen habe ich auch mal zum Testen wieder die "alten" eingebaut 
auch diese Kommunizieren untereinander auch ohne Problem, selbst die 
zwei Antennen gemischt (erste und zweite Bestellung) Kommunizieren 
miteinander.

Kann man auch mehrere Antennen bzw Teilnehmer zusammen schlaten?
Also ein Empfänger und zwei oder drei Sender.. sollte ja dann über die 
pipe auswahl gehen wenn ich das richtig verstanden hab.

[Christian S. (roehrenvorheizer)]

Also ist die Funktionalität im Wesentlichen gegeben. Von da aus kann man 
weiter machen. Es fehlt also noch die Ausgabe des ganzen 32kByte langen 
Fifos, falls Paketlänge >1 bis 32 eingestellt ist.

Die Pipes dienen dazu, eine quasi-parallele Datenübertragung über 
mehrere logische Kanäle zwischen zwei Geräten herzustellen. Immerhin 
können diese Module Audio in CD-Qualität übertragen, zumindest was die 
Datenrate angeht.

Andere Geräte sollten mit anderen sinnvollen Adressen ausgestattet 
werden.

Ich habe das nie gebaucht und mir war es ohne das bereits kompliziert 
genug.


MfG

[Torsten M. (knoddelpusch)]

Hallo,

endlich bin ich mal wieder dazu gekommen etwas weiter zumachen.

Der Endplan von diesem Projekt ist eine Funkfernbedinung. Da würde mir 
eine Paketlänge von 16kByte genügen.

Als Payload habe ich noch die 32kByte stehen.

Ja die Ausgabe habe ich jetzt ja schon teils drin mit dem Hochzählen des 
Wertes. Vom Sender übertrage ich mir ja einen Wert der immer um 1 erhöt 
wird und schreibe diesen in payload[1].

Kann ich auch einen Wert vom Empfänger an den Sender Schicken und diesen 
dort auswerten. Sollt denk ich mal ja Funktionieren.

Ok jetzt gibt das mit den Pipes wieder was genaueres, dachte man kann 
darüber mit mehrere Senderen kommunizieren.

Mfg
Torsten

[NRF Tester (Gast)]

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.

[Torsten M. (knoddelpusch)]

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


Nein das ist natürlich nicht zuviel Verlangt (ich mach das meisten nur 
am Schluss). Das wäre dann bei meinem Nächsten beitrag gekommen (wird 
wahrscheinlich nicht jeder glauben).

Dann zieh ich es jetzt mal vor:

Hier an dieser Stelle ein ganz großes Dankeschön an die Helfenden und 
stark Unterstütztende Person die mir bei diesem Projekt geholfen haben.
Ein ganz besonderer Dank geht an den NRF Tester für dass Programm wo er 
erstellt hat und es uns Kostenlos zur Verfügunk stellt. Das ist auch 
nicht Selbstverständlich. Dankeschön

[Christian S. (roehrenvorheizer)]

"Da würde mir
eine Paketlänge von 16kByte genügen.

Als Payload habe ich noch die 32kByte stehen."

Solche Paketlängen wären mir auch lang genug. Damit könnte man ganze 
Flash- oder EEPROM-Inhalte übertragen... Sehr toll, daß es so ein Modul 
gibt, das das kann!


Nene, der Fehler kam von mir, sollte 32 Bytes heißen, die der Fifo groß 
ist. Wie konnte da nur das k zwischen rein kommen. Kopfschüttel.


mfg