RFM69W / RFM69HW - Sendezeiten <1 Sekunde?

    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!

    • RFM69W / RFM69HW - Sendezeiten <1 Sekunde?

      Hallo!

      Hat hier jemand Praxiserfahrungen mit dem RFM69W bzw. RFM69HW?
      Beide Module sind bezüglich Register identisch, bis auf die Sendeleistung.

      Bei meinem Projekt sollen in einem Timeslotverfahren Pakete mit einer festen Größe von 25 Byte ausgetauscht werden.

      Diese 25 Bytes werden im Standbymode in das FIFO geschoben (SPI mit 2MHz Takt) und sollen dort dann wie folgt weiter verarbeitet werden:
      Preable auf Defaultwert: 3 Byte = 24Bit
      Syncwort besteht aus 2 Byte = 16Bit
      Dann kommen meine 25 Byte = 200Bit
      Zum Schluß eine CRC16 vom RFM69 - 2 Byte = 16Bit

      Über den Sender sollen dann also inklusive Overhead 32 Bytes entsprechend 256 Bit.

      Anfangs angestrebt war GFSK mit 9600Baud was laut meiner Annahme eine Paketlänge von ca. 0,0375 Sekunden (knapp 40ms) entsprechen würde.

      Den DIO0 habe ich auf "Packet Sent" und schalte sobald dieses Signal aufläuft das RFM69 wieder in den Standby.
      Ergebnis: Der Sender sendet eine komplette Sekunde, also etwa 25 mal so lange als geplant!

      So richtig kam ich ins grübeln als ich die Baudrate hochgesetzt abe auf 19200Baud: Das Signal sieht anders aus, aber ist noch immer 1 Sekunde lang!

      Ich steh auf dem Schlauch...was mache ich verkehrt?

      BASCOM-Quellcode

      1. Testsendung:
      2. RFM = 0 '/CS aktivieren
      3. SPIOUT FifoW , 1 'FIFO-Schreibregister anwählen
      4. SPIOUT Paket_Test(1) , 25 'Datenpaket 25Byte ins FIFO schieben
      5. RFM = 1 '/CS deaktivieren
      6. waitms 5
      7. RFM = 0 '/CS aktivieren
      8. SPIOUT RFM_OpModeW , 1 'OpMode-Schreibregister anwählen
      9. SPIOUT RFM_TX , 1 'Modeumschaltung: TX
      10. RFM = 1 '/CS deaktivieren
      11. If RFM_INT = 0 then gosub Standby , end if 'Wenn letztes Byte gesendet Standby
      12. Return
      13. Standby:
      14. RFM = 0 '/CS aktivieren
      15. SPIOUT RFM_OpModeW , 1 'OpMode-Schreibregister anwählen
      16. SPIOUT RFM_Standby , 1 'Modeumschaltung: Standby
      17. RFM = 1 '/CS deaktivieren
      18. Return
      Alles anzeigen

      Grüße

      Jürgen
    • Zeile 14 ist ja eine einmalige Abfrage. Wenn das RFM_int zur Zeit der Abfrage nicht =0 ist, passiert nix. Ich weiß jetzt nicht, wo dieses RFM_int resettet wird, vielleicht ist da zur Abfrage eine Schleife sinnvoll, oder ein bisschen warten.
      Ist jetzt geraten, siehe @Michaels post.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo!

      Das Programm anhängen...da würdet Ihr was werfen oder hauen so unübersichtlich ist das.
      Wenn es wirklich nicht anders geht, nehme ich alle Programmzeilen betreffend der problematischen Hardware (hier eben RFM69HW) raus in eine neue Programmdatei. Habe ich aber bisher nicht gemacht, denn es geht mir erst mal um die Eigenschaften des RFM69HW selber, weniger darum was man mit der Software drumm herrum macht.
      Denn die Datenblätter, sowohl das RFM69HW_HopeRF_1.3.pdf als auch das des Funkchips sx1231h.pdf lassen grundlegende Informationen offen.

      Das der Reset-Eingang z.B. Highaktiv ist, kann man in den Datenblätter recht weit hinten finden.
      Die Polarität der übrigen Pins, z.b. der DIO-Pins musste ich durch Try&Error herausfinden:
      Der ist dann Lowactiv...

      Aber abseits der Unwägsamkeiten der Datenblätter:
      Das ich da via DIO0 versuche zu dedektieren wann das letzte Byte ausgesendet wurde, war eigentlich so nicht gedacht.
      Angestrebt war zuerst der Auto-Mode wo der RFM69 intern sofort vin Tx auf Rx umschaltet, sobald die Bedigung "PacketSend" erreicht ist.

      Und genau dort ist das Problem, welches ich oben bereits beschrieb:
      Ein Datenbyte mit 25 Nutzbytes + 7 Bytes Overhead vom RFM69 (Dotting, Syncwort, CRC16) sendet bei mir bislang immer zwischen 975ms und 1125ms.
      Egab ob im AutoMode (RegAutoMode h3B) oder manuell über RegOpMode (h01) initiiert.
      Und da ganz besondern sogar mit der Kuriosität das das selbe Datenpaket (32Bytes inkl. Overhead) mit GFSK bei 9600Baud exakt 975ms braucht, und bei 19200Baud sogar 1125ms.

      Was ich aber hier mitgeben kann sind die Register der RFM-Initialisierung bei mir:

      Quellcode

      1. Reg Bezeichnung Wert
      2. h01 RegOpMode h04 (Standby)
      3. h02 RegDataModul h03 (Packet-Mode, GFSK, BT 0,3)
      4. h03 RegBitrateMSB h0D
      5. h04 RegBitrateLSB h05 (entsp. 9600Bd)
      6. h05 RegFdevMSB h00
      7. h06 RegFdevLSB hA4 (enspr. 10kHz Hub)
      8. h07 RegFrqMSB hD9
      9. h08 RegFreqCSB h5A
      10. h09 RegFreqLSB h49 (Entspr. 869,4125MHz)
      11. h0A RegOsc1 h41
      12. h0B RegAfcCtrl h02
      13. h0C RegReserved h00
      14. h0D RegListen1 h92
      15. h0E RegListen2 hF5
      16. h0F RegListen3 h20
      17. h10 RegVersion h24
      18. h11 RegPaLevel h78 (PA1+PA2 +10dBm)
      19. h12 RegPaRamp h09 (40µs Ramp)
      20. h13 RegOcp h1A (95mA Strombegrenzung)
      21. h14 RegReserved h41
      22. h15 RegReserved hB0
      23. h16 RegReserved h7B
      24. h17 RegReserved h9B
      25. h18 RegLna h88
      26. h19 RegRxBw h55
      27. h1A RegAfcBw h8A
      28. h1B RegOokPeak h40
      29. h1C RegOokAvg h80
      30. h1D RegOokFix h06
      31. h1E RegAfcFei h00
      32. h1F RegAfcMSB h00
      33. h20 RegAfcLSB h00
      34. h21 RegFeiMSB h00
      35. h22 RegFeiLSB h00
      36. h23 RegRssiConfig h00
      37. h24 RegRssiValue h00
      38. h25 RegDioMapping1 h00
      39. h26 RegDioMapping2 h05
      40. h27 RegIrqFlags1 h80
      41. h28 RegIrqFlags2 h00
      42. h29 RegRssiThresh hFF
      43. h2A RegRxTimeout1 h00
      44. h2B RegRxTimeout2 h00
      45. h2C RegPreambleMSB h00
      46. h2D RegPreambleLSB h03 (3 Bytes Dotting)
      47. h2E RegSyncConfig h89 (Syncword aktiv, 2 Bytes, maximal 1Bit fehlerhaft)
      48. h2F RegSyncword1 h22
      49. h30 RegSyncword2 hF7 (Mein Syncword = 0010001011110111)
      50. h31 RegSyncword3 h01
      51. h32 RegSyncword4 h01
      52. h33 RegSyncword5 h01
      53. h34 RegSyncword6 h01
      54. h35 RegSyncword7 h01
      55. h36 RegSyncword8 h01
      56. h37 RegPacketConf1 h50 (Feste Paketlänge, Whitening, CRC aktiv, PayloadReady nur bei CrcOk)
      57. h38 RegPayloadLeng h19 (entsprechend 25 Byte Paketlänge)
      58. h39 RegNodeAdres h00
      59. h3A RegBroadcast h00
      60. h3B RegAutoModes h3B
      61. h3C RegFifoThres h0F
      62. h3D RegPacketConf2 h02
      Alles anzeigen

      Eigentlich möchte ich Datenpakete in deutlich <100ms versenden, da stoßweise bis zu 16 Pakete x 2 (Ack's) = 32 Pakete in weniger als 4 Sekunden über den Funkkanal flutschen können.

      Grüße

      Jürgen
    • du machst es uns mühsam a_28_2c02f089 . Hast du keinen link zu den Datenblättern? Musst du dem modul nicht die Größe des Pakets mitteilen, oder ein 'Paketende erreicht' signalisieren? Wird deine standbye-sub gleich angesprungen und das modul verzögert, oder kommst du nicht zur sub, wie gedacht?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • DG7GJ schrieb:

      da würdet Ihr was werfen oder hauen so unübersichtlich ist das
      und du hast jetzt Angst vor dem Feedback?

      DG7GJ schrieb:

      Wenn es wirklich nicht anders geht, nehme ich alle Programmzeilen betreffend der problematischen Hardware (hier eben RFM69HW) raus in eine neue Programmdatei.
      Das ist eine gute Idee, so mache ich es auch, wenn es nicht weiter geht. ;)
    • Hallo!

      tschoeatsch schrieb:

      du machst es uns mühsam a_28_2c02f089 . Hast du keinen link zu den Datenblättern? Musst du dem modul nicht die Größe des Pakets mitteilen, oder ein 'Paketende erreicht' signalisieren? Wird deine standbye-sub gleich angesprungen und das modul verzögert, oder kommst du nicht zur sub, wie gedacht?

      Wenn du die Links zu den Datenblättern willst, muss ich auch suchen. Denn zu PDF's speichere ich keine Links, sondern lade sie mir lokal runter.
      Aber bitteschön...das Modul: RFM69HW-V1.3 Datasheet.pdf und RFM69W-V1.3 Datasheet.pdf.

      Der Chip darauf ist der SX1231h (RFM69HW) bzw. SX1231 (RFM69W): SX1231h.pdf und SX1231.pdf.


      Und wie ich schon andeutete: Es kann zwar sein das 30 Augen im Datenblatt mehr sehen als meine zwei, allerdings wäre mir Rätselraten um irgendwelche Spekulationen rund ums Datenblatt weniger wichtig als reine Praxiserfahrung von Leuten die schon häufiger was mit den Teilen gemacht haben.


      Michael schrieb:

      und du hast jetzt Angst vor dem Feedback?

      Ne, aber wie das so ist in einem kreativ lebendigen Quellcode wo ich im Minutentakt permanent was ändere, und wo ich selber Mühe habe den Überblick zu behalten, will ich niemandem hinschmeißen. Der Anblick würde warscheinlich mehr abschrecken.

      Dennoch, hab das alles mal in ein eigenes Testprogramm gezogen.
      Von der Hardware-Abtastung via DIO bin ich gerade wieder weg und versuche in Register h3C den Automatik-Packethandler zum Leben zu erwecken.




      Grüße

      Jürgen
      Dateien
      • Repeater_X0.bas

        (13,71 kB, 28 mal heruntergeladen, zuletzt: )
    • Hallo!

      tschoeatsch schrieb:

      In deinem code steht
      RFM_INT alias Porta.0
      Porta.0 ist doch ein input, dann müsste es heißen
      rfm_int alias pina.0
      Oh, danke für den Hinweis!
      Ändert aber nicht wirklich was an dem störrischen RFM69HW.
      Gestern noch zig anläufe gemacht...grob umfasst:

      - FIFO gefüllt mit 25 Bytes
      - Sendebefehl rausgeschossen.

      ----

      dann einmal:
      Auf Umschaltsignal an PinA.0 vom DIO gewartet in einer While-Wend-Schleife:

      While RFM_INT = 1
      waitus 1
      i = i + 1
      wend
      Print "PacketSend nach ";i;"µs"
      Gosub RFM_RxMode

      und diverse anläufe über das Status-Register mit diesem IRP:


      while RFM_Irq2.3 = 0
      RFM = 0
      SPIOUT RFM_Irq2R , 1
      SPIIN RFM_Irq2 , 1
      RFM = 1
      waitus 1
      i = i + 1
      Wend
      Print "PacketSend nach ";i;"µs"
      Gosub RFM_RxMode

      Beide While-Wend-Schleifen durchlaufen angeblich 0-4 mal:
      Unmittelbar nach Umschaltung in den TX-Modus kommt der Ausdruck

      "PacketSend nach 0µs" bis "PacketSend nach 4µs" ist alles drin.

      Der RFM69HW sendet nun auch nicht mehr eine ganze Sekunde, sondern erfreulicher weise soager so verflixt kurz das es schon anspruchsvoll wird diese Impulse zu triggern.
      Problem aber dabei: In den XXms sind keine Daten, sondern lediglich ein einzelner FSK-Ton.

      Wie dem auch sei, gestern Abend mal mein ganzes Init-Register erst mal in die Ecke gestellt und nun baue ich ein reines Testprogramm komplett neu auf für den RFM69.
      Eben um einfacher mit den ganzen Registern rumexperimentieren zu können, und dort dann nochmal von 0 an mit den Reset-Defaultwerten ausgehen rumspielen.

      Dauert noch, heute Abend oder Morgen bin ich da vielleicht weiter und kann das dann hier rein stellen.

      Grüße

      Jürgen
    • Hallo!

      Zum Abend bin ich endlich weiter gekommen.
      Erst ein Schritt: Das Senden von kurzen Paketen - andere folgen über das Wochendende.

      Kurz und Knapp:
      RFM69HW resetet und die Grundvorgaben aller Register ausgelesen.
      Dann Schritt für Schritt die Register angepasst bis ich erreicht hatte was ich wollte.

      Wichtig zu wissen: Der RFM69W/HW ist zwar "intelligent" genug für blitzschnelle Realisierung von CRC16-Kalkulation, Whithening und sogar AES-Verschlüsselung, und zu wissen wie viele Bytes im FIFO liegen, jedoch zu dumm um selber zu merken wenn das letzte Bit gesendet wurde. Das Teil sendet einfach unendlich lange - oder bis man manuell den Betriebsmode wechselt, nach den Nutzdaten einfach einen Sinuston aus.

      Der DIO0 wechselt bei entsprechender Programmierung (h00 in Register h25) von Low auf High wenn das letzte Byte gesendet wurde.
      Den muss man in einer Schleife abfragen und vom TX-Mode in einen anderen Mode (RX, Standby oder Sleep) schalten.
      Mit meinen ursprünglich geplanten 25Bytes @ 9600Baud komme ich so auf Paketlängen von exakt 27ms.
      Bei flotter Umschaltung dürfte so Datenpaket + Ack-Paket in knapp 60-70ms möglich sein, was gute 10-12 Doppelpaketen je Sekunde ermöglichen sollte.

      Der Quellcode ist zu Lang für ein Code-Fenster, daher wieder als Anhang.

      Die dazugehörige UART-Ausgabe sieht dann so aus:

      Quellcode

      1. Neue Register geladen
      2. Alle Register geschrieben
      3. Registerausgabe des RFM69W / RFM69HW:
      4. Register h01 enthält &h04 bzw. &b00000100 RegOpMode RW
      5. Register h02 enthält &h02 bzw. &b00000010 RegDataMdul RW
      6. Register h03 enthält &h0D bzw. &b00001101 RegBitrateMSB RW
      7. Register h04 enthält &h05 bzw. &b00000101 RegBitrateLSB RW
      8. Register h05 enthält &h00 bzw. &b00000000 RegFdevMSB RW
      9. Register h06 enthält &h52 bzw. &b01010010 RegFdevLSB RW
      10. Register h07 enthält &hD9 bzw. &b11011001 RegFrfMSB RW
      11. Register h08 enthält &h5A bzw. &b01011010 RegFrfCSB RW
      12. Register h09 enthält &h49 bzw. &b01001001 RegFrfLSB RW
      13. Register h0A enthält &h41 bzw. &b01000001 RegOsc1 RW
      14. Register h0B enthält &h00 bzw. &b00000000 RegAfcCtrl RW
      15. Register h0C enthält &h02 bzw. &b00000010 Reserved 0C R
      16. Register h0D enthält &h92 bzw. &b10010010 RegListen1 RW
      17. Register h0E enthält &hF5 bzw. &b11110101 RegListen2 RW
      18. Register h0F enthält &h20 bzw. &b00100000 RegListen3 RW
      19. Register h10 enthält &h24 bzw. &b00100100 RegVersion R
      20. Register h11 enthält &h78 bzw. &b01111000 RegPaLevel RW
      21. Register h12 enthält &h09 bzw. &b00001001 RegPaRamp RW
      22. Register h13 enthält &h1A bzw. &b00011010 RegOcp RW
      23. Register h14 enthält &h40 bzw. &b01000000 Reserved 14 R
      24. Register h15 enthält &hB0 bzw. &b10110000 Reserved 15 R
      25. Register h16 enthält &h7B bzw. &b01111011 Reserved 16 R
      26. Register h17 enthält &h9B bzw. &b10011011 Reserved 17 R
      27. Register h18 enthält &h08 bzw. &b00001000 RegLna RW
      28. Register h19 enthält &h86 bzw. &b10000110 RegRxBw RW
      29. Register h1A enthält &h8A bzw. &b10001010 RegAfcBw RW
      30. Register h1B enthält &h40 bzw. &b01000000 RegOokPeak RW
      31. Register h1C enthält &h80 bzw. &b10000000 RegOokAvg RW
      32. Register h1D enthält &h06 bzw. &b00000110 RegOokFix RW
      33. Register h1E enthält &h10 bzw. &b00010000 RegAfcFei RW
      34. Register h1F enthält &h00 bzw. &b00000000 RegAfcMSB R
      35. Register h20 enthält &h00 bzw. &b00000000 RegAfcLSB R
      36. Register h21 enthält &h00 bzw. &b00000000 RegFeiMSB R
      37. Register h22 enthält &h00 bzw. &b00000000 RegFeiLSB R
      38. Register h23 enthält &h02 bzw. &b00000010 RegRssiConfig RW
      39. Register h24 enthält &hFF bzw. &b11111111 RegRssiValue R
      40. Register h25 enthält &h00 bzw. &b00000000 RegDioMapping1 RW
      41. Register h26 enthält &h07 bzw. &b00000111 RegDioMapping2 RW
      42. Register h27 enthält &h80 bzw. &b10000000 RegIrqFlags1 R
      43. Register h28 enthält &h00 bzw. &b00000000 RegIrqFlags2 R
      44. Register h29 enthält &hE4 bzw. &b11100100 RegRssiThresh RW
      45. Register h2A enthält &h00 bzw. &b00000000 RegRxTimeout1 RW
      46. Register h2B enthält &h00 bzw. &b00000000 RegRxTimeout2 RW
      47. Register h2C enthält &h00 bzw. &b00000000 RegPreambleMSB RW
      48. Register h2D enthält &h03 bzw. &b00000011 RegPreambleLSB RW
      49. Register h2E enthält &h89 bzw. &b10001001 RegSyncConfig RW
      50. Register h2F enthält &h22 bzw. &b00100010 RegSyncValue1 RW
      51. Register h30 enthält &hF7 bzw. &b11110111 RegSyncValue2 RW
      52. Register h31 enthält &h22 bzw. &b00100010 RegSyncvalue3 RW
      53. Register h32 enthält &hF7 bzw. &b11110111 RegSyncvalue4 RW
      54. Register h33 enthält &h00 bzw. &b00000000 RegSyncValue5 RW
      55. Register h34 enthält &h00 bzw. &b00000000 RegSyncvalue6 RW
      56. Register h35 enthält &h00 bzw. &b00000000 RegSyncvalue7 RW
      57. Register h36 enthält &h00 bzw. &b00000000 RegSyncValue8 RW
      58. Register h37 enthält &h50 bzw. &b01010000 RegPacketConfig1 RW
      59. Register h38 enthält &h19 bzw. &b00011001 RegPayloadLength RW
      60. Register h39 enthält &h00 bzw. &b00000000 RegNodeAdrs RW
      61. Register h3A enthält &h00 bzw. &b00000000 RegBroadcastAdrs RW
      62. Register h3B enthält &h00 bzw. &b00000000 RegAutoMode RW
      63. Register h3C enthält &h0F bzw. &b00001111 RegFifoThresh RW
      64. Register h3D enthält &h02 bzw. &b00000010 RegPacketConfig2 RW
      65. Register h3E enthält &h00 bzw. &b00000000 RegAESKey01 RW
      66. Register h3F enthält &h00 bzw. &b00000000 RegAESKey02 RW
      67. Register h40 enthält &h00 bzw. &b00000000 RegAESKey03 RW
      68. Register h41 enthält &h00 bzw. &b00000000 RegAESKey04 RW
      69. Register h42 enthält &h00 bzw. &b00000000 RegAESKey05 RW
      70. Register h43 enthält &h00 bzw. &b00000000 RegAESKey06 RW
      71. Register h44 enthält &h00 bzw. &b00000000 RegAESKey07 RW
      72. Register h45 enthält &h00 bzw. &b00000000 RegAESKey08 RW
      73. Register h46 enthält &h00 bzw. &b00000000 RegAESKey09 RW
      74. Register h47 enthält &h00 bzw. &b00000000 RegAESKey10 RW
      75. Register h48 enthält &h00 bzw. &b00000000 RegAESKey11 RW
      76. Register h49 enthält &h00 bzw. &b00000000 RegAESKey12 RW
      77. Register h4A enthält &h00 bzw. &b00000000 RegAESKey13 RW
      78. Register h4B enthält &h00 bzw. &b00000000 RegAESKey14 RW
      79. Register h4C enthält &h00 bzw. &b00000000 RegAESKey15 RW
      80. Register h4D enthält &h00 bzw. &b00000000 RegAESKey16 RW
      81. Register h4E enthält &h01 bzw. &b00000001 RegTemp1 RW
      82. Register h4F enthält &h00 bzw. &b00000000 RegTemp2 R
      83. Register h50 enthält &h00 bzw. &b00000000 RegTestLna
      84. Register h51 enthält &h01 bzw. &b00000001 RegTest (undokumentiert)
      85. Register h52 enthält &h88 bzw. &b10001000 RegTest (undokumentiert)
      86. Register h53 enthält &h08 bzw. &b00001000 RegTest (undokumentiert)
      87. Register h54 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      88. Register h55 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      89. Register h56 enthält &h01 bzw. &b00000001 RegTest (undokumentiert)
      90. Register h57 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      91. Register h58 enthält &h1B bzw. &b00011011 RegTestPa1
      92. Register h59 enthält &h09 bzw. &b00001001 RegTest (undokumentiert)
      93. Register h5A enthält &h55 bzw. &b01010101 RegTestPa2
      94. Register h5B enthält &h80 bzw. &b10000000 RegTest (undokumentiert)
      95. Register h5C enthält &h70 bzw. &b01110000 RegTest (undokumentiert)
      96. Register h5D enthält &h33 bzw. &b00110011 RegTest (undokumentiert)
      97. Register h5E enthält &hCA bzw. &b11001010 RegTest (undokumentiert)
      98. Register h5F enthält &h08 bzw. &b00001000 RegTest (undokumentiert)
      99. Register h60 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      100. Register h61 enthält &h11 bzw. &b00010001 RegTest (undokumentiert)
      101. Register h62 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      102. Register h63 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      103. Register h64 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      104. Register h65 enthält &h0F bzw. &b00001111 RegTest (undokumentiert)
      105. Register h66 enthält &h70 bzw. &b01110000 RegTest (undokumentiert)
      106. Register h67 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      107. Register h68 enthält &h11 bzw. &b00010001 RegTest (undokumentiert)
      108. Register h69 enthält &h15 bzw. &b00010101 RegTest (undokumentiert)
      109. Register h6A enthält &h18 bzw. &b00011000 RegTest (undokumentiert)
      110. Register h6B enthält &h1B bzw. &b00011011 RegTest (undokumentiert)
      111. Register h6C enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      112. Register h6D enthält &h04 bzw. &b00000100 RegTest (undokumentiert)
      113. Register h6E enthält &h0C bzw. &b00001100 RegTest (undokumentiert)
      114. Register h6F enthält &h00 bzw. &b00000000 RegTestDagc
      115. Register h70 enthält &h00 bzw. &b00000000 RegTest (undokumentiert)
      116. Register h71 enthält &h00 bzw. &b00000000 RegTestAcf
      117. Fülle FIFO mit 64 Bytes
      118. Sende Paket aus!
      119. RFM-INT: PacketSend nach 27ms
      120. Paket gesendet
      121. Modeumschaltung: Sleep
      122. Fülle FIFO mit 64 Bytes
      123. Sende Paket aus!
      124. RFM-INT: PacketSend nach 27ms
      125. Paket gesendet
      126. Modeumschaltung: Sleep
      127. Fülle FIFO mit 64 Bytes
      128. Sende Paket aus!
      129. RFM-INT: PacketSend nach 27ms
      130. Paket gesendet
      131. Modeumschaltung: Sleep
      132. Fülle FIFO mit 64 Bytes
      133. Sende Paket aus!
      134. RFM-INT: PacketSend nach 27ms
      135. Paket gesendet
      136. Modeumschaltung: Sleep
      137. Fülle FIFO mit 64 Bytes
      138. Sende Paket aus!
      139. RFM-INT: PacketSend nach 27ms
      140. Paket gesendet
      141. Modeumschaltung: Sleep
      142. Fülle FIFO mit 64 Bytes
      143. Sende Paket aus!
      144. RFM-INT: PacketSend nach 27ms
      145. Paket gesendet
      146. Modeumschaltung: Sleep
      147. Fülle FIFO mit 64 Bytes
      148. Sende Paket aus!
      149. RFM-INT: PacketSend nach 27ms
      150. Paket gesendet
      151. Modeumschaltung: Sleep
      Alles anzeigen

      Woran es die letzten Tage scheiterte weis ich nicht, vermute mal das irgendwas mit meiner ursprünglichen Initialisierung nicht passte.

      Grüße

      Jürgen
      Dateien
      • RFM69W_Test1.bas

        (38,13 kB, 34 mal heruntergeladen, zuletzt: )
    • Hallo!

      Nächstes Problem beim RFM69, welches eher ein matematisches ist:

      In den Registern h07, h08 und h09 steckt die Frequenz auf welche der RFM69 arbeiten muss.
      Diese Register bestehen aus MSB, CSB und LSB einer unsignierten Ganzzahl.

      Die Frequenz ergibt sich aus dieser Zahl multipliziert mit der PLL-Referenzfrequenz von theoretisch 61Hz.
      So liegt z.B. der Registerwert D9 7A 77 (Dezimal 14252663) multipliziert mit 61Hz auf 869,412443MHz.
      Soweit die Theorie.
      In der Praxis führt diese extrem niedrige PLL-Referenz für immense Frequenzfehler bereits bei minimalen Bauteilstreuungen.
      Während also von h7-h9 der theoretisch errechnete Wert hD97A77 ziemlich genau die 869,4125MHz treffen sollte, erreicht mein RFM69HW dagegen eine Frequenz von 869,915MHz. Also gute +502,5kHz.
      Von meinen 10 RFM69W und 2 RFM69HW habe ich von -4xxkHz bis +5xxkHz alles vertreten.
      Eine Abgleichmöglichkeit für die Referenzfrequenz hat der RFM69 nicht.
      Einzige Möglichkeit ist die korrektur der Funkfrequenz über die drei Frequenzregister.

      Mein Kanaltabelle im E²PROM (16 Kanäle zu je drei Bytes) müsste also komplett auf den jeweiligen RFM69 angepasst werden.
      Die Alternative die ich mir ausdachte:
      Bei Inbetriebnahme eines Gerätes den Frequenzfehler feststellen und in einer Korrektur-Variable im E²PROM mit ablegen.
      Wie bewerkstellige ich das am simpelsten?

      Zunächst habe ich die drei Registerwerte (z.B. hD9, h7A, h77) und muss die zusammen führen in eine hinreichend breite Variable.
      Es ist eine Ganzzahl ohne Vorzeichen, also müsste ein Dword taugen:

      Dword = 0
      Dword = Registerwert MSB (hD9)
      Shift Dword , Left , 8
      Dword = Dword + Registerwert CSB (h7A)
      Shift Dword , Left , 8
      Dword = Dword + Registerwert LSB (h77)

      Müsste dann ein Dword mit h00D97A77 ergeben.

      Der Korrekturwert ist Vorzeichenbehaftet, kann ja auch negative Werte annehmen.
      Da wäre dann z.B. ein Long geeignet:
      Der aus obigem Beispiel erforderliche Korrekturwert -502,5kHz / 61,03526Hz = -8233 müsste als Long dann hFFFFDFD2 betragen.

      Die Korrektur dann simpel Dword + Long.

      Könnte das so funktionieren, oder habe ich da nen Patzer drin?

      Zum Schluss dann müsste das korrigierte Dword dann nur wieder aufgesplittet werden in drei Einzelbytes.
      Gibt es da spezielle Tricks unter Bascom mit wenigen Zeilen (ähnlich den zusammenfügen oben) für sowas?

      Bislang habe ich bei sowas gerne geschummelt und bitweise zerlegt:

      RegisterwertMSB.7 = Dword.23
      RegisterwertMSB.6 = Dword.22
      ........
      RegisterwertLSB.0 = Dword.0

      Also 24 Zeilen die den Quelltext nur unnötig unübersichtlicher machen.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Die Frequenz ergibt sich aus dieser Zahl multipliziert mit der PLL-Referenzfrequenz von theoretisch 61Hz.
      So liegt z.B. der Registerwert D9 7A 77 (Dezimal 14252663) multipliziert mit 61Hz auf 869,412443MHz.


      In der Praxis führt diese extrem niedrige PLL-Referenz für immense Frequenzfehler bereits bei minimalen Bauteilstreuungen.
      Während also von h7-h9 der theoretisch errechnete Wert hD97A77 ziemlich genau die 869,4125MHz treffen sollte, erreicht mein RFM69HW dagegen eine Frequenz von 869,915MHz. Also gute +502,5kHz.
      Von meinen 10 RFM69W und 2 RFM69HW habe ich von -4xxkHz bis +5xxkHz alles vertreten.
      ...

      Der Korrekturwert ist Vorzeichenbehaftet, kann ja auch negative Werte annehmen.
      Da wäre dann z.B. ein Long geeignet:
      Der aus obigem Beispiel erforderliche Korrekturwert -502,5kHz / 61,03526Hz = -8233 müsste als Long dann hFFFFDFD2 betragen.

      Die Korrektur dann simpel Dword + Long.

      Könnte das so funktionieren, oder habe ich da nen Patzer drin?
      Ist zwar schon ein Jahr alt, aber ich schreibe hier trotzdem etwas dazu, weil ich gerade am RFM66W dran bin, einem Modul, daß dem RFM69 sehr ähnlich ist mit etwas besseren Empfängerdaten.

      Die Bezugsfrequenz für die Berechnung der Sendefrequenz beträgt nur ungefähr 61 Hz. Genau beträgt sie 32 MHz / 2^19 = 61,03515625 Hz. Demzufolge ist die korrekte Frequenz bei Programmierung des Frequenzregisters mit hD97A77 (=14.252.663 dez) 869,91351318359375 MHz also 869,135132 MHz, was gegenüber der von Jürgen gemessenen 869,915 MHz nur 1,49 kHz also 1,7*10^-6 zu gering ist. Kein schlechtes Ergebnis wenn die Messung in Ordnung war. Das Modul verfügt über eine AFC, die während der Übertragung der Präambel einrastet, was stabile Übertragung ermöglicht.


      Was mich zu löngerem Fehlersuchen bewegt hat, war die Tatsache, daß ich (ohne darüber nachzudenken) für die Synchronbytes hAA verwendet habe. Die Präamble-Bytes sind aber defaultmäßig auch hAA, was dazu führt, daß das Modul sich bei der Präamble verzählt und der Empfang nicht funktioniert. Ein anderes Bitmuster für eine der beiden Datenarten löst das Problem.

      Gruß Ingo.
      Press any key to continue or any other key to abort!

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

    • Hallo zusammen,

      notgedrungen muss ich auch meine Anwendung mit RFM12B auf RFM69 umstellen.
      Mit erstaunen lese ich nun, dass die Ansteuerung offenbar gänzlich anders ausfällt und obendrein verstehe ich den Quellcode nicht.
      Für was denn so unglaublich viele Dimensionierungen und ein Array mit 99 Stufen?
      Gibt es eventuell schon eine fertige LIC/LIB von Mark oder ein fertiges Sample?

      VY73, Dieter (DB8PR)

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