Medizinprojekt: CAN-Protokoll über Funk ?!

[muetzi]

Hallo Leute!

Nachdem ich den nachfolgenden Text vor ca. 1 Std in mühsamer Arbeit (bin nämlich nicht der schnellste schreiber!) verfasst hatte und nach anklicken auf Attachement hinzufügen ich mich noch einmal neu einloggen musste, obwohl ich es bereits war, war der Text (und die Arbeit) verschwunden! Somit sind im Moment meine Nerven ziemlich am Boden und den Text bekomm ich sowieso nicht mehr so wie beim ersten mal hin, aber ich versuche das ganze Problem in kürzerer Fassung nochmal zu schildern (Mit Auszügen aus Lasten, Pflichtenheft, ...)

Tja, wie kommt man auf so eine Idee?!?

Ich besuche z.Zt. das TGM in Wien und hole auf dem Abendweg meinen Ingenieur nach.
Somit sind die Lehrer und auch die Schüler gezwungen, das Wichtigste in der hälfte der Zeit (ca 20 Wochenstunden) gegenüber einem Tagesschüler einem beizubringen bzw zu lernen!

Nur das "Wichtigste" reicht halt manchmal nicht!

Unser Projekt, welches nächstes Jahr ca selbe Zeit als Diplomarbeit präsentert werden soll, ist folgendes:

Biofeedbacksystem (welches eigentlich kein richtiges mehr in diesem Sinne ist) mit folgender Peripherie:

→ Universell einsetzbares Biofeedbacksystem
→ Funkübertragung (Reichweite bis 250 m)
→ 4 Sensoren (Hautleitwert, Hauttemperatur, Puls, Atemfrequenz)
→ EKG
→ 1 Aktor (Muskelstimulator)
→ Stromversorgung der Auswerteeinheit über USB-Schnittstelle
→ Grafische Darstellung am PC
→ Speicherung der Messwerte in Datenbank

Grundvoraussetzung für jede Einheit ist der Einsatz eines µC.
Somit brachte der Lehrer den Vorschlag, s.g. intelligente Sensoren zu entwickeln.
Kabellos, damit ein höherer Tragekomfort und eine höhere Flexibilität des Systems erreicht wird.

Gruppenaufteilung wie folgt:

Gruppe 1: Ableitung EKG, Biomed-Verstärker, Signalverarbeitung
Gruppe 2: Erfassung von Puls,Hautleitwert und Hauttemperatur, Biomed-Verstärker, Signalverarbeitung
Gruppe 3: Erfassung der Atemfrequenz, Biomed-Verstärker, Signalverarbeitung
Gruppe 4: Muskelstimulator, Biomed-Verstärker, Signalverarbeitung
Gruppe 5: Auswertung der Signale und grafische Darstellung am PC sowie Abspeichern der Messwerte in einer Datenbank

Gruppe 5 sind wir, d.h. mein Kollege und Ich.
Um die anderen brauchen wir uns (fast) keine Gedanken mehr zu machen, wir bekommen das fertig aufereitete und digitalisierte Signal (Werte) von den Sensoren welche wir "nur" mehr aufbereiten und am PC bzw Laptop darstellen müssen.

Das FM, für welches wir uns entschieden haben, ist das ER400TRS, u.a. wegen der höheren Reichweite (250m lt. Angabe) -> Sportplatzgröße!

USB deswegen, weil heutzutage fast kein Laptop mehr mit einer COM-Buchse ausgestattet ist und wir die Spannungsversorgung für unser "Kästchen" direkt von der USB-Schnittstelle beziehen können.
Geplante Option: Aufzeichnung der Datenwerte auf einem EEPROM für eine Auswertung zu einem späteren Zeitpunkt. Dafür wäre aber eine eigene Spannungsversorgung notwendig. Wie gesagt: Option!

Die grafische Darstellung wird mittels VB2005 realisiert, da unsere C++ und Java- Kenntnisse ziemlich bescheiden sind!
Das Grundgerüst steht bereits, der Code zur Datenauswertung muss noch implementiert werden, aber wir hoffen, dies wird nicht das Hauptproblem an unserer Aufgabenstellung werden.

