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?
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öö
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..
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
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
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
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
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
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
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.
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
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.
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?
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
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...
