Assembler RFN12b an Tiny44 und Tiny2313 via USI

[Dirk]

Inzwischen ist das jetzt so durcheinander

Stimmt wird sonst zu unübersichtlich.

Ja für andere User ist es dann recht schwer, den Durchblick zu behalten, wenn man nicht ständig mit liest.

@dannyboy1994 Du hattest am Anfang Fehler im Code, das konnte dann nicht funktionieren. HardwareSPI mit USI sah doch gut aus und du hattest auch mal SoftwareSPI verwendet, das sah für mich auch in Ordnung aus. Ich hatte noch die Initialisierung im Verdacht, da würde ich noch einmal nach schauen. Ich schaue mir am Wochenende mal die Routine in 70 an.

 

[dannyboy1994]

Hallo Dirk. Das Problem ist das ich keinen durchblick durch die parameter habe:/ ich bring es ums sterben nicht zum laufen. Der Empfänger liefert den Fehler fifo lleer+ buffer underrun. ich treff den richtigen zeitpunkt um den fifo zu lesen nicht. Wenn ich mich nur mit der Amateurfunkthematik auskennen würde. Ich habe auch schon angeboten ein kleines gemeinschaftsprojekt daraus zu machen. Den wenn nur 1 die Hardware zum testen besitzt ist es in diesem fall sehr schwer eine lösung zu finden, in dem man sich 100mal durch das datenblatt kämpft. Wenn ich nur etwas mehr zeit hätte ab 9ten gehts wieder los mit arbeit. Bis dahin muss das RFM fasst laufen, denn dann wird es zeitlich so und so leider sehr eng. Wenn du möchtest kann cih dir gerne bei pollin 2 RFM module + 2 tinys bestellen und an deine adresse liefern lassen, dann wäre etwas unterstützung noch gegeben...

 

[Dirk]

Ich schaue mir das mit der Initialisierung noch mal an. Ich weiß allerdings nicht, wie schnell ich dazu komme. Hardware brauche ich erst mal nicht.

 

[avr_racer]

Der RFM muss erstmal analog über die digitale Seite eingestellt werden. Auf welcher Frequenz, Sendeleistung, Empfangsempfindlichkeit usw und sofort. Damit will ich sagen nur weil er mit der Betriebspannung versogt ist heißt es nicht das er sofort senden/empfangen kann.

Hier mal zwar Code in C aber da sind eindeutige CMD auf Seite 11 gelistet wie zu verfahren ist für den Transmitter.
Ab Seite 16 CMD gelistet für den Receiver.
http://www.hoperf.com/upload/rf/RF12_code.pdf

in DEUTSCH das verstehts sich gleich ganz anders als did Englisch
http://www.mikrocontroller.net/articles/RFM12
Zitat:
"Also: Im Allgemeinen ja, bei Mondfahrzeugen oder Omas Fernbedienung in 'zig Kilometer Entfernung würde ich davon erst mal abraten."

Auch dein Problem mit dem "underrun" ist dort aufgeführt!!!!

Die Grundkommandos hast du ja schon. Manchmal halt nicht so einfach, als BSP beim DS18x20 habe ich auch fast 3Monate gebraucht nur um es mit der ID-Adressierung hinzubekommen.

 

[dannyboy1994]

@avr_racer habe ich nun bereits das xte mal gelsen nun folgt nocheinmal der Versuch, aber erst wenn ich wieder etwas nüchterner bin frohes neues an alle !
PS: und da wolltest du mir den DS18 schmackhaft machen xD dann brauche ich dafür warscheinlich ein halbes jahr

 

[fredred]

Hallo dannyboy,

Habe mich sehr lange mit RFM12B beschäftigt.
Einige Funkübertragungen laufen schon seit Jahren zuverlässig.
Für Sender und Empfänger nutze ich zwar ATMega8 ist aber nicht das Problem Er wohl das ich alles mit Bascom programmiere.
Die viele Empfangsdaten schiebe ich per UART in ein ATMega644p. Für Berechnungen, Auswertungen, Anzeige usw.
Habe Thema nur grob gelesen aber eins ist ersichtlich die rfninit: sind falsch. Der 12b kann optimal auf Umgebung und Leistung eingestellt werden die Grundeinstellungen müssen aber stimmen.
Eine eigenwillige aber sehr zu verlässliche Variante sieht so aus.

