ElectroYou

Mi trovo a dover leggere i dati da due accelerometri MPU-6050 con comunicazione I2C a circa 3 metri di distanza dalla scheda con il microcontrollore; ora so che non è proprio l'ideale visto che l'I2C non permetterebbe di raggiungere tali distanze senza avere attenuazioni o disturbi sulla linea dati, ma cercando una soluzione mi sono imbattuto su questi "I2C Bus Extender" e in particolare sul P82B715 per cui mi sono detto "proviamo questa via ".

Ho buttato giù uno schema e uno sbroglio per creare una schedina che ospiti anche l'extender:






so che poi nella scheda con il micro dovrò integrarne altri due per le stesse linee.

Unico dubbio che mi sorge sulle resistenze di pull-up che dovrebbero essere calcolare con:

Codice: Seleziona tutto

R = 1 μs/(Cdevice + Cwiring)
where
• Cdevice = Sum of any connected device capacitances
• Cwiring = Total wiring and stray capacitance on the bus section


voi cosa ne pensate ? è possibile calcolarle umanamente o meglio fare qualche prova e trovare i giusti valori ?

Consigli e commenti sempre ben accetti, anche per quanto riguarda il progetto in generale.

Innanzitutto complimenti per l'esposizione del problema e della tua soluzione

Il layout è veramente buono, non è sicuramente il primo che fai
Ci sono due-tre cosette che io farei diversamente, ma sono veramente piccolezze, non so nemmeno se te le voglio dire o meno

Riguardo la capacità per il calcolo dei pull-up: la componente principale è probabilmente data dal cavo. Scegli il cavo e guarda nel data-sheet quanto ti danno di capacità al metro. Aggiungi le capacità parassite degli altri componenti che hai sul bus e usalo come punto di partenza.
Quando poi l'hai assemblato, se sei attrezzato con un oscilloscopio si può cercare di ottimizzare.

Una cosa che non mi piace molto sono i quattro SS16 che caricano il bus con 150 pF ciascuno. Se vuoi una protezione da sovratensioni ci sono componenti apposta a bassa capacità. Per esempio: https://assets.nexperia.com/documents/d ... 233CZ6.pdf

Il PDN (power distribution network) mi sembra un po' fiacco. È un'applicazione che per sua natura pilota carichi capacitivi importanti. È anche vero che i fronti sono definity da pull-ups e quindi ridicoli, ma io sono sempre per l'eccesso di zelo.
Sul lato in basso del layer superiore io ci metterei un poligono dedicato alla distribuzione di Vcc. Inoltre sostituirei l'elettrolitico da 10 uF con 5 MLCC da 2.2 uF (ottieni un'impedenza del PDN molto inferiore). Non mi dilungo adesso sulla scelta dei condensatori (è tardissimo) ma se vuoi domani si può approfondire.
Il pin 8 di U2 deve poi essere collegato direttamente a questo poligono e C1 deve essere veramente vicino! L'altro lato di C1 va collegato al layer inferiore con un via.
Inoltre sono un grandissimo fan del routing completamente sul top-layer per avere così il layer inferiore dedicato completamente al piano di massa. Anche qui ci sono ottime ragiorni per farlo, ma non ne parliamo adesso

Sul progetto in generale: I2C sta per Inter-Integrated Circuit. Che poi lo si stupri portandolo off-board è putroppo prassi comune, come dimostra l'esistenza di questi repeater.
Una possibile alternativa è usare un bus RS-485 (che utilizza lo stesso numero di cavi). Sulla schedina dell'accelerometro non avresti piú il repeater, ma un piccolo microcontroller che si occupa di gestire il protocollo RS-485 e l'I2C. Inoltre ti servirebbe un transceiver.
Insomma, la complessità aumenterebbe di poco, ma avresti una soluzione robustissima e scalabile senza problemi fino a dozzine di schede sullo stesso bus.

Ripeto che l'impressione generale è molto buona e ho visto lavori "professionali" fatti peggio. Se ho scritto molto è solo perché sono un perfezionista e sfegatato adepto del first-time-right

Boiler

Se posso aggiungere un suggerimento (a quanto già detto da boiler) gli elettrolitici SMD di questo genere sono una delle maggiori cause di guasto o malfunzionamento a lungo termine negli alimentatori e in altri circuiti similari.
Potrebbe essere vantaggioso passare alla versione Tantalio o ceramico se scelto con consapevolezza .
Per quanto riguarda il connettore 9 poli utilizzerei 2 pin in parallelo anche per i segnali I2C specialmente se ci sono vibrazioni ecc.
Volendo utilizzare un bus ( in modalità SPI) sempre con due fili ma con maggiori possibilità sia di estensione che di immunità ai disturbi e anche galvanicamente isolato si può utilizzare questo chip dedicato LTC6820
https://www.analog.com/en/products/ltc6820.html
Ciao

