CFSensors XGZP6857D Drucksensor Informationen

[Gerhard O. (gerhard_)]

Moin,

falls es jemanden interessiert:

Seit einiger Zeit befasse ich mich mit Drucksensoren der Firma 
CFSensors. Da es derzeit bei Digikey wegen "Global 
Partner"-Beschränkungen umständlich und teuer ist, solche Komponenten zu 
beziehen, habe ich mir ein paar Exemplare mit unterschiedlichen 
Messbereichen von 5 bis 100 kPa über AliExpress besorgt.

Die Sensoren funktionieren grundsätzlich, allerdings gab es einige 
Überraschungen:

Heute wurde für die Reihe XGZP6857D ein neues Datenblatt (V2.9) 
veröffentlicht, das grundlegende Änderungen in der Belegung der internen 
Datenregister enthält.

Viele Arduino-Bibliotheken auf GitHub basieren noch auf der vorherigen 
Registernummerierung. Wer ab heute neue Sensoren über offizielle Kanäle 
bezieht, wird feststellen, dass bestehende Treiber nicht mehr 
funktionieren und angepasst werden müssen. Ich selbst habe mir ohnehin 
eigene Sensor-Routinen geschrieben.

Das Hersteller Beispiel Programm enthält m.M.n. Fehler. Die Behandlung 
des ACK/NAK ist falsch, weil es nur den Zustand des ACK/NAK checken 
will. Der Host setzt üblicherweise beim Read nämlich den ACK oder NAK 
Zustand am Datenbus. Testen alleine tut nichts Nützliches und verhindert 
dem Slave mitzuteilen, daß der letzte READ mit dem NAK die Datenübergabe 
beenden soll. Ich habe aber  das Herstellerprogramm nicht ausprobiert 
und kann nicht beurteilen ob es trotzdem funktioniert.

Zusätzlich stimmen die Angaben zum I2C-Leseprotokoll im Datenblatt nicht 
vollständig. Beim Einzellesen der Ausgaberegister muss der Host ein NAK 
nach dem Lesen senden, was im Datenblatt nicht erwähnt wird. Wenn man 
nur mit ACK liest, kommt es zu Fehlern in der Synchronisierung im 
I2C-Teil und gibt bei nachfolgenden Lesen einige mal nur Nullwerte aus. 
Abhilfe: nach jedem Lesen vor dem Stop ein NAK senden. Das 
Datenblattbeispielprogramm nimmt augenscheinlich darsuf keine Rücksicht.

Da das Einzellesen der fünf Datenregister auf diese Weise zeitaufwendig 
ist, habe ich getestet, ob man alle fünf Register gleichzeitig auslesen 
kann. Obwohl das Datenblatt keine Reihenlesung vorsieht, funktionierte 
es problemlos nach dem üblichen Schema: die ersten vier Lesevorgänge mit 
ACK, der fünfte mit NAK. Ich verwende übrigens nicht die Wire Bibliothek 
von Arduino, sondern arbeite mit der kompakteren ASM SoftI2CMaster 
Bibliothek.

Die Arduino Sensor Bibliothek verwendet die Multy-Byte Read Funktion. 
Ich habe nicht untersucht inwieweit dort auf ACK/NAK Rücksicht genommen 
wurde. Es ist sicher, daß es sich so verhält, weil diese Bibliothek 
zuverlässig funktioniert.

Alle verfügbaren Bibliotheken beziehen sich auf Versionen vor 2.9. Neu 
bezogene Devices sollten unbedingt überprüft und ggf. angepasst werden – 
besonders bei Bestellungen über AliExpress oder eBay. Zu berücksichtigen 
ist, daß das Datenaustausch Protokoll auch mit ähnlichen 
Parallelversionen ihrer Sensoren funktioniert.

Ich stehe derzeit mit dem technischen Kundensupport von CFSensors in 
Kontakt und werde neue Informationen hier teilen. Der FEI erklärte mir, 
dass keine neue Typenbezeichnung vorgesehen sei, wodurch die 
Marktunsicherheit leider bestehen bleibt – persönlich finde ich das 
suboptimal.

