Arduino remoto su ROV, possibile trasferire dati via network ?

Salve a tutti, mi scuso se il titolo e' un po criptico, ma la domanda richiedeva una spiegazione troppo lunga e non ci stava ...

Comunque, permettetemi di spiegare il problema, cosi la cosa diventa (forse) un po piu comprensibile (se cosi non fosse, siete pregati di non cominciare subito a fare tiro a segno ... o almeno di non usare pallettoni, che fanno male ... ).

Ho un'applicazione su un ROV che, tramite un'interfaccia lan remotata attraverso un EOP (al momento un TPLink TL-PA211) mi invia al ROV 8 segnali 1/0 (divisi in due word da 4 bit, che decodifico in remoto ed uso per il pilotaggio), e dal rov alla superficie 8 segnali, sempre 1/0, che uso come controlli di stato, piu un'interfaccia RS485 bidirezionale per il sonar ... il tutto sovrapposto all'alimentazione a 250VAC, insieme ad un paio di portanti video analogiche a 50-60MHz per le camere, su un coassiale neutro da 450 metri (il ROV potrebbe andare anche piu giu, ma il cavo e' un "recupero" di seconda mano che viene da un precedente ROV "defunto", e solo quello c'era)

Ora, volevo spedire in superficie alcuni segnali dati (bussola, profondimetro, termiche, sonda PH, ed alcune altre cosette), ma l'interfaccia di pilotaggio non lo consente ... vero che mi remota una RS485, ma il sonar che la usa ha una carogna di protocollo di comunicazione che si prende la RS485 in esclusiva, qualsiasi tentativo di inserirci qualsiasi altra cosa manda in tilt il sonar e lo blocca ... mi hanno detto che forse un'arduino potrebbe coesistere con il canale lan utilizzato dall'interfaccia comandi e mandarmi tutti i segnali in questione, via altro canale lan, direttamente al PC che gestisce il sonar ... se fosse vero, potrei connettere un secondo schermo e visualizzare su quello tutti i dati, pero'ì mi serve sapere se arduino e' in grado di fare una cosa del genere.

Vale a dire, puo leggere tutti i sensori e mandarmi i dati in superfice attraverso lo stesso cavo lan dell'interfaccia comandi, usando uno switch di rete per separare i due protocolli ? ... tenete presente che, usando la coppia di TL-PA211, sarebbe come connettere tutto quanto con un singolo cavo ethernet, con uno switch in superficie che separa interfaccia e PC, ed uno switch in remoto che separa arduino ed interfaccia.

Inoltre, ma questo e' un diverso problema e non vorrei complicarmi la vita un po troppo, arduino sarebbe in grado, contemporaneamente, di sostituirmi anche l'interfaccia di decodifica dei comandi ?

Al momento, per comandare tutte le periferiche, ho costruito un'interfaccia basata sui vecchi ed affidabili CD4515, che mi decodificano le due word da 4 bit e mi generano tutti i segnali di comando e controllo per motori, fari, pinza, scambiatore per le camere, comandi della camera principale (zoom, rec, ecc), e cosi via ... mi hanno detto che arduino potrebbe fare anche tutto questo, in contemporanea alla gestione dei segnali, ma la cosa e' realmente fattibile ? ... se cosi fosse, mi si semplificherebbe in parte la gestione della macchina ... anche usando componenti SMD il piu possibile, non e' che le schede di decodifica e pilotaggio vengano proprio piccole, e lo spazio nel barilotto stagno di un ROV non e' che abbondi proprio ...

Comunque, al momento ho inutilizzato un mega2560, pensate che sarebbe in grado di reggere il tutto ?

puoi fare quello che dici.

Arduino ha una Seriale Hardware che normalmente viene lasciata libera (per programmarlo, grazie al boot-loader), ma può far coesistere più Seriali via Software, anche se può ascoltarne solo una alla volta. A questo punto ti basta un chip RS485 -> RS323 ttl/i2c/spi e poi di nuovo RS232tll/i2c/spi -> RS485 e puoi:

1. leggere tutti i sensori, sonar compreso, da arduino
2. usare arduino per creare un bel pacheetto dati come più ti piace
3. spedire i dati sul cavo esistente

Quindi arduino diventa il tuo "controllore di traffico" sulla RS485.

Se poi i vari sensori hanno interfaccia i2c o SPI ancora meglio, perchè puoi leggre più sensori senza usare l'implementazione software e i un chip esterno che faccia da bridge tra protocolli...

edit: vedo che hai un mega... meglio, hai molte più periferiche hardware, oltre che ram da vendere. Secondo me è pure troppo

