Forum: Mikrocontroller und Digitale Elektronik ADC auslesen - Werte ab 2. Abfrage falsch - Python


von Chris M. (chris_appment)


Lesenswert?

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

: Bearbeitet durch User
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von absd (Gast)


Lesenswert?

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.

von Chris M. (chris_appment)


Angehängte Dateien:

Lesenswert?

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ß

: Bearbeitet durch User
von Chris M. (chris_appment)


Lesenswert?

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?

von Chris M. (chris_appment)


Angehängte Dateien:

Lesenswert?

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

von my2ct (Gast)


Lesenswert?

Chris M. schrieb:
> Sorry fürs verpfuschte Ausschneiden :)

Viel störender ist der nicht aktivierte I2C-Decoder.

von Chris M. (chris_appment)


Lesenswert?

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ß

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
Noch kein Account? Hier anmelden.