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?
Was spricht dagegen das in einem Datenblatt nachzuschauen ? Ich hab da grad das Usermanual von Maxstream XBee ... und das arbeitet mit Bloecken.
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
Was ist die minimal zulaessige Blockgroesse ? Wieviele von diesen Bloecken kann man pro sekunde senden ?
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...
Dann probier doch mal... wieviele Bloecke zu 8,16,32,64,128 bytes pro sekunde ?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.