Sammelbestellung Funkmodule?

Der Burggraben wird langsam voll.

Doch! Die Fehlerrate steigt bei gleicher Sendeleistung. Die berühmten Kurven und Shannon.

Es kann sein, daß deine Frames so kurz sind, das du im Bereich sehr hoher Wahrscheinlichkeit für einen fehlerfreien Empfang geblieben bist. Also keine wahrnehmbaren Fehler auftraten.

Das ist der Unterschied zwischen digitalen und analogen Denken. Oder Lotto spielen: 1x im Leben gespielt und gleich einen Sechser gemacht :-)

Buggy?

Kontrolliere mal die Versorgungsspannung! Drähte übers Modul liegend?

- Henry

--
www.ehydra.dyndns.info

Naja. Ein einfach bedienbarer Chip sieht anders aus. Das schließt vermutlich viele Bastler einfach vom Spiel aus.

Wurde wohl unter microcontroller.net angesprochen.

Stimmt!!!!!!

Äh. Die synchronisieren ständig weiter anhand der Daten. Was ist da vorgeschrieben? Aufpassen!!! NRZ möglich oder Manchester oder was?

- Henry

--
www.ehydra.dyndns.info

DAs ist mir klar, aber das Verhalten bei mir macht keinen Unterschied.

Noe..da steckt wohl eine gewisse Logik drin. Da FFIT so als erstes kommt kann man es schnell als Statusbit gebrauchen, aber harmoniert halt nicht besonders mit Hardware-SPI.

Einmal 3.3V frisch aus dem Palm, und einmal 5V auf meinem M16C-Board. Daran gibt es sicherlich nichts auszusetzen. Und natuerlich mit 100nF am Modul.

Nein. Ich habe aber ein Modul stehend auf ein 14pol IC-Sockel geloetet. Die Antenne natuerlich nicht!

Olaf

Olaf Kaluza schrieb:

Wie kommst Du auf 18 Bit? Schau Dir im Datenblatt mal die Grafik zu "15. Status Read Command" an. Es sind 16 Bits. Und man kann halt im Anschluss durch weitere Clock-Pulse noch den FIFO-Inhalt auslesen.

Nö, das ist das erste Bit. Es ist halt so, dass Daten bei einer steigenden Clock-Flanke übernommen werden. D.h. Dein erstes Bit muss bei der ersten steigenden Flanke bereits anliegen, ebenso wird das erste Bit von Chip (FFIT/RGIT) ebenfalls vor der ersten steigenden Flanke bereitgestellt.

Ist da evtl. eine zu große Pause zwischen Präambel+Sync und den Nutzdaten? Mir ist nämlich auch noch nicht ganz klar, was der Chip sendet, wenn die TX-Register leer laufen.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Olaf Kaluza schrieb:

Die synchronisieren sich mit Hilfe der Bitflanken in den Nutzdaten. Kritisch dürften also vor allem lange 0- oder 1-Folgen sein. Iirc ist im Datenblatt auch eine Formel zur maximal zulässigen Abweichung zwischen Sender- und Empfängerbitrate in Abhängigkeit von der Länge dieser Folgen.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Ich hab die Clockimpulse in der Grafik von 0 bis 17 gezaehlt.

Mit anderen Worten wenn man alles lesen will sind es

18Bit.

Aeh...moment mal...ich dachte es handelt sich bei den FO bits um ein Register welches den Fuellstand der Fifo angibt. Aber wenn da bereits die Fifodaten selber rauskommen dann has du natuerlich recht.

Nein. Da war Bloedheit im Hirn des Programmierer. [schaem] Ich hatte uebersehen das die beim berechnen der Baudrate von kBaud ausgehen und immer brav alles in Baud gerechnet.

Allerdings ist mir eines immer noch nicht ganz klar. Wenn ich das richtig sehe dann bekommt man mit 0xC67f die niedrigst denkbare Baudrate. Und das sind 2.694kBaud. Wie kommen die dann auf angebliche Baudraten von 600Baud?

Dann wird wohl das Register leer laufen, er sendet immer nur 0 oder 1 und der Empfaenger verliert seinen sync.

Olaf

Olaf Kaluza schrieb:

Es sind in der Tat die FIFO-Daten. Den FIFO-Füllstand kann man afaik nicht auslesen. Man wird nur via FFIT informiert, dass der gesetzte Schwellwert überschritten ist.

Das CS-Bit aktiviert noch einen zusätzlichen Vorteiler durch 8. Damit kommt man theoretisch (mit 0xC6FF) bis auf ca. 337 bit/s herunter. Aber der digitale Filter im Empfänger ist erst ab 600 bit/s (= 0xC6C7) spezifiziert.

CU Christian PS: Geht es denn jetzt bei Dir?

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Nein...momentaner Stand:

SendeDaten: 01 01 01 01 80 80 80 80 f0 f0 f0 f0 0f 0f 0f 0f

Empfang: C1 81 C1 C1 E0 E0 E0 E0 fc fc fc fc cf 8f cf cf

Wie man sieht, die einsen kommen alle durch, aber er hat Probleme seine Nullen rauszugeben.

Aktuelle Arbeitshypothese, ich hab noch irgendein PullupWiderstand am Dragonball aktiv und das Modul ist zu schwaechlich um dagegen anzukommen. Muss ich mir gleich mal anschauen...

Olaf

JAAHAHAHA....es geht!

Ursache: Ich hatte die Routinen zum ansprechen des IO-Port im Palmpilot vor vielen Jahren geschrieben und es hat auch immer funktioniert.

Als ich die Sache gerade durchgeschaut habe ist mir aufgefallen das die Funktion zum auslesen von GPIO2/PM7-Dragonball das gelesene invertiert. Und das macht sie deshalb weil bei meinem PalmProf im Gegensatz zu den fruehen 5000er noch ein Transistor vor dem Port haengt.

Das sieht dann also so aus:

Pullup im Dragonball | E--------PM7--+ RF12-SDO-------330R--------B C | | GND

Tja und das schafft der arme RF12 nicht mehr schnell genug zu treiben. Ich hab den Transistor jetzt extrahiert und invertiere nicht mehr und alles laeuft super.

Da vermutet man die schlimmsten Programmierprobleme und das ist es nur ein doofer Schaltungsfehler der seine Wurzeln 10Jahre in der Vergangenheit hat.

Olaf