Hallo alle zusammen, Ich habe ein Problem mit meinem RFM Modulen. Ich habe alles schön als Master Slave System mit 2 RFM Modulen implementiert und die Funkübertragung funktioniert bei kleinen Baudraten((0xC614) also etwas weniger als 19.2k) auch sehr stabil und zuverlässig. Der Master sendet kontinuierlich Daten an den Slave. Durch eine bestimmt Bitfolge kann der Master dem Slave erlauben ebenfalls Daten zu senden. Die Übertragung wird mit dem Rücksenden eines Acknowledge abgeschlossen immer abgeschlossen. Falls dies nicht geschieht (wenn z.B. die Checksumme beim Empfänger nicht übereingestimmt hat) werden im nächsten Zyklus die Daten einfach nochmal gesendet. Jetzt bin ich dabei meine Sende- und Empfangsbaudrate langsam hochzustellen. Sprich: (0xC611) oder (0xC605) Hierbei lässt der Empfänger jedoch öfters Interrupts über den nIRQ einfach aus. Dadurch werden nicht alle Daten gelesen! F0000TEK.JPG zeigt das normale Verhalten der Interrupte auf der Master (gelb) und der Slave (blau) Seite. Hier: Requestanfrage vom Master an den Slave welche vom Slave verneinend beantwortet wird (also Slave sendet keine "Nutzdaten" an den Master) Master sendet: 3 Präambeln, Sync Hi, Sync Low, 5 Datenbytes, 3 Präambeln 2 ms warten Slave antwortet mit: 3 Präambeln, Syc Hi, Sync Low, 5 Datenbytes, 3 Präambeln Bei der Erhöhung der Baudrate auf (0xC611) sieht es oft folgendermaßen aus. Bild F0001TEK.JPG und F0002TEK.JPG der Master empfängt nicht die vollständigen Datenbytes (Hier nur 4) Auffällig ist, dass das Auslesen der Bytes beim Master und beim Slave 2 Bytes immer zu spät erfolgt. d.h. z.B. Master sendet 3 Präambeln, Sync Hi, Sync Low, 1. Datenbyte, 2.Datenbyte, 3.Datenbyte und erst jetzt beginnt der Salve das erste Datenbyte zu lesen. (dargestellt durch die Interrupt) Kann es sein das ich durch das "zu späte" Auslesen bei hohen Baudraten ein Timing Problem bekomme und daher Interrupte vergessen werden? Welche Gründe kann es haben das der Empfänger (egal Master oder Slave) die Datenbytes erst 2 "Takte" später aus dem Fifo holt? Muss man den RFM FIFO Puffer bzw. die SPI dafür bestimmt konfigurieren? meine Config sieht folgendermaßen aus: RF12_receive_WRT_CMD(0x80D7); RF12_receive_WRT_CMD(0x82D9); RF12_receive_WRT_CMD(0xA640); RF12_receive_WRT_CMD(0xC611); RF12_receive_WRT_CMD(0x94A0); RF12_receive_WRT_CMD(0xC2AC); RF12_receive_WRT_CMD(0xCA81); RF12_receive_WRT_CMD(0xC483); RF12_receive_WRT_CMD(0x9850); RF12_receive_WRT_CMD(0xE000); RF12_receive_WRT_CMD(0xC800); RF12_receive_WRT_CMD(0xC400); RF12_receive_WRT_CMD(0xCA83); Standard config vom Pollin test Prog. Für Hilfe und Anregungen bin ich sehr dankbar! mfg Gerald
Hallo, dann muß was grundsätzliches nicht stimmen. Ich empfange voll transparent im IRQ mit 19200 auf U. Radigs Webserver und habe außer bei Störungen noch nie ein Byte verloren. Nach der Syncword werden die Daten in den FIFO geschoben. Der steht auf 8 Bit, der IRQ kommt also, sobald ein Byte komplett ist. Da die Verarbeitung bei mir in main() erst erfolgt, wenn die erwartete Anzahl Bytes im Buffer liegen, ist die IRQ auch kurz genug für höhere Raten, die brauch ich hier allerdings nicht. Präambel nach den Daten ist nutzlos, die 0xAA davor sind nur, damit der Empfänger AFC und AGC einstellen kann. http://www.avr.roehres-home.de/sensoren/index.html Ist leider alles sehr unaufgeräumt, vielleicht findest da trotzdem was. Gruß aus Berlin Michael
Danke für die schnell Antwort und den Link! Ich werde es mir mal anschauen. Vll finde ich was mir noch helfen könnte. Also die angestrebte Baudrate soll min. die 57.6 kBaud sein! Ich sollte von der Anwendung aber schon besser auf die 115.2kBaud gehen! Das der FIFO auf 8Bit steht habe ich auch im gesamten Programm durchgecheckt! nach jedem Senden mache ich: RF12_receive_WRT_CMD(0x82D9); RF12_receive_WRT_CMD(0xCA81); RF12_receive_WRT_CMD(0xCA83); von daher verstehe ich halt auch nicht wirklich warum der sich 2 Bytes mit dem Auslesen zeitlässt. Übrigens das Problem mit den verlorenen Interrupten und damit Bytes scheint nur in die Richtung zu bestehen, wenn der Slave auf den Master sendet. Und das verwirrt mich mal richtig! Wenn der nIRQ LOW wird, springe ich in die ISR und lese dann den FIFO mit (0xB000) in der ISR aus. Ist beim Master und Slave genau gleich. Der Interrupt wird schnell genug abgearbeit! Das kann man auch in den Bildern oben erkennen! Habs auch nochmal mit anderen Ausgängen getestet gehabt ob er wirklich rausspringt und sich nicht im Interrupt verläuft! Das hat alles gepasst! Von daher für mich unerklärlich ... Jiop danke zwecks der 3 Präambeln am Schluss! Die stammen noch vom Pollintest prog und werden sicherlich noch rausfliegen.
Mahlzeit, achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind. Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa) nachschieben. MfG
Hallo, Sauger schrieb: > Mahlzeit, > > achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind. Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig ausgelöst. > Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa) > nachschieben. Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er mit Senden auch fertig ist, also den wieder leeren Buffer meldet.
Hallo, Sauger schrieb: > Mahlzeit, > > achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind. Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig ausgelöst. > Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa) > nachschieben. Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er mit Senden auch fertig ist, also den wieder leeren Buffer meldet. @Gerald H. (elsuppus): 115kBaud sind zumindest ehrgeizig, die Reichweite dürfte merklich geringer werden bzw. die Empfangsbedingungen und die Einstellung vov Hub, Bandbreite usw. muß man wohl gut austesten. Man ist ja auch von den Störungen im Umfeld abhängig. Gruß aus Berlin Michael
Michael U. schrieb: > Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig > ausgelöst. nicht nur falsche Daten, das ganze RFM gerät außer Tritt. > Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er > mit Senden auch fertig ist, also den wieder leeren Buffer meldet. dann hat der Sender beim nächsten einschalten schon mal was zum senden, wenn die 0xaa raus sind kommt der nächste Interrupt und verlangt nach mehr (sozusagen als Starthilfe). MfG
Hallo, Sauger schrieb: > Michael U. schrieb: >> Bringt eigentlich nur falsche Daten, der IRQ wird ja trotzdem richtig >> ausgelöst. > > nicht nur falsche Daten, das ganze RFM gerät außer Tritt. Nicht unbedingt. Die interne Übernahme aus dem FIFO geht schief, das Kommando wird wie üblich mit vollem Speed gelesen und decodiert. Schon deshalb, wei er ja davor nicht weiß, daß der FIFO gelesen werden soll. >> Zu welchem Zweck? Wichtig ist nur, den Sender erst abzuschalten, wenn er >> mit Senden auch fertig ist, also den wieder leeren Buffer meldet. > > dann hat der Sender beim nächsten einschalten schon mal was zum senden, > wenn die 0xaa raus sind kommt der nächste Interrupt und verlangt nach > mehr (sozusagen als Starthilfe). Merk ich mir mal fpr den RFM12. Habe auf den Sendemodulen RFM02 drauf, die wollen sowieso anders bedient werden. Gruß aus Berlin Michael
Michael U. schrieb: > Nicht unbedingt. Die interne Übernahme aus dem FIFO geht schief, das > Kommando wird wie üblich mit vollem Speed gelesen und decodiert. Schon > deshalb, wei er ja davor nicht weiß, daß der FIFO gelesen werden soll. wenn der auf den RFM12 verbaute Chip (IA4420/1) auf Empfang geschaltet ist und das Empfangssignal abtastet, braucht er etwas Zeit, die nicht mehr zur Kommunikation auf der SPI-Schnittstelle zur Verfügung steht. Der IA4420 ist ein (mimosenhafter) Endlicher Automat (neudeutsch state machine) die entsprechend behandelt werden will. MfG
Hallo, Sauger schrieb: > Michael U. schrieb: >> Nicht unbedingt. Die interne Übernahme aus dem FIFO geht schief, das >> Kommando wird wie üblich mit vollem Speed gelesen und decodiert. Schon >> deshalb, wei er ja davor nicht weiß, daß der FIFO gelesen werden soll. > > wenn der auf den RFM12 verbaute Chip (IA4420/1) auf Empfang geschaltet > ist und das Empfangssignal abtastet, braucht er etwas Zeit, die nicht > mehr zur Kommunikation auf der SPI-Schnittstelle zur Verfügung steht. > Der IA4420 ist ein (mimosenhafter) Endlicher Automat (neudeutsch state > machine) die entsprechend behandelt werden will. > > MfG habe ich die Stelle im Datenblatt übersehen? Ich kenne nur den Hinweis, daß das Lesen des FIFO nur mit max. 2MHz erfolgen darf. Jedes andere Kommando kann ich ihm mit voller Geschwindigkeit schicken und das versteht er auch. Kann natürlich sein, daß ich da Glück hatte, weil mein SPI sowiso nur max. 4MHz schaffte. Gruß aus Berlin Michael
Hi, Danke für die Antworten! So, ich habe mittlerweile alles durchprobiert. Das Problem besteht noch immer. SPI-Takt liegt bei mir auf 1 MHz. Das kann nicht das Problem sein. @Sauger >Mahlzeit, >achte darauf das zum lesen das FIFOs max 2MHz SPI-Takt erlaubt sind. >Nach dem Senden, Sender abschalten und noch ein 0xaa (0xb8aa) >nachschieben. Habe es versucht eine B8AA nachgeschoben ... keine besserung! Wie meinst du das genau mit Sender abschalten? et = 0 ? Das mache ich! @Michael >Präambel nach den Daten ist nutzlos, die 0xAA davor sind nur, damit der >Empfänger AFC und AGC einstellen kann. Habe die Präamblen versucht rauszuwerfen. Leider geht es nicht komplett! Problem scheint meiner Meinung nach zu sein, dass er dann die letzten Bytes nicht mehr liest. Siehe Bild F0003TEK! Er fängt einfach zu spät an die Bytes zu lesen! Habe am ende es um ein Präambel reduziert (sprich nur noch 2) D.h. der Empfänger bekommt das letzte Datenbye auf der 2. Präambel vom Sender mit. Sprich auf dem letzten gesendeten byte. folgendes habe ebenfalls versucht: anstelle von: RF12_receive_WRT_CMD(0xCA81); RF12_receive_WRT_CMD(0xCA83); habe ich überall RF12_receive_WRT_CMD(0xCA11); RF12_receive_WRT_CMD(0xCA13); konfiguriert. der empfänger hat nach jeden bit eine nIRQ ausgelöst was auch passieren soll! Jedoch erst wieder nach dem 7. gesendeten Byte und nicht nach dem 5.! also ebenfalls 2 zu spät. Ich habe auf der Empfängerseite mir das Statusregister vor dem ersten empfangenbyte auslesen lassen. Wenn ich es richtig ausgelesen habe müsste FFOV = 0 gewesen sein! lese das Statusregister wiefolgt aus. teststatus = RF12_receive_WRT_CMD(0x0000); itoa(teststatus,text,10); uart_puts("\r\n teststatus:"); uart_puts(text); Das ganze wird dann im Windows rechner weider binär dargestellt! Wenn jeman eine besser variante weiß! immer her damit! das RSSI Bit scheint bei mir die ganze Zeit auf 1 zu stehen! Kann das noch ein Problem sein? Gescheite Antennen habe ich! Grüße Gerald
Moin, @ Gerald H. stell doch einfach mal dein Projekt als Quellcode in Compilierbarer Form ein. @ Michael U. Bei den älteren (<3.0) durfte man bei geöffnetem Empfänger (Präambel empfangen) erst nach dem Auslesen des FIFOs wieder neue Kommandos absetzen. Abschalten oder Umschalten auf senden in dieser Phase führt in fast allen Fällen zum Absturz. Ob neuere (>=3.0) dieses Problem noch haben kann Ich nicht sagen, die Routinen sind für die Alten ausgelegt und arbeiten auch mit den neuen. Die Dinger werden übrigens kommerziell in „Funkbirnen“ eingesetzt und ersetzen Bedienpulte in Förderanlagen (Hand-/Einrichtbetrieb). MfG
Hoi, >Bei den älteren (<3.0) durfte man bei geöffnetem Empfänger (Präambel >empfangen) erst nach dem Auslesen des FIFOs wieder neue Kommandos >absetzen. Habe Präambel nun auch mal richtig im Interrupt ausgelesen. Leider keine Besserung. >stell doch einfach mal dein Projekt als Quellcode in Compilierbarer Form >ein. Werde ich nun auch machen. Muss den Code noch ein bisschen aufbereiten sodass man den besser lesen kann. Grüße Gerald
Mahlzeit, Die Präambel kannst du nicht auslesen. Damit rastet der Empfänger seine PLL ein, um dann nach Empfang des Synchronwords das FIFO bis zum Sankt-Nimmerleins-Tag zu füllen. MfG
Moinsen, Die "Präambel" sende ich nochmal zum Schluss! Ich meine nicht die am Anfang zum einrasten. Sprich z.B einer Requestanfrage welche durch einen Timer nach einer bestimmten zeit aufgerufen wird. 3 Präambeln, Syc Hi, Sync Low, 5 Datenbytes, 2 Präambeln Die letzten Beiden Bytes lese ich beim Empfänger nicht mehr aus... Aber selbst wenn ich sie beim Empfänger auslese macht es keinen Unterschied. Wenn ich die nicht mitschicke funktioniert das ganze nicht mehr. Weil meiner Meinung nach halt die Interrupts zu spät kommen. Aber wäre cool wenn du es dir mal anschauen könntest! Danke Grüße Gerald
Mahlzeit, ohne den ganzen Code angeschaut zu haben: werfe alle "uart_puts" aus den ISRs raus, diese dauern zu lange und blockieren alles andere. Ein "FIFO voll" Interrupt vom RFM kann so verloren gehen. MfG
Hi, Danke erstmal. Das musste ich auch feststellen und vermeide dies schon. Wenn ich den Sender an habe ('a' übers Terminal gesendet habe) dann wird kein uart_puts aufgerufen ... es sei denn ich frage bewusst einen status über das terminal ab. Grüße Gerald
Nabend, Deine Quellen sind mir umfangreich um diese zu zerlegen. Du hast Post... MfG
Nachtrag, da fehlt mittendrinn ein zu, dass Ich hiermit nachliefere.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.