Unklar bleibt zudem die Herstellungsgeschichte der im Markt 
existierenden Devices. Möglicherweise stammen einige Sensoren aus 
fragwürdigen Quellen.

Interessant ist: Ein gemessener 100 kPa-Sensor zeigt ein Grundrauschen 
von ±0,1 %, was für einen 24‑Bit-ADC relativ hoch ist. Ich habe 
diesbezüglich ebenfalls angefragt und vorbeugend für eine saubere 
Versorgungsspannung mit entsprechender Filterung gesorgt. Nachtrag: im 
neuen Datenblatt gibt es Einstellungen zum Mitteln. Das kann ich 
allerdings erst nach Erhalt von Exemplaren der neuesten Generation 
prüfen.

Ich hoffe, diese Informationen sind für den einen oder anderen nützlich. 
Übrigens, ich gebe hier nur meine praktischen Erfahrungen weiter und 
möchte  keinen Anspruch auf Korrektheit erheben.

Gruß,
Gerhard

[Rahul D. (rahul)]

Moin,
Da du interessante Informationen lieferst, aber keine Frage stellst, 
würde ich vorschlagen aus dem Text einen Artikel für die Artikelsammlung 
zu erstellen.
Hier im Forum verschwindet der sonst irgendwann auf den nächsten Seiten, 
wenn andere wichtige und "wichtige" Fragen stellen.

[Gerhard O. (gerhard_)]

Rahul D. schrieb:
> Moin,
> Da du interessante Informationen lieferst, aber keine Frage stellst,
> würde ich vorschlagen aus dem Text einen Artikel für die Artikelsammlung
> zu erstellen.
> Hier im Forum verschwindet der sonst irgendwann auf den nächsten Seiten,
> wenn andere wichtige und "wichtige" Fragen stellen.

Moin Rahul,

Wenn Du meinst, dann werde ich gescheit machen müssen, wie man es macht. 
Aber ich stimme Dir bei, daß es hier verloren gehen wird.

Gruß,
Gerhard

[Christoph db1uq K. (christoph_kessler)]

> "Global Partner"-Beschränkungen

Das bedeutet, Trump lässt den Export nach Kanada nicht mehr unbehindert 
zu?
Feindliches Ausland, das irgendwann Teil der USA werden muss?
Der Zar hat auch mal "russische Erde gesammelt", bis er am Pazifik 
angekommen war.

Ist der Softwareunterschied Absicht des Herstellers, oder ein Versehen?

[Gerhard O. (gerhard_)]

Christoph db1uq K. schrieb:
>> "Global Partner"-Beschränkungen
>
> Das bedeutet, Trump lässt den Export nach Kanada nicht mehr unbehindert
> zu?
> Feindliches Ausland, das irgendwann Teil der USA werden muss?
> Der Zar hat auch mal "russische Erde gesammelt", bis er am Pazifik
> angekommen war.
>
> Ist der Softwareunterschied Absicht des Herstellers, oder ein Versehen?

Moin,

Uff - Viele Fragen auf einmal.

Nein. Die "Global Partner" Einrichtung ist ein internationales Partner 
Netzwerk und da wird dadurch das Angebot vergrössert. Leider fallen dann 
bei jeder Bestellung rund $38 an zusätzlichen Lieferkosten an und oft 
stören dann auch MOQs. Da ist nichts Böses daran.

Und male den Teufel nicht an die Wand - was 51st State "Anschluß" 
betrifft reagieren wir neuerdings sehr empfindlich auf solche 
Anspielungen:-)

Der SW-Unterschied ist eine Hersteller Entscheidung. Es hat mich schon 
sehr gewundert. Zur Zeit warte ich auf eine Rückantwort vom FEI.

Was die I2C Transaktionen betrifft, möchte ich mich noch näher 
hineinknien.

