Temp. Sensor

[mark (Gast)]

Hallo

Ich möchte hobbymässig den Sensor DS1621 auslesen.
Jedoch verstehe ich nicht wie dieser funktionieren soll. Auf Seite 4 ist 
beschrieben, dass er mittels einem Byte eine Auflösung von 1°C hat, bei 
2 Byte 0.5°.
Wie soll das gehen?
Es sind die Bytes zB 7D00 für +125°C angegeben dann erst 25°C wieder. 
..und das ist ja auf 1° genau und nicht 0.5 (2Byte)

Muss ich da interpolieren?

Wie komme ich dann auf meinen gemessenen Wert?
Was ist Count_Per_C und _Remain?

Ich verstehe leider nicht wie das funktionieren soll.
Vielen Dank für die Infos

[Volker K. (tobel)]

mark schrieb:
> Auf Seite 4 ist
> beschrieben, dass er mittels einem Byte eine Auflösung ...

Hänge bitte den Text (das Datenblatt) an.
Dann können alle einfach nachlesen und eher verstehen was du meinst.

[Dirk B. (dirkb2)]

Das sin 9 Bit Zweier-Komplement.

Im ersten Byte sind die (ganzen) Grad.

Als unsigned char ergibt das schon den richtigen Wert.

Im höchsten Bit vom zweiten Byte versteckt sich das halbe Grad.

[Michael B. (laberkopp)]

mark schrieb:
> Ich verstehe leider nicht wie das funktionieren soll

Hmm, deutlich als auf Seite 4 im Datenblatt kann man es eigentlich nicht 
beschreiben, Figure 9 zeigt es sogar bit für bit.

Woran mangelt's, englisch, P.I.S.A. ? Zudem wird es den Auslesecode für 
die üblichen Microcontroller auch fertig im Netz geben, einfach einen 
aussuchen.

[mark (Gast)]

hallo

ich habe nochmals alles durchgelesen (aufmerksam)

Nun möchte ich wissen, ob ich das auch alles richtig verstanden habe.

Also meine Slaveadresse, wenn ich A0,A1,A2 auf GND geschlossen habe (1 
Sensor) ist: 1001 000(R/W)
Also entweder 0x90 oder 0x91

Dann gibt es da das Control Register. Auf dieses kann ich zugreifen, 
wenn ich den AdressenBefehl als Read schicke (0xAC).
Dann kann ich diesen ändern und wieder mit dem AdressenBefehl als Write 
schreiben. Dann muss ich min. 10ms warten.
Ich habe da 2 Fragen dazu:
Um das DONE bit nach jedem Conversionsstart abzufragen, kann ich ja 
nicht einfach while(DoneBit==0) nutzen, da ja das Register stets 
abgefragt werden muss.
Muss ich das mit einer Schleife machen?
Ist das 1SHOT Bit anfangs defaultmässig auf 1SHOT oder muss ich den 
Sensor konfigurieren? Mehr muss ich ja wie es aussieht nicht 
konfigurieren als das 1Shot, wenn ich Tout nicht nutze.

Das Auslesen der Temperatur gibt mir immer 2 Byte zurück, wenn ich also 
nur das high Byte auswerte, habe ich gerade Temperaturwerte, sonst 0.5°C 
resolution.

Habe ich das so richtig verstanden?

[Dirk B. (dirkb2)]

mark schrieb:
> Das Auslesen der Temperatur gibt mir immer 2 Byte zurück, wenn ich also
> nur das high Byte auswerte, habe ich gerade Temperaturwerte, sonst 0.5°C
> resolution.

Nein.
Das MSB (High Byte) liefert ganzzahlige Werte. (also auch 125, ..., 25, 
..., 2, 1, 0, -1, ..., -25, ..., -55)

[mark (Gast)]

Dirk B. schrieb:
> mark schrieb:
>> Das Auslesen der Temperatur gibt mir immer 2 Byte zurück, wenn ich also
>> nur das high Byte auswerte, habe ich gerade Temperaturwerte, sonst 0.5°C
>> resolution.
>
> Nein.
> Das MSB (High Byte) liefert ganzzahlige Werte. (also auch 125, ..., 25,
> ..., 2, 1, 0, -1, ..., -25, ..., -55)

Hallo

Danke für die Erklärung. Das ist mir schon klar, aber ich meinte, wenn 
ich das LByte einfach weglassen würde, sprich nicht auswerte, habe ich 
einfach ganzzahlige Temperaturen (negativ, positiv).



Ich hätte übrigens mal eine Frage zu meiner stm32 uC i2c-Funktion.
Die Funktionen nehme ich an sind ja bei allen stms die gleichen.