Was uns größere Probleme bereitet, ist die Erstellung eines Übertragungsprotokolls, welches auch von uns Entwickelt werden muss.
Und somit kam uns, auch von Lehrerseitiger unterstützter, Gedanke, einen CAN-Controller zu verwenden.
Somit würde uns die Erstellung eines eigenen Übertragungsprotokolles entfallen, weil dieses ja der CAN-Controller übernimmt, welchen wir "nur" mehr richtig konfigurieren müssten.
Dabei stellt sich aber folgende Frage:
Erfordert das CAN-Protokoll eine Voll- oder Halbduplexfähige Schnittstelle?
Eine Anbindung von CAN an UART soll ja möglich und auch nicht zu kompliziert sein. Aber das o.g. FM arbeitet ja nur Halbduplex.
Wenn CAN also Vollduplex benötigen würde, wär die Idee in Folge wieder nichtig.
Was gut klingt, aber dem Datasheet nicht eindeutig zu entnehmen ist, ist die Funktion Frequency-Swap (Senden auf einem, empfangen auf anderen Kanal). Nur ist nicht ganz herauslesbar, ob die gleichzeitig, also Vollduplex geschieht.

Wir haben uns z.Zt. schon etwas mit CAN auseinandergesetz, stoßen aber trotzdem noch auf einige (viele) Verständnisschwierigkeiten, z.B. was es bei CAN mit den Zeitfenstern,... auf sich hat.

Anderes Problem sind die Zeiten, da das EKG das "schnellste" Signal darstellt, da es mit 300Hz abgetastet wird, und somit bei einer Herzgrundfrequenz v. 1Hz ca, alle 3,33ms ein Wert eintrifft.
Die anderen Werte (Hautleitwert,...) sind ja dem entsprechend langsamer, wobei es reicht, wenn ca. alle 1s ein Wert abgefragt bzw. dann gesendet und von uns empfangen wird.
Die könnte man ja aber mit CAN auch recht gut mit der richtigen Verteilung der Prioritäten lösen. Ausserdem gibt es ja auch TTCAN, welches zeitabhängig gesteuert wird, nur die genaue Funktion (gegenüber dem normalen CAN) haben wir auch wiederum nicht genau verstanden.

So, jetzt ist mein Treat doch wieder ziemlich lang geworden und ich klicke jetzt sicherlich nicht mehr auf Attachements!!!

Also, wie gesagt, wir wären für jede Antwort, Wünsche, Anregungen und auch (aber keine beleidigende) Kritik dankbar!
Zusatzinformationen von meiner Seite natürlich jederzeit!

Würde mich freuen, wenn vielleicht auch ein neuer Diskussionstoff im Laufe dieses Projektes entsteht!

In diesem Sinne, herzlichen Dank für kommende Antworten,

Gruß Jörn (und von meinem Kollegen Franz)

PS: Unsere Gruppe muss natürlich auch einen µC verwenden, welcher, wird noch gewählt.

[x-ryder]

schade dass du keine beleidigende kritik haben willst *hrhrhr* aber das wäre jetzt auch böse von mir, weil du ja ziemlich kaputt bist vom schreiben ^^

also die idee mit can wird wohl ziemlich mies umsetzbar sein, vor allem bei maximalgeschwindigkeiten von ca. 300Hz... denn: die übertragungsrate des moduls sinkt mit der sendeentfernung rapide ab. bzw. wenn das nicht der fall sein sollte kommen auf jeden fall tausende von fehlern zustande, aber das dann wiederum sehr schnell

naja, außerdem erfordert can ja auch nochn paar berechnungen, die nen controller aus unserer klasse ziemlich beschwerlich so schnell hinbekommt denke ich...

meine idee würde wieder auf ein eigenes protokoll abzielen, und das dürfte doch eigentlich keine schwierigkeit sein oder irre ich mich da sehr gewaltig? man baut sich nen eigenen frame auf, in dem man steuerbits für verschiedene funktionen einbaut, z.b. obs nen ekg oder "nur" was anderes ist... das kann eigentlich nich so schwer sein... kannst ja ma schreiben was nu alles übertragen werden muss, dann denkich mir da was aus, was schon halbwegs passend sein sollte, außer ihr dürft eigentlich soweit schon keine fremde hilfe mehr haben, kann ja sein ^^

sag erstmal deine meinung zu meiner, dann sehn wa weiter, also meine these: das wird niemals unter can funzen

VG Martin

[maw_hn]

Hallo Jörn,

also was ich net ganz versteh ist warum du überhaupt CAN dazwischen schalten willst. Der Aufwand die Bitübertragungsschicht von CAN so anzupassen dass es über Easyradio läuft ist denk ich höher als selber ein kleines Protokoll zu entwerfen.

Mit den 250m wär ich übringends vorsichtig. Die gelten für optimale Bedingungen. Und die hast du in der Realität leider sehr selten.

MfG Marco

[vajk]

Ich kann meinen Vorrednern nur zustimmen, CAN über funk - eher nicht ...