Ich habe am iPad einige I2C Bausteine Datenblätter begutachtet und fest 
gestellt, daß ACK/NAK Protokol Details je nach Hersteller 
unterschiedlich sein können. Ein LM75 braucht ein NAK als Bestätigung 
beim letzten gelesenen Byte vor der STOP Anweisung. Andere Bausteine 
begnügen sich mit ACK vor dem STOP. Das muß man in jeden Fall 
berücksichtigen. Bei Abweichungen kann es passieren, daß folgende 
Datenabfragen inkorrekt ausgehen. Das ist bei jeden Baustein 
unterschiedlich. Bei dem besagten Drucksensor passiert es, daß bei ACK 
folgende Abfragen fehlerhaft sind. Was Arduino WIRE betrifft, ist das so 
eine Sache, weil die Multi-Byte Daten Abfrage kein NAK am letzte Byte 
ausgeben soll. Ich probierte eine Arduino Drucksensor Lib damit aus und 
die funktioniert. Da ich immer meine eigenen Treiber mit SoftI2CMaster 
schreibe, fiel es mir auf, daß es auch bei Einzelabfragen mit ACK 
Folgefehler gibt. Wenn ich NAK verwende funktioniert es zuverlässig. 
Eine Multi-Byte Abfrage funktioniert nur dann zuverlässig mit 4xACK + 
1xNAK. Warum die Arduino Lib funktioniert kann ich noch nicht erklären. 
Ich möchte mich etwas tiefer damit befassen. Auch möchte ich abwarten 
wie CFSensor dieses ACK/NAK Abwicklung sieht.

Im Datenblatt geben sie ein 8051 Beispiel an. In diesem Beispiel 
Programm wird der ACK/NAK nicht vom Host gesetzt, sondern nur abgefragt. 
Das widerspricht dem Standard I2C Protokoll - Der Bus Teilnehmer (Slave) 
erwartet eine solche Bestätigung vom Controller nach jedem Lesen eines 
Bytes, das machen sie aber in dem Programm nicht.

Falls es keine weitere Überraschungen gibt, muss ich davon ausgehen, daß 
die Beschreibung im Datenblatt unzuverlässig ist. In früheren 
Datenblättern (vor V2.9) wird das ACK beim Lesen überhaupt nicht 
angegeben, was eine Protokollverletzung des Standards ist. Im neuesten 
Datenblatt wurde diese Unterlassung behoben und ein ACK angegeben. Ich 
kann das momentan nicht aktuell testen, weil mir momentan noch kein 
neuester Sensor zur Verfügung steht. Nun, Abweichungen gibt es - Man 
denke nur an den ersten Intersema MS5344 Sensor. Bei dem war das I2C 
Protokol auch "verballhornend" umgesetzt und konnte nur als einzelner 
Busteilnehmer eingesetzt werden. Spätere Versionen wurden dann dem I2C 
Standard angeglichen. Wahrscheinlich haben sich damals viele Kunden 
beschwert.

Fazit:

Ich habe aus langjährigen Gebrauch der SoftI2CMaster vollstes Vertrauen. 
Ich schreibe mir fast immer meine eigenen I2C Treiber nach Datenblatt 
Vorgaben und hatte bis jetzt 100% die zu erwartenden Erfolge damit 
gehabt. Ein Fehler der Bibliothek ist also ausgeschlossen. Bei dem 
besagten Drucksensor funktioniert er nur dann zuverlässig wenn ich, wie 
beschrieben mit ACK/NAK umgehe. Warum das Arduino Beispiel funktioniert 
ist mir noch nicht erschlossen und werde es bald näher untersuchen. Ich 
ziehe die SoftI2CMaster ASM Bibliothek vor, weil sie sehr schlank ist 
und nicht von den HW Pins abhängig ist. Sie verbraucht kein SRAM und 
beansprucht nur 240 Bytes. Die Wire Bibliothek ist diesbezüglich 
wesentlich anspruchsvoller. Hat allerdings auch gewisse vorteilhafte 
Eigenschaften. Aber in meiner Anwendung ist mir Schlankheit und Freiheit 
der Pin Zuordnungen wichtiger.

Fortsetzung folgt

Gruß,
Gerhard

[Gerhard O. (gerhard_)]

Nachtrag:

Im Anhang auf Seite 18 kann man sehr schön nachvollziehen, wie das 
ACK/NAK-Spiel abläuft.

