SF10 an Raspi mit Perl über I2C auslesen

[Defiant]

Erste Frage: Welcher Rpi ist das? 1,2,3 oder 4?
Den SF10 kenne ich leider nicht, das Protokoll klingt aber ähnlich zu dem SRF8 oder 10, macht dein Sensor manchmal Clock Stretching?

[Hectic]

Ey, danke für die Antwort!

Erstmal muss ich mich korrigieren: Es handelt sich natürlich um einen SRF10 von Devantech und NICHT um einen SF10. Kein Wunder dass ich mich mit der Internetrecherche so schwer getan habe.
Beim Raspi handelt es sich um den 3er.
Ob der Sensor Clock Stretching macht ... puh,.. im Datenblatt habe ich dazu nichts finden können. Wie bekommt man sowas raus?

[Defiant]

Clock Stretching: z.B. durch ein Oszilloskop, hat aber zugegeben nicht jeder. Ist aber auch praktisch um z.B. herauszufinden ob die I2C-Signale sauber sind und nicht irgendwie verwaschen durch zu lange Kabel, falsche Pullup-Werte etc.

Dein Verfahren mit 81 schreiben, warten, zwei Byte lesen ist jedenfalls korrekt für den Sensor. Magst du vielleicht mal den Code online stellen und dann gucke ich was bei mir raus kommt?

Es gibt wohl auch offizielle Beispiele in C: https://www.robot-electronics.co.uk/...i_examples.htm - was kommt bei denen bei dir raus?

[Hectic]

Gerne, bin für jede Hilfe dankbar

#!/usr/bin/perl

use warnings;
use strict;
use Time::HiRes ('usleep');
use RPi::I2C;

my $SF10 = RPi::I2C->new(0x70);
my $version = undef;
my $loopcount = 0;

while(1) {
     system('clear');
     $loopcount++;
     printf("Loop: %d\n", $loopcount);

     $version = $SF10->read_byte(0);
     printf("SF10 Version: %d (0x%X)\n", $version, $version);

     usleep(65000);

     last if($loopcount > 100);
}

Ich bin vom Modul Device::I2C zum Modul RPi::I2C gewechselt, da dies wohl neuer ist und einfach um auszuprobieren ob es daran lag. Hat aber am Verhalten nichts geändert.
Momentan wird nur die Version des Sensors ausgelesen. Aber auch bei Entfernungen verhält es sich gleich. Nach der selben Zeit erscheinen völlig falsche Werte (jup, scheint Zeitabhängig, nicht Abhängig von den Zugriffen).
Oszilloskop habe ich leider keines. Evtl. habe ich auch einfach nur den Sensor geschossen, wüsste aber nicht wodurch

Bei dem Beispielprogramm in C kommen bei mir die selben schrägen Werte raus wie wenn mein Programm ein paar Leseversuche hinter sich hat (cooler Link übrigens!)

**** SRF02/10/235 example program ****
Software v: 133
Range was: 32768

- - - Aktualisiert - - -

Was mir noch einfällt: Evtl. könnte noch die Art meiner Stromversorgung eine Rolle spielen.

Das Ganze wird durch einen 12V Bleigelakku versorgt.
MD25 (Motortreiber) hängt direkt am Akku.
SRF10 und Raspi hängen über einen Step Down Wandler auf 5V dran.
Es werden also sämtliche "Geräte" individuell mit Strom versorgt. Aber es hängen natürlich alle drei am selben Bus.
Naiv wie ich bin, dachte ich, dass das schon so laufen sollte (abgesehen vom SRF10 tut es das ja auch).

[Defiant]

ok, ich probier das Montag mal aus. Ich kann zwar kein Perl, aber Programm sieht soweit gut aus.

[Defiant]

Witzig, ich habe das jetzt zwar auch nicht auf dem Oszi analysiert, aber diese Lesefehler riechen stark nach dem Clock stretching Bug [1]. Das Problem ist nicht neu, das Herabsetzen des I2C-Taktes bringt hier Abhilfe ohne Garantien zu geben, der Autor des Perl I2C-Modus beschreibt wie das geht und reduziert den Takt sogar auf 10kHz [2].


[1] http://www.advamation.de/technik/ras...i-i2c-bug.html
[2] https://metacpan.org/pod/RPi::I2C#Raspberry-Pi

[Hectic]

Super! Also eigentlich nicht, aber super, dass du dir so viel Mühe gegeben hast! Ich werde der Sache in diese Richtung weiter folgen und berichten wenn ich Erfolg hatte. Das kann aber etwas dauern. Vielen Dank, das hilft mir schon sehr weiter.

[Hectic]

Hi nochmal,

die Lösung, die Baudrate zu reduzieren funktioniert einwandfrei! Eine niedrige Baudrate stört wohl in den wenigsten Fällen weshalb dadurch zumindest mein Problem komplett behoben wird. Vielen Dank nochmal, dass du dir die Mühe gemacht hast!