Nun ich habe beispielweise
HAL_I2C_Master_Transmit(&hi2c1, TEMP_SENSOR_ADRESS_7_BIT << SHIFT, 
&txData, sizeof(txData), 10);
und
HAL_I2C_Master_Receive(&hi2c1, TEMP_SENSOR_ADRESS_7_BIT << SHIFT, 
&rxData, sizeof(rxData), 10);

Die Adressen, die ich beispielweise durchgeben müsste, wären 0x90 zum 
schreiben 0x91 zum Lesen. Jetzt aufgrund des Hinweises in der 
STM-Funktionsbib. muss dieses geshiftet werden und zwar nach rechts um 
1. Das ergäbe dann für die obigen beiden Fälle immer 0x48 egal ob ich 
schreiben möchte oder lesen. 0x48 ist dann ja quasi die 7Bit-Adresse vom 
TempSensor.
Jetzt shifte ich in der Funktion wieder nach links um 1, dann habe ich 
zwar die ursprüngliche Adresse, 0x90, und habe somit Platz für das LSB 
gemacht, aber schreibe so nur noch. Wo gebe ich nun explizit an, ob ich 
schreiben oder lesen möchte?

Ich möchte ja nicht immer schreiben.

[Dirk B. (dirkb2)]

mark schrieb:
> Wo gebe ich nun explizit an, ob ich
> schreiben oder lesen möchte?

Das sollte die Lib  schon selber wissen, da das LSB das Schreiben/Lesen 
bestimmt.

[mark (Gast)]

Dirk B. schrieb:
> mark schrieb:
>> Wo gebe ich nun explizit an, ob ich
>> schreiben oder lesen möchte?
>
> Das sollte die Lib  schon selber wissen, da das LSB das Schreiben/Lesen
> bestimmt.

Ja aber das heisst, dass ich dann doch die 8-bit adresse reischreiben 
muss als 2. Parameter und diesen aber wirklich nach rechts shiften muss, 
oder?

Also so:
wenn Address     0x90 definiert ist, muss es in der Fkt. doch heissen
Address >> 1

Weil wenn ich 0x48 als 7_Bit Adresse angebe und nach links shifte, 
bekomme ich  es ohne zusäzliche Angabe als Parameter nicht hin, zwischen 
lesen und schreiben zu wählen.

Denn
7_bit_Adresse     0x48
nach links geshiftet ergibt 0x90??
Also ist die richtige Lösung doch:
TEMP_SENSOR_ADRESS_READ                                          0x91
TEMP_SENSOR_ADRESS_WRITE                                         0x90
und damit
TEMP_SENSOR_ADRESS_READ >> 1 bzw. TEMP_SENSOR_ADRESS_WRITE >> 1
für das Lesen bzw. Schreiben

Richtig?

[Dirk B. (dirkb2)]

mark schrieb:
> Weil wenn ich 0x48 als 7_Bit Adresse angebe und nach links shifte,
> bekomme ich  es ohne zusäzliche Angabe als Parameter nicht hin, zwischen
> lesen und schreiben zu wählen.

Du hast doch verschiedene Funktionen zum lesen und schreiben. Oder?

[mark (Gast)]

ich habe nur diese hier, deshalb frage ich ja so blöd

/* IO operation functions  ****************************************************/
 /******* Blocking mode: Polling */