Voto dieci alla soluzione proposta da boiler dell'RS-485 Molto più affidabile e sicura. Servirebbero informazioni su ambito utilizzo e numero dei pezzi prodotti. Se è per hobby in singolo pezzo la I2C ci può stare.
Due avvertenze se utilizzi la RS-485:
Ogni dispositivo connesso deve avere un proprio indirizzo quindi devi prevedere un modo X per assegnare l'indirizzo ai vari dispositivi connessi.
Se è possibile che i dispositivi connessi alla linea possano essere disalimentati separatamente attenzione a come colleghi i pullup alla linea perché potrebbe rientrati la tensione sul dispositivo spento tramite il pullup.

boiler ha scritto:Innanzitutto complimenti per l'esposizione del problema e della tua soluzione

Il layout è veramente buono, non è sicuramente il primo che fai

Grazie per me è un grosso complimento visto che sono solo un amatore.

Ci sono due-tre cosette che io farei diversamente, ma sono veramente piccolezze, non so nemmeno se te le voglio dire o meno (...)

Ottimo, sembra ci sia parecchia carne al fuoco ...
A questo punto mi state facendo rivalutare l'idea di usare una comunicazione RS-485, cosa che avevo inizialmente scartato per via di dover programmare un micro solo per la conversione da I2C a UART e poi usare il MAX485 per gestire la RS-485.
Effettivamente come dici non ci sarebbe troppa differenza in termini di componentistica e complessità.

Forse è meglio che vi esponga il progetto per farvi una idea migliore di come gestire il tutto:
in prativo sto provando a realizzare una equilibratrice per rotori, vengono installati degli accelerometri sui due supporti che sostengono il rotore e un encoder vincolato alla rotazione del rotore.
L'encoder e di tipo con indice, quindi la "tacca indice" viene poi sincronizzata con una ghiera graduata visibile vicino al rotore in modo da sapere esattamente dove mettere il peso per controbilanciare:



i due supporti possono fare un piccolo movimento trasversale (hanno una guida che vincola solo quel movimento) in modo da rilevare il sbilanciamento quando viene mosso il supporto.
Il tutto è movimentato da un motore asincrono sotto inverter per controllare i giri in base alle dimensioni del rotore, la velocità massima è di 1080 RPM.

Come potete ben capire è cruciale che la raccolta dei dati dai sensori sia rapida e precisa.

A 1000 rpm, la velocità angolare è di circa 16.67 Hz (1000/60 secondi per giro). Per identificare efficacemente il punto di squilibrio, dovrei campionare ad una frequenza significativamente più alta.

Molto probabilmente userò un raspberry per ricevere, interpretare e visualizzare i dati su due grafici polari in cui vengono segnati i punti di squilibrio.
La scelta del raspberry e' data dal fatto che: è moto veloce, in una unica soluzione posso anche visualizzare su un display da 10 pollici touch tutto il programma di gestione.

Ora io ho gia' fatto delle prove con i sensori collegati a un cavo schermato senza extender o altro, effettivamente i segnali hanno una elevata attenuazione, però sono riuscito a leggerli e a vedere gli squilibri che applicavo via via su un rotore inizialmente bilanciato.

theking0 ha scritto:Ottimo, sembra ci sia parecchia carne al fuoco ...
Forse è meglio che vi esponga il progetto per farvi una idea migliore di come gestire il tutto:
in prativo sto provando a realizzare una equilibratrice per rotori, vengono installati degli accelerometri sui due supporti che sostengono il rotore e un encoder vincolato alla rotazione del rotore.
L'encoder e di tipo con indice, quindi la "tacca indice" viene poi sincronizzata con una ghiera graduata visibile vicino al rotore in modo da sapere esattamente dove mettere il peso per controbilanciare:

Intanto complimenti per l'intraprendenza, e la logica con cui affronti il problema, non è poi così scontato.

Quindi lasci del gioco sull'albero che vai poi a leggere con accelerometro? gia lasciare libero un marchingegno che viaggia a 1000 giri non lo vedo benissimo.

Quindi avrai una lettura di accelerazione sulla massa del blocco? gia la lettura dell'accelerometro non credo possa essere rapida, ma oltretutto nutro dubbi sul conseguente calcolo, dei pesi in gioco e precisione di accelerazione, oltre che per stabilire il punto preciso dove mettere i pesi.

Io avrei pensato ad un sensore di forza applicato al supporto piu esposto allo sbilanciamento, meccanicamente lo trovo piu sicuro, credo possa essere piu veloce la lettura in ADC, e leggendone il picco troverai anche il punto dove applicare i pesi.

