Pinhapple a écrit :
...
Mais non !
Un système envoyant et recevant un signal en continu, le tout en rotation, ça vous parle ?
....
A chaque lecture d'une valeur, je l'ajoute à une liste. J'ai autant de listes que de DOF à mesurer, donc 9 dans mon cas : vitesse angulaire, angle, accélération, le tout sur 3 axes. Tous les calculs sur ces valeurs (conversion, écriture dans un CSV, etc.) sont faits une fois les enregistrements terminés.
spourre a écrit :nombre de lecture max = débit I2C / (taille échantillon x nombre échantillon).
Je tente le calcul, qu'on m'arrête si je me trompe : avec un débit de 100 kbit/s = 100 000 bits/s ; la taille d'un échantillon vaut 16 bits (2 * 8 bits si je comprends bien la datasheet) ; il me faut 9 échantillons.
=> 100 000 / (9 * 16) = 100 000 / 144 ≈ 694 échantillons/s. J'ai bon ? Honnêtement, 500 échantillons/s ça m'irait bien
Un derviche tourneur ?
(j'ai bien une autre idée mais je la garde pour respecter la neutralité politique de ce forum
)
La lecture en différé est une nouvelle information qui a son importance. Cela implique un programme de lecture assez rapide.
Par contre, quel est la période de mesure ? ça peut générer une forte volumétrie et c'est dimensionnant pour la taille du "tampon" en RAM, avant d'écrire sur la carte SD.
Encore une fois, mon approximation ne donne qu'une estimation à la louche mais c'est un point de départ.
N'oubliez pas de vérifier toutes les restrictions déjà émises:
- Si le LSM peut échantillonner à cette vitesse.
- Si l'I2C le permet (en tenant compte de la stabilité minimum des signaux )
- Si le Raspberry n'est pas surchargé par des services inutiles
Vous devez éplucher finement la data-sheet pour trouver ces informations. Comme l'a mentionné Bud, c'est un vrai roman. Je l'avais parcouru en diagonale pour répondre utilement à vos premières questions mais là, il faut aller dans le détail (le diable se niche dans les détails).
Sylvain