Ciao, grazie per la risposta ... il problema del sonar e' che il suo protocollo custom di comunicazione e' un bastardo con i fiocchi ... qualsiasi tentativo di usare un multiplex o di gestire piu di una porta sulla stessa linea lo fa andare in timeout, vuole la comunicazione sempre ininterrotta (e' il motivo per cui in origine ho preso quelle interfacce che oltre alle otto linee up ed otto down, mi remotano anche una RS485 che uso solo per il sonar, per cui quello ora e' a posto) ... il mio dubbio era se, dato che gia quelle interfacce comunicano via lan, la lan dell'arduino pèoteva coesisterci (ovviamente tramite uno switch) ... un po come due coppie di computer che comunichino fra di loro sullo stesso cavo di rete, ma in modo indipendente uno dall'altro.

Oltretutto l'interfaccia industriale puo essere impostata in modo che le due schede accettino di comunicare solo con il mac id dell'altra, quindi loro non dovrebbero essere disturbate dall'arduino, il dubbio era solo se l'arduino avrebbe potuto essere disturbato da loro, ma se mi confermi che la cosa e' fattibile, per me e' gia un passo avanti ... poi state tranquilli che quando sara' il momento di imparare come fare a programmare le varie funzioni, ve li rompero' non poco (scherzo ... spero :D) ... ma gia sapere che una cosa PUO essere fatta, e' molto meglio del partire con un tentativo senza neppure sapere se potra' funzionare o no.

