www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP medizinische Datensätze


Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe ein Picdem Zigbee Demoboard und soll nun probieren, welche 
medizinischen Datensätze dort übertragen werden können. Es ist 
eigentlich eine theortische Arbeit über Zigbee in der Medizin, da es 
sich aber explizit um diese Picdem Board dreht, soll ich die 
Möglichkeiten testen. Mein Betreuer sagt, ich soll einfach mal 
Datensätze (EKG, EEG..etc.) simulieren und von einem Modul zum nächsten 
schicken. Wie mache ich das, ist meine aktuelle Frage. Ich dachte mir: 
Wenn ich ein EKG Signal abtaste, dann brauche ich etwas 200 HZ. Jetzt 
würde ich einen Sinusgenerator mit 200 HZ an dem AD Wandler des einen 
Picdem anschließen und übertragen. Auf der anderen Seite könnte ich dann 
doch einfach das Resultat ansehen. Aber wie kann ich das dann 
validieren? Oder gibts es eine bessere Alternative als mit dem 
Sinusgenerator?

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oih.

Picdem sagt mir zwar nichts, aber das ist eigentlich auch egal. Du 
brauchst die 200 Hz zum abtasten nicht. Der Picdem wird das Signal 
intern wahrscheinlich mit mehr als 200 Hz abtasten. Das ist also egal. 
Bei, sagen wir mal, 200 Schlägen pro Minute kommste auf grade mal 3,33 
Hz (Starkt vereinfacht). Wichtiger ist glaube ich eher, das die 
Datenübertragung fehlerfrei abläuft. Wenn ich annehme, dass ein 
Differenzverstärker für die Messung der Herzfrequenz genutzt wird, dann 
solltest du darauf achten, dass dessen Spitzenausgangsspannung nicht 
wesentlich kleiner ist als die Referenzspannung. Sonst könnten wegen der 
endlichen Auflösung (Volt/Bit) Informationen verloren gehen. Aber da du 
ja nur Datensätze simulieren sollst, kannst du einfach ein paar 
Bitmuster übertragen. Zb mal 0x0F oder 0xAA usw. Sind die ankommenden 
Bits richtig und keines ist verlorengegangen oder umgefallen, ist die 
Übertragung fehlerfrei.
Ich weiß nicht wie sensibel diese Daten sind, aber evt. solltest du dir 
Gedanken machen in welchem Code du die Daten überträgst und einen 
wählen, der eine Fehlererkennung und -korrektur erlaubt (Zb Hamming-Code 
oder einen anderen systematischen Code, bei dem du über des Syndrom 
Einbitfehler erkennen und korrigieren kannst).

tschöö

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal. Picdem z ist ein Demoboard mit MCU, Peripherie und Zigbee 
Transceiver. Ich soll wie gesagt eine eher theoretische Arbeit über 
Zigbee in der Medizin schreiben. Und dann soll ich testen welche 
Datensätze übertrabar sind.Ich soll also davon ausgehen dass die 
Datensätze für z.B. ein EKG vorliegen und die über Zigbee übertragen 
werden. Er sagte, "schließe doch einfach einen Sinusgenerator an den 
AD-Wandler des Boards an und schau dir das Resultat an". Mir iss nicht 
ganz klar was ich damit soll. Wahrscheinlich will er wissen wie 
echtzeitfähig dieses Picdem-Board diese Daten übertragen kann. Ich noch 
nicht besonders fit in Signatheorie oder MCU Programmierung, daher 
fehlen mir auch Ideen..

Autor: Gerrit Buhe (gbuhe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chris,

ich flechte ein:

> Ich habe ein Picdem Zigbee Demoboard und soll nun probieren, welche
> medizinischen Datensätze dort übertragen werden können.

Die Anforderungsanalyse ist schon recht dürftig. ;o)

Hier ist doch offensichtlich zu klären, welche Datenrate für die 
Übertragung von EKG, EEG,...-Datensätzen benötigt wird und welche 
Datenrate die Zigbee-Verbindung bietet. In diesem Zusammenhang ist 
ebenfalls über eine noch maximal akzeptierte Bitfehlerrate zu 
entscheiden, die ggf. eine Fehlerschutzkodierung erfordert und damit die 
zur Verfügung stehende Datenrate reduziert. Müssen nicht korrigierbare 
Daten erneut angefordert werden (erfordert Zwischenspeicher im 
Quellsender)? Wie ist die Echtzeitanforderung? Sie ist wahrscheinlich 
weniger kritisch, aber Du solltest das klären, z.B. <= 1s reicht aus.
Die nötige Reichweite hat natürlich ebenfalls Einfluß auf die 
Bitfehlerrate.