CAN hat als "verbausteintes" Protokoll eben nur den Vorteil, daß Du Dich nicht normalerweise um Fehlerabläufe aufgrund von Datenkollisionen etc. kümmern mußt, CAN ist jedoch auf Leitungen spezialisiert.

Info zu Zeitfenster - Du meinst hier sicher den einstellbaren Abtastpunkt um ein relativ sicheres Ergebnis zu bekommen. Das ganze hat den Hintergrund, das Sampling dem elektr. Aufbau und den Leitungslängen anzupassen .. also Einschwingvorgänge der Pegel herauszufiltern, die sich u.A. auf Grund der Leigungskapazitäten ergeben etc.. (im Gegensatz zum RS232, das ist alles fix vorgegenben).

Eure Idee PC - USB - RS232/TTL - CAN - Funk --- Funk - CAN - TTL - uC ===== das ist wie ein Zusammenknoten von unterschiedlichen Wasserrohren, mal dick, mal dünn ... Probleme von Dichtigkeit und unterscheidlicher Druckverteilung ... statt einem durchgängigen Schlauch ....

Also PC - USB - RS232 (- ggf. uC) - TTL - FUNK ---- FUNK - TTL - uC wird die Sache doch "etwas" vereinfachen


Bei der Funkübertragung kommen die Bytes entweder korrekt an - oder nicht - ihr müsst euch ein fehlersicherndes Protokoll ausdenken, das doch nicht schwer ... <ID-Sender><ID-Empfänger><Datenlänge><Daten><Prüfsumme>
Wenn ihr es besser machen wollt, dann noch ein Codierungsverfahren wählen, daß "geringe" Übertragunsfehler selbständig "korrigiert".
Und sowas berücksichtigen, wie Daten bei Empfang fehlerhaft, nochmal anfordern. Die EKG-Werte müssen sinnvoll zwischen gespeichert werden !

... es geht auch nur Halbduplex, denn zwei Funkmodule nebeneinander werden vermutlich nicht gehen liegen zu dicht bei einander!

Um Fehlerkollision zu vermeiden, muß ein Master von den Slaves Daten anfordern, einen nach dem anderen abarbeiten.

Die Funkmodule brauchen externe Antennen! Für den Master würde ich zu einer oder zwei Quad-Antennen raten ....

Weiter müßt ihr EMV-zulässigkeiten beachten, Herzschrittmacher und Co.KG ....

Oder ihr müßt fertige Industriekomponenten für die Datenübertragung nutzen und nicht das Spieltzeug im GSM-Bereich, das dort keine störungsfreie Kommunikation garantiert! Dafür wird dieser Frequenzbereich von zu viel Spielzeug genutzt!


Und aus meiner Sicht das Schärfste: VB zu nehmen, statt was anständiges zu lernen. Ne,ne!!! Und dann am besten einen Access-Server für die Daten ... dan ganze möglichst überladen, prima


Ich würde euch sehr zu C/C++ raten, einer schnellen, smarten Datenbank z.b. codebase und für die Datenübertragung mal an WLAN zu denken.
Hätte nicht nur den Vorteil von schnelleren Datenraten.... kleineren Antennen. Aber auch hier EMV beachten !

250m .. Sportplatz ... bewegte Objekte ... viel Erfolg und guten Spurt !
LG, Vajk / DD1GV <- funkamateur

[muetzi]

Hallo an alle!

Danke erst mal für die ersten Antworten!

Wie gesagt, ich bin für jeden Vorschlag dankbar, war ja nie die Rede, das wir mit unseren Gedankengängen richtig liegen!

Ich fahr nur jetzt über dieses WE in einen Spontanurlaub und kann deswegen nicht gleich retour antworten, aber am Mo Nachmittag bin ich wieder online und werde mich euch genauer widmen.

Ich werd mir auf jeden Fall eure Vorschläge durch den Kopf gehen lassen!
Die Technik verfolgt einen ja überall hin!

Also, bis Mo, erholsames WE an alle und Danke fürs erste!

Gruß, Jörn

[muetzi]

Hallo an alle!

Soo, wieder zu Hause vom Kurzurlaub, aber dafür Megaerhohlt, war ziemlich notwendig nach ca einem 3/4 Jahr jeden Tag ca 17-18 Std.

Wie gesagt, das Problem bei uns, das wir weder in Funk-, geschweige in Übertragungstechnik, noch in Programmieren (auch µC) genügend Grundkenntnisse nach heißen 3 Jahren Schule mit auf den Weg bekommen haben.

