Es ist eine Fortsetzung aus: Beitrag "512 Byte-Sektor einer SD-Karte mit E32-868T drahtlos übertragen" (enthält auch das Datenblatt zum E32-868T) Zwischenzeitlich habe ich weitere Versuche mit dem E32-868T unternommen, um mehr als 58Bytes zu übertragen. Offensichtlich habe ich das Datenblatt nicht richtig verstanden, wo von einem Puffer von 512 Bytes gesprochen wird. Meine Frage: Was muss man tun, um den 512 Bytes Puffer zu laden (oder was ist mit Puffer gemeint?) und wie kann man den Inhalt versenden. Um über 58 Bytes zu kommen, habe ich versucht, einzelne Datenpakete zu je 58 Bytes zu versenden. Dazu werden nach dem Senden von 58 Bytes noch einmal die Adresse und der Kanal (empfaenger_festlegen) an den Empfänger gesendet und danach weitere Datenbytes. Das hat leider nur zum Teilerfolg geführt. Ab einer Summe von >97 Bytes wurden ab Byte 59 nur Nullen empfangen. Im Anhang die aus meiner Sicht entscheidenden Programmteile für das Senden. Hat schon jemand mit den Dingern ( E32-868T) erfolgreich gearbeitet und könnte mir helfen?
Nimms mir nicht für Übel, aber du solltest dich als erstens von diesen E32 Teilen trennen. Das was du willst, unterscheidet sich zu sehr von dem für das diese Teile gebaut sind. Das kann nur Frust erzeugen. Besser ist es hier direkt mit den Lora-Chips direkt zu arbeiten. RFM95 oder ein vergleichbares Board. Die sind nach etwas Einarbeitung auch nicht schwieriger zu handeln. Ausserdem können die E32xxx die Frequenz nur im 1MHz Raster einstellen, was zur Folge hat, dass man die in D kaum legal betreiben kann. Die E32 bestehen ja auch nur aus einen sx12xxx Chip und einen kleinen Controller und dieser Controller ist hier mehr im Wege als das er nützt.
Wolle G. schrieb: > Offensichtlich habe ich das Datenblatt nicht richtig verstanden, wo von > einem Puffer von 512 Bytes gesprochen wird. > Meine Frage: Was muss man tun, um den 512 Bytes Puffer zu laden (oder > was ist mit Puffer gemeint?) und wie kann man den Inhalt versenden. Hallo, das Datenblatt habe ich eben einige Zeit gelesen. Ja, der 512-Byte-Puffer scheint wirklich zu existieren. Es scheint so, also mußte man nach den ersten 58 Bytes einfach weiter Bytes einschreiben, damit weiter gesendet wird. Oberhalb von 58 Bytes werden dann angeblich automatisch neue Pakete generiert, die wiederum 58-Bytes-Bündel enthalten. Vermutlich paßt dies zum 64-Byte-Puffer des SX1278 und ist fix vorgegeben. Das Datenblatt läßt auf den ersten Blick die Funktionsweise nicht genau erkennen, da es wie so oft recht schwammig formuliert ist. Nach Übertragung von so einem 58-Bytes-Paket ändert sich anscheinened AUX, um zu signalisieren, daß das nächste 58-Bytes-Paket eingefüllt werden kann. Füllt man keine weiteren Daten mehr ein, wartet es drei Bytes lang und sieht das als Ende an. So weit mein Verständnis bisher. mfG
Christian S. schrieb: > das Datenblatt habe ich eben einige Zeit gelesen. Ja, der > 512-Byte-Puffer scheint wirklich zu existieren. Es scheint so, also > mußte man nach den ersten 58 Bytes einfach weiter Bytes einschreiben, > damit weiter gesendet wird. Oberhalb von 58 Bytes werden dann angeblich > automatisch neue Pakete generiert,.... Danke. So hatte ich es im Wesentlichen auch verstanden. Leider führten meine Versuche, auf diese Art mehr als 58 Bytes zu senden, noch nicht so richtig zum Erfolg. Nur wenn ich nach 58 Bytes noch einmal Adresse und Kanal eingebe, werden weitere 58 Bytes richtig übertragen. Da es einen 512 Bytes großen Puffer geben soll, wollte ich diese Verfahrensweise mit der 58Bytes-Stückelung vermeiden. Deshalb noch einmal die Frage an alle Experten, welcher Weg zum Ziel führen könnte. temp schrieb: > RFM95 oder ein vergleichbares Board. Die sind nach etwas Einarbeitung auch > nicht schwieriger zu handeln. Wäre RFM69HW, 868 MHz vergleichbar? Damit hatte ich vor einigen Jahren leider keinen Erfolg. Deshalb wollte ich es nun mit E32-868T versuchen. Damit hat sich wenigsten ein Teilerfolg eingestellt. Wenn jemand ein funktionstüchtiges Programm für RFM69HW, 868 MHz für mich übrig hat, würde mich es freuen. (vorzugsweise Ansteuerung mit MSP430F1611 o. ä.)
Hallo, das RFM95 ist dem RFM69 sehr ähnlich, nur um LoRa erweitert mit einem zweiten Satz Registern zum Umschalten. RFM69 kann bis 255 Bytes Paketlänge im Paketmodus übertragen: https://cdn.sparkfun.com/datasheets/Wireless/General/RFM69HCW-V1.1.pdf 5.5.2. Packet Format 5.5.2.1. Fixed Length Packet Format 5.5.2.2. Variable Length Packet Format 5.5.2.3. Unlimited Length Packet Format Das klappt aber nur so lange, wie auch der Empfänger des laaangen Datenpaketes den Takt der FSK-Modulation mit halten kann, sonst überspringt er das eine oder andere Bit und detektiert falsch. Das Datenblatt ist recht umfangreich und trickreich kompliziert beschrieben. Codeschnipsel habe ich im Forum irgendwo schon mal verewigt, finde sie aber momentan nicht. mfg
Christian S. schrieb: > Codeschnipsel habe ich im Forum irgendwo schon mal > verewigt, finde sie aber momentan nicht. Es muss ja nicht sofort sein. Ich wäre sehr an einem Schnipsel interessiert.
Wolle G. schrieb: > Wäre RFM69HW, 868 MHz vergleichbar? Damit hatte ich vor einigen Jahren > leider keinen Erfolg. RFM69W kann kein Lora, somit ist das nicht vergleichbar. Der prinzipielle Umgang mit den Modulen ist aber vergleichbar. Wenn du von den besseren Reichweiten im Lora Modus profitieren willst, wird es langsamer. Trotzdem noch eine Frage. Wie oft und wie viele solcher 512-Byte Blöcke musst du denn übertragen und in welcher Zeit? Ich vermute mal dass dein Vorhaben die 0,1% bzw. 1% Regelungen im 868MHz Band damit sprengen wird. Außerdem erhöhen zu lange Einzelpakete die Fehleranfälligkeit deutlich. Die Lora Chips kommen alle von Semtech, egal ob auf dem RFM9x oder ES32xxx, und die haben nur 256Byte RAM für die Buffer, somit kommst du um eine Stückelung sowieso nicht herum. Wolle G. schrieb: > Wenn jemand ein > funktionstüchtiges Programm für RFM69HW, 868 MHz für mich übrig hat, > würde mich es freuen. (vorzugsweise Ansteuerung mit MSP430F1611 o. ä.) Dazu findest du auf github gefühlte tausende Beispiele. Es ist ja auch nur immer das gleiche: Über SPI ein paar Register füllen bzw. lesen. Wie der Controller heißt ist ja völlig egal. Und wenn du mit SPI schon überfordert sein solltest, dann lerne oder lass es ganz. Eventuell ist eine komplett andere Technologie wie WLAN für das gesamte Vorhaben die bessere Alternative. Aber dazu müsstest du uns mehr verraten.
temp schrieb: > Trotzdem noch eine Frage. Wie oft und wie viele solcher 512-Byte Blöcke > musst du denn übertragen und in welcher Zeit? Ich vermute mal dass dein > Vorhaben die 0,1% bzw. 1% Regelungen im 868MHz Band damit sprengen wird. > Außerdem erhöhen zu lange Einzelpakete die Fehleranfälligkeit deutlich. > Die Lora Chips kommen alle von Semtech, egal ob auf dem RFM9x oder > ES32xxx, und die haben nur 256Byte RAM für die Buffer, somit kommst du > um eine Stückelung sowieso nicht herum. Der gute Wolle ist Ü80 und hat keinen nennenswerten Programmiererhintergrund. Mit Englisch steht er auf Kriegsfuß. Ich bewundere seine Ausdauer, hab da aber auch Mitleid. Denn er versucht da was, das ein GUTES Stück außerhalb seiner Reichweite liegt. Man kann das Problem schon mit seiner Hardware lösen, dazu braucht es aber DEUTLICH mehr Wissen und Erfahrung, als er hat. Und das geht bei Kleinigkeiten der C-Programmierung los.
Das Thema muss mal wieder aus dem Keller geholt werden. Gibt es zwischenzeitlich jemanden, der eine Lösung kennt, wie man an den 512Byte Puffer kommt und den Inhalt ohne nennenswerte Unterbrechungen in einem "Rutsch" versenden kann. Oder wie müsste man das Datenblatt dazu deuten?
Wolle G. schrieb: > Das Thema muss mal wieder aus dem Keller geholt werden. Warum? Dort war es gut aufgehoben. > Gibt es zwischenzeitlich jemanden, der eine Lösung kennt, wie man an den > 512Byte Puffer kommt und den Inhalt ohne nennenswerte Unterbrechungen in > einem "Rutsch" versenden kann. Da fehlt ein Fragezeichen. Wenn dein Tranceiver keine so langen Datenpakete versenden kann, muss man diese halt in kleine Brocken aufteilen. Ist doch logisch. Aber ja, dabei muss man schon das eine oder andere Detail beachten. Und ja, dazu braucht es DEUTLICH mehr Ahnung von C und Programmiertechnik, als du sie hast. Tu dir einen Gefallen und such dir ein Hobby, daß im Rahmen deiner Möglichkeiten liegt. Ich spiel auch nicht Klavier und tanze auch kein klassisches Ballett.
Falk B. schrieb: > Und ja, dazu braucht es DEUTLICH mehr Ahnung von C und > Programmiertechnik, als du sie hast. > Tu dir einen Gefallen und such dir ein Hobby, daß im Rahmen deiner > Möglichkeiten liegt. Warum solch unnötigen und nicht helfenden Zeilen? Was hat das mit der Hilfeanfrage zu tun? Schade um die Zeit, um diesen Text zu schreiben. Wir sind doch hier nicht in sozialen Netwerken, wo viel Stuss abgesondert wird. (Oder wie man die Netzwerke nennt) Besser wäre vielleicht ein ähnlicher Stil, wie die Dir bekannten ehemaligen Forenteilnehmer Buchegger oder Rufus an den Tag legten. Einfach mal analysieren und vergleichen! und beachten Nun wieder zum Problem und zu meinem Stand: Mit der Funktion "void wert_an_E32(void)" lassen sich jetzt in den E32-xx 512 Byte "irgendwo einlagern" , um danach übertragen zu werden. Nach jeweils 58 Bytes muss jedoch noch einmal die Funktion "void empfaenger_festlegen(void)", also die Adresse und der Kanal vom Empfangsgerät, eingefügt werden. Die Übertragung ("wert_an_E32") in den E32xx (Sendegerät) dauert nach Oszi-beobachtung ca. 600ms. Danach beginnt die eigentliche Sendung an das Empfangsgerät. Beobachtet man dort mit dem Oszi den Empfang an TXD von E32xx, so werden jeweils im Abstand von ca 600ms 58Bytes empfangen. Nach 512 Bytes ist die Übertragung beendet. Die Kontrolle an meiner Flüssigkristallanzeige (FKA) zeigt, dass alle Bytes richtig angekommen sind. Überschreitet man die 512 Bytes, z.B. dadurch, dass zum Schluss statt 48 Bytes 49 Bytes eingegeben werden, dann werden nur 1 x 58 Bytes, also nur ein Datenpaket, übertragen. Im Anhang die Konfiguration vom Sender und die genannten Funktionen. Was könnte man evtl. in der Zeile: txbuffer[3] = 0x1A // 8N1, UART baut rate:9600 (bps), // Übertragungsrate:2,4k (bps) (oder wo ) noch ändern, um den Abstand zwischen den 58-Bytes-Datenpaketen zu verkürzen? Hoffentlich habe ich mich verständlich genug ausgedrückt und vielleicht könnte jemand mir helfen.
:
Bearbeitet durch User
Hallo, schaue doch mal, was hier über die Datenrate bei LoRa zu lesen ist auf Seite 2. https://lora-developers.semtech.com/uploads/documents/files/Understanding_LoRa_Adaptive_Data_Rate_Downloadable.pdf Da ist angegeben, daß die Dauer einer Übertragung vom Spreizfaktor abhängt. Im Detail kenne ich mich damit nicht aus und lese mich jetzt nicht stundenlang ein. Es scheint also, daß die Dauer Deiner 512-Bit-Übertragung anstatt 22 ms eben die 600 ms benötigt, weil bei LoRa mehrmals das gleiche ausgesendet wird und noch gespreizt wird (kann falsch beschrieben sein, vorsicht). Erste Idee wäre also, den Spreizfaktor zu ändern, falls dies per Konfiguration möglich ist. Es schient ja jetzt wie gewünscht zu funktionieren, auch wenn "empfaenger_festlegen(); " ständig wiederholt werden muß. Man könnte mit Logik annehmen, daß es so sein müßte, oder auch nicht, weil das Datenblatt sich hierzu ausschweigt. Wolle G. schrieb: > Überschreitet man die 512 Bytes, z.B. dadurch, dass zum Schluss > statt 48 Bytes 49 Bytes eingegeben werden, dann werden nur 1 x 58 Bytes, > also nur ein Datenpaket, übertragen. Das hätte ich so ähnlich erwartet, da der Sender auf Verdacht entscheidet, ob ein Datenpaket zu Ende ist oder ob da ein Fluß von Daten ständig weiter ankommt. Der 512-Byte-Puffer läuft dann über, bzw die Software im Modul füllt dann wieder von Anfang an auf. Kommen dann beim Empfänger die 512-Bytes-Daten als Ganzes heraus oder in 58er-Paketen? Ist die Wiederholung der Adresse dann herausgelöscht? WAs zeigt denn die Flüssigkristallanzeige? mfg
:
Bearbeitet durch User
Christian S. schrieb: > 5.5.2.3. Unlimited Length Packet Format > > Das klappt aber nur so lange, wie auch der Empfänger des laaangen > Datenpaketes den Takt der FSK-Modulation mit halten kann, sonst > überspringt er das eine oder andere Bit und detektiert falsch. > Das Datenblatt ist recht umfangreich und trickreich kompliziert > beschrieben. Codeschnipsel habe ich im Forum irgendwo schon mal > verewigt, finde sie aber momentan nicht. Ist es :D Es funktioniert aber aber hab es selber so im betrieb mit rund 1000 Bytes Aber Mehr habe ich nicht hinbekommen, zu einem geht beim XMEGA gerne der Speicher aus wenn man das mit UART noch versenden will und auch ein Paar packte puffern will. Danach hatte ich meistens CRC fehler bestimmt hätte ich aber noch was an den RF Einstellungen tunen Könen. Vereinfacht gesagt musst du dich um alles kümmern CRC, Paket Head, reset by Time-outs wann dein Packet fertig ist das genug um Puffer ist etc....
Christian S. schrieb: > Das hätte ich so ähnlich erwartet, da der Sender auf Verdacht > entscheidet, ob ein Datenpaket zu Ende ist oder ob da ein Fluß von Daten > ständig weiter ankommt. Der 512-Byte-Puffer läuft dann über, bzw die > Software im Modul füllt dann wieder von Anfang an auf. Wie oft muss man das noch wiederholen, mag sein dass der Controler im E32 512 Byte Buffer hat, der Lora Chip aber nicht. Und der kann auch keinen Datenstrom senden, sondern nur Pakete. Da steckt dann auch jedesmal eine oder mehrere Kennungen, CRCs u.s.w. drin. Wenn du den E32 mit Daten fütterst, macht es in meinen Augen keinen Sinn blind die Daten da reinzuhauen. Halte dich an die genannte Grenze von 58 Byte und schreib erst die nächsten rein, wenn das letzte Packet draussen ist. Dann hast du wenigstens die Kontrolle über den Prozess. Anderenfalls macht der E32 Auto sub packing über das du keine Kontrolle hast. Auf der Empfänger Seite kommen die Daten sowieso in Paketen an und nicht als Datenstrom. Und fehlende oder kaputte Pakete musst du auch berücksichtigen und eventuell wiederholen. Es wird wirklich Zeit, dass du mal mit der Sprache rausrückst was das überhaupt werden soll.
Christian S. schrieb: > Es schient ja jetzt wie gewünscht zu funktionieren, auch wenn > "empfaenger_festlegen(); " ständig wiederholt werden muß. Man könnte mit > Logik annehmen, daß es so sein müßte, oder auch nicht, weil das > Datenblatt sich hierzu ausschweigt. Richtig. Im Prinzip funktioniert die 512 Bytes Übertragung. Ich kann mir aber nur schwer vorstellen, dass man immer zwischen zwei Datenpaketen (je 58 Bytes) ca. 600ms warten muss und hoffe, dass jemand den Grund für diese Arbeitsweise kennt. Dann hätte man evtl. eine Möglichkeit, noch irgendwo zu "drehen". s. u. temp schrieb: > Es wird wirklich Zeit, dass du mal mit der Sprache rausrückst was das > überhaupt werden soll. Es sollte es eigentlich egal sein, warum sektorenweise Daten einer SD-Karte übertragen werden sollen. Aber wenn es hilft? Es werden in einem Heizungskeller alle 8s 8 Temperaturen (VL, RL,AT, WW usw.) mit den Temperaturfühler DS18B20 gemessen und auf einer SD-Karte abgespeichert. Im unregelmäßigen Abständen wird die auf der SD-Karte befindliche Datei auf einen Laptop kopiert und am Rechner werden dann die Messwerte in Kurven umgewandelt. Jetzt kam die Idee des Bastlers, dass man mit einer Fernübertragung sich die "Arbeit erleichtern" kann. Dazu soll der Inhalt der Datei, die sich auf der SD-Karte des Datenspeichers befindet, auf Knopfdruck sektorenweise (512 Bytes) gelesen und dann verschickt werden. (so die Vorstellung) Wie schon mal angedeutet, wollte ich evtl., falls sinnvoll, an der Konfiguration noch etwas ändern, um zunächst den aktuellen Abstand (ca 600ms) zwischen den gesendeten Datenpaketen (58 Bytes) zu verringern. (Zeile: txbuffer[3] = 0x1A; s. o. 28.1.22) Unter DB Pkt. 7.5. "Parameter setting command " gibt es den Pkt. "Air data rate", den ich nicht deuten kann. Was ist darunter zu verstehen? (Laie !)
:
Bearbeitet durch User
Wolle G. schrieb: > Es werden in einem Heizungskeller alle 8s 8 Temperaturen (VL, RL,AT, WW > usw.) mit den Temperaturfühler DS18B20 gemessen und auf einer SD-Karte > abgespeichert. Im unregelmäßigen Abständen wird die auf der SD-Karte > befindliche Datei auf einen Laptop kopiert und am Rechner werden dann > die Messwerte in Kurven umgewandelt. > > Jetzt kam die Idee des Bastlers, dass man mit einer Fernübertragung sich > die "Arbeit erleichtern" kann. > Dazu soll der Inhalt der Datei, die sich auf der SD-Karte des > Datenspeichers befindet, auf Knopfdruck sektorenweise (512 Bytes) > gelesen und dann verschickt werden. (so die Vorstellung) Ich hatte sowas befürchtet. Denn Sinn kann ich allerdings nicht verstehen. Wenn man 8 Werte pro Record hat mit max je 2 Byte sind das 16 Byte. Genau für so etwas ist LORA gemacht. Mehr würde ich auch nicht am Stück versenden. Und wenn du Temperaturen alle 8s versendest, ist das schon ein extrem feines Raster. Wozu dann überhaupt noch die SD Karte? Selbst wenn 1% der Pakete verloren gehen reicht das für Temperaturanwendungen sicher aus. Was du vorhast ist ein Bulk-Transfer von mehreren kb wenn das per Hand bedient werden soll. Das geht mit LORA weder rechtlich noch praktikabel. Für sowas ist WLAN (ESP32 o.ä.) oder Bluetooth sicher besser geeignet. Ab diesem Punkt bin ich hier raus. Wenn du mit dem Kopf durch die Wand willst, dann bastle weiter an hoffnungslosen Sachen.
temp schrieb: > Wenn du mit dem Kopf durch die Wand willst, dann bastle weiter an > hoffnungslosen Sachen. > Wozu dann überhaupt noch die SD Karte? Ganz einfach. Mein Datenspeicher mit einer SD-Karte läuft jetzt schon erfolgreich über 10 Jahre und es gibt keinen Grund, die bewährte Speicherung zu ändern. Das Fernauslesen ist nur eine neue Idee zur Befriedigung des Spieltriebes. Wenn die Idee aber nicht machbar sein sollte, halb so schlimm. Die sichere Datenspeicherung auf SD bleibt ja erhalten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.