CFW: Data Logger

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

CFW: Data Logger

Beitrag von chehr » 28 Feb 2017, 21:20

Wie integriert man am besten in die CFW eine Funktion damit man Daten auf der SD-Karte loggen kann?
Via Microcontroller ging das z.B, mit SDFileSystem.h

richard.kunze
Administrator
Beiträge: 558
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Data Logger

Beitrag von richard.kunze » 28 Feb 2017, 22:56

chehr hat geschrieben:Wie integriert man am besten in die CFW eine Funktion damit man Daten auf der SD-Karte loggen kann?
Einfach mit den "normalen" Dateifunktionen in der Programmiersprache Deiner Wahl - also in Python z.B. mit

Code: Alles auswählen

with fopen('/home/ftc/data.log', 'w') as file:
    file.write('Hier kommen die Daten!\n')
und in C mit den üblichen Funktionen aus "stdio.h"

Am besten schreibst Du in eine Datei irgendwo unterhalb von "/home/ftc" - da sind die Daten dann per SSH leicht zugänglich, und /home/ftc ist auch in der Default-Konfiguration ohne zusätzliche Rechte beschreibbar.
chehr hat geschrieben:Via Microcontroller ging das z.B, mit SDFileSystem.h
In der CFW brauchst Du für die SD-Karte und das Deteisystem keinen speziellen Treiber nachrüsten - das macht da der Linux-Kernel.

Benutzeravatar
MasterOfGizmo
Beiträge: 1871
Registriert: 30 Nov 2014, 07:44

Re: CFW: Data Logger

Beitrag von MasterOfGizmo » 01 Mär 2017, 14:14

richard.kunze hat geschrieben: Am besten schreibst Du in eine Datei irgendwo unterhalb von "/home/ftc"
Wenn Du statt "/home/ftc" z.B. unter Python os.path.join(os.path.expanduser("~") nimmst, dann macht das auf dem TXT keinen Unterschied, aber Dein Programm läuft auch auf einem normalen PC und schreibt die Daten dort auch in das Home-Verzeichnis des aktuellen Users. Das macht die Programmentwicklung ggf. etwas einfacher.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 25 Jun 2017, 12:48

Wie kommt man am schnellsten (z.B. via einem Button klick) an die gespeicherten Sensor Daten ran?
Am liebsten wäre mir wenn man über http die Daten downloaden könnte und zwar auf dem "web-interface", weil da gibt es auch schon den upload button.

Zur Info, die Sensor Daten werden direkt in ein Excel file auf SD-Karte gespeichert.
Das Python Programm des BNO055 ist momentan hier (der Speicherpfad muß noch angepasst werden):
https://github.com/chehr/ftc-apps/blob/ ... enshot.png

Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?

richard.kunze
Administrator
Beiträge: 558
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Data Logger

Beitrag von richard.kunze » 25 Jun 2017, 14:16

chehr hat geschrieben:Wie kommt man am schnellsten (z.B. via einem Button klick) an die gespeicherten Sensor Daten ran?
Am liebsten wäre mir wenn man über http die Daten downloaden könnte und zwar auf dem "web-interface", weil da gibt es auch schon den upload button.
Wenn ich mir die App unter https://github.com/chehr/ftc-apps/ anschaue, dann sollte es eigentlich reichen wenn Du im Manifest zusätzlich die folgende Zeile einfügst:

Code: Alles auswählen

html: Datalogger.xls
Dann solltest Du das Excel-File im Webinterface bei den Details der App unter "Application pages" finden.
chehr hat geschrieben:Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?
Kommt drauf an, mit welchem Betriebssystem der PC läuft, und was Du mit "simulieren" meinst. Für Linux würde ich mal nach einem USB-nach-I2C/smbus-Adapter suchen (z.B. den hier: https://www.silabs.com/documents/public ... asheet.pdf - ich hab damit allerdings keinerlei Erfahrung, das Ding kam halt bei Google als Antwort auf "USB smbus converter linux" raus). Damit sollte das eigentlich ganz ohne Simulation auch direkt mit dem echten Sensor funktionieren...

Benutzeravatar
MasterOfGizmo
Beiträge: 1871
Registriert: 30 Nov 2014, 07:44

Re: CFW: Data Logger

Beitrag von MasterOfGizmo » 25 Jun 2017, 14:45

chehr hat geschrieben: Das Python Programm des BNO055 ist momentan hier ...
Interessant. Was ähnliches habe ich neulich für BMX055 gemacht: https://github.com/harbaum/cfw-apps/tre ... ges/bmx055 . Ggf. kann man das alles kombinieren und hat dann eine App, die mit diversen Sensoren dieser Art funktioniert.
chehr hat geschrieben: Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?
Unter Linux nutze ich meinen alten i2c-tiny-usb. Als Hardware-Basis kann man den Digispark nehmen, der kostet nur ca 1 Euro und wird per USB abgschlossen: https://github.com/harbaum/I2C-Tiny-USB ... /digispark

Unter Linux gibt es dafür einen Kernel-Treiber. Damit sieht der vom Geräte bereitgestellte I2C/SMBUS am PC identisch zu den anderen smbus'en aus und Deine App würde auf dem PC den Sensor 1:1 ansprechen können. Habe ich neulich gerade mit einem rfid-Leser gemacht. Die App dazu läuft auf dem TXT, dem R-Pi oder dem PC und kann auf allen Systemen den i2c-RFID-Sensor direkt ansprechen.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 25 Jun 2017, 20:25

Einfach genial, damit geht es super einfach.
richard.kunze hat geschrieben: Wenn ich mir die App unter https://github.com/chehr/ftc-apps/ anschaue, dann sollte es eigentlich reichen wenn Du im Manifest zusätzlich die folgende Zeile einfügst:

Code: Alles auswählen

html: Datalogger.xls
Dann solltest Du das Excel-File im Webinterface bei den Details der App unter "Application pages" finden.
Vielen Dank Richard für den Tipp

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 27 Jun 2017, 14:33

Hi Mog,
MasterOfGizmo hat geschrieben: Interessant. Was ähnliches habe ich neulich für BMX055 gemacht: https://github.com/harbaum/cfw-apps/tre ... ges/bmx055 . Ggf. kann man das alles kombinieren und hat dann eine App, die mit diversen Sensoren dieser Art funktioniert.
Das finde ich eine gute Idee
Ich hatte die Hoffnung, das die I2C Treiber schneller in Python geschrieben sind im Vergleich zu Robo Pro, weil es div Codes schon gibt. Leider habe ich die Hoffnung aufgegeben. Die vorhandenen div Codes sind meist halbfertig und sehr unterschiedlich. Der Aufwand ist fast so groß, wie den Treiber neu zu schreiben. Deshalb macht ein vernünftiges grundgerüst Sinn für div Sensoren dieser Art.
Zunächst bin ich aber noch an prinzipielle Probleme dran immer im Hinblick auf eine hohe Samplingrate. Ist die Liste geeignet bevor man alle Daten auf SD schreibt?

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 11 Jul 2017, 18:21

Hallo,
dank der genialen Community Firmware funktioniert das Data Logging auf die TXT SD-Karte nun schon ganz gut.
Die Daten werden gleich im Excel Format gespeichert. Die Daten sind für mich wichtig für die Auswertung, Steuerung und Regelung bzgl autonomes Fahren.
Ein Bildschirmfoto anbei mit 10Hz sampling rate:
Excel Data von der TXT SD-Karte
Excel Data von der TXT SD-Karte
Leider entspricht die Samplingrate mit max ca 25Hz noch nicht meiner Erwartung. Deshalb die frage, wie man diese höher und zwar über 100Hz bekommt. An die visuelle Anzeige zu verzichten habe ich schon gedacht. Aber ist der QTimer die beste Methode oder gibt es bessere in Python? Ist der I2C Bus im High Speed mode?

Außerdem verstehe ich nicht warum die gespeicherten Datenzeilen immer weniger sind wie theoretisch via Samplingrate und Zeit errechnet. Die Anzahl der Datenzeilen sind Zufällig (z.B 1330 oder 327 Zeilen). Ein überlauf der Liste bzw das der TXT nicht genügend RAM hat denke ich ist nicht die Ursache für diesen Fehler. Ich vermute mal das der I2C Bus mit der Kommunikation abbricht. Leider gibt Python keine Fehlermeldung aus.

Das Python Programm ist da:
https://github.com/chehr/ftc-apps/blob/ ... /bno055.py

Benutzeravatar
MasterOfGizmo
Beiträge: 1871
Registriert: 30 Nov 2014, 07:44

Re: CFW: Data Logger

Beitrag von MasterOfGizmo » 11 Jul 2017, 20:40

chehr hat geschrieben: Leider entspricht die Samplingrate mit max ca 25Hz noch nicht meiner Erwartung.
Sowas habe ich bei meinem Sensor auch. Du kannst mal ein paar-tausend Sensor-Abfragen direkt in einer Schleife machen und mit Python-Timer-Board-Mitteln die Zeit messen. Das war bei mir immernoch recht langsam, also haben weder Bildschirmausgabe noch QT-Timer damit was zu tun. Und die Zeit korrelliert recht gut mit den pro I2C-Transfer übertragenen Bytes, das ist also kein "setup-Overhead" oder so.

Nachgemessen habe ich's nicht, aber der i2c scheint nicht sehr schnell zu sein. Kann aber durchaus CFW-spezifisch sein. M.E. hat sich nie einer den I2c im Detail angeschaut. Ging halt einfach ...
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 12 Jul 2017, 09:15

Der Console Befehl

Code: Alles auswählen

sudo i2cdetect -y 1
liefert bei mir folgenden Fehler:
Error: Can't use SMBus Quick Write command on this bus
Der Befehl:

Code: Alles auswählen

i2cdetect -F 1
zeigt auch an das SMBus Quick Command nicht implementiert ist.

Es scheint mir dass die Übertragungsrate von 100 kbit/s definiert ist und nicht im High Speed mode mit 400 kbit/s.
Wie kann man in den High Speed Mode umschalten?
Zuletzt geändert von chehr am 12 Jul 2017, 11:37, insgesamt 1-mal geändert.

richard.kunze
Administrator
Beiträge: 558
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Data Logger

Beitrag von richard.kunze » 12 Jul 2017, 11:34

MasterOfGizmo hat geschrieben: Nachgemessen habe ich's nicht, aber der i2c scheint nicht sehr schnell zu sein. Kann aber durchaus CFW-spezifisch sein.
Im DTS steht für beide definierte I2C-Busse ein Bustakt von 400000Hz, genau wie im DTS aus der originalen Firmware von Fischertechnik.

Ob man da beim externen Bus (müsste i2c1 sein, aber keine Garantie) gefahrlos an der Taktrate drehen kann müsste man mal im Treiber und in den Hardware-Specs nachschauen...

Benutzeravatar
ski7777
Beiträge: 845
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Data Logger

Beitrag von ski7777 » 12 Jul 2017, 11:39

richard.kunze hat geschrieben:(müsste i2c1 sein, aber keine Garantie)
Ist der 1er. Der 0er hängt am Power Controller. Da würde ich besser nix hinschicken.

Raphael

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 12 Jul 2017, 11:42

Hi Richard,
die Messung des SCL-Takt hat mit der CFW >100kHz und mit RoboPro <400kHz betragen. Kann man noch irgendwo den Fast Mode aktivieren?

Benutzeravatar
ski7777
Beiträge: 845
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Data Logger

Beitrag von ski7777 » 12 Jul 2017, 11:53

Mehr als https://github.com/ftCommunity/ftcommun ... t.dts#L130 ist nicht drin. Also der fast mode ist an. Eventuell musst du python oder so mitteilen, dass du auch den fastmode nutzen willst.

Raphael

Benutzeravatar
ski7777
Beiträge: 845
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: CFW: Data Logger

Beitrag von ski7777 » 12 Jul 2017, 11:59

Der TXT hat sowohl interne Pull-Ups, als auch welche im AM335x. Liegt es vielleicht an einem insgesamt zu kleinen Pull-Up?

Raphael

richard.kunze
Administrator
Beiträge: 558
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Data Logger

Beitrag von richard.kunze » 12 Jul 2017, 12:21

chehr hat geschrieben:Hi Richard,
die Messung des SCL-Takt hat mit der CFW >100kHz und mit RoboPro <400kHz betragen.
Hmm. "CFW > 100kHz" klingt danach, dass der Bus schon im Fast Mode ist (sonst müsste das <= 100kHz sein). Da steckt das Limit dann wohl eher woanders...

Ich würde mal folgendes probieren
  • Timings mit RoboPro auf der CFW messen (also in der CFW die "FT GUI" starten). Wenn das ähnlich schnell ist wie in der Original-Firmware liegt das Limit schon mal nicht im Kernel
  • Timings in Python in einer simplen Schleife (ohne GUI, Threads und Timer) messen (wie von MoG schon vorgeschlagen). Wenn das langsam ist, liegts vermutlich an Python.
  • Als Gegenprobe das ganze als C-Programm implementieren und nochmal messen. Das sollte dann ähnlich schnell (bzw eigentlich schneller) sein als RoboPro, und wenn das so ist, dann ist definitiv Python die "Bremse".

chehr
Beiträge: 161
Registriert: 07 Apr 2015, 21:07
Wohnort: Friedrichshafen

Re: CFW: Data Logger

Beitrag von chehr » 12 Jul 2017, 22:22

Hallo Richard,
habe mal Messungen mit RoboPro mit und ohne CFW durchgeführt und es gibt reproduzierbar einen Geschwindigkeitsunterschied von ca 20%, wobei die CFW etwas langsamer ist.
Via WLan Verbindung ist natürlich diese die Schwachstelle aber auch im Downloadbetrieb jeweils mit und ohne CFW gibt es den Unterschied.

Weitere Infos anbei
I2C Speedtest mit RoboPro mit und ohne CFW
I2C Speedtest mit RoboPro mit und ohne CFW
Zur Info:
Angeschossen war der BNO055 Sensor
Zeitdauer gemessen nach 1000 Lesezyklen a 9 x 16bit Sensorwerte - RoboPro Programm ist im Bild anbei.

Einen Geschwindigkeitsunterschied mit 100kHz oder 400kHz I2C Lesegeschwindigkeit in den RoboPro Settings konnte ich nicht feststellen.
chehr hat geschrieben:>100kHz mit CFW
ich muß mich korrigieren, ich meinte eigentlich <100kHz mit der CFW

richard.kunze
Administrator
Beiträge: 558
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: CFW: Data Logger

Beitrag von richard.kunze » 13 Jul 2017, 17:23

chehr hat geschrieben:Zeitdauer gemessen nach 1000 Lesezyklen a 9 x 16bit Sensorwerte - RoboPro Programm ist im Bild anbei.
Hmm. Wenn ich mich nicht verrechnet habe kommst Du da dann auch beim schnellsten Lauf (Originalfirmware, 1,88 Sekunden) nur auf etwa 76Kbit/s. Da muss irgendwas anderes bremsen als der I2C-Bus...

Verdacht nach Bauchgefühl: Die CPU ist am Anschlag (würde auch dazu passen dass die CFW etwa 20% langsamer ist - da braucht der Launcher schliesslich auch etwas CPU)...

Benutzeravatar
MasterOfGizmo
Beiträge: 1871
Registriert: 30 Nov 2014, 07:44

Re: CFW: Data Logger

Beitrag von MasterOfGizmo » 14 Jul 2017, 22:11

Naja, 1000*16*9/1.88 ist 76k ... so weit zwar richtig, aber:

Wenn man am I2C ein Byte übertraägt, dann hat das jeweils noch ein Ack-Bit. Bei jedem Transfer geht vorher noch die Chip- und die Registeradresse über den Bus sowie das Start- und Stoppbit. 9*16 Daten-Bit sind also insgesamt mindestens 9*18 + 2 * 9 + 2 Bit. Da kommt man auf 1000 * (9*18 + 2 * 9 + 2) / 1.88 = 97kBit/s. Da ist er also schon echt nah an den 100kbit/s dran.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Antworten