Per i sensori, alcuni sono in I2C, come la bussola (il buon vecchio HMC5883L), altri sono in analogico (le termiche ed il profondimetro, ad esempio, che e' un trasduttore di pressione da 100BAR con uscita 0-5V, ed altri ancora li devo costruire, quindi se li trovo dotati di interfaccia I2C prendo quelli, se no dovro' leggerli tramite qualcuna delle porte A/D ... ed anche in questo caso, se non dovessi avere abbastanza porte, potrei multiplexarle (ad esempio, le termiche sono tutte NTC identiche da 10K, posso benissimo costruire un circuitino esterno che, pilotato da 3 linee di out dell'arduino, mi collega 8 sensori a turno ad una sola porta A/D (o usando 4 linee di out, 16 sensori :P), e leggerle in sequenza, tanto anche se le leggo una ogni secondo, non c'e' nessun problema, non mi servono in tempo reale ...

ora io non conosco ilprotocololo, ma se non è troppo complesso, puoi far credere al sonar che l'arduino è il pc, con relativo programma (immagino sia così no?), quindi a quel punto non solo puoi prendere i dati del sonar, ma pure pulirli dal protocollo indesiderato.

Visto che parli di switch mi viene da pensare che hai un circuito da seriale a ethernet.. nel qual caso ti consiglio di dare un occhiata aalla ethernet shield, anche se non pare stabilissima, almeno l'ufficiale.

Per i sensori sappi che leporte analogice sono già multiplexate (e non ho idea di cosa possa sucedere se multiplexi ancora se bisogna fare qualcosa di particolare), ma con la 2560 non credo avrai bisogno di ulteriori porte analogiche... oppure anche un ADC i2c può essere un'idea, costa poco e magari ti da pure qualche bit di precisione in più

sembraun bnel progettone di sottomarino... hai per caso qualche link?

Ciao, no, al momento non ho link, non e' una macchina che sto realizzando per la vendita, e' un ROV che sto realizzando insieme ad un gruppo onlus per l'esplorazione subacquea, in sostituzione di un vecchio modello della Mariscope che avevano gia prima, ma che al momento e' "leggermente defunto", e che quindi parte da zero.

O meglio, se ci va bene, almeno lo chassis lo recuperiamo da una ditta commerciale che ci lascerebbe uno dei loro chassis che usavano come prototipo ad un prezzo ragionevole (intendo "ragionevole" in confronto a quelli commerciali ... sempre comunque molto meno che doverlo comperare da nuovo o farlo realizare in un'officina specializzata negli assemblaggi inox) ... dovrebbe essere questo qui : http://www.freeimagehosting.net/yynmc

Il sistema di trasmissione dei comandi non usa convertitori ethernet, si tratta di una coppia di interfacce industriali che escono direttamente con la loro presa di rete, e sono fatte per remotare a lunga distanza 8 segnali in andata, 8 in ritorno, piu una RS485 in bidirezionale, sono tipo queste qui: http://www.hw-group.com/download/IO_Controller2_MAN_en.pdf (questo e' il modello nuovo, io ho quello vecchio in rail DIN, ma le caratteristiche sono simili) configurate in modalita' "box-to-box"

Per il sonar, purtroppo ci ho gia provato in tutti i modi, il sonar e' un Tritech Micron che esce direttamente in RS485, e che funziona solo ed esclusivamente con il suo programma, e solo se il PC su cui gira il programma vede il sonar connesso direttamente (dal cavetto del sonar al PC uso un convertitore RS485/USB, e persino quello lo si e' dovuto comperare di un modello specifico, perche' se non e' il modello che vuole lui non funziona) ... e sul vecchio ROV si era dovuto aggiungere un cavo esterno avvolto intorno a quello principale, per portare su il segnale RS485, perche' nessuno dei convertitori che sono stato in grado di provare e' mai riuscito ad inviare il segnale attraverso il cavo principale, ne come portante modulata, ne come segnale sovraimposto, ne come pacchetti digitali ... credimi, ci ho gia bestemmiato sopra per mesi, e poi ci siamo dovuti arrendere ed aggiungere un secondo cavo bifilare, con tutti i relativi problemi ... ora con la nuova configurazione mi passa attraverso lo stesso cavo utilizzando la RS485 che viene remotata in bidirezionale attraverso questa interfaccia, e con questa funziona, ma con niente altro.

Inoltre, questa interfaccia mi manda al rov i comandi della console (in forma di 2 word da 4 bit, una per la meta' destra ed una per la meta' sinistra della console, usando gli 8 ingressi), e mi rimanda in superfice 8 segnali di stato, ma solo di stato ... il ritardo di azionamento fra locale e remoto e' di circa 20mS, quindi non posso usarle come linee dati, posso solo far accendere delle spie, ma nientre altro ... per questo volevo sfruttare la presa ethernet del mega2560, e farlo comunicare attraverso uno switch sulla stessa linea lan con il PC che gia gestisce in sonar, ed usarlo per mandare in superfice tutti i dati dei sensori (e, se possibile, fargli anche sostituire la mia scheda di decodifica dei segnali di pilotaggio, che al momento usa i CD4515 come decoder per le 2 word dei comandi dalla console) ...

Tanto per farti un'esempio, questo e' il disegno di una delle schede che ho riprogettato per il vecchio ROV ... l'originale pilotava due fari on/off, i comandi della telecamera principale (zoom, rec, foto, data, power) e la pinza, tutto a rele, sulla mia usando lo stesso numero di comandi in modo diverso (perche' non se ne potevano aggiungere altri) e un po di "robaccia" SMD ( ) ho aggiunto lo scambiatore ciclico per 4 telecamere sullo stesso trasmettitore (principale, camera pinza, camera navigazione e camera retro), un banco di fari per la retrocamera, una protezione a ripristino automatico per i sovraccarichi e l'accensione/spegnimento remoto del sonar ... http://www.freeimagehosting.net/m98j9 ... e' incasinata abbastanza, secondo te ? (e' rotonda perche' tutta l'elettronica originale e' composta da varie schede impilate a sandwich in un barilotto cilindrico ... non e' male come sistema per risparmiare spazio, ma quando ci devi mettere le mani per riparare o modificare qualcosa, ti assicuro che diventa un'incubo formato famiglia, specialmente perche' tutte le schede originali avevano tutti i valori e le sigle dei componenti cancellate per non farsele copiare, per cui la mia l'ho dovuta riprogettare partendo dal nulla :P)

Secondo me è fattibile.
Mi pare di capire che l'IO Controller comunichi con un protocollo TCP, quindi a questo punto potresti prendere una power line a 2 porte (c'è un modello netgear) e collegare lato ROV una porta all'IO Controller e l'altra ad un Arduino Ethernet (oppure UNO + Eth Shield o MEGA + Eth Shield).
Con la MEGA potresti pensare anche di collegare, invece della Ethernet shield col Wiz, una Shield col ENC28J60, pare dia meno problemi anche se la gestione dei protocolli deve essere effettuata dall'Arduino, ma con la MEGA hai spazio a volontà.

Per il resto dall'altra parte del cavo useresti un semplice switch e le varie periferiche collegare avrebbero, come è necessario, indirizzi IP diversi.
Non avresti problemi di instradamento perché se ne occupa lo switch e l'IO Controller non dovrebbe interessarsi alle comunicazioni non dirette a lui.
Puoi fare una prova inserendolo in una LAN con altri PC.

Per quando riguarda i sensori servirebbero i datasheet di ciascuno per capire la modalità di interfacciamento.