Entweder wir haben ca ein 3/4 Jahr lang an Schwingkreisberechnungen (RLC-Glieder) rumgegaukelt oder dieses (Schul-)Jahr wiederum die 3/4 Zeit damit verbracht, wie oft man die Halbleiter bezogen auf Dioden & Co ausintgrieren muss, damit man auf die Diffusionsspannung kommt.
Grad mal in den letzten Wochen etwas Digitaltechnik (ohne die ja µC-Programmierung sowieso keinen Sinn macht).

Über Protokolle haben wir grad mal die Grundkenntnisse erfahren (CSMA, OSI-Modell,...), aber nicht, wie man sowas entwickelt bzw programmiert.

In C (NICHT C++!) war das letzte, was wir programmiert hatten, ein Taschenrechner und ein Adressverwaltungsprogramm (natürlich nur Darstellung auf CMD-Ebene).

µC-Programmierung hatten wir auf dieses Jahr zwar etwas gelernt, aber das war ein Schnellkursus in einem Zeitrau von 18 Schulstunden a einer 3/4 Std (80C517A), wo wir grad mal Timer und Display gelernt haben.
Weil mich µC schon immer interessiert haben, hab ich halt ein paar (viele) Stunden zusätzlich investiert, damit ich mal überhaupt Grundlegend mit dem Wichtigsten auskenne (auch ADC und UART).
Die anderen dürfte dieses Thema weniger Interessiert haben und wenn man Sie fragt, was ein Register ist: Antwort: HÄÄÄÄ???????

Aber Hauptsache, wir lernen Filterdesign mit Mathematica. Äußerst sinnvoll!! Und das nächste Jahr werden wir, also die anderen Gruppen, die mit EKG und Co beschäftigt sind, ganz easy auf einem 16Bit µC mit DSP das Programmieren und Filterdesignen lernen! Das ganz easy stammt natürlich von einem Lehrer, der uns erzählt, dass bei einem 12Bit A/D-Wandler 4096 das Datenwort ist, welches als 32Bit-Wert über die UART übertragen wird!!!

Was das Aufgabengebiet bezogen auf alles betrifft, bekommen wir meistens nur die Aufgabenstellung vor den Latz geknallt und es heißt einfach: "Macht's einfach". Nur meine Meinung ist, wenn man nicht zumindest ein paar Grundlagen auf den Weg mitbekommt, wofür geht man dann eigentlich in eine Schule?!? Dann kann man sich ja alles im Selbsttudium beibringen, oder???

Die Sache vereinfacht leider auch nicht, dass man, da ja die Schule berufsbegleitend ist, nur Fr Nachmittag bis So Abend Zeit zum lernen hat, und die elektronischen Fächer nicht die einzigen sind (bzw waren).
Zumindest ich war unter der Woche, wo ich um ca 22.00 Uhr nachhause gekommen bin, nicht fähig, viel zu lernen, wo ich um halb 6 wieder aufstehen musste. Und diejenigen, welche Arbeitslos oder sonstiges waren, bei denen liegt das Interesse eher an "Hauptsache ich bekomm irgendwie den Schein".

Aber das soll nicht mein Problem sein. Wie im ersten Treat beschrieben, mein Kollege ich bilden die Gruppe 5 für die Auswerteeinheit und dort MUSS auch ein µC verwendet werden, obs Sinn macht oder nicht. Man muss sich dann halt einen Grund ausdenken, in wie weit dort ein µC Sinn macht und dies auch interpretieren.


Meiner Meinung nach ist das Projekt eh ziemlich zum scheitern verurteilt, aber die Idee ist da, die Vorarbeiten (wie sinnvoll diese auch immer sein mögen) sind im Laufen und wenn wir zum nächstes Jahr zur Diplomarbeit ein nicht fertiges oder funktionierendes Projekt präsentieren, dann heißt es: "Danke, wir sehen uns beim nächsten Prüfungstermin wieder".

Tja das ist der Grund, warum ich mich an euch Wende, weil in diesem Forum genug Leute sind, welche entweder genug Erfahrung oder auch (gelerntes) Wissen mitbringen. Auch wenns nicht immer Medizintechnik ist, ist ja im Prinzip auch "nur" Elektronik mit ein paar (verschärften) Zusatzbestimmungen. Muss ja auch so sein.