Questo è quello che penso io, per fare due chiacchiere, non avendo mai affronato questo circuito, magari vanno benissimo le tue considerazioni in merito.

saluti.

Secondo me sarebbe il caso di utilizzare due accelerometri (o celle di carico o estensimetri) analogici se il problema è la velocità e la tempestività di acquisizione.

Piuttosto si potrebbe dotare il Microcontrollore di un adeguato convertitore A/D esterno con specifiche ottimali per questa applicazione.
Ciao

Il timing potrebbe essere critico e esclude quasi sicuramente la soluzione con il bus RS-485.

Nel tuo sistema rilevi tre grandezze pseudo-contemporaneamente:
- accelerometro 1
- accelerometro 2
- posizione angolare dell'albero

In realtà c'è ovviamente una differenza tra i tre momenti nei quali viene effettuata la misura.

Quanto scostamento puoi accettare al massimo?
E questo scostamento, quanto costante deve essere?

Per esempio, può darsi che tu mi dica che 1 ms di differenza ci sta, ma deve essere costante, contenuto tra 0.99 ms e 1.01 ms.

Boiler

lelerelele ha scritto:

theking0 ha scritto:...

Intanto complimenti per l'intraprendenza, e la logica con cui affronti il problema, non è poi così scontato.

Quindi lasci del gioco sull'albero che vai poi a leggere con accelerometro? gia lasciare libero un marchingegno che viaggia a 1000 giri non lo vedo benissimo.

non e' lascito libero, i supporti sono pensati per chiudere le gli estremi del rotore in un sistema con 3 cuscinetti e poi tutto il supporta ha una piccola mobilità solo trasversalmente, per farvi capire posto una immagine che ho trovato online:



ora in questa immagine manca il cuscinetto superiore che tiene premuto il rotore sugli altri due, ma ti assicuro che tutto e ben vincolato senza possibilità di volare via

Quindi avrai una lettura di accelerazione sulla massa del blocco? gia la lettura dell'accelerometro non credo possa essere rapida, ma oltretutto nutro dubbi sul conseguente calcolo, dei pesi in gioco e precisione di accelerazione, oltre che per stabilire il punto preciso dove mettere i pesi.

Io avrei pensato ad un sensore di forza applicato al supporto piu esposto allo sbilanciamento, meccanicamente lo trovo piu sicuro, credo possa essere piu veloce la lettura in ADC, e leggendone il picco troverai anche il punto dove applicare i pesi.

Questo è quello che penso io, per fare due chiacchiere, non avendo mai affronato questo circuito, magari vanno benissimo le tue considerazioni in merito.

saluti.

si, la mie idea era di leggere un solo asse per accelerometro.

Dal datasheet del MPU-6500 avevo letto che ha una frequenza di campionamento di 32KHz, almeno da quello che ho capito io.
Quindi in linea teorica dovrebbe essere più che sufficiente per lo scopo.

stefanopc ha scritto:Secondo me sarebbe il caso di utilizzare due accelerometri (o celle di carico o estensimetri) analogici se il problema è la velocità e la tempestività di acquisizione.

Piuttosto si potrebbe dotare il Microcontrollore di un adeguato convertitore A/D esterno con specifiche ottimali per questa applicazione.
Ciao

Ho visto su RS che ci sono una marea di tipi di sensori ma hanno un costo non indifferente.
Alla fine quei MPU6050 hanno una risoluzione di 16bit e oltre a essere veramente economici sono molto pratici anche nell'uso, con soluzioni analogiche mi intripperei di sicuro nella lettura con amplificatori operazionali ecc.

boiler ha scritto:Il timing potrebbe essere critico e esclude quasi sicuramente la soluzione con il bus RS-485 (...)

se la differenza resta constante nelle acquisizioni non sarebbe un problema visto che poi potrei compensarla nel calcolo via software.

certo, un ritardo di 1ms su una velocità di 1000rpm avrei un errore di circa 6 gradi sul punto di lettura, ma e' sempre compensabile (se costante) sapendo gli rpm attuali.

L'idea del software di acquisizione sarebbe (in pseudocodice):

Codice: Seleziona tutto


# Variabili globali
GRADI_ATTUALI = 0
RPM = 0
MAX_SQUILIBRIO_S1 = 0
ANGOLO_SQUILIBRIO_S1 = 0
MAX_SQUILIBRIO_S2 = 0
ANGOLO_SQUILIBRIO_S2 = 0
PREVIOUS_Z_TIME = 0

