Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

[labella-baron]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Wenn die Auflösung so zu gering ist, kannst Du ja einfach mehrere Magnete nehmen.

Nützt doch nix, dann wird halt statt 1, 2, 3 z.B. 3, 6, 9 pro Intervall übertragen aber niemals 4, 5, 7, 8 - also gleiche Informationsmenge.

 

[TimB]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Nützt doch nix, dann wird halt statt 1, 2, 3 z.B. 3, 6, 9 pro Intervall übertragen aber niemals 4, 5, 7, 8 - also gleiche Informationsmenge.

Ich gebs auf

Gruß,

Tim

 

[danZR]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

.Die kann ich problemlos auch exakt ausgeben, bin mir aber nicht sicher, was diese überhaupt aussagen, da Linux ja kein Echtzeitbetriebssystem ist, kann man die Werte eigentlich vergessen.

Ich weiss nicht wie der Kern auf dem PI gebaut ist. z.b tickless, mit HRT etc. aber hast du das Programm zumindest mit "chrt" mit SCHED_FIFO oder SCHED_RR laufen lasen ? Meinem Wissen nach sollten da select(), poll() bzw epoll intern aktiv warten (busy wait), was die Latenz verbessert.

 

[Leonardi]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Es muss möglich sein, noch genauere Daten aus dem GSC-10 auszulesen als die timestamp und RPM in der Datei von gyps.
Andernfalls könnte der Edge 705 aus dem GSC-10 auch nicht solche genauen Daten abfragen, von Carbono:



Die mögliche Datenrate besagt zwar noch nichts über die Genauigkeit, aber das pro Sekunde über den ANT Standard 1Mbps*1024/8= 128 Kbyte/s :5 Kbyte = 25 Schreibmaschinenseiten voll Zahlen und Buchstaben hin- und hergeschickt werden können, zeigt die Möglichkeiten auf.

Technische Anfragen sind jedenfalls ausdrücklich erwünscht: http://www.nordicsemi.com/eng/Support/Application-Notes

Gruß Leonardi

 

[TimB]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Es muss möglich sein, noch genauere Daten aus dem GSC-10 auszulesen als die timestamp und RPM in der Datei von gyps.
Andernfalls könnte der Edge 705 aus dem GSC-10 auch nicht solche genauen Daten abfragen, von Carbono:

Wieso? Das sind sekündlich abgespeicherte Werte, also wird da über 4 Werte gemittelt und mit einer krummen Zahl (Reifenumfang) multipliziert. 9 km/h sind beim 20" Rad etwa 100 UPM, macht eine mögliche Abstufung von 2,5 Promille. Dann wird der Edge noch selber eine Mittelung zur Synchronisierung durchführen, die vollends krumme Werte liefert. Aussagekräftig sind die Geschwindigkeiten trotzdem nur im Rahmen von etwa 1 % bei 9 km/h, bei unbekanntem Zeitpunkt durch die ganze Mittelung uind Rechnerei.

Ach ja: Mein Osynce hat mir schon mehr als 80 km/h angezeigt, macht schon 900 UPM. Das Dumme ist halt, daß die Geschwindigkeit nicht in Echtzeit angezeigt und erst recht nicht abgespeichert wird. Mit dem Auslesen der ANT+-Daten kriegt man diese Latenz wenigstens auf 0,25 s runter, ist doch klasse. Und wer weiß, vielleicht lässt sich der eine oder andere Sensor ja auf eine höhere Sendefrequenz einstellen.

Gruß,

Tim

 

[labella-baron]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Es muss möglich sein, noch genauere Daten aus dem GSC-10 auszulesen als die timestamp und RPM in der Datei von gyps.
Andernfalls könnte der Edge 705 aus dem GSC-10 auch nicht solche genauen Daten abfragen, von Carbono:

Anhang anzeigen 55415