Ciao, si le interfacce I/O comunicano in quel modo e le ho impostate come "box-to-box" (che e' come se le uscite e gli ingressi delle due fossero connessi fisicamente, ed inoltre colloquiano solo fra di loro ignorando qualsiasi altro dispositivo presente), e li accoppio attraverso il coassiale che porta l'alimentazione attraverso due EOP (o powerline, se preferisci) ... ho gia sia una coppia di TL-PA211, sia gli switch, dei TL-SF1005D, tutto della TPLink (e tutto gia smontato dai relativi contenitori per risparmiare spazio ;P) ... dalle prove fatte a banco (senza gli switch), gia ho visto che viaggiano attraverso tutto il cavo senza problemi ...

Il mega che ho io e' una vecchia release che mi ha regalato un'amico, lo aveva preso per giocarci anni fa, poi non lo ha piu usato e lo ha dato a me ... non ho idea di che versione sia, perche' a parte "arduino mega 2560" non c'e' scritto niente altro ... Volevo usare questo perche' e' gia qui e posso giocarci un po, ma anche se non dovesse andare bene posso sempre comperare una rev 3, con tutto quello che ci stiamo buttando in questo ROV, non sono certo i 39Euro di una nuova board a crearci problemi ...

Per l'ethernet, piu che una shield volevo trovare un modulino il piu piccolo possibile, e poi cablarlo direttamente sullo switch, sempre per motivi di spazio ... ad esempio, se qualcosa di questo tipo funzionasse http://www.ebay.com/itm/1pcs-ENC28J60-Ethernet-LAN-Network-Module-Schematic-For-Arduino-51AVR-LPC-STM32-/300882740890?pt=LH_DefaultDomain_0&hash=item460e02469a , potrei dissaldare i connettori, cablarlo direttamente sulla schedina dello switch, e portare una piattina alla scheda su cui vorrei montare l'arduino in reverse, usando i connettori dei segnali (cosi posso sfruttare anche lo spazio che rimane fra l'arduino e la scheda di supporto per metterci alcuni dei componenti delle interfacce, se serve ... oppure trovare un chip e saldarlo direttamente sulla scheda di supporto, integrandoci cosi anche la lan ... in fondo, non e' che ce ne sia poi molto di spazio, in un ROV) ... comunque questi sono problemi secondari per me, a lavorare con queste cose ci sono abituato ... quello che mi frega e' sempre la parte software.

Per la prova, si, potrei anche fare cosi, oppure anche assemblare le interfacce con gli switch, poi collegarci un paio di portatili e metterli in rete, cominciare a trasferire un sacco do files da uno all'altro e vedere se si disturbano a vicenda ... o meglio ancora, recuperare un modulo ethernet per il mega, collegarlo ad un portatile, e vedere cosa succede ... pero' per fare questo mi serve di capire come gestire questo ENC28J60 ... tu dici che i protocolli dovrebbero essere gestiti dal mega, ma cosa intendi esattamente, scusa ?

Ricordati che io sono un profano, per quanto riguarda arduino, per cui abbi pazienza se le mie domande sembrano stupide, ok ? ... intendi che per utilizzare quel chip servono librerie specifiche, o che l'intero protocollo di rete dovrebbe gestirlo arduino ? ... ed in questo caso, cosa comporterebbe a livello di software ?

Comunque non sono certo di corsa, il progetto va avanti da un bel po, e chi da una mano lo fa nel tempo libero ... per cui, ammesso che ci riesca, di tempo per imparare qualcosa in piu dovrei averne abbastanza ... forse ... spero ... be, qualche martellata al cervello per scrostare la ruggine, e poi si vedra'

Non avevo capito che avessi già tutto il materiale... bene mi sa che ti serve solo il modulino con l'ENC.
La MEGA 2560 va benissimo, non c'è bisogno di comprare una Rev3, anzi non è neanche così vecchia. Pensa che le prime mega erano le 1280 e anche con quelle ci saresti andato di lusso.
La differenza principale tra il chip Wiz5100, montato sulla Shield Ethernet ufficiale e non, e i chip ENC28J60 e che i secondi hanno la gestione del protocollo di comunicazione a carico del microcontrollore, mentre nel primo caso è integrata nel chip.
Questo porta vantaggi e svantaggi. Lo svantaggio è che devi inserire nel codice di gestione del micro la libreria che comprende anche la gestione dei flussi della Ethernet, il vantaggio e che puoi modificare a piacimento il protocollo o inserirne di nuovi, cosa non possibile col Wiz5100 perché programmato in fabbrica.
In soldoni vai a occupare più spazio in memoria su Arduino, ma se è già possibile gestirlo, con limitazioni, su una UNO con 32Kb, su una Mega con 256Kb non hai questi problemi. Ci stai molto largo.
Le librerie sono facilmente reperibili su internet e l'unico problema, da verificare, è la tensione di funzionamento, 5V di Arduino e 3V3 quella dell'ENC, quindi se il modulo non prevede un sistema di commutazione della tensione dei segnali dovrai interporne uno tu.

Per quanto riguarda la MEGA, se hai la necessita di spazio puoi reingenerizzare la scheda creandone una custom pero sappi che il chip e un TQFP con passo 0.5mm, non proprio uno scherzo sia da saldare che per creare le piste del pcb. Molto meglio la soluzione con incastro rovesciato, spazio permettendo.

Per il software non ti devo preoccupare, Arduino è molto semplice da programmare e trovi, qui sul forum o sulla rete, tantissimi spunti. Non ultimo, c'è tutta una comunità che ti da supporto: non scriviamo il codice al posto tuo, ma se abbozzi la struttura o se hai problemi o punti che non riesci a risolvere, ti daremo volentieri una mano; quello che ti si chiede in cambio, se vuoi e puoi, è la condivisione del lavoro finale con la comunità (fosse anche un pezzo di codice o una libreria per l'uso di un particolare sensore).