Tja, @Martin:
Ich möchte nicht so einer sein sein, wie "Hilfe, ich habe ein Problem, kann mir einer schnell einen Code schreiben"! Das ist nicht sehr sinnvoll und lernen tut man dabei auch nichts.
Wenn du mir aber deine Hilfe anbietest, bin ich natürlich Dankbar, es hat kein Lehrer gesagt, dass wir keine Fremde Hilfe annehmen dürfen, wir sollen uns ja selbständig Problemlösungen erarbeiten, wie, hat keiner gesagt!
Ich hab mal oben wieder ziemlich viel geschrieben, aber wie du vielleicht liest, ist so ein Protokoll selber schreiben doch ziemlich ein Problem für uns (bzw für mich)!
Kennst du das ER400TRS oder ist auf Funktechnik oder Module allgemein bezogen (433 Mhz, Entfernung, Fehler,...).
Nachdem du und Marco bzw Vajk mir von CAN abraten, wird dies sicher einen Sinn haben, wie gesagt, habe keinerlei (wenig) Erfahrung mit CAN und Funk, und eigenes Protokoll ist dann sicherlich auch weniger Arbeit, wenn manns kann!!
Müsstest mir halt nochmal sagen, was genau du für Daten brauchst.
Danke erst mal für's erste!

@ Marco:
Tja wie im ersten Treat geschildert, kam die Idee wiederum von unseren Lehrern, u.a. auch von dem "Alles-ganz easy-Lehrer".
Die anderen haben halt gemeint, wir sollen uns erst mal erkundigen, ob über unser Modul überhaupt fähig ist, CAN zu übertragen, bzw ob dies überhaupt funzt. Und nachdem ich nach stundenlangen Googeln nichts brauchbares gefunden hab, hab ich mich an euch ans Forum gewendet.
Die Reichweite haben wir noch nicht getestet, das müssen wir allerdings, das teil hat ja auch DCS, obs was nutzt, werden wir ja sehen. Nur wie Vajk schreibt, dürfte das ER doch nicht so sinnvoll für medizintechnische Datenübertragung sein.

@ Vajk:

Nachdem du der Dritte im Bunde bist, der mir von CAN über Funk abrät, werd ich dies nun entgültig aus meinen Gedanken entfernen!
Betreffend Zeitfenster: Den Punkt, den du ansprichst, hat uns natürlich noch keiner erklärt, ist aber auf jeden Fall zu beachten! Danke!
Was ich gemeint habe, war immer die Rede von den schnellen erforderlichen Datenübertragungsraten:
EKG wird mit 300 Hz abgetastest, bei einer Grundfrequenz (normaler Herzschlag) von 1Hz werden ca alle 3,33ms ein Datenwert übertragen.
Wird das Ergebnis 12Bit A/D gewandelt, ergibt: (12 Bit/ 3,33ms)x1000= 3604 Datenbits/ sec, natürlich ohne die restlichen Bits, welche zu einem vollständigen Protokoll noch dazukommen.

Da das ER400 über Luft nicht besonders schnell ist (19200 Baud fix), würde 1 Byte nur in der Luft alleine schon 9ms von Modul zu Modul benötigen. Den Rest kann man sich in etwa hochrechnen, wie lange ein komplettes EKG-Signal, wobei dieses ja aus 2 Frames besteht (wg 12Bit), benötigen würde, um vom Sensor bei uns anzukommen. Die anderen Signale (Hautleitwert, Hauttemperatur,...) sind natürlich dementsprechen langsamer, Atemfrequenz z.B. 12/ min. Da würde ein Wert ca. alle 1 Sekunden reichen. Da müssen wir aber schauen, dass sich die Datenwerte trotzdem nicht (zeitmäßig) überschneiden, deswegen war auch die Rede von einem Zeitstempel, falls doch ein eigenes Protokoll notwendig.

Ich hab leider keine Ahnung Ahnung von solchen Codierungsverfahren betreffend, wie du Sie mir beschrieben hast. Und auch keine Ahnung, wo man Anhaltspunkte findet, wie man solche funktionieren. Unsere Lehrer haben über sowas natürlich auch nichts erwähnt.

Das mit den zwei FM nebeneinander hab ich schon öfters gehört, aber keine Ahnung warum.

Es waren auch schon Überlegungen, da das FM zehn Kanäle hat, jeden Sensor auf einem anderen Kanal zu betreiben (Master müsste halt dann immer auf den betreffenden Kanal wechseln), aber ob das Sinn macht???

Wegen den EMV-Bestimmungen, das haben mein Kollege und ich immer wieder erwähnt, was damit ist, aber da hats nur geheißen, das ist daweil nicht so wichtig, darum brauchts ihr euch noch keine Gedanken zu machen.