Dazu kommen die Anforderungen hinsichtlich Meßdynamik, -bandbreite, 
-genauigkeit, -linearität usw. der AD-Wandlung.

Ohne eine vernünftige Anforderungsanalyse bleibt alles nur eine nette 
Spielerei ohne Aussagekraft. Versuche doch einfach mal, die Punkte oben 
systematisch zu klären.

Viele Grüße und viel Erfolg!

Gerrit, DL9GFA

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Gerrit,

Er sagte ja er solle per AD-Wandler Signale messen. Wenn ich mir jetzt 
denke, dass ein normaler AD-Wandler 10-16 Bit Tiefe besitzt, die 
Datenübertragung seriell erfolgt und der Leitungscode zb der Hamming 
ist, komm ich so auf 13-19 Bits. Da kannste die Dauer der Übertragung 
bei 12MHz Taktfrequenz des Controllers, die Pufferung und Decodierung 
sowie die Fehlererkennung locker im ms Bereich einordnen (worst case).

Aber hast einige Dinge angesprochen, an die ich so auch nicht gedacht 
hätte :-)

- bla

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke zunächstmal für die Antworten!
Was meinst du mit -ms Bereich-? Ist damit die Dauer einer 
Datensatz-Übertragung gemeint? Wenn ich nun vorne einen Sinus 
"reinstecke" und den übertrage, wie kann ich das Ergebnis am Empfänger 
überhaupt bewerten? Bewertet man das auf Bit-Ebene?
VG

Autor: Gerrit Buhe (gbuhe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chris und "bla",

bla, ich habe ja geschrieben, daß die Latenz sicher nicht kritisch ist, 
aber dennoch sollte man auch diese Anforderung definieren. Die <=1s 
waren als großzügiger Vorschlag aus Sicht der Anwendung zu verstehen. 
Deiner Abschätzung stimme ich inhaltlich durchaus zu, aber Du weißt 
eigentlich noch gar nicht, ob Du nicht nach Analyse aller Anforderungen 
einen 1 Mbit/s Datenstrom mit einem 1/2-Faltungskode in Echtzeit 
prozessieren mußt, was ein 12MHz-Mikrocontroller nicht in Echtzeit 
schaffen wird. Eine strukturierte Vorgehensweise hilft hier, "Unfälle" 
zu vermeiden. ;o)

Chris, wenn Du keine Anforderungen definierst, kannst Du auf der 
Empfängerseite auch keine Bewertung vornehmen. Das wollte ich mit meiner 
ersten Nachricht aussagen. Versuche doch wenigstens einige Punkte von 
oben zu klären, z.B. mindestens:
 - Was ist das kleinste und größte zu messende Signal [Volt]?
 - Auf wieviel Milli- oder Mikrovolt genau muß es gemessen werden?
 - Was ist die höchste vorkommende Signalfrequenz?
(Zur Festlegung der minimalen Abtast- und damit Datenrate.)

Wenn Du das festgelegt und bei der Wandlung und Übertragung 
berücksichtigt hast, kannst Du auch das empfangene Signal (in binärer 
Darstellung, die aber eindeutig auf Spannung umgerechnet werden kann) 
mit dem Quellsignal (vor Abtastung) vergleichen und die Einhaltung der 
definierten Anforderungen bewerten.

Gruß, Gerrit

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Gerrit, hi Chris

Gerrit:
gut.. da weis ich jetzt leider nichts genaues aus der Praxis drüber (Die 
Vorlesung über die digitale Übertragungstechnik war zwar ausführlich, 
aber nicht dermaßen), aber ich weis, dass Faltungscodes (Der 
Reed-Solemon-Code ist ja auch so ähnliches.) mit einem 
Viterbi-Algorithmus decodiert werden können. Dieser soll ja auf dem 
Trellis-Diagramm beruhen. Die Implementierung eines Decodierverfahrens 
nach dem Trellis-Diagramm stell ich mir eigentlich nicht besonders 
rechenlastig vor. Es könnte zb rekursiv implementiert werden, was aber 
auch wieder Zeit benötigt. Dennoch denke ich, dass ein 32MHz Prozessor 
sowas in annähernd Echtzeit schaffen könnte. Die 12MHz, die ich in 
meinem letzten Beitrag erwähnte, waren als schlechtestes der möglichen 
Szenarien gedacht.

