Hi Leute (Auch) aus gesundheitlichen Gründen (und aus Spaß) interessiere ich mich für ein EKG. Mir ist die Tage über Ebay ein günstiger EKG Transmitter namens "marquette APEX S" in die Hände gefallen so das es mir nicht weh tun würde wenn ich damit doch nix anfangen kann. (aber schon das Kabel mit den 5 Ableitungen ist es Wert gewesen...) Die Frage ist nun ob es für einen Laien (evtl. mit Hilfe der Erleuchteten hier) möglich wäre dem Gerät die EKG Daten zu entlocken... Soweit ich das richtig sehe werden die Teile normalerweise als Patientenmonitor in Krankenhäusern verwendet und funken ihre Daten an ein zentrales Empfänger-Rack (Apex Pro receiver) im Schwesternzimmer. Normalerweise wird im Transmitter alles wie Verstärkung/Begrenzung/Level und Filter und (evtl) ADC erledigt und dann nur noch die digitalen Daten übertragen. Zu den Sendefrequenzen habe ich das auf dem Gerät gefunden: Band G: 430-462MHz Band H: 462,05-474MHz Ich habe im Netz ein Manual dazu gefunden und diese Techn. Daten: Channel spacing 25kHz Bit rate: 10kb/sec Power output: 0,64mW Bandwidth: 9,5kHz Modulation: GMSK (oder GFSK, je nach Model) Das Gerät hat neben den Ableitungen auch noch einen Anschluss zum Programmieren des Geräts (ICP-interface connector port) der wohl auch als Serielle Schnittschtelle dient und um das Gerät in verschiedene Service Modi zu versetzten. (Serial communication: 2-9600 baud asynchronous) Laut Manual können die Geräte auf eine Frequenz programiert werden und auch die Anzahl der genutzten Ableitungen und auch der ICP. Die Testroutinen zeigen mir an das alle Ableitungen aktiv programmiert sind und auch der ICP Port aktiviert wurde. Auf dem Gerät ist ein Sticker der den Kanal/Frequenz des Geräts angibt. Bei mir steht "TTX 394" drauf. Im Manual gibt es eine Formel mit der sich aus dem TTX Wert die Frequenz berechnen lasssen soll: MHz=((TTX-1000)*0,025)+420 demnach müsste mein Gerät laut Label auf 404,85MHz senden... Tuts aber nicht. Wurde möglicherweise auf eine andere Frequenz programmiert. Also habe ich mein alten RTL-SDR Strick aus der Rumpelkammer geholt und das ganze Programm GQRX/GNURadio installiert. Eine heatmap von 420 bis 460 MHz über 20 Minuten generiert und nach 10 Minuten das Gerät eingeschaltet. Auf dem Plot habe ich dann bei 5 Minuten Aktivität bei ~433 Mhz gefunden. Also Bereich noch mal eingeschränkt und die Frequenz ~433,6993 MHz gefunden (evtl 433,65 wegen ppm error...). Da ich nun die Frequenz kenne frage ich mich ob ich evtl. wirklich brauchbare Daten aus dem Signal bekommen kann. Ich habe leider total NULL Plan was Demodulation betrifft, auch wenn ich wohl einen GMSK und GFSK Demodulator in GNURadio gefunden habe. Außerdem ist mir völlig unbekannt in welchem Format die Daten dann am ende nach dem Demodulieren vorliegen. Das ICP wil ich mir auch noch mal anschauen, evtl kann ich ja die PINs für der Serielle Schnittstelle herausfinden und ja evtl. eine Konsole öffnen ... Hat jemand eine Idee ob das mit Gnuradio klappen könnte die Daten zu demodulieren und dekodieren?
:
Bearbeitet durch User
Paul G. schrieb: > (Auch) aus gesundheitlichen Gründen (und aus Spaß) interessiere ich mich > für ein EKG. Mir ist die Tage über Ebay ein günstiger EKG Transmitter > namens "marquette APEX S" in die Hände gefallen so das es mir nicht weh > tun würde wenn ich damit doch nix anfangen kann. (aber schon das Kabel > mit den 5 Ableitungen ist es Wert gewesen...) Auch wenn ich Deine Hauptfrage nicht beantworten kann, würde mich mal interessieren, wann bzw. warum Du " (Auch) aus gesundheitlichen Gründen" ein EKG gebrauchen könntest. Evtl. gibt es dafür einfachere Lösungen. (z.B. kleines Gerät, das in der Hosentasche mitgeführt werden kann)
wolle g. schrieb: > ...wann bzw. warum Du " (Auch) aus gesundheitlichen > Gründen" ein... ich würde dir die Frage gerne in einer Mail beantworten aber nur so viel für die Allgemeinheit: Meine "Pumpe" macht nicht mehr so wie sie soll und ich bin dafür schon in bester ärztl. Behandlung... Nur habe ich öfters mal "Salven" zu den unmöglichsten Zeiten die ich gerne aufzeichnen möchte, das wäre ein nettes Gimmick für meinen Arzt, therapeutischen Nutzen hat es 0! > ...kleines Gerät, das in der Hosentasche mitgeführt werden > kann... Falls du damit auf diese https://www.ebay.de/itm/Mobiles-EKG-ECG-Monitor-Herz-Gerat-Observer-Elektrokardiogramm-mit-50Elektroden/202543356952?hash=item2f28865c18:rk:5:pf:0 Dinger zielst.. mein Arzt sagt das ist Spielzeug und wenn ich wirklich Daten aus dem richtigen Transmitter bekomme so sind die ziemlich genau im Gegensatz zu dem Ebay billig Zeug. Für den ganzen Spaß würde ich auch keine 70€ ausgeben... Wenn klappt, schön, wenn nicht, egal :)
Paul G. schrieb: > ich würde dir die Frage gerne in einer Mail beantworten ja, dann könnten wir unsere Erfahrungen evtl. austauschen. > Falls du damit auf diese Dinger zielst.. mein Arzt sagt das ist Spielzeug Wahrscheinlich hat er damit auch recht, denn eine Zulassung für medizinische Gerätetechnik gibt es nicht für 70€. Aber um bestimmte Herzrhythmusstörungen ermitteln zu können, kann schon ein Eigenbau reichen. (habe zuerst ein 3 Kanalgerät in Größe einer Videokassettenhülle mit SD-Karte als Speicher gebaut und habe jetzt zusätzlich ein 1 Kanalkleinstgerät in Handgröße ) Für einen Bastelheini spielt hier natürlich auch der Spaßfaktor eine "wichtige" Rolle. (es gab noch mehrere Zwischenstufen unterschiedlichster Art)
:
Bearbeitet durch User
> ...ja, dann könnten wir unsere Erfahrungen evtl. austauschen. siehe Mail... Ich habe noch ein paar Daten gefunden. Der interne ADC hat 10bit und die Samplerate beträgt 240 samples/sec. Ob der dann auch 240 10bit Werte (0-1023) pro Sekunde überträgt? Da das Teil aber 3 Kanäle hat (mit 5 Ableitungen) müsste er ja 3x so viel übertragen, es sei denn ich schließe nur ein Kanal an... Hier noch ein paar Impressionen aus dem Inneren: https://p-bg.de/pics/Marquette_Apex_S_front.jpg https://p-bg.de/pics/Marquette_Apex_S_back.jpg Scheint schon ziemlich alte Hardware zu sein. Interessant finde ich auch das die gar keine Instrumentenverstärker nutzen sondern nur low-power Opamps (TY2334). Zu dem TY2324 habe ich überhaupt nichts gefunden. Der "interface connector port" scheint Daten auszugeben sobald ich die Batterien einlege. An Pin 1 und 4 kann ich mit dem Oszi unterschiedliche Daten sehen die aber für mich alle keinen Sinn ergeben. Dabei spielt es keine Rolle ob ich die Ableitungen angeschlossen habe oder nicht. Ich habe versucht meinen billig USB-UART Adapter an die Datenpins zu legen und auf dem Terminal zu schauen was ankommt... und ja es kommt was an, es kommt viel an, allerdings kann ich mir nix daraus reimen, es scheinen nur wahllose Zahlen zu kommen. Ich habe auch verschiedene Baudraten ausprobiert aber es hat sich nix sinnvolles ergeben. Vielleicht nutzen die ja auch ein unbekanntes/internes Protokoll. Der Transmitter fängt aber erst an Daten über die Antenne zu Senden wenn die Ableitungen angeschlossen sind (an Signalquelle..Körper..Signalgenerator..). Ausgenommen ein kurzer Datenstrom sobald die Batterien eingelegt werden. Dann sendet er für ca. 5 Sekunden und hört dann auf sofern kein EGK Signal anliegt. Im Moment stecke ich bei dem Seriellen Port fest. Ich werde mich mal weiter dem Funksignal zuwenden und das EKG an mich anschließen und mal 10 Sekunden Datenstrom in Gnuradio aufzeichnen. Leider fehlt mir jedes Hintergrundwissen zu Demodulation, geschweige denn die Parameter mit denen die Daten moduliert wurden, wie z.Bsp. Samples/Symbol. Evtl. Frage ich da nochmal direkt bei den Gnuradio Profis nach ob man das vieleicht auch irgendwie anhand der Daten herausfinden kann. Aber was ich so im Netz zu GMSK gefunden habe scheint zumindest diese Bausteine zu beinhalten: FileSource-->Throttle(sampl_rate)-->GMSK-Demod-->Viterbi/FEC? decode? Und dann evtl Clock-Recovery... und am Ende hat man möglicherweise wieder ein proprietäres Format :)...
Paul G. schrieb: > (Serial communication: 2-9600 baud asynchronous) zumindest das scheint laut dem Bild halbwegs plausibel, bei 1ms/div ergeben sich so ca. 10+- bit/Div, 9600baud ist da wohl richtig (allerdings sind es durch Zählen eher 11-12, das müsstest du am Oszi nochmal genau messen) Paul G. schrieb: > aber es hat sich nix sinnvolles ergeben. Vielleicht nutzen die ja auch > ein unbekanntes/internes Protokoll. die gelbe Kurve síeht sehr komisch aus, die kurzen Pulse passen zu 9600baud, dann ist nur in der Mitte eine ca. 20 Bit lange low Sequenz. auch der blaue Kanal ist komisch, wenn man den ersten Puls über dem "AA" als Start interpretiert sidn das immer noch 12Byte 1010..., also auch kein "normaler" 8-10 bit Uart. Paul G. schrieb: > Ob der dann auch 240 10bit Werte (0-1023) pro Sekunde überträgt? > > Da das Teil aber 3 Kanäle hat (mit 5 Ableitungen) müsste er ja 3x so > viel übertragen 240*10*3 = 7200baud, sollte mit 9600baud eventuell noch gehen, vllt. wird ein 10 (oder 30) bit Uart Wort übertragen, nur normales Uart kein Kanal (oder Messfehler). Sind Blau/gelb die signale von Pin 1/4 am Stecker? kommt etwas auf Pin2 oder ist das die Datenleitung zum Gerät? wo hast du die Pinbelegung her/wie sicher stimmt die so? kannst du eine etwas längere Sequenz aufnehmen und als .csv oder so exportieren?
K. S. schrieb: > Sind Blau/gelb die signale von Pin 1/4 am Stecker? also oben im vorherigen Post in den Bildern ist blau/Data2/Pin1, ich habe in den nächsten Bildern die Kanäle mit den Pin Nummern gelabelt. > kommt etwas auf Pin2 > oder ist das die Datenleitung zum Gerät? also keine Daten an sich am Oszi.. Pin2 scheint sich bis auf ~2,8V aufzuladen sobald ich Batterien einlege und nach ~500ms setzt so eine Art schwaches Pulsieren ein die eine Dauer von ~8,3ms haben. Pin 2 scheint für mich der einzige Kandidat als RX Pin Wenn ich mich nicht irre geht Pin4 direkt zum MOSI des MC68HC705C8A* Microcontroller, das müsste ich aber nochmal genau testen wenns sein muss. *http://cache.freescale.com/files/microcontrollers/doc/data_sheet/MC68HC705C8A.pdf Nebenbei wird im Manual erwähnt das wenn man Pin2/Pin4 kurzschließt: "Short pins 2 and 4 on either one of the interface connector ports. Power up the transmitter. This forces the transmitter to run the manufacturing code, which outputs a test pattern that can be measured accurately for center frequency." (Manual Seite 101) > wo hast du die Pinbelegung > her/wie sicher stimmt die so? Die Pin Nummern habe ich aus einem Manual zum "Apex Pro Transmitter", ein sehr wahrscheinlich jüngeres Modell als mein "Apex S", sehen aber Baugleich aus und zumindest die PowerOn Self Tests sind identisch und das Verhalten bisher auch. Hier das Manual falls es interessiert: http://p-bg.de/pdf/ApexPro_Telemetry_Transmitter.pdf Pin3 und Pin5 habe ich per Multimeter getestet. Durchgangsprüfung hat bei mir gezeigt das Pin3 direkt zum -Pol der Batterie geht und Pin5 zum +Pol. Evtl. kann man damit die Batteriespannung messen wenn der Transmitter an der Basisstation per Kabel angeschlossen ist oder sogar als Spannungsversorgung verwenden (ohne eingelegte Batterien)... das werde ich aber lieber nicht testen :) > kannst du eine etwas längere Sequenz aufnehmen und als .csv oder so > exportieren? siehe oben, ich weiß nicht ob du etwas mit dem Rigol format anfangen kannst... einmal nur den Screen und einmal den ganzen Memory. Und als letztes Bild noch eine Messung der ganz kurzen Impulse, also von Pulsanfang bis Pulsanfang ~200µs...
Aha, also dann hat ein Impuls eine Frequenz von 1/(208ms/2)=~9600Hz=9600Baud?
mit dem standard UART wird das tatsächlich nichts, die Baudrate stimmt zwar so, aber es gibt immer (5-9 bit, mit/ohne Parität ... ) irgendwo wiederholt Frame Error. was für Channel 2 in mem100ms_csv funktioniert (mit modifizierten UART detektor für Sigrok/Pulseview): Daten invertieren baudrate stimmt so lsb first (geraten, nur zur Info) Länge auf 59 bis ca. 80 bit (hier muss modifiziert werden) das passt so über die ganze Länge ich habe die Daten mal zu 64 bit Länge angenommen (kürzeste Länge durch 8 teilbar) und exportiert, anghängt in der Textdatei (einmal in hex und direkt dahinter in binär)
Channel 1 lässt sich mit 74-78 bit länge und auch invertiert dekodieren: 88 Zeilen fangen mit 369 an. 54 Zeilen fangen mit 169 an. 1 Zeile fängt mit 368 an. auch sonst gibt es innerhalb der Daten über einige Werte hinweg Wiederholungen, interessant wären Daten wenn alle/einige Ableitungen definierte Potentiale haben, also entweder auf Masse/Abschirmung liegen oder am Körper etwas aufzeichnen, mit externer Spannung würde ich da nicht rangehen. Die daten habe ich übrigends mit einem modifizierten Skript von github (csv2vcd) in vcd umgewandelt und dann in Pulseview geöffnet in PulseView\share\libsigrokdecode\decoders\uart kann man in dem Python file eine Zeile ändern: {'id': 'num_data_bits', 'desc': 'Data bits', 'default': 8, 'values': (5, 6, 7, 8, 9)}, zu {'id': 'num_data_bits', 'desc': 'Data bits', 'default': 8}, dann kann man die Bitlänge genau einstellen. man muss aufpassen dass die Zeit nicht zu groß wird sonst crasht Pulseview ( 1 millionen geht noch bei 100-1000 mill crash), also lieber als timebase ns oder µs wählen, bei ps stürzt der ab.
aus Versehen dasselbe Bild zweimal hochgeladen, das Zweite sollte das hier werden. der grüne "UART" gehört zum oberen Trace/CH1 der pinke "UART" gehört zum unteren Trace/CH2
:
Bearbeitet durch User
Sehr interessant, danke! Ich bin tatsächlich gestern erst über Sigrok/Pulseview gestolpert. Das ist natürlich richtig mit den Ableitungen. Theoretisch, also wenn der Transmitter tatsächlich permanent Daten der Ableitungen ausgibt müssten das wirre floating output Werte sein, es war ja nix angeschlossen. Vom Gefühl her würde ich fast meinen der sendet nichts über die Seriellen Pins denn über die Antenne sendet er ja auch erst wenn irgendwelche Signale an den Elektroden anliegen, aber man weiß es nicht. Vielleicht sendet der Transmitter immer nur kodiert sowas wie seine Kennung,Seriennummer, Batteriestatus oder sowas wie ein Beacon damit, wenn an den Programmierer angeschlossen, eine Verbindung initiiert werden kann... https://youtu.be/XOfPrzYUXoY?t=62 Ich werde wie du vorgeschlagen hast mal alle Ableitungen zusammenschließen, dann müsste doch zumindest an allen das selbe Potential sein. Aber ich bin mir gerade nicht sicher ob ich alle Ableitungen zusammen schließen soll. Es gibt ja R,L,F und C. Wenn ich das richtig verstehe ist C (chest) das Mittelpunkt Potential auf das sich die drei Ableitungen R,L,F beziehen. Dann gibt es noch N neutral, zur Rauschdämpfung, die sollte ich doch lieber rummhängen lassen oder? Ich probiere das mal so. Mal sehen was/ob sich etwas im CSV ändert. Mir ist gestern Abend noch eingefallen das mein Signalgenerator DG1022 intern sogar ein ganzes Paket "ECG Waveforms" gespeichert hat. Die Amplitude kann ich bis auf 2mVPP runterdrehen, im Manual des Transmitters steht QRS-Detection Range 5mV. Sollte eigentlich passen. Evtl. besser als das EKG an mich selbst anzuschließen (im Moment jedenfalls).
K. S. schrieb: > Die daten habe ich übrigends mit einem modifizierten Skript von github > (csv2vcd) in vcd umgewandelt Was genau hast du da geändert? Ich bekomme mit dem unmodifizierten nur "ERROR: Breakpoint "0 s" not found." Ich hatte bisher die csv dateien über "import raw binary logic data" importiert, aber das ist wohl nicht der richtige Weg?
Paul G. schrieb: > K. S. schrieb: >> Die daten habe ich übrigends mit einem modifizierten Skript von github >> (csv2vcd) in vcd umgewandelt > > Was genau hast du da geändert? > Ich bekomme mit dem unmodifizierten nur > "ERROR: Breakpoint "0 s" not found." > > Ich hatte bisher die csv dateien über "import raw binary logic data" > importiert, aber das ist wohl nicht der richtige Weg? jede Menge, das wir über ein "string".strip().endswith('0 s') abgefragt der geht auch von einem Format mit: Wert1, Wert2, ..., Zeit Einheit aus, während hier ein Format Nummer Messwert, Wert1, Wert2 vorliegt, also den quasi den kompletten parsing Algorithmus, z.b. die Erkennung zu "string".strip().startswith('0,'), aber das reicht nicht alleine bei mir ist die zeitbasis um den Faktor 1000? falsch, da sigrok bei ca. 500ms-1s crasht (wenn die Zeit zu groß wird im Verhältnis zur Zeitbasis, ob zur internen oder der aus der Datei keine Ahnung) im header kannst du die Zeitbasis der Datei verändern:
1 | $end |
2 | $timescale |
3 | 1ns |
hier modifizier ich die aus der Datei eingelesene Zeitbasis (delta t pro messung) :
1 | # set timebase |
2 | global tbase |
3 | fline = infile.readline() |
4 | tbase = float(fline.strip().split(',')[-1]) * 10e6 # ns timebase, so multiply by 10^9 |
5 | print(tbase) |
wenn oben ns verwendet werden, muss unten 10e9 stehen, oben µs wäre 10e6 usw. da ich nicht wusste ob der crash durch zu große Zeitwerte in der Datei oder insgesammt zu lange Messungen entsteht, habe ich alles "verkürzt", die scheinbare Baudrate ist dementsprechend auch höher. ich hoffe ich darf die datei hier so hochladen edit: Paul G. schrieb: > Ich hatte bisher die csv dateien über "import raw binary logic data" > importiert, aber das ist wohl nicht der richtige Weg? kann man natürlich auch machen, wenn es funktioniert, bei mir crashte Pulseview nur immer nach spätestens 1 Minute oder schon beim Laden, mit der neuen Datei läuft es stabil
:
Bearbeitet durch User
ich glaube asl raw binary data wird das nicht korrekt eingelesen bild 1: mem100ms.csv mit excel geplottet, erste 4-5 pakete bild 2: vcd in pulseview, erste 4-5 pakete bild 3: raw binary logic data, sieht irgendwie komplett anders aus, pulseview wird bei raw binary logic wirklich einzelne bits (oder bytes) erwarten das format in der datei ist ja sogar x.yy E +-nn und dass auch noch als string, der wird denke ich die char nach int/byte konvertieren. wenn ich raw binary data mit 2 channeln importiere erhalte ich 22 millionen Messwerte pro channel, in der Datei stehen 600k, das passt überhaupt nicht. wenn dann müsste man csv imporieren, nur das macht er bei mir nicht (Fehler oder crash)
1 | X,CH1,CH2,Start,Increment |
2 | Sequence,Volt,Volt,1.40E+00,2.00E-06 |
3 | 0,3.28E+00,3.36E+00,-6.40E-01, |
4 | 1,3.28E+00,3.36E+00,-6.40E-01, |
5 | 2,3.28E+00,3.36E+00,-6.40E-01, |
6 | ... |
ist halt weder raw noch binary noch logic
:
Bearbeitet durch User
ah okay, danke für die Infos! Ich dachte mir das fast weil meine Daten nicht zu deinen gepasst haben.. Ich würde erstmal kurz STOP sagen! :) Ich habe glaube ich gerade das original Service Manual des Transmitters gefunden, inkl. PCB Layout und detailierten techn. Infos. Bin gerade am lesen und poste später noch was dazu.
Also laut dem Manual (von 1999) ist mein Modell (430-474Mhz): PCB Part Nr. 801278-004, SchematicPart Nr. SD801278-004 Hier ein paar interessante Passagen: The APEX telemetry transmitter acquires three differential leads of ECG information and a pace channel from the patient and converts this information to 10-bit NRZI digital data. This digital data is then transmitted to a central receiving unit by phase modulating a carrier signal. The RF carrier signal is broadcast using the patient leadwires as an antenna. The transmitter PCB contains all ECG signal acquisition circuitry, the pace detect circuitry, the microprocessor and A/D converter support circuitry, and the RF circuitry. • The ECG circuitry includes a reconfigurable front end, ECG detect, and pace detect circuits. The front end circuitry has a three-stage ECG section and pace detect section with the first two stages being common to both. • The digital circuitry is composed of the microprocessor, an A/D converter, and supporting circuitry. • The RF circuitry includes the frequency synthesis circuitry and the BPSK phase modulation circuitry. Hier das ganze Manual: http://p-bg.de/pdf/Marquette_Apex_S_Manual.pdf Aber leider keine genaue Angabe ob die NRZI kodierten Daten auch am Seriellen Output ankommen. Auf Seite 60 steht: Port D communicates with the A/D converter and the EEPROM via the three serial peripheral interface (SPI) lines (MISO, MOSI, and SCK). Port D also contains serial communications interface lines (RDI and TDO) which can be connected to external equipment through the auxiliary connector (J1). Leider steht NRZI noch auf der Sigrok Todo Liste...
So, neue Pin Bezeichnung. Wenn 5 (Bat-) und 4 (Bat+) von oben nach unten gehen wird der Rest auch abwechselnd oben/unten gezählt... Der ominöse Pin 3 (EXPID) geht direkt in einen analog Eingang des ADC's. Pin 1 ist dann also RX (RDI), warum dort aber auch ständig Bewegung zu sehen ist verstehe ich nicht. Ich würde mich von jetzt an nur noch Pin 2 (TX/TDO) konzentrieren.
Mir ist gerade noch aufgefallen das der RDI Eingang Pin über einen 10k Widerstand an PA0 des Mikroprozessors hängt welcher dort als Output zum RF Modlulator dient. Das würde die aktivität dort erklären und man müsste dort ja die Daten finden bevor sie Moduliert werden... "Port A bit 0 (PA0) outputs serial data to the RF drive circuit which drives the BPSK modulator."
Paul G. schrieb: > also oben im vorherigen Post in den Bildern ist blau/Data2/Pin1 dann ist gelb wohl Pin4 gewesen (alt) ist gelb/Pin4(alt) dann auch CH2 in mem100ms.csv und Pin1(alt) CH1 in dieser Datei, sieht zumindest so aus für mich? (gelb/CH2 hat sehr viel weniger Änderungen als blau/CH1) Wenn diese Annahme stimmt: Paul G. schrieb: > Ich würde mich von jetzt an nur noch Pin 2 > (TX/TDO) konzentrieren. Das ist dann der alte CH2/Pin4(neu) der interessante, das ist gut. Der andere Channel(RX) scheint nur Müll oder zufällige Daten zu beinhalten auf TX/TDO gibt es einige Regelmäßigkeiten, siehe das erste Capture.png/heatmap (blau: bit=1, gelb: bit=0, Zeilen sind die Datenpakete, Spalten die bits) - hinten pulsiert ein Signal (bit 2,3,4,5 von rechts, Zählung beginnt Ausnahmsweise mal bei 1), Sequenz ist (0,5,3,5,10,15,15,15) - Capture1 - Bit 6 ist komisch, keine Ahnung ob das zu den Pulsierenden gehört - Bit 7,8,9 sind ein 3 bit counter (von 7 nach 0 Abwärts) - Capture2 Capture3 ist Capture1, nur in den roten Bereichen sieht es so aus als könnte ein Bit springen (von binär 1000... zu 0111...), dann wären rechts die niederwertigen Bits und einige Grenzen von Bytes vorgegeben
:
Bearbeitet durch User
Im Header von mem100ms.csv steht ein Increment von 2µs (Differenz zwischen zwei Messungen) dann ist ein bit in CH1/RX auch nur ca. 80µs lang -> 12500 baud (real 12240) (also sind meine Daten dazu falsch) ein Bit in CH2/TX ist dann ca. 104µs lang -> 9600 baud (passt also alles) das nur so nebenbei, eigentlich war die Aussage dass in CH2 ein Datenpaket einen Abstand von ca.80 bit hat und damit mit im Mittel 120Hz übertragen wird, was die Hälfte von den angegebenen 240Hz Samplerate sind.
Sorry, ich muss gestehen meine Aussage zu den techn. Daten vor Beitrag "Re: EKG Transmitter auslesen möglich?" sind mit Vorsicht zu genießen, wenn nicht sogar zu verwerfen... Die 240samples/s stammen aus dem Apex Pro Manual. Die GMSK Modulation war ja auch falsch... Es ist schon sehr nervig das Rigol nur CH1/CH2... exportiert und nicht die Labels die ich vergeben habe... Ich beziehe mich ab jetzt immer auf CH1=RDI=Pin1 CH2=TDO=Pin2
:
Bearbeitet durch User
Ich werde auch nochmal neue csv aufnehmen. Die alten sind glaube ich problematisch aus dem Grund weil der Transmitter sobald ich die Batterien einlege eine Zeit lang "sensed" ob an den Elektroden ein Signal anliegt, das dauert evtl länger als eine Sekunde... dann entscheidet er ob er Daten sendet oder in den low-power Modus geht. Meine alten csv's die du benutzt sind alle so getriggert das gleich nach dem Batterie einlegen beim ersten signal gespeichert wurde. evtl ist es sinnvoller den Transmitter ein paar Sekunden laufen zu lassen und dann erst aufzuzeichnen. Ich mache nochmal ein paar neue morgen.
So, ich habe mir noch ein bisschen den Schaltplan angeschaut und mir eine Skizze gemacht um mir deutlich zu machen wo was herkommt. Es ist ziemlich sicher das die EKG Daten am RDI-Eingang "herauskommen". Meine Vermutung ist das dieser Eingang zum debuggen des Datenstroms zwischen dem Mikrocontroller und dem RF Teil vorgesehen ist so lange der Transmitter als Standalone Gerät arbeitet. Also wäre RDI noch am interessantesten wenn da nicht die Vermutung wäre das der Datenstrom per NRZI kodiert ist (und dann vielleicht noch mit Bitstuffing...). Bei mir fällt dann an dem Punkt das Wissen steil nach unten in ein schwarzes Loch :) Ich habe mir inzwischen ein Spielzeug-Logic-Analyser zukommen lassen und RDI für 20 Sekunden nochmal richtig aufgezeichnet, dabei habe ich alle EKG Elektroden zusammengeklemmt so dass alle das selbe Potential sehen müssten. Interessant zu sehen ist dabei der Anfang der Daten. Dort sind immer 36 Bits hintereinander zu sehen und danach nochmal 7. Diese Muster zeigt sich immer direkt nach dem Einschalten. Man könnte meinen dass das evtl. dazu dient um etwas zu synchronisieren oder als Clock? Wird beim dekodieren von NRZI nicht auch ein Clock benötigt...? Vielleicht hängt das ja damit zusammen. Des weiteren scheint die Geschwindigkeit irgendwas bei 12500 oder mehr Baud zu sein. Auf dem Oszi schwankt es immer minimal zwischen 80-82µs für ein Bit. Das entsprächen dann so etwa ~12200 Baud. Witziger weise soll der Mikrokontroller ja mit 1,2288Mhz Bustakt laufen... Koinzidenz? In dem Datenstrom selbst kann man auch wiederkehrende Muster erkennen und ich denke das die Daten dort drinne sind aber wie gesagt bei NRZI ist bei mir Schluss. Eine letzte Möglichkeit sähe ich noch zu versuchen die Daten direkt am ADC DATA-OUT abzugreifen bevor sie im Mikrocontroller mit NRZI kodiert werden. Das Datenblatt for den TLV1543 ist ja vorhanden. Mal sehen ob ich mich noch mal daran versuche.
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.