Sender:

Data &H80E7% 'Configurations Settings Command
Data &H82DA% 'Power Management Command
Data &HA708% 'Frequency Setting Command (HA708 = 869.0MHz)
Data &HC647% 'Data Rate Command
Data &H90C0% 'Receiver Control Command
Data &HC2AD% 'Data Filter Command
Data &HCA81% 'FIFO und Reset Mode Command
Data &HCA83% 'FIFO und Enable Mode Command
Data &HCED4% 'Synchron Pattern Command
Data &HC400% 'Automatic Frequecy Control Command
Data &H9850% 'TX Control Command
Data &HCC17% 'PLL Settings Command
Data &HE000% 'Wake-Up Timer Command
Data &HC800% 'Low Duty-Cycle Command
Data &HC000% 'Low Battery Detect & µC CLK Command Data 0% 'ende initialisierung

Empfänger:

Data &H80E7% 'Configurations Settings Command
Data &H8299% 'Power Management Command
Data &HA708% 'Frequency Setting Command (HA708 = 869,0MHz)
Data &HC647% 'Data Rate Command
Data &H94A0% 'Receiver Control Command
Data &HC2AD% 'Data Filter Command
Data &HCA81% 'FIFO und Reset Mode Command
Data &HCA83% 'FIFO und Enable Mode Command
Data &HCED4% 'Synchron Pattern Command
Data &HC483% 'Automatic Frequecy Control Command (AFC ist an)
Data &H9850% 'TX Control Command
Data &HCC17% 'PLL Settings Command
Data &HE000% 'Wake-Up Timer Command (nicht"schlafen"legen)
Data &HC800% 'Low Duty-Cycle Command
Data &HC000% 'Low Battery Detect & µC CLK Command Data 0% ' ende initialisierung


Kenne deine Beschaltung der RFM12B nicht, da gibt es aber auch ein paar Kleinigkeiten zu beachten. Hilfreich ist auch eine LED am Empfänger die Empfang bestätigt.
Wie geschrieben Code in Bascom oder auch mein ganzes Projekt kann ich einstellen.
Gesendet werden in Sekundentakt 2 Temperaturmessungen, 3x Digitalwerte und 6x Analogwerte.
Im Paket ist aber noch allerhand Platz.

Gruß

 

[fredred]

Hallo dannyboy,
nun habe ich gelesen, dass du sehr viel Ausdauer hast um die Funkdinger zu verstehen.
Muss sagen auch das Datenblatt ist widersprüchlich und erst recht wenn jemand wie ich kein Englisch kann. Aber „Impulsdiagramme“ lesen kann ich alter Mann noch sehr gut(wenn groß genug abgebildet).
Scheint immer noch Vorteilhaft zu sein.
Könnte auf der schnelle noch zwei Module aufbauen(36x80mm) VCC 3,3 Volt und Programmiert wie oben erwähnt. Als Beispiel noch den Empfängercode vorab, damit du siehst, wie einfach es ist ein Datenpaket mit UART als String an einem anderem Controller weiter zu geben.
Ja wer Assembler kann für den ist doch BASCOM das kleine Ein mal Eins. Natürlich wenn Code erklärt ist.
Hoffe ich hab es halbwegs hinbekommen.

Wenn Interesse möchte ich nur die Material- Portokosten erstattet haben.

Gruß

 

[dannyboy1994]

Hallo @fredred Danke das du dich hier ebenfalls eingeklinckt hast. Ja das Datenblatt widerspricht sich teilweise slebst ein wenig. danke für deinen init werte und dein bascom code. Ich werde versuchen morgen zu einem ausgiebigen test zu kommen. Heute ist es leider schon zu spät für mich. Codetechnisch ist post 70 mein letzter stand. Dieser funktionierte 50/50


Wie ist das mit der vorgehensweise beim Empfang(empfänger an....warten...daten auslesen...empfänger aus empfänger an???)? wie weis ich wann daten vorhanden sind, wann muss ich auf den SDO pin(high level) warten? Das vorgehen beim senden von 3x 0xAA danach 2D und 0xD4 als synchword und dann das nutzdatenbyte stimmt denke ich mal.

