Daum Schnittstellenprogrammierung

[Quen]

Hallo zusammen,

 

Ich habe hier ein Daum ergo_bike medical8i stehen, und soll es an eine (via python) an eine bestehende Software anbinden.

Zum Testen der Verbindung und Einstellungen habe ich mal ErgoPlanet getestet, was auch einwandfrei funktioniert hat.

Des weiteren habe ich mir das Kommunikationsprotokoll bei Daum runtergeladen. (http://faq.daum-electronic.de/cgi-bin/faq.pl?faq_id=00000194)

 

Leider bin ich in Sachen Netzwerkprogrammierung noch grün hinter den Ohren. Daher wollte ich fragen, ob mir hier jemand ein kleines Beispiel zum Aufbau einer Verbindung, und Senden eines Befehls geben könnte? In welcher Programmiersprache spielt keine Rolle, ich muss nur erstmal grundsätzlich verstehen wie die Kommunikation läuft und wie ich die Pakete richtig packe.

 

Freue mich über jeden Hinweis!

 

Grüße,

Quen

[schnelltreter]

Hallo Quen,

 

also erstmal solltest du sagen, ob du mit dem Ergo über die serielle Schnittstelle oder über die Netzwerkschnittstelle kommunizieren möchtest. Ich würde die Netzwerkschnittstelle empfehlen, da sie zuverlässiger ist!

 

Zur Netzwerkschnittstelle wird eine TCP Socketverbindung über Port 51955 aufgebaut. Über diesen Socket kann man dann alle Befehle senden und die Antworten empfangen. Hier zwei Zeilen C# wie man die Verbindung aufbaut:

 

Socket socket = new Socket( AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp );

socket.Connect( new IPEndPoint( bikeIp, 51955 ) );

 

Weiterhin rate ich dir einen Network-Sniffer wie http://www.wireshark.org zu verwenden und einfach mal auf die Kommunikation zwischen Premium und ErgoPlanet bzw. ergo_win zu lauschen. Da kann man dann die Kommunikation genau nachvollziehen.

 

Viel Erfolg!

[Quen]

Vielen Dank für deine schnelle Antwort!

Ja, ich versuche die Verbindung über die Netzwerkschnittstelle aufzubauen. Die von dir beschriebenen Parameter für die Socketverbindung konnte ich auch schon erfolgreich umsetzen!

Ich hab nur leider keine Ahnung, wie ich nun Daten abfrage. Ich nehme an, das müsste von der Strucktur her in etwa so aussehen:

 

command = ???

socket.send(command)

data = socket.recv(1024)

 

Den Sniffer werde ich mir mal anschauen. Vielen Dank schonmal

[Quen]

Update:

Dank des Sniffers habe ich rausbekommen, wie die Pakete zu schnüren sind.

Habe die wichtigsten Sachen auch schon hinbekommen: z.B. Geschwindigkeit abfragen oder Belastung(Watt) setzen!

Damit habe ich eigentlich schon fast alles, was ich brauche.

 

Vielen Dank nochmal schnelltreter!

[Quen]

Leider lief jetzt doch nicht alles so glatt, wie ich es mir erhofft hatte

 

Wenn ich die Verbindung aufbaue und beispielsweise die Geschwindigkeit abfrage, wird mir das Ergebnis vom Rad alle 11 Sekunden erneut geschickt (Packet 11 und 13 auf dem Screenshot). Die SEQ ist immer eine andere, also handelt es sich um einen neuen Vorgang, und nicht um einen abgelaufenen Timer. Jedoch ist der Wert immer der gleiche wie beim ersten Packet, auch wenn sich die Geschwindigkeit in der Zwischenzeit ändert.

 

http://img37.imageshack.us/img37/460/myconnection03.th.jpg

 

Irgendwie ist mir nicht klar, wieso das Rad diese Daten nochmal schickt. Hat da vielleicht noch jemand eine Idee?

[schnelltreter]

Hast du nach erhalt der Antwort dies mit einem ACK bestätigt? Falls nein, sendet dass Premium so lange, bis es die Bestätigung erhält. Das steht aber schön in der Doku beschrieben

 

public const byte ACK = 0x06;

[Quen]

Das muss man aktiv machen? O.o

Ich dachte das ACK des Protokolls selber (siehe screenshot) würde das übernehmen.

Na das werde ich morgen doch gleich mal testen!

(Und die Doku vorsichtshalber auch nochmal genauer lesen )

Danke für den Hinweis

[DickyMo]

Das ist ja nicht das ACK des TCP Protokolls, sondern das ACK des Cockpit-Kommandos

 

Aber auf diese Weise kann man das auch als Heartbeat zweckentfremden.

[Quen]

Ja, ich glaube, ich stelle mich erstmal ne Runde in die Ecke

 

Mit dem ACK funktioniert es jetzt einwandfrei, nochmal vielen Dank!

Nun muss ich nur noch die "schnellstmögliche" Frequenz testen, mit der ich Daten abrufen kann. Schneller als ca. einmal pro Sekunde scheint dem Bike zu viel zu sein.

[DickyMo]

Warum du überhaupt ein ACK senden musst bzw. warum das alle 11 Sekunden wiederholt wird:

Nicht erkannte ACK-Zeichen werden als NAK gewertet.

 

Bei inkorrektem Ende-Zeichen verwirft der Empfänger das Datenpaket nach einem Empfangs-Timeout

von 10s. Der Sender erhält dabei kein ACK oder NAK und wiederholt daraufhin das Senden des

Datenpakets nach einem Sende-Timeout von 11s. Nach fünf erfolglosen Versuchen gibt der Sender

auf.

Nun muss ich nur noch die "schnellstmögliche" Frequenz testen, mit der ich Daten abrufen kann. Schneller als ca. einmal pro Sekunde scheint dem Bike zu viel zu sein.

Brauchst du denn die Werte schneller als eine Sekunde? Die Trainingsergebnisse haben ohnehin nur nen Step von 1er Sekunde (sofern du diese auch verarbeiten willst).

Jetzt aber wirklich ab in die Ecke. Aus der Doku (Classic Modelle; dies gilt wohl aber auch für die Premiums):

Die Daten werden in Form von einzelnen Datenpakete übertragen, die einen

Mindestabstand (Mindestpause) von 50 ms aufweisen müssen. Das Cockpit antwortet

meist innerhalb 50 ms und garantiert innerhalb 1 s, falls im Cockpit nicht ein Menü

aufgerufen wurde.

 

[Quen]

Brauchst du denn die Werte schneller als eine Sekunde?

Ja, es geht um eine VirtualReality-Anwendung. Da wäre eine Verarbeitung in Echtzeit schon klasse

 

 

 

Aus der Doku (Classic Modelle; dies gilt wohl aber auch für die Premiums)

Japp, da gilt wohl das gleiche, steht aber in der premium/medical Schnittstellen-Doku nicht drin :f:

http://www.ergobike.de/de/download/bedaprem/SP-KOMM-PM1.pdf

Damit hab ich dann auch genug in der Ecke gestanden

Bearbeitet 15. Juli 2010 von Quen