Array Shiften?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Array Shiften?

      Hallo!

      Kämpfe schon seit längerem mit einem Projekt mit RFM69W und RFM69HW Transceivern.
      Inzwischen habe ich so viele Fallstricke mit diesen Teilen hinter mir, das ich demnächst dazu geneigt wäre hier einen Lexikonartikel zu diesen RFM69 zu erstellen.

      Aber hier habe ich jetzt mal eine gänzlich andere Frage:
      Um Bits innerhalb einer Variable nach links oder rechts zu shiften gibt es ja recht einfache Befehle. Aber wie sieht das mit Arrays aus?

      Ich sende zwischen meinen RFM69 GFSK-Pakete mit exakt 25 Bytes hin und her.
      Diese werden von den RFM69 not der nötigen Pramble (3Byte hAA), zwei beit Syncword (h22 , hF7) vor dem ersten und einer CRC16 nach dem 25.sten Nutzbyte ausgestattet und übertragen.
      Zusätzlich sorgt die Funktion Whitening das längere gleichwertige Bitketten den Empfänger nicht desynchronisieren.
      Also kurz gesagt: Ich nutze bereits sämtliche Sicherungsfunktionen für die Übertragung, welche die RFM69 bieten.

      Solch ein Datenpaket sieht bei mir z.B. so aus:

      A0 13 68 8F 0F 14 1A E4 6A 08 00 60 F2 A0 1B A0 03 A6 00 5F 00 00 00 00 36

      Das erste Byte setzt sich zusammen aus Kanal (MSB-Nibble) und Sensor-ID (LSB-Nibble) gefolgt von einem Timestamp:
      Byte 2 das Jahr
      Byte 3 Monat sowie Wochentag
      Byte 4 Tag + MEZ/MESZ
      Byte 5 Stunde
      Byte 6-24 sind Sensordaten
      Byte 25 ist eine eigene CRC8

      Ursprünglich habe ich die CRC8 weniger wegen der Funkübertragung vorgesehen, sondern zur Datensicherung während den zahlreichen umkopierungen.

      So wie oben das Musterpaket sehen also die Standardpakete aus welche ich beim Sender in den FIFO schiebe, und beim Empfänger aus dem FIFO ziehe.
      Der empfangende RFM tut (inzwischen) was er soll: Er empfänge die GFSK-Pakete, sucht nach dem Syncword, schiebt ins FIFO.
      Dann wird die CRC16 geprüft und das Paket im FIFO gesäubert: Alles vor dem Nutzdatenpaket (Dotting, Syncword) sowie die CRC16 wird abgeschnitten.
      Erst dann löst der RFM69 den Interrupt "PayloadReady" aus.

      Soweit funktioniert das, aber nicht wirklich zufriedenstellend:
      Etwa alle 40-60 Pakete meckert mein Testprogramm über folgenden Fehler:

      RFM69 erkennt die Reamble, erkennt das Syncwort, schiebt schön brav alles ins FIFO, und erkennt auch seine CRC16 als korrekt an.
      Lese ich nach der Meldung "PayloadReady" das FIFO aus, meckert mein Testprogramm das meine eigene CRC8 als letztes Byte falsch sei.

      Ein Blick in die Rohdaten zeigt schnell den Fehler: Flasche Paketsäuberung des RFM69:

      5B E7 82 A0 13 68 8F 0F 14 1A E4 6A 08 00 60 F2 A0 1B A0 03 A6 00 5F 00 00

      Am Anfang sind drei nicht abgeschnittene Müllbytes, Byte 1 ist um 4 Bytes nach hinten verschoben.
      Als Konsequenz sind am Ende die drei letzten Paketbytes abgeschnitten, darunter halt auch meine CRC8.

      Ich hänge gerade in der Abwägung:
      In der geplanten Endanwendung ist ein Protokoll vorgesehen wo jedes korrekt empfangende Packet (CRC16 intern + CRC8 extern) mit einem Ack-Paket quittiert werden soll. Kommt beim Sender innerhalb von 100ms kein Ack, soll das Paket erneut gesendet werden.

      Problem oberflächlich erledigt.

      Andererseits könnte ich beim Empfänger auch einfach größere Arrays auslesen und mein Paket darin suchen.
      Die Frage ist nur, was ist effizienter?

      Gibt es eine einfache Möglichkeit die Bytes innerhalb eines Arrays nach links zu verschieben?

      So nach art von...:

      If RX(30) = CRC8(RX(5), 29) then SHIFT RX(), 5, Left

      Grüße

      Jürgen
    • Meinst du etwas in der Art?

      BASCOM Source Code

      1. Dim Mein_array(25) As Byte
      2. Dim Temp1 As Byte , Temp2 As Byte , I As Byte
      3. Temp1 = Mein_array(1) 'Zur Sicherung falls nötig
      4. For I = 1 To 24
      5. Temp2 = Mein_array(i + 1)
      6. Mein_array(i) = Temp2
      7. Next I
      8. Mein_array(25) = Temp1
      Display All
      Das ist nur mal als Beispiel gedacht.
      Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
    • DG7GJ wrote:

      Inzwischen habe ich so viele Fallstricke mit diesen Teilen hinter mir, das ich demnächst dazu geneigt wäre hier einen Lexikonartikel zu diesen RFM69 zu erstellen.
      Hallo DG7GJ, da hätte ich großes Interesse dran.
      War selbst mal am überlegen für eine Datenfunkstrecke solche Module einzusetzen, habe dann aber Abstand genommen. Der Aufwand für das RF-Protokoll hat mich abgeschreckt. Dann habe ich zu fertigen RF-Modems mit UART-Schnittstelle (Kappa-m868) gegriffen, obwohl diese Teile ziemlich teuer sind aber einfacher in der Anwendung (dachte ich). Durch Fehler in der Dokumentation habe ich aber auch eine Weile gebraucht bis das lief. Ein universelles Stand-alone-modul mit Atmega und RFM69 wäre was wunderbares. :rolleyes: z.B. für eigenes Sensornetzwerk.
      Wenn ich deine Text richtig verstehe, meldet der empfangene RFM69 per Interrupt dass er ein gültiges Telegramm erhalten hat, legt aber im FIFO ein verschobenes Paket ab. Dann hilft auch keine ACK-Quittung, denn der RFM69 meint ja er hätte korrekt empfangen. Und das suchen im empfangenen Paket halte ich auch nur für eine Krücke. Dann schon mehrmalige Übertragung des Paketes und vergleichen. Beim erstmaligen Empfang löschen des FIFO und nochmal neu anfordern?
    • Einfach den index erhöhen/erniedrigen 'verschiebt' doch die Daten innerhalb des arrays. Wenn der index gleich bleiben soll, dann lege einfach mehrere overlays an, die dann zum Originalarray versetzt sind.
      Raum für Notizen

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

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

      Ich kämpfe gerade wieder an einer anderen Baustelle.
      Das Problem mit dem verschobenen FIFO-Array muss ich die Tage mal ausprobieren wie zweitintensiv ein manuelles suchen und umkopieren wäre.
      Also sequentiell halt bis zu 20 mal 24Bytes prüfen ob dahinter eine gültige CRC8 sitzt, und sich so Byte für Byte durch das Array arbeiten ob ich dort ein intaktes Paket finde.
      Gelingt mir das in deutlich unter 60ms (ATmega1284PA an 11,0592MHz Quarz) lohnt es sich. Dauert es länger spar ich mir das und überlasse es dem zukünftigen Protokoll.


      oscar wrote:


      DG7GJ wrote:

      Inzwischen habe ich so viele Fallstricke mit diesen Teilen hinter mir, das ich demnächst dazu geneigt wäre hier einen Lexikonartikel zu diesen RFM69 zu erstellen.
      Hallo DG7GJ, da hätte ich großes Interesse dran.War selbst mal am überlegen für eine Datenfunkstrecke solche Module einzusetzen, habe dann aber Abstand genommen. Der Aufwand für das RF-Protokoll hat mich abgeschreckt.

      Die RFM69 sowie die neueren RFM26 usw. reizen mich schon lange, weil sie vom Datenblatt her beherrschbar und gar nicht mal übel aussehen. Bei dem ersten Projekt hingegen entpuppten sich diese Teile als ziemlich wiederspänzig.
      Mehrfach als ich sporadisch mit diesem Projekt kämpfte suchte ich vergeblich im Internet nach Infomaterial.
      Datenblatt von Hope zum RFM69W und RFM69HW, zuzüglich dem Datenblatt zum SX1231 / SX1231h ist das eine. Praxiserfahrungen über den Umgang mit den zahlreichen Registern was gänzlich anderes.

      Beispiel Frequenz:
      Will man eine Funkfrequenz quarzstabil machen, nimmt man eine PLL...hat der RFM freilich.
      Aus meiner beruflichen Vorbelastung bin ich primär zwei PLL-Topologien gewohnt:
      Gewöhnliche PLL's welche den Referenzquarz auf eine dem Kanalraster entsprechende Vergleichsfrequenz teilen, auf einige duzend kHz, sowie Sonderformen welche als Vergleichsfrequenz direkt die Quarzfrequenz oder zumindest locker 10-20MHz verarbeiten.

      Der RFM69 gehört zu ersteren, allerdings teilt er ähnlich einer DDS: Das Quarz (32MHz) wird erst mal durch einen 19Bit-Counter gejagt und landet dann irgendwo bei 61,0xxHz. Das Quarz ist billig und hat entsprechende Streuungen, dementsprechend ungenau sind auch die 61Hz Vergleichfrequenz.
      Lange Rede, kurzer Sinn: Die Frequenzeinstellung ist höchstgradig bei jedem einzelnen RFM69 eigens ab zu gleichen.
      Oder anders gesagt:
      Meine Wunschfrequenz 869,4125MHz wäre nach Angaben aus dem Datenblatt / 61,035Hz = 14244491.
      Also hD9 5A 8B. Mehrere RFM69 mit genau diesen Frequenzdaten gefüttert führte dazu das nix klappte:
      870,1430MHz
      869,2143MHz
      870,4798MHz
      Prima...eigentlich hatte man PLL's ursprünglich entwickelt um genau sowas zu vermeiden.

      Ein weiteres leidiges Thema was mich jetzt gerade mal wieder nervt ist das Register h29 RssiThreshold.
      Eine Art skuriler "Rauschsperre".

      Wenn man den RFM69 korrekt initialisiert hat, auf Empfang schaltet, erwartet man das er so lange nach Paketen lauscht bis er eines empfangen hat, oder man den RX-Mode verlässt.
      Dumm nur wenn er nix empfängt:
      Im Hintergrund, nicht wirklich beeinflussbar durch den ATmega, läuft im RFM nämlich eine äusserst unintelligente Prozedur:
      Der Empfänger verharrt in einem "WAIT-Modus" so lange wie kein Signal die Rauschsperre durchbricht.
      Sobald irgend ein Signal die Rauschsperre triggert versucht der RFM die RSSI zu messen, den Vrequenzversatz, die AGC ein zu stellen und wartet auf das Syncwort.
      War es aber gar kein Nutzpaket sondern nur irgend eine Störung, dann sind die ganzen Registerwerte der getriggerten Messungen (AFC, AGC, RSSI) so verhunzt, das er ein danach ankommendes Nutzpaket schlicht nicht mehr auswerten kann.
      In diesem Zustand verharrt er.

      Man kann einen RssiTimeout definieren und über einen GPIO herrausführen.
      Dann kann man wenigstens reagieren: Modus wechseln auf Standby und wieder in RX.
      Ist die Rauschsperre (Register h29) zu niedrig, passiert das etwa alle 20ms, ist der Wert zu hoch wird gar nix mehr empfangen.
      Und wie ich gerde lerne, muss man offensichtlich die Rauschsperre dynamisch nachführen.

      Um so interessanter das man genau über solche Details im Internet keinerlei Erfahrungsberichte findet.

      Grüße

      Jürgen
    • Ich habe immer mit den RFM12 Teilen rumgemacht, die mich auch manchmal in den Wahnsinn getrieben haben. Das sind auch so Teile von Hope (dt. Hoffung).

      Die konnten auch so kunfiguriert werden, dass sie auf das SyncByte warten und dann empfangen.
      Das hat auch wunderbar funktioniert. Die Synkbytes hat das ding aber nicht ausgegeben.

      Ich hatte das über SPI betrieben und den internen Fifo benutzt.

      Aber einfach waren die Dinger nicht. Das dauerte bis die ordentlich liefen.
      Kaum macht man es richtig - und schon geht's!
    • DG7GJ wrote:

      Um so interessanter das man genau über solche Details im Internet keinerlei Erfahrungsberichte findet.
      Vielleicht weil fast alle genervt aufgegeben haben oder diejenigen welche das geschafft haben ihr Wissen für sich behalten. :?:
      Wenn ich deinen Ausführungen folge bin ich froh nicht in diese Teile investiert zu haben, schon weil mir die nötige HF-Messtechnik fehlt, das hätte nie funktioniert und ich nicht mal erfahren warum nicht.
      Ich hoffe du bleibst dran und lässt uns (mich) teilhaben. Habe mich auch schon gewundert warum über diese Module im Netz nichts brauchbares zu finden ist.
      Wie gesagt bleib hartnäckig, ich drücke dir die Daumen und bin neugierig auf das Ergebnis. :thumbsup:
    • Die Probleme mit den RFM Modulen treten meist schon auf, wenn man anfängt das Teil zu konfigurieren.
      Man denkt, dann tut alles. Aber das Modul muss sich auch Mitteilen. Beachtet ma nicht was einem das Modul mitteilen will, kann man auch nicht drauf reagieren.

      So gings mir. Immer nach einem PowerOn gings nicht auf Anhieb.
      Erst, wenn man mehrmals das Teil konfigurierte.

      Viele Ignorieren den /INT - Pin (ich war genauso). Man schrieb die Initialisierung und wollte senden.

      Wenn man aber hin geht nach dem Einschalten und auf den /INT Pin wartet und daraufhin das Statusregister liest, erfährt man auch, was das Modul will. Darauf muss man reagieren.

      Das /INT wird beispielsweise ausgelöst, nach dem PowerOn. Dann muss man das Teil initialisieren.
      Kommt dann wieder ein /INT, können Daten zur Abholung bereitstehen, oder der Senderegister kann wieder befüllt werden, usw. Nachdem ich das begriffen hatte gings auch.

      Alle Codes, die ich im Internet gesehen habe, gehen nicht auf das Statusregister ein und reagieren auch nicht darauf. Deswegen ist für mich auch einleuchtend, dass es nicht immer so klappt wie gewollt.

      Ein anderes Thema ist die PLL. Diese Erfahrungen mit falschen Frequenzen habe ich nicht gemacht.
      Die Frequenz wurde eingestellt und als korrekt (weil kein Messgerät vorhanden) angenommen.

      Der Empfänger hat alles auch empfangen. Um die Reichweite zu optimieren muss man bischen mit den Kondensatoren spielen (per Software einstellbar). Und ein wichtiges Merkmal ist immer auch die Antenne!

      Stimmt die wirksame Länge nicht, wird es schon schlechter mit der Reichweite.

      Gute Erfahrungen habe ich gemacht mit dem Mode, wo ein Byte in das TxRegister zum Senden geschrieben wird. In Verbindung mit den SyncBytes hat das gut geklappt. Sofern der Rest dann gestimmt hat.

      Die Datenblätter von Hope sind, mal mit Atmel-Datenblätter verglichen, schlicht gesagt unter aller Sa...u.
      Sogar dort wird im Konfigurationsbeispiel nicht auf das Statusbyte eingegangen.

      Mit solchen Informationen ist es natürlich schwer das Ding vernünftig zum laufen zu bekommen.

      Wie bereits erwähnt, habe ich meine Erfahrungen mit RFM01, RFM02 und RFM12 gemacht.
      Das neue Modul kenne ich nicht. Aber Hope hat wohl bezüglich Datenblätter nichts dazu gelernt.

      Eigentlich schade.
      Aber dann machen eben andere Hersteller das Rennen mit Modulen dieser Art.
      Kaum macht man es richtig - und schon geht's!
    • Hallo!

      Puh, stressig soein verteiltes Projekt: Habe in der Erstkonfiguration drei Teile die unterenander funken sollen.
      Ein Sensor, ein Repeater und ein Terminal.
      Eigentlich war Repeater und Sensor bereits im Teststadium prüfbar...liefen bereits seit Wochen mehr oder weniger zuverlässig.
      Beim Terminal lief anfangs auch alles vielversprechend, weswegen ich versuche das dortige LCD endlich in Betrieb zu nehmen.
      Auch ne Story für sich:
      Ein EAGOM128x64 der zusammen mit dem RFM69HW und dem ISP am HW-SPI hängt.
      Da aber die eadogm128x6-Lib offensichtlich nicht damit klar kommt das der RFM mit am selben Bus hängt, muss ich das display manuell, ohne Lib ansteuern.
      Mitten rein platzte mir gestern der Amoklauf des RssiTimeout bei allen drei Geräten.

      oscar wrote:


      DG7GJ wrote:

      Um so interessanter das man genau über solche Details im Internet keinerlei Erfahrungsberichte findet.
      Vielleicht weil fast alle genervt aufgegeben haben oder diejenigen welche das geschafft haben ihr Wissen für sich behalten. :?: Wenn ich deinen Ausführungen folge bin ich froh nicht in diese Teile investiert zu haben, schon weil mir die nötige HF-Messtechnik fehlt, das hätte nie funktioniert und ich nicht mal erfahren warum nicht.
      Ich hoffe du bleibst dran und lässt uns (mich) teilhaben. Habe mich auch schon gewundert warum über diese Module im Netz nichts brauchbares zu finden ist.
      Wie gesagt bleib hartnäckig, ich drücke dir die Daumen und bin neugierig auf das Ergebnis. :thumbsup:

      Informationen über Bastelprojekten mit den RFM69 gibt es im Netz zuhauf. Nur wie Mitch64 bereits andeutete handelt es sich nur um Ergüsse zahlreicher Raspi-Anwender die sich auf 1-2 fertige Softwareprojekte beziehen.
      Wenn ich mich da aber durch den C code quäle finde ich dort nix zu den Registereinstellungen.

      Was die HF-Meßtechnik angeht: Das wenigste in meiner Werkstatt kann überhaupt diese einzelnen 20ms-Pakete triggern.
      Um da Frequenzversatz, Hub, Ausgangspegel zu messen, muss man den RFM auf dauersenden halten.

      Kurz gesagt: Wichtigstes Meßmittel bei mir für dieses RFM-Projekt ist ein RTL-SDR Stick, und zwar genau solcheiner:
      rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
      Ich habe inzwischen drei dieser Sticks und verwende die als eine Art "HF-Taschen-Multimeter" zusammen mit der Software SDR#.

      Sendeleistung abgleichen im Sinne von "exakt +10dBm einstellen" geht damit NICHT.
      Aber man sieht sofort:
      - Frequenzversatz (exakter Frequenzabgleich)
      - Frequenzhub
      - Störspektrum---was funkt links und rechts sonst noch?

      Beispielsweise zeigt mir der 22$ preiswerte SDR-Stick das die dummen Rauchmelder in meiner Wohnung 500kHz unter meiner Frequenz liegen, aber auch gute 250kHz Kanalbreite fahren. Mit einer Rauschglocke die z.B. keine RssiThresholt triggert.

      Mitch64 wrote:

      Die Probleme mit den RFM Modulen treten meist schon auf, wenn man anfängt das Teil zu konfigurieren.
      Man denkt, dann tut alles. Aber das Modul muss sich auch Mitteilen. Beachtet ma nicht was einem das Modul mitteilen will, kann man auch nicht drauf reagieren.

      So gings mir. Immer nach einem PowerOn gings nicht auf Anhieb.
      Erst, wenn man mehrmals das Teil konfigurierte.

      Viele Ignorieren den /INT - Pin (ich war genauso). Man schrieb die Initialisierung und wollte senden.

      Wenn man aber hin geht nach dem Einschalten und auf den /INT Pin wartet und daraufhin das Statusregister liest, erfährt man auch, was das Modul will. Darauf muss man reagieren.
      Da gehöre ich nicht zu. Von Anfang an bei Planung der Platinen stand für mich fest das ich zwei DIO's nutzen wollte:

      DIO0 für entweder PayloadReady oder (inzwischen) CrcOK
      DIO4 für anfangs RSSI, zwischenzeitlich für Timeout.

      Zu diesem Zeitpunkt dachte ich mir das so:
      Wenn ein Paket empfangen wird, sollte DIO4 (RSSI) High werden damit ich eine RSSI auslesen kann.
      Kurz darauf sollte DIO0 (PayloadReady) High werden um zu signalisieren das ich das FIFO auslesen kann.

      Hat so wie gedacht aber nicht funktioniert.
      Denn RSSI ist (bei korrekter RssiThresholt) ein Maschinengewehr welches gefühlt jede ms wenn nicht sogar alle xxxµs feuert.
      Der RSSI-INT ist also kein INT der mitteilen will das man den RSSI auslesen soll.
      Viel mehr ist der RSSI-INT für mich eine Abstimmhilfe zum Abgleich des RssiThresholt.

      Sinn-Funktion von Rssi: Wenn der endlos rattert wie eine SCK-Leitung bei Empfangsbereitschaft ist alles OK, das muss so.
      Reist er ab läuft was schief: Der RFM hat dann seinen WAIT-Mode beendet und empfängt gar nix mehr.

      Ich benutze inzwischen am DIO4 den selterenen Timeout:
      Ich habe den Timeout2 (RssiTimeout) so gesetzt das er ungefähr zwei Paketlängen nach einem RSSI.INT wartet auf ein Payload Ready. Passiert das oben beschriebene, löst der Timeout aus.

      An DIO0 nutze ich nicht mehr den PayloadReady.
      Da ich nicht permanent zig Register umkonfigurieren will (kostet Zeit und vor allem Strom, geht hier um absolute Low-Power-Anforderung), will ich die Kommunikation möglichst rationalisieren.
      Für das DIO-Mapping heißt das: feste DIO-Einstellungen für Rx und TX.
      Und da ich bei Tx zwingend den INT "PacketSent" brauche, landet bei Rx dort der INT CrcOK an DIO0.

      Anfangs nahm ich blauäugig den CrcOK als gleichwertigen Ersatz für PayloadReady.
      Erst durch das oben angesprochene Verhalten des unaufgeräumten FIFO's gehe ich nun anders:

      Wird bei Rx der DIO0 High (CrcOK) lese ich zuerst 11 Register ein:

      h1E = FEI Status
      h1F = AFC Wert MSB
      h20 = AFC Wert LSB
      h21 = FEI Wert MSB
      h22 = FEI-Wert LSB
      h23 = RSSI Status
      h24 = RSSI Wert
      h25 = DIOmapping1
      h26 = DIOmapping2
      h27 = IRQ-Flags1
      h28 = IRQ-Flags2

      Landet alles in einem Array wo ich final in einer while-wend Schleife warte bis h28.2 High wird (PayloadReady).
      Allerdings brachte das keine Lösung: Der Fehler mit dem unaufgeräumten FIFO ist so genau so häufig der Fall wie bei auslesen nach CrcOK.


      Mitch64 wrote:


      Der Empfänger hat alles auch empfangen. Um die Reichweite zu optimieren muss man bischen mit den Kondensatoren spielen (per Software einstellbar). Und ein wichtiges Merkmal ist immer auch die Antenne!

      Stimmt die wirksame Länge nicht, wird es schon schlechter mit der Reichweite.

      Gute Erfahrungen habe ich gemacht mit dem Mode, wo ein Byte in das TxRegister zum Senden geschrieben wird. In Verbindung mit den SyncBytes hat das gut geklappt. Sofern der Rest dann gestimmt hat.

      Die Datenblätter von Hope sind, mal mit Atmel-Datenblätter verglichen, schlicht gesagt unter aller Sa...u.
      Sogar dort wird im Konfigurationsbeispiel nicht auf das Statusbyte eingegangen.
      Mit solchen Informationen ist es natürlich schwer das Ding vernünftig zum laufen zu bekommen.
      Wie bereits erwähnt, habe ich meine Erfahrungen mit RFM01, RFM02 und RFM12 gemacht.
      Das neue Modul kenne ich nicht. Aber Hope hat wohl bezüglich Datenblätter nichts dazu gelernt.
      Eigentlich schade.
      Aber dann machen eben andere Hersteller das Rennen mit Modulen dieser Art.
      Beim RFM69W / HW gibt es keine abgleichwerte mehr für irgendwelche Kapazitäten. Weder an der Antenne, noch dort wo sie braichal wichtiger wären: Dem Referenzquarz.

      Das Thema Antenne würde ich bei einem Lexikonartikel auch gleich mit erschlagen.
      Was du ansprichst, die Antennenlänge, ist nicht das einzige.
      Das Hauptproblem bei den zahlreichen Bastlers mit solchen 434 oder 868MHz-Modulen ist schlichtweg die Masse-Geometrie.

      Setzt man, wie die meißten da draußen im Web, einfach einen Drahtstummel auf eine Platinenkante, kommt es weniger auf die exakte Antennenlänge an, sondern eher was auf der Platine alles an Masse und Leiterbahnen sich als resonantes Gebilde entpuppt was gerne die Funktion der Antenne erfüllt, wenn die Antenne selber nicht kann. Im dümmsten Fall ist das eine SPI, ein I²C oder gar eine Vcc-Leitung die den StepDown grillt.
      Das mit den Antennenlängen auf Resonanz stimmt aber unter idealen Bedingungen:
      Also ohne große Leiterbahnführung möglichst nahe am Antennenanschluß des Moduls auf brauchbares Kabel (z.B. RG316 was ich nehme), und beim Gehäuseeinbau ein Gehäuse mit mindestens einer Alu-Frontplatte wählen, wo man die Antenne dann drauf setzt.

      Merke: HF sucht sich immer den Weg der gerne resoniert.
      Reflektiert die Antenne zuviel Sendeleistung, verteilt sich die Energie über die Platine.
      Und wer reichweitemäßig wirklich an die Grenzen gehen will (mit RFM69HW also stabile Verbindungen über >>800m) kommt ohne eigene HF-Schaltung am Antennenausgang des Moduls eh kaum zum ziel.
      Dabei rede ich nicht von einer Sendeendstufe...die +13....+20dBm die der RFM69HW kann reichen dafür locker.
      Vielmehr ginge es dann um einen rauscharmen LNA für den Empfang. Denn die oberen drei Stufen der RFM-AGC sind kaum Nutzbar vom Rauschverhalten.

      Jürgen