Welche commandos müsste ich dem RFM für z.B. vollgende unterfunktionen übergeben
RXEN: (Empfänger einschalten mit FIFO und auf Daten warten)
RXRESETFIFO reinitialisieren um wieder das synchword zu erkennen)
TXEN: (Sender an)
RFMSTBY RFM in den minimalen stromsparendsten Modus versetzen)
RFMWAKEUPDas RFM wieder aus diesem Modus in Betriebsbereitschaft zu bringen)

Wenn der Sender aktiviert wird, ist der Empfänger automatisch deaktiviert oder?
bzw andersrum.

 

[dannyboy1994]

Meine beschaltung sieht wie folgt aus:
NSEL- an Ausgang des AVR
SDI - an Ausgang des AVR
SDO- an Eingang des AVR
SCK- an Ausgang des AVR

DATA pin vom RFM üver 10kpullup an VCC

VCC-GND der Schaltung +3V

wobei interessant zu wissen wäre ob das RFM es mit 2,2 V auch noch macht. Der AVR schaffts definitiv und ich hab hier so einen schönen NiMH Akku gefunden in miniaturausgabe. 2,6V 400mAh


Das ist ein sehr nettes angebot, aber der selbstbaufaktor is auch ein anreiz der sache. Desweiteren denke ich das das ganze noch wesentlich kompakter werden muss(zumindest der sender) um in das gehäuße zu passen, mit akku und eventueller zusätzlichen sensoren.

 

[dannyboy1994]

Also wie versprocvhen einmal ein testbericht des heutigen nachmittags.
Di programme sehen wie folgt aus:
Sender


CodeBox Assembler

.include "tn85def.inc"

.org 0x0000
rjmp reset
;ANSCHLÜSSE UND REGISTER
.def temp1=r16
.def temp2=r17
.def temp3=r18
.def counter = r19

.def lsb = r23
.def msb = r24

.equ SS = PB3
.equ NIRQ = PB4
.equ SDO = PB0
.equ SDI = PB1
.equ SCK = PB2
.equ rfmpin = pinb
.equ rfmport= portb
.equ rfmddr = ddrb
.equ XTAL = 1000000
.org 0x0010
reset:
ldi temp1, low(ramend)
out spl, temp1
ldi temp1, high(ramend)
out sph, temp1
ldi temp1, (1<<SDI)|(1<<SS)|(1<<SCK)
out rfmddr, temp1
sbi rfmport, SS           ;Nsel auf high
rcall delay100ms

main:
rcall RFMinittrans

loop:
ldi lsb, 0xC7
rcall sendbyte
rcall delay100ms
rjmp loop







.include "AVRRFM12B_USIV3.asm"
.include "stddelay.inc"

Empfänger:


CodeBox Assembler

.include "tn44def.inc"

.org 0x0000
rjmp reset
;ANSCHLÜSSE UND REGISTER
.def temp1=r16
.def temp2=r17
.def temp3=r18
.def counter = r19

.def lsb = r23
.def msb = r24

.equ SS = Pa3
.equ NIRQ = PB2
.equ SDO = Pa6
.equ SDI = Pa5
.equ SCK = Pa4
.equ LED = PB1
.equ rfmpin = pina
.equ rfmport= porta
.equ rfmddr = ddra
.equ XTAL = 1000000
.org 0x0020
reset:
ldi temp1, low(ramend)
out spl, temp1
ldi temp1, high(ramend)
out sph, temp1
ldi temp1, (1<<SDI)|(1<<SS)|(1<<SCK)
out rfmddr, temp1
sbi rfmport, SS           ;Nsel auf high
rcall delay100ms


main:
rcall rfminitrec
rcall delay1ms
rcall Fifo_reset



loop:
sbic rfmpin,nirq           ;wenn nirq low
rjmp loop
******!********"******!********"******!********"******!********"******!********"******!********"******!********"******!********"
;Daten vorhanden
rcall readFIFO
rcall Fifo_reset
cpi lsb, 0xC7
breq ja
rjmp loop



