Hallo Gemeinde, ich habe eine 433Mhz Funkstrecke aufgebaut die mich zur Verzweiflung treibt. Zwei Arduino Nano mit den Modulen TX1EN und et-rxb-12. Alles wird derzeit mit 5V betrieben. Die Nanos haben den üblichen 16Mhz Quarztakt. Die Software ist in Assembler geschrieben. Soweit so gut. Ich erzeuge das im Bild zu sehende und dokumentierte Funktelegramm und sende es kontinuierlich 10 mal hintereinander.(3ms Pause zwischen den Telegrammen) Zum Testen wiederholt sich das alle 3 Sekunden. Folgende Triggerbedingungen checkt die Empfangssoftware: Nach dem Startimpuls mindestens 4ms Sendepause. Nach dem kommenden ersten 0>1 Wechsel 3ms nicht zuhören.(Einschwingverhalten abwarten) Warten auf >450us "1" Lage. Die folgende "0" abwarten. 32 Bit einlesen. Die Telegramme 6-10 werden fast ausnahmslos jedes mal alle richtig erkannt. Die Telegramme 1-5... 1 nie, 2 selten, 3 manchmal, 4 gelegentlich, 5 öfter Zu Risiken und Nebenwirkungen... :-) Also sehr unzuverlässig. Es gelingt mir nicht die Telegramme 2-5 zuverlässig zu empfangen. Mir gehen die Ideen aus woran es liegen könnte das es nicht geht. Telegramm 1 ist geschenkt, das ist meist noch überlagert/verzerrt von irgendwas. Ich würde gerne die Aussendung der Telegramme auf die Anzahl 3- max.5 reduzieren. Der Sender soll später auf einem Tiny laufen und hat nur eine CR3032 und die soll so lange wie möglich halten. Der Sender bekommt dann einen Upstepper für den Sender auf 5V. Wenn meine Berechnungen stimmen, dann hätte die Batterie mit den jetzigen 10 Telegrammen je Aussendung eine theoretische Lebenserwartung von etwas über einem Jahr wenn es eine Aussendung pro Tag gibt. Zum Hintergrund, es soll ein Briefkastenalarm werden. Der Empfänger (in der Wohnung) hat noch ein ESP01 Modul und macht dann daraus eine Email.(was schon funktioniert) Hat jemand Ideen/Vorschläge was zu tun ist bzw. wo ein offensichtilicher Denkfehler ist? Vielen Dank vorab für eure Aufmerksamkeit. Hans
Angehängte Dateien:
-
Telegramm.png
7,3 KB
Deine Übertragung hat einen DC Offset. Nutze ein anderes Protokoll, z.B. Manchester Encoding. Auch dann könnte die Präambel ruhig etwas länger sein.
Hans schrieb: > Hat jemand Ideen/Vorschläge was zu tun ist bzw. wo ein offensichtilicher > Denkfehler ist? Ich schau mal in meine Glaskugel ob ich dort deinen Code finde.... Mist nix gefunden. Also meine hellseherischen Fähigkeiten sind doch irgendwo begrenzt. Und Assembler auf nem Arduino? Warum?
Joe F. schrieb: > Deine Übertragung hat einen DC Offset. > Nutze ein anderes Protokoll, z.B. Manchester Encoding. > > Auch dann könnte die Präambel ruhig etwas länger sein. Der Offset ist nicht wirklich da. Es ist mit der Soundkarte gerippt.
Hans schrieb: > Joe F. schrieb: >> Deine Übertragung hat einen DC Offset. >> Nutze ein anderes Protokoll, z.B. Manchester Encoding. >> >> Auch dann könnte die Präambel ruhig etwas länger sein. > > Der Offset ist nicht wirklich da. > Es ist mit der Soundkarte gerippt. Dein Empfänger macht aber vermutlich das gleiche. Die Präambel ist symmetrisch, und damit schiebt sich das Signal in einen brauchbaren Bereich. Deine "Einsen" sind unsymmetrisch, womit sich das Signal langsam wieder der Nullinie annähert. Bei den "Nullen" ist es noch ungünstiger. Je mehr Nullen du in deinen Daten hast, desto schneller tritt der Effekt also auf. Du könntest als Hack natürlich rausfinden, wieviele Nullen du noch einwandfrei hintereinander versenden kannst, und dann vor jedes einzelne Telegramm eine lange Präambel setzen. Das ist aber nicht wirklich schön. Mit einer für Funkübertragung geeigneten Encodierung (ohne DC Anteil) ist das Problem daher viel eleganter gelöst. Statt Manchester könntest du auch "FSK" nehmen (1 = 300us/300us 0=600us/600us), das ist auch ohne DC Anteil - wäre vielleicht mit deinem jetzigen Code einfacher zu realisieren.
:
Bearbeitet durch User
@ Joe Deinen Überlegungen würde ich bedingungslos zustimmen wenn nicht T6-10 immer wie geschnitten Brot reingehen. Das Encoding benutzen so Aussenthermometer auch. Die senden aber auch zig Wiederholungen. Der Knaller ist so ein Funkschlüssel vom Auto. 3 Telegramme (allerdings Manchester) und gut ist. Das ganze dann auf 100Meter mit einmal drücken zuverlässig. Wie geht das denn?? Sind da schärfere Empfänger verbaut? Oder steppen die im Schlüssel auf eine höhere Spannung?
Guck mal ins Datenblatt vom TX1EN: Input Duty: 1 Kbps, min 40%, max 60% Dann auch ET-RXB-12: Data Rate: 2.4 Kbps Du bist also mit deiner 25% duty rate und der Geschwindigkeit ausserhalb der Specs. Präambel hat 1.6 Kbps Die "Einsen" immer noch 1.1 Kbps Ist das Bild eigentlich vor dem Sender abgegriffen, oder ist das das empfangene Signal?
:
Bearbeitet durch User
Joe, das ist ein sehr guter Hinweis. Danke das du dir solche Mühe machst! Aber das Bild zeigt den Ausgang des Empfängers. Somit verkraftet der TX das Timing. Das kann es also auch nicht sein.
Hans schrieb: > Joe, das ist ein sehr guter Hinweis. > Danke das du dir solche Mühe machst! > > Aber das Bild zeigt den Ausgang des Empfängers. > Somit verkraftet der TX das Timing. > Das kann es also auch nicht sein. Dann wird es wohl deine Software sein. Ob da aber jemand Lust zu hat das zu debuggen (Assembler...) ;-) Eine letzte Möglichkeit wäre noch, dass der Ausgangspegel des Moduls nicht zum erwarteten Eingangspegel deines Arduinos passt. Hast du ein Oszilloskop zur Verfügung? Im Zweifel auch mal mit den Pullup/Down Möglichkeiten spielen (bzw. Pullup/down auch mal disablen). In einem der Datasheets steht der denkwürdige Satz "NOTE : ET-RXB-12 Drive Current from Data-PIN is weak, if directly connection with Driving Chip which I/O can not connect Pull Up Resistor or Pull Down Resistor, Driving Chip inner Pull Up Resistor and Pull Down Resistor turn to Disabled State." Verstehe ich mal so, dass man den Pullup/down eher disablen sollte.
:
Bearbeitet durch User
Joe, genau deine Gedanken hatte ich auch schon. Ich hatte ja immer vor dem "Trommelfell" geschaut aber nie dahinter. Also habe ich auf einem anderen Port ausgegeben was am Pin ankommt an dem der Empfänger hängt. Es war exakt das gleiche. Der Pegel ist somit auch ok. Ein richtiges Oszi hab ich aber auch hier. Die Software sollte soweit ok sein, da T6-10 zuverlässig, und gelegentlich einer der ersten 5 auch durchgeht. Ich höre auch mit einem "Radio" (Funkscanner) mit ob nicht zufällig immer bei den ersten 5 Tele. etwas dazwischen funkt. Ist nicht. Es muss irgendetwas analoges sein. Ein Einschwingverhalten oder sowas. Hingegen den Funkschlüssel bekomme ich jedes mal fehlerfrei. Der hat sagenhafte 126ms lange Präambel(300us/300us) und dann kommt Manchester. Welches von den 3Tele. ich bekomme weis ich aber nicht. Ich hab auch schon mal probiert die Präambel auf 100 oder 200 Bit zu setzen. Hat nicht geholfen. Es ist echt ein Mysterium.
Auch das mit dem Pullup habe ich natürlich schon ausprobiert. Ohne Erfolg.
Hans schrieb: > Also habe ich auf einem anderen Port ausgegeben was am Pin ankommt an > dem der Empfänger hängt. > Es war exakt das gleiche. > Der Pegel ist somit auch ok. Das ist auf jeden Fall die beste Debuggingmethode. Wenn du dein Oszi ranhängst, mach mal ein Bild mit dem Receiver Ausgang und dem Debug-Pin auf dem 2. Kanal. So wie es sich aber anhört wird das in Ordnung sein. Es kommt also eigentlich nur noch dein Decoder (Software) in Frage.
Joe F. schrieb: > Wenn du dein Oszi ranhängst, mach mal ein Bild mit dem Receiver Ausgang > und dem Debug-Pin auf dem 2. Kanal. Ich habe leider kein Speicheroszi. Da 5ms Pause nach dem Trigger kommen, sind die Nutzdaten dann rechts rausgefallen :-) Oder so eng, dass man nichts mehr erkennen kann. Aber wie du auch schon sagtes und vermutest wird das OK sein. Der "Decoder" funktioniert ja prima. Zumindest bei T6-10. Ok selten auch nur von T7-10. Wie ich sehe sind unsere Überlegungen ziemlich die gleichen. Es wäre schön wenn jemand diesen Beitrag liest, der diese Probleme auch schon mal hatte. Denn mit digitaler Logik scheint man hier nicht weiter zu kommen. Wenn es mir reicht und keine Lösung zu finden ist, dann nehme ich eben 2 AA Batterien und sende eben 10 Telegramme. Finde ich aber unsportlich ;-)
Wenn es ja höchstwahrscheinlich am Decoder liegt müsste man idealerweise dessen Programmcode mal angucken können... Hört sich nach Synchronisationsproblem an.
:
Bearbeitet durch User
Hans schrieb: > Die Telegramme 6-10 werden fast ausnahmslos jedes mal alle richtig erkannt. > Die Telegramme 1-5... 1 nie, 2 selten, 3 manchmal, 4 gelegentlich, 5 öfter Sind die ersten und die letzten demodulierten Telegramme wirklich identisch? Kann man die Breite der entsprechenden Impulse irgendwie genau vergleichen?
3V(2AA) oder 5V sind nicht viel für einen Sender. Probiere es mal mit 12V (dann V23GA Batterie)wie eigentlich alle 433MHz Fernsteuer Sender.
sorry, ich hatte angenommen, dass der TO dieses Modul verwendet. http://www.eeant.com/wireless-transmitter-module/et-tx-1.html
Also der TX1EN könnte sicher auch mit 12V betrieben werden. Das wäre noch eine Option. Ich denke aber nicht, dass es am Pegel liegt, denn auf kurze Distanz ist das Ergebniss nicht viel anders. Das wäre sicher sinnvoll wenn eine grösere Distanz zu überbrücken wär. Ich poste gleich mal den Code des Decoders mit einem Bild der Ergebnisse des Debuggings. Der Quelltext ist leider noch sehr schlecht dokumentiert da er sich in den letzten Versionen schnell verändert hat, ich habe aber Erläuterungen dazu am Anfang in der Datei angeführt. Die Hardcoreprogrammierer, die die noch jedem Takt ins Auge sehen und Assembler schreiben, werden es aber hoffentlich verstehen.
Angehängte Dateien:
-
debug.png
4,9 KB
Hier der Quelltext des Decoders in Assembler und das dazu gehörende Bild der Debuggingausgabe.
Also mit dem Assembler Code kann ich nichts anfangen, aber die Debug Ausgabe verrät ja schon, dass hier absoluter Bullshit rauskommt. Alleine schon die Länge der Telegramme wird ja nicht richtig erkannt. Und das hiesse ja, dass dein Decoder 3ms Pause erkannt hat, die nicht da waren. Frage: warum schreibst du sowas in Assembler und nicht in (lesbarem) C? Datenraten von 3 KHz erfordern ja nicht unbedingt Assembler... Du könntest mal ein definiertes Bitmuster aussenden (z.B. 0x55AA...), und den Empfang damit vergleichen.
:
Bearbeitet durch User
Wenn ich hier sehe wie da herumgepfuscht wird kann ich nur dringendst empfehlen sich die VirtualWire Implementierung anzusehen. Die Sourcen sind ja offen. Nur um kurz darauf hinzuweisen was da gemacht wird: 8-fach oversampling, Sync-Feld, Checksummenbildung und Redundanz-Codierung (Verwendung von lediglich sechzehn 6-Bit Symbolen für halbe Bytes, also Nibbles, die Symbole sind so gewählt dass maximal 3 Nullen oder 3 Einsen direkt aufeinander folgen). Der Autor hat schon gewusst was er macht, und er hat es sicherlich auch "billiger" versucht, vielleicht nicht ganz so dilettantisch wie hier. Meinen Respekt für diese Implementierung hat er. Wer meint es einfacher besser zu können, bitte gerne .....
Hans schrieb: > Folgende Triggerbedingungen checkt die Empfangssoftware: > Nach dem Startimpuls mindestens 4ms Sendepause. > Nach dem kommenden ersten 0>1 Wechsel 3ms nicht > zuhören.(Einschwingverhalten abwarten) Deine Empfangssoftware bekommt IMHO den Startimpuls und die ersten 0/1- und 1/0-Wechsel gar nicht mit, weil der Empfänger seine Empfindlichkeit noch gar nicht an dein Sendesignal angepasst hat. Je nach Geschwindigkeit deiner AGC braucht der den ersten Teil des Syncsignals, um sich einzupegeln. Erst dann kommt überhaupt irgendetwas sinnvolles am Digitalausgang des Empfängers raus. Die Software muss dann und erst dann - egal was vorher war - im Idle-Zustand sein und darf erst danach auf die Triggerbedingung lauern.
Mitlesa schrieb: > Nur um kurz darauf hinzuweisen was da gemacht wird: ... Der ganze Zirkus sorgt dafür, dass der Hammingabstand größer wird und Fehler auf Grund von Störungen besser erkennbar bzw. korrigierbar sind. Da macht die Sache aber nicht besser, wenn "sauberer" Luft und guten Empfangsbedingungen das Signal nicht ankommt, weil der Empfänger nicht eingepegelt und die Empfangssoftware noch nicht synchronisiert ist.
Wolfgang schrieb: > Der ganze Zirkus sorgt dafür ..... Die Wortwahl spricht dafür was du davon hältst, obwohl du dir bis dahin die Implementierung noch gar nicht angeschaut hast. Wolfgang schrieb: > weil der Empfänger nicht > eingepegelt und die Empfangssoftware noch nicht synchronisiert ist. Nochmal ein Beweis dass du von etwas sprichst wovon du noch wenig bis keine Ahnung hast. "der Empfänger" ist ein Pendelempfänger der im Leerlauf, also ohne Signal, hochempfindlich ist und bei grösser werdendem Signal selbst begrenzt, für diesen Vorgang ist unter anderem das Sync-Feld der VirtualWire Implementierung da. Was wohl den meisten schlechten Implementierungen fehlt ist die in VirtualWire realisierte PLL die für einen beschränkten Zeitraum Sender und Empfänger ziemlich perfekt synchronisiert.
Hans schrieb: > Ich würde gerne die Aussendung der Telegramme auf die Anzahl 3- max.5 > reduzieren. > Der Sender soll später auf einem Tiny laufen und hat nur eine CR3032 und > die soll so lange wie möglich halten. > Der Sender bekommt dann einen Upstepper für den Sender auf 5V. > Wenn meine Berechnungen stimmen, dann hätte die Batterie mit den > jetzigen 10 Telegrammen je Aussendung eine theoretische Lebenserwartung > von etwas über einem Jahr wenn es eine Aussendung pro Tag gibt. > Zum Hintergrund, es soll ein Briefkastenalarm werden. Welche Perversion. Da quäle ich mich herum mit Assembler-Codierung, erfinde das Rad neu, versuche Code in einen möglichst kleinen Controller zu quetschen, zuzele (von Zuzeln, Aussaugen) eine arme kleine CR2032 aus um 5V zu gewinnen, alles nur um ein möglichst kleines Kästchen zu bekommen. Das muss ein ärmlicher Briefkasten sein in dem ich keinen Platz finde einen Controller und eine angemessene Batterie für eine anständige Betriebsdauer unterzubringen - ohne mit den Mikro- amperes hadern zu müssen. Wenn es dem Esel zu bunt wird geht er aufs Eis zum tanzen. Wenn man keine Probleme hat dann macht man sich eben welche.
> Wenn ich hier sehe wie da herumgepfuscht wird kann > ich nur dringendst empfehlen sich die VirtualWire > Implementierung anzusehen. Für jemanden, der noch nicht gut programmieren und analysieren kann, ist die richtige Verwendung einer fremden Library unter Umständen noch schwieriger, als es selbst zu machen.
Angehängte Dateien:
-
Einschwingen.png
50 KB
Ich möchte das Unverständnis einiger hier ein wenig erklären... Post Kunde schrieb: > Da quäle ich mich herum mit Assembler-Codierung,... Für mich ist es keine Qual. Im Gegenteil es macht Spaß jedem Takt ins Auge zu sehen. C habe ich nie gelernt, gut, könnte man lernen. Compiler haben mir aber nie gefallen, da sie eine Menge Overhead produzieren, und man nicht wirklich weis was er an Code wegschreibt. Klar ist es angenehmer in einer Hochsprache zu schreiben wenn man schnell etwas erreichen will. Es geht mir sicher auch nicht darum das Rad neu zu erfinden, wenn es hier vieleicht auch so aussehen mag. Ich möchte eine solche Aufgabe Schritt für Schritt selber machen, verstehen und dadurch lernen. Wenn ich auf fertige Dinge zurückgreifen würde, würde ich mir eine Funkklingel kaufen, anpassen und gut ist. Da bräuchte ich noch nicht mal irgendwelche Librarys. Auch ist der Briefkasten sicher groß genug um da eine Batterie für 20 Jahre Lebensdauer unterzubringen. Aber darum geht es doch garnicht. Es gibt viele Varianten etwas zu realisieren. Die Aufgabenstellung hier ist aber eben die beschriebene auch wenn man es sich leichter machen könnte. 100Km mit einem Benziner zu fahren und 15Liter verbrauchen wird kein Thema sein, das ist nicht schwierig... 5Liter wird dann schon eine Herausforderung. So muss man es sehen. Es ist eine Aufgabe die es gilt mit sportlichem Ehrgeiz zu lösen. Ich könnte auch einfach wie bisher in den Briefkasten schauen ob was drin ist... Genug davon. Was "Mitlesa" heute um 13:07 geschrieben hat, gefällt mir gut. Es beschreibt genau das Verhalten des Empfängers. Ich habe von HF leider überhaupt keine Ahnung! Könntest du das von dir angesprochene Thema "PLL" vielleicht bitte mal ein wenig erläutern oder aufzeigen wo man nachlesen kann was da passiert ? Aus dem Datenblatt des Empfängers ist nichts darüber zu entnehmen. Ich habe ein Bild angehängt welches auf etwas ungewöhnliche Art und Weise deutlich zeigt, dass da über einen längeren Zeitraum sowas wie ein Einschwingverhalten beim Empfänger stattfindet. Es zeigt die Spectralansicht der 10 Telegramme am Ausgang des Empfängers. Das ist auf ähnliche Art auch bei anderen Protokollen zu sehen. Diese Zeit gilt es sinnvoll zu überbrücken bzw. so kurz wie möglich zu halten. Vielen Dank für eure Beteiligung, Aufmerksamkeit, Verständnis und Mühen.
@ Joe Der Bullshit der in der debug.png zu sehen ist <1>1>0... passiert in den 3ms Pause. Erkennt man daran, steht immer hinter dem 10. Tele.
Hans schrieb: > Ich habe ein Bild angehängt welches auf etwas ungewöhnliche Art und > Weise deutlich zeigt, dass da über einen längeren Zeitraum sowas wie ein > Einschwingverhalten beim Empfänger stattfindet. > Es zeigt die Spectralansicht der 10 Telegramme am Ausgang des > Empfängers. > Das ist auf ähnliche Art auch bei anderen Protokollen zu sehen. Ach SOOO. Sag mal, um Strom zu sparen nimmst du dem Sende-Modul ja vermutlich die Versorgungsspannung weg. Dabei ist zu beachten (Datenblatt...): Turn on Time: 20ms Mach einfach mal den Saft 20ms vor dem Senden an. Energie kann man in deinem Fall ja ganz prima sparen, indem sich der Briefkasten nicht allzu oft (z.B. nur alle 5 Minuten, und auch nur wenn Post da ist) meldet. Einschreiben-Rückschein werden ja nach wie vor bis an die Türe getragen ;-) Und wie sieht's denn gererell aus mit Abblockkondensator und so?
:
Bearbeitet durch User
Hans schrieb: > Ich habe von HF leider überhaupt keine Ahnung! Das merkt man gleich. Zeigst ein Foto wo sich jeder selbst einen Reim draus machen muss. Zeigst weder Messpunkt noch Darstellungsart der Y-Achse. Beschreibst nicht was da zu sehen sein soll. Aus dem Diagramm erkenne ich wirklich nichts, rein gar nichts. Ausser die Zeitachse. Dann bezeichnest du noch eine Darstellung im Zeitbereich als Spektraldarstellung. Sehr seltsam. Hans schrieb: > Könntest du das von dir angesprochene Thema "PLL" vielleicht bitte mal > ein wenig erläutern oder aufzeigen wo man nachlesen kann was da passiert > ? Wie eine PLL funktioniert kann man überall im Internet nachlesen. Hier nur soviel zu Virtualwire: Durch Oversampling wird im Sync-Feld die zeitliche Mitte eines Bits ermittelt und als Bezugspunkt genommen um den folgenden (Daten-) Bitstrom zu sampeln. Alle heutzutage implementierten Seriell-Schnittstellen arbeiten nach diesem Prinzip, nur dass die Bit-Mitte vielleicht anders ermittelt wird. Hans schrieb: > Aus dem Datenblatt des Empfängers ist nichts darüber zu entnehmen. Das hat auch mit dem Empfangsmodul nichts zu tun. Wir haben es hier nicht mit einer PLL-Schaltung zu tun sondern mit einer in Software realisierten. Wer lesen kann ist klar im Vorteil. Mitlesa schrieb: > die in VirtualWire realisierte PLL
Joe F. schrieb: > Und wie sieht's denn gererell aus mit Abblockkondensator und so? Was ist das? Kann man Abblockkondensator essen?
Joe F. schrieb: > um Strom zu sparen nimmst du dem Sende-Modul ja vermutlich die > Versorgungsspannung weg. > Dabei ist zu beachten (Datenblatt...): Turn on Time: 20ms Mach ich klar, die 20ms hab ich schon gesehen und berücksichtige sie auch. Ist zwar ne lange Zeit, aber solange der keine 1 am Eingang hat braucht er auch so gut wie nix. Bei 1 aber gut 20mA. Und das ist bei meiner pfenigfuchser uA Rechnerei ne Hausnummer. Eben darum so wenig wie nötig senden. Abblockkondensator ? Wo? Wozu?
Mitlesa schrieb: > Was ist das? Kann man Abblockkondensator essen? Dafür dass du eine so große Klappe hast ("Wie eine PLL funktioniert kann man überall im Internet nachlesen.") ist deine Frage dann erstaunlich bescheuert. Hans schrieb: > Abblockkondensator ? > Wo? Wozu? Vor dem Sendemodul. Um zu verhindern, dass die Spannung am uC einbricht, wenn das Modul Strom zieht (Einschalten/Senden). Gibt's einen Schaltplan zu Sender & Empfänger (-Aufbau)?
Bevor das hier in Verbaleskalation ausartet... Ich bitte um Nachsicht das ich nicht alles 100% perfekt zum Ausdruck bringe. Ein wenig Grundverständniss setze ich schon voraus. Es ist hier schliesslich kein Forum für Sozialpädagogen... Wenn etwas unklar ausgedrückt ist oder erscheinen sollte, bitte bei Interesse nachfragen.
Joe F. schrieb: > ist deine Frage dann erstaunlich bescheuert. Manche kapiern's, mancher lernt's nie.
Mitlesa schrieb: > Manche kapiern's, mancher lernt's nie. Ich meinte dich (Mitlesa) damit. Und jetzt lass' doch deine unnützen Kommentare mal bitte einfach stecken.
@ Joe Verstehe, nein den gibt es bisher nicht. Würde aber sicher nicht schaden. Es gibt bei noch voller Batterie keinen Erforderniss dazu. Und derzeit hängt alles noch an 5V Festspannung. Der Prototyp im Briefkasten hält mit der CR bisher seine Spannung.
Was mich halt wundert: dein Spektrogramm ist ja das Ausgangssignal des Receivers, d.h. die Bitrate deines Daten-Signals + die Obertöne (da Rechteck). Die dargestellte Frequenzänderung am Anfang (Einschwinger) würde sich also auf die Bitrate beziehen. Und die wird ja alleine durch deinen uC im Sender bestimmt, der 433 MHz Sender hat da keinen Einfluss darauf, und der Receiver auch nicht. Spiele doch mit der Wartezeit nach dem Einschalten des Sendemodules etwas herum (+20ms, +50ms, +100ms), ob sich dann an diesem seltsamen Verhalten etwas ändert. Heisst ja nicht, dass es später so bleiben muss, aber damit man mal dahinterkommt, wodurch es ausgelöst wird. Der Startpuls und die Präambel können es ja nicht sein, die kommen ja auch später immer wieder.
:
Bearbeitet durch User
Joe F. schrieb: > der Receiver auch nicht. Ich glaube doch. Wie gesagt, ich habe keine blasse Ahnung von HF. Und ich weis nicht was ein Pendelempfänger ist und wie er funktioniert. Aber dieser Pendelempfänger regelt bei Empfang den Pegel scheinbar auf ein verständliches Mass ein. Dazu braucht er scheinbar seine Zeit. Über genau dieses Verhalten wüsste ich gerne mehr. Speziell auf das Modul bezogen. Wie möchte das Modul angesprochen/zugetextet werden, damit es so schnell wie möglich die optimale "Mitte" gefunden hat. Dazu steht im Datenbaltt aber eben leider nichts. Hier wären mal Meinungen und Erfahrungen von Funkamateuren gefragt. Das sind doch alles HF Freaks oder ? Heute ist aber der Strom aus, die Birne muss auch mal was anderes tun. Morgen werde ich mal versuchen was passiert wenn die Nutzdaten CCAA..AA sind CCAA deswegen weil es zum einen von 1100 auf 1010 um 100% "runter" geht, und zum anderen gefällt es mir wegen der historischen Nähe zu Köln... :-)
Hans schrieb: > Wie gesagt, ich habe keine blasse Ahnung von HF. Ist Dein Briefkasten vollständig aus Blech? Falls ja, dann hat der auch keine Ahnung von HF und behält sie für sich in seinem Inneren. :)
@Joe Deine Interpretation des Spektogramms ist genau das was ich auch denke. Es wird ja die Frequenz (Bitrate) im Verlauf der Zeit gezeigt. Und die wechselt. Am Anfang schnell rauf und dann laaaangsam runter. Das scheinen die Anpassungen zu sein, die der Pendelempfänger vornimmt um seine "Mitte" zu finden.
Hans schrieb: > Wie gesagt, ich habe keine blasse Ahnung von HF. > Und ich weis nicht was ein Pendelempfänger ist und wie er funktioniert. > Aber dieser Pendelempfänger regelt bei Empfang den Pegel scheinbar auf > ein verständliches Mass ein. > Dazu braucht er scheinbar seine Zeit. Ja, den Pegel, aber nicht die Frequenz. Du misst ja die Frequenz am Ausgang deines Moduls, also des demodulierten Daten-Signals. Und die Frequenz des Daten-Signals (Bitrate) kommt vom Sender. Kannst ja mal Spaßeshalber dein Spektrogramm vom Eingang des Sendemoduls aufzeichnen. > Über genau dieses Verhalten wüsste ich gerne mehr. > Speziell auf das Modul bezogen. Meine momentane Vermutung ist, dass das Sende-Modul beim Einschalten ordentlich Strom zieht, und deinen uC aus dem Tritt bring (Quarz läuft kurzfristig schneller oder was weiss ich). Daher -> einfach mal länger warten und gucken ob es was bringt. Hans schrieb: > Und derzeit hängt alles noch an 5V Festspannung. Das nützt nichts, denn auch da ist ein Kabel und Leiterbahnen dazwischen mit entsprechender Induktivität, die kurze Stromspitzen nicht durchlassen und du damit ohne Abblockkondensator in der Nähe des Moduls (sehr kurzzeitige) Spannungseinbrüche hast.
:
Bearbeitet durch User
Herr B. schrieb: > Hans schrieb: >> Wie gesagt, ich habe keine blasse Ahnung von HF. > > Ist Dein Briefkasten vollständig aus Blech? Falls ja, dann hat der auch > keine Ahnung von HF und behält sie für sich in seinem Inneren. > > :) Hallo Herr Barium, ja, er ist vollständig aus Blech... ... mit jeweils einem kleinen Loch in den Ecken wo man die Antenne rauslegen kann ;-P
Vielleicht liegt es auch am Sende-uC selbst. Ich nehme an, du legst den die meiste Zeit schlafen, evtl. braucht die PLL eine gewisse Zeit den Systemtakt einzuregeln, nachdem er aufwacht.
Joe F. schrieb: > Ja, den Pegel, aber nicht die Frequenz. Ok, sehe ich ein. Dennoch denke ich, dass er an den Flanken "arbeitet" und somit die Frequenz kürzer oder länger macht. Ist ne Vermutung. Joe F. schrieb: > Sende-Modul beim Einschalten > ordentlich Strom zieht, und deinen uC aus dem Tritt bring Das ist sicher nicht ausgeschlossen. Halte ich aber eher für unwahrscheinlich, da die AVRs auch mit 3,3V und weniger zuverlässig arbeiten. Das werde ich aber mal überprüfen. Stromspitzen... Die merkwürdigsten Fehler kommen meiner Erfahrung nach in allen Bereichen aus der Stromversorgung. Ich verbaue zum testen mal einen fetten Pufferkondensator um das auszuschliessen.
Joe F. schrieb: > Meine momentane Vermutung ist, dass das Sende-Modul beim Einschalten > ordentlich Strom zieht... Das könnte durchaus sein und die CR Zellen mögen so was gar nicht.
@ Dieter Werner Das ist im Moment ja noch nicht der Fall. Derzeit hängt alles an festen 5 Volt.
Hans schrieb: > Ok, sehe ich ein. > Dennoch denke ich, dass er an den Flanken "arbeitet" und somit die > Frequenz kürzer oder länger macht. > Ist ne Vermutung. Ja stimmt, das könnte auch sein. In diesem Fall müsstest du deinen Decoder toleranter gegenüber kürzeren High Phasen machen. Die Grundfrequenz ändert sich dadurch nicht, aber die Oberwellen, und genau danach sieht es auch aus.
:
Bearbeitet durch User
Angehängte Dateien:
-
Remote_433_1.png
23 KB -
Remote_433_4_chan.JPG
62 KB
Hi, ich hatte mal einen Empfänger für einen billigen Handsender mit pt2262 protokoll (s. Bild nur Sender) zur Steuerung 2er Servos auf einem Attiny 2313 programmiert. Der funktioniert ohne Probleme. Habs mal im Anhang, falls du mal reinschauen möchtest. Das Protokoll ist einfach. 4ms low, dann 16bit Adresse, dann 8bit Daten (4 Tasten ABCD, jew. 2bit pro Taste auf 1). 0= 170µs high 520µs low 1= 520µs high 170µs low ca. Werte (gemessen) Kurzbeschreibung. status=0 -> warten auf 4ms low durch Pinabfrage und Timervergleich status=1 -> danach INT1 Interrupt Flankenwechsel einschalten und auf nächste Flanke warten. Bei jedem Flankeninterrupt status hochzählen, Zeit des Highimpuls (ungerade status Werte) auswerten und in die 3 Ergebnisbytes schieben. Low Impuls wird nicht ausgewertet. Bei status 50 ist alles empfangen. ---------------- Im letzten Urlaub hatte ich einen FAAC Parkschrankensender, der sich seltsamerweise nicht mit einem lernfähigen 433Mhz Sender kopieren liess, auf einem Attiny13 programmiert. Sendemodul ist ein 1€ Teil. http://www.ebay.de/itm/3V-5V-315Mhz-433Mhz-MINI-Wireless-Transmitter-Receiver-Module-Transceiver-Board-/331697816221 Ich hatte noch ein altes IR Fernsteuerprogramm, dass liess sich leicht anpassen. Leider ( für mich eigentlich nicht) kann ich auch kein C, deswegen alles in Assembler. Hat mir bis jetzt auch immer gereicht. All das hat auch ohne Beachtung von HF Sachen, Einschwingvorgängen oder Plastik oder Metallbriefkästen relativ zügig funktioniert. Allerdings tatsächlich nur mit Abblock Kondensator, ohne ist der Tiny immer beim Senden abgestürzt. Ausserdem möchte ich nochmal bemerken, dass unter 12V Senderspannung gar nichts ging (auch nicht direkt neben dem Empfänger). Auch kann ich mir nicht vorstellen, dass sich 1-2 mal am Tag 5 oder 10 Telegramme zu senden arg unterschiedlich auf die Batt. Lebensdauer auswirkt. Die 12V Batt im Garagentor Sender hält auch ein Jahr und sendet bestimmt 100 Telegramme beim Drücken. Da würde ich eher die 3ms Wartezeit nach dem Start weglassen. (keine Ahnung für was die sind) viele gruesse HerrMueller
:
Bearbeitet durch User
Hans schrieb: > Dazu braucht er scheinbar seine Zeit. > Über genau dieses Verhalten wüsste ich gerne mehr. > Speziell auf das Modul bezogen. Dann Sende ein Bitmuster mit Zeitmarken drin und guck dir mit Hilfe eines LA/Oszi o.ä. am Digitalausgang des Empfängers an, ab welchem Zeitpunkt nach dem Start des Bitmusters der Empfänger die Folge sauber mit bekommt. Evtl. hängt diese Zeit von der Signalstärke ab, d.h. das Verfahren liefert möglicherweise unrealistische Werte, falls Sender und Empfänger direkt nebeneinander auf dem Basteltisch liegen.
Problem gelöst ! alle Überlegungen hätten zwar alle so ein Verhalten auslösen können, aber das Problem sitzt wie meist vor der Tastatur. Soviel Dusseligkeit ist schon schmerzhaft. Alle Schande über mein Haupt ! Her damit... Aber wie das so ist, man liest 1000 mal über den Fehler weg bis einem irgendwann ein Licht aufgeht. Es war ein selten blöder Fehler in der Software, der sich ungünstigerweise fast immer auf die ersten 5 Telegramme ausgewirkt hat. Erkannt wurden sie schon die ganze Zeit immer richtig, nur bei der Auswertung passierte dann der Fehler. Die Telegramme werden nicht on the fly ausgewertet. Die Software beginnt, mit der ersten steigenden Flanke nach dem Präambelstopsignal, die Zeiten der Signallängen zu messen und speichert diese 64 Messwerte im RAM. Danach erfolgt erst die Auswertung und Umsetzung in Daten. Dadurch konnte ich ein debuging machen, was mir beim richtig erkennen eines Telegramms, die Zeiten des voherigen nicht richtig erkannten anzeigte. Die manuelle Auswertung der Zeiten zeigte aber, dass das vorherige richtig eingelesen wurde. Also musste der Fehler in der Auswertung liegen. Jetzt werden, bis auf das erste, immer alle Telegramme 100% erkannt. Ich bitte alle um Verzeihung, eure Zeit mit meiner nachlässigen Dusseligkeit beansprucht zu haben. Dennoch waren im gemeinsamen Brainstorm sehr viele interessante Gedanken dabei was es alles hätte sein können, und wie man sich einem solchen Problem in kleinen Schritten nähert. Vielen Dank für eure Mühen.
Hans schrieb: > Jetzt werden, bis auf das erste, immer alle Telegramme 100% erkannt. Da bleiben jetzt noch 2 Fragen: a) warum klappt's beim ersten Telegramm nicht? b) woher kommt diese ominöse Spektrumveränderung am Anfang der Übertragung Vermutlich hängt das zusammen. Wenn du mal Zeit hast, würde ich mir an deiner Stelle mal eine Hochsprache (gängigerweise C) angucken. Ein solcher Decoder nimmt in C in etwa 20-50 (idealerweise selbsterklärende) Zeilen ein. Assembler-Programmierung in Ehren, aber um da Fehler zu finden, muss man sich ja schon sehr auf die Kommentare des Autors verlassen, und ich finde es sehr anstrengend, dass man verschachtelte Strukturen (Schleifen, Bedingungen) einfach sehr schwer sehen kann. Und Registernamen sind einfach deutlich weniger sprechend als Variablennamen.
Oftmals lässt sich das abkürzen, wenn man andere über den Code schauen lässt...
Joe F. schrieb: > a) warum klappt's beim ersten Telegramm nicht? > b) woher kommt diese ominöse Spektrumveränderung am Anfang der > Übertragung Das scheint dann vermutlich wirklich an der diskutierten Thematik eines Einschwingens des Empfängers zu liegen. Wenn man sich den Anfang einer empfangenen Übertragung anschaut, egal von welchem Sender er kommt, dann sind da zwischen 50-150ms unbrauchbare Bits. Zumindest sieht das hinter meinem Empänger so aus. Was deine Argumente in Bezug auf die Lesbarkeit angeht, so ist das in C sicher einfacher zu erkennen und nachzuvollziehen. Andererseits könnte man sich ja auch mal ein wenig disziplinieren und nicht wie ich so ein rudimentäres Gestammel als Doku hinterlassen. Da blickt man dann selber nicht mehr durch wenn man da nach einiger Zeit noch mal dran muss. Ich gelobe Besserung :-) Auch in Assembler muss man nicht mit Registernamen arbeiten, auch da kann man wunderbar Variablennamen verwenden. In C ist dann auch der Quellcode nicht so lang, da stimme ich dir zu. So, mittlerweile versteht der Empfänger auch den Autoschlüssel. Also beide Protokolle gleichzeitig. Die Idee dahinter... Da ich ja eh schon auf 433 zuhöre, warum dann nicht auch den Autoschlüssel. So soll dann, wenn ich Heim komme und innerhalb von 5 Sekunden 2mal hintereinander "Auto zu" drücke, die Haustür aufgedrückt werden. Die Gegensprechanlage ist aber auch ein Bussytem. Also geht es jetzt daran das Kommando "Tür aufdrücken" auf diesen Bus zu schicken. Das passende Telegramm habe ich mal vom Bus abgegriffen und aufgezeichnet und werde es jetzt einfach stur nachbilden ohne mich mit dem Protokoll zu beschäftigen. Das sind nur ein paar Bit. Ich lerne doch keine komplette Fremdsprache nur weil ich mir ein Bier bestellen will :-)) Oder kennt sich jemand mit dem Busprotokoll von TCS aus? Im Netz hab ich nichts brauchbares darüber finden können. Ist wohl zu exotisch so eine Anwendung und es hat sich noch niemand tiefer damit beschäftigt.
Hans schrieb: > Da ich ja eh schon auf 433 zuhöre, warum dann nicht auch den > Autoschlüssel. > So soll dann, wenn ich Heim komme und innerhalb von 5 Sekunden 2mal > hintereinander "Auto zu" drücke, die Haustür aufgedrückt werden Dazu wäre mir die Batterie im Autoschlüssel zu wertvoll... Aufpassen muss man auch, wenn man das zu oft außer Empfangsreichweite des Fahrzeuges macht. Dann kommst du evtl. aus dem Fenster für den Rolling-Code raus, und dann musst du den Schlüssel neu synchronisieren. Wobei ich gar nicht weiss, ob heute überhaupt noch Rolling-Code verwendet wird, oder generell ein bidirektionales auf Verschlüsselung basierendes Verfahren. Eigenes Thema. Hans schrieb: > Das passende Telegramm habe ich mal vom Bus abgegriffen und > aufgezeichnet und werde es jetzt einfach stur nachbilden ohne mich mit > dem Protokoll zu beschäftigen. Man sieht: langweilig wird dir nicht. Die Schwierigkeit bei solchen Sprechanlagen ist allerdings oft: wie koppelt man das eigene Signal in den Bus ein. Da gab es schon Leute hier, die haben sich die ganze Sprechanlage im Mehrfamilienhaus zerschossen. Naja, man darf auf deine kommenden Threads gespannt sein. ;-) Schönes WE noch.
:
Bearbeitet durch User
Joe F. schrieb: > Dazu wäre mir die Batterie im Autoschlüssel zu wertvoll... Da habe ich keine Erfahrung wie lang so eine Batterie hält. Bei meiner umAsek Rechnerei zählt natürlich auch da jede Aussendung. Sie ist aber sehr einfach austauschbar und ist eine handeslübliche Knopfzelle. Joe F. schrieb: > Dann kommst du evtl. aus dem Fenster für den Rolling-Code raus, Das wird nicht passieren, da mein Parkplatz vor der Tür ist. Das ist aber gut zu bedenken. Joe F. schrieb: > wie koppelt man das eigene Signal in den Bus ein. Die Frage habe ich mir im Vorfeld auch gestellt. Das Protokoll wird auf dem Bus mit einem definierten "Kurzschluss" erzeugt und die Spannung wird von 12V auf 8V runter gezogen. Das werde ich vermutlich mit einem Optokoppler realisieren. Ich werde berichten wenn Tag der offenen Tür ist :-))
The Door is open ! Wenn es auch länger gedauert hat als gedacht. Der richtige Kniff das Signal auf den Bus zu bringen hat seine Zeit gebraucht. Mit Widerständen ging es nicht. Und es ist so simpel. Einfach mit einem NPN Transistor eine 8V Zehnerdiode, auf den Bus legen und so die Bits draufknüppeln. Die Ruhespannung ist nicht, wie falsch angegeben, 12V sondern 24V. Erschreckend einfach... Wenn ich das Kommando der Anlage kenne, kann ich an einer x-beliebigen Anlage an der Haustür das Klingeltableau öffnen und das Signal auf den Bus geben. Und offen ist die Tür ohne Einbruchsspuren ! Jedes Kommando sendet aber die Zielgeräteadresse mit, und die variert vermutlich von Anlage zu Anlage ein wenig.Da das aber nur ein paar Bits sind, ist das mit Bruteforce in wenigen Millisekunden erledigt.
Ich hatte nach langen Recherchen schon fast aufgegeben Informationen über den Bus zu finden. Dann bin ich aber auf eine Patentschrift von TCS aus dem Jahr 1996 gestossen und da war es mit der Zehnerdiode erklärt.
Hans schrieb: > Anlage > an der Haustür das Klingeltableau öffnen und das Signal auf den Bus > geben. > Und offen ist die Tür ohne Einbruchsspuren ! > Jedes Kommando sendet aber die Zielgeräteadresse mit, und die variert > vermutlich von Anlage zu Anlage ein wenig.Da das aber nur ein paar Bits > sind, ist das mit Bruteforce in wenigen Millisekunden erledigt. "Aber das macht doch keiner!!!"... würde der Hersteller vermutlich sagen. Ja, die "Sicherheit" bei solchen Anlagen ist erschreckend, ich kenne da noch andere krasse Beispiele, die ich jetzt hier nicht veröffentlichen möchte. Bekannter Klassiker ist "Zugriff auf CAN-Bus eines verschlossenen Fahrzeuges über Steuerleitungen im Aussenspiegel". Oder auch Nachbar ruft von aussen "Alexa, open door!".
:
Bearbeitet durch User
Beitrag #5132704 wurde von einem Moderator gelöscht.
Jo! Sicherheit... Der CCC (ich glaube die waren es) hatte mal eine Abhandlung über einen Angriff über die Reifenluftdrucksensoren/aktoren eines Autos vorgestellt. Auch schön, das geht dann drahtlos. Aber gut, die kriminelle Energie fordert immer mehr Wissen und Können um Hindernisse zu umgehen. Ein altes schnödes Schloß bekommt jeder mit nem Polenschlüssel auf. Von daher ist das "Jammern auf sehr hohem Niveau". Die Jungs aus der Fraktion "ich war in der Schule oft Kreide holen", haben da eher keine Chance. Beschaffungskriminelle wohl auch nicht. Aber die Liga ein par Etagen darüber baut Gerätschaften die ein solcher Typ bedienen kann... Erschreckend, dass Leute mit soviel Grips zu wenig Geld haben und solche Machenschaften mit ihrem Wissen unterstützen. Alexa... Auch so ein Thema... Spracherkennung, Analyse... Wer stellt sich sowas in die Bude ??? Wie minderbemittelt ist das Gro der Menschen ? Iphone Fingerabdruckscan... und Schwups ist der Fingerabdruck bei der NSA. Handys wo man den Akku nicht rausnehmen kann... Was so direkt um uns herum passiert, interessiert die meisten aber LEIDER nicht. Sie sind aus dieser Betrachtungsweise heraus gesehen einfach taub. Der Klassiker als Antwort ist immer:"Ich hab doch nichts zu verbergen" Darauf antworte ich immer gerne, das haben die Juden damals auch gedacht. Hätte der Gasmann aus Wien damals die Möglichkeiten von heute gehabt...
Jetzt habe ich Schwierigkeiten das Ganze an die Stromversorgung der Gegensprechanlage anzubinden. Die Schaltung funktioniert jetzt zwar perfekt, aber wenn ich sie von der Gegensprechanlage mit Strom versorgen lassen will, bringt sie Störgeräusche und Pfeifen in die Anlage. Die Anlage liefert über eine seperate Leitung Saft für Verbraucher die etwas mehr brauchen. In den Spezifikationen werden 60mA zugesichert. Ca. 50 brauche ich im Dauerbetrieb. Die restlichen mA (bis ca.100) die ich beim Senden ins Wlan brauche hole ich aus einem Kondensator mit 0,47F. Wobei die Anlage ja bestimmt auch noch Reserven hat. Die Anlage pfeift aber schon, wenn ich nur ca. 20mA abgreife. Ich benutze in der Stromversorgung einen Step/down von 24V auf 5V. Der schaltet natürlich wild und strahlt "nach Hinten". Das habe ich versucht mit einer in Reihe geschalteten Induktivität von 47uH abzublocken. Auf dem Oszi sieht das auch prima aus, es pfeift aber trotzdem. Ganz grob geschätzt bei ca. 1Khz. Akustische Rückkopplung ist es aber nicht. Beim "Reinpusten" verändert sich die Frequenz leicht. Im Moment habe ich noch keine Idee was es sein könnte. Über Anregungen würde ich mich freuen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.