EKG Transmitter auslesen möglich?

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)

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

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

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

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

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

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.