Archiv verlassen und diese Seite im Standarddesign anzeigen : Medizinprojekt: CAN-Protokoll über Funk ?!
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.
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 :D
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 ;)
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
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
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
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
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
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
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 ;-)
Ich kann da nichts für, hab an dem Institut nur gerade Technische Informatik. Bin ja noch armer Student...
MfG, Ozzy
So, nachdem ich eigentlich nur eine url einfügen wollte und diese Windoof im gleichen Fenster wie meinen Beitrag öffnete, sind einmal wieder 2 Std schreibarb und meine Neven im A.... (tschuldigung für den Ausdruck).
@ Ozzy
Danke für den Link, werd ihn mir mal genauer anschauen, nur find ich das ganze mal wieder total Beunruhigend, das sowas ähnliches, was wir versuchen zu lösen ein Uni-Projekt ist und das ganze noch mit FPGA's, wo nicht einmal richtig µC-Programmierung beherrschen.
Hallo Vaijk!
Danke erst mal für deine ausführliche Antwort.
So wie ich das seh, bin ich ja bei Dir an einen richtigen Professionisten geraten und das sogar in der Fachrichtung, was ich (wir) benötigen!
> also seid ihr ganz normale Studenten
Jein.
Der HTL-Ingenieur (HTL= Höhere technische Lehranstalt) in Österreich ist ein etwas abgespekter Ingenieur. Du hast 4 bzw 5 Jahre Schullaufbahn. Abschluß mittels Abitur (in AUT namentlich Matura). Nur hast du neben den allgemeinbildenden Fächern auch die Technischen. Abitur besteht einerseits aus allgemeinbildenden Teil und andererseits aus dem technischen Teil, welcher aus einem technischen-, einem Komplementärfach und aus der Diplomarbeit besteht, welche während der Schullaufbahn (meist im letzten Jahr) mit deinem Lehrer, welcher auch als Projektleiter agiert, ausgearbeitet.
Diese Art von Ingenieur ist dann beruflich eher nur für die Konstruktion oder Service gedacht.
Wenn du anschließend zur Uni oder FH Studieren gehst und du dies auch abschließt, dann bist du Dipl.Ing. oder FH-Dipl-Ing. Denn nur an der Uni lernst du dann die richtigen Hintergründe kennen und bist auch für eine Entwicklung und Forschung geeignet und dem HTL-Ing (wissensmäßig) überlegen.
> 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)
Haben uns unsere Lehrer auch gesagt, aber:
Abendschule, d.h Zeitproblem, Unter der Woche 40 Std arbeiten oder manchmal auch mehr, am Abend in die Schule und Zeit zum lernen bleibt selber nur am WE. (Privatleben? Was ist das!!!). Deswegen wend ich mich ja auch an euch (ans Forum)!
> Solange Du nicht Asm aufm uC machst, ist C die bessere
> Wahl, weil Du richtig schöne Fehler machen kannst, die
> Dir Basic verwehrt
Meinst du Basic am µC???
Ich kenn nur Bascom am AVR (vom hören).
ASM kann ich nicht, ich habs nur zum debuggen genommen, also ich schreib einen C-Code, funktioniert nicht und kontrolliere dann im
Assembler, wieso. Das zu lernen, war zwar nicht einfach, aber es zahlt sich aus, z.B. bei Laufzeitfehlern.
> aber einmal kapiert, nie wieder Basic !
Ich gebs ja zu, wenn ich's könnte oder mich auskennen würde, würd ich Windoof von meinem PC verdammen, Linux drauf und nur in C, C++ oder Java programmieren!
Unser Informatiklehrer hat ja selber gesagt, das gerade VB insbesondere bei laufzeitkritischen Anwendungen seine Schwächen hat. Es ist halt DAU-sicher und für Windoof, das halt leider viel zu verbreitet ist.
> ganz easy auf einem 16Bit µC mit DSP das Programmieren
> und Filterdesignen lernen!
Is ja eh geil, aber wie gesagt:
Filterdesign auf einem Mathematikprogramm, sprich Mathematica. Ein Lehrer hat selber gesagt, das für uns Filterdesign mit Matlab sinnvoller wäre, weil es dort auch die dafür vorgesehenen Tools gibt. Nur unsere Lehrer dürften da anderer Meinung sein.
Meine Meinung: Mathematica ist für jemanden geeignet, der die Mathematik wirklich versteht und nicht zum rumspielen, denn das Prog beruht ja auf mathem. Grundlagen.
Um Filter zu Designen, braucht man ja bekanntlich u.a. tiefere mathem. Kenntnisse (Z-Transformation,...), welche aber man erst auf der Uni richtig lernt und mit unseren paar Mathekenntnissen, wo wir grad mal bissl Integrieren gelerent haben (aber nicht partielles,...) keine Chance haben, jemals die Materie zu verstehen.
Am Dsp programmieren ist dies dann eine weitere Geschichte, die sich weisen wird.
Wie gesagt, ich kenn mich halt mal mit nem "normalen" 8-Bit-µC grundlegend aus, andere aus unserer Klasse wissen
nicht mal,was ein Register ist (ohne Übertreibung), und dann gleich zum Einstieg einen 16Bit-µC mit DSP, welchen man aber mind. zum Filtern braucht, viel Spass!!!!
> .. bei einem 12Bit A/D-Wandler 4096 das Datenwort ist,
> welches als 32Bit-Wert über die UART übertragen wird!!!
Der "Alles-ganz-easy-Lehrer" hat folgendes gemeint:
4096 is das Wandlungsergebnis des ADC (2^12), dieser wird laut ihm auf den Datenbus als 4Byte-große(r)s Wort(Wert, also 32Bit) ausgegeben (4 0 9 6) und dann halt auf die UART oder anderes.
Ich hab das so verstanden:
4096 is die Schrittweite, womit ich ma die max Auflösung/ Schritt errechne, also 5V/4096=1,22mV/ Schritt.
Das Wandlungsergebnis beträgt aber bei einen 16Bit-µC nur 12Bit, das halt dann als Int-Zahl am mit 4 Nullen am Schluss oder Anfang oder ... am Bus ausgegeben wird.
Folglich Easy-Lehrer-Theorem:
Bei fa=300Hz, T=3,33ms: 32 Bit/3,33ms*1000= 9610Bit/s Übertragungsrate.
Jörnsches Theorem:
12Bit (16Bit)/3,33*1000= 3604 (4805)Bit/s Übertragungsrate.
Warum, das ganze mit 3,33ms,... kommt noch!
Wer liegt richtig???
> Übrigens später im Berufsleben macht ihr ständig Diplomarbeiten !!!
Das ist ein guter Ansatz (Grundgedanke), so hab ich das bis jetzt noch nicht gesehen! Werds beherzigen und mir merken!
Hab halt noch keine Berufspraxis als Ing, bin daweil noch normaler Facharbeiter.
> Die uC - Schnittstelle von Funkübertragung zu PC macht durchaus Sinn !
> Außer ihr würdet eben WLAN nutzen.
Hat ein Lehrer auch gemeint. Der µC würde entweder den PC entlasten, oder auch als eigener µComputer agieren, wenn man die Daten erst mal nur speichern und erst später Auswerten will.
> fähig ist, CAN zu übertragen, bzw ob dies überhaupt funzt.
Überredet, Thema abgehakt!!!
So, nun zum Geheimns EKG:
Es ist richtig, es werden mehre Elektroden am Körper (Brustbereich) angelegt, welche die s.g. Aktionspotentiale des Herzens erfassen. Dadurch wird das EKG in verschiedenen Dimensionen gemessen, welches als Vektorfeld interpretiert wird (is aber eher nur für die medizinische Diagnostig von Interesse!) Grundlegend reichen 3 Elektroden (s.g. Extremitäten-Ableitungungen nach Goldberger und Einthoven).
Diese Elektroden werden auf einen Instrumentenverstärker geführt, somit wird daraus letztendlich ein Signal. Dies wird analog vorgefiltert (wg. ganzen Elektroschrott wie 50Hz-Brumm in der Luft,...), und rein in den µC, dort A/D-gewandelt und richtig gefiltert (DSP,..).
Die Grundfrequenz des Herzschlages bei einem gesunden Menschen beträgt ca. 1Hz, Spannung der PQRST-Welle ca -2mV bis 6mV, somit kann man aus einem EKG auch den Puls regenerieren, der in etwa 60bpm beträgt. Dieser besteht ja nur aus einzelnen Werten und ist kein kontinuierliches Signal. Um ein solches EKG Signal richtig digitalisiert wiedergeben (und interpretieren) zu können, muss es mind. mit 300 Hz abgetastet und 12Bit A/D-gewandelt werden.
Faktum: T=1/f: 1/300= 3,33ms/Sample, welcher auch mit dieser Frequenz bzw Periodendauer gesendet wird.
Wie oben bereits beschrieben erfolgt die Aufbereitung bereits mittels µC.
Das System:
Sensor (z.B. EKG)-Verstärker-Filter-ADC-µC (DSP)-FM <--> #FM-µC-UART-USB <--> PC#
Wie bereits erwähnt, um die Sensoren brauchen wir,
also mein Kollege und Ich nicht zu kümmern, das ist Aufgabe der anderen Gruppen (wenn die das zusammenbringen). Wir haben nur die Aufgabe, die "Auswerteeinheit(nenne sie ab jetzt AE)" zu konstruieren (den Teil zwischen #...#) und das Übertragungsprotokoll zu entwickeln, was wir für die Kommunikation benötigen und den anderen sozusagen für die Kommunikation mit uns vorschreiben.
Die anderen Sensoren hab ich ja bereits in meinem ersten Treat beschrieben.
Falls du über EKG genauer bescheid wissen willst:
http://www.grundkurs-ekg.de/index.htm#anfang
> 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
Die 19200 Baud zw. Host-FM sind einstellbar (bis zu 88kBaud), aber die Übertragungsrate IN DER LUFT (von FM zu FM) sind fix mit 19200. Hab deswegen schon mit dem Support in England kommuniziert, die haben mir das bestätigt.
Mit Betriebsspannungen hab ich noch keine Probleme gehabt, hab die Module schon mehrmals am µC bzw PC gehabt und getestet, funktioniert einwandfrei, aber darüber hab ich auch schon einiges gelesen.
>ö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 ?
Ja sicher, aber wir haben gelernt dass, bei Baud ja nicht nur die Datenbits relevant sind, sonder das ganze Frame (das komplette Protokoll samt Start-, Stopbits, Präambel,...). 1 Frame besteht aus z.B. 23Bit, also müssen alle Bits dieses Frames mittels den 19200 übertragen werden.
> Der Master muß die einzelnen Slaves nacheinander abfragen - folglich
> müssen die Slaves Werte zwischenspeichern ...
Wenn ich dass richtig verstanden habe, ist das bei Protokollen immer so, weil die Daten ja seriell Übertragen werden, folglich kann der Master nicht mehrere Slaves parallel abfragen???
Sorry, aber da wir so gut wie noch nichts über Protokollerstellung gelernt haben, kann ich mir einfach nichts drunter vorstellen wie so was abläuft
oder auch ablaufen könnte.
> 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.
Stimmt, derzeitiger Stand, ein EKG, restlichen Sensoren, siehe 1er Treat von mir.
Wenn ich das richtig verstanden hab, was du meinst, ist, dass die restlichen Daten von den anderen Sensoren Datenwerte in viel größeren Zeitabständen liefern müssen (z.B. Atemfrequenz/min: 12-40, T=0,2 - 0,6s) und zwischengespeichert werden müssen, weil sie ja erst später abgefragt werden, aber was hat das mit Langsameren und schnelleren Daten zu tun???
Sorry, aber irgendwie komm ich durcheinander.
Wegen EMV und CO:
Theoretisch dürfte man ja gar nichts über Funk übertragen, 433MHz ist sicher auch nicht ungefährlich, aber halt nicht sooo Hochfrequent wie 2,4Ghz.
Ich hab ehrlich gesagt keine Ahnung, ob unsere Lösung verkaufsfähig sein sollte oder nicht. Was ich gehört habe, nein. Aber da werd ich mich noch erkundigen.
Thema Protokoll:
Danke für die ausführliche Antwort!
ASCII-Format: bis jetzt habe ich auch nochts anderes Übertragen, da das Modul sowieseo nur an eine gewöhnliche UART-Schnittstelle angeschlossen wird, wegen dem debuggen stimmt, ich hab am Hyperteminal dann die Daten verglichen, ob sie die gleichen sind,
wie ich Sie abgeschickt habe. Solche Befehle/Funktionen wie strtok u strchr kenn ich allerdings nicht, werds mir aber mal anschauen.
Danke für den Hinweis!
Mein Kollege übernimmt die PC-Oberfläche, hab ihm alles erzählt, er is der Meinung, man kann mit VB2005 sogar Pointer programmieren, ich kanns nicht sagen, aber ich glaubs persönlich nicht. Er will, solang es nicht wirklich nötig ist, bei VB bleiben und die Datenbank mittels SQL programmieren. *Sturbleib*
Ich kann nicht sagen, dass ich wirklich C programmieren kann. Pointer sind mir daweil auch noch ein fremdes Dorf, aber ich möchts lernen und ich persönlich finde C auch besser (vielleicht auch, weil ichs gewohnt bin, Syntax,..). Nur ich weiß halt leider nicht, warum C, C++ effizienter gegenüber VB ist. Ich vermut halt, weil mann in C eben mit Pointern Speicherstellen direkt ansprechen kann und das genauso, als wenn man beim µC in Assembler programmiert, eben effizienter (auf Laufzeiten bezogen) ist.
Aber ob das einzige Grund ist???
Ich denk halt immer wieder daran, wie man so ein Protokoll programmiert und das einzige, was ich mir vorstellen kann, ist, dass das Protokoll in Form eines Arrays programmiert wird. Lieg ich da richtig?
> 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 ...
Das hat uns mein Lehrer auch gesagt: solange man davon ausgeht, dass keine anderen (fremden) Einflüsse in der Umgebung sind, also die Kommunikation stören, braucht man keinen Zeitstempel.
Erst, wenn das der Fall ist, dann Zeitstempel.
> Da der Master ja mehrere Sensormodule abfragen soll, darf ein Fehlen
> von Daten eines Moduls nicht zur Blockierung des Systems führen.
Meinst du in etwa so (stark vereinfacht): Daten fehlen -> Ja ->nochmal Abfragen (evt 3mal) -> Daten fehlen noch immer -> dann nächsten Sensor abfragen,...
Also eine Art Quittierungsverfahren, genauso wie wenn Daten fehlerhaft (CRC nicht bestanden, nochmal senden)
Das einzige, was ich noch gehört habe, dass wir noch einen Zeitstempel bräuchten ist, weil wir ja die Daten mittels Kurven in Fenstern z.B untereinander darstellen müssen (so ähnlich wie in der Oberfläche von Ozzy's LinK). Da die Daten also Zeitgleich dargestellt werden müssen, obwohl sie's in Wirklichkeit nicht sind, weil diese Unterschiedlich "schnell" sind und nacheinder reinkommen, brauchen wir einen Zeitstempel, um das ganze so zu realisieren zu können.
Das mit dem Zähler ist eine gute Idee, man muss einfach nur improvisieren können -> so viel zu Effizient!
Nur falls dass mit dem Zeitstempel bezogen auf die Darstellung richtig ist, würde das dann auch mit dem Zähler realisierbar sein??
Sorry, ich bin halt leider auf dem Gebiet ein totaler Anfänger. Eigentlich traurig nach 3 Jahren Schule, aber is halt so, so viel zu dem, was wir bis jetzt gelernt haben!
Oder Denk ich am Anfang vielleicht schon viel zu weit???
Ich wäre für weitere Hilfe auf jeden Fall dankbar!
LG Jörn
Hi Jörn,
grundsätzlich, da Dir schon zweimal Deine Schreibarbeit in die Tüte gehüpft ist, editiere doch den Text im Editor wie notepadkate oder sonstwas und wenn Du fertig bist, kopierste es ins Browserfenster :-)
ui .. viel zu lesen .. grad nicht genug Zeit, nur ein paar kleine Vorantworten:
> einen richtigen Professionisten geraten
nun, ich kann besser Westernreiten als Professionell sein, aber ich übe beides :-) ... Ich gehör halt noch zur "Alten Schule" die wissen, daß bei Windoof nur gutverpackte WM_MESSAGES geschickt werden ... salopp ausgedrückt. Ich vertreib eine Sonnenstudiosoftware, aber mein Klientel stirbt finanziell aus. Vielleicht sagt Dir in Wien u.a. ja MAGICSUN was ...
>>> Solange Du nicht Asm aufm uC machst, ist C die bessere
>>> Wahl, weil Du richtig schöne Fehler machen kannst, die
>>> Dir Basic verwehrt
> ...ich schreib einen C-Code, funktioniert nicht und kontrolliere
> dann im Assembler, wieso. Das zu lernen, war zwar nicht
> einfach, aber es zahlt sich aus, z.B. bei Laufzeitfehlern.
gut .. wie gesagt C auf dem uC das einzig Wahre in meinen Augen, wenn man nicht direkt alles in ASM macht, was ich noch zu Zeiten des 8051 gemacht habe, aber nimmer will.
Auf PC-Ebene ist ein KlickiBunti-Developement normal (BorlandBuilder, Delphi, VB, VC) .. nur daß eben C Dir die Möglichkeit läßt, effizienteren Code zu schreiben und eben alle Möglichkeiten offen läßt, was nicht unbedingt ein Vorteil sein muß. C++ ist in meinen Augen nur ein Overlay, daß in einigen Bereichen viele Vorteile bringt, in einigen wie den uCs eben nicht !
Ärgerlich ist, das MS-Produkte eine starke Produktbindung haben, SQL-Server muß dann von MS sein etc. ... hat Vorteile und Nachteile ... ist aber ein anderes Thema.
Zum Filterdesign .. da erinnere ich mich an FFT, LaPlace und vieles mehr .. aber nachdem Studium nie eingesetzt, geübt oder vertieft ... also keine Ahnung mehr.
Über die Bauds denke ich nochmal nach ... stimmt schon, daß der Overhead auch noch mitübertragen werden muß: 8N2-typisch, aber wirklich viel ist das nicht, bezogen auf den Datenstring der übertragen wird.
> 1 Frame besteht aus z.B. 23Bit, also müssen alle Bits dieses
> Frames mittels den 19200 übertragen werden.
jepp ...
> > Der Master muß die einzelnen Slaves nacheinander abfragen - folglich
> > müssen die Slaves Werte zwischenspeichern ...
> Wenn ich dass richtig verstanden habe, ist das bei Protokollen immer
> so, weil die Daten ja seriell Übertragen werden, folglich kann
> der Master nicht mehrere Slaves parallel abfragen???
Ein Protokoll ist nur eine Festlegung, wie der Datenübertragunsablauf (Inhaltlich und zeitlich) funktionieren soll. Der ders entwickelt, erfindest ... :-) Mehr ist das nicht.
In Eurem Fall liefert der EKG-Module die meisten Daten .. drum sollte das Mdoul oft abgefragt werden .. und immer wenn nicht die EKG -Abfrage ansteht dann eben immer wieder eines der anderen Module .... je nachdem was das EKG-Timing zuläßt ...
> Wenn ich das richtig verstanden hab, was du meinst, ist, dass
> die restlichen Daten von den anderen Sensoren Datenwerte in
> viel größeren Zeitabständen liefern müssen (z.B.
> Atemfrequenz/min: 12-40, T=0,2 - 0,6s) und zwischengespeichert
> werden müssen, weil sie ja erst später abgefragt werden, aber
> was hat das mit Langsameren und schnelleren Daten zu tun???
nochmal - zeitkritisch ist die Datenmenge vom EKG-Modul und begrenzt wird es durch die maximale Übertragungsrate .. also zähl die Bytes an Informationen und dann guck was durchs Nadelöhr paßt ...
> Ich kann nicht sagen, dass ich wirklich C programmieren kann.
> Pointer sind mir daweil auch noch ein fremdes Dorf, aber ich
> möchts lernen und ich persönlich finde C auch besser (vielleicht
> auch, weil ichs gewohnt bin, Syntax,..). Nur ich weiß halt leider
> nicht, warum C, C++ effizienter gegenüber VB ist.
Nun es ist nur ein Handwerkszeug .. das Klickibunti-Ergebnis ist ein Funktionsaufruf - Overhead .. und was dann passiert, wird von Hand codiert ... eben in Basic, C, C++, Pascal, oder was auch immer.
C läßt einem die meisten Freiheit, Fehler zu machen ...
In C kannste sowas machen
char *pbuffer = new char [50];
void funki(int _hugo)
{
strcpy(pbuffer,"%s (%d)", _hugo > 0 ? "großer Hugo" : _hugo < 0 ? "kleiner hugo" : "kein hugo", _hugo);
}
in basic geht das wohl nicht in einer Zeile ...
> Abschitt ...
> Also eine Art Quittierungsverfahren, genauso wie wenn Daten
> fehlerhaft (CRC nicht bestanden, nochmal senden)
genau so
Je nachdem wieviel Platz zur Datenübertragung Du hast, kann es sinvoller sein, einen Zähler zu nutzen und diesen zu versenden, Du weißt als Sender ja, wann Du abgefragt hast, daß muß nicht über funk hin- und wieder zurück übermittelt werden - so reicht einzähler zur Kontrolle ! Idee verstanden ?
Zur Synchronisations der gleichzeitigen Werte hast Du natürlich recht ... da könnte der master also jede Minute einen Zeitimpuls vorgeben und plus Zähler die Zeit erhalten ...
.. kommt eben auf die Datenmenge an, die übertragen werden soll .. je wejniger Overhead, desto besser ...
So, hoffe mein geschreibsel hilft, echt viel Text .. und mach grad paar Sachen gleichzeitig ...
Vajk
Hi Vajk
Vielen Dank für die flotte Antwort!
Is mir ziemlich peinlich, hab sie erst viel später bemerkt, hab ja auch Arbeit (sicher nicht so eine Anspruchsvolle wie Du, aber trotzdem) und ich will dich auch nicht für mich allein beanspruchen, du hast sicher wichtigeres zu tun! O:)
Antworte mir einfach, wenn Du Zeit und Lust hast, so dringend ist es auch wieder nicht und wie gesagt, ich bin Dir äußerst dankbar, das du dich meiner annimmst ! Hoffe Du bereust es nicht, ich bin nämlich manchmal leider nicht einfach weil ich leider oft viel zu kompliziert denke! :lol:
> grundsätzlich, da Dir schon zweimal Deine Schreibarbeit in die Tüte
> gehüpft ist, editiere doch den Text im Editor wie notepadkate oder
> sonstwas und wenn Du fertig bist, kopierste es ins Browserfenster :-)
Hab ich dann eh gemacht, Danke trotzdem!
> ui .. viel zu lesen .. grad nicht genug Zeit, nur ein paar kleine Vorantworten:
Kein Problem!
> nun, ich kann besser Westernreiten als Professionell sein, aber ich übe
> beides :-) ... Ich gehör halt noch zur "Alten Schule" die wissen, daß bei
> Windoof nur gutverpackte WM_MESSAGES geschickt werden ... salopp
> ausgedrückt. Ich vertreib eine Sonnenstudiosoftware, aber mein
> Klientel stirbt finanziell aus. Vielleicht sagt Dir in Wien u.a. ja
> MAGICSUN was ...
Das ist meistens eh besser, früher hat man sicher noch wesentlich mehr gelernt als heutzutage und da gab es wahrscheinlich auch noch nicht so viele Tools, die einem das Leben bzw programmieren leichter machen sollten, aber es eh nicht tun! Ich schätz mal, dass man früher sich noch richtig mit der Materie Computer hat auseinandersetzen müssen (einen Computer halt wirklich "verstehen"). Und Speicher u. a. Ressourcen gab es auch nur beschränkt, also musste man effektiv programmieren, was sicher nicht schaden kann. Heutzutage ist das meiner Meinung nach nur mehr ein irgendwas programmier ich halt (bestes Beispiel: Microschrott !), und wenn die Kapazitäten nicht ausreichen, dann nehemen wir halt eine leistungsfähigere Maschine (der dumme Kunde wirds schon kaufen) !
WM_MESSAGES -> Sorry keine Ahnung, was das ist. Hat das was mir Windoof-Programmierung zu tun???
Sicher kenn ich MAGICSUN. Schade, das tut mir leid für dich, hoffe Du hast dafür noch genügend andere Kundschaft. Selbständigsein ist halt leider nicht so einfach, aber wenn ich mal jemanden kenn, der einen programmierer braucht, werd ich als erstes an Dich denken!
> gut .. wie gesagt C auf dem uC das einzig Wahre in meinen Augen,
> wenn man nicht direkt alles in ASM macht, was ich noch zu Zeiten des
> 8051 gemacht habe, aber nimmer will.
Assembler würd ich auch gern können, ist sicher die beste Alternative für nen µC, aber... eh schon wissen!
Darum schreibt man ja (normal) ein Gemisch aus C und Assembler (für die laufzeitkritischen Anwendungen), so habs ichs halt gehört, kling auf jeden Fall sinnvoll!
> Auf PC-Ebene ist ein KlickiBunti-Developement normal (BorlandBuilder,
> Delphi, VB, VC) .. nur daß eben C Dir die Möglichkeit läßt, effizienteren
> Code zu schreiben und eben alle Möglichkeiten offen läßt, was nicht
> unbedingt ein Vorteil sein muß. C++ ist in meinen Augen nur ein
> Overlay, daß in einigen Bereichen viele Vorteile bringt, in einigen wie
> den uCs eben nicht !
Sicher, man kann auch mit falschen Programmieren Dinge aus dem Lot bringen, milde ausgedrückt. Bestes Beispiel: Pointer!
Hoffe Du meinst das gleiche.
> Ärgerlich ist, das MS-Produkte eine starke Produktbindung haben, SQL-Server
> muß dann von MS sein etc. ... hat Vorteile und Nachteile ... ist aber ein
> anderes Thema.
Naja, fast alle haben heutzutage (leider) Windoof auf den Rechnern.
Und erklär mal einen absoluten DAU, der grad mal weiß wie man einen PC einschaltet, das der dann Netframework usw braucht, um ein Programm überhaupt ausführen zu können. -> Totale Überlastung, aber für den USER!
Und grad Programme, die man z.B. in VB2005 programmiert, basieren auf diese Tools und sind ohne die gar nicht ausführbar. Mein Kollege sieht aber das gar nicht ein und meint, dann braucht mans halt, wie gesagt, Sturschädel!
Apropro, wegen Datenbanken und Co: Wie ist eigentlich SQL, ist das etwas besser als Access (was wahrscheinlich auch nicht schwer ist)?
Was bietet Codebase für Vorteile? Ich bin leider in Sachen Datenbanken ein totaler Anfänger und kenn mich damit natürlich auch überhaupt nicht aus. In der Schule haben wir auch noch NICHTS über Datenbanken gelernt.
>Zum Filterdesign .. da erinnere ich mich an FFT, LaPlace und vieles
> mehr .. aber nachdem Studium nie eingesetzt, geübt oder vertieft ...
> also keine Ahnung mehr.
macht nix! Wie gesagt, brauchen wir für unseren Teil der Dipl.-Arbeit eh nicht (Gott dei Dank!). Damit müssen sich EKG & Co-Partie rumärgern! *HEHE, Gemein bin*
> Über die Bauds denke ich nochmal nach ... stimmt schon, daß der
> Overhead auch noch mitübertragen werden muß: 8N2-typisch, aber
> wirklich viel ist das nicht, bezogen auf den Datenstring der übertragen wird.
Ok, Danke! Wenn Du überlegen mußt, heißt das was!
Das Modul überträgt im Normalmodus auf jeden Fall 8N2, mann kann aber Parity und/oder 2 Stoppbits auch einstellen. Kein Softwarehandshake, das bringt das Modul durcheinander, Ergebnis: falsch übertragene Daten. Hab ich bereits ausprobiert!
Hardwarehandshake is möglich und grad bei dem Modul auch sinnvoll, sonst müsste man sich bezüglich CTS mit unnötigen Warteschleifen rumspielen.
Das FM kann Byteweise übertragen, indem man mind nach jedem (oder der gewünschten Anzahl von Bytes) eine 2Bytezeiten lange Pause einfügt. Is aber glaub ich eh Standard.
Das ist, glaub ich, sicher sinnvoll, weil das FM hat nämlich nur einen 180Byte großen (kleinen) Buffer, d.h. wenn dieser voll, Daten werden abgeschickt und nachkommenden Daten gehen verloren, solange Modul mit senden beschäftigt ist (-> CTS!)
Das Frame kann ich mir selber zusammenstoppeln. Entweder als Array und/oder mittels 2Bytezeiten Pause zw. den Frames. Hoffe, ich lieg mit meinen Gedankengang richtig.
> > Der Master muß die einzelnen Slaves nacheinander abfragen - folglich
> > müssen die Slaves Werte zwischenspeichern ...
> Ein Protokoll ist nur eine Festlegung, wie der Datenübertragunsablauf
> (Inhaltlich und zeitlich) funktionieren soll. Der ders entwickelt,
> erfindest ... :-) Mehr ist das nicht.
> In Eurem Fall liefert der EKG-Module die meisten Daten .. drum sollte
> das Mdoul oft abgefragt werden .. und immer wenn nicht die EKG
> Abfrage ansteht dann eben immer wieder eines der anderen Module ....
> je nachdem was das EKG-Timing zuläßt ...
> Wenn ich das richtig verstanden hab, was du meinst, ist, dass
> die restlichen Daten von den anderen Sensoren Datenwerte in
> viel größeren Zeitabständen liefern müssen (z.B.
> Atemfrequenz/min: 12-40, T=0,2 - 0,6s) und zwischengespeichert
> werden müssen, weil sie ja erst später abgefragt werden, aber
> was hat das mit Langsameren und schnelleren Daten zu tun???
nochmal - zeitkritisch ist die Datenmenge vom EKG-Modul und begrenzt wird es durch die maximale Übertragungsrate .. also zähl die Bytes an Informationen und dann guck was durchs Nadelöhr paßt ...
OK, Danke! Jetz is es mir klar, was du meinst! Bezüglich dessen wäre es sicher mal sinnvoll. eine Timingtabelle aufzustellen.
So eine Gedankengang haben, ich (wir) eh schon gehabt, nur bin ich mir meiner immer so unsicher.
Nur wie man (ich) so was programmiert, ist mir allerdings ein Rätsel.
> Nun es ist nur ein Handwerkszeug .. das Klickibunti-Ergebnis ist ein
> Funktionsaufruf - Overhead .. und was dann passiert, wird von Hand
> codiert ... eben in Basic, C, C++, Pascal, oder was auch immer.
Alles klar!
> C läßt einem die meisten Freiheit, Fehler zu machen ...
Sehr kritisch, aber ich bin mir sicher, du weißt von was du redest!
Ich kann da leider nicht mitreden, und wenn ich behaupten würde, das ich Programmierer bin, dann wäre das gelogen.
In C kannste sowas machen
char *pbuffer = new char [50];
void funki(int _hugo)
{
strcpy(pbuffer,"%s (%d)", _hugo > 0 ? "großer Hugo" : _hugo < 0 ? "kleiner hugo" : "kein hugo", _hugo);
}
in basic geht das wohl nicht in einer Zeile ...
Glaub ich auch!
Hab verstanden, was Du bezüglich Effizienz meinst: Weniger Codezeilen, direkte Sprünge,.. -> weniger Rechenarbeit und/oder Speicheraufblähen! Genauso wie beim µC, wo mans auch nötig hat, der hat keine 2GB RAM u. 3GHz Taktfrequenz! Aber bin mir sicher, wenn man für den PC effizient programmiert, kanns auch nicht schaden!
Kann man eigentlich in VB mit Pointern arbeiten???
Mein Kollege ist der Meinung: Ja.
Nur ich weiß es nicht und kanns mir aber auch ehrlich gesagt nicht vorstellen.
> Je nachdem wieviel Platz zur Datenübertragung Du hast, kann es
> sinvoller sein, einen Zähler zu nutzen und diesen zu versenden, Du
> weißt als Sender ja, wann Du abgefragt hast, daß muß nicht über funk
> hin- und wieder zurück übermittelt werden - so reicht einzähler zur
> Kontrolle ! Idee verstanden ?
Jepp! Auf so was muss man mal kommen!
> Zur Synchronisations der gleichzeitigen Werte hast Du natürlich
> recht ... da könnte der master also jede Minute einen Zeitimpuls
> vorgeben und plus Zähler die Zeit erhalten...
> .. kommt eben auf die Datenmenge an, die übertragen werden soll .. je
> wejniger Overhead, desto besser ...
Is klar, wie im detail alles abläuft und welche Methode dann am sinnvollsten bzw wirkungsvollsten ist, wird sich dann sicher weisen!
Nur im Moment fehlt mir halt, so wie fast immer, komplett der Ansatz.
> So, hoffe mein geschreibsel hilft, echt viel Text .. und mach grad paar
> Sachen gleichzeitig ...
Wie gesagt, hast sicher wichtigeres zu tun! Aber trotzdem, vielen Dank, dass du mir trotz anderen Arbeiten so flott antwortest (im Gegensatz zu mir *peinlich*).
Mir hilft auf jeden Fall im Moment jede noch so kleine Information, und dein "geschreibsel" auf jeden Fall!
Also, bis ???
Schönen Abend,
Gruß aus Wien, Jörn
PS: Blöde Frage noch bitte:
Wie machst du das eigentlich, mit den > Mein/Dein Text und darunter dann halt deine Antwort? Ich habs bis jetzt leider noch nicht rausgefunden und bin noch nicht so lang im Forum.
Hab bis jetzt immer die> manuell eingetragen, aber es gibt da sicher eine automatisierte Methode, oder???
Hi Jörn,
ist schon gut .. viel Text immer, für son armes kleines Hirn :-) Aber als Pause beim Layouten, was ich grad mache ...
Kleine Bitte, wenn Du Fragen soweit ich helfen kann, gerne :-) Bin auch nur ein Fachideot, allerdings auf allen 3 Schichten eines Projekts, da selbst und das ständig :-)
> ... Tools und früher
ja,hmm ... eben in den Windoof-Anfängen zu denen ich auch erst später gestoßen bin, gabs auch nicht viel Werkzeug und Hilfe .. ich hatte das Glück, nachdem mich die Borland-Hotline als Freak abgestempelt hatte "Das ist nicht Standard, was sie machen, da können wir ihnen nicht helfen" , einen Geschäftsfreund zu finden, der super fit war, ein typischer Code-Hacker, den wenn man ihn ansprach, erst nach einer Zeit antwortete, und er eben IDLE war :-)
Der hat mir sogar damals geholfen, einen Fehler aufzuspühren, der darin gründete, daß in einer Borlandbibliothek ein statisches Array unterdimmensioniert war ... argl ...
>> WM_MESSAGES
> Sorry keine Ahnung, was das ist. Hat das was mir mit
>Windoof-Programmierung zu tun???
Yepp .. die unterste Windoof-Schicht - vermute mal in VB wird man die nie sehen ... aber wissen will ichs auch gar nicht ....
> Sicher kenn ich MAGICSUN. Schade, das tut mir leid für dich,
> hoffe Du hast dafür noch genügend andere Kundschaft.
nicht wirklich, als Oldtimer (mit 44) ist man nicht so fit auf Neumodischen und als strikter Gegner von MS-Nutzung wird die Luft dünn.
> der einen programmierer braucht, werd ich als erstes an Dich denken!
Danke !!!!!!
> Darum schreibt man ja (normal) ein Gemisch aus C und
> Assembler (für die laufzeitkritischen Anwendungen), so
> habs ichs halt gehört, kling auf jeden Fall sinnvoll!
bisher gings mit reinem C, Ablaufoptimiert ... aber wie gesagt, Zeh ist eh ein MacroAssembler :-)
> Bestes Beispiel: Pointer!
Jepp ... allgemeiner der Speicherüberblick .. ich liebe sprintf und dessen Geschwister ... aber wehe das Array ist zu klein ;-) Böse Fehler.
> Apropro, wegen Datenbanken und Co: Wie ist eigentlich SQL, ist
> das etwas besser als Access (was wahrscheinlich auch nicht
> schwer ist)?
Access .. -> rotes Tuch, da MSkotz.
SQL via MySQL unter Linux ist schön flott und bei mir aufm Server stabil .. und php ist eine schöne C-Erweiterung mit einigen Erweiterungen, die einem das Leben erleichern ... aber auch ein anderes Thema.
> Was bietet Codebase für Vorteile?
Nun Codebase ist eine alte dBase kompatible datenbankschnittstelle, weiß gar nicht, obs die noch zu kaufen gibt. Was damals die beste Wahl, wenn man keine horenten Lizenzgebühren zahlen wollte ....
Um das dB-Handling hab ioch mir einen OO-Mantel gebaut - im Prinzip nutze ich nur das dBase-Format gerne - abe nutze es ganz und gar nicht nach Standard. Mal lieber nicht ausufern tu ...
Klarer Vorteil - eine DLL und gut is - nix Server einrichten und verwalten müssen .... alles in einem Verzeichnisbaum zu handhaben .. bzwgl. Backup, Reorg, Reperatur etc. Aber SteinzeitDB !
> >Zum Filterdesign .. da erinnere ich mich an FFT, LaPlace und vieles
> > mehr .. aber nachdem Studium nie eingesetzt, geübt oder vertieft ...
> > also keine Ahnung mehr.
> macht nix! Wie gesagt, brauchen wir für unseren Teil der Dipl.-Arbeit
> eh nicht (Gott dei Dank!).
Doch - nächstes Jahr wirds schon kommen :-)
> Das Frame kann ich mir selber zusammenstoppeln. Entweder als
> Array und/oder mittels 2Bytezeiten Pause zw. den Frames. Hoffe,
> ich lieg mit meinen Gedankengang richtig.
Vielleicht .... grübel ... weiß nicht.
> > > Der Master muß die einzelnen Slaves nacheinander abfragen - folglich
> > > müssen die Slaves Werte zwischenspeichern ...
> > Ein Protokoll ist nur eine Festlegung, wie der Datenübertragunsablauf
> > (Inhaltlich und zeitlich) funktionieren soll. Der ders entwickelt,
> > erfindest ... :-) Mehr ist das nicht.
> > In Eurem Fall liefert der EKG-Module die meisten Daten .. drum sollte
> > das Mdoul oft abgefragt werden .. und immer wenn nicht die EKG
> > Abfrage ansteht dann eben immer wieder eines der anderen Module ....
> > je nachdem was das EKG-Timing zuläßt ...
> > Wenn ich das richtig verstanden hab, was du meinst, ist, dass
> > die restlichen Daten von den anderen Sensoren Datenwerte in
> > viel größeren Zeitabständen liefern müssen (z.B.
> > Atemfrequenz/min: 12-40, T=0,2 - 0,6s) und zwischengespeichert
> > werden müssen, weil sie ja erst später abgefragt werden, aber
> > was hat das mit Langsameren und schnelleren Daten zu tun???
> > nochmal - zeitkritisch ist die Datenmenge vom EKG-Modul und
> > begrenzt wird es durch die maximale Übertragungsrate .. also
> > zähl die Bytes an Informationen und dann guck was durchs
> > Nadelöhr paßt ...
> OK, Danke! Jetz is es mir klar, was du meinst!
> Bezüglich dessen wäre es sicher mal sinnvoll. eine
> Timingtabelle aufzustellen.
genau das meinte ich ...
1. die Übertragungsrate ist begrenzt
2. ermittle was an relevanten Daten übertragen werden muß
3. packe die Datenübertragung in entsp. Pakete
> Nur wie man (ich) so was programmiert, ist mir allerdings ein Rätsel.
Nun, dieses Rätsel gilt es zu lösen.
Ansatz . .. Tischtennis - Ping - Pong
ich habs so gelöst:
- via Timer wird ein PingPongFlag gesetzt
- wenn PingPongFlag > 0, Funktionsablauf nicht anspringen, außer wenn Zeitlimit überschritten -> Übertragung gescheiert, entsp. reagieren
- Abfrage Master an Slave, PingPongFlag += 10
- Antwort von Slave an Master, auswerten, PingPongFlag += 10 (also der nächste Schritt)
- Wenn das Spiel: Senden - warten auf Antwort - Reaktion - neues Senden - Antwort .. etc. fertig ist, dann wird PingPongFlag wieder auf 0 gesetzt .. nächste Spiel kann beginnen ...
Wie machste das ... mit globaler Variable und switch/case Abarbeitung je nach PingPongFlag
Wenn Du das verstanden hast, ists klar warum ich es PingPong nenne.
Tipp .. lies mal nach, was Semaphoren sind und wie man sie nutzt.
Das ganze kann ich Dir nicht abnehmen - aber stell mal Deine Überlegungen rein, dann sehen wir schon ...
> > C läßt einem die meisten Freiheit, Fehler zu machen ...
> Sehr kritisch,
Nix kritisch .. schwere Lernphase, am Anfang waren es 10 % Code schreiben .. 90 % Debuggen - heute bin ich bei 90 % Code schreiben und 10 % Debuggen ... wobei das Debuggen vornehmlich zur Qualitätssicherung stattfindet ... ABER es gibt Ausnahmen zur Vermehrung der Grauen Haare ;-)
> Hab verstanden, was Du bezüglich Effizienz meinst:
> Weniger Codezeilen, direkte Sprünge,..
Genau .. und wenn Du die Hieroglyphen des Zeh lesen kannst, ist das ganze Übersichtlicher, weil eben weniger Text !
Bei einem großen Projekt unabdingbar.
UND natürlich Maschinencode näher, je nachdem was für einen Stil Du Dir angeeignet hast und wie maschninennah Du denkst.
A pro pos - großes Projekt - "grep" ist für mich die einzigste Möglichkeit, mich in meinen Projekten auch nach Jahren wieder zurecht zufinden ....
> Aber bin mir sicher, wenn man für den PC effizient programmiert,
> kanns auch nicht schaden!
Exakt !
> Kann man eigentlich in VB mit Pointern arbeiten???
> Mein Kollege ist der Meinung: Ja.
Keine Ahnung - will ich auch gar nicht wissen :-)
> Nur im Moment fehlt mir halt, so wie fast immer, komplett der Ansatz.
Hmmm .. Ansatz siehe oben ...
Und dann schrittweise reinarbeiten ... ist wie das Modellieren eines Reliefes oder das malen eines Bildes .. zum Anfang hab ich eine Idee was es werden soll und freu mich, wenns gelingt ...
> Wie gesagt, hast sicher wichtigeres zu tun!
weiß nicht, was wichtig ist ... packe das nicht auf eine Waagschale. Denn jemandem zu helfen ist die beste Methode, selbst zu lernen.
> Wie machst du das eigentlich, mit den > ...
MEGALOOOLOLLOLOLOLOL KICHERWECHWIEERBSE
> ... eine automatisierte Methode, oder???[/quote]
nö !
Einfach nur schnelle Finger .. war mal Op in einem Chat .. da lernt man auch als Programmierer schnell zu tippen ..
Also viel Erfolg und gute Ideen,
Vajk
Hallo Jörn,
bist Du umgefallen oder imUrlaub ?
LG
Vajk
Hallo Vajk!
Danke der Nachfrage!
Ich wollte mich sowieso melden, da ich schon ein schlechtes gewissen hab, weil ich mich eben schon länger nicht mehr gemeldet hab.
Eigentlich bin ich beides, Urlaub, aber nur zu Hause und Umgefallen, weil ich mich in Sachen Projekt wahrsceinlich viel zu sehr zerdenke und ich einfach auf keinen vernünftigen Ansatz komme!
Über Semaphoren hab ich mich erkundigt, ist im Prinzip etwas, was ich brauchen kann, nur verstanden hab ichs halt nur teilweise, so wie alles.
Das ist eigentlich mein Hauptproblem bei der ganzen Sache.
Stelle eine Timingtabelle auf und häng dann nauf einmal und weiß nimmer, wo ich weiter machen könnte.
*Verzweifelntu*
Entwedert ich bin einfach zu blöd für das ganze oder keine Ahnung was.
LG, Jörn
Hey hey,
also am Einfachsten in kleine Scheiben zerhacken.
In dem Thread hab ich meinen ping-pong-Gedankengang nochmals beschrieben ...
https://www.roboternetz.de/phpBB2/viewtopic.php?p=199273#199255
Auch Dir kann ich anbieten, mich mal anzurufen ...
LG
Vajk
Hallo, Vajk!
Ich glaub, jetzt hab ichs!
Danke für den Treat!
Du nimmst die gV u.a. zur Abarbeitung der verschiedenen Prozess zw Master und Slave, den Timer muss man Zeitmäßig auf die Länge der Übertragungsroutine setzen.
Wegen anrufen, gerne!
Müßten wir halt mal Nummern austauschen!
Vielen Dank daweil!
LG, Jörn
Zum Timer .. ich wähle da nur einen Timer mit einem sinnvollen Wert ... z.b. alle 2usec ... die Unterteilung mach ich über einzelne Variablen, die hochgezählt werden und nach Überschreiben eines gewünschten Schwellwerte, wieder auf 0 gesetzt werden .. oder 1, wenn 0-Wert als Schalter fungieren soll .. statt 0 auch -1 oder was auch immer ... UND ein entsp. Flag gesetzt !
Durch entsp. Verändern des Schwellwertes kann auch für Schrittmotoren eine Beschleunigung geregelt werden ....
Durch die Vorgehensweise können auch Tasten entprellt oder mit kurz- und langer gedrückt - Auswertung versehen werden ... oder auch das DCF77-Signal abgetastet werden ....
Die Flags werte ich dann in der entsp. Hauptroutine (nicht im Interrupt) aus ... wobei ein Teil der Auswertung natürlich im Interrupt passieren kann (Flag wird erst nach Entprellzeit gesetzt, oder eben der Impuls für den Schrittmotor, damit die Kontinuität der Impules gesichert ist) ...
Alles klar ?
LG
Vajk
sorry, aber wieder alle klarheiten beseitigt!
>>> Wenn 10, dann Daten in Sendebuffer übertragen und Sendevorgang starten, gV auf 11.
Wenn Daten abgesendet, dann gV auf 12 setzen. Wenn 12, dann via Timer eine Abruchvariable (fürs Timeout) hochzählen.
Wenn jetzt ein ack (Empfangsbestätigung der Gegenseite) kommt) wird gV auf 13 gesetzt.
Wenn 13, dann Timeout löschen und gV = 14.
Wenn 14, dann job fertig, gV auf 0.
Wenn Daten reinkommen, dann gV auf 20,
wenn Daten fertig gV auf 25.
Wenn 25, dann Daten auswerten,
....
ich kapier den sinn, bezogen auf die 2µs im zusammenhang mit der protokollprozedur nicht. was bezwecken dort 2µs??
und der begriff timeout ist mir im moment auch ein rätsel.
lg, jörn
ps: hab ja gesagt, ich bin anstrengend!
https://www.roboternetz.de/phpBB2/viewtopic.php?p=199366#199366
irgendwie ähneln die beiden Projekte sich ... guck Dir den Beitrag von mir bitte auch nochmal an ...
nun und ich lerne mich besser auszudrücken .. die 2 us sind als beispiel für eine Timer einstellung, wann eben ein Timer-Interrupt durch ÜBerlauf ausgelöst werden soll .. mehr nicht.
Zum Beispiel oben, wird wenn 12, dann z.b. eine abbruchzahelvariable in der Timer-Interrupt-Routine hochgezählt. wenn diese 500 erreicht, wird er abbruckcounter um 1 erhöht ... wenn dieser Abbruchcounter dann bei 5 steht, gilt das als timeout ...
also in dem zahlenbeispiel (und wenn ich richtig gerechnet habe) nach 5 msec ... das muß natürlich zur Übertragungsrate und der zu übertragenen Datenmenge passen !!
Timeout: das ist ein Zeitpunkt, in dem eine erwartete Antwort der Gegenseite hätte erfolgen müssen. Der Zeitraum bis dahin muß natürlich groß genug gewählt werden.
Sinn und Zweck ist es, daß das Programm eine Chance bekommt, auf eine nichterfüllung einer Annahme zu reagieren ... so daß nicht gV immer auf 12 bleibt und somit dein Prozess hängt.
Jetzt verstanden ?
Hallo Vaijk!
Danke erstmal für das ausführliche Telefonat von gestern!
Die Ansätze hätt ich ja mal grundlegend verstanden.
Aber....
Mein Hauptproblem liegt eindeutig in: wie programmiert man sowas.
Ich weiß, programmieren lernt man nicht in 3 Tagen (Wochen) und ich will auch nicht einfach auf: ich brauche mal schnell einen Code für dies oder jenes.
Was mir aber z.B. Kopfzerbrechen macht:
Mein Lieblingsfeind Protokoll:
#<ID-Sender><ID-Empfänger><Datenlänge><Daten>#<Prüfsumme>
Ich will den Programmteil für ID-Sender und Empfänger entwerfen.
Frage 1: ID-Sender (Empfänger): ist das dann jeweils eine eigene Funktion???
Falls ja, nach was oder wie vergeb ich die ID.
Die ID ja dann im Protokoll nix anderes als z.B. 0x01, 0x02,...
Nur ich kann mir in aller Welt nicht vorstellen wie ich diese ID z.B meinem Master vergebe (programmiere).
Wie sagt man, du bist Master mit ID 0x01, du bist Slave (von mir aus EKG) mit der ID 0x02????
Ob ich jemals zu sowas fähig bin zustande zu bringen, bezweifle ich langsam, weil bei mir scheiterts ja schon an den grundlegenden Dingen.
Vielleicht bin ich im Moment etwas negativ eingestellt, aber ein Problem lösen ohne die die geringsten Grundkenntnisse und nach Stunden- (Tage-) langen erfolglosen Googeln kann mich leider nicht besonders motivieren.
In diesem Sinne, schönes WE,
Gruß Jörn
das TGM in Wien Ahhh, ein Feind ^_^. Nö, Scherz, ich studiere dann nur so ungefähr 1km von dir Weg (Technikum Wien) :). Kenn das Problem mit'm "So und nun löst schön mal dieses Problem" nur zu genüge (auch wenn ich noch nicht bei meiner Dimplomarbeit sitzte...
>Frage 1: ID-Sender (Empfänger): ist das dann jeweils eine eigene Funktion???
>Falls ja, nach was oder wie vergeb ich die ID.
>Die ID ja dann im Protokoll nix anderes als z.B. 0x01, 0x02,...
>Nur ich kann mir in aller Welt nicht vorstellen wie ich diese ID z.B meinem Master vergebe (programmiere).
>Wie sagt man, du bist Master mit ID 0x01, du bist Slave (von mir aus >EKG) mit der ID 0x02????
Die ID eine eigene Funktion? Die ID,die du da bekommst ist ein Byte, eine Zahl. Also jein, du kannst eine Funktion schreiben, die das ID des Empfängers (Senders) vor dem Senden generiert und diesen in den Frame packt, beziehungsweise diesen Byte aus dem Frame extrahiert und ihn mit der eigenen ID gegenprüft. Ist aber meiner Meinung nach nicht zwingend notwendig.
Also am einfachsten wäre es, wenn du die ID als Konstante fest in den µC reinprogrammierst. Danach würde der Master zum Beispiel die ID 0x01 haben, die EKG vllt. 0x02, der nächste 0x03 und so weiter. Wenn jetzt der Master etwas an den EKG-Slave sendet, schreibt er halt als erstes Byte "0x01" in den FM, anschließend "0x02" und danach die wirkliche Nachricht.
Interessant ist noch die Idee, dass der Master die IDs der Slave nicht fest hineinprogrammiert hat, sondern beim Starten auf alle IDs ein "Hallo, bist du da?"-Message (=Ping) schickt. Der Slave antwortet danach mit seiner Funktion (also halt ob EKG, Atmungsmesser, etc.) und der Master speichert diese ab. Hat seine Vorteile (wenn du z.B.: einen neuen Slave einfügst, musst du nur einen neuen "Funktionsteil" in dem Master einfügen und dass, der Master nicht stockt, wenn du zum Beispiel den Atmenfrequenz-Slave nicht einschaltest, Nachteil halt das Daten-Overhead beim Starten und der Programmieraufwand.
Halt, wenn du in C porgammierst ist das am Einfachsten mit einem define zu lösen, also halt "#define myID 0x01" und dann immer abfragen, ob die Empfangene ID gleich myID ist.
Hoffentlich war ich nicht zu verwirrend, wenn ja, dann bitte sagen und ich werd versuchen mich zu bessern ;)
MfG
Mobius
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.