HAL_StatusTypeDef HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_Master_Receive(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_Slave_Transmit(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_Slave_Receive(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_Mem_Write(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_IsDeviceReady(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint32_t Trials, uint32_t Timeout);

 /******* Non-Blocking mode: Interrupt */
HAL_StatusTypeDef HAL_I2C_Master_Transmit_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Master_Receive_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Slave_Transmit_IT(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Slave_Receive_IT(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Mem_Write_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Mem_Read_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size);

HAL_StatusTypeDef HAL_I2C_Master_Sequential_Transmit_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t XferOptions);
HAL_StatusTypeDef HAL_I2C_Master_Sequential_Receive_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t XferOptions);
HAL_StatusTypeDef HAL_I2C_Slave_Sequential_Transmit_IT(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size, uint32_t XferOptions);
HAL_StatusTypeDef HAL_I2C_Slave_Sequential_Receive_IT(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size, uint32_t XferOptions);
HAL_StatusTypeDef HAL_I2C_EnableListen_IT(I2C_HandleTypeDef *hi2c);
HAL_StatusTypeDef HAL_I2C_DisableListen_IT(I2C_HandleTypeDef *hi2c);
HAL_StatusTypeDef HAL_I2C_Master_Abort_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress);

 /******* Non-Blocking mode: DMA */
HAL_StatusTypeDef HAL_I2C_Master_Transmit_DMA(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Master_Receive_DMA(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Slave_Transmit_DMA(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Slave_Receive_DMA(I2C_HandleTypeDef *hi2c, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Mem_Write_DMA(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size);
HAL_StatusTypeDef HAL_I2C_Mem_Read_DMA(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size);
/**

[mark (Gast)]

und das ist die Beschreibung zu einer der Funktionen

/**
  * @brief  Transmits in master mode an amount of data in blocking mode.
  * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *                the configuration information for the specified I2C.
  * @param  DevAddress Target device address: The device 7 bits address value
  *         in datasheet must be shift at right before call interface
  * @param  pData Pointer to data buffer
  * @param  Size Amount of data to be sent
  * @param  Timeout Timeout duration
  * @retval HAL status
  */

[Dirk B. (dirkb2)]

Wenn du anderer Quellen googelst steht da:

Du musst die 7-Bit Adresse aus dem Datenblatt durch Links-Schieben auf 
8-Bit erweitern.

[mark (Gast)]

genau das verstehe ich eben nicht, wie soll das denn gehen?
die 7-bit Adresse ist in beiden Fällen 0x48

0x90 und 0x91 nach rechts geschoben ergibt ja 0x48 (beide mal)

wenn ich jetzt die 0x48 habe und lesen möchte, weiss ich jetzt nicht wie 
das das Programm nun wissen soll, ob ich lesen oder schreiben möchte.
So wie ich das verstehe wie du sagst

0x48 << 1 ergibt 0x90 also schreiben. IMMER!!!

Wir sind da in einem Forum wo es sicher stm32 Programmierer gibt.
Kennt sich denn hier niemand aus, der das schnell sagen kann oder wie?
Sonst kann ich ja gleich in ein Flohmarktforum gehen.

[mark (Gast)]

übrigens aus welchem Datenblatt??

Die ist bei mir soweit ich weiss fixiert.
1001 für den Sensor, die sind fix
und A0,A1 und A2 sind bei mir GND
1001 000
da bleibt ja nicht mehr viel übrig, dass man noch in irgend ein 
Datenblatt schauen müsste, was die als 7-bit Adresse wollen.. hallo..?
Ich muss das machen/angeben, was der Sensor will..

[H.Joachim S. (crazyhorse)]

Das alte Drama bei I2C.
Entweder direkt 8bit-Adresse (beinhaltet dann schon Lesen oder 
Schreiben), oder eben 7bit-Adresse, die dann geschoben wird und falls 
nötig mit dem read-bit ergänzt wird.
Logischer ist eigentlich die 7bit-Adresse, weil die tatsächlich den 
Baustein adressiert. Ich nehme inzwischen aber durchweg die 
8bit-Adressierung.

[mark (Gast)]

H.Joachim S. schrieb:
> Das alte Drama bei I2C.
> Entweder direkt 8bit-Adresse (beinhaltet dann schon Lesen oder
> Schreiben), oder eben 7bit-Adresse, die dann geschoben wird und falls
> nötig mit dem read-bit ergänzt wird.
> Logischer ist eigentlich die 7bit-Adresse, weil die tatsächlich den
> Baustein adressiert. Ich nehme inzwischen aber durchweg die
> 8bit-Adressierung.

ok, ich frag jetzt noch mal genau nach.
was gibst du nun konkret ein als Deviceaddress?

0x90 >> 1 für schreiben
oder 0x91 >> 1 für lesen?

oder direkt die Adressen 0x90 oder 0x91 als Deviceaddress?
Ich nehme an nicht das letztere, weil die Fkt. ja voraussetzt dass man 
schiebt..

bitte um Beispiel

[Dirk B. (dirkb2)]

mark schrieb:
> 0x48 << 1 ergibt 0x90 also schreiben. IMMER!!!

Wie schon geschrieben, die etnsprechende Funktion weiß, das beim LSB 
eine 0 oder eine 1 hin gehört.

mark schrieb:
> übrigens aus welchem Datenblatt??

Zu deinem Sensor.
Es gibt noch andere I2C-Device. Die haben andere Adressen.

[mark (Gast)]

Dirk B. schrieb:
> mark schrieb:
>> 0x48 << 1 ergibt 0x90 also schreiben. IMMER!!!
>
> Wie schon geschrieben, die etnsprechende Funktion weiß, das beim LSB
> eine 0 oder eine 1 hin gehört.
>
> mark schrieb:
>> übrigens aus welchem Datenblatt??
>
> Zu deinem Sensor.
> Es gibt noch andere I2C-Device. Die haben andere Adressen.

kann ich mir nicht vorstellen, dass das funktioniert so..

aber ok, DeviceAddress zur Uebergabe an die Funktion, 2. Parameter oben 
von der Transmitfunktion gebe ich dann ein -->

DeviceAddress => (0x48 << 1)

also so?

Ok, du bist ja Programmierer. Dann mal die Frage anders herum gestellt:
Wenn du das programmieren müsstest, wie würdest du durch ein geschicktes 
Programm herausfinden, welchen Wunsch ich bei der Ausführung der 
I2C_Transmit  Funktion habe. Habe ich den Wunsch zu Lesen oder zu 
Schreiben??

Ich denke, du hast eine 50/50 Chance es zu erraten.

[Dirk B. (dirkb2)]

Fürs lesen hast du die Funktion I2C_Receive

[Wolfgang (Gast)]

mark schrieb:
> ok, ich frag jetzt noch mal genau nach.
> was gibst du nun konkret ein als Deviceaddress?
>
> 0x90 >> 1 für schreiben
> oder 0x91 >> 1 für lesen?
>
> oder direkt die Adressen 0x90 oder 0x91 als Deviceaddress?
> Ich nehme an nicht das letztere, weil die Fkt. ja voraussetzt dass man
> schiebt..

Die Zahl der Möglichkeiten ist an einer Hand abzählbar. Warum probierst 
du die nicht der Reihe nach durch und guckst dabei, wann dein Baustein 
mit einem ACK anwortet und wann in den I2C-Daten auf dem Bus das 
richtige Bitmuster auftaucht. Das geht schneller, als hier 9h auf den 
Thread zu schielen.

[mark (Gast)]

Wolfgang schrieb:
> mark schrieb:
>> ok, ich frag jetzt noch mal genau nach.
>> was gibst du nun konkret ein als Deviceaddress?
>>
>> 0x90 >> 1 für schreiben
>> oder 0x91 >> 1 für lesen?
>>
>> oder direkt die Adressen 0x90 oder 0x91 als Deviceaddress?
>> Ich nehme an nicht das letztere, weil die Fkt. ja voraussetzt dass man
>> schiebt..
>
> Die Zahl der Möglichkeiten ist an einer Hand abzählbar. Warum probierst
> du die nicht der Reihe nach durch und guckst dabei, wann dein Baustein
> mit einem ACK anwortet und wann in den I2C-Daten auf dem Bus das
> richtige Bitmuster auftaucht. Das geht schneller, als hier 9h auf den
> Thread zu schielen.

Weil ich durch Fragen am schnellsten lerne, vor allem bin ich ja 
nebenbei am Programmieren.
Aber du hast recht mit dem Probieren. Um das aber tun zu können, 
bräuchte ich ein Oszilloskop mit Decoderfunktion, was ich leider nicht 
habe.
Und den Oszi, den ich bestellt habe ist aufgrund häufiger Bestellung vor 
der Weihnachtszeit bis zum Jänner 18 verzögert.

Darum muss ich bis dahin noch auf die Threads, wie du so schön sagst, 
schielen.

[mark (Gast)]

Dirk B. schrieb:
> Fürs lesen hast du die Funktion I2C_Receive

Das hilft mir schon weiter. Jetzt ist es klar.

Manchmal sehe ich den Wald vor lauter Bäume nicht mehr... ohh mann

[Manfred (Gast)]

mark schrieb:
> Weil ich durch Fragen am schnellsten lerne, vor allem bin ich ja
> nebenbei am Programmieren.

Ich lerne nicht "durch Fragen", sondern dadurch, dass ich eigenständig 
teste.

[Dirk B. (dirkb2)]

mark schrieb:
> Dirk B. schrieb:
>> Fürs lesen hast du die Funktion I2C_Receive
>
> Das hilft mir schon weiter. Jetzt ist es klar.
>
> Manchmal sehe ich den Wald vor lauter Bäume nicht mehr... ohh mann

Beitrag "Re: Temp. Sensor"

[S. R. (svenska)]

Verschiedene Bibliotheken nutzen verschiedene Ansätze.

Manche wollen die 7 Bit-Adresse und shiften selbst, andere wollen die 
geshiftete 8 Bit-Adresse, und wieder andere wollen die vollständige 8 
Bit-Adresse (mit korrektem R/W-Bit) haben. Die Zahl der Möglichkeiten 
ist aber begrenzt.

Wenn dein Sensor antwortet, dann hast du die richtige Wahl getroffen. Ob 
er antwortet, kannst du den Statusbits entnehmen (da steht drin, ob ein 
ACK eingetroffen ist).

[mark (Gast)]

hallo

ich hätte eine Frage zur Programmierung mit dem STM32F302
Ich habe diese Fkt. geschrieben und es gibt mir die richtige Temperatur 
heraus.

t_ByteArray readTemperature()
{  
  txDataBuf[0] = READ_TEMPERATURE;
  uint8_t resultBuf[2];
  t_ByteArray tempBytes;

  HAL_I2C_Master_Transmit(&hi2c1, TEMP_SENSOR_ADRESS_8_BIT, txDataBuf, 1, 10);    // Shift is necessary because of i2C function description 
  HAL_I2C_Master_Receive(&hi2c1, TEMP_SENSOR_ADRESS_8_BIT, resultBuf, sizeof(resultBuf), 10);     // Shift is necessary because of i2C function description 

  tempBytes.HByte = (int8_t)resultBuf[0];
  tempBytes.LByte = resultBuf[1];
  
  return tempBytes;
}

Gedacht hätte ich aber, dass lediglich die Receive fkt. brauchen würde, 
da ich ja die Temperatur lesen möchte.
Sie müsste also so aussehen. Es kommt aber die falsche Temperatur 
heraus. Warum?
Hier ist das Datenblatt. 
https://datasheets.maximintegrated.com/en/ds/DS1621.pdf

t_ByteArray readTemperature()
{  

  uint8_t resultBuf[4];
  resultBuf[0] = READ_TEMPERATURE;
        resultBuf[1] = SensorAddress;
  t_ByteArray tempBytes;

  HAL_I2C_Master_Receive(&hi2c1, TEMP_SENSOR_ADRESS_8_BIT, resultBuf, sizeof(resultBuf), 10);     // Shift is necessary because of i2C function description 

  tempBytes.HByte = (int8_t)resultBuf[0];
  tempBytes.LByte = resultBuf[1];
  
  return tempBytes;
}

[Pete K. (pete77)]

mark schrieb:
> Gedacht hätte ich aber, dass lediglich die Receive fkt. brauchen würde,
> da ich ja die Temperatur lesen möchte.
> Sie müsste also so aussehen. Es kommt aber die falsche Temperatur
> heraus. Warum?

Schau mal auf Seite 4 im Datenblatt den zweitletzten Absatz.

[mark (Gast)]

Pete K. schrieb:
> mark schrieb:
>> Gedacht hätte ich aber, dass lediglich die Receive fkt. brauchen würde,
>> da ich ja die Temperatur lesen möchte.
>> Sie müsste also so aussehen. Es kommt aber die falsche Temperatur
>> heraus. Warum?
>
> Schau mal auf Seite 4 im Datenblatt den zweitletzten Absatz.

The DS1621 always powers up in a low power idle state, and the Start 
Convert T command must be used
to initiate conversions.

Ja das mache ich ja, es findet im main noch vor dem auslesen der 
Temperatur statt:

  WriteCommand(START_CONVERT_T,NONE);
  temp = getTemperature();

[Wolfgang (Gast)]

mark schrieb:
> Um das aber tun zu können, bräuchte ich ein Oszilloskop mit
> Decoderfunktion, was ich leider nicht habe.

Das Dekodieren geht im Einzelfall ach mal von Hand. Du willst ja nicht 
eine stundenlange Datenverbindung nach irgendwelchen komischen 
Bitmustern durchsuchen.

Und ein Oszi für diese Aufgabe ist nur wirklich etwas übertrieben.
Ein kleine Logikanalysator, der das kann, kostet 5€ - falls du einen PC 
hast ;-)
https://www.ebay.de/itm/201541710029

[mark (Gast)]

Wolfgang schrieb:
> mark schrieb:
>> Um das aber tun zu können, bräuchte ich ein Oszilloskop mit
>> Decoderfunktion, was ich leider nicht habe.
>
> Das Dekodieren geht im Einzelfall ach mal von Hand. Du willst ja nicht
> eine stundenlange Datenverbindung nach irgendwelchen komischen
> Bitmustern durchsuchen.
>
> Und ein Oszi für diese Aufgabe ist nur wirklich etwas übertrieben.
> Ein kleine Logikanalysator, der das kann, kostet 5€ - falls du einen PC
> hast ;-)
> Ebay-Artikel Nr. 201541710029

super, danke ;)

habs übrigens hinbekommen.
Die obere Variante stimmt. :) Ich muss beim lesen auch einen 
schreibprozess zuvor ausführen. Das ist mir komplett entgangen..