Unser Grundgedanke war, da HF-frequente Strahlung im GHz-Bereich nicht die gesündeste ist, nehmen wir halt ein FM mit etwas niederfrequenterer Strahlung. Bluetooth, WLAN und Co, sind zwar gesetzlich nicht verboten, aber es ist halt daweil eine graue Zone, solange nichts passiert. Bestes Beispiel: DECT! In allen Krankenhäusern installiert, aber 1000 x gefährlicher als GSM.

Aber ich bin gerne für Vorschläge offen, wie gesagt, die paar Infos, die ich z.Zt. hab, sind alle nur selber zusammengestoppelt, aber ob diese alle richtig sind, kann ich nicht wissen.
Das Problem ist nur, dass wir das FM schon für alle bestellt und erhalten haben und 40,- EUR/FM zum ... sind, wenn sich nun herausstellt, das dies die falsche Wahl war. Die anderen glauben natürlich, das die FM's die richtige Wahl sind, weil die sich noch weniger auskennen als wir (siehe µC) und noch mit überhaupt nichts in Richtung Funk beschäftigt haben.
Ich glaub, ich hätte mich vorher hier her an euch wenden sollen, aber meine Zeit war leider zu eingeschränkt, um mich in Ruhe mit dem ganzen Kapitel auseinanderzusetzen.

Tja, und das Kapitel Zeit spielt leider auch beim Programmieren eine Rolle. (siehe weiter oben). Mir (uns) ist bewusst, dass C++ sicher die bessere alternative währe, aber unser Informatiklehrer hat gemeint, wenn wir schon seit 3 Jahre C++ o.ä. programmieren würden, kein Problem, aber so sollten wir uns etwas einfacherern widmen. Dewegen VB.

Wegen bewegten Objekten, schätz einmal, die sind per Funk nicht so gut zu erfassen, oder was meinst du damit!

Also, Danke erst mal fürs erste und würd mich auf zahlreiche Anregungen und Anhaltspunkte freuen!

Gruß, Jörn

[vajk]

Hallo Kurzurlauber !

Danke für die Ausführungen - also seid ihr ganz normale Studenten - meinst etwas, wo anders ists viel besser (gewesen) ...

> aber nicht, wie man sowas entwickelt bzw programmiert.

Nun, als Student lernt man Probleme zu lösen .. lernt zu Wissen wo die wichtigen Informationen stehen .. die Fächer sind alle nur Schein (in doppeltem Sinn)


Mein Werdegang war Ausbildung zum PhyTA, Bw, Studium Nachrichtentechnik .. dann zwei Jahre Project Auditing bei VEBA OEL und danach selbständig als Softwareentwickler .... im Studium gings mir so ähnlich wie euch, trotz FH, vorher gabs Basic und Asm .. später TurboPacscal und Modula und wieder pascal .. nur irgendwann war mir das geschreibsel zu viel und hab eben selbst Zeh gelernt und später lange gebraucht, die Vorteile von OO/C++ zu kapieren .. und heute ists ein C/C++-Gemisch auf Windoof-Ebene (nein keine MSKotzWerkzeuge) und Zeh auf uC

Solange Du nicht Asm aufm uC machst, ist C die bessere Wahl, weil Du richtig schöne Fehler machen kannst, die Dir Basic verwehrt
Und eben sehr effizienten Code schreiben kannst .. Kenner wissen, C ist eigentlich eine Mischung aus Aprilscherz und Macroassembler

Im Endeffekt ists nur das Werkzeug und hat nichts damit zu tun, ob man programmieren kann, das "Können" ist aus meiner Sicht was anderes ....

> In C (NICHT C++!) war das letzte, was wir programmiert
> hatten, ein Taschenrechner und ein Adressverwaltungsprogramm
> (natürlich nur Darstellung auf CMD-Ebene).
Na ist doch prima !!!

> µC-Programmierung hatten wir auf dieses Jahr zwar etwas gelernt,
> aber das war ein Schnellkursus in einem Zeitrau von 18
> Schulstunden a einer 3/4 Std (80C517A), wo wir grad mal Timer
> und Display gelernt haben.

Nun für euer Project müßt ihr nunmal uC entwickeln und programmieren - wie gesagt, C ist da nur ein Werkzeug, Timer, Interrupts und Co sind die Basis ... und von C brauchste nur Schleifen und Bedingungs-Abfragen verschiedener Art (if, switch/case) oder eine Mischung daraus

Was bei C haarig sein kann, ist die Verwendung von Pointern oder Referenzen ... aber einmal kapiert, nie wieder Basic ! (bitte an Basic-Menschen, nicht hauen )

> ganz easy auf einem 16Bit µC mit DSP das Programmieren
> und Filterdesignen lernen!

geil !


