ADC auslesen - Werte ab 2. Abfrage falsch - Python

OP #5902262
Moin,

ich verzweifle hier an meinem ADC, den ich über Python an meinem Raspi 
einlesen will.
Der ADC spuckt mir bei der ersten Abfrage den richtigen Wert raus, ab 
der 2. Abfrage kommt jedoch nur Müll. Ich habe das Gefühl ich habe etwas 
in der Programmierung falsch gemacht, stehe aber auf dem Schlauch.
ADC ist der ADS1100
Mein Code:

*main.py*
1
#!/usr/bin/python
2

3
import time
4
import smbus
5

6
from adcConfig import ADC
7

8
i2c = smbus.SMBus(1)
9

10

11
adctest = ADC(i2c)
12
time.sleep(1)
13
while True:
14
 adctest.getValue()
15
 time.sleep(1)

*adcConfig.py*
1
class ADC:
2
    #DeviceI2CAddress
3
    ADCAddress = 0x49
4

5
    #DeviceI2CCommands
6
    ADCConfigMode =  0x8c
7

8
    #Additional Device Parameters
9
    amountADCReadingBytes = 2
10
    emptyPlaceholder = 0
11

12
    #Initialization
13
    def __init__(self,bus):
14
        ##Configuration
15
        self.bus = bus
16
        self.bus.write_byte(ADC.ADCAddress,ADC.ADCConfigMode)
17

18
    ##Function
19
    def getValue(self):
20
        rawOutput =      self.bus.read_i2c_block_data(ADC.ADCAddress,ADC.emptyPlaceholder,ADC.amountADCReadingBytes)
21
        #VoltageFunction: U = (Code * 5)/32768
22
        voltage = ((rawOutput[0]<<8)+rawOutput[1])*3.3/32768
23
        print(voltage)


Bin noch relativ neu in Python und denke wohl, dass da irgendwo der 
Fehler liegt.
Jemand ne Idee? Danke
Gast
Chris M. schrieb:
> Jemand ne Idee? Danke

Ich würde dir erstmal empfehlen, deine mathematische Berechnung 
aufzubrechen. Nur um hier bezüglich der Shift-Operartionen und 
Operatorenaffinität auzuschließen.

Danach mal Vmax an den ADC anlegen, und den RAW-Wert durch die Formel 
verfolgen. Da dürftest du schnell sehen, ob oben Müll reinkommt oder du 
unten falsch rechnest.
OP
Lothar M. schrieb:
> Chris M. schrieb:
>> ab der 2. Abfrage kommt jedoch nur Müll.
> Immer der gleiche? Oder ändert der sich? Und: was passiert auf dem Bus?
> Kannst du das messen mit Oszi oder LA und mit dem Datenblatt
> vergleichen? Denn so lässt sich ein serieller Bus am einfachsten
> debuggen...

Immer der gleiche Müll ab 2. Abfrage. Habe den LA mal drangehangen, 
komme aber erst heute Abend / morgen zur Auswertung
1. Frame ist der Writebefehl zum Konfigurieren des ADC's
2. Frame ist der erste Readbefehl, der noch die richtigen Werte 
ausspuckt
3. Frame ist der zweite Readbefehl, der dann die falschen Werte 
ausspuckt

Sorry fürs verpfuschte Ausschneiden :)
Edit: Ich habe vom letzten SPI messen die MISO und MOSI's nicht aus der 
Beschreibung rausgenommen, also nicht wundern.

Würde ich jetzt so weiter messen würden, wie gesagt, die falschen Werte 
immer die gleichen falschen bleiben. An dem Wert ändert sich nichts.

Schau dann später mal, ob ich was finde.

absd schrieb:
> Chris M. schrieb:
>> Jemand ne Idee? Danke
>
> Ich würde dir erstmal empfehlen, deine mathematische Berechnung
> aufzubrechen. Nur um hier bezüglich der Shift-Operartionen und
> Operatorenaffinität auzuschließen.
>
> Danach mal Vmax an den ADC anlegen, und den RAW-Wert durch die Formel
> verfolgen. Da dürftest du schnell sehen, ob oben Müll reinkommt oder du
> unten falsch rechnest.

Das stimmt alles. Wie gesagt die erste Abfrage spuckt exakt das aus, was 
sie soll. Die Formel ist sogar im Datenblatt hinterlegt, sollte also 
erst recht nicht falsch sein.

Gruß
Angehängte Dateien:
OP
So habe eben mal ein wenig geschaut.
Der erste Frame der ADC-Config ist komplett richtig und wird auch 
richtig übertragen.
Beim 2. Frame (Read) müsste dort nicht der 8.Bit auf 1 sein, da es ein 
Read-Befehl ist?
Und was ich mich auch frage, was ist dieser komische Sprung bei SCL 
links von der Mitte?
OP
Hier nochmal die Konsolenausgabe im Binärformat...
Habe eben auch nochmal einen Beispielcode aus GitHub ausprobiert mit 
exakt dem gleichen Fehler.
Werde es morgen mal am neuen 4er Pi testen.
Kann es sein, dass mein Kommentar zum "komischen SCL-Bit" vom 
fehlerhaften Clock-Stretching des 3er Pi's kommen kann?
Der wurde ja, wie ich gehört habe, im 4er Raspi behoben.
Naja morgen bin ich schlauer
Angehängte Dateien:
OP
ADC läuft jetzt.

Der Fehler liegt im Read-Befehl. SMBus haut vor dem Readbefehl doch 
wirklich noch ein Write raus. Da dadurch jedesmal meine Konfiguration 
überschrieben wurde, ist es klar, dass nichts mehr sinnvolles rauskommt

Für alle die damit auch mal zu kämpfen haben sollten, hier die Änderung 
die zum Erfolg geführt hat.

Meine Platzhaltervariable wurde durch die Konfigurationsvariable 
ersetzt.

Vorher:
1
rawOutput=self.bus.read_i2c_block_data(ADC.ADCAddress,ADC.emptyPlaceholder,ADC.amountADCReadingBytes)

Nachher:
1
rawOutput=self.bus.read_i2c_block_data(ADC.ADCAddress,ADC.ConfigMode,ADC.amountADCReadingBytes)

Somit kann man sich sogar den Writebefehl in der _init_ sparen.

Danke nochmal an die Idee mit dem LA. Das hat es echt um einiges 
einfacher gemacht.

Gruß

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 7 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.