Forum: Mikrocontroller und Digitale Elektronik Viel Information mit wenig Bytes übertragen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Lachsack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ui (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Kichererbse (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lachsack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lachsack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Erwin D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Meister E. (edson)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lachsack (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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...

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Dietrich L. (dietrichl)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Michael U. (amiga)


Bewertung
1 lesenswert
nicht lesenswert
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

von Frank K. (fchk)


Bewertung
1 lesenswert
nicht lesenswert
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

von Frosti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lachsack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joe F. (easylife)


Bewertung
0 lesenswert
nicht lesenswert
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
von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Norbert S. (norberts)


Bewertung
0 lesenswert
nicht lesenswert
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

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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
von Michael U. (amiga)


Bewertung
0 lesenswert
nicht lesenswert
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

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Ratloser Schulterzucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.