ja:
sbi ddrb, LED
sbi portb, LED
rcall delay100ms
cbi portb, LED
rcall readstatus

ret

.include "AVRRFM12B_USIV3.asm"

und die routine


CodeBox Assembler

;*******************************ACHTUNG*********ACHTUNG!!!!!!!**********
;Die routine SPI4RFM12 verändert das msb und lsb
;Beim senden von mehreren Datenbytes muss das MSB stehts neu geladen werden!
;
;

RFMinitrec:           ;INIT FÜR EMPFÄNGER
ldi msb, 0x80
ldi lsb, 0xE7
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0x82
ldi lsb, 0x99
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xA7
ldi lsb ,0x08
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC6
ldi lsb, 0x47
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0x94
ldi lsb, 0xA0
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC2
ldi lsb, 0xAD
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCA
ldi lsb, 0x81
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCA
ldi lsb ,0x83
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCE
ldi lsb, 0xD4
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC4
ldi lsb, 0x83
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0x98
ldi lsb ,0x50
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCC
ldi lsb, 0x17
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xE0
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC8
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC0
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ret
RFMinittrans:           ;INIT FÜR SENDER
ldi msb, 0x80
ldi lsb, 0xE7
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0x82
ldi lsb, 0xDA
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xA7
ldi lsb ,0x08
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC6
ldi lsb, 0x47
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0x90
ldi lsb, 0xC0
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC2
ldi lsb, 0xAD
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCA
ldi lsb, 0x81
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCA
ldi lsb ,0x83
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCE
ldi lsb, 0xD4
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC4
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0x98
ldi lsb ,0x50
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xCc
ldi lsb, 0x17
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xE0
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC8
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ldi msb, 0xC0
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12
ret

;***************************************RESET FIFO******************************
Fifo_reset:
ldi msb, 0xca
ldi lsb, 0x81
rcall delay1ms
rcall SPI4RFM12


ldi msb, 0xca
ldi lsb, 0x83
rcall delay1ms
rcall SPI4RFM12
ret


RXEN:
ldi msb, 0x82
ldi lsb, 0x99
rcall delay1ms
rcall SPI4RFM12


ldi msb, 0x94
ldi lsb, 0xA0
rcall delay1ms
rcall SPI4RFM12

ldi msb, 0xC4
ldi lsb, 0x83
rcall delay1ms
rcall SPI4RFM12




ret

TXEN:
ldi msb, 0x82
ldi lsb, 0xDA
rcall delay1ms
rcall SPI4RFM12

ldi msb, 0x90
ldi lsb, 0xC0
rcall delay1ms
rcall SPI4RFM12


ldi msb, 0xC4
ldi lsb, 0x00
rcall delay1ms
rcall SPI4RFM12

ret