Um auf deinen letzten Beitrag einzugehen:

Das es eine großzügige Abschätzung war, ist mir bewusst gewesen. Mein 
Argument des ms-Bereichs, war ebenfalls eine großzügige Abschätzung, die 
auf dem Wissensniveau, in Hinsicht auf die Systhem- und Signaltheorie, 
des Fragestellers, beruht. Einen Hammingcode kann man auch ohne dieses 
Wissen verstehen und implementieren. Seine Codierung, die Übertragung, 
Decodierung , Fehlererkennung und -korrektur dürfte sich sogar unterhalb 
des von mir genannten Zeitrahmen bewegen.
(Ein ATXMega mit 32MHZ schafft die Berechnung einens Polynoms 15ten 
Grades mit Koeffizienten vom Typ double, die mehr als 4 Nachkommastellen 
besitzen in weniger als 1ms)

-Was ist das kleinste und was das größte zu messende Signal?

Das kommt auf den eingesetzten Differenzverstärker, spezieller: 
Intrumentenverstärker (Signal-Rausch-Abstand, CMRR, Verstärkungsfaktor 
etc.) und die verwendeten Elektroden an.

- Auf wieviel Milli- oder Mikrovolt genau muß es gemessen werden?

Kommt auf die Speichertiefe des AD-Wandlers an, auf den Betrag und die 
Stabilität der Referenzspannung, sowie auf die Ausgangsspannung des 
Differenzverstärkers an.

- Was ist die höchste vorkommende Signalfrequenz?

Die wird durch das angeschlossene Herz bzw. Gehirn bestimmt :-D. 
Außerdem kann man die Abtastrate nur indirekt über den Systemtakt des 
Controllers bestimmen. Gegebenenfalls müssen hier dan zusätzliche 
externe Wandler genutzt werden, derren Einbingung sicherlich nicht 
trivial ist.

Chris:
Du siehst wie es hier zugeht. Geh doch einfach mal zu deinem Betreuer 
und frag lieber ihn, wie er es haben möchte und was du wie tun sollst, 
anstelle dieses Forum hier. Das bringt Dir letztendlich die Gewissheit. 
Alles andere ist doch nur rein hypothetisch.
Wenn Du dann immernoch Fragen hast, werden wir Dir schon helfen.


- bla

