ASK-Empfänger einlesen?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • ASK-Empfänger einlesen?

      Hallo!

      Hänge gerade daran mit einem RXB6 meine Temperatursensoren mit Bascom empfangen zu wollen.
      Eigentlich hätte ich gerne ein RFM69 benutzt, allerdings sind die nicht kompatibel mit dem Signal der auszuwertenden Sensoren.
      Denn der SX1231 welcher auf den RFM69-Modulen sitzt braucht zwingend ein Dotting in der Signalbitrate.
      Dummer weise senden die Sensoren aber bereits das Dotting mit Manchestercodierung.
      Statt also 101010101001101001.... senden die 1100110011001100110101100110......
      Das erstere würden die RFM verstehen, das zweite aber nicht.

      Nun stehe ich schon auf dem Schlauch...wie liest man brauchbar so ein einfachen ASK-Empfänger in Bascom ein?

      Mein erster Versuch:

      BASCOM-Quellcode

      1. 'ARUDINO-NANO auf Steckbrett mit 433MHz ASK-Empfänger RXB6
      2. 'Evaluation eines ASK-Empfängers zur Langzeitdoku über UART
      3. 'Datenausgang des RXB6 liegt auf PC1
      4. $regfile = "m328pdef.dat" 'ARUNDIO-NANO Prozessor
      5. $crystal = 16000000 'ARUNDIO-NANO Originalquarz
      6. $hwstack = 100
      7. $swstack = 100
      8. $framesize = 100
      9. $baud = 38400
      10. Config Portb = &B11111111 'Pull Up Deaktiviert (0) oder aktiviert (1)
      11. Config Portc = &B11111101 'Pull Up Deaktiviert (0) oder aktiviert (1)
      12. Config Portd = &B11111111 'Pull Up Deaktiviert (0) oder aktiviert (1)
      13. Ddrb = &B11111111 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      14. Ddrc = &B11111101 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      15. Ddrd = &B11111111 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      16. Dim RXword as Word
      17. Dim RXwordpacket(26) as Word
      18. Dim PacketA(26) as Byte
      19. Dim PacketB(26) as Byte
      20. Dim Pulse as Word
      21. ASK Alias PinC.1 'Signaleingang ASK-Digital
      22. '$lib "pulsein.lib"
      23. 'const cPulseIn_Timeout = 0
      24. 'waitus bPulsein_delay
      25. 'bPulseIn_Delay = 10
      26. Do
      27. If ASK = 1 then Gosub MessungH
      28. If ASK = 0 then Gosub MessungL
      29. Loop
      30. MessungH:
      31. while Pulse < 100
      32. Pulsein Pulse, pinc, 1, 1
      33. wend
      34. Print Pulse;"H"
      35. Pulse = 0
      36. Goto MessungL
      37. Return
      38. MessungL:
      39. While Pulse < 100
      40. Pulsein Pulse, pinc, 1, 0
      41. wend
      42. Print Pulse;"L"
      43. Pulse = 0
      44. Goto MessungH
      45. return
      Alles anzeigen
      bringt nur Müllwerte.
      Eigentlich erhoffte ich mir das Signal zu finden von dem ich ziemlich genau weis wie es aussieht.
      Nämlich Impulszeiten von mindestens 488µs (ein Bit) oder maximal 976µs.
      In der Dottingphase erst mal eine lange reihe (gute 40 Bit) mit exakt 976µs High und 976µs Low.

      Die Bedingung "While Pulse < 100" habe ich schon aus Verzweifelung rein gesetzt, da mir der Nano das komplette Rauschspektrum von 1µs bis 10000µs via UART rauspfefferte.
      Nun ist es schon deutlich aufgeräumter, aber selbst hier find ich nichtmal das Dotting.

      Der erste Anfang mit Pulsein ist erst mal ein Anfang überhaupt was zu empfangen.
      Später mache ich das vielleicht über einen Timer und Interrupt.
      Aber bei dem Rauschen spare ich mir das erst mal.

      Für die jenigen die es interessiert wie das Signal exakt aussieht:
      Das Linux-Tool rtl_433 kennt diesen Sensor nicht. Aber im Analyze-Modus kann er das Rohsignal vermessen.
      Dabei spuckt er dieses hier aus:

      https://triq.org/pdv/#AAB...

      Und es ist genau das Signal welches ich schon zigfach mit Oszi und via Soundkarte mitloggen konnte.

      Als Hinweis noch:
      Ich versuche nicht einen Sensor zu empfangen der zig Meter entfernt ist. Ne, er liegt gerade während dieser Versuche knapp 50cm vom RXB6 entfernt.

      Was mache ich falsch?

      Jürgen
    • Hallo!

      Ulrich schrieb:

      Hallo Jürgen,

      Schau mal hier, vielleicht ist was dabei

      forum.g-heinrichs.de/viewtopic.php?t=76
      Ja, da bin ich schon häufiger drüber gestolpert.
      Inzwischen gehe ich einen anderen Weg.
      Weg von Pulsein, hin zu Timer1.
      Da mein NANO mit 16MHz Takt läuft habe ich erst mal Vorteiler /8 genutzt (TCCR1B = 00000010).
      Damit sollte auch auf 0,5µs Auflösung messen.
      Aus den 488µs müsste dann Zählerwert 970-990 und aus 976µs müssten dann 1945-1955 werden.

      Damit shifte ich einen Empfangsbuffer (Word) nacheinander mit 1 (488µs) oder 2Bit (976µs) des aktuellen ASK-Pegels.
      Und warte darauf das ich das Syncwort entdecke (h9696).

      Aber bislang nix.
      Probiere morgen mal einen anderen ASK-Empfänger.
      Sollte das alles nicht helfen werfe ich morgen mal ein Oszi an, um zu gucken was dort tatsächlich aus dem Empfänger kommt.
      Oder...wenn ich mein Adapterkabel Krokoklemmen -> Chinch finde gleich noch über Soundkarte gucken.
      Aber ich fürchte da ist schon was faul.
      Da die von mir gebrauchte Baudrate irgendwo um 1000~1024Bd liegt und ich mehrfach über google den Hinweis bekommen habe das manche ASK-Empfänger genau um 1000Bd rum unsauber sind.

      Na mal schauen.

      Jürgen
    • Hallo nochmal.

      Kurzer Blick vorhin auf dem Oszi zeigte das die beiden ASK-Empfänger die ich hier habe prinzipiell schon die richtigen Rechtecksignale abbilden, allerdings in sehr unsauberen und verrauschen störsignalen.
      Hinzu kommt die fehlende Rauschsperre.

      Mein Testprogramm habe ich zwischenzeitlich abgeändert.
      Statt Pulsein verwende ich nun den Capture In ICP1 und Timer1:

      BASCOM-Quellcode

      1. 'ARUDINO-NANO auf Steckbrett mit 433MHz ASK-Empfänger RXB6
      2. 'Evaluation eines ASK-Empfängers zur Langzeitdoku über UART
      3. 'Datenausgang des RXB6 liegt auf PC1
      4. $regfile = "m328pdef.dat" 'ARUNDIO-NANO Prozessor
      5. $crystal = 16000000 'ARUNDIO-NANO Originalquarz
      6. $hwstack = 40
      7. $swstack = 40
      8. $framesize = 40
      9. $baud = 115200
      10. Config Portb = &B11111110 'Pull Up Deaktiviert (0) oder aktiviert (1)
      11. Config Portc = &B11111101 'Pull Up Deaktiviert (0) oder aktiviert (1)
      12. Config Portd = &B11111111 'Pull Up Deaktiviert (0) oder aktiviert (1)
      13. Ddrb = &B11111110 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      14. Ddrc = &B11111101 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      15. Ddrd = &B11111111 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      16. Dim RXword as Word
      17. Dim RXwordpacket(26) as Word
      18. Dim PacketA(26) as Byte
      19. Dim PacketB(26) as Byte
      20. Dim Pulse as Word
      21. Dim bitcount as Byte
      22. Dim bytecount as Byte
      23. Dim wordcount as Byte
      24. Dim Pegel as Bit
      25. Dim Pegel1 as Bit
      26. bitcount = 0
      27. 'ASK Alias PinC.1 'Signaleingang ASK-Digital
      28. 'Signaleingang nun PB0 -> ICP1
      29. 'Config Timer1 = Timer, Prescale = 64, Noise_Cancel = 1, Capture_EDGE = RISING 'müssten 4µs (250kHz) sein.
      30. 'Config Timer1 = Timer, Prescale = 8, Noise_Cancel = 1, Capture_EDGE = RISING 'müssten 0,5µs (2MHz) sein.
      31. tccr1b = &b10000011 'für 4µs und Noise-Canceller
      32. 'tccr1b = &b10000010 'für 0,5µs und Noise Canceller
      33. timsk1 =&b00100000 'Input Capture Int Enable
      34. enable interrupts
      35. On ICP1 Readtime
      36. Print "Start..."
      37. Do
      38. If bitcount = 1 then
      39. Print Pulse;" ";Pegel1
      40. bitcount = 0
      41. end if
      42. Loop
      43. Readtime:
      44. Pulse = High(icr1h)
      45. Pulse = Low(icr1l)
      46. icr1h = 0
      47. icr1l = 0
      48. Pegel1 = tccr1B.6
      49. Toggle Tccr1b.6
      50. bitcount = 1
      51. Return
      Alles anzeigen

      Gerade scrolle ich mich durch die endlosen Ausgaben im Terminal.
      Das Dotting bestehend aus 970-990µs abwechselnd High/Low müsste bei 4µs + Noice-Canceler (4 Sampels =16µs) also irgendwo im Bereich der Ausgabewerte 250 - 264 liegen.

      @Mitch64:

      Das es Verwunderung verursacht das ein Dotting Manchester-codiert wird, war klar.
      Daher habe ich ja auch den Link auf das Spektrogramm im ersten Post gesetzt.
      Wer sich das anguckt und trotzdem nicht versteht, steht wirklich auf dem Schlauch.

      RTL_433 ist ein SDR-Softwaretool aus dem Linuxumfeld, welches sich zur Aufgabe gemacht hat genau diese ganzen ASK-Protokolle die bei 433 und 868MHz rumschwirren decodieren zu wollen.
      Selber bin ich kein Linux-Freak, jedoch nutze ich das Programm auf einem Raspberry-Pi.
      github.com/merbanan/rtl_433

      Viele Protokolle die rtl_433 noch nicht kennt, kann er zumindest vermessen und seine Signalform mit exaktem Timing dokumentieren. Die Beschreibung des Signals verpackt er in einen Link, wo dann auf triq.org/pdv/ die grafische Darstellung bietet.
      Das einzige was mich gelegentlich in die Tischkante beißen lässt:

      Obwohl gefühlt 90% der handelsüblichen ASK-Welt Manchester-codiert ist, behaart rtl_433 darauf das es wohl ein PWM-moduliertes Signal sein müsste.

      Macht aber nichts.

      Spätestens unter der grafischen Ansicht auf trip.org kann man die Modulation im Auswahlmenue "Slicer" ändern auf "MC" für Manchester.


      Jürgen
    • Hallo Jürgen,
      in der ISR schreibst du

      DG7GJ schrieb:

      Pulse = High(icr1h)
      Pulse = Low(icr1l)
      Macht ja nicht wirklich Sinn.
      Außerdem gibt du nach jeder Flanke den Wert per Print aus, ob das schnell genug geht?
      Musst du denn überhaupt auf jede Flanke reagieren? Selbst bei Manchester sollte es doch reichen, die Periode festzustellen. Daraus kannst du dann ableiten, ob das gleiche Bit wie davor kommt, oder ein Wechsel.
    • Hallo!

      Franz schrieb:

      Hallo Jürgen,
      in der ISR schreibst du

      DG7GJ schrieb:

      Pulse = High(icr1h)
      Pulse = Low(icr1l)
      Macht ja nicht wirklich Sinn.Außerdem gibt du nach jeder Flanke den Wert per Print aus, ob das schnell genug geht?
      Musst du denn überhaupt auf jede Flanke reagieren? Selbst bei Manchester sollte es doch reichen, die Periode festzustellen. Daraus kannst du dann ableiten, ob das gleiche Bit wie davor kommt, oder ein Wechsel.
      Das mache ich, weil ich da im Datenblatt des ATmega328P so verstehe:
      Das Input Capure Register ist 16Bit breit und aufgeteilt in ein Highbyte und Lowbyte welche man schnell hintereinander auslesen soll. Pulse ist somit ein Word welches mit dem MSB-Register von ICR1H und dem LSB-Register ICR1L gefüllt wird.

      Würde ich den Config-Timer nehmen könte ich den 16Bit Wert komplett übernehmen mit Pulse = TIMER1.
      Warscheinlich händelt Bascom das im Hintergrund konform zu den Regeln des Datenbattes bezüglich zugriff auf 16Bit-Registr ab.
      Da ich mich aber aufgrund der Schnelligkeit versuche die Register manuell zu setzen, halte ich mich lieber an das Datenblatt.

      Und ja, die Flankenerkennung soll mit zwei Informationen geben:
      Pegel und Zeit bis zum nächsten Flankenwechsel. Flankenwechsel dind entweder nach einer Bitzeit (470-490µs) oder nach zwei Bitzeiten [940-980µs).

      Doch egal ob ich den Timer1 mit 2MHz (=0,5µs) oder 250kHz (=4µs) takte.
      Er gibt mir am UART immer Werte zwischen 100-255 aus...alles nur 8Bit-Werte *grübel*.
      Spätestens unter 2MHz würde ich eher mit einer Bitzeit von 940-980 und zwei Bitzeiten von 1880-1940 rechnen.

      Egal, das mit dem UART mache ich eigentlich nur um fest zu stellen in welchem Wertebereich sich die ein oder zwei Bitzeiten real befinden. Zumal der NANO zwar mit "etwa 16MHz" läuft, aber eben nicht quarzstabil sondern über einen Resonator.
      Hinzu kommt das der Sensor den ich empfangen will ebenso streut, warscheinlich Temperaturabhängig.
      Bei 20°C liegt er bei 488µs für eine Bitzeit, letzte Nacht bei 0° eher bei 460µs *seufz*

      Ob das mit der UART-Ausgabe schnell genug geht, ist eine gute Frage.
      Habe trotz der Warnung von bascom das 115200Bd zu Abweichungen bei 16MHz führt die 115,2kBd genau aus diesem Grund gewählt. Gleichzeitig in Hterm definiert das er mir auch Fehler (abgehachte bytes usw.) anzeigen soll.
      Derartige Fehler meldet mit Hterm bislang nicht.
      Allerdings gibt es da ein Indiz das doch was eng werden könnte vom Timing.
      In der ISR ändere ich nach jeder Übernahme des logischen Pegels die polarität der Input-Capture Funktion in TCCR1B.6.
      Prinzipiell müsste also jedes Sampel in der Ausgabe abwechselns entweder 1 oder 0 sein.
      Ist es häufig, aber nicht immer. Zei aufeinanderfolgende Sampels mit 11 oder 00 sind durchaus darunter.

      Jürgen

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von DG7GJ ()

    • DG7GJ schrieb:

      Er gibt mir am UART immer Werte zwischen 100-255 aus...alles nur 8Bit-Werte *grübel*.
      Schau dir doch noch einmal an, was ich dir zu den beiden Zeilen in der ISR geschrieben habe.
      Es geht übrigens auch nicht schneller, wenn du die Timerregister von Hand setzt.
      Und in der ISR kannst du einfach schreiben
      Pulse =ICR1
      Damit umgehst du auch deinen Fehler.
      Durch die Printausgabe kann es dir aber passieren, dass du eine Flanke verpasst. Du kannst die Werte auch in ein Array schreiben und dann in Ruhe hinterher ausgeben.
      Und nochmal: Ich sehe nicht, was dir die High und Low Zeiten an Zusatzinfo geben gegenüber der Periodenlänge. Dafür hast du aber doppelten Aufwand.

      Der Ausgabe in HTerm siehst du das nicht an, ob eine Flanke verpasst wurde.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Franz ()

    • Franz schrieb:


      Und nochmal: Ich sehe nicht, was dir die High und Low Zeiten an Zusatzinfo geben gegenüber der Periodenlänge. Dafür hast du aber doppelten Aufwand.

      OK, mit Pulse = ICR1 funktioniert, danke für den Hinweis.

      Zu deiner Unverständniss zum Thema low- und high-Zeiten verstehe ich nicht ganz worauf du hinaus willst.

      Ich möchte das Signal so in Word-Variablen (später einem Word-Array) abbilden, wie es tatsächlich auch so über Funk rein kommt.
      Eben um später die Manchester-Decodierung in Bascom mit MANCHESTERDEC zu erledigen.
      Hierzu ist die Polarität aber wichtig.

      Habe ich nur die flankenzeiten, beispielsweise 488 oder 976µs, weis ich ja nur das im Manchester-Bitstrom ein Bit oder zwei identische Bits aufeinander folgten.
      Vielleicht bist du gerade im Denkmuster von PWM-Modulation wo es wirklich nur um die Zeiten geht.
      Ich bin hier aber beim ganz normalen oldscool Manchester.
      Also ein Bit ist 488µs lang.

      010101 sind dann 488µs Low, 488µs High, 488µs Low, 488µs High, 488µs Low, 488µs High.
      100110 sind dann 488µs High, 976µs Low, 976µs High, 488µs Low

      Die Flankenzeiten sagen mir also ob ein Bit oder zwei identische Bits übertragen wurden.

      Jürgen
    • Neuer Status mit aktueller Erkentniss:

      Mein Hauptproblem liegt offenbar in erster Linie am Steckboard.
      Frustriert habe ich eben meine diversen ASK-Empfänger mal zur Seite gelegt.

      Statt dessen habe ich meine TTL-Teilerplatine vorgekramt und die TTL-Signale direkt in den ICP1 (PB0) eingespeißt.
      Dort kommen exakt binär geteilte Rechtecksignale raus die auf dem oszi perfekt aussehen. Haupttaktquelle auf dem Board ist ein 2MHz TTL-Oszillator.

      Und siehe da:

      2MHz / 1024 = 1953,125Hz entsprechend 256µs wird vom NANO bei Vorteiler 64 (4µs) mal mit Zählerwert 8869 und mal mit 24835 gemessen.
      2MHz / 2048 = 976,5625Hz entsprechend 512µs wird vom NANO bei Vortieler 64 mal 4601 und mal 36609 gemessen.
      2MHz / 4096 = 488,28125Hz entsprechend 1,024ms wird mal mit 50856 und mal 52328 gemessen.

      Das sind derart fatale Abweichungen das entweder mein NANO ne Macke hat, oder das Steckboard daran schuld ist.
      So ein Mist, da muss ich mir am Wochenende mal Gedanken machen wie ich da was fest zusammen gelötet bekomme...
      Wenn er aber nichtmal meine akkoraten Rechtecksignale mit gleichbleibenen Taktverhältniss erkennt, ist da wohl etwas oberfaul.

      Jürgen
    • Hallo Jürgen

      Ich habe mir jetzt mal die Signale auf der Webseite angesehen.
      Ich musste ne Weile drauf schauen, bis ich merkte, wie ich das interpretieren muss.

      Also es ist definitiv Manchester. Bitrate ist 976µs, also 1024 Bit/s.
      Was mir auffällt ist, dass die angezeigten Bits nicht dem entsprechen, was da gesendet wird.

      Wenn die Frequenz bei Manchester tief ist, wird 1010101010 übertragen.
      Ist die Frequenz doppelt so hoch, werden 111111111 oder 00000000 Bits übertragen.

      Siehe Wikipedia Manchester.

      Zu deiner Dekodierung:
      Wenn du das ICP1 benutzt, wird immer nur auf eine Flanke getriggert.
      Der Timer1-Wert wird dann im ICP1-Register (16 Bit) gespeichert. Das weist du ja schon.

      Aber wenn du das ausliest, musst du zuerst das Low-Register, danach das High-Register lesen.
      Nicht anders herum.

      Quellcode

      1. ; Beispiel Lese-Zugriff auf 16-Bit Register (auch ICP1-Register)
      2. ; Auszug aus Datenblatt!
      3. TIM16_ReadTCNT1:
      4. ; Save global interrupt flag
      5. in r18,SREG
      6. ; Disable interrupts
      7. cli
      8. ; Read TCNT1 into r17:r16
      9. in r16,TCNT1L
      10. in r17,TCNT1H
      11. ; Restore global interrupt flag
      12. out SREG,r18
      13. ret
      Alles anzeigen

      Beim Dekodieren per Flanken-Interrupt z.B. am ICP1-Pin, kann es natürlich bei Störflanken zu Falschmessungen kommen.
      Das zu händeln ist vielleicht umständlich und vielleicht auch nicht möglich.

      Denke mal an RS232, wie es dort funktioniert.
      Das Signal wird gesampelt, so dass pro Bit 16 Sample-Werte vorhanden sind. Die Bitwerte werden im Grunde gezählt um festzustellen, ob es mehr High oder mehr Low-Bits ist.

      In ähnlicher weise sollte es auch mit Manchester gehen, wenn das Signal etwas verrauscht ist.
    • Ach, also doch byteweise auslesen, hatte ich nur halt verkehrt rum.

      Egal, habe doch gerade nochmal den Lötkolben hervorgeholt und GND+Rechtecksignal von meiner Teilerplatine fix auf 2MHz / 4096 über zwei Drähten direkt an den NANO gelötet.
      Das entspricht beinahe dem Signal was mein Sensor als Dotting aussendet, also statt 976µs Flankenabstand eben 1,024ms Abstand.
      Frustrierender weise keine Besserung.

      Soeben dann nochmal, komplett zurückgegangen auf meine ersten Versuche gestern.
      Da der Draht nun mal schon an PB0 angelötet ist, nahm ich den als normalen PINB.0.

      BASCOM-Quellcode

      1. 'ARUDINO-NANO auf Steckbrett mit 433MHz ASK-Empfänger
      2. 'Evaluation eines ASK-Empfängers zur Langzeitdoku über UART
      3. $regfile = "m328pdef.dat" 'ARUNDIO-NANO Prozessor
      4. $crystal = 16000000 'ARUNDIO-NANO Originalquarz
      5. $hwstack = 100
      6. $swstack = 100
      7. $framesize = 100
      8. $baud = 115200
      9. Config Portb = &B11111110 'Pull Up Deaktiviert (0) oder aktiviert (1)
      10. Config Portc = &B11111101 'Pull Up Deaktiviert (0) oder aktiviert (1)
      11. Config Portd = &B11111111 'Pull Up Deaktiviert (0) oder aktiviert (1)
      12. Ddrb = &B11111110 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      13. Ddrc = &B11111101 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      14. Ddrd = &B11111111 'definieren der verwendeten Ports ( 1 = ausgang; 0= eingang)
      15. Dim RXword as Word
      16. Dim RXwordpacket(26) as Word
      17. Dim PacketA(26) as Byte
      18. Dim PacketB(26) as Byte
      19. Dim Pulse as Word
      20. ASK Alias PinB.0 'Signaleingang ASK-Digital
      21. $lib "pulsein.lib"
      22. const cPulseIn_Timeout = 0
      23. 'waitus bPulsein_delay
      24. 'bPulseIn_Delay = 10
      25. Do
      26. If ASK = 1 then Gosub MessungH
      27. If ASK = 0 then Gosub MessungL
      28. Loop
      29. MessungH:
      30. 'while Pulse < 100
      31. Pulsein Pulse, pinb, 0, 1
      32. 'wend
      33. Print Pulse;" H"
      34. Pulse = 0
      35. Goto MessungL
      36. Return
      37. MessungL:
      38. 'While Pulse < 100
      39. Pulsein Pulse, pinb, 0, 0
      40. 'wend
      41. Print Pulse;" L"
      42. Pulse = 0
      43. Goto MessungH
      44. return
      Alles anzeigen

      Und siehe da: Was gestern mit den Funkmodulen am PINC.1 nicht klappte, geht nun am PINB.0 fast schon perfekt!

      Zu meinem TTL-Signal 2MHz / 4096 = 2 Bitzeiten gibt er aus:
      106 L
      106 H
      106 L
      106 H
      106 L
      106 H
      106 L
      106 H

      Und zu meinen 2MHz / 2048 = 1 Bitzeit gibt er brav aus:

      53 L
      53 H
      53 L
      53 H
      53 L
      53 H
      53 L

      Damit könnte man arbeiten.
      Schön, wenn ich das morgen auch mit einer meiner ASK-Empfänger genau sogut hinbekäme.

      Neben dem RXB6 habe ich hier noch einen MWS371-3 mit einem zusätzlichen RSSI-Ausgang.
      An dem kommt ein optisch sauberes Signal raus, wenn ich nahe genug am Sender bin.

      Jürgen
    • DG7GJ schrieb:

      Ach, also doch byteweise auslesen, hatte ich nur halt verkehrt rum.
      Davon habe ich nichts gesagt (byteweise auslesen)!
      Für mich ist es erst mal nur ein Bit-Strom, wie auch immer der zusammen gesetzt ist.

      Vielleicht sind es 7 Bit oder 12 oder sonstwas? Könnte auch etwas binäres sein wo die Bits-Informationen unterschiedliche Bitbreiten haben.
    • Hallo!

      Mitch64 schrieb:

      Beim Dekodieren per Flanken-Interrupt z.B. am ICP1-Pin, kann es natürlich bei Störflanken zu Falschmessungen kommen.
      Das zu händeln ist vielleicht umständlich und vielleicht auch nicht möglich.

      Denke mal an RS232, wie es dort funktioniert.
      Das Signal wird gesampelt, so dass pro Bit 16 Sample-Werte vorhanden sind. Die Bitwerte werden im Grunde gezählt um festzustellen, ob es mehr High oder mehr Low-Bits is

      Oh ja...
      Das einzige mal als ich vor einigen Jahren mal mit Pulsein und Pulseout gearbeitet habe, ging es um IR-Fernbedienungen.
      Da war der IR-Empfänger offenbar sehr gut gefiltert und hat ein hinreichend gutes Signal geliefert für die Pulsein-Funktion.

      Bei meinen bisher drei unterschiedlichen ASK-Empfängern kommen aber Unsauberkeiten raus die fatal sind.
      Da wäre zum einen das heftige Rauschen ohne Signal, und hinzu kommen unsaubere Flanken mit Spikes die mir alle Messungen verhageln.

      Das heftigte finde ich, das mir der überall so gelobte RXB6 die Tastbreiten gehörig verzieht: High-Sighnale fast 70% breiter und Low-Signale 30% schmaler.

      Habe gerade angefangen mit einer Grundstruktur für Oversampling nach UART-Vorbild.
      Allerdings erst mal mit 1/5tel Bitzeit.
      Also Timer0 mit 16MHz über Vorteiler /8 und Preload 56 alle 100µs einen interrupt auslösen lassen.
      Dann in den Pin abfragen.
      Nach 5 Sampels dann bewerten ob da mehr 0 oder 1 waren.
      16faches oversampling, ok...da wäre ich dann bei einem Intrrupt alle 31,5µs.
      Ich fange erst mal mit 5 an und schaue dann weiter.

      Aber was ich nicht verstehe:
      Warum zum Geier ist dieser ganze ASK-Müll überhaupt so verbreitet.
      Wenn die Auswertung schon so kompliziert ist das gesendete Signal überhaupt ansatzweise im µC zu rekonstruieren, ist das neben den vielzähligen Gegenargumenten die ASK so mitbringen doch ein Supergau.

      Jürgen
    • DG7GJ schrieb:

      Also Timer0 mit 16MHz über Vorteiler /8 und Preload 56 alle 100µs einen interrupt auslösen lassen.
      Dann in den Pin abfragen.
      Nach 5 Sampels dann bewerten ob da mehr 0 oder 1 waren.
      Wenn du das mit 5-facher Frequenz sampeln willst, dann musst du von den kurzen Bitzeiten, also 488µs ausgehen.
      Das wären dann 10240Hz Sampel-Frequenz.

      Warum die kurze Bitzeit? Einfach weil du sonst Gefahr läuftst, 2 Bithälften mit entgegengesetztem Pegel zu sampeln. Das würde keine Mehrheit geben.
      So baust du dir gleich einen logischen Fehler im Programm ein. Deswegen halbes Bit und das mit 5fachem oder 16-fachem sampeln.

      Und vergess Preload 56. Bis du in der ISR bist und den Timer neu gesetzt hast, sind schon einige an Takten vergangen, die deine Sampel-Rate verfälschen.
      Lass stattdessen den Timer im CTC-Mode laufen.

      Einfach
      Config Timer1=Timer,Prescale=1,Clear_Timer=1 ' CTC-Mode durch Clear_Timer=1 aktivieren
      Compare1A=1562 ' ergibt Frequenz 10237 Hz

      Im CTC-Mode muss das OCRnA-Register gesetzt werden.

      Dann solltest du nicht stur 5 bit lesen und dann schauen, ob die mehr High oder Low-Bits haben.
      Das würde funktionieren, wenn du taktsynchrom und flankensynchron mit dem Bitstrom sampelst. Davon kannst du aber nicht ausgehen.
      Also musst du in der isr immer einen Pegel lesen, in ein Byte-Buffer (rechts nach links) schieben umd dann die untersten 5 Bits prüfen.
      Beim nächsten Bit, was du sampelst wieder den Pegel in das Byte schieben und wieder die unteren 5 Bit anschauen, ob mehr High oder Low da sind.
      Der Output ist immer das Ergebnis ob mehr High, dann 1 oder mehr Low, dann 0 ausgeben, bzw in ein Ergebnisbyte schieben.

      Im Ergebnisbyte stehen dann quasi gefiltert dein Bitstrom vom Empfänger. Und das musst du dann noch dekodieren.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mitch64 ()

    • Ein anderer Ansatz wäre, um beim Sampeln mit 5-facher Frequenz zu bleiben, anstatt die Bits in einer Variable zu zählen, die Variable direkt abhängig vom Sampel-Wert zu erhöhen oder zu veringern.

      Also du hast eine Variable z.B. BitPegel.
      Wenn du eine 1 Sampelst, wird BitPehel inkrementiert, bei 0 dekrementiert.
      Es muss dabei sichergestellt werden, dass der Wert nicht kleiner 0 und nicht größer 5 werden kann.

      Somit schwankt deine Variable BitPegel zw. 0 und 5. Kommen viel einsen hintereinander, ist der Wert 5, kommen viele nullen hintereinander, ist der Wert 0.

      Jetzt machst du sowas wie ein Schmitt-Trigger. Wenn der Pegel > 3 wird, liefert der eine 1, ist der <3 eine 0. Hysterese, wenn man so will ist 1 Bit.
      Den Pegel vom Schmitt-Trigger muss man sich merken, wenn das nächste Bit gesampelt wird. Das neue Bit aus dem Schlitt-Trigger wird dann mit dem letzten verglichen.

      Ist der Wert zuvor 0 und jetzt 1, dann ist das eine steigende Flanke. Und umgekehrt erkennt man so eine fallende Flanke.
      Aus den Zeiten der Flankenabständen müsste sich so das Manchester dekodieren lassen,.
    • ASK-Müll, oder was

      DG7GJ schrieb:

      Aber was ich nicht verstehe:
      Warum zum Geier ist dieser ganze ASK-Müll überhaupt so verbreitet.
      Wenn die Auswertung schon so kompliziert ist das gesendete Signal überhaupt ansatzweise im µC zu rekonstruieren, ist das neben den vielzähligen Gegenargumenten die ASK so mitbringen doch ein Supergau.
      Ich versuch es trotzdem mal; bei mir läuft seit einigen Jahren dieser ASK-Müll völlig problemlos, über mehrere Stockwerke und auch draußen über Entfernungen größer 20m.
      Man muss den Müll nur entsprechend aufgereiten, z.B. eine Präambel auswerten und erst dann die Daten.
    • Soweit ich Jürgen verstanden habe, hat er immer noch jede Menge Piks im Signal, selbst wenn er sendet.
      Das ist bei mir überhaupt nicht der Fall. Ich habe hier so einen Billigheimer Sender/Empfänger für 433MHz. Wenn nicht gesendet wird, kommt da Dauermüll raus. Sobald aber ein Signal kommt, scheint die automatische Verstärkung sofort runterzuregeln und ich sehe ein absolut sauberes Signal.
      Daher frage ich mich, ob der Zustand bei Jürgen wirklich nicht auf der Empfängerseite verbessert werden könnte.