;*******************************readFIFO*******************************
;Daten sollten anschließend in lsb stehen
;Daten sind im FIFO vorhanden wen der Status 0x8000 entspricht also das bit 15 gesetzt ist
readFIFO:
;ldi counter, 100
schleife:               ;sind daten vorhanden?
;dec counter
;breq nix               ;100 mal keine Daten?? dann wieder ins Hauptprogramm
;rcall readstatus
;sbrs msb, 7               ;wenn daten vorhanden weiter machen
;rjmp schleife
ldi msb, 0xB0               ;Befehl für das lesen des FIFOS
ldi lsb, 0x00
rcall SPI4RFM12               ;datenbyte in lsb
ret
nix:
ret
;***************************************readstatus************************
;Status muss in msb/lsb stehen
readstatus:               ;Muss ebenfalls funktionieren
ldi msb, 0x00
ldi lsb, 0x00
rcall SPI4RFM12
ret
;************************************sendbyte********************************
;SENDET BYTE AUS LSB
;Verändert:Counter, LSB, MSB
sendbyte:
push lsb
ldi msb, 0xB0               ;Msb mit sendebefehl füllen
ldi counter, 3
bla:                   ;3 mal preambel senden 0xAA
ldi msb, 0xB0               ;Msb mit sendebefehl füllen
ldi lsb, 0xAA
rcall SPI4RFM12
rcall delay1ms
dec counter
brne bla
ldi msb, 0xB0               ;Msb mit sendebefehl füllen
ldi lsb, 0x2D               ;Synclow
rcall SPI4RFM12
rcall delay1ms
ldi msb, 0xB0               ;Msb mit sendebefehl füllen
ldi lsb, 0xD4               ;Synchigh
rcall SPI4RFM12
rcall delay1ms
ldi msb, 0xB0               ;Msb mit sendebefehl füllen
pop lsb
rcall SPI4RFM12               ;Datenbyte
ret                   ;BYTE müsste übertragen sein
;****************************UNTERROUTINEN*********************************
SPI4RFM12:               ;Getestet mit logic. Funktioniert
cbi rfmport, SS               ;Sendet msb+lsb.Antwort in msb/lsb
wait:                   ;warten AUF SDO=LOW
sbic rfmpin, sdo
rjmp wait
mov temp1, msb               ;MSB
rcall SPITransfer
mov msb, temp1
mov temp1, lsb               ;LSB
rcall SPITransfer
mov lsb, temp1
nop nop nop
sbi rfmport, SS
ret
SPITransfer:
out    USIDR,temp1
ldi    r16,(1<<USIWM0)|(0<<USICS0)|(1<<USITC)
ldi    r17,(1<<USIWM0)|(0<<USICS0)|(1<<USITC)|(1<<USICLK)
out    USICR,r16 ; MSB
out    USICR,r17
out    USICR,r16
out    USICR,r17
out    USICR,r16
out    USICR,r17
out    USICR,r16
out    USICR,r17
out    USICR,r16
out    USICR,r17
out    USICR,r16
out    USICR,r17
out    USICR,r16
out    USICR,r17
out    USICR,r16 ; LSB
out    USICR,r17
in     temp1,USIDR
ret
.include "stddelay.inc"

Der logikanalyzer zeigt das der sender mit den werten aus der routine inittialisiert wird. Danach folgt einen pause und er erhält jeweils 3mal preambel synchword Datenbyte. Einen Antwort des Moduls erhalte ich hierbei nicht( ist denke ich auch so angedacht vom hersteller)

Das Empfänger Modul wird initialisiert mit RFMinitrec danach folgt reset FIFO ich erhalte den Inhalt des Statusregisters als 0x4000 beim ersten auslesen danach 0x0000

Danach wartet das Programm bis Nirq low wird (was meines erachtens signalisiert das Daten im FIFO bereit stehen). Das Problem ist das Nirq immer low ist, aber das Programm trotzdem nicht über den Punkt welche oben mit "******!********" im Code markiert ist hinaus kommt. Es wird also nie in die routine readFIFO gesprungen, obwohl nirq immer low ist.

PS: Abstand der Module ca 20 cm. Auch eine näherung bringt nichts! Ich hoffe das ich nicht wieder vor dem problem sitze, obwohl es klar erkenntlich ist.

 

[LotadaC]

Hallo,

im Code vom ATtiny44 definierst Du in Zeile 15 nIRQ=PB2(=2).
In Zeile 20 rfmpin=PINA(=0x19).

Ist nIRQ an A2 oder B2 angeschlossen - im Code prüfst Du effektiv auf A2.

Wenn das geprüfte Bit clear ist, überspringt SBIC den jump to Loop...
Hast Du das gelesen?

Bei Interruptbetrieb ist darauf zu achten, dass wirklich auf jeden Interrupt reagiert wird. Solange ein Interrupt nicht behandelt wird bleibt nIRQ auf LOW! Durch das Lesen des Statusregisters können alle Interrupts ausser FFIT und RGIT "gelöscht" werden. Für FFIT ist das FIFO zu lesen und für RGIT das TxRegister zu beschreiben.

Quelle: Mikrocontroller.net

 

[dannyboy1994]

Nirq hängt an PB2 so weit ich es jetzt gerade im kopf habe. Ok das ist schon einmal ein Fehler. Das erklärt mir aber noch nicht warum nirq dauerhaft low bleibt. zur vorsorge lese ich den status regelmäßig aus und versuche den FIFO zu lesen. Ich werde das mal ändern und morgen früh testen.
PS: Ist NIRQ open Drain? Benötigt er evtl einen externen Pullup 10k gegen VCC

 

