Hallo, ich nutze in meinem Haus diverse Funksensoren im ISM Band, die
ich in meiner Hausautomatisierung integriert habe. Um mehr ueber die
darunterliegende Technik zu verstehen, habe ich mir nun ein CC1101
Module gekauft und experimentiere damit. Besonders geht es mir auch um
den Aspekt, das Signal mit einem SDR aufzufangen und zu decodieren um zu
verstehen "was da eigentlich passiert".
Ich nutze einen ESP8266 mit einem CC1101 Modul via SPI. Verwendet wird
die Bibliothek https://github.com/LSatan/SmartRC-CC1101-Driver-Lib
Ich habe folgenden simplen Sketch, der auf 433.92 MHz die Nachricht
"Hello World" in Endlossschleife sendet. Es handelt sich dabei um das
Beispiel, dass man in der Arduino IDE unter Examples->CC1101 default
examples->New transmit method Hello World Advanced findet.
1
// These examples are from the Electronics Cookbook by Simon Monk
ELECHOUSE_cc1101.setMHZ(433.92);// Here you can set your basic frequency. The lib calculates the frequency automatically (default = 433.92).The cc1101 can: 300-348 MHZ, 387-464MHZ and 779-928MHZ. Read More info from datasheet.
34
ELECHOUSE_cc1101.setDeviation(47.60);// Set the Frequency deviation in kHz. Value from 1.58 to 380.85. Default is 47.60 kHz.
35
ELECHOUSE_cc1101.setChannel(0);// Set the Channelnumber from 0 to 255. Default is cahnnel 0.
36
ELECHOUSE_cc1101.setChsp(199.95);// The channel spacing is multiplied by the channel number CHAN and added to the base frequency in kHz. Value from 25.39 to 405.45. Default is 199.95 kHz.
37
ELECHOUSE_cc1101.setRxBW(812.50);// Set the Receive Bandwidth in kHz. Value from 58.03 to 812.50. Default is 812.50 kHz.
38
ELECHOUSE_cc1101.setDRate(99.97);// Set the Data Rate in kBaud. Value from 0.02 to 1621.83. Default is 99.97 kBaud!
39
ELECHOUSE_cc1101.setPA(10);// Set TxPower. The following settings are possible depending on the frequency band. (-30 -20 -15 -10 -6 0 5 7 10 11 12) Default is max!
ELECHOUSE_cc1101.setSyncWord(211,145);// Set sync word. Must be the same for the transmitter and receiver. (Syncword high, Syncword low)
42
ELECHOUSE_cc1101.setAdrChk(0);// Controls address check configuration of received packages. 0 = No address check. 1 = Address check, no broadcast. 2 = Address check and 0 (0x00) broadcast. 3 = Address check and 0 (0x00) and 255 (0xFF) broadcast.
43
ELECHOUSE_cc1101.setAddr(0);// Address used for packet filtration. Optional broadcast addresses are 0 (0x00) and 255 (0xFF).
44
ELECHOUSE_cc1101.setWhiteData(0);// Turn data whitening on / off. 0 = Whitening off. 1 = Whitening on.
45
ELECHOUSE_cc1101.setPktFormat(0);// Format of RX and TX data. 0 = Normal mode, use FIFOs for RX and TX. 1 = Synchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins. 2 = Random TX mode; sends random data using PN9 generator. Used for test. Works as normal mode, setting 0 (00), in RX. 3 = Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins.
ELECHOUSE_cc1101.setPacketLength(0);// Indicates the packet length when fixed packet length mode is enabled. If variable packet length mode is used, this value indicates the maximum packet length allowed.
48
ELECHOUSE_cc1101.setCrc(1);// 1 = CRC calculation in TX and CRC check in RX enabled. 0 = CRC disabled for TX and RX.
49
ELECHOUSE_cc1101.setCRC_AF(0);// Enable automatic flush of RX FIFO when CRC is not OK. This requires that only one packet is in the RXIFIFO and that packet length is limited to the RX FIFO size.
50
ELECHOUSE_cc1101.setDcFilterOff(0);// Disable digital DC blocking filter before demodulator. Only for data rates ≤ 250 kBaud The recommended IF frequency changes when the DC blocking is disabled. 1 = Disable (current optimized). 0 = Enable (better sensitivity).
51
ELECHOUSE_cc1101.setManchester(0);// Enables Manchester encoding/decoding. 0 = Disable. 1 = Enable.
52
ELECHOUSE_cc1101.setFEC(0);// Enable Forward Error Correction (FEC) with interleaving for packet payload (Only supported for fixed packet length mode. 0 = Disable. 1 = Enable.
53
ELECHOUSE_cc1101.setPRE(0);// Sets the minimum number of preamble bytes to be transmitted. Values: 0 : 2, 1 : 3, 2 : 4, 3 : 6, 4 : 8, 5 : 12, 6 : 16, 7 : 24
54
ELECHOUSE_cc1101.setPQT(0);// Preamble quality estimator threshold. The preamble quality estimator increases an internal counter by one each time a bit is received that is different from the previous bit, and decreases the counter by 8 each time a bit is received that is the same as the last bit. A threshold of 4∙PQT for this counter is used to gate sync word detection. When PQT=0 a sync word is always accepted.
55
ELECHOUSE_cc1101.setAppendStatus(0);// When enabled, two status bytes will be appended to the payload of the packet. The status bytes contain RSSI and LQI values, as well as CRC OK.
56
57
Serial.println("Tx Mode");
58
}
59
60
voidloop(){
61
62
//3 different methods to send data
63
64
//Transmitt "Hello World" from byte format.
65
ELECHOUSE_cc1101.SendData(transmitt_byte,11);
66
delay(2000);
67
68
//Transmitt "Hello World" from char format.
69
ELECHOUSE_cc1101.SendData(transmitt_char);
70
delay(2000);
71
72
//Transmitt "Hello World" from char format directly.
73
ELECHOUSE_cc1101.SendData("Hello World");
74
delay(2000);
75
76
}
Mit gqrx finde ich mein Signal, allerdings nicht bei 433.92 MHz, sondern
auf 433.964 MHz. Hier die erste Frage: Warum? Ist das Billig-CC1101
Board so schlecht, dass es da eine solche Verschiebung gibt?
Ich sehe, dass es definitiv mein Signal ist, da es in exakt 2000ms
Abstand im Wasserfall zu sehen ist. Ändere ich die Zeit, ändern sich die
Abstände entsprechend.
Mit dem Tool Universal Radio Hacker (https://github.com/jopohl/urh)
zeichne ich nun das Signal auf und demoduliere es.
Dabei viel mir auf, dass ich, wenn ich das Signal in AM sende
(ELECHOUSE_cc1101.setModulation(2)) ich immer wieder Fehler habe, sende
ich es in FM (setModulation(0)) kann es immer perfekt demoduliert
werden.
Ein Zoom In auf das Signal zeigte mir, dass in AM die Trägerwelle einen
Nulldurchgang macht und die Fehler immer dann auftraten, wenn dort ein
Symbol codiert wurde. Bei FM war dies nicht der Fall, das Signal wurde
immer perfekt demoduliert. Jetzt frage ich mich natürlich: Ist dann AM
überhaupt nicht dafür geeignet Daten zu versenden, wenn es bei den
Nulldurchgängen des Signals zu solchen Problemem kommen? Ich habe aber
trotz einiger Google-Recherche nichts dazu gefunden, insofern bin ich
mir nicht sicher, ob ich nicht einfach was falsch mache?
Zur Interpretation der Screenshots: Das was man unter "hex decode" sieht
sind 4 Byte preamble AAAA, dann 4 Byte Syncword d391, dann die Länge 0b
und dann die ASCII-Hexwerte von H,e,l,l,o, ...
Man sieht oben das AM demodulierte Signal und unten das FM demodulierte
Signal. Es sind natuerlich auch pro Signal unterschiedliche
Aufzeichnungen, einmal von einem Signal mit setModulation(0) und einmal
von setModulation(2).
Markus schrieb:> Mit gqrx finde ich mein Signal, allerdings nicht bei 433.92 MHz, sondern> auf 433.964 MHz.
Wird vermutlich daran liegen:
Markus schrieb:> ELECHOUSE_cc1101.setMHZ(433.92);Markus schrieb:> ELECHOUSE_cc1101.setDeviation(47.60);
433.92 + 0.0476 = 433.967
Der Restfehler stammt wohl von SDR und/oder vom CC1101
(Frequenzungenauigkeiten der Quarz-Referenzen oder Ungenauigkeit
beim Einstellen der Empfangsfrequenz).
Wastl schrieb:> Markus schrieb:>> Mit gqrx finde ich mein Signal, allerdings nicht bei 433.92 MHz, sondern>> auf 433.964 MHz.>> Wird vermutlich daran liegen:>> Markus schrieb:>> ELECHOUSE_cc1101.setMHZ(433.92);>> Markus schrieb:>> ELECHOUSE_cc1101.setDeviation(47.60);>> 433.92 + 0.0476 = 433.967>> Der Restfehler stammt wohl von SDR und/oder vom CC1101> (Frequenzungenauigkeiten der Quarz-Referenzen oder Ungenauigkeit> beim Einstellen der Empfangsfrequenz).
Danke! Stimmt, das könnte es erklären! Und das macht man.... damit nicht
alle auf 433.92 senden und sich gegenseitig ins Gehege kommen, sondern
man von vornherein einen gewissen Jitter hat?
Welche Breite muss mein Filter denn haben, wenn ich das möglichst exakt
mit dem SDR rausschneiden will? Ich gehe auf 433.967 rechne nochmal die
Ungenauigkeit drauf und dann...? Vordefiniere Filter sind ja z.B. 10kHz,
20kHz (Narrow, Wide, ...)?
Und wie erklärt sich jetzt das "Problem" bei AM? Ist das eine inherente
Problematik warum man dann eher FM verwenden würde?
Markus schrieb:> Ist das Billig-CC1101> Board so schlecht, dass es da eine solche Verschiebung gibt?
Dass du ein Billig-SDR haben könntest, auf die Idee bist du
nicht gekommen? Zu einer problematischen Funkübertragung
gehören immer zwei, ein Sender und ein Empfänger, beide
können "schlecht" sein. Was das vermutliche Problem ist
habe ich ja bereits vorher beschrieben.
Doch, das habe ich schon verstanden, und ja auch als mögliche Erklärung
selbst erkannt.
Im Kern geht es mir ja aber in der Frage um die unterschiedliche
Darstellung zwischen AM und FM und ob ich überhaupt erwarten darf, dass
eine längere Nachricht problemlos via AM übertragen werden kann aufgrund
dessen, dass beim Nulldurchgang die Demodulation doch nicht mehr sicher
möglich ist - zumindest meine Vermutung?
Falls ich gänzlich falsch liege, bitte gerne korrigieren
Wenn du dir mal den Unterschied zwischen AM (genauer OOK -
on-off-keying) und FM klar machst, kommst du vielleicht selbst drauf:
bei OOK wird der Unterschied Signal - kein Signal ausgewertet, bei FM
hast du immer ein Signal und kannst den Empfänger per Squelch schalten
und eine AGC zum Regeln verwenden.
Falls es der Erklärung dient:
Sender ist ein CC1101, wie schon geschrieben, Empfänger ist ein NOOELEC
NESDR Smart https://www.nooelec.com/store/sdr/sdr-receivers/smart.html
Ich habe aber auch ein SDRplay und stelle dort das gleiche fest.
Meinem Verständnis nach ist aber die Frage nach der Empfänger HW nicht
die Erklärung dafür, wie sich das Signal prinzipiell darstellt, sondern
nur Unterschiede im SNR, generelle Qualität, usw.?
Helmut -. schrieb:> Wenn du dir mal den Unterschied zwischen AM (genauer OOK -> on-off-keying) und FM klar machst, kommst du vielleicht selbst drauf:> bei OOK wird der Unterschied Signal - kein Signal ausgewertet, bei FM> hast du immer ein Signal und kannst den Empfänger per Squelch schalten> und eine AGC zum Regeln verwenden.
OK, d.h. dann interpretiere ich daraus also dass ich für eine
Datenübertragung eher nicht AM nutzen sollte, sondern FM, da am
Nulldurchgang bei AM eben nicht unterschieden werden kann ob das Signal
0 ist oder die Trägerwelle, wie im Screenshot oben zu sehen?
Wenn du dein Signal so codierst, dass "kein Träger" eine 0 bedeuten
soll, hast du eine falsche Codierung verwendet. Bei ASK (=OOK) sollte
man halt Manchestercodierung oder PWM oder sowas verwenden, etwas, das
für eine logische 0 und 1 einen Signalwechsel beinhaltet. Die üblichen
Wettersensoren verwenden z.B. 100µs Signal und 200µs kein Signal als 0
und 200µs Signal und 100µs kein Signal für 1. Und eine ausreichend lange
Präambel zur Synchronisierung vorher nicht vergessen!
Helmut -. schrieb:> Wenn du dein Signal so codierst, dass "kein Träger" eine 0 bedeuten> soll, hast du eine falsche Codierung verwendet. Bei ASK (=OOK) sollte> man halt Manchestercodierung oder PWM oder sowas verwenden, etwas, das> für eine logische 0 und 1 einen Signalwechsel beinhaltet. Die üblichen> Wettersensoren verwenden z.B. 100µs Signal und 200µs kein Signal als 0> und 200µs Signal und 100µs kein Signal für 1. Und eine ausreichend lange> Präambel zur Synchronisierung vorher nicht vergessen!
Vielen Dank für diesen Hinweis Helmut, das war "wertvoll" und ja auch
genau ein Punkt, warum ich frage!
OK, dann liegt der "Fehler" also hier, dass in dem Beispiel gesetzt
wurde:
1
ELECHOUSE_cc1101.setManchester(0);
und ein Wechsel auf 1 sollte es mir dann auch mit AM immer erfolgreich
sein? Eine Präambel wird ja bereits gesendet (
1
ELECHOUSE_cc1101.setSyncMode(2);
)
Würde ich das gleiche Ziel nicht aber auch erreichen, indem ich die
Geschwindigkeit, mit der die Daten gesendet werden, deutlich herabsetze?
Dann sollte es doch sehr viel seltener zu der Situation kommt, dass ein
übertragenes Symbol genau (nur) in dem Zeitpunkt übertragen wird, indem
der Träger 0 ist?
Das wäre dann wohl
1
ELECHOUSE_cc1101.setDRate(99.97);// Set the Data Rate in kBaud. Value from 0.02 to 1621.83. Default is 99.97 kBaud!
was ich dann einfach mal auf einen viel kleineren Wert setze und schaue
wie es sich dann darstellt?
Oder wird es in der Praxis dann auch so gemacht, das man eine CRC mit
überträgt und am Empfänger prüft und sicherheitshalber das Signal
mehrfach aussendet, so dass man etwaige Übertragungsfehler kompensieren
kann?
Markus schrieb:> Oder wird es in der Praxis dann auch so gemacht, das man eine CRC mit> überträgt und am Empfänger prüft
Das machen so gut wie alle digitalen Funkprotokolle, außer vielleicht
billige Funksteckdosen oder so.
Markus schrieb:> sicherheitshalber das Signal mehrfach aussendet
Das wird auch oft gemacht.
Dass AM unzuverlässig ist ist doch bekannt - hast du einen Grund das zu
nutzen statt FSK?
Niklas G. schrieb:> Markus schrieb:>> Oder wird es in der Praxis dann auch so gemacht, das man eine CRC mit>> überträgt und am Empfänger prüft>> Das machen so gut wie alle digitalen Funkprotokolle, außer vielleicht> billige Funksteckdosen oder so.>> Markus schrieb:>> sicherheitshalber das Signal mehrfach aussendet>> Das wird auch oft gemacht.>> Dass AM unzuverlässig ist ist doch bekannt - hast du einen Grund das zu> nutzen statt FSK?
Der Grund ist lediglich, dass ich blutiger Anfänger bin und mir dachte
ein AM Signal zu "verstehen" (auch im Sinne des URH Tools, siehe
Screenshot) wäre einfacher. Störungen, was ja einer der Gründe gegen AM
ist(?), verhinderten ja hier offenbar nicht, dass die Demodulation
erfolgreich war.
Im Grunde wäre dann also die Erkenntnis aus diesem Thread:
* Ausser es gibt triftige Gründe, grundsätzlich immer FM verwenden
* Wenn doch AM (Modus ASK/OOK), dann immer auch Manchester mit
aktivieren, ansonsten kommt es zu dem beobachteten Verhalten.
* Immer eine CRC und/oder mehrfach aussenden, da ein einzelnes Aussenden
immer gestört werden könnte und somit der Empfänger im Zweifelsfall es
nicht sauber decodieren kann
Ist das so richtig?
Markus schrieb:> Oder wird es in der Praxis dann auch so gemacht, das man eine CRC mit> überträgt und am Empfänger prüft und sicherheitshalber das Signal> mehrfach aussendet, so dass man etwaige Übertragungsfehler kompensieren> kann?
Ein CRC ist zwar schon mal gut damit Schrott in der Übertragung
erkannt wird, aber was hilft ein CRC wenn das Datenpaket gar
nicht ankommt? Bei Funkübertragung kann ich ein Datenpaket x-mal
schicken und es können alle Pakete von anderen Funkteilnehmern
gestört sein. Daher ist eine (Funk-)Datenübertragung erst dann
sicher wenn der Sender auch eine Bestätigung über den Erhalt
eines Datenpaketes vom Empfänger bekommt.
Diese Funktionalität ist übrigens bei den NRF24 Chips (ja, wir
reden hier von 433MHz Modulen) automatisch enthalten wenn man
das Acknowledge aktiviert. Dieses Ack wird nur dann gesendet
wenn ein Datenpaket vollständig und fehlerfrei beim Empfänger
angekommen ist. Eine sehr komfortable Art der Datensicherung.
Markus schrieb:> Immer eine CRC und/oder mehrfach aussenden, da ein einzelnes Aussenden> immer gestört werden könnte
Wie gerade geschrieben, es nützt nichts, jedes einzelne
deiner (vielen) Datenpakete kann gestört sein.
Es ist halt auch keine besonders gute Idee, bei einer AM-Modulation
den Traeger bis auf 0% abzusenken. Das bekommt "einfachen"
Demodulatoren nicht besonders. Uebliche Werte liegen eher bei 20 - 30%.
Zur Reichweiteoptimierung kann man auch noch hoehere Werte probieren.
Motopick schrieb:> Es ist halt auch keine besonders gute Idee, bei einer AM-Modulation> den Traeger bis auf 0% abzusenken. Das bekommt "einfachen"> Demodulatoren nicht besonders. Uebliche Werte liegen eher bei 20 - 30%.> Zur Reichweiteoptimierung kann man auch noch hoehere Werte probieren.
Beziehst Du Dich darauf, dass ich in dem Beispiel einfach mal naiv von
FM zu ASK/OOK gewechselt habe ohne zeitgleiche andere Parameter zu
ändern? (Ich habe verstanden, das Manchester Encoding zu aktivieren wäre
eine gute Idee gewesen?)
Ich habe jetzt jedenfalls nichts gefunden, dass ich so etwas wie die
Absenkung in dem ASK/OOK Modus einfach beeinflussen könnte und offenbar
ist hier auch nicht ein sinnvoller Default wie von Dir geschrieben
20-30% gesetzt?
Wie schon eingangs geschrieben bin ich Neuling in dem Thema und wollte
vor allem verstehen WARUM es Probleme gibt. Das ist mir soweit gelungen,
denke ich.
Markus schrieb:> Beziehst Du Dich darauf, dass ich in dem Beispiel einfach mal naiv von> FM zu ASK/OOK gewechselt habe ohne zeitgleiche andere Parameter zu> ändern? (Ich habe verstanden, das Manchester Encoding zu aktivieren wäre> eine gute Idee gewesen?)
Da ich den CC1101 nicht kenne, kann ich mich nicht auf dein
Beispiel beziehen. Man kann aber mit sinnvoll gewaehlten
Modulationsparametern bereits asynchron Zeichen senden und
empfangen.
Eine Manchestercodierung sorgt fuer ein Signal ohne Gleichanteil,
0 und 1 treten gleich haeufig auf.
Die behebt das Modulationsproblem bei AM aber nicht.
> Ich habe jetzt jedenfalls nichts gefunden, dass ich so etwas wie die> Absenkung in dem ASK/OOK Modus einfach beeinflussen könnte und offenbar> ist hier auch nicht ein sinnvoller Default wie von Dir geschrieben> 20-30% gesetzt?
Das wirst du selbst herausfinden muessen.
Man koennte das Modulationssignal statisch anlegen und die
Ausgangsspannung/leistung messen.
> Wie schon eingangs geschrieben bin ich Neuling in dem Thema und wollte> vor allem verstehen WARUM es Probleme gibt. Das ist mir soweit gelungen,> denke ich.
Das es bei 100%iger AM-Modulation Probleme gibt, hast du ja schon
herausgefunden. :)
Was mir jetzt aber noch nicht klar ist: Wenn doch ASK/OOK doch offenbar
so "schlecht" ist, Manchester-Codierung auch das Problem nicht löst -
warum wurde das dann wohl integriert? Natürlich kann das am Ende nur TI
beantworten, aber was kann denn der Use-Case sein, wenn doch FM
eigentlich in allen Varianten überlegen ist? Einfach "weil man das halt
auch braucht"?
Markus schrieb:> warum wurde das dann wohl integriert
Damit es kompatibel mit existierenden (sehr einfachen/billigen) Geräten
ist die nur ASK/OOK haben. Wenn man auf beiden Seiten FSK zur Verfügung
hat sollte man es wohl auch nutzen.
Markus schrieb:> Was mir jetzt aber noch nicht klar ist: Wenn doch ASK/OOK doch offenbar> so "schlecht" ist,
Ist sie ja nicht. Ich wuerde auch nicht glauben, dass man den
CC1101 dabei nur mit 100% Modulation betreiben kann.
Das fehlt womoeglich einfach in den Libraries (aka verhackstueckten
Include-Files).
Hast du denn schon einmal Datenblatt/Manual zum CC1101 bemueht?
> Manchester-Codierung auch das Problem nicht löst -
Manchester setzt auf die gewaehlte Modulation auf. Es kann also
etwas schlecht konfiguriertes nicht verbessern.
Manchester kann man im uebrigen mit einfachster Hardware
sowohl kodieren als auch dekodieren. Was so einfach ist, kann
nicht schlecht sein. :)
> warum wurde das dann wohl integriert? Natürlich kann das am Ende nur TI> beantworten, aber was kann denn der Use-Case sein, wenn doch FM> eigentlich in allen Varianten überlegen ist? Einfach "weil man das halt> auch braucht"?
Im Moment redest du noch von Dingen, zu denen dir jedes Verstaendnis
fehlt. Und das wird sich auch mit der Benutzung von zusammenkopierten
Code nicht verbessern.
Moin,
Ich empfehle mal g'schwind ein Studium der elektrischen
Nachrichtentechnik. Da werden genau so Sachen, wie verschiedene
Modulationsverfahren, ihre Eigenschaften, verschiedene Kanalcodierungen,
ihre Eigenschaften, Fehlerschutzverfahren und ihre Eigenschaften,
Kommunikationskanaele, ihre Eigenschaften wie z.b. Bandbreite,
Kapazitaet, Fehlereigenschaften, etc. bla. sehr gruendlich
durchgekaut...
Gruss
WK
Ich habe meine Versuche mit dem am Anfang erwähnten Beispielcode jetzt
noch ein wenig fortgesetzt:
Aktiviere ich Manchester Encoding so war es in jedem Fall moeglich in
wenigstens 1 von 3 Übertragungen die ursprüngliche Nachricht erfolgreich
zu dekodieren.
Setze ich allerdings die Datenrate drastisch herunter, so dass die
Übermittlung einer "1" bereits mehrere komplette Schwingen umfasst - war
und es somit nicht zu dem Fall kommt, dass ein Symbol genau zum
Nulldurchgang der Amplitude moduliert wird - so war mit reinem ASK/OOK
auch ohne Manchester Encoding die Demodulation stets erfolgreich.
@motopick: Ja, ich habe mir gestern noch das gesamte Datenblatt zu
Gemüte geführt und auch das dagegen gehalten, was die Library macht. Ich
gebe zu, dass ich - Überraschung - nicht alles verstanden habe, was das
Datenblatt beschreibt. Das was noch am ehesten in Frage kommt ist m.E.
der Punkt 10.6 im Datenblatt auf Seite 33
(https://www.ti.com/lit/ds/symlink/cc1101.pdf). Ich vermute aber, dass
es hierbei mehr um die generelle Sendeleistung geht. Ansonsten habe ich
tatsaechlich nichts gefunden. "By programming the PATABLE, controlled PA
power ramp-up and ramp-down can be achieved, as well as ASK modulation
shaping for reduced bandwidth" sowie "The ASK variant supported by the
CC1101 allows programming of the modulation depth
(the difference between 1 and 0), and shaping of the pulse amplitude.
Pulse shaping" - allerdings scheint da nicht mehr weiter darauf
eingegangen zu werden. Eventuell ist es aber Seite 59 "If OOK modulation
is used, the logic 0 and logic 1 power levels shall be programmed to
index 0 and 1 respectively." im Bereich der PA_POWER Tabellen.
Markus schrieb:> ..."If OOK modulation> is used, the logic 0 and logic 1 power levels shall be programmed to> index 0 and 1 respectively." im Bereich der PA_POWER Tabellen.
Naja siehste. Eine Sendeleistung fuer die '0' und eine fuer die '1'.
Wenn man fuer die '0' da eine Null hineinschreibt, ist man halt
selber zu doof. :)
Und Rampen fuer die Flanken...
Was will man mehr.
Thread beobachten
Seitenaufteilung abschalten