Autor: Gerrit Buhe (gbuhe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo bla,

was Du schreibst ist inhaltlich völlig korrekt, aber die Vorgehensweise 
ist es nicht konsequent. Die Frage nach der nötigen Genauigkeit 
beantwortest Du mit der durch den AD-Wandler möglichen Genauigkeit. 
Die nötige Abtastrate ist tatsächlich durch die Signale von Herz und 
Hirn, aber sicher nicht durch die Möglichkeiten des Controllers 
angesichts des Systemtaktes bestimmt. Deine Antwort zur ersten Frage 
sucht dagegen die Performancegrenzen der bereits gegebenen Applikation 
(hier Sensorik), was definitiv ein valider Weg zur Bestimmung der 
Anforderungen an das "Meß- und Funk-Board" ist.

Nichts für Ungut; ich wollte nur die korrekte Vorgehensweise 
vorschlagen. Leider ist es sehr verbreitet, erst Lösungen vorzugeben und 
diese zu analysieren, anstatt sich um die Analyse der 
Applikationsanforderungen zu kümmern, die unbedingt als erstes erfolgen 
muß. Das böse Erwachen kommt dann erst zum Schluß bei der 
Systemintegration, wenn die Anforderungen nämlich nicht vollständig 
erfüllt werden. Das passiert selbst technisch guten Ingenieuren, wenn 
sie methodisch noch nicht so erfahren sind.

Viele Grüße!

Gerrit, DL9GFA

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Datenuebertragungen sollte man sich vorneweg im Klaren sein, ob man 
Blockdaten, oder Streamingdaten uebertragen will. Der Unterschied :

Blockdaten haben keine Redundanz und muessen richtig ankommen. Die 
gesammten Daten sind endlich und gehoeren zusammen. Ein Bit davon Falsch 
und alles ist unbrauchbar. Dafuer darf es auch laeger dauern. Das 
erreicht man mit Fehlerkorrektur und Wiederholungen.

Streamingdaten sind unendlich und nicht wirklich wichtig. Als Beispiel 
moegen Video und Tondaten gelten. Wenn mal ein Frame fehlt so ist das 
egal. Wichtig ist dass immer das Neuste unterwegs ist. Es gibt keine 
Wiederholungen.

Die unterliegende Kommunikations Schicht sollte dem angepasst sein. So 
machen Streamingdaten auf TCP/IP, was schon eine gesicherte Verbindung 
darstellt, wenig Sinn. Streamingdaten transportiert man auf UDP. Bei UDP 
redet man von einer verbindungslosen Kommunikation. Verbindung im Sinne 
von nummerierten Bloecken, die einzeln geprueft und abgerechnet werden.

Ich bin mit Zigbee und bluetooth zuwenig zuhause. Dachte aber, Bluetooth 
sei eine gesicherte Verbindung, und Zigbee eher ungesichert, mag mich 
aber taeuschen. Bei medizinischen Echtzeitdaten scheint es mir um 
Streamingdaten zu gehen. Wie lange dauert ein Verbindungsaufbau, 
Verbindungswiederaufbau, usw. Eigentlich braucht man gar keine 
Verbindung. Naja allenfalls als Kontrolkanal, um dem Geraet zu melden, 
es soll beginnen und zu stoppen.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke bla! Ich denke du hast recht. Ich werde morgen mal meinen Betreuer 
fragen wie das Anforderungsprofil ansehen soll. Dann komme ich wieder 
auf Dich (Euch) zurück. VG Chris

Autor: Wayne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollst du eigentlich auch prüfen, wie es mit der EMV-Verträglichkeit 
aussieht?
Ich könnte mir vorstellen, das so empfindliche Geräte wie EKGs und EEGs 
auf deine ZigBee-Funkerei empfindlich reagieren, bzw. die gestört 
werden.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo. Ja. ich denke das werde ich auch testen.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nochmal:0)
Mal ne eine allgemeine Frage. Wie läuft das ab, wenn ich ein 
kontinuerliches Siganl über ein (mein) Modul übertragen will? Angenommen 
ich schließe ein Sinus Generator an einen AD_Wandler des 
Mikrocontrollers an und möchte das  die Daten als Stream über zigbee 
übertragen. Werden die Daten dann einzeln übertragen und übertragen oder 
in Blöcke?

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was spricht dagegen das in einem Datenblatt nachzuschauen ? Ich hab da 
grad das Usermanual von Maxstream XBee ... und das arbeitet mit 
Bloecken.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich einen Plan hätte, dann würde dagegen siche nichts sprechen:= ) 
Aber danke für den Hinweis. Dann suche ich mal in den Datenblättern des 
Transceivers. Auf meinem Modul läuft ein ein einfaches Demoprogramm: Man 
betätigt einen switch auf Modul A, welches ein Request an  Modul B 
sendet (10 byte Daten). Das ganze läuft über TxBuffer[TXData++].Jetzt 
will ich halt mal ein Signal über die Luft schicken, weiss aber nicht 
wie ich das realisiere. Kannst du mir helfen? Ich weiss nicht wie ich 
mit diesem Buffer arbeite muss. Wenn ich z.B. ein 50 HZ Signal 
anschließe und dieses übertragen will, wie gehe ich da vor? Vg Chris

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist die minimal zulaessige Blockgroesse ? Wieviele von diesen 
Bloecken kann man pro sekunde senden ?

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo stehen diese Infos? Im Datenblatt des Transceivers? Vg

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. zum Beispiel. Dann mag es auch noch Vorgaben des Standards geben.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, in den Datenblättern des MRF24J40 steht, dass ein 128 byte FIFO 
Block zur Verfügung steht. Der Standard sagt dass man mit Zigbee 250 
kbit/s übertragen kann, aber das ist sicher incl Overhead...

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann probier doch mal... wieviele Bloecke zu 8,16,32,64,128 bytes pro 
sekunde ?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.