mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wahrscheinlichkeit für Bitmuster?


Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend!

Ich habe folgendes Problem und hoffe, dass mir dabei vllt jemand helfen 
kann!?

Also ich sende Daten per Funk in einem Datenpaket. Dabei besitzt das 
Paket eine Magic Number zur Identifizierung mit dem Bitmuster 
BA:AD:FO:OD also
10111010101011011111000000001101. Meine Frage ist nun, mit welcher 
Wahrscheinlichkeit dieses Bitmuster im Datenpaket vorkommen kann?
Der Header beträgt eine Gesamtlänge von 10 Byte und das Datenelement 
besitzt eine Größe von 28 Byte. Ich hoffe ihr könnt mir das vllt mit 
einer Beispielrechnung verständlich erklären ;)

Vielen Dank!
Torsten

Autor: Thomas S. (tsalzer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du das so sendest, sollte die Wahrscheinlichkeit doch möglichst 1 
sein.

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie meinst du das?

Autor: Einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ca. 1/1000000000

Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nun, du sagst, dass du diese Magic Number sendest. Also wird sie doch 
mit Wahrscheinlichkeit 1 = 100% auch im Datenpaket enthalten sein.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
42.

Die Daten in deinem Datenpaket sind vermutlich nicht zufällig, deswegen 
kann hier auch niemand eine seriöse Antwort geben.

Autor: Samuel C. (dragonsam)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1/2^32

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, die Frage war eigentlich folgende.
Die Magic Number dient im header zur identifizierung des Headeranfangs 
(Datenpakets). Nun kann es ja sein, dass Nutzdaten gesendet werden mit 
gleichem Bitmuster. Sollte dies vorkommen, könnte es zu Fehlern in der 
Datenübertragung kommen, da der Empfänger statt Daten ein neues 
Datenpaket erwartet. Gesucht ist also die Wahrscheinlichkeit, dass 
soetwas vorkommt und dies sollte eigentlich sehr gering sein und nicht 
100%!
Ich hoffe, ich konnte es jetzt nochmal verstädnlicher machen...
Danke!

Autor: hdd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die Daten zufällig sind, dann ist meiner Meinung nach die 
Wahrscheinlichkeit für das Auftreten des Headers (10 Bit) im Datenpaket 
(28 Bit)
Weil ja das vorgegebene 10-Bit-Muster an 18 verschiedenen Stellen des 
Datenpakets anfangen kann. Kann mich aber auch täuschen, Stochastik ist 
schon etwas her.

Verrate doch mal, um was für Daten es sich handelt, diese werden ja 
eventuell nicht zufällig sein.
Du könntest auch beim Sender erst prüfen, ob dein Header in den Daten 
enthalten ist und das dann quasi maskieren, z.B. über zwei 
zusammenhängende Pakete.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke das war den Leuten hier schon klar. Wir wissen aber nichts 
über die daten die gesendet werden sollen, wie soll man das eine 
Wahrscheinlichkeit ableiten.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

das hatte ich mir schon gedacht. Nur ohne etwas über die Nutzdaten zu 
wissen, kann man darüber halt keine Aussage machen. Es handelt sich ja 
wahrscheinlich um irgendwelche sinnvollen Daten, da sind die Werte 
0x00-0xff in der Regel nicht gleich verteilt und es gibt Korrelationen. 
Wenn das erste Byte X war, könnte als nächster Wert Y häufiger vorkommen 
als Z. Und auch für das dritte Byte sind dann in der Regel auch nicht 
alle Werte gleich wahrscheinlich usw.

Nur wenn man diese Informationen hat, könnte man überhaupt etwas 
ausrechnen. Alles andere ist Kristallkugel.

Gruß, DetlevT

Autor: Klaus 2m5 (klaus2m5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Murphy spielt das alles aber nicht wirklich eine Rolle. Nach Murphy 
ist die Wahrscheinlichkeit 100%, dass etwas schiefgeht, wenn es 
schiefgehen kann.

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Daten die gesendet werden sind letzenendes folgende.
Gewicht in g (uint32), Tara in g (uint32) und ticks (long). mehr wird 
nicht gesendet. Das Gewicht ist dabei zufällig oder besser gesagt 
variabel!

@ hdd
das sieht vielversprechend aus. Sowas habe ich mir vorgestellt! =) Wenn 
das jetzt noch richtig zu sein scheint, und ich glaube das ist es, dann 
vielen Dank!

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achja, so ein paket sieht folgendermaßen aus:
 ___________________
|Header | Datenelement|

Das Datenpaket ist somit 28 + 10 = 32 byte groß.

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schick den Header und die Daten und häng noch eine Prüfsumme an. Der 
Empfänger kann den Header prüfen und die Checksumme. Wenn beides passt 
kannst du die Daten auf plausibilität überprüfen.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten schrieb:
> Die Daten die gesendet werden sind letzenendes folgende.
> Gewicht in g (uint32), Tara in g (uint32) und ticks (long). mehr wird
> nicht gesendet. Das Gewicht ist dabei zufällig oder besser gesagt
> variabel!

Du verstehst es nicht. Du redest von insgesamt 38 Bytes, gibst hier aber 
nur 12 an. Was ist mit dem Rest? Kristallkugel?

Außerdem glaube ich nicht, dass alle Gewichte zwischen 1g und ~4300 
Tonnen mit der gleichen Wahrscheinlichkeit vorkommen. Was für eine Waage 
soll das denn sein?

Und was sind die "ticks"?

Gehen wir einmal davon aus, dass alle anderen Bytes 0x00 sind. Gehen wir 
weiter davon aus, dass diese Wage maximal mittelgroße Lastwagen bis 16 
Tonnen (2^24) wiegt und das Tara auch nicht größer ist, dann kann das 
Bitmuster nur noch durch die "Ticks" erzeugt werden.

Da musst du dir halt nur noch überlegen, ob dieser Wert dort vorkommen 
kann und wenn ja, wann.

Gruß, DetlevT

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hdd:
Diese Lösung wollte ich auch erst schreiben, aber Vorsicht die 
Wahrscheinlichkeit die Du ausrechnest ist nur eine obere Grenze, denn es 
kann passieren, dass der Header genau zweimal vorkommt, dann wurde er 
aber schon mitgezählt, diese Fälle müßtest Du abziehen. Ein einfaches 
Beispiel:

In der 4 Bitfolge soll die Wahrscheinlichkeit berechnet werden, dass die 
Bitfolge 10 auftaucht:

 1 0000
 2 0001
 3 0010   x
 4 0011
 5 0100   x
 6 0101   x
 7 0110   x
 8 0111
 9 1000   x
10 1001   x
11 1010   x (!)
12 1011   x
13 1100   x
14 1101   x
15 1110   x
16 1111

Die Folge 10 kommt 11 (!) mal vor (wegen Bitfolge 11), macht 11/16 = 
0.6875 = 68.75%.

Die Folge 10 kann an 3 Positionen (1,2,3, 4 geht nicht da kein Platz 
mehr) anfangen, d.h. jeweils 2 weitere Bits sind frei wählbar, das 
macht: 3*(2^2) Möglichkeiten, insgesammt gibt es 2^4 (da Bitfolge der 
Länge 4), das macht dann 12/16 = 75%. Also gibt dieses Vorgehen nur eine 
obere Schranke an...
Aber vielleicht reicht das ja schon. Wenn ich mehr Zeit habe, dann 
versuche ich mal eine bessere Lösung anzugeben.

Viele Grüße
Stephan

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erratum: Der Wert ist 0x0DF0ADBA (Little Endian vorausgesetzt) 
entspricht über 200 Tonnen. Man kann also Lastwagen und kleinere Schiffe 
damit wiegen ohne dieses Bitmuster zu erzeugen.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Lösung für solche Probleme ist Bit Stuffing. Ein Beispiel dafür 
findet sich bei HDLC.

Bei HDLC fängt ein Frame immer mit der Bitfolge 01111110 an (und hört 
mit derselben Folge auf). Um zu verhindern, dass diese Sequenz mitten im 
Paket auftreten kann, wird jeweils nach 5 Eins-Bits eine 0 in den 
Bitstrom eingefügt, und auf Empfängerseite wird eine 0 nach 5 Eins-Bits 
verworfen.

Angenommen es wäre ein Paket mit genau einem einzelnen der Sync-Sequenz 
entsprechenden Octet (0b01111110 = 0x7e) zu übertragen, dann sieht der 
Bitstrom auf der Leitung dann so aus:
 0 1 1 1 1 1 1 0   0 1 1 1 1 1 0 1 0   0 1 1 1 1 1 1 0
 Frameanfang       Daten       ^       Frameende
                               |
                  hier ist das eingefügte Bit

Beachte, dass das Zusatzbit nach jeder Folge von 5 Eins-Bits eingefügt 
werden muss, da der Empfänger eine folgende 0 sonst fälschlicherweise 
verwerfen würde. "0xff 0xff" würde also so gesendet:
 0 1 1 1 1 1 1 0   1 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 1 0 1   0 1 1 1 1 1 1 0
 Frameanfang       Daten     ^           ^           ^     Frameende
                             |           |           |
                             +--- eingefügte Bits ---+

Im Extremfall führt das natürlich dazu, dass bis zu 20% mehr Bits 
übertragen werden müssen.

Übertragen auf deine eigene Sync-Sequenz könntest du z.B. eine 0 
einfügen, wenn eine Bitfolge gesendet wurde, die bis zur letzten 0 (dem 
vorletzten Bit) mit deiner Sync-Sequenz übereinstimmt.

Andreas

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobi schrieb:
> Schick den Header und die Daten und häng noch eine Prüfsumme an. Der
> Empfänger kann den Header prüfen und die Checksumme. Wenn beides passt
> kannst du die Daten auf plausibilität überprüfen.

Das ist keine Lösung des Problems!

Zwar würde man damit erkennen, wenn ein Paket durch sein Bitmuster zu 
einem Verlust der Synchronisation der Paketgrenzen führt. Der Preis wäre 
aber, dass man dann etwas geschaffen hätte, was sich "Deterministic 
Packet Loss" nennt, das heisst Pakete mit bestimmten Daten drin gehen 
immer während der Übertragung verloren.

Ein solches Verhalten ist für Protokolle, die die Auslieferung der Daten 
sicherstellen sollen (z.B. TCP) mit Abstand der "ekligste" Fall 
überhaupt. Mir ist kein Protokoll bekannt, das diesen Fall abdecken 
würde (bei TCP bleibt z.B. in soeinem Fall die Verbindung einfach 
"hängen", und bricht irgendwann nach einem Timeout ab).

Andreas

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 28 + 10 = 32 ...

Werd' das nachher noch einmal nachrechnen.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Ein solches Verhalten ist für Protokolle, die die Auslieferung der Daten
> sicherstellen sollen (z.B. TCP) mit Abstand der "ekligste" Fall
> überhaupt.

Noch kleine Ergänzung, warum das so eklig ist: Deterministic Packet 
Loss ist eigentlich der einzige Fall von Paketverlust (ausser einer 
dauerhaft unterbrochenen Verbindung, aber da hilft eh überhaupt nichts 
mehr), der sich nicht durch Retransmit der verlorenen Pakete lösen 
lässt. Beim erneuten Senden enthält das Paket wieder die gleichen Daten, 
und geht deshalb dann auch verloren.

Auch Routing-Protokolle, die bei unterbrochenen Verbindungen nach 
kurzer Zeit für eine Umleitung auf funktionierende Verbindungen führen 
(wie es z.B. im Internet gemacht wird) helfen hier nicht weiter, da die 
Verbindung eben nicht unterbrochen ist.

Andreas

Autor: Der Schelm (derschelm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähnlich zum oben beschriebenen Bitstuffing funktioniert auch die 
DLE-Verdoppelung. Solche Daten wie z.B. Deine Magic-Number beginnen 
immer mit einem DLE (0x10; und dann sind es zusammen 2 Bytes). Sollte 
einmal eine 0x10 in Datenstrom vorkommen, was so alle 256 gesendete 
Bytes sein sollte (statistisch und gleichverteilt), dann wird das DLE 
einfach verdoppelt. Beim Empfänger entsprechend rückwärts. Dieses 
Verfahren ist gefühlte 100 Jahre alt aber Byte-orientiert und damit wohl 
etwas leichter zu handeln als Bitstuffing. Google mal ein wenig.

Schönen Äbend noch!

Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal so eine ganz blöde Frage:
Warum wird nicht einfach definiert in welchem Zusammenhang und/oder an 
welcher Stelle die Magic Number auftauchen darf? So arbeiten andere 
Protokolle doch auch, es wird genau definiert was in welchen Bits steht 
und welche Werte dort zulässig sind. Wenn ich nun also definiere dass 
die Bytes 6 bis 9 des Headers die Magic Number enthalten dann kann ich 
mein Programm entsprechend anpassen dass es nur reagieren soll, wenn an 
dieser Stelle das entsprechende Bitmuster auftaucht. Zumindest versteh 
ich grad nicht wo das Problem an einer solchen Vorgehensweise ist.

Autor: gonzo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel H. schrieb:
> Warum wird nicht einfach definiert in welchem Zusammenhang und/oder an
> welcher Stelle die Magic Number auftauchen darf? So arbeiten andere

Ist natürlich blöd wenn dann aus Zufall an dieser Stelle das Bitmuster 
steht obwohls nicht das richtige Paket ist.
Zur Problem lösung wäre wohl Bitstuffing ein guter weg.

Und zur eigentlichen Frage, unter der Annahme das alle Werte gleich 
Wahrscheinlich sind könnte man das Wohl mit dem Urnenmodell lösen. Die 
Frage ist nur, was es dir bringt wenn du weisst das es schiefgehn kann.

Schönen Abend noch.

Autor: (nicht "Gast") (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel H. schrieb:
> Mal so eine ganz blöde Frage:
> Warum wird nicht einfach definiert in welchem Zusammenhang und/oder an
> welcher Stelle die Magic Number auftauchen darf?

Es handelt sich hier um Funk. Wenn keine Daten gesendet werden bekommt 
man nur Müll, vor allem wenn der Empfänger eine AGC hat.

Ich würde eine Checksumme am Ende empfehlen. Wenn das Startmuster 
gefunden wurde wird die entsprechende Anzahl Bytes empfangen und mit der 
Summe verglichen.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Schelm schrieb:
> Ähnlich zum oben beschriebenen Bitstuffing funktioniert auch die
> DLE-Verdoppelung. Solche Daten wie z.B. Deine Magic-Number beginnen
> immer mit einem DLE (0x10; und dann sind es zusammen 2 Bytes). Sollte
> einmal eine 0x10 in Datenstrom vorkommen, was so alle 256 gesendete
> Bytes sein sollte (statistisch und gleichverteilt), dann wird das DLE
> einfach verdoppelt.

Das reicht nicht. Auf der (fast) untersten Ebene (dem nackten Bitstrom) 
weiss der Empfänger nicht einmal, an welchen Stellen die Grenzen 
zwischen den Bytes liegen. Deshalb darf das Bitmuster der 
Frame-Syncsequenz nirgendwo sonst im Datenstrom auftauchen, auch nicht 
als Kombination von Bits zweier aufeinanderfolgender Bytes, und deshalb 
reicht ein Escaping auf Byte-Ebene nicht aus.

(nicht "Gast") schrieb:
> Ich würde eine Checksumme am Ende empfehlen. Wenn das Startmuster
> gefunden wurde wird die entsprechende Anzahl Bytes empfangen und mit der
> Summe verglichen.

Das würde einen Resync dauerhaft verhindern (oder zumindest unnötig 
verzögern), wenn zufällig mal ein Bit verloren geht und kurz danach die 
Syncsequenz in den Nutzdaten auftaucht.

Solche "Lösungen" sind Käse, da sie in bestimmten Situationen (die sich 
vorhersehen lassen!) ohne sichtbaren Grund einfach mal versagen. Auch 
wenn diese Situationen nur selten auftreten mögen, irgendwann wird der 
Tag kommen. Um auf einem nackten Bitstrom Framing sauber hinzubekommen 
darf die Syncsequenz einfach nicht in den Nutzdaten auftauchen. Wie man 
das erreichen kann habe ich oben ja schon erklärt.

Wem das zu aufwendig erscheint: wenn man sowieso auf Bitebene 
"rumfummelt" (um die Syncsequenz zu erkennen), dann ist die 
Implementierung von Bit Stuffing trivial.

Andreas

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Magic wird am Anfang deiner Pakete gesendet damit diese beim 
Empfänger erkennt werden können. Dh. wird dieses Magic nicht erkannt so 
wird das Paket nicht ausgewertet. Ergo: BA:AD:FO:OD = ein 32 Bit Muster 
aus 2^32 möglichen Bitmustern = 1/2^32 Wahrscheinlichkeit. Was danach 
kommt und wie lang das Paket ist spielt keine Rolle.
Entscheidend ist aber nicht diese Wahrscheinlichkeit sondern die 
Bitfehler-Wahrscheinlichkeiten die dazu führen könnten das aus einem 
nicht-Magic ein Magic-Code wird. Und das hängt von der 
Empfängercharakteristik/Hardware, Übertragungs/Modulationsart und den 
Störungen in der Kommunikation ab.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:

>> Ich würde eine Checksumme am Ende empfehlen. Wenn das Startmuster
>> gefunden wurde wird die entsprechende Anzahl Bytes empfangen und mit der
>> Summe verglichen.

>Das würde einen Resync dauerhaft verhindern (oder zumindest unnötig
>verzögern), wenn zufällig mal ein Bit verloren geht und kurz danach die
>Syncsequenz in den Nutzdaten auftaucht.

>Solche "Lösungen" sind Käse...

Nö, nicht Käse. Die CRC gibt nur die Erkenntnis das die vorher 
empfangenen Daten mit der Fehlerwahrscheinlichkeit der CRC eben korrekte 
Daten sind. Die CRC hat mit dem Resync, der Synchronisation oder dem 
Magiccode garnichts zu tun. Man kann auch Bitweise alle Daten fließend 
auswerten und darüber nach jedem Bit die CRC berechnen. Das würde dann 
genauso schnell einen Resync erzwingen wie du in deinem Posting 
beschrieben hast. Ergo: die CRC hat mit dem Resync und dessen 
Fehler/Problemen nichts zu tun.

Gruß Hagen

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Wahrscheinlichkeit ein 80bit muster per Zufall zu treffen ist doch 
1/(2^80), etwa 1.2e24, wenn wir nun noch 10^3 bit daran vorbeiziehen, 
erniedrigt sich die Chance auf 1.2e21. Nein ?

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> Nö, nicht Käse.

Doch. Was ist wenn ein Bit im Datenstrom fehlt, also nicht den 
falschen Wert hat sondern wirklich weg ist? Was ist wenn ein Bit in 
der Längenangabe von 0 nach 1 wechselt? Das sind beides Fälle, wo dann 
durch einen Einzelbitfehler zwei oder mehr vollständige Datenpakete 
verloren gehen, da du dann in den nächsten Frameanfang hineinliest. 
Deshalb ist das so wie von "(nicht "Gast")" beschrieben in vielen Fällen 
Käse.

BTW, es gibt "CRC based framing", das wird unter anderem von ATM 
verwendet, ist aber nur bei festen Framelängen (wie z.B. ATM-Zellen) 
gut geeignet, bei variabler Länge wird der (Speicher-)Aufwand sehr hoch, 
so dass man das de fakto nur nimmt, wenn der Overhead beim Bit Stuffing 
für die jeweilige Anwendung zu gross oder zu variabel (da datenabhängig) 
würde.

http://en.wikipedia.org/wiki/CRC-based_framing

Andreas

Autor: (nicht "Gast") (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Doch. Was ist wenn ein Bit im Datenstrom fehlt, also nicht den
> falschen Wert hat sondern wirklich weg ist?

Wie kann denn bitte ein Bit verschwinden? Wenn der Sender glaubt er 
müsse mal eben ein bit auslassen, dann geht doch beim Sender was schief. 
Wenn x Bit gesendet werden sollen dann dauert das auch immer x 
Bitzeiten. Da kann kein bit fehlen, außer der Sender und Empfänger 
bewegen sich auseinander.

Außerdem implementiert man eine CRC auch nicht in der Bit Ebene. Mir ist 
schon klar das eine CRC nicht beim Synchronisieren hilft. Aber wenn mal 
ein Frame kaputt ist sollte man es lieber wegschmeißen.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

die Frage von Torsten war, wie groß die Wahrscheinlichkeit ist, dass 
diese "Magic Number" im Datenstrom auftaucht. Ihr diskutiert hier 
Verbesserungen auf Senderseite ohne überhaupt zu wissen, ob man daran 
überhaupt etwas ändern kann. Vielleicht ist das ein fertiges Gerät zu 
dem ein neuer Empfänger gebaut werden soll, schon einmal daran gedacht?

Die naheliegende Frage kam dabei trotzdem nicht zur Sprache: Wurde als 
"Magic Number" überhaupt ein Wert gewählt, der im normalen Datenstrom 
vorkommen kann? Und wenn ja: warum? Woher kommt diese spezielle 
Kombination überhaupt? Möglicherweise wurde diese Kombination ja gerade 
deshalb gewählt, weil sie in dem restlichen Strom eben nicht vorkommen 
kann.

Nehmen wir an, das ist eine Waage, die bis maximal 100 kg wiegt. (Leider 
macht Torsten dazu keine Angaben, so dass wir in unsere Kristallkugel 
gucken müssen) Das wären eine Folge von maximal 17 Bits, die 
grundsätzlich von 0 verschieden sein können. Es gibt 15 weitere Bits in 
Folge, die 0 sind. Damit kann man die "Magic Number" nicht verwechseln.

Es könnte natürlich auch sein, dass die Daten Byte-weise übertragen 
werden, little Endian mit MSB first. Leider macht Torsten auch dazu 
keine Angaben, so dass wir auch hier auf unsere Kristallkugeln 
angewiesen sind.

Dann würde sich ein anderes Muster ergeben: 16 beliebige Bits, 7 mal 
eine 0, dann eine 1 oder 0, gefolgt von 8-mal einer 0. Auch hier besteht 
keine Verwechslungsgefahr.

Für "Tara" gilt das gleiche, selten ist die Verpackung schwerer als das 
Gut. Bleiben die "Ticks", von denen Torsten nicht angibt, was das ist 
(Kristallkugel!), die restlichen Daten, von denen wir gar nichts wissen 
(Kristallkugel!) und einem Header, zu dem Torsten keinerlei Angaben 
macht (Kristallkugel!)

Ich verstehe nicht, wie ihr hier ernsthaft versuchen könnt, irgendwelche 
quantitativen Aussagen zu machen.

Gruß, DetlevT

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein Artikel von Wiki dazu, der das Beschreibt
(Abschnitt: "Magische Zahlen in der Programmierung"):

http://de.wikipedia.org/wiki/Magische_Zahl_(Informatik)

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sry, ich beschreibe es nochmal genauer:
Gewicht = zwischen 0 und 250kg
Tara = max 400 kg
Ticks = ist sowas wie die Uhrzeit, allerdings als fortlaufende Zahl 
(long)

Der Header ist folgendermaßen aufgebaut:

Magic Number = 4 Byte
HeaderLength = 2 Byte
DataLength   = 2 Byte
Datenelemente= 1 Byte
Revision     = 1 Byte (ob aktuelle Protokollversion genutzt wird)

Ich hoffe, damit ist nun alles klar!?

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(nicht "Gast") schrieb:
> Wie kann denn bitte ein Bit verschwinden? Wenn der Sender glaubt er
> müsse mal eben ein bit auslassen, dann geht doch beim Sender was schief.
> Wenn x Bit gesendet werden sollen dann dauert das auch immer x
> Bitzeiten. Da kann kein bit fehlen, außer der Sender und Empfänger
> bewegen sich auseinander.

Kommt drauf an, wie übertragen wird. Wenn Du mit festen Bitzeiten 
arbeitest, können eigentlich keine Bits verschwinden, sondern höchsten 
falsch ausgewertet werden. Das passiert durch Störungen oder 
Timingproblemen.

Wenn es sich aber um ein asyncrones Protokoll handelt, können Bits durch 
Störungen verschwinden.

Über die Übertragung hat sich hier noch niemand ausgelassen. Wir wissen 
nur, dass es Funk ist - also leicht zu stören.

Das Problem sind hier wohl eher die zufälligen Werte aufgrund des 
erwähnten Grundrauschens. Wie wahrscheinlich ist es, dass in diesem 
Rauschen genau die erforderlichen Magic-Bytes und ggf eine Prüfsumme 
stimmen? Ich würde schätzen, recht gering. Ist nur noch zu klären, ob 
das tollerierbar ist.
Hier werden in diesem Fall falsche Gewichte angezeigt/verrechnet. Das 
kann man wiederum über einen Plausibilitätscheck mit mehreren Messungen 
ausfiltern.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten schrieb:
> Ich hoffe, damit ist nun alles klar!?

Nö.

Lese dir doch einmal die Informationen durch, die du hier preisgegeben 
hast und überlege dir, ob du das zugehörige Bitmuster damit konstruieren 
könntest. Weißt du dann zum Beispiel, ob Daten aus mehreren Bytes in 
Little oder Big Endian übertragen werden? Weißt du, ob von den Bytes das 
niederwertigste Bit (LSB) oder das höchstwertige (MSB) zuerst übertragen 
wird? Kennst du den Wertebereich der "Ticks" - und an welcher Stelle der 
Daten diese zu finden sind?

Ich klinke mich hier aus. Dieses Aus-Der-Nase-Ziehen nervt mich.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.