A proposito di sensori, senza datasheet e senza conoscere le interfacce di collegamento sarà un po' difficile farli colloquiare con Arduino.

Ti lascio il link di un tutorial in 12 parti sull'uso combinato di Arduino e una shield ethernet con l'ENC28J60 cosi ti fai un'idea.
--> http://www.lucadentella.it/category/enc28j60-arduino/page/2/

Ilprotocollo TCP ruba anche tanta RAM e tanta CPU, ma come detto l'ENC da meno problemi. Non so se la libreria è compatibile con la mega1280 o superiori però, controlla.
Se poi vuoi proprio stare sul sicurto prendi un convertitore seriale rs232ttl a rs485 e stai in una botte di ferro.

io ti consiglierei di giocare un poco con l'arduino per farti un'idea, ma se ne sai un poco di C vedrai che in meno di una giornata capirai le sue potenzialità e la sua semplicità

Si, la libreria è compatibile perché si poggia sulla libreria SPI ufficiale
--> GitHub - njh/EtherCard: EtherCard is an IPv4 driver for the ENC28J60 chip, compatible with Arduino IDE

Riguardo al consumo di ram, non deve gestire un Web server ma mandare pochi dati dei sensori via ethernet. Non dovrebbe avere problemi con la Mega 2560. 8)

PaoloP: grazie, specie del tutorial, me lo scarico e provo a dargli un'occhiata in questi giorni, cosi (spero) mi faccio un'idea un po piu precisa di dove vado a sbattere la testa ... per quanto riguarda i sensori, al momento ho in casa solo le NTC da 10K a 25C ... ne ho una cinquantina, ma all'atto pratico pensavo di metterne una per ogni motore (per ora progettiamo di usarne 4, la soluzione con 6 prevede un po troppo lavoro oppure un controller indipendente, ma non si sa mai ...), piu una nel barilotto dell'elettronica principale, una nel barilotto delle alimentazioni ed una esterna per la temperatura dell'acqua ... ho visto che il mega2560 dovrebbe gestire fino a 16 ingressi analogici, quindi ce n'e' d'avanzo, mi pare ... poi c'e' la bussola, ho preso uno di questi http://www.ebay.com/itm/110950932755?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649 , il classico 3 assi con l'HMC5583L, ho visto che da parecchie parti lo spacciano come "bussola per arduino" ... di sicuro non e' di uso "immediato" come lo spacciano i venditori, ma il fatto che fosse pubblicizzato come "per arduino" mi ha fatto immaginare che ci siano gia in giro librerie o routine in grado di gestirlo senza troppi problemi (spero, almeno, comunica in I2C, quindi dovrebbe essere possibile leggerlo senza troppi problemi) ... il profondimetro e' un trasduttore da 100BAR massimi (il che dovrebbe dare una profondita' massima di poco piu di 1000 metri, anche se non ci arriveremo mai :P), che ha un'uscita in tensione che va da 0V (0BAR) a 5V (100BAR) ... e' l'unico che ho trovato con quella portata e che fosse anche "alla portata" delle mie tasche, al momento ... penso sia possibile farlo leggere ad uno degli ingressi analogici, e se l'escursione di tensione fosse troppo piccola, posso sempre disaccoppiarlo con un'operazionale per moltiplicare l'uscita, ad esempio moltiplicandola per 2, mi darebbe 5V ad una pressione di 50BAR (poco piu di 500 metri) ... c'era anche la versione current-loop, ma dato che e' nello stesso barilotto dell'elettronica, non aveva molto senso.

