Hallo, ich möchte über eine Funkstrecke Daten übertragen. Ich möchte ein Außenthermometer mit den RFM69 vom Pollin bauen. Da möchte ich aber nicht -9.8 übertragen (hatten wir letzte Nacht) (das wären ja 4 Bytes) sondern etwas platzsparenderes. Ich hab mir gedacht, dass man ja als erstes Byte den Wert von -128 bis +127 übertragen kann, als zweiten die Nachkommastelle (hier brauche ich nicht 0-255 sondern nur 0-9, also auch wieder Verschwendung irgendwie). Ich könnte auch die zwei Bytes zusammenlegen und könnte dann −32.768 bis 32.767 codieren. Das auf einen sinnvollen Temp Bereich gemappt (z.B. -40 bis +88 --> 128°) ergibt zB. folgendes: Wertebereich = 65.535 (dh. ich habe eine Auflösung von 128 / 2^16 = 1/512 = 0,0019° = mehr aus Ausreichend!!) Nullpunkt auf -40° Festgelegt, also 0 = -40°; 1=-39,998°; 20480=0°; 65535=+127,998° So kann ich mit zwei Byte wesentlich mehr Information übertragen. Soweit die Theorie. Das Thermometer soll aber auch die relative Luftfeuchte übertragen (und ggf. irgendwann nochmal die Windgeschwindigkeit). Dh. ich muss die einzelnen Messwerte irgendwie abgrenzen. Das könnte ich entweder mit einem festen "Protokoll" (den Namen verdient es wohl nicht ganz) machen, nämlich Byte0 und Byte1 = Temp, B2+B3=rel.LF, B4+B5=Windgeschwindigkeit, B6+B7=Regenmenge etc. Dann habe ich aber das Problem, dass jeder Sensor alles senden muss, brz. nciht vorhandene Daten mit 00 füllen muss. Kacke. Nix gewonnen. Alternativ stelle ich jedem Messwert einen Identifier voraus (0x00 für Temp, 0x01 für rel.LF etc.) so könnte ich mit einem Byte 255 Größen unterscheiden. DAs ist ja schonmal was. ISt immer noch ein Byte weniger als die ursprünglichen -9.2 :-) Nun meine Frage: Sollte ich zw. den einzelnen Werten bzw. ihren Bezeichnern irgendwie eine "Pause" einbauen damit der Empfänger merkt, dass der Wert hier zu Ende ist? Ich denke nicht, da ich mich mit dem Protoköllchen ja auf ein Tripel "Identifier-LowByte-HighByte" festgelegt habe. Außerdem sehe ich das Problem, dass der Trenner (zb.0x42) ja auch als Wert vorkommen kann. Ich habe dazu das hier gelesen (natürlich die ganzen Threads aber das sind markante Ansichten): Beitrag "Re: UART Daten binär übertragen" und Beitrag "Re: STM32 USART Strings verarbeiten" Es läuft dann doch irgendwie wieder auf "Zahlen als Zahlen" und "Steuerzeichen als Steuerzeichen" übertragen hinaus... Ich bin etwas ratlos. Gibt es einen Königsweg? Danke schonmal vorweg.
Abgesehen von dem, dass für die Temperatur ein Byte mehr als ausreichend ist (damit kann man immerhin 255 Zeichen kodieren, bei 0.5° Schritten kannst du damit immerhin knapp delta Temp = 126° übertragen, und so genau gehen Temperatursensoren eh nicht), kann man das schon machen. Also einfach ID (1Byte) Wert (2Byte). Warum soll man dann eine Pause einlegen müssen? Wenn zu jeder ID genau 1 Bytewert gehört ist das überhaupt nicht nötig. Und wenn du mehr als 1 Byte benötigst, könntest du die IDs bisserl runterbrechen (z.B. nur noch 6 Bit ID) und die restlichen Bit kodieren dann die Anzahl an Bytes die zu der ID gehören. Alles ganz normal!
Lachsack schrieb: > Außerdem sehe ich das Problem, dass der Trenner (zb.0x42) ja auch > als Wert vorkommen kann. Dann trenne dich vom Denken in Bytes. Und du willst nicht wirklich ganze 8 Bit für einen Trenner verschwenden, oder? Überlege dir, wieviele Datensatzidentifier du brauchst und welchen Informationsgehalt (Anzahl Bits) deine einzelnen Sensoren übertragen sollen. Für die Windgeschwindigkeit brauchst du nie und nimmer 16 Bit. Du wirst keinen Sensor finden, der so hoch aufgelöst messen kann. Dafür wirst du vielleicht 4 oder 5 Bit für die Windrichtung brauchen u.s.w.
Lachsack schrieb: > Nun meine Frage: Sollte ich zw. den einzelnen Werten bzw. ihren > Bezeichnern irgendwie eine "Pause" einbauen damit der Empfänger merkt, > dass der Wert hier zu Ende ist? Ich denke nicht, da ich mich mit dem Ich denke doch. Da du keine richtigen Pakete schickst und jede Bytekombination vorkommen kann, ist der einzig richtige Weg Pakete zu unterscheiden, die Pause dazwischen. Eine Pause von 5ms reicht vollkommen, um in der Timer ISR einen Flag zurückzusetzen (oder zu setzen). Und mit 3 bit für Temp/Wind/Feuchte etc. bleiben dir noch 5 bit übrig für Sensoradresse.
ui schrieb: > Alles ganz normal! Hehe, danke :-) Ganz normal ist es wohl für den, der das regelmäßig macht oder zumindest schon Langzeiterfolge > 0 hat. Ich bin da noch nicht so firm. Klar, 0,002 Auflösung brauche ich bei der Temperatur nicht!! Zugegebenermaßen fällt mir gerade auch nichts ein, was mit 255 Schritten nicht praxisgerecht abbildbar ist. Aber nun. OK, also das spricht jetzt für ein festes Format ohne interne Synchronisation.
Lachsack schrieb: > Da möchte ich aber nicht -9.8 übertragen (hatten wir letzte Nacht) (das > wären ja 4 Bytes) sondern etwas platzsparenderes. Kann der Sensor überhaupt auf Zehntel Grad genau auflösen? Wenn nein: Ein einzelnes Byte reicht für Temperaturwerte von +128 bis +127. Oder für einen halb so großen Bereich wenn man halbe Schritte zulässt, wie der Kollege über mir schon geschrieben hat.
Marc V. schrieb: > Eine Pause von 5ms reicht vollkommen, um in der Timer ISR einen Flag > zurückzusetzen (oder zu setzen). Das verstehe ich jetzt nicht. Ich will ja nicht dauernd auf den Kanal blasen. Ich übertrage vlt. max alle 10 Minuten die Temperatur, Windgeschwindigkeit ggf. öfters, aber vlt. auch nur den Maximalwert der letzten Messperiode.
Lachsack schrieb: > Marc V. schrieb: >> Eine Pause von 5ms reicht vollkommen, um in der Timer ISR einen Flag >> zurückzusetzen (oder zu setzen). > > Das verstehe ich jetzt nicht. > Ich will ja nicht dauernd auf den Kanal blasen. Ich übertrage vlt. max > alle 10 Minuten die Temperatur, Windgeschwindigkeit ggf. öfters, aber > vlt. auch nur den Maximalwert der letzten Messperiode. Na das meinte doch Marc. Er hat eben 5ms angesetzt, bei dir sind es eben 5min. Kleiner Unterschied, aber egal. Das ist eben eine Pause von 5min. Genauso machen es auch die Funkthermometer. Sie senden ca. 1mal pro Minute und den Rest der Zeit schlafen sie. Der Empfänger muß nur rechtzeitig bereit sein für den Datenempfang. Den Rest der Zeit kann er ebenfalls schlafen.
Lachsack schrieb: > Marc V. schrieb: >> Eine Pause von 5ms reicht vollkommen, um in der Timer ISR einen Flag >> zurückzusetzen (oder zu setzen). > > Das verstehe ich jetzt nicht. > Ich will ja nicht dauernd auf den Kanal blasen. Ich übertrage vlt. max > alle 10 Minuten die Temperatur, Windgeschwindigkeit ggf. öfters, aber > vlt. auch nur den Maximalwert der letzten Messperiode. Dann ist ein Timeout als Kennzeichnung für das Übertragungsende doch eigentlich am sinnvollsten. So kommst du mit wenigen Bytes aus und der Sender kann den Timeout buchstäblich "im Schlaf" auslösen, also direkt nach Versand des letzten Bytes im Frame in einen stromsparenden Modus gehen (bei 8N1 kann er 10 Bitzeiten eher in den Sleep gehen).
Nimm doch 2 Byte = 16 Bit große Telegramme. In den Obersten zwei Bit kodierst du die Art des Paketes (00 = Temperatur, 01 = Luftfeuchte, 10 = Windgeschwindigkeit, 11 = ?). Dann hast du immer noch 14 Bit (= 8192 Werte) für die Information übrig.
Mark B. schrieb: > Lachsack schrieb: > Kann der Sensor überhaupt auf Zehntel Grad genau auflösen? > Ich nehme diese hier: http://www.mouser.de/ProductDetail/Silicon-Labs/SI7051-A20-IM/?qs=sGAEpiMZZMs29kr3d%252bndI0%252bCGT8zbcuMtQC1OmGiLoQ%3d und https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280_DS001-11.pdf
Und warum dann dieser umständlich Hokuspokus? Da ist doch genug Zeit für eine ASCII Übertragung, die zur Not und zum Debuggen von jedem Terminal angezeigt werden kann. Ich auf jeden Fall würde so lange wie möglich an ASCII festhalten...
Lachsack schrieb: > Das verstehe ich jetzt nicht. > Ich will ja nicht dauernd auf den Kanal blasen. Ich übertrage vlt. max > alle 10 Minuten die Temperatur, Windgeschwindigkeit ggf. öfters, aber > vlt. auch nur den Maximalwert der letzten Messperiode. Dann hast du ja doch schon eine Pause dazwischen, warum fragst du danach ? Vielleicht diesen Wert senden, Pause von 5-50ms, nochmals senden und dann ist Schlafen für die nächsten 10 Minuten angesagt...
Lachsack schrieb: > Das verstehe ich jetzt nicht. > Ich will ja nicht dauernd auf den Kanal blasen. Ich übertrage vlt. max > alle 10 Minuten die Temperatur, Windgeschwindigkeit ggf. öfters, aber > vlt. auch nur den Maximalwert der letzten Messperiode. Das verstehe ich jetzt nicht. Warum willst Du Bytes sparen, wenn Du sowieso Zeit wie blöd hast? Oder ist das nur eine theoretische Überlegung ohne praktischen Nährwert?
Hallo, darüber habe ich vor Jahren nachgedacht, als ich meine Sensoren mit dem RFM02 gebaut habe. Letztlich war die Entscheidung, größenteils ASCII zu übertragen. Hatte beim Debug den Vorteil daß ich es direkt lesen konnte. Es werden fest 28 Byte übertragen, Sensornummer, Kennung für Sensor (1 Temperatur, 2 Feuchte usw. Wert mit fester Stellenzahl, also links Leerzeichen, wenn der Wert kürzer ist. Der Aufwand im Tiny ist minimal, die Sendzeit mit 19200 kurz genug. Eine CR2032 lebt selbst im Gefrierfach des Kühlschranks ca. 9 Monate trotz (unnötig häufiger) Übertragung alle Minute. Ich habe für mich keinen Grund gesehen, da irgendwelche Bytes einzusparen. Gruß aus Berlin Michael
Mach es so wie serielle Mäuse. Die nehmen ein gesetztes Bit 7 als Kennung für den Start eines neuen Paketes. Alle folgenden Bytes des Pakets haben Bit 7 gelöscht. Damit ist eine Synchronisation auf den Anfang eines neuen Paketes immer eindeutig möglich. fchk
Michael U. schrieb: > Eine CR2032 lebt selbst im Gefrierfach des Kühlschranks ca. 9 Monate > trotz (unnötig häufiger) Übertragung alle Minute. Es würde mich interessieren, wie Du da das Gehäuse gemacht hast. Vor allem, wie Du es wasserdicht gemacht hast. Magst Du das mal mit ein paar Fotos und Sätzen dazu in Projekte einstellen? Das wäre nett.
Dietrich L. schrieb: > Lachsack schrieb: >> Das verstehe ich jetzt nicht. >> Ich will ja nicht dauernd auf den Kanal blasen. Ich übertrage vlt. max >> alle 10 Minuten die Temperatur, Windgeschwindigkeit ggf. öfters, aber >> vlt. auch nur den Maximalwert der letzten Messperiode. > > Das verstehe ich jetzt nicht. > Warum willst Du Bytes sparen, wenn Du sowieso Zeit wie blöd hast? > Oder ist das nur eine theoretische Überlegung ohne praktischen Nährwert? Effizienz, zugegebenermaßen ohne große Not. Aber man sagt doch (hier?) immer, dass die Luft voll von wild funkenden Dölmern ist. Und wie sagt Mikki Krause? Das muss doch nicht sein :-) Daher möchte ich halt mit wenig Byte viel Information übertragen.
Lachsack schrieb: > Ich hab mir gedacht, > dass man ja als erstes Byte den Wert von -128 bis +127 übertragen kann, > als zweiten die Nachkommastelle (hier brauche ich nicht 0-255 sondern > nur 0-9, also auch wieder Verschwendung irgendwie). "Verschwendung" ist immer relativ. Bei Telegrammen, die alle paar Minuten mit bis zu 300 Kbit gesendet werden, macht das Einsparen einzelner Bits nicht wirklich Sinn. Im Gegenteil, sinnvoll wäre es, das Telegramm gleich mehrmals hintereinander zu senden (z.B. 3x), um Übertragungsfehler erkennen und evtl. gleich eliminieren zu können (in diesen offenen Frequenzbändern nicht unwahrscheinlich). 2 Bytes pro Wert (1. Byte vor Komma incl. Vorzeichen + 2. Byte nach Komma) nennt man dann auch Fixpoint (Q7.8), und damit lässt sich gut rechnen. Um das Protokoll dann noch wasserdicht zu machen, könnte man ein "Startwort" definieren, das z.B. 0xffff heissen könnte.
:
Bearbeitet durch User
Lachsack schrieb: > OK, also das spricht jetzt für ein festes Format ohne interne > Synchronisation. Nö, das tut es garantiert nicht, denn irgendeine Form der Synchronisation ist immer erforderlich. Und bei Funk ist die energiesparendste Form der Synchronisation halt, einfach über einen "längeren" Zeitraum einfach garnix zu senden und so die Pakete zu separieren, also im Endeffekt auch den Empfänger auf die Pakete zu synchronisieren. Des weiteren: der Empfanger muß die Sender unterscheiden können, es muß also in irgendeiner Form eine Senderadresse ausgesandt werden. Das ist teuer und hier kann man leider auch garnix sparen, null Redundanz. Aber: über die Senderadresse kann die Paketstruktur bereits vereinbart sein (shared information=vollkommen redundant). Es ist also nicht nötig, Maßnahmen über die Paketabgrenzung durch Pausen hinaus zu benutzen. In dem Moment, wo der Empfänger nach einer hinreichend langen Phase von Funkstille eine ihm bekannte Adresse empfängt und positiv verifiziert, weiß er auch schon, was da noch kommen sollte und wie genau es zu interpretieren ist. Dafür braucht man also keine Bits (=Senderenergie) zu verschwenden. Lieber dafür, indem man der zentralen Bedeutung der Absender-ID Rechnung trägt und dieser entsprechende Redundunz hinzufügt, die es dem Empfänger ermöglicht, sie zumindest mit hinreichender Sicherheit zu verifizieren. Auch das ist leider recht "teuer", aber unumgänglich. Bei dem eigentlichen Payload hingegen braucht man sich keine großen Gedanken mehr zu machen. Man codiert halt einfach so, dass man je nach Anwendungsfall mit möglichst wenigen Bits auskommt. Kein Problem, da Sender und Empfänger dieses "Geheimnis" ja teilen können, es also nicht über den engen und energiekritischen Funkkanal immer und immer wieder ausgetauscht werden muss. Je nach Wichtigkeit der Information kann man dann natürlich auch noch Redundanz zum Payload hinzufügen, z.B. eine CRC oder was auch immer. Kein Problem, da auch hierzu Sender und Empfänger bereits vor dem Informationsaustausch wissen, was da genau im Paket sein muß. Am Ende macht man daraus ein "Profilkonzept". D.h.: Die Sender entsprechen gewissen Profilen, und dem Empfänger teilt man mit: Mit Adresse sowieso kannst du den Empfang von einem Sender mit diesem und jenen Datenprofil erwarten. Im Prinzip machen es alle neuzeitlichen Funk-Datenprotokolle in ihren Grundzügen in etwa so. Der ganze Rest, etwa, daß ein Sender bei einem discovery auch mal seine Profil-ID selber verbreitet, ist schon reine Komfort-Funktionalität, für die eigentliche Funktion aber nicht zwingend notwendig.
Mark B. schrieb: > Kann der Sensor überhaupt auf Zehntel Grad genau auflösen? Jeder DS18B20 für 60ct schafft das locker. Was spricht dagegen, die 12 Bit, die vom Sensor kommen, auch zu übertragen? Die Übertragung informationsloser Bits (Rauschen) kann man verringern, indem man beim Sensor vor der Übertragung vernünftig mittelt.
Moin, Ich kann nur empfehlen, nicht zu sparen wenn es nicht sein muss. Man kann quetschen wie man will, also z.B. Temperatur in 6 Bit, Wind in 4, Richtung gemittelt in 4 und schon ist alles in 16 Bit. Höher aufgelöst wäre nicht nötig für eine Wetterstation. Allerdings quält man sich dann beim Debuggen wie blöd, das würde ich mir nicht antun. Wir hatten sowas mal gemacht, allerdings mit gutem Grund, nämlich Übertragungsgeschwindigkeit. Alles proprietär nur so aufgelöst wie zwingend erforderlich und div. Werte über viele Bytes verteilt. Die Minute braucht nur 6 Bits, die Stunde nur 5, andere Werte wollten wir als 10 Bit. Natürlich alles binär. Wenn da mal was nicht lief ist man durchgedreht beim Bit-Zählen. Gruß, Norbert
Norbert S. schrieb: > Alles proprietär nur so aufgelöst wie zwingend erforderlich und div. > Werte über viele Bytes verteilt. Die Minute braucht nur 6 Bits, die > Stunde nur 5, andere Werte wollten wir als 10 Bit. Andere erheben soetwas zum weltweit verbindlichen Standard. Guck dir an, wie im Seefunk die AIS-Daten gepackt werden.
Norbert S. schrieb: > Wenn da mal was nicht lief ist man durchgedreht beim Bit-Zählen. LOL. Schon mal mit PC probiert ? Wolfgang schrieb: > Andere erheben soetwas zum weltweit verbindlichen Standard. Guck dir an, > wie im Seefunk die AIS-Daten gepackt werden. Warum ? c-hater schrieb: > Bei dem eigentlichen Payload hingegen braucht man sich keine großen > Gedanken mehr zu machen. Man codiert halt einfach so, dass man je nach > Anwendungsfall mit möglichst wenigen Bits auskommt. Kein Problem, da > Sender und Empfänger dieses "Geheimnis" ja teilen können, Genau. Wenn es meine WS ist, codiere ich so, dass es mit so wenig bits wie nur irgendwie möglich auskommt, aber nur wenn das auch notwendig ist. Datum und Zeitstempel eben beim Empfänger. Da ich nicht in Sibirien lebe, werden Temperaturen unter -21 nicht gebraucht. Und da ich auch nicht in Afrika lebe, werden Temperaturen über 42 auch nicht gebraucht, ergibt 8 bit mit 0,25C Auflösung. Windgeschwindigkeit passt locker in 8 bit. Luftfeuchtigkeit draussen ist ziemlich unwichtig, Auflösung von 1% oder 2% reicht vollkommen, ergibt 5-6 bit. Die restlichen 2-3 bit werden für die Windrichtung genommen. Regenmenge ist auch 8 bit. Insgesamt 4 Byt für alles. Aber selbst mit 6 Byt binär oder 30 Byt für ASCII Nachrichten ist es überhaupt nicht schlimm. GPS sendet mit 9600 Baud und ASCII mindestens einmal pro Sekunde und für die meisten ist das vollkommen ausreichend. Du sendest einmal alle 10 Minuten...
:
Bearbeitet durch User
Hallo, Frosti schrieb: > Michael U. schrieb: > >> Eine CR2032 lebt selbst im Gefrierfach des Kühlschranks ca. 9 Monate >> trotz (unnötig häufiger) Übertragung alle Minute. > > Es würde mich interessieren, wie Du da das Gehäuse gemacht hast. Vor > allem, wie Du es wasserdicht gemacht hast. Magst Du das mal mit ein paar > Fotos und Sätzen dazu in Projekte einstellen? Das wäre nett. es gibt eine alte Webseite von mir dazu: http://www.avr.roehres-home.de/sensoren/index.html aaber... Die Gefrierfachgeschichte war als Test für tiefe Temperaturen gedacht, Gehäuse ist irgendein fernbediengehäse von Segor. Sensor der interne des Tiny (entsprechend ungenau). Alles frei verdrahtet und dann mit Plastikspray eingesprüht, die 17cm Drahtantenne fragwürdig "reingewickelt". Die beiden Tastenlöscher nur mit Tesafilm "abgedichtet". Entgegen den Erwartungen lief es eben einfach. Batteriewechsel ist jedesmal eine Strafe, ich habe es aber immer weider reingelegt... Mittlerweile seit 7 Jahren! Beim nächsten Batteriewechsel (müßte bald fällig sein) mache ich mal Bilder davon. Mittlerweile hängt eine 433MHz-WLAN-Bridge mit einem ESP8266 dazwischen, da geht es mit MQTT zu FHEM weiter. Anzeige ist ein 7" Tablett geworden, im Web auch zu finden: http://www.roehres-home.de/fhem/fhem.png Gruß aus Berlin Michael
Marc V. schrieb: > Warum ? Weil bei diesem Standard für die Übertragung Zeitschlitze mit fester Länge verwendet werden und unter Nutzung der damit zur Verfügung stehenden Blockgröße möglichst viel Information (und nicht irgendwelche redundanten oder leeren Bits) übertragen werden sollen.
Wolfgang schrieb: > Marc V. schrieb: >> Warum ? > > Weil bei diesem Standard für die Übertragung Zeitschlitze mit fester > Länge verwendet werden und unter Nutzung der damit zur Verfügung > stehenden Blockgröße möglichst viel Information (und nicht irgendwelche > redundanten oder leeren Bits) übertragen werden sollen. Nein, was ich meinte war: Warum soll der Sensor Zeit und Datum überhaupt senden ?
> Da möchte ich aber nicht -9.8 übertragen (hatten wir letzte Nacht) (das > wären ja 4 Bytes) sondern etwas platzsparenderes. Warum Platzsparend? Auf Anhieb fällt mir da nur die 42 ein.
Marc V. schrieb: > Warum soll der Sensor Zeit und Datum überhaupt senden ? Wer sagt, dass unbedingt Zeitstempel gesendet werden sollen? Das ist nur nötig, wenn die Laufzeit der Datenübertragung variiert und gegenüber dem zulässigen Abtastjitter nicht vernachlässigt werden kann.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.