MaWin schrieb:
> Setz dich also lieber fuer weniger Behinderungen durch Patente ein,
> wenn du hier Fortschritt sehen willst, denn Siemens & Co halten den
> Fortschritt durch ihr Patentgebaren massiv auf. Die einzigen, die
> davon nicht behindert werden, sie die, die eh drauf scheissen, die
> Chinesen.
>
Sobald die Chinesen ihre Steinzeit verlassen haben, werden die gegen
jeden und alles klagen. Du wirst sehen!
MaWin schrieb:
> "Henry Kiefer" <ehydra news 20070423@arcor.de> schrieb im
Newsbeitrag
> news:47add46b$0$2297$9b4e6d93@newsspool4.arcor-online.net...
>> Sobald die Chinesen ihre Steinzeit verlassen haben, werden die gegen
jeden und
>> alles klagen. Du wirst sehen!
>
>
> Dann wird dort halt das Wirtschaftswachstum zusammenbrechen,
> und stattdessen wird in Afrika oder wo sonst auf Patente geschissen wird,
> das Wirtschaftswachstum schwindelerregende Hoehen aufweisen.
>
> Es gibt eine KLARE Korrelation zwsichen Patenten und wirtschaftlicher
> Stagnation.
Das mag sein. Wie sieht denn deine Alternative zu Patenten aus?
horst-d.winzler schrieb:
> Henry Kiefer schrieb:
>> MaWin schrieb:
>
>> Das mag sein. Wie sieht denn deine Alternative zu Patenten aus?
>>
>
> Betriebsgeheimnis, "Intelligente" Module. Wird von vielen
Unternehmen
> bereits mit Erfolg verfolgt ;-)
>
MaWin schrieb:
> "Henry Kiefer" <ehydra news 20070423@arcor.de> schrieb im
Newsbeitrag
> news:47add8f5$0$381$9b4e6d93@newsspool2.arcor-online.net...
>> Das mag sein. Wie sieht denn deine Alternative zu Patenten aus?
>
>
> Das Wettbewerbsrecht, hab ich hier schon mehrmals ausgefuehrt.
Michael Eggert schrieb:
> Michael Eggert <m.eggert.nul@web.de> wrote:
>
>> Nun die schlechte: Sie haben sich die erste Fuhre der
"reparierten"
>> RFM12B (500mW) nochmal genauer angeschaut und dann entschieden, die
> ^^^^^^
>> alle nochmal neu zu bauen und "in 10 Tagen" zu schicken.
>
> RFM12BP meinte ich natürlich...
In den ersten drei Tagen werden aber erstmal die SMD-Bauteile abgelötet...
Michael Eggert schrieb:
> Zugegeben, die RFM12BP sind wohl recht neu, das Datenblatt ist vom
> Oktober - aber ich kann doch wohl unmöglich der erste sein, der die
> Dinger auch haben will!?
>
Vielleicht stapeln sie etwas hoch und müssen erst in der Nachbarklitsche
einige Mitarbeiter anheuern. Danach gehen die dann wieder Hähnchen
grillen...
Michael Eggert schrieb:
> Moin!
>
> So, die ersten 100 Päckchen sind raus...
> Wer schon mit dabei ist, hat ne Mail.
>
> Montag kommt geht dann noch ein Stapel auf die Reise
> und dann fehlen nur noch die mit RFB12BP und HP03S/M.
> Das wird dann wohl nächstes Jahr...
>
Ich hoffe du hast die auch alle getestet. Ich habe da jetzt so meine
Befürchtungen...
Michael Eggert schrieb:
> Henry Kiefer <ehydra news 20070423@arcor.de> wrote:
>
> Moin!
>
>> Ich hoffe du hast die auch alle getestet.
>
> Natürlich! Jedem Modul liegt ein 5-seitiges Spec-Sheet incl.
> DNA-Analyse des Chinesen bei, der den Kram zusammenlöten musste.
>
Christian Zietz schrieb:
> Ich schrieb:
>
>> Hat sich hier eigentlich schon jemand fundierte Gedanken über
eine zu
>> den 868-MHz-Modulen passende Antenne gemacht?
>
> So, nachdem ich zwei Module mal eingebaut und die nötige Software
> geschrieben habe, kann ich sagen: Mit einem Stück Draht (ca. lambda/4
> lang) als Antenne funktionieren die Module für meinen Zweck gut
genug.
Naja. Wenns billig und einfach sein soll, geht eh nur ein Stück Draht
als Antenne. Du kannst ne Teleskopantenne benutzen. Abgleich dann
einfach durch passendes Längeneinstellen.
Für einen Reichweitentest sollte man aus dem Nahfeld heraugehen und am
Empfänger dann auf maximalen Störabstand schauen.
Soweit ich mich erinnere, haben die Chips auch eine automatische
Antennenanpassung. Dann würde ne ungefähre Länge des Drahtes
einfach
reichen.
>
> Dafür habe ich noch eine Frage: Weiß jemand, was es mit dem DQD
(Data
> Quality Detector) auf sich hat bzw. wie der genau funktioniert und was
> der einstellbare Threshold bedeutet? Aus dem Datenblatt werde ich an der
> Stelle nicht schlau.
DQD ist nichts anderes als der Störabstandsmesser. Einfache messen nur
die Feldstärke, bessere messen nach dem Datendemodulator - da ist es
genauer.
Der Threshold setzt einfach nur die Grenze für deine gewünschte
Fehlerfreiheit der Daten. Typischerweise steuert man damit den Wakeup
eines Microcontrollers.
Genaueres kann ich hier nicht sagen, da ich die Datenblätter noch nicht
gelesen habe.
Christian Zietz schrieb:
> Henry Kiefer schrieb:
>
>> DQD ist nichts anderes als der Störabstandsmesser. Einfache
messen nur
>> die Feldstärke, bessere messen nach dem Datendemodulator - da
ist es
>> genauer.
>
> Soweit ist mir das klar. RSSI ist die Feldstärke, DQD ist irgendein
Maß
> für die Empfangsqualität im Basisband (lt. Blockschaltbild vor
dem
> I/Q-Demodulator). Nur wie dieses Maß bestimmt wird und welcher
> Thresholdwert folglich sinnvoll ist, kann ich aus dem Datenblatt nicht
> heraus lesen.
>
Ohne jetzt das Datenblatt gelesen zu haben: Warum willst du es genau
wissen? Es reicht doch wenn du weißt, das es stetige Werte sind.
Christian Zietz schrieb:
> Henry Kiefer schrieb:
>
>> Ohne jetzt das Datenblatt gelesen zu haben:
>
> Darum suche ich ja jemanden, der es getan hat und versteht, was da zum
> DQD gesagt wird: "The [DQD] is based on counting the spikes on the
> unfiltered received data." (Welche Spikes?) und "To let the DQD
report
> good signal quality the threshold parameter should be less than 4 in
> the case where the bit-rate is close to the deviation. At higher
> deviation/bit-rate settings higher threshold parameter settings can
> report good signal quality as well."
Gib mir mal den direkten Link. Ich lese es jetzt durch.
>
>> Ist da keine Kurve DQD vs. Bitfehlerrate?
>
> Nein. Sollte ich vielleicht für mein Szenario mal selber aufnehmen.
>
Das wäre interessant. Vielleicht sind die Chips auch nicht wirklich von
dieser Firma und der Originalhersteller bietet mehr Daten?
Letztendlich wäre der ultima ratio eine unter Meßbedingungen im
Labor
aufgenommene Kurve.
Übrigens mußt du bit-error-rate von frame-error-rate unterscheiden!
Olaf Kaluza schrieb:
> Christian Zietz <newsgroup@chzsoft.com.ar> wrote:
>
>
> >Keine Ahnung, aber HopeRF erweckt schon den Eindruck,
tatsächlich
> >Hersteller der Chips zu sein.
>
> Ich hab im Internet gelesen das da jemand nachgefragt hat. Die sollen
> die Dies von www.integration.com kaufen und nur auf die Platinen
> pappen.
> Der RF12 entspricht dem IA4420 und der RF12B dem IA4421. Das ist auch
> sehr glaubwuerdig wenn man sich mal diese Datenblaetter anschaut.
>
> Insbesondere das Datenblatt des IA4421 ist etwas ausfuehrlicher.
Ah. Hatte ich doch richtig in Erinnerung. Kann mir also die Arbeit des
Suches sparen.
>
> Ich bin uebrigens kurz davor die Teile zu shreddern weil sie meine
> Nerven kosten. SCHLUCHZ!
>
> Ich hab einem im Palmpilot eingebaut und einer haengt an einem
> M16C. Ich verwende bei beiden SoftSPI. Ich kann Register lesen und
> schreiben. (sieht man z.B am POR bit nach dem einschalten, oder daran
> das ich den Taktausgang schalten kann. Oder wenn ich die Schwelle der
> Batterieueberwachung verschiebe bekomme ich halt ein Batterieflag oder
> auch nicht)
>
> Ich kann beide dazu bringen etwas zu senden. Man kann sogar die
> Modulation auf dem Spektrumanalyzer sehen. Mein Empfaenger wartet bis
> er die beiden Syncbytes empfaengt, aber wenn ich dann die Fifo lese
> kommt nur noch Muell raus der lediglich eine grobe Aehnlichkeit mit
> den Sendedaten hat. Irgendwie gehen mir langsam die Ideen aus
> was ich noch falsch gemacht habe da doch alles wichtige laufen muss
> um ueberhaubt soweit zu kommen.
>
> Ich glaub ich brauch nen Ingwertee, seufz.
>
Offensichtlich hast du dein Limit erreicht und an deiner Stelle würde
ich den Kram zumindest ne Nacht liegenlassen. Morgen kommst du schneller
voran. (Meine Erfahrung)
Christian Zietz schrieb:
> Henry Kiefer schrieb:
>
>> Gib mir mal den direkten Link. Ich lese es jetzt durch.
>
> http://www.hoperf.com/pdf/RF12.pdf
> Insbesondere die Seiten 4 und 17f.
Habe es mir angesehen. Leider steige ich da auch nicht durch.
Alles was ich dazu sagen kann, ist:
- Der Empfänger ist laut Blockschaltbild ein ganz gewöhnlicher
moderner
I/Q FSK-Receiver. Mit der Info sollte man weiterreichende Papers im
Internet finden können.
- Ein RSSI von -90dBm sollte weitgehend fehlerfreie Daten liefern können.
- Stelle einfach die Register nach einem Programmierbeispiel ein. Gibts
das nicht bei hopeRF? Jetzt wissen wir auch wieso die so heißen ;-)
Das Datenblatt ist furchrbar lang. Also das kann man wirklich besser
machen. Die meisten Leute wollen doch nur die Bitrate und Sendeleistung
einstellen und dann endlich SENDEN!!!
>
>> Das wäre interessant. Vielleicht sind die Chips auch nicht
wirklich von
>> dieser Firma und der Originalhersteller bietet mehr Daten?
>
> Keine Ahnung, aber HopeRF erweckt schon den Eindruck, tatsächlich
> Hersteller der Chips zu sein.
OK, das hatten wir nun erledigt. Neue Begriffe für Google...
>
>> Übrigens mußt du bit-error-rate von frame-error-rate
unterscheiden!
>
> Ja, ich bemerke gerade ein Problem dabei. Wenn ein Bitfehler in der
> Synchronisationssequenz auftritt, empfängt man
standardmäßig gar nichts.
> D.h. man kann die Bitfehler in so einem Fall gar nicht zählen,
sondern
> nur feststellen, dass es einen Frame-Error gegeben hat. Ich müsste
also
> schon die Synchronisation abschalten und den rohen Bitstrom untersuchen,
> um in allen Fällen Bitfehler zählen zu können.
>
Die Synchronisierungsphase muß man extra unterscheiden. BTW: Es gibt
auch Modulationsverfahren, in denen die Synchronisation innerhalb des
Datenblocks realisiert ist. siehe Phil Karn.
Wenn du ohne FEC arbeitest, würde ich einen CRC nehmen und fertig.
Entscheidend ist dann sowieso nur die frame-error-rate, da alles andere
automatisch erkannt und verworfen wird.
Die bit-error-rate ist sozusagen der akademische
Leistungsfähigkeits-Beweis :-)
Christian Zietz schrieb:
> Henry Kiefer schrieb:
>
>> - Stelle einfach die Register nach einem Programmierbeispiel ein.
Gibts
>> das nicht bei hopeRF?
>
> Es funktioniert ja alles, aber ich wüsste halt gerne, was ich da
genau
> mache, wenn ich die Schwelle für das DQD auf 4 setze.
>
>> OK, das hatten wir nun erledigt. Neue Begriffe für Google...
>
> Das Datenblatt des IA4420 von Integration ist beinahe wortwörtlich
> gleich und sagt auch nix Neues zum DQD. Muss ich wohl damit leben, ist
> ja auch nicht dramatisch.
>
> Aber: Was ist denn das für ein Quatsch auf der Webseite von
Integration?
> Datenblatt-Download nur nach Captcha-Eingabe?
>
Eventuell findest du aber unter den neuen Suchbegriffen die Antwort!
Google halt mal.
Vielleicht ist 4 einfach die Zahl zulässiger schlechter Spikes im
Demodulator pro Datenbit? ->:
Ein FSK-Empfänger vergleicht im Prinzip einfach nur den Energieinhalt
zweier Frequenzbänder, die sehr nahe beieinander liegen. Energien, die
in beiden Frequenzbändern auftreten, werden also nicht
berücksichtigt.
Dazu zählen typischerweise unkorrelierte Störer, das
Hintergrundrauschen
aus diversen Quellen. Also alles was der Sender nicht bezweckt erzeugte.
Nachdem der Demodulator synchronisiert wurde, ist die Zeitdauer eines
Bits genau festgelegt. Das ist der Punkt, wo von Leistungsmessung in den
beiden Frequenzbändern auf Energiemessung
(Leistungsmessung=Energiemessung/Bitlänge) umgeschaltet wird.
Wenn ich das Blockschaltbild richtig verstehe, wird in den beiden I und
Q Kanälen nach dem Tiefpaßfilter (Was einem Realsignal-Bandpaß
entspricht, sich aber besser in Chips integrieren läßt) einfach nur
die
Menge positiver und negativer Pulse differenziert. Da sitzen D-FFs. Die
geklippte Differenz sollte den Datenbit-Wert ergeben.
Die genaue Theorie dazu kenne ich allerdings noch nicht. Daher mein Tipp
nach Papers suchen.
Ergo, sinnvoll ist: Bei längerer Datenblock-Länge (=längeres
Frame)
braucht man auch einen höheren Störabstand!
Oder anders herum ausgedrückt: Macht man das Frame nur lange genug, kann
man sicher gehen, das es fehlerhaft sein wird!
Olaf Kaluza schrieb:
> Christian Zietz <newsgroup@chzsoft.com.ar> wrote:
>
> >> Der RF12 entspricht dem IA4420 und der RF12B dem IA4421. Das ist
auch
> >> sehr glaubwuerdig wenn man sich mal diese Datenblaetter
anschaut.
>
> >Danke für den Hinweis, die Datenblätter werde ich mir mal
ansehen.
>
> Die haben auch den Vorteil das sie sich drucken lassen. Ich weiss
> nicht ob ihr es schon gemerkt habt aber die Versionen von Hope haben
> ein Password gesetzt damit man sie nicht drucken kann. Da muss man
> erst den Umweg gehen und sie als Postscript umwandeln. .-)
Der Burggraben wird langsam voll.
>
> >Bei mir hat alles unglaublich gut funktioniert, nachdem ich ein
Problem
> >beseitigt hatte. Und zwar hatte ich die Datenrate so hoch
gewählt, dass
> >ich mit dem Bit-Banging am Parallelport des PCs nicht mehr hinterher
> >kam.
>
> Ich arbeite Momentan mit 1000Baud, obwohl ich es auch schon mit
> 20000Baud probiert habe. Das macht aber keinen Unterschied.
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 :-)
>
> Das SPI-Interface der Kiste ist...nun ja.. nicht
> jugendfrei. Normalerweise 16Bit, bei Status 18Bit, aber wenn einem
> danach ist dann auch mal nur 1Bit. Und wenn ich das richtig sehe gibt
> er FFIT/RGIT bereits ohne Takt oder 0Bit auf SDI aus.
Buggy?
>
>
> >Das ist allerdings seltsam. Hast Du mal das Statusregister
während des
> >Sendens bzw. Empfangens auf Auffälligkeiten überprüft?
>
> Da faellt mir nichts auf. Momentan gehe ich der Theorie nach das die
> Baudrate unterschiedlich ist obwohl das nicht so sein sollte da ich
> den Source zwischen Palmpilot und M16 weitestgehend kopiert
> habe. Grund ist das ich z.B das hier sende:
>
> Send: aa aa aa 2d d4
> Send: 01 01 01 01 80 80 80 80 f0 f0 f0 f0 0f 0f 0f 0f
>
> und dies empfange:
>
> Empf: 03 00 c0 c0 00 60 60 60 7c 7c 7c 7c 07 c0 f1 f0 7f ....
>
Kontrolliere mal die Versorgungsspannung! Drähte übers Modul liegend?
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Login
Search
![New posts [ Popular ]](images/topic_unread_hot.gif "New posts [ Popular ]"){kind=small}
![No new posts [ Popular ]](images/topic_read_hot.gif "No new posts [ Popular ]"){kind=small}
![New posts [ Locked ]](images/topic_unread_locked.gif "New posts [ Locked ]"){kind=small}
![No new posts [ Locked ]](images/topic_read_locked.gif "No new posts [ Locked ]"){kind=small}