Sensore per la conduttivita', per quelle pressioni non ne ho trovati, ma ho pensato di costruirmelo ... due stupidi elettrodi placcati in oro che escono da un blocchetto di resina solida in cui annegare il circuito di lettura, e siccome devo farmelo io, posso dargli l'uscita che voglio, il sistema piu semplice e' un'uscita in continua, proporzionale (come per il profondimetro), da far leggere ad un'altro degli ingressi analogici ...

Per gli altri sensori, stiamo guardando cosa offre il mercato ... pensavamo ad un sensore per il Ph, ma mi sa che ci rinuncio, quelli standard sono di una fragilita' mostruosa, mentre per quelli industriali, la ABB mi ha sparato un preventivo di 600 dollari per uno di quelli garantiti solo fino a 100 metri, ti lascio immaginare cosa potrebbero chiedere per un modello che regga 500 metri ... faccio prima a spararmi ...

Se vorranno fare altri esami, dovranno farli in superfice, progettero' un sistema per raccogliere campioni di acqua o del fondale, in grado di riportarli su senza contaminarli durante la risalita e senza perderli ... l'unico vero problema e' la quantita', quelli che fanno analisi vogliono almeno un paio di litri di acqua ... e non basta un recipiente a tenuta stagna, se lo riempi a 400 metri il contenuto e' a 40 atmosfere ... un paio di litri di aria a 40 atmosfere non pongono alcun problema, ma un paio di litri di ACQUA a 40 atmosfere ... quando risali o scoppia durante la risalita, o scoppia in faccia al primo che lo apre (e cio non e' bello ] ... farebbe meno danni una granata) ...

Lesto: meno di una giornata ? ... non sai cosa dici ... fra gestire il negozio, stare dietro alla contabilita' ed alla burocrazia, e problemi vari in famiglia, in questo periodo non so piu dove metterli, tutti quei 10 minuti AL MESE di tempo libero che mi avanzano ...

EDIT: dimenticavo, io a condividere tutto quanto non ho il minimo problema, ma con un'esperienza di zero, che aiuto potrei dare ? ... se si tratta di hardware o di prototipi (o anche di invenzioni pazze :P), forse un minimo posso essere d'aiuto, ma sul software sono a zero ...

allora un pò di cose al volo:

1. la bussola sarà fortemente influenzata dallo scafo metallico e dai motori. non mi stupirei se risultasse inutilizzabile. (però in compenso sì, esistono mille librerie per arduino che la rendono immediata.. colleghi 4 fili SCL SDA 5v e GND, carichi l'esempio et voilà, i tuoi valori sul serial monitor)
2. 0V (0BAR) a 5V (100BAR), quindi 0.05 V/bar. ora con un ADC a 10bit vuol dire che leggi valori da 0 a 1023 (1024 valori, detti lsb), dove 0lsb = 0v e 1023lsb = 5v, quindi 1lsb = 0,0048828125. Quindi se hai un errore di +-5lsb (il minimo che puoi ottenere è +-1lsb) hai la precisione di 1BAR (~10 metri?), se scendi a +-1lsb hai la precisione di 1/3 (~3 metri?) di BAR. c'è da vedere se il sensore è così preciso, o è solo rumore quello che leggi. Serirebbe il datasheet

e se l'escursione di tensione fosse troppo piccola

abbassi il reference a 3.3V, o a 1.1V, dato che rimangono comunque 1024 step di lsb e vengono tagliate le tensioni suiperiori (nel senso che ritorna 1023 fisso), rifatti i calcoli per vedere la precisione finale (e poi c'è sempre da vedere il sensore cosa dice)

due stupidi elettrodi placcati in oro

basta qualsiasi metallo meno "pregiato" che non faccia ossidazione. Per esempio acciaio inox (in particolare acciaio 18/8/3 codice AISI 316) (da wikipedia Acciaio inossidabile - Wikipedia)

il ritardo di azionamento fra locale e remoto e' di circa 20mS

uhmm qui vorrei capire bene perchè quaesto ritardo... e cosa intendi per dati.

in caso posso rivedere o aiutarvi a stendere il codice, sarebbe interessante.. ma non ti aspettare che faccio il lavoro per te. Anche io ho il tempo per gli hobby contato

lesto:

1. la bussola sarà fortemente influenzata dallo scafo metallico e dai motori. non mi stupirei se risultasse inutilizzabile ....

Si, avevo lo stesso dubbio, almeno per quanto riguarda i motori (lo scafo e' di acciaio inox, in teoria non dovrebbe influire piu di tanto) ... pensavo di piazzarla in un punto il piu distante possibile da tutti gli elementi magnetici, magari sopra, al centro del pannello galleggiante di tarmanto sulla superficie del ROV, annegata in un blocchetto di resina ... pero' purtroppo questo tipo di prove le potro' fare solo ad assemblaggio completato.

... 0V (0BAR) a 5V (100BAR), quindi 0.05 V/bar. ora con un ADC a 10bit vuol dire che leggi valori da 0 a 1023 ...

ahi ... non avevo considerato che l'ADC fosse solo a 10 bit ... mi sa che se voglio un minimo di precisione mi tocca usare un'ADC da 16 bit o piu ... potrei collegarlo ad un chip esterno senza problemi, ma poi come lo leggo ... dubito che ci siano librerie gia pronte per leggerli ... pero' non si sa mai ... ad esempio questo : http://www.analog.com/static/imported-files/data_sheets/AD7984.pdf ... 18 bit, quasi esagerato, ma abbastanza economico, 15 dollari inclusa la spedizione ... il problema principale e' il case MSOP , 0,3 mm di terminali sono un pochino piccoli da lavorare a mano ... oppure c'e' questo, in DIL, http://focus.ti.com/lit/ds/symlink/ads1210.pdf ... piu "maneggevole", ma quasi esagerato come capacita' ... secondo te' sarebbe possibile interfacciarli ?

basta qualsiasi metallo meno "pregiato" che non faccia ossidazione. Per esempio acciaio inox

Lo so, ma gli elettrodi placcati in oro li ho gia, di recupero da un'altro aggeggio, per cui non mi costerebbero nulla ... e poi, hai mai provato a fare saldature a stagno decenti sull'inox ?

iuhmm qui vorrei capire bene perchè quaesto ritardo... e cosa intendi per dati.

Intendo dire che il ritardo intrinseco della coppia di interfacce e' di circa 20 mS ... cioe', quando chiudi un'ingresso su una, la corrispondente uscita sull'altra si chiude dopo circa 20mS (anche perche' queste interfacce campionano gli ingressi ogni 10mS, quindi anche se l'azione fosse istantaneam il che non e', il ritardo minimo sarebbe sempre di almeno 10mS ... nella pratica, ho constatato ritardi che vanno da 15 a 20mS, quindi considero normale il ritardo massimo che ho misurato) ... per dati, intendevo semplicemente che, visti questi ritardi, non posso usare le linee che ritornano in superfice per trasmetterci dati, ma solo segnali di stato on/off.

No, non mi aspetto che mi scrivi il codice tu (sarebbe troppo bello :P) ... ma sto cercando di raccogliere il maggior numero di informazioni possibili, prima di mettermi a fare prove, cosi almeno quando parto avro' gia un'idea di quello che e' possibile e soprattutto di quello che NON e' possibile fare, e (forse, spero, magari :D) non dovro' perdere un sacco di tempo in tentativi per fare cose che gia si sa che non funzionano.

L'ADC esterno potresti prenderlo con interfaccia I2C, quelli che hai postato hanno interfaccia SPI. Siccome sulla SPI c'è già collegata la Ethernet, anche se è possibile collegarci n periferiche, è consigliabile non utilizzarla per altro. Ti eviti una parte di codice deputata allo swap tra le 2 due periferiche e eventuali problemi sulle trasmissioni.
Per l'interfaccia I2C è presente già la libreria Wire che la supporta e sarebbe da integrare solo il protocollo specifico dell'ADC. Può anche essere che si trovi del materiale già pronto in rete.
Ad esempio --> ADS1115 16-Bit ADC - 4 Channel with Programmable Gain Amplifier [STEMMA QT / Qwiic] : ID 1085 : $14.95 : Adafruit Industries, Unique & fun DIY electronics and kits
Tutorial --> Overview | Adafruit 4-Channel ADC Breakouts | Adafruit Learning System

prima di sbattere la testa sull'ADC... sicuro della precisione del sensore arrivi a MENO di un metro (precisione con AREF a 5v), 30cm (precisione con AREF a 3,3V) o 10cm (precisione con AREF a 1,1V, ma poi la profondità massima è 1.1V che sono circa 22BAR, 220 metri)?

ma gli elettrodi placcati in oro li ho gia

ottimo allora

Intendo dire che il ritardo intrinseco della coppia di interfacce e' di circa 20 mS ... cioe', quando chiudi un'ingresso su una, la corrispondente uscita sull'altra si chiude dopo circa 20mS

accidenti! e queste interfaccie cosa comandano? se invece che usare queste interfaccie, quei cavi li eviti o li usi per "portare su" la rs485 da arduino (che fa più metri rispetto ad una ethernet e come detti prima è assai più affidabile) e poi in base a dei comandi che dai ad arduino, arduino accende/spegne le sue uscite e comanda gli encoder dei motori, luci, tilt telecamera etc...

Alla fine una seriale a 9600baud trasposra 960 byte al secondo, ovvero (arrotondato per difetto)9 byte ogni 10mS che sono 9*8=72bit, ovvero ci controlli lo stato di 72 uscite digitali... e 10mS sono i riflessi di un essere umano molto reattivo

lesto:
... e 10mS sono i riflessi di un essere umano molto reattivo

No, i tempi medii per i riflessi sono intono a 1 decimo di secondo, quindi 100ms.
Considera che la IAAF considera falsa partenza un tempo di reazione (allo sparo) inferiore al decimo di secondo.
Un riflesso di 1 centesimo di secondo è inconcepibile. Saresti un alieno.

PaoloP: Grazie. questo non lo avevo preso in considerazione all'inizio perche' pensavo ad un solo canale ... ma riflettendoci meglio, potrebbe essere la soluzione migliore ... non costa molto, e 16 bit sono gia piu che sufficenti (il progetto e' di avere una portata massima di 450/500m, 65535 step darebbero una risoluzione teorica maggiore di 1 cm, ma dato che anche i modelli commerciali di profondimetri per ROV che ho visto, ad alto costo, sono in grado di dare al massimo una risoluzione di 10cm, andrebbe di lusso) ... e poi, chissa', magari gli altri 3 canali potrebbero venire utili per qualche altra cosetta ] ] ]

Lesto: per quanto riguarda la precisione del sensore non lo so ancora, sto cercando i datasheet ma non sono ancora riuscito a trovarli (l'avevo preso su internet tempo fa) ... in teoria dovrebbe essere abbastanza preciso, dato che e' un trasduttore per uso industriale, ma nella pratica ancora non ho avuto occasione di fare dei test ... il modello non e' identificabile, e' un cilindro di acciaio con un connettore minidin ad un'estremita' ed una protuberanza filettata con un foro all'altra, che riporta solo le scritte UCC (probabilmente il produttore), 10/36VDC (l'alimentazione), 100BAR (la portata), e "0/5V" parzialmente illeggibile (l'uscita) ... il resto e' parzialmente cancellato, si legge un "cy 0,05%", che potrebbe riferirsi alla massima accuratezza ... di solito sui sensori industriali e' riportata in percentuale della pressione massima, quindi in teoria dovrebbe significare che la massima accuratezza (e quindi probabilmente anche la massima risoluzione) e' dello 0,05% della massima pressione, 100BAR, cioe' sempre in teoria 0,05BAR ... in teoria ... il modello e' parzialmente cancellato, si legge solo "R10" e niente altro ... un po pochino per capire cos'era o per trovare i datasheet ... ricordo solo che quando l'ho comperato lo vendevano come "sensore a tecnologia thin-film con controllo ASIC", ma anche questo non dice molto.

Per quanto riguarda le interfacce, ho usato queste perche' il cavo, che e' piu di 400 metri, all'interno ha solo un coassiale RG58 con anima flessibile, e basta ... e su quello ci passano sovrapposte la 250VAC dell'alimentazione, i canali video delle camere, ed i segnali di controllo (l'ethernet che accoppia le interfacce, convogliara attraverso un powerline sulla 250V) ... non ne avevo proprio, di altri cavi da usare

E' vero, potrei usare un PC e comandare direttamente l'arduino tramite la rete, ma questa soluzione era stata originariamente scelta perche' in questo modo il sistema era indipendente da qualsiasi PC ... in caso di emergenza, il sistema di comando sta tutto in una valigetta, e puo funzionare anche senza il PC del sonar (ovvio che in questo caso il sonar non va) ... inoltre, dato che queste interfacce di solito sono fatte per uso industriale, dovrebbero essere molto piu stabili di qualsiasi sistema basato su un PC ... posso persino usare una delle linee per resettare in remoto l'arduino se dovesse piantarsi, mentre se a comandare il tutto fosse lui e si piantasse, dovrei tirare su tutto a mano (mai provato a recuperare 400 metri di cavo con attaccati un paio di quintali di massa da sott'acqua ? ... anche se e' neutro per quanto riguarda il galleggiamento, non e' uno scherzo da niente :D)