> .. bei einem 12Bit A/D-Wandler 4096 das Datenwort ist,
> welches als 32Bit-Wert über die UART übertragen wird!!!
ja macht Sinn .. dann muß man auf Windoof-Ebene nicht drüber nachdenken, was man tut

> "Macht's einfach". Nur meine Meinung ist, wenn man
> nicht zumindest ein paar Grundlagen auf den Weg
> mitbekommt, wofür geht man dann eigentlich in eine
> Schule?!? Dann kann man sich ja alles im Selbsttudium
> beibringen, oder???

wie denn - ohne die aus Schüler/Studentensicht fiesen Aufgaben würdet ihr euch doch garnicht damit auseinander setzen

Übrigens später im Berufsleben macht ihr ständig Diplomarbeiten !!!



Die uC - Schnittstelle von Funkübertragung zu PC macht durchaus Sinn !
Außer ihr würdet eben WLAN nutzen.


> wir sollen uns erst mal erkundigen, ob über unser Modul überhaupt
> fähig ist, CAN zu übertragen, bzw ob dies überhaupt funzt.

Thema ist hoffentlich abgehakt, CAN ist wiegesagt ein Baustein-Protokoll für Kabel wegen Kabel-Verhalten ... mit dem Vorteil gegenüber z.B. RS232, daß die "Kabelbedingungen" angepaßt werden können. Na gut, es nimmt einem auch "Arbeit" ab ...

> Und nachdem ich nach stundenlangen Googeln nichts
> brauchbares gefunden hab, hab ich mich an euch ans Forum
> gewendet.
brav

> EKG wird mit 300 Hz abgetastest, bei einer Grundfrequenz
> (normaler Herzschlag) von 1Hz werden ca alle 3,33ms ein
> Datenwert übertragen.
> Wird das Ergebnis 12Bit A/D gewandelt, ergibt:
> (12 Bit/ 3,33ms)x1000= 3604 Datenbits/ sec, natürlich
> ohne die restlichen Bits, welche zu einem vollständigen
> Protokoll noch dazukommen.

bei 19200 Bit per sec ist da noch Luft !


Aber ich verstehe das noch nicht so richig .. EKG mit 3 1/3 ms abgetastet. Ist EKG nicht etwas mit mehreren Elektroden an verschiedenen Stellen des Körpers ? ... Oder nur der Puls ? ... Ähm ... Grübel ...

Gib mal mehr Input ...
Und generelle Frage, kann nicht eine Vorverarbeitung der Werte im uC erfolgen ?



Zur Info eine Messung A/D dauert beim ATmega128/16MHz maximal 200 usec ...




> Da das ER400 über Luft nicht besonders schnell ist (19200 Baud fix),

habs ergoogelt- die 19200 sind nicht fix ! Der Defaultwert ist änderbar. Aber es gibt beim Modul scheinbar Probleme mit der Betriebsspannung verschiedener Chargen ... fragt mal Dr. Google

öhm .. sind 19200 Baud - sind die Bauds nicht den Bits gleichzusetzen - und nicht gleich 2400 Bytes pro sec ? Sprich 1 Byte in ca. 500 usec ?

>deswegen war auch die Rede von einem Zeitstempel, falls
> doch ein eigenes Protokoll notwendig.

zum Thema Protokoll sag ich noch was ...


> Es waren auch schon Überlegungen, da das FM zehn Kanäle hat,
> jeden Sensor auf einem anderen Kanal zu betreiben (Master
> müsste halt dann immer auf den betreffenden Kanal wechseln),
> aber ob das Sinn macht???

Kurzfassung - vergiss es !

Der Master muß die einzelnen Slaves nacheinander abfragen - folglich müssen die Slaves Werte zwischenspeichern ...

Nicht jeder Slave liefert ja EKG-Werte - oder ? ... sprich nur Pulsmessungen etc. können auf die Slaves ausgelagert werden und müssen dann nur minimal Daten übertragen.



> Wegen den EMV-Bestimmungen, das haben mein Kollege und
> ich immer wieder erwähnt, was damit ist, aber da hats nur
> geheißen, das ist daweil nicht so wichtig, darum brauchts ihr
> euch noch keine Gedanken zu machen.

jeinörgl. ... schon klar, soll ja kein Produkt für den Markt werden sondern eine Studie


> Unser Grundgedanke war, da HF-frequente Strahlung im GHz-Bereich
> nicht die gesündeste ist, nehmen wir halt ein FM mit etwas
> niederfrequenterer Strahlung. Bluetooth, WLAN und Co, sind
> zwar gesetzlich nicht verboten, aber es ist halt daweil eine
> graue Zone, solange nichts passiert. Bestes Beispiel: DECT! In
> allen Krankenhäusern installiert, aber 1000 x gefährlicher als GSM.