1. Betrachtest du bei 15km/h einen unkritischen Bereich, wo nur ca. drei Radumdrehungen pro Sekunde erfolgen (20" vorausgesetzt).
2. Werden selbst diese "Messwerte" errechnete Werte z.B. auf Grund eines gleitenden Durchschnitts über ? Sekunden sein.

Erst wenn innerhalb des Sendeintervalls von 0,25 Sekunden mehr als ein Sensor-Impuls anfällt wird es interessant.
Also bei zwei Impulsen gleich 8 Laufradumdrehungen pro Sekunde = 12m/s = 43km/h. - Und wir benötigen die genauen Messdaten bei Geschwindigkeiten über 43km/h !

 

[Leonardi]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Ich hatte nur das:
<Speed id='49459s' timestamp='1392119754.05' RPM='206.00' />
<Speed id='49459s' timestamp='1392119754.30' RPM='203.00' />
<Speed id='49459s' timestamp='1392119754.55' RPM='202.00' />
<Speed id='49459s' timestamp='1392119755.04' RPM='200.00' />
<Speed id='49459s' timestamp='1392119755.29' RPM='198.00' />
<Speed id='49459s' timestamp='1392119755.54' RPM='196.00' />
<Speed id='49459s' timestamp='1392119755.79' RPM='195.00' />
<Speed id='49459s' timestamp='1392119756.28' RPM='192.00' />
...
<Speed id='49459s' timestamp='1392119842.25' RPM='36.00' />
<Speed id='49459s' timestamp='1392119843.99' RPM='35.00' />
<Speed id='49459s' timestamp='1392119845.72' RPM='34.00' />
<Speed id='49459s' timestamp='1392119847.70' RPM='33.00' />
<Speed id='49459s' timestamp='1392119849.44' RPM='32.00' />
<Speed id='49459s' timestamp='1392119851.42' RPM='31.00' />
<Speed id='49459s' timestamp='1392119853.15' RPM='30.00' />

und das:

...Dann wäre die mögliche Auflösung ja lediglich 1,5m/4 also 0,37m/s oder 1,35km/h...

... Die RPM-Werte sind da vermutlich schon für zuverlässiger, sind allerdings nur Integer und bei rounds per minute wohl nicht genau genug. Genaueres wird man wahrscheinlich per ANT+ leider nicht bekommen...

Dagegen finde ich die von Carbono mit einer Auflösung von ca. 0,2 Km/h erfassten gegenüber den labella-baron berechneten 1,35 Km/h schon genauer. Es ist auch nicht nur die Auflösung sondern auch die Genauigkeit, andernfalls würden die Messwerte von Carbono nicht der Ausroll folgen, sondern zB. zufallsverteilt in einem 1,35 Km/h breiten Streifen liegen.

Ich hatte auch irgendwo eine Messung in Erinnerung, die auf 0,1Km/h genau war wie mein Polartacho, finde sie nur nicht. Es müssen sich also noch mehr Informationen, mehr Genauigkeit rauslesen lassen als das von gyps gezeigte.

Gruß Leonardi

 

[Leonardi]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

1. Betrachtest du bei 15km/h einen unkritischen Bereich, wo nur ca. drei Radumdrehungen pro Sekunde erfolgen (20" vorausgesetzt).
2. Werden selbst diese "Messwerte" errechnete Werte z.B. auf Grund eines gleitenden Durchschnitts über ? Sekunden sein.

Erst wenn innerhalb des Sendeintervalls von 0,25 Sekunden mehr als ein Sensor-Impuls anfällt wird es interessant.
Also bei zwei Impulsen gleich 8 Laufradumdrehungen pro Sekunde = 12m/s = 43km/h. - Und wir benötigen die genauen Messdaten bei Geschwindigkeiten über 43km/h !

War 1. und 2. als Frage zu verstehen ?

Also mit liegt eine Datei "2038.xls" von Carbono mit Ausrollkurve eines Ultremo ZX 20 Zoll-Reifen angefangen bei 60,07 Km/h vor, welche genau so stetig bis zum Stillstand abfällt, war doch sekündliche Erfassung. Auf der Darstellung geht es erst bei 53Km/h runter, weil der erste Teil abgeschnitten wurde.
Es geht sicher auch noch bei höheren Geschwindigkeiten über 60Km/h, da muss nur noch was mechanisch verändert werden, damit es die Bohrmaschine schafft. Also ich sehe nicht, das es Oberhalb von 43 Km/h Probleme gibt.

Ich denke die timestamp lassen sich noch genauer und nicht nur gerundet auslesen.

Gruß Leonardi

 

[TimB]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Dagegen finde ich die von Carbono mit einer Auflösung von ca. 0,2 Km/h erfassten gegenüber den labella-baron berechneten 1,35 Km/h schon genauer.

Das von Labella-baron gerechnete ist ja auch Murks. Schau Dir die Daten mal an, 206 zu 203 UPM macht 18,54 zu 18,27 km/h bei 1.5 m Entfaltung. Und das ließe sich noch dritteln, wenn das Rad nicht so schnell auslaufen würde, Auflösung ist mit diesem Radumfang 0,09 km/h bei 0,25 s Zeitauflösung (die größeren Zeitabstände sind wohl durch verlorene Päckchen verursacht und lassen sich verringern, aber nicht ganz ausschließen).
Die Auflösung berechnet sich übrigens aus (1/60)*3.6*Radumfang, Umrechnung 1 UPM auf 1/s auf 1000/h auf 1000m/h=km/h
Genauer wirds also mit mehr Magneten, weil sich der virtuelle Radumfang verkleinert. Allerdings ist die Zeitauflösung schon der begrenzende Faktor. Die blaue Linie hat am Anfang -0,075 km/h pro 0,25s Steigung, die grüne schon 0,19 km/h pro 0,25s, da ist die zeitliche Unsicherheit schon doppelt so hoch wie die der Geschwindigkeit, selbst wenn der Timestamp genauer ausgelesen wird.

Gruß,

Tim

 

[labella-baron]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

1. Werden selbst diese "Messwerte" errechnete Werte z.B. auf Grund eines gleitenden Durchschnitts über ? Sekunden sein.

Ich hatte nur das:
Dagegen finde ich die von Carbono mit einer Auflösung von ca. 0,2 Km/h erfassten gegenüber den labella-baron berechneten 1,35 Km/h schon genauer.

Es müssen sich also noch mehr Informationen, mehr Genauigkeit rauslesen lassen als das von gyps gezeigte.

Am Prüfstand müsste sich doch bei ca. 4 Umdrehungen pro Sekunde das Laufrad mit einem Handschuh in weniger als einer Sekunde zum Stillstand abbremsen lassen. Was wird denn dann dabei abgespeichert?

 

[Leonardi]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

...Erst wenn innerhalb des Sendeintervalls von 0,25 Sekunden mehr als ein Sensor-Impuls anfällt wird es interessant...

Vielleicht beißt Du Dich zu sehr an den 0,25 s fest, vielleicht stimmt das gar nicht was irgendwo bei so einem Stick im Beilageblatt in engl. gedruckt steht. Haben das die Urentwickler in Oslo geschrieben oder ein unbekannter Chinese ?

Am Prüfstand müsste sich doch bei ca. 4 Umdrehungen pro Sekunde das Laufrad mit einem Handschuh in weniger als einer Sekunde zum Stillstand abbremsen lassen. Was wird denn dann dabei abgespeichert?

Bitte Carbono schreiben und fragen.

Gruß Leonardi

 

[labella-baron]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

War 1. und 2. als Frage zu verstehen ?

Als Feststellung!

Also mit liegt eine Datei "2038.xls" von Carbono mit Ausrollkurve eines Ultremo ZX 20 Zoll-Reifen angefangen bei 60,07 Km/h vor, welche genau so stetig bis zum Stillstand abfällt, war doch sekündliche Erfassung.

Ja, die habe ich auch. So ganz durchschaue ich aber nicht, welche Werte vom Gerät sind - so stammen z.B. die Sekunden aus einer Spalte mit Minuten
Das Problem dieser Geräte ist doch, dass sie die Zahlen im Sekunden-Raster liefern müssen, die Radimpulse aber nicht zu ganzen Sekunden anfallen; also eine irre Rechnerei.

Also ich sehe nicht, das es Oberhalb von 43 Km/h Probleme gibt.

Die Zahlen werden halt durch die Rechnerei "verschliffen".

Ich denke die timestamp lassen sich noch genauer und nicht nur gerundet auslesen.

Vielleicht beißt Du Dich zu sehr an den 0,25 s fest, vielleicht stimmt das gar nicht was irgendwo bei so einem Stick im Beilageblatt in engl. gedruckt steht.

<Speed id='49459s' timestamp='1392119754.30' RPM='203.00' />
<Speed id='49459s' timestamp='1392119754.55' RPM='202.00' />
<Speed id='49459s' timestamp='1392119755.04' RPM='200.00' />

Woher kommt denn dann die timestamp-Rasterung von 0,25 Sekunden?

 

[Leonardi]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

...Die Zahlen werden halt durch die Rechnerei "verschliffen"...
Woher kommt denn dann die timestamp-Rasterung von 0,25 Sekunden?

Wären die Zahlen "verschliffen" so würde die Messkurve auch bei 60Km/h nicht so stetig, sondern verrauscht sein.

Die 0,25s können vom Stick kommen, der Software des Sticks muss ja nicht für alle Anwendungszwecke vollkommen sein, wer weiß wer das entwickelt hat - das muss ja nichts mit den Urentwicklern vom GDC-10 stammen. Das Edge muss mit dem GDC-10 jedenfalls anders kommunizieren, zumindest so das es für unsere Anwendungszwecke auf 0,1Km/h reicht. Ich habe doch den Link zu den Urentwicklern eingestellt, nur die können definitiv eine Antwort geben.

Gruß Leonardi

 

[Patrick]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Wäre es vom Aufwand her nicht günstiger, eine Hardware zu bauen die bei Magnetdurchgang Zählerwerte abspeichert, als ewig ohne Quellcodes und Schaltpläne zu versuchen, fremde Hard- und Software zu analysieren?

Sorry, aber Ihr verzettelt/verrennt Euch genau so wie mit der GPS-Geschichte.

Gruß,
Patrick

 

[Leonardi]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Wäre es vom Aufwand her nicht günstiger, eine Hardware zu bauen die bei Magnetdurchgang Zählerwerte abspeichert, als ewig ohne Quellcodes und Schaltpläne zu versuchen, fremde Hard- und Software zu analysieren?...

Ich hatte hier schon an Aufwand dafür 6-7Wochen mit täglich 8 Stunden angedeutet und auch nur wenn man sich damit auskennt.

***

Es geht hier doch nur um einen preisgünstigen Geschwindigkeitsmesser für Jedermann. Da der GDC-10 von mehreren benutzt werden kann, macht es schon Sinn, nach geeigneten Auslesegeräten zu suchen.

Jede Radumdrehung braucht nicht aufgezeichnet werden, sekündlich reicht. Der GDC-10 mit einem Edge 705 geht doch, nochmal eine Vergleichsmessung durchführen wegen der Knicke in der Ausroll.

Es wurde nur nach anderen Empfängern gesucht, weil nicht jeder den Edge 705 hat - nur darum ging es auf den letzten Seiten hier. Der Stick von gyps konnte bis jetzt noch nicht beweisen, das er für uns genau genug ist.

Welche Geräten haben wir noch, die den GDC-10 auslesen können, Edge 800 ? oder eins von hier: http://www.thisisant.com/directory ?

Gruß Leonardi

 

[gyps]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Ich weiss nicht wie der Kern auf dem PI gebaut ist. z.b tickless, mit HRT etc. aber hast du das Programm zumindest mit "chrt" mit SCHED_FIFO oder SCHED_RR laufen lasen ? Meinem Wissen nach sollten da select(), poll() bzw epoll intern aktiv warten (busy wait), was die Latenz verbessert.

Das Problem liegt tatsächlich (zumindest bislang) nicht beim Pi. 4Hz schafft der auf jeden Fall und die timestamps haben ohnehin nur die Bedeutung, dass man testen kann ob man einen Datensatz verloren hat. Wenn der Pi nur im 4Hz Takt Daten sendet ist das bei hohen Geschwindigkeiten möglicherweise zu grob. Insbesondere, wenn man das Höhenprofil berücksichtigen will.

-- Alex

 

[TimB]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Wäre es vom Aufwand her nicht günstiger, eine Hardware zu bauen die bei Magnetdurchgang Zählerwerte abspeichert, als ewig ohne Quellcodes und Schaltpläne zu versuchen, fremde Hard- und Software zu analysieren?

Naja, die Hardware bauen dauert halt recht lange.
Es gäbe ja schon fertige Lösungen dafür, z.B. sowas hier, da braucht man dann "nur" noch einen passenden Induktivsensor, 24 V Spannungsversorgung und einen Datenlogger (wahlweise Spannung/Strom).
Das Ausgangssignal kann auf den Messbereich getrimmt werden, damit werden 0,2% Genauigkeit erreicht, die Anzahl der Daten, über die ein Mittelwert gebildet wird kann eingestellt werden, Frequenzen von 0 bis 10 kHz sind übertragbar...
...aber das geht halt richtig ins Geld, wiegt kräftig und ist recht klobig und die Datenlogger sind für "etwas" andere Bedingungen programmiert. Hier z.B.: Ringspeicher, Speicherintervall 5 min, Speicher reicht für 3 Jahre.

Gruß,

Tim

 

[Reinhard]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Naja, die Hardware bauen dauert halt recht lange.

Sorry, aber da reicht ein einfacher (bereits fertiger!) Arduino, der von ein bis vier Radsensoren gefüttert wird. Und natürlich ein wenig Software ...

 

[TimB]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Sorry, aber da reicht ein einfacher (bereits fertiger!) Arduino, der von ein bis vier Radsensoren gefüttert wird. Und natürlich ein wenig Software ...

Hast Recht, wird schon gemacht. (Server ist grade down, Google hats im Cache)

Damit wirds dann wirklich sehr einfach für jemanden, der sich mit Arduinoprogrammierung etwas auskennt. 1 Tag Programmieraufwand, inkl. Debugging?
Dazu noch die Anpassung des Radsensors an den Arduinoeingang, und evtl. Ausfiltern des Prellens, falls die Reedsensoren da anfällig sind.

Gruß,

Tim

 

[labella-baron]

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Das Problem liegt tatsächlich (zumindest bislang) nicht beim Pi.

Also nicht beim Raspberry-Pi. Danke für die Klarstellung. Also liegt es am Sender, dem O-Sync-Sensor. Ist der eigentlich baugleich mit dem GDC-10 von Garmin? - oder sendet er wenigstens identische Signale?

4Hz schafft der auf jeden Fall und die timestamps haben ohnehin nur die Bedeutung, dass man testen kann ob man einen Datensatz verloren hat. Wenn der Pi nur im 4Hz Takt Daten sendet ist das bei hohen Geschwindigkeiten möglicherweise zu grob.

So. - Und nun verstehe ich wieder überhaupt nichts mehr:

1. Werden offenbar die timestamps im Raspberry-Pi erzeugt - wieso kann man damit erkennen, ob man einen Datensatz verloren hat. Dazu müssten dann ja alle timestamps im ungefähr gleichen zeitlichen Abstand liegen. Liegen sie aber in der von dir verlinkten Datei speed2.txt nicht. Also wurden da Datensätze verloren
2. Wieso sendet der Pi? Ich denke er ist Empfänger der Daten vom Sensor
3. Was genau steht in einem einzelnen gesendeten Datensatz? Und mit welcher Zahlenauflösung bzw. -darstellung.
4. Wie sieht im vorliegenden Fall das "Protokoll" der ANT+ Funkstrecke aus?