[LotadaC]

Das erklärt mir aber noch nicht warum nirq dauerhaft low bleibt.

Woher weißt Du das, wenn Du den falschen Pin abfragst? Direkt gemessen?
Laut dem Zitat oben ist nIRQ low, genau dann wenn mindestens ein IRQ offen ist. IRQs setzt Du durch lesen des Statusregisters, auslesen des FIFO, beschreiben des TxRegisters zurück.

Welcher IRQ wird denn dann im RFM-SREG gemeldet? Immer noch FFIT? Auch, wenn Du direkt nach dem FIFO-auslesen das SREG liest?

 

[dannyboy1994]

Nirq wurde mit LA nebenbei mitgelesen und ist immer low. egal ob status ausgelesen wurde, fifo gelesen wurde oder das tx register(wenn auch sinnlos in diesem fall) beschrieben wurde. Den status lese ich auch nur vom LA ab dar das ganze bis jetzt ohne USART läuft

 

[dannyboy1994]

Angenehmen Feiertag euch allen. Ich habe das Programm abgeändert und NSel via Pullup 8k2 gegen VCC beschalten. Das RFM spuckt als status immer wieder 0x0200 (FIFO empty) und 0x0220 (FIFO empty+afc Toggle) aus. Nirq geht nicht mehr auf low. es werden keine Daten empfangen. Kann es sein das bei der init zu viel wert auf Richtigkeit der Daten gelegt wird? Das man testhalber das ganze auf fast stellen sollte? Oder kann es sein das 20cm abstand zu wenig sind und der RFM "übersteuert"?

 

[fredred]

Oder kann es sein das 20cm abstand zu wenig sind und der RFM "übersteuert"?

Na klar.
Sieht ja so aus dass das Rauschen als Nutzsignal einrastet.
Deshalb auch die Einstellmöglichkeiten z.B. Verstärkung absenken und AFC aus.
Also an Bedingungen anpassen.
Wenn nIRQ genutzt wird empfehle ich ein 100p von Pin4 auf GND zu schalten. Keinen Widerstand.
Ja dann sollte man auch in der IRQ das Fifo File zurücksetzen(0xCA81) und wieder aktivieren(0xCA839) und eventuell anstehende Interrupt löschen.
Wichtig ist halt immer erst mal zu wissen ob überhaupt ein Nutzsignal ankommt.
Hatte damals einfach ein String mit einer länge von 10 Byte gesendet und am Empfänger diese gezählt. Hat der FIFO 10 Byte ausgespuckt war ich sicher Sender und Empfänger sind ein Paar und lieben sich.
Der Inhalt war erst mal nebensächlich.

Gruß

 

[dannyboy1994]

Ich lese das ganze im mom hauptsächlich mit dem LA am PC mit, dar ich erster Linie einmal erreiche. Wollte das der Empfänger das rein kriegt was gesendet wird. Könnte es also helfen LNA Gain einmal auf -20dB zu stellen um weniger Müll aus der Umgebung zu fangen. Die genaue bedeutung von AFC toggle is mir auch noch etwas schleierhaft. Den fifo aus und wieder anzuschalten ist doch in diesem Fall nicht nötig, oder? Denn das sync-muster wurde ja bis dahin noch nicht erkannt. Oder lese ich das richtig herraus, das afc einrastet wenn ein sinnvolles bit empfangen wurde. Kann es passieren das er aus dem rauschen sich iwie die synchbszes einfängt? Ich Bau das ganze Empfänger zeug mal wieder auf den 2313 um. Dann lass ich mir die Werte gleich noch schön per usart ausgeben.

 

[dannyboy1994]

Hallo Leute. Also der Aktuelle Stand ist folgendermaßen und ich dreh jetzt bald am rad.

Der sender bekommt die richtig4en signale vom mikro
der empfänger ebenfalls wenn ich status lese oder äühnliches
Nur entweder sendet der sender nicht oder der empfänger empfängt nichts...Nirq des empfängers wird niemals low. zieh ich es per hand auf low ließt der AVR den Fifo und bekommt 0x00 zurück.