Nun zu EMV und Co könnte ich jetzt meine Meinung schreiben ... FM .. 70cm-Band ist da auch schon nicht zu verachten !!
Aber für euer Project wohl unrelevant !
Egal was ihr wählt ! Ode reben gewählt habt !

>> Dewegen VB.
Argl .. macht was ihr wollt - ich hasse nurmal WinzigWeich und lehne auch VC ab ! ...
Auf Windoof-Ebene progge ich mit Compiliern von Borland seit dem Turbo C für den Atari ..... und das C derivat von Delphi(e) - sprich Borland Builder ist genauso einfach wie VB zu handhaben ... die Oberfläche klickt man(n und frau) sich zusammen ... und Code in C ist eben effizienter ...




> Wegen bewegten Objekten, schätz einmal, die sind per Funk nicht
> so gut zu erfassen, oder was meinst du damit!
jein .. da ihr den Probanten sicher keinen Helm mit Antenne drauf aufsetzt, hast Du bei all den Frequenzen mit möglicherweise mit menschlichen Hinternissen zu tun ...

.. und aus EMV-Gründen und im speziellen im medizinischen gehe ich davon aus, daß es da viel zu beachten geben würde ..

.. da ihr jedoch keine verkaufsfähige Lösung erstellt ist dies unrelevant.


So nochwas zum Thema Protokoll:

Also ein Datenprotokoll ist nichts anderes als eine Zusammenstellung von Daten, wie ich ja schon geschrieben habe. #<ID-Sender><ID-Empfänger><Datenlänge><Daten>#<Prüfsumme>

Abgesehen davon ist es wichtig, daß ihr die zu übertragenden Daten aber nicht aufbläht, also nicht nur long = 32-Bit - Werte, sondern bytes von 0xFF als Inforamtion ausreicht ..

Die Prüfsumme kann ein CRC-Wert sein - dieser Wert wird mit übermittelt - so kann auch der Empfänger über die Daten ein CRC machen und mit dem übertragenen Wert vergleichen. Die Prüfsumme wird jeweils über den mit # begrenzeten Bereich ermittelt !

Ich bevorzuge Daten im ASCII-Format, so daß man mit einem normalen Terminal die ankommenden Wert auf RS232 / PC - Ebene mit einem Terminalprogrammm sehen kann. Zumindest in der Debugphase ist das sinnvoll!

ACSII kann man auf PC-Ebene wie auch uC - Ebene schön einfach wieder in die Bestandteile zerhacken (strtok, strchr) ....

in C geht das mit schön effizientem Code .. auf uC und PC identisch.
Wobei ich keine Ahnugn habe, ob es ein "strtok" in Basic gibt ...

Der Master spricht die einzelnen Slaves mit ihren Adressen an und erwartet eine Antwort innerhalb eines Zeitfensters .. kommt diese nicht, muß er entweder sofort wieder abfragen und/oder feststellen Kommunkation ggf. gestört ist ...
Da der Master ja mehrere Sensormodule abfragen soll, darf ein Fehlen von Daten eines Moduls nicht zur Blockierung des Systems führen.

Der Master könnte bei seiner Abfragesendung an das Modul auch eine Zeitinformation mitsenden - oder

ihr setzt einfach einen Zähler - int-16bit-bereich reicht und dieser Wert muß wieder zurückgegeben werden ... das kostet weniger Bytes als ein voller Zeitstempel .. und kommt dem gleich ...



So genug Text,
helfe gerne weiter ..

LG
Vajk

[Ozzy]

Hi,

also bei uns an der Uni im Institut für Robotik wird gerade auch an so etwas gearbeitet:
http://www.iti.uni-luebeck.de/Research/MUC/EKG/
Vielleicht ist das ja mal einen Blick/Kontakt wert???
Allerdings arbeiten die mit Bluetooth; also hast Du da nicht so eine Entfernung...

MfG, Ozzy

[vajk]

http://www.iti.uni-luebeck.de/Research/MUC/EKG/

Aber eines find ich zum Würgen: eine Deutsche Domain imt englischem Text !
Das solltet ihr schon zweisprachig gestalten! Noch ist Deutschland nicht Neu Amerika!
Neues englisches Wort: Sender

[Ozzy]

Ich kann da nichts für, hab an dem Institut nur gerade Technische Informatik. Bin ja noch armer Student...

MfG, Ozzy