Hallo, ich bin an meinem Projekt Arduino-Windmesser TX23 Auswerten an meine Verständnisgrenzen geraten. Das Problem ist nicht die Funktion sondern das Verstehen BIN Decimal Print.
Hab die Frage schon in dem Forum gestellt wo der Code her ist, nur werd ich da bestimmt keine Antwort bekommen wenn ich mir die Datums der Post ansehe.
mein Problem, die Werte für Richtung und Windgeschwindigkeit kommen im BIN Format vom Windmesser.
ein
Serial.println(dataword1, BIN);
Serial.println(dataword1);
gibt folgendes aus
zeigt
1001010000
592
so, eigentlich sollte da doch als dec Wert da 41 stehen? was ich auch am Win Taschenrechner so ablesen kann.
aber andere Converter sagen wieder 592.
in oben genannten 2.Link, da sind ja 4 Beispiele der Windgeschwindigkeit, geht alles im Taschenrechner von Win nachzuvollziehen, nur wieso wird aus dem BIN bei mir und im Inet 592?
Ich verstehe nicht ganz, wo genau am Win-Taschenrechner du für 41 deine von dir oben genannten 1001010000 abliest....
Die 1001010000 sind wirklich 592
41 wäre binär 101001
Also wenn man deine binäre Zahl umdreht (0000101001) dann gibt das 41
void loop() {
int dataword = 0; // Prepare data word
stat = digitalRead(senspin); // get the sensor input
while(stat == HIGH){ // wait for falling edge (sync to startbit)
stat = digitalRead(senspin);
}
delayMicroseconds(half_bit_ms); //wait for MIDDLE of startbit, we are now in sync
// Skip the start bit, we now it ist there ;-)
delayMicroseconds(bit_ms);
// Skip four header bits, we don´t want these...
delayMicroseconds(bit_ms);
delayMicroseconds(bit_ms);
delayMicroseconds(bit_ms);
delayMicroseconds(bit_ms);
// Now the 13 bits we want...
// *** Dataword [0..3] = WIND DIRECTION (LSB first)
// *** Dataword [4..12] = WIND SPEED (LSB first)
for (int i=0; i <= 13; i++){
stat = digitalRead(senspin);
if (stat) {
dataword = dataword + (1 << i);
}
delayMicroseconds(bit_ms); // Wait for next bit
}
Serial.println(dataword, HEX); // Print out Dataword as readable ASCII string to PC
digitalWrite(ledpin, HIGH); // Sensor Data Indicaror LED on
delay(200); // Spens some time, to make sure finished tranmittion
digitalWrite(ledpin, LOW); // Sensor Data Indicaror LED on
}
hat er die kleine Unschönheit, dass er 14 statt 13 Bit liest. Aber das scheint hier nicht dein Problem zu sein.
Eigentlich sollten nach 9 Datenbit noch 4 mal 0 kommen: 0x250 wäre also gar nicht möglich.
ich kann mit der 1000101011 irgendwas nix anfangen, muss es wandeln/konvertieren was auch immer.
zitat aus einer anderen Anleitung, evtl hilft es bei der "ich stell mich blöd an" Lösung
F – Wind Speed
The wind speed is a 12 bit value. It requires it’s endianness to be reversed.
I’m unsure of the exact units, but it appears to be a factory calibrated value in units of 0.1 metre/sec. The 3 MSB’s are always 000, so only 9 bits are used. With a max value of 511, this relates to 51.1 metres per second, or 183.96 km/h (114.31 miles per hour).
From the example image above, the wind speed is read as 101010100000, then endianness reversed to 000001010101, which is decimal 85, or 8.5 metres per second.
Die Lösung steht, wenn ich nicht irre, in Deinem Text: "WIND DIRECTION (LSB first)" und "WIND SPEED (LSB first)". Und "the wind speed is read as 101010100000, then endianness reversed to 000001010101".
Du mußt also tatsächlich 1001010000 in der Reihenfolge umdrehen zu 0000101001, was die 41 ergibt.
Ein Testprogramm zur Veranschaulichung:
uint16_t dataword = 0, w = 0b100101000; // 000101001
void setup() {
Serial.begin(9600);
Serial.println(w, BIN);
for (int i = 0; i < 9; i++) {
bool stat = w & 1;
if (stat) {
dataword = dataword | (0b100000000 >> i); // Hier kann man die Richtung umdrehen
}
w = w >> 1;
}
Serial.print(dataword, BIN);
Serial.print("\t");
Serial.println(dataword, DEC);
}
void loop() {
}
EDIT 2.10.16 11:00 Uhr: Programm auf die relevanten 9 Bit verändert.
einfach, ob die höherwertigen bits zuerst kommen oder die niederwerigen.
bei einer dezimalzahl würde es bedeuten, daß bei der zahl 1536 entweder erst 1, dann 5, dann 3 und dann die 6 kommt, oder umgekehrte reihenfolge, also 6 - 3 - 5 - 1. mal braucht man's so, mal andersrum.
OK, Danke, ich versteh es so halb in der Theorie um was es geht.
Mein Problem dabei ist, das Teil steht schon eingebaut vor Ort, mitten auf einem Feld ohne Strom ohne alles, 20KM von mir entfernt. Ich kann also zuhause keine Tests machen bezüglich Änderungen. Vor Ort, auf dem Feld hab ich 1Stunde Akku Laptop zum rumspielen und ändern.
Ich gebe zu, ich kann die Code Schnippsel nicht interpretieren, ich schreib die mal so in mein Scetch.
Der Idealfall für mich wäre, ich hab ein CodeSchnippsel Alt und eins neu vereint in einem.
Ich weiß ja das mein aktueller Ausleseprozess funktioniert, nur eben die Werte/der Inhalt von dataword1 gespiegelt werden muss.
Daher wäre es von Vorteil für mich eine "Print" Ausgabe zu haben mit meinem org. dataword1 und eine mit newdataword1, um zu vergleichen ob wirklich richtig gespiegelt wurde.
Oder kann man nicht mein Auslesen so lassen und das nach dem Auslesen erst spiegeln?
Das ich alles was das auslesen angeht so lasse, weil ich weis es stimmt soweit, und dann 2 vars hab eine dataword1 und eine newdataword die gespeigelt ist?
Ich stell ja euer können nicht in Frage aber ich hab ja so keinen Vergleich zu vorher. Wenn dummerweise "in der Mitte" 2 falsch getauscht werden, kommt ja DEC wieder was anderes raus, ODER ist das unmöglich?
for (int i=0; i <13; i++){
stat = digitalRead(senspin);
if (stat) {
if (i <= 3) {
dataword = dataword + (1 << i);
} else {
dataword1 = dataword1 + (1 << i);
}
}
//jetzt reverse
uint16_t revdataword = 0, w = dataword1; // 000101001
for (int i = 0; i < 9; i++) {
bool stat = w & 1;
if (stat) {
revdataword = revdataword | (0b100000000 >> i); // Hier kann man die Richtung umdrehen
}
w = w >> 1;
}
Serial.println(dataword1, BIN); // orginal Ausgelesen
Serial.println(revdataword, BIN);//reverse
kollimann:
Vor Ort, auf dem Feld hab ich 1Stunde Akku Laptop zum rumspielen und ändern.
Wenn Du da häufiger bist, wäre hier ein Ansatzpunkt für Verbesserungen. Mein Laptop hält länger, habe ich gerade beim Camping probiert. Sonst eben Stromaggregat, Autobatterie, Sonnensegel ...
Was sagt denn Dein Compiler dazu, denn im trauten Heim kannst Du auch ohne Arduino compilieren:
bool stat = w & 1;
kollimann:
Ich stell ja euer können nicht in Frage aber ich hab ja so keinen Vergleich zu vorher. Wenn dummerweise "in der Mitte" 2 falsch getauscht werden, kommt ja DEC wieder was anderes raus, ODER ist das unmöglich?
Ich weiß, was ich kann, daher weiß ich auch, was ich nicht kann, da kannst Du mich nicht aus der Ruhe bringen, sei unbesorgt. Irrtümer gibt es bei mir inklusive. Aber danke für die Empathie
Unmöglich ist überhaupt nichts, daher stimme ich Dir vollkommen zu, alle Zwischenschritte möglichst zu dokumentieren, also ausgeben zu lassen. So bekommst Du auch ein Gefühl für das, was da passiert. Das mache ich nicht anders
Wenn alles wunschgemäß funktioniert, speichere diese Version Deines Programms und beginne mit den Optimierungen.