# Funzione per gestire il segnale Z dell'encoder
funzione segnale_Z_interrupt():
    GRADI_ATTUALI = 0
    TEMPO_ATTUALE = tempo_corrente()
    DELTA_TEMPO = TEMPO_ATTUALE - PREVIOUS_Z_TIME
    if DELTA_TEMPO > 0:
        RPM = 60 / (DELTA_TEMPO * FATTORI_DI_CONVERSIONE)
    PREVIOUS_Z_TIME = TEMPO_ATTUALE

# Funzione per calcolare i gradi utilizzando i segnali A e B dell'encoder
funzione calcola_gradi(fase_A, fase_B):
    GRADI_ATTUALI += GRADI_PER_STEP
    GRADI_ATTUALI = GRADI_ATTUALI % 360  # Mantiene il valore tra 0 e 359

# Funzione per leggere e processare i dati del sensore 1
funzione processa_sensore_1():
    lettura = leggi_valore_sensore_1()
    if lettura > MAX_SQUILIBRIO_S1:
        MAX_SQUILIBRIO_S1 = lettura
        ANGOLO_SQUILIBRIO_S1 = GRADI_ATTUALI

# Funzione per leggere e processare i dati del sensore 2
funzione processa_sensore_2():
    lettura = leggi_valore_sensore_2()
    if lettura > MAX_SQUILIBRIO_S2:
        MAX_SQUILIBRIO_S2 = lettura
        ANGOLO_SQUILIBRIO_S2 = GRADI_ATTUALI

# Loop principale
funzione main():
    while sistema_attivo():
        # Lettura dei segnali dell'encoder
        fase_A = leggi_fase_A()
        fase_B = leggi_fase_B()
        if segnale_Z_rilevato():
            segnale_Z_interrupt()
       
        calcola_gradi(fase_A, fase_B)
       
        # Lettura e processamento dei dati dai sensori
        processa_sensore_1()
        processa_sensore_2()
       


Ovviamente il tempo di clock di un raspberry e' ampiamente più grande dei classici micro da 8 .. 16 .. 32 MHz quindi non avrei problemi di lettura da quel lato, l'unico problema per quanto mi riguarda sono i due sensori e il protocollo di comunicazione usato. Poi come detto anche trovo un lag si qualche ms tra le varie conversioni I2c -> UART -> RS485 basta che siano costanti e poi introduco un fattore correttivo nel software di lettura.

Cosa ne pensate ?

Cosa ne pensate ?

Che conosco l'applicazione troppo poco per poder dare giudizi definitivi, ma non mi ispira fiducia.
Le letture che ho chiamato pseudo-contemporanee non lo sono nemmeno lontanamente, sono sequenziali.
E, peggio ancora, non sono atomiche: l'interrupt può esserci una volta tra sensore 1 e sensore 2, una volta prima del sensore 1 e un'altra volta da qualche altra parte.
Inoltre il sistema operativo del raspberry pi ha il suo scheduler che fa un po' quello che vuole.
Sono tutte incertezze che si sommano e producono jitter.
Se raccogli abbastanza campioni, probabilmente l'errore sparisce nella media, ma non è detto (dipende da come è distribuito).

Quando ho letto cosa vuoi fare, i miei primi pensieri sono stati:
- ci vuole una FPGA (poi mi son detto che forse esagero )
- ci vuole un accelerometro con threshold impostabile, al superamento del quale viene generato un interrupt
- ci vogliono accelerometri e encoder con uscita analogica (come già scritto da stefanopc), da campionare con un tre convertitori sincroni (o con una misura interleaved usando il multiplexer d'ingresso di un ADC sufficientemente veloce).

Tornando sull'I2C, ho dato un'occhiata alle specifiche del componente. Non dovrebbero esserci problemi a raggiungere velocità di lettura molto elevate. Probabilmente diverse centinaia di letture al secondo non sono un problema. È che con il tuo sistema non hai sincronia e assegnare un "timestamp" affidabile ai dati che ricevi è praticamente impossibile.

Se vuoi continuare su questa strada, ti elenco un paio di strategie che potrebbero mitigare il problema:
- usa due interfacce I2C indipendenti, usane le API in modo non-blocking e avviane la lettura in un'operazione atomica
- realizza la decodifica del segnale dell'encoder in hardware. I moduli timer/counter dei microcontroller hanno spesso questa funzionalità. In questo modo sgravi il software di molto. Allo stesso tempo puoi impostare sulla stessa periferica la funzione compare che genera un interrupt al raggiungimento di un certo angolo. Questo a sua volta fa partire la lettura dell'accelerometro
- se puoi, usa un canale DMA per la lettura dell'accelerometro
- se puoi, usa la versione SPI invece di quella I2C (timing molto piú deterministico)

Boiler