Hi, ich komme einfach nicht weiter. Ich habe eine Wetterstation hier, deren Sensoren ich gern selbst dekodieren würde. Nur fehlt mir echt der Ansatz wie ich das hinbekomme. Der AM Empfänger gibt dauerhaft so ein ekliges Pfiepen von sich, nur kurz unterbrochen von den Sensorsignalen, welche ich dekodieren will. Hatte die Hoffnung mittels Transistor und Poti an dessen Basis das Pfiepen soweit runter zu drehen, das es nicht mehr hörbar ist (hab mal Ohrhöhrer über Transistor + Poti an den Ausgang des Empfangsmoduls geklemmt). Gut, da war dann das Pfiepen weg, aber die Sensorsignale waren damit dann auch weg. Bleibt also nix anderes übrig als den Atmega8 permanént den Pin abzufragen und auf die Präambel (10x0) zu warten. Das Signal ist folgendermaßen aufgebaut: 1Bit= 1220,7us entsprechend 819,2Hz, bestehend aus 854,5uS HIGH + 366,2uS LOW = 0 bzw 366,2uS HIGH + 854,5uS LOW =1. Genaue Beschreibung des zu dekodierenden Signals hier: http://www.f6fbb.org/domo/sensors/ws_signals.php Programmiersprache ist Bascom und da ich mich mit C und ASM kein bischen auskenne, wären mir Beispielprogramme zur Dekodierung solcher Funktelegramme natürlich in Bascom am liebsten. Wenn jemand einen Beispielcode in Bascom für mich hätte, in welchem ein Funktelegramm über ein AM Funkmodul empfangen und dekodiert wird, wäre ich sehr dankbar.
Stefan S. schrieb: > Wenn jemand einen Beispielcode in Bascom für mich hätte, in welchem ein > Funktelegramm über ein AM Funkmodul empfangen und dekodiert wird, wäre > ich sehr dankbar. Ich kann kein Bascom, aber das Dekodieren solcher Signale ist ein Job für den Timer. Du baust eine Routine, die die Länge des High Signales misst und verwirfst alles (bzw. startest den Empfang des Signales neu), was nicht innerhalb der Zeiten für ein low Bit oder ein high Bit ist, denn es muss sich um einen Übertragungsfehler handeln. Das Ergebnis rollst du in einen Buffer, der mindestens so lang ist, wie das zu erwartende Signal.
Dennis schrieb: > Ist kein AM. Ist nur OnOffKeying. Träger da oder nicht. Genau das ist AM. Und zwar mit Modulationsindex von 100%. Am bedeutet nicht "analog", sondern Amplitudenmodulation. Und den Träger ein- und ausschalten ist eben eine 100%-Modulation mit einem digitalen Signal. Genau wie bei FM, da wird eine FM mit einem digitalen Signal statt einem analogen dann als FSK bezeichnet (frequency shift keying). Der Oberbefriff ist aber FM. Und der Oberbegriff in unserem Fall hier ist AM.
wie sieht denn der Empfänger aus? Es gibt AM Module die haben einen digitalen Ausgang den du direkt auswerten kannst. Z.B. von Aurel (Farnell, HBE), Vellemann (Conrad) oder auch das beliebte RFM12 (eBay). Per ICP kann man dann die Pulse-Pausen messen und auswerten. Bascom kenne ich nicht, das hat evtl. auch eine fertige Funktion dafür.
Hi, also der Empfänger ist ein ELV HFS301, welchen ich aus meinem defekten WS2500 PC-Funkinterface habe. Hat auf der Platine gar einen Lötpunkt für eine einfache Drahtantenne. Mein bisheriger Ansatz war, mit Bitwait zu warten bis der Pin auf log. 1 wechselt. Danach misst Pulsein, wie lange der Pin auf log. 1 steht. Da Pulsein in 10uS Abständen misst, sollte er bei einem 0 Bit, auf ca 85 kommen. Da ich jetzt nicht von exakt 850uS ausgehen kann, habe ich den Wert auf größer 83 UND kleiner 87 geprüft. Stimmt diese Bedinungung, wird eine Variable namens "count" hochgezählt, andern falls wird diese Variable auf 0 zurück gesetzt. Wird nun eine Präambel, bestehend aus 10 mal log. 0 empfangen, so müsste Count den Wert 10 aufweisen. In der Praxis sah es leider bisher noch nicht so aus. Aber in der Nacht kam mir die Idee, den Empfänger mal auf Batteriebetrieb umzustellen um damit den Störsignalen aus dem Netz zu entgehen und zugleich den Ausgangspin den Moduls über einen Widerstand nach Masse zu ziehen. Theoretisch sollte dies für ein deutlich sauberes Signal sorgen, mit dem ich dann vielleicht zumindest die Präambel erstmal bekomme.
Eventuell lässt sich die asynchrone serielle Schnittstelle des Controllers dazu verwenden. Eine passende Baudrate einstellen, dass der UART das als 8Bit-Zeichen mit Start- und Stopbit erkennt und dann ein Datenbit in der Mitte auswerten.
Hm, wäre ne Idee. Nur leider ist das Datentelegramm als 4 Bit Nibble aufgebaut, jeweils durch 1 Bit log. 1 voneinander getrennt. Sprich 1 Daten (4 Bit) 1 Daten 1 Daten ... und so weiter. Da passen die 8 Bit der seriellen Schnittstelle leider nicht. Ich probier heute Nachmittag mal die Umstellung auf Batteriebetrieb und den Pulldown Widerstand und dann mal weiter schauen.
Stefan S. schrieb: > Daten (4 Bit) 1 Daten 1 Daten ... und so weiter. Da passen die 8 Bit der > seriellen Schnittstelle leider nicht. Dann versuchs doch mal mit dem 9 bit-Modus der USART im AVR, vorausgesetzt, dein "Füllbit" ist im ganz normalen Bit-Raster und nicht beispielsweise doppelt so lang...
Hey danke. Die Protokolle sind richtig klasse. Ich realisiere die ganze Sache jetzt mit einem Repeater. Dieser empfängt die Datenpakete und sendet sie kurz danach selbst wieder aus. Das Sendemodul habe ich demontiert und an dessen Stelle eine Verbindung zum Atmega16 geschaffen. Hier stimmt die Dekodierung und der Atmega spuckt auch die Werte aus, welche das WS2500-Display anzeigt. Im Atmega sind bisher die Sensoren 1-5 programmiert, da ich diese auch selbst in Betrieb habe. Das Schöne daran, dadurch habe ich nun auch die XOR Checksumme, als auch die Checksumme verstanden. Einem Bau eines eigenen Sensors dürfte damit nix mehr im Wege stehen. Was mich in der Datei allerdings gerade ein wenig verwirrt, wo sind die Unterschiede der Sensoren des Typs1 und des Typs 9? Beides Sensoren mit Thermo und Hygro. Einzigster Unterschied sollte sein, das dem WS2000/WS2500 der Sensortyp 9 nicht bekannt ist und diese diesen Sensor entsprechend nicht anzeigen.
@ Stefan, freut mich dass ich Dir mit der Datei helfen konnte. Da ich in meiner Anlage alle 8 Adressen des Typs 1 belegt habe, habe ich mir für die Entwicklung eines eigenen Sensors den Typ 9 kreiert (steht ja auch Eigenentwicklung), damit ich mir bei Tests meine Anlage nicht störe. Das Protokoll ist bis auf den Typ identisch und daher später schnell an den Typ 1 anzupassen. Es ist korrekt, dass WSxxxx diesen Sensor nicht anzeigt. Habe mir aber einen Empfänger gebaut, der diesen auch Sensor auswertet und über RS-232 ausgibt. Das größte Problem bei der Entwicklung von Sensoren ist den Stromverbrauch möglichst gering zu halten. Gruß NobbyH
@ NobbyH Genau das versuche ich auch gerade. Mir einen Empfänger für die Sensoren zu bauen. Nur rauscht das Empfangsmodul viel zu sehr, als mit dem Atmega16 da brauchbare Daten heraus filtern zu können. Mit angeschlossenen Ohrhöhrer sind die Datenpakete der Sensoren allerdings deutlich zu hören. Derzeit bin ich dabei, dass Timer0 10 mal pro 1220uS (Zeit für 1 Bit) den Pin abfragt. Sollte der Pin in 7 Takten nacheinander log 1 anliegen haben und danach folgt 3x log. 0, dann liegt ein 0-Bit an. Soweit die Theorie. Dies in die Praxis umzusetzen, ist mehr als kompliziert. Folgende Einstellungen habe ich derzeit am laufen: Atmega16: Timer0 mit Prescale=8, vorgeladen mit 195. Der Timer0 läuft. Erkennbar daran, dass seine Interuptroutine den Print Befehl stört, sofern der Timer nicht gestoppt wird. Errechnet habe ich die Werte mit "rnAvr". Bin schon geneigt zu fragen ob Du mir Dein Empfangsprogramm vielleicht per Mail schicken könntest. Andererseits will ich es irgendwie auch selbst hinbekommen... :D.
schon mal über gleichrichter mit eventuellen Komparator der INTx triggert der dann wiederum nen Timer startet nachgedacht grober ablauf: 1. Signal kommt mit HIGHFLANKE INTx löst INT_ISR aus 2. in INT_ISR INTx auf LOWFLANKE einstellen und TIMER starten mit TCNTx = 1µs/bit 3. bei LOWFLANKE löst INT wieder aus und stoppt timer TCNTx lesen 4. TCNTx Auswerten nach 855µs für bit=1 oder 367µs für bit=0 5. und die restliche zeit der periode können weitere kleinigkeiten erledigt werden
So, bin jetzt dabei mich mit der Input-Capture Funktion unter Bascom zu beschäftigen. Was ich aber irgendwie nirgends finde, wie ich den Timer1 so einstelle, dass der übergebene Wert dieser Funktion genau die gemessene Zeit in uS bzw in *10uS ausgibt. Denn dann könnte ich wieder auf die Zeitangaben des Funkprotokolls zurück greifen. Finde nur wieder nichts wo auf die Einstellung des Timers im Falle der Input-Capture Funktion genauer eingegangen wird. Für Interrupts in 10uS Abstand hat mir rnAvr für Timer1 bei 4 Mhz einen Prescaler von 1 und einen Timervorgabewert von 65496 errechnet. Gerade wie ich den Timervorgabewert unter bringe, frage ich mich gerade.
nutze den CTC-Modus (autoreload) für Timer 1 mit Vorteiler 1 und in OCR1xh:l schreibst du den wert 19dez dann bekommst du alle 10µs einen INT und du brauchst dich auch nicht um den NACHLADEWERT kümmern macht dieser Modus selbst. Aber was ist dein Controller und wie sieht dein Signalaufbereitung aus ?
Angehängte Dateien:
-
WS-Receiver.png
17 KB
@Stefan, anbei meine Schaltung. Kannst Dich daran ja bezüglich der Signalaufbereitung orientieren. Programm muss ich auf einem anderen Rechner suchen. Programmiere diese Dinge allerdings immer in Assembler, damit die Timings immer korrekt sind. Ich weiß nicht wie stark Bascom den Code aufbläht. Ein Tipp: Vielleicht findest Du auch Hilfe im Wetterstationsforum http://www.wetterstationen.info/ Gruß NobbyH
NobbyH schrieb: > anbei meine Schaltung. ARef an VCC ist etwas seltsam und von Abblockkondensatoren ist auch nichts zu sehen.
@Wolfgang, völlig korrekt, aber hier ging es ja um den Part der Signalaufbereitung.
Hab mir mal die Schaltung angeschaut. Der verwendete Schmitt Trigger ist eine richtig gute Idee. Damit würde ich vielleicht endlich das Grundsignal weg bekommen und übrig bliebe nur das Nutzsignal. Der Rest wird dann einfach. Aber erstmal das Pfiepen des HFS301 raus filtern... Da ist das eigentliche Problem. Danke für diesen Tip ;).
Stefan S. schrieb: > Damit würde ich vielleicht endlich das > Grundsignal weg bekommen und übrig bliebe nur das Nutzsignal. Du musst immer damit rechnen, das da erstens auch andere Signale kommen und zweitens Störungen. Deine Empfangsroutine sollte also recht kritisch beurteilen, ob es wirklich dein Signal ist oder irgendetwas ungewolltes. Ich bin z.B. gerade dabei, eine X10 Fernbedienung zu dekodieren und habe auf dem Oszi immer wieder Sensorsignale vom Nachbargrundstück (da werde ich mich später mal ranmachen :-P) chris schrieb: > schon mal über gleichrichter mit eventuellen Komparator der INTx > triggert der dann wiederum nen Timer startet nachgedacht Es gibt recht viele Möglichkeiten, so ein Signal auszuwerten. Z.B. hat der Mega16 ja auch den Analog Comparator, der ein Capture Signal auslösen kann, oder ganz simpel einen Interrupt für sich selber. Externe Hardware zur Signalaufbereitung brauchst du eigentlich nur dann, wenn das Nutzsignal des Empfängers nicht ausreicht, um einen MC Eingang durchzusteuern, das ist aber bei dir nicht der Fall.
Angehängte Dateien:
-
WS-receiver_2313.png
12 KB
@Stefan, habe die Basisdatei gefunden, mit der ich damals auch angefangen habe. Vielleicht kannst Du Dir hier die nötige Inspiration holen. Mir hat es sehr geholfen. Im Zweifelsfall Hardware nachbauen und per Programm verwenden. Gruß NobbyH
@ NobbyH ich danke Dir. Auch wenn ich bisher nur Bascom kann, hoffe ich die Vorgänge im Programm zu verstehen. Auch die Schaltung sollte mir weiter helfen. Der AT90S2313, hoffe mal das der kompatibel zum Attiny2313 ist. Weil hab nur einen ISP Prgrammer hier. Bzw, erstmal gucken ob der nicht vielleicht doch gar auch per ISP programmiert werden kann. Hab bisher nur Erfahrungen im ATmega und Attiny-Bereich.
Cool, dann saug ich mir mal nen Assembler Compiler und compilier es mal. Danach drauf auf nen Attiny 2313 und dann mal geschaut was der genau an die serielle Schnittstelle sendet. Die Verwendung beider Interrupts hat mich bezüglich Programmierung eines eigenen Empfängers auf eine Idee gebracht. INT0 eigestellt auf steigende Flanke startet Timer0/1. Dieser ist auf 10uS eingestellt und löst entsprechend aus. Im Timer Ereignis wird eine Variable hoch gezählt. INT1 ist auf fallende Flanke eingestellt und stoppt den Timer und lädt die vom Timer hochgezählte Variable in eine Ergebnisvariable. Der Timer sowie dessen Zählvariable werden auf 0 gesetzt. Die Ergebnis-Variable sollte nun die Zeit des HIGH-Pulses in x*10 uS. Im Hauptprogramm wird nun geprüft ob der Impuls entweder 850uS (log. 0) oder 360uS (log. 1) lang war. Trifft eines von beidem zu, wird das Bit einer weiteren Variable entsprechend gestzt. Zuvor muss allerdings geprüft werden ob 10x ein Puls mit 850uS empfangen wurde. Denn dies ist die Präambel des Datenpakets. Soweit die Theorie. Die Umstzung und Prüfung der Theorie erfolgt aber an einem anderen Tag. Heute ist mal programmierfreier Tag :D.
Bau aber eine gewisse Toleranz bei den Timings ein. Die müssen nicht immer 100% stimmen. z. B. Temperaturdrift bzw. unterschiedliche Beriebstemperaturen, etc.
Hab noch etwas drüber nachgedacht. Da der Interrupt ja fast ständig auftritt, bleibt keine Zeit für ein anständiges Programm. Wird also nur ein kleiner Dekoder (wahrscheinlich wirklich ein kleiner 2313), welcher 0 und 1 des Sensorpakets dekodiert. Den Rest müsste ein nachgeschalteter Controller machen, da dieser dann deutlich mehr Zeit für sein Programm hat.
Ich versuche gerade das Programm mit AVR Studio zu compilieren. Da ich natürlich keine Ahnung von ASM habe, die Frage, was ist an dieser Zeile falsch? ldi temp, (1<<TOV0) ; Timerflag zuruecksetzten Zeile 94 Fehler: D:\eigene Dateien\WS-Receiver.asm(144): error: syntax error, unexpected '\n' Mir scheint, als wären die Semikolons falsch, da er das <TOV0) dadurch als Kommentar ansieht. Anbindung des Attiny2313 an AVR Studio scheint wenigstens schon mal zu funktionieren.
Stefan S. schrieb: > ldi temp, (1<<TOV0) ; Timerflag zuruecksetzten Das liegt daran, das da eigentlich
1 | ldi temp,(1<<TOV0) |
stehen soll. Bisschen weiter unten kommts nochmal, also da auch korrigieren.
Juti, danke. Hat jetzt funktioniert. Programm ist compiliert und auf den Attiny geladen.
Ok, so weit, so gut. Auf RS232 wird auch tatsächlich etwas ausgegeben. Und zwar immer wenn ein Sensor empfangen wird. Nur was genau wird da ausgegeben? Wenn ich den Comport auf 19200 Baud stelle, kommen da nur Herzchen und Hyroglyphen bei heraus. Keine wirklich verwertbaren Daten.
Langsam weiss ich echt nicht mehr weiter... Der Attiny gibt nur Mist seriell aus, ich selbst komme mit meiner Programmierung auch nicht weiter... Scheint mir langsam als wenn "rnAvr" falsche Werte berechnet? Im Kopfhöhrer sind die Signale klar und deutlich zu hören. Werte ich die gemessenen Bitzeiten jedoch aus, kommen Ergebnisse zustande, die den Sensorwerten überhaupt nicht entsprechen. Die sich nichtmal zu 100% ans Protokoll halten. Da wird aus dem immer log. 1 - Stopbitt dann mal eben eine 0 und all son Dreck. Bin mal wieder kurz davor den ganzen Mist in die Ecke zu kanten und doch lieber mit Holz zu bauen. Da bekommt man wenigstens etwas hin und sitzt nicht Tage lang am Rechner ohne irgendwas produktives hin zu bekommen. Das eigentliche Problem ist, dass ich immer noch keine machbare Lösung gefunden habe. Es kommen immer sehr unterschiedliche Werte bei heraus, die alles andere als nah an 854uS oder 366uS dran sind. Egal ob ich Timer0 mit Prescaler=1 und Vorladwert von 216 an int0 und int1 laufen lasse, die gemessenen Bitzeiten passen einfach nie. Bisher habe ich vor allem mit dem Befehl "pulsein" gearbeitet, bzw über int0 (Flanke 0 zu 1) den Timer0 starten und über int1 (Flanke 1 zu 0) stoppen lassen und die vom Timer hochgezählte Variable ausgewertet. Und so krass abweichen können die Werte doch nun auch nicht. Gerade nicht bei der Präambel, die ja aus 10 Nullen besteht. Da kann doch nicht das eine Bit 370uS lang sein und das Nächste 410uS und das drauf folgende volle 500uS lang sein und obwohl eigentlich ein Wert um die 850uS zu erwarten wären...
Angehängte Dateien:
-
Terminal.png
62 KB
Hi,
hab nicht immer Zeit hier zu folgen. Sorry, dass mit den (1<<TOV0)
hatte ich leider übersehen.
Prüfe bitte folgende Punkte:
1.) Hast Du einen 4MHz Quarz verwendet?
2.) Hast Du die Fuses (auf externen Quarz) entsprechend programmiert?
Wenn nicht läuft die CPU mit interner Clock (1MHz). Das hat zur Folge,
dass
1.) die Timings nicht stimmen
2.) mit interner Clock häufig das Timing die seriellen Schnittstelle
nicht stimmt, da Faktor zu ungenau.
Ok, so weit, so gut. Auf RS232 wird auch tatsächlich etwas ausgegeben.
Und zwar immer wenn ein Sensor empfangen wird.
Das ist korrekt.
So, hab mir gerade die Mühe gemacht und meinen alten Empfänger
rausgeholt, ein Empfängermodul draufgelötet und mit dem anhängenden File
programmiert.
Das Ergebnis siehst Du im Screenshot des Terminalprogramms
Übrigens: Das sind die Hex-Daten, die der Sender tatsächlich schickt.
Und wie oben schon erwähnt: Die Fuses richtig setzen
Wenn es mit den geschickten Dateien nicht funktioniert ist Deine
Hardware wahrscheinlich nicht OK.
Kleiner Tipp am Rande: Nicht so schnell die Flinte ins Korn werfen.
Juti, dann schau ich mir das Morgen nochmal an. Auch das Terminal Programm sieht richtig klasse aus. Ist ein wenig was anderes als der Bascom Terminal-Emulator. Quarz hatte ich auf 4 Mhz extern. Aber vermute mal das der Bascom Terminal Emulator die Daten als ASCII dargestellt hat. Erklärt zumindest warum Herzchen und Frage und Dollarzeichen und alles angezeigt wurde.
Hi, weiter die Fuse-Einstellung beachten. clkdiv8 auf aus (Haken weg) sonst nur 1/8 Taktfrequenz
Ja, mit der Einstellung hatte ich immer wieder so meine Sorgen. Bevor ich das compilierte Programm aufgespielt hatte, programmierte ich mir in Bascom noch schnell eine Testausgabe auf seriell. Hatte eine Weile gedauert bis ich in den Fuses auf diese Einstellung aufmerksam wurde. Dies abgeschaltet und schon stimmte auch die Ausgabe. Scheint aber auch nur der kleine Attiny zu haben. Zumindest ist mir beim Mega8/16 solch ein Fusebit noch nicht aufgefallen.
Leider keine Ergebnisse. Der Attiny gibt Daten aus, mit denen ich nix anfangen kann. Auch eine binäre Ausgabe der Daten hilft mir nicht weiter. Ich habe mir einen weiteren 433Mhz Empfänger bestellt. Dieser arbeitet digital und gibt nur dann ein Signal aus, wenn er auch wirklich etwas empfängt. Sobald dieses Empfangsmodul da ist, werde ich einen Mega8/16 eine Flankendetektion durchführen lassen. Bei 0 > 1 wird Timer 1 gestartet und bei 1 > 0 wieder gestoppt und der Wert des Timers ausgewertet. Diesmal wird aber kein Interrupt verwendet. Mal gucken, muss doch irgendwie zu schaffen sein.
Hallo Stefan, einen ganz interessanten Thread habt ihr da! Ich habe vor einigen Jahren mal mit AVRs gearbeitet und bin mittlerweise bei den PICs gelandet. Rein beruflich und nicht wegen besser/schlechter o.ä. AM habe ich selber auch schon empfangen müssen und entsprechend auch die dazugehörigen Störungen. Kann es sein, dass Du an der Stelle hängst? Beim on-off keying bekommst Du während der 0-Bits teilweise grandiose Störungen. Du must fast zwingend oversampling betreiben und das Signal bewerten. Machst Du das schon, das kam bei den Postings nicht klar raus? Funksignale direkt auf Timer oder UARTS zu geben funktioniert eigentlich nie, auch wenn es schön wäre. Probier doch mal einen deutlich schnelleren Timer (faktor 10) und eine Bewertung, wie viele Samples über, bzw. unter fünf waren. Nur um sicherzustellen, dass Störungen herausgemittelt werden. Dein Auswertecode bleibt davon völlig unberührt und kann gleich bleiben. Ich verwende seit Jahren das "docklight" als Monitor für ser. Signale. Damit bin ich immer bestens gefahren und er ist auch in der Basisversion frei. www.docklight.de Viel Erfolg, Christian
Wenn digitale Daten übertragen werden, nennt man die Amplitudenmodulation AM gerne Amplitudenumtastung ASK. :-) Ansonsten ist die Variante mit schnellem Timer und Bewertung nichts anderes als ein gleitender Mittelwert mit Schwellwertbildung über dem Signal.
Ich glaube, das funktioniert nicht, weil die RS232 Beschaltung komisch ist. Schwingt der Quarz? Fuse bits richtig? Ansonsten im Wiki schaun, warum das nicht funktioniert.
@Stefan, die Schaltung und das Programm, das ich Dir geschickt habe funktioniert. Ich habe ja extra für Dich die Software bei mir noch einmal reinprogrammiert und das Empfängermodul eingelötet. Den Screenshot des obigen Empfangsstrings habe ich an dem Tag erstellt als ich den Thread eingestellt habe. Welches Empfängermodul verwendest Du denn? Das HFS301? Achtung, das hat 3,3 V Betriebsspannung. Ich arbeite schon seit Jahren auf der Basis dieser Empfangsdecodierung und habe in abgewandelter Form sowohl Repeater als auch Umsetzer laufen. Stell doch mal ein Foto Deines Hardware-Aufbaus ein.
Das hfs301 hängt an int0 und int1 wie im schaltplan oben dargestellt. Verwendet wird ein kleiner Attiny2313 und das Programm läuft auch. Es wird nicht immer alles empfangen, aber zumindest gibt die Schaltung Daten aus. Bisher habe ich mich am Sensorprotokoll orientiert. 10 mal 0 und dann eine 1 als Präambel und danach die Daten. Muss ich mal gucken was der Attiny so ausgibt. Wie es scheint, gibt er die Daten anders aus als nach Sensorprotokoll mit den ganzen Stopbits im Datentelegramm.
Ich habe sowas auch schon mal gemacht. Allerdings mit einem etwas teureren Empfänger. Da sind Welten zwischen. Allerdings sollte man sich schon im Klaren sein, dass die üblichen Empfänger ohne Signal ein kräftiges Rauschen liefern und mit Signal sehr häufig kurze Spikes im Datenstrom. Das macht jede Interruptauswertung unmöglich und gefährlich. Eine Alternative hatte ich hier schon mal gepostet: Beitrag "S555HT AVR Beispielcode" Ist aber nur ein Codebeispiel. Ich betreibe den fast identischen Code z.Z. auf einem LPC11C24 und verschicke die Daten per CAN. Das geht mit allen Sensoren die bei mir im Haus verteilt sind ausgesprochen zuverlässig. Ob sich mit Bascom eine Interruptroutine für einen schnellen Timer noch realisieren lässt, entzieht sich meiner Kenntnis. Ich denke ehr nicht.
Die Sache mit dem Attiny läuft ja soweit ganz gut. Ich muss nur noch heraus finden, wie genau ich die über UART gesendeten Daten interpretieren muss. Allerdings liegt schon ein gewisser Reiz darin die Daten ohne zusätzlichen Controller zu empfangen und dekodieren. Ich habe einen Empfänger hier (zusätzlich zu meinen 2 HFS301) welcher aus einer Mebus-Wetterstation (typisches Supermarktprodukt) stammt und nur dann einen Pegel ausgibt, wenn auch Daten empfangen werden. Wird nichts empfangen, liegt dauerhaft Betriebsspannung am Datenpin an. Das Lustige an diesem Modul, bei meinen Timer + Interrupt Versuchen, stimmte das Stopbit schon mal. Jedes 5te Bit, nach der Präambel war tatsächlich log. 1. Nur ergaben die Daten bei einer manuellen Auswertung unter Excel keinen Sinn. Weder die Sensoradresse ergab einen Sinn, noch die restlichen Daten. Ich versuche mich weiter in dem Thema. Denn ich will lernen, wie ich sowas zukünftig lösen kann. Zumal ein eigener Empfänger den Charme hat, die auf 433 und 868 Mhz sendenden Sensoren mit der Zeit zu dekodieren und anzeigen zu lassen. Beispielsweise steht nur ein paar hundert Meter von hier entfernt eine Wetterstation mit Windsensor in 10m Höhe über freien Feld. Dessen Daten wären sehr interessant. Und die Station ist definitiv eine andere als meine eigene. @Jürgen Hab mir Deinen Beitrag mal durchgelesen. Also vom Prinzip her wird bei jedem Timerinterrupt geschaut ob sich der Zustand am Pin geändert hat. Ist der Zustand unverändert, wird beispielsweise eine Variable hochgezählt. Hat er sich inzwischen geändert, wird die Variable auf 0 zurück gesetzt. Da zwischen den Timerinterrupts nichts passiert, werden auch Spikes ignoriert, welche in der Zwischenzeit passieren. Die Idee ist klasse. Hab nämlich auch so die Vermutung, dass gerade der Empfänger der Mebus Station, solche Spikes von sich gibt.
So, stand der Dinge: Repater durch nachlöten aller Lötstellen wieder in Gang gesetzt. Dadurch war es möglich die Zeiten an dessen Sendeausgang zu messen und diese in der Empfängerschaltung zu übernehmen. Die Empfängerschaltung arbeitet folgender Maßen: Vor dem Eingang vom HFS301 zum Kontroller sitzt eine kleine Transistorverstärkerstufe. Int0 = fallend, Int1 = steigend, Timer0 als Timer. Wird Int0 ausgelöst, startet dieser den Timer. Bei jedem Timerinterrupt wird eine Variable hochgezählt. Wird Int1 ausgelöst, wird der Timer gestoppt und die Timervariable ausgewertet. Es wird geprüft ob sich die Variable im Rahmen für log. 0 oder log. 1 befindet und der Wert eines Arrays entsprechend gesetzt. Entspricht die Variable keinem dieser beiden Bedingungen, wird der Zähler fürs Array auf 0 zurück gesetzt. In der Hauptschleife schließlich wird geprüft ob der Arrayzähler einen bestimmten Wert erreicht hat. Wenn ja, dann wird in einer for to Schleife das Array auf RS232 ausgegeben. Diese Daten habe ich mir in Excel kopiert und war erstaunt das ich nun auch mit dem HFS301 Modul saubere Daten empfange. Richtig sauber wurde der Empfang, seit das HFS301 nicht direkt sondern über eine Trasistorstufe am Kontroller hängt. Diese Transistorstufe sieht so aus, dass der Ausgang des HFS301 direkt an die Basis eines BC548 geht. Die Kollektor-Emitter Strecke bildet zusammen mit einem 200k Widerstand einen Spannungsteiler in dessen Mitte das Signal für den Kontroller abgegriffen wird. Allerdings muss ich sagen, das HFS301 hat keinen übermäßigen Empfang. Befinde ich mich zu weit im inneren meiner Dachgeschosswohnung, so werden nur noch die auf dem Dach montierten Sensoren empfangen. Nach dem ich auch die Errechnung der XOR Checksumme herausbekommen habe, stand gleich ein Eigenbausensor auf dem Programm, welcher nun sauber von meiner Wetterstation empfangen wird. Ende gut, alles gut ;). Ich Danke Euch allen für Eure Hilfe. Besonderer Dank geht an Norbert Hanebeck (nobbyh) für seine Mühe Schaltungen noch einmal zu testen und deren Code sowie Schaltplan hier einzustellen.
versuch doch mal das: http://bascom-forum.de/showthread.php?6227-elv-pc-wetterstations-empf%E4nger-(ws2000-ws2500)-FRAGE&p=49417#post49417 -bascom -lesbar -selbst erweiterbar -drei drähte cu
Thread beobachten
Seitenaufteilung abschalten