Die "Bottom Line" lautet:
1. Der Controller sendet ein Write an das Target, das Target quittiert 
mit ACK.
2. Der Controller empfängt Daten vom Target. Danach sendet der 
Controller ein ACK, wenn er weiter lesen möchte, oder ein NAK, um dem 
Target mitzuteilen, dass die Transaktion beendet ist (ggf. zusammen mit 
Stop).

Im Datenblatt des Sensors wird im Diagramm auf Seite 5 farblich 
angezeigt, wer wem was sendet. Bis kurz vor dem Abschluss ist das 
korrekt. An der markierten Stelle müsste das "A" jedoch vom Controller 
kommen und nicht vom Target, also mit weißem Hintergrund dargestellt 
sein. Der Sinn dieser Bestätigung ist, dem Target zu signalisieren, dass 
das übermittelte Byte erfolgreich empfangen wurde.

Da im Datenblatt fälschlich ein "A" vom Target angegeben ist, würde das 
Target eigentlich im aktuellen Zustand verbleiben, wenn nicht das 
Stop-Signal alles intern zurücksetzen würde. Hier scheint das jedoch 
nicht zuverlässig zu passieren.

Wie bereits erwähnt: Auch beim Lesen eines einzelnen Werts mit 
vorgegebener Pointer-Adresse und anschließendem ACK liefert ein weiteres 
Lesen mit anderer Pointer-Adresse falsche Werte. Erst wenn mit NAK 
gearbeitet wird, funktioniert alles wie erwartet. Auf das Stop allein 
kann man sich offenbar nicht verlassen.

Meine Tests zeigen: Der XGZP erwartet NAK und Stop, um den Datenverkehr 
zu beenden und die State-Maschine in den Wartezustand zu versetzen. Wird 
nur ACK und Stop gesendet, bleibt der Datenzeiger anscheinend stehen. 
Darum geht es hier: um die unklare interne Reaktion des Targets in 
diesem Fall.

Wie versprochen, möchte ich das noch genauer prüfen, um 100 % sicher zu 
sein. Auch will ich mir die Signale noch einmal mit dem Oszilloskop 
ansehen. Oft erkennt man schon an kleinen Spannungsschwankungen gut, wer 
gerade sendet. Mit kleinen Serienwiderständen lässt sich die 
Datenrichtung zudem leichter beobachten.

Erstaunlich finde ich, dass der Hersteller keine sequenzielle 
Lesemöglichkeit dokumentiert. Dabei genügt es, vor dem Lesen die 
Startadresse zu senden und dann fünfmal hintereinander zu lesen (4× mit 
ACK), beim letzten Mal mit NAK und Stop – das funktioniert zuverlässig. 
Warum wird diese Information verschwiegen?

Ehrlich gesagt sind die Datenblätter der bekannten Platzhirsche in 
dieser Hinsicht deutlich zuverlässiger. Meist funktioniert das 
Treiber-Design nach deren Angaben sofort. Naja – Steine werfen möchte 
ich trotzdem nicht;-)

Ich bin gespannt, ob es dazu eine Stellungnahme gibt, und werde 
berichten.

Mich würde außerdem interessieren, ob hier im Forum jemand ebenfalls mit 
diesen Bausteinen gearbeitet hat und ähnliche Erfahrungen gemacht hat.

Gerhard

Nachtrag:

Ich habe noch bei CFSensors herumgestöbert und fand ein ähnliches Sensor 
Datenblatt (XGZP6810D), wo das I2C Kommunikationsprotokoll korrekt 
dokumentiert ist (Seite 5) und sich mit meinen Erfahrungen deckt. Hier 
ist der Link:

https://cfsensor.com/wp-content/uploads/2025/04/XGZP6810D-Pressure-Sensor-V1.1.pdf

Ich habe mir neugierigerweise noch einige andere Sensoren dieser Firma 
angesehen. Alle solcher I2C Typen haben das gleiche Protokoll bezüglich 
NAK + STOP wie der obige 6810 und dieser Ansatz funktioniert auch bei 
mir wie berichtet.