Apparato Focardi-Rossi

[brunovr]

ciao a tutti

Io non capisco......
Solitamente per fare prove calorimetriche si procedeva nel misurare il DT tra entrata ed uscita e la portata del fluido vettore.
Non servivano accumuli o qunat'altro, ma bastava misurare la T in , la Tout , la portata anzi, bastava a questo punto inserire un bellissimo contacalorie ad ultrasuoni in classe I e si poteva misurare perfettamente le calorie sviluppate dall'apparecchio....

Mah...... mi sembra che negli ultimi anni si sia persa quella visione d'insieme delle cose, bisogna sempre andare in cerca di tagliare il capello in 4 parti per misurare raggi gamma, beta, alfa ....sono basito che nessun Ingegnere partecipante all'esperimento non abbia chiesto il perchè di un calcolo simile.......perchè non calcolare il COP come si fa con le caldaie, con le PDC....... anche se l'errore fosse del 5% già sarebbe stata una notizia da TG (beh, forse ho esagerato, tira più il bunga bunga che la scienza...)
Credo nella buona fede di Focardi-Rossi, ma penso anche che tanta teoria soffochi la pratica, che la sperimentazione vera sia sul campo piuttosto che sulla carta o al Pc, spero infine che Focardi-Rossi dimostrino la reale resa dell'apparecchio attraverso una prova acqua-acqua........

Io uso PLC a 32bit con campionamento a 150kHz costa 1000 euro ma ci fai quel che vuoi

[Vettore]

Se questo vapore lo condenso e misuro il condensato e la temperatura del refrigerante va bene, se viene buttato per lo scarico, dato che la pompa continua a spingere acqua nel sistema e che non si può vedere cosa esce dal tubo, come si fa a sapere quanta di quell' acqua è stata vaporizzata, e quanta era ancora liquida?

Secondo te prevedono una cosa poco intuitiva come la pesata, e si dimenticano di controllare se esce acqua liquida? Suvvia...
A parte la banalissima ispezione visiva (non so se hanno messo un vaso di raccolta liquido vero e proprio sull'uscita, ma comunque lo stesso tubo di gomma trasparente usato avrebbe raccolto il liquido negli avvallamenti, provocando anche gorgoglii facilmente udibili e visibili), c'è una cosa che si chiama diagramma di fase dell'acqua:
Fileiagramma di fase acqua 2.svg - Wikipedia
che fornisce indicazioni sufficienti in base alla misura di temperatura ed umidità fatta (la pressione era quella atmosferica).

Il fatto che fosse tutto vapore dipende da quanto è valida la misura eseguita con quella sonda, e il peso dell' eventuale combustibile chimico potrebbe essere compensato da un' adeguata quantità di acqua spillata dal circuito di raffreddamento; si torna alla necessità di misurare sia la materia in entrata che la materia in uscita.

Dalle osservazioni che si leggono in rete mi sono convinto che è una partita persa. Puoi fare tutte le misure che vuoi nei modi più perfetti possibili, ci sarà sempre qualcuno che se ne esce con dubbi ed osservazioni inverosimili (che alla fine sono giustificate solo dal presupposto che chi ha condotto la misura sia un incapace o che sia un "compare" di Rossi e Focardi e che questi a loro volta abbiano messo in scena una specie di truffa)...
Per questo motivo non spenderò più una parola sul tema della misura.

eroyka:
Piantelli ha fatto un primo brevetto con Focardi (che prima collaborava con lui) nel 1995 e su cui è basato quello attuale di Rossi: (WO/1995/020816) ENERGY GENERATION AND GENERATOR BY MEANS OF ANHARMONIC STIMULATED FUSION

Questo brevetto è estremamente interessante! Aggiunge dei particolari che non sono presenti ne in quello di Rossi, ne in quello di Piantelli (devo dire che comunque somiglia di più a quest'ultimo).
In particolare si spiega in dettaglio come avviare la reazione ed alcuni meccanismi (ipotetici) per cui la reazione di mantiene fino ad un successivo "colpo"... Inoltre viene evidenziato un certo ruolo dei campi magnetici.

[SGF]

Vettore, vada per l'mcp6004, poco fa' mi hanno consegnato arduino. Probabilmente un conoscente mi mette a disposizione LabView.

Ho letto il brevetto del tuo link, mi sembra di aver capito che questi hanno depositato un film di nichel metallico in dei tubetti di rame percorsi da H, a bassa pressione,da una parte e dall'altra dal fluido termovettore, quindi se cosi fosse e sufficiente del nichel metallico per osservare il fenomeno, il problema sta nel trovare i parametri di innesco !?.

Zorto e company....poi se vi danno 2 sculacciate non mettetevi a piangere...

[SGF]

X Vettore e Bepo, ho trovato questi semplici programmi per leggere i grafici
Gioblu robotics | Arduino e i grafici in tempo reale su Excel | Serial, Excel, Permette, Dati, Arduino
Gioblu robotics | Grafico con Processing | Myport, Arduino, Processing, Xpos, Serial[url=http://www.starlino.com/imu_kalman_arduino.html#more-16]Arduino code for simplified Kalman filter. Using a 5DOF IMU (accelerometer and gyroscope combo)
Dategli un'occhiata...

[GabriChan]

Ciao SGF ho dato un'occhiata il programma non fa altro che aprire la COM e inviare il log delle letture a un programma PLX-DAQ su pc, che si occupa de incasellare i dati in un file excel e generare i grafici.
La cosa non è difficile da fare ma si può fare di meglio come implementare un protocollo standard come ad esempio il MODBUS RTU e così poterlo leggere con qualche software di supervisione, il labview o atro.
ad esempio questo.
arduino modbus slave - jpmzometa

il vantaggio di usare un protocollo standard è proprio il fatto che è standard e quindi può essere gestito da molti software di supervisione e addirittura da HMI o simili.

Ciao.

[SGF]

Cercavo qualcosa di sbrigativo che mi permettesse di salvare i grafici al volo senza dovermi dilungare nella programmazione, e senza contare che non sono esperto di linguaggio C e quindi non vorrei che la cosa si faccia lunga e pesante...
Poi il protocollo, non penso sia un problema sostituirlo secondo le nostre esigenze, tra l'altro avevo già scaricato il codice della seriale proprio per labView...

[Vettore]

Vettore, vada per l'mcp6004, poco fa' mi hanno consegnato arduino. Probabilmente un conoscente mi mette a disposizione LabView.

Ok, ma probabilmente LabView è eccessivo per quello che serve.

il problema sta nel trovare i parametri di innesco !?.

Da quello che ho capito basta una qualsiasi condizione di non equilibrio rapida, perfino una martellata... [Questa cosa mi rocrdaper certi versi il funzionamento dei laser...]

Blade Runner:
Beh, temo che se si moltiplicano queste bruttissime notizie
[Vo]efkalion Energy has no knowledge of Rossi, and Leonardo Company i
saremo noi CREDENTI che dovremo presto auto-sculacciarci...

Il nome della società è Defkalion Green Technologies S.A. C'è un'altra società che si chiama Defkalion Energy, ma non ha niente a che vedere con questa tecnologia. E' tutto spiegato su JONP...
Riguardo alla Leonardo Technology, tempo fa avevo fatto delle ricerche e avevo trovato un sito: si occupavano evvettivamente di energia, ma non c'era traccia del reattore. Recentemente ho fatto la stessa ricerca trovando nel sito i contenuti relativi alla EON! Probabilmente erano in fase di manutenzione...

SGF:
X Vettore e Bepo, ho trovato questi semplici programmi per leggere i grafici

Bisogna distinguere se si vuole registrare i dati o visualizzarli in tempo reale. E' chiaro che la priorità è registrarli, poi una volta che sono su un file li si può visualizzare con Excell o in qualsiasi altro modo. Per registrare i dati ho già dei software pronti. Se serve invece visualizzarli in tempo reale bisogna pensare a qualcosa di apposito. Bisogna valutare se è più semplice usare software standard (LabView o Modbus) e scrivere un firmware che si interfacci in quel modo, oppure semplificare al massimo il firmware e scrivere un software su misura. A mio avviso è più semplice la seconda strada, considerando anche che non dobbiamo costruire un prodotto che andrà sul mercato... Io di software che fanno cose del genere ne ho scritti parecchi e non mi risulterebbe difficile prepararne uno su misura, in modo da semplificare al massimo la scrittura del firmware (che potrebbe perfino inviare dati grezzissimi così come letti dai convertitori, senza perdere tempo in conversioni, correzioni e tarature)... Faccio notare un'altra cosa un pò tecnica: la parte del firmware relativa al "parsing" dei comandi è tutt'altro che banale se si vuole ottenere un comportamento robusto o essere compliant con qualche standard. Invece viste le funzioni veramente basilari richieste ed i tempi degli eventi da gestire, in una soluzione su misura la si potrebbe quasi del tutto eliminare!

Cercavo qualcosa di sbrigativo che mi permettesse di salvare i grafici al volo senza dovermi dilungare nella programmazione, e senza contare che non sono esperto di linguaggio C e quindi non vorrei che la cosa si faccia lunga e pesante...

Appunto...

[GabriChan]

Ciao Vettore se non si vuole fare il grafico in tempo reale basta solo l'interfaccia seriale con arduino
Arduino - ArduinoSoftwareRS232
e si usa l'Hiperterminal settato come Aquisisci testo, si leggono i dati grezzi da arduino in formato CSV "testo semplice separato da un ';' " e poi si caricano con Excel, da scivere c'è molto poco.
solo l'interfaccia su arduino che è molto semplice, be si vedono i numeri scorrere e si vede se aumentano o diminuiscono....
Ciao

[SGF]

Da quello che ho capito basta una qualsiasi condizione di non equilibrio rapida, perfino una martellata... [Questa cosa mi rocrdaper certi versi il funzionamento dei laser...]

Piu che il laser mi ricorda il televisore a valvole di nonna, due colpi decisi e riprendeva a funzionare.....MA dicono che l'hanno fatto funzionare con inox 316...?!

Purtroppo temo ci serviranno sia i grafici che le letture in tempo reale e finite non grezze, anche perché riconvertirmi a carta e penna tutti i punti dei grafici è leggermente stressante...ne va di mezzo la mia salute mentale (tra l'altro già precaria)....

Con Excel oltre a ricostruire il grafico si potrebbero inserire anche le formule di conversione e taratura...male che vada...

Altra notte insonne a cercare in rete, scada hmi della Sielco Winlog lite.
Ho scaricato, e da un occhiata al volo, sembra faccia al caso nostro, ci sono degli esempi pronti, penso siano facili da modificare secondo le nostre esigenze.... che ne dite ??

//non ho capito? Winlog lite per funzionare vuole componenti aggiuntivi a pagamento?

[GabriChan]

Ciao Vettore da quello che ho capito la versione light lavora per 15 minuti poi si ferma per farla lavorare sempre bisogna acquistare la versone full che costa 49€ ... e comunque devi sempre implementare un protocollo su arduino.
a questo punto è più facile fare un programmino.... uno script in VB in excel ad esempio.

[SGF]

50 € si può fare, anche in vista di altre applicazioni, mi sembra abbastanza completo sopratutto sui grafici, si può zumare sui punti più salienti regolare i tempi, grafico multicanale, interfaccia carina (fa scena) insoma fa un bel po' di funzioni.
Anche se non ho capito come fa le tarature, o meglio ho visto che fa una traslazione di scala cioe aggiunge ho toglie qualche punto al value, ma non o visto tarature sullo spam (guadagno).

Comunque, ribadisco il concetto; La patata bollente è vostra...

Per il software per arduino mi sembra meno difficoltoso, dovremmo trasferire i valori dell'acquisizione analogica tal quali alla seriale.

CAIO:-Testina...era fusione fredda!

Appunto se era fusione calda dovevano fare la presentazione in costume da bagno

[Vettore]

x SGF e GabriChan: se siete propensi per l'approccio minimale io posso svilupparvi sia il firmware per l'Arduino che il software per PC che faccia calcoli e conversioni, visualizzi i dati elaborati e ne faccia il log su file. Vedere i dati in tempo reale è sicuramente utile (per capire che so, se il coso sta esplodendo o se si è bruciata la resistenza...), vedere i grafici live meno, ma si può fare pure. In genere durante gli esperimenti si preferisce acquisire i dati, e solo dopo li si elabora in tutti i modi possibili ed immaginabili. Del resto una volta che i dati sono tabellati su file basta usare Excell... Il contrario non sempre è vero, vedi quello che è successo a Levi...
Se volete optate per soluzioni diverse non c'è problema, vi supporto ugualmente per quello che posso.
Winlog è carino, ma a parte il costo ho paura che il lavoro per implementare il protocollo sul firmware sia maggiore.


P.S. Riguardo al link sulla seriale di Arduino: basta una riga di codice per trasmettere un carattere con un ATMega, non c'è bisogno di tutto quel listato!!! :-)

[SGF]

Per me va bene, vada per un programmino semplice, i grafici in tempo reale sono relativi,in effetti quel che interessa e' il login.
Ricordiamoci che nell'arduino ci va il conteggio del geiger.
Per i neutroni che alternative abbiamo, solo la lamina d'oro?

P.S. Riguardo al link sulla seriale di Arduino: basta una riga di codice per trasmettere un carattere con un ATMega, non c'è bisogno di tutto quel listato!!! :-)

Serve per rallentare i cicli macchina.

[GabriChan]

Ciao SGF be per fare il log della seriale basta hiperterminal con l'opzione acquisisci testo. Credo che il convertitore max232 ti serva comunque.

[Vettore]

Ricordiamoci che nell'arduino ci va il conteggio del geiger. Per i neutroni che alternative abbiamo, solo la lamina d'oro?

Per i conteggi ci sono degli ingressi appositi collegati propri a contatori. Si possono usare quelli.
I neutroni sono un problema: purtroppo sono difficili da rilevare. Non si possono usare i tubi geiger perchè non ionizzano i gas, ne rivelatori elettronici perchè non hanno carica. Bisogna per forza usare effetti secondari: o scintillatori a base di sostanze esotiche (He3, floruro di Boro, etc.) o reazioni chimiche/fisiche particolari.
Credo che solo gli scintillatori possono dare una lettura in tempo reale, altre tecniche danno misure cumulate alla fine dell'esperimento. Recentemente sono stati messi a punto dei diodi a base semiconduttori particolari basati sul Boro che forniscono una lettura tipo geiger, ma non sono ancora disponibili commercialmente. Usando elettronica convenzionale, sono state di recente proposte due tecniche: uso di MOSFET o di memorie RAM. Nel primo caso i neutroni danneggiano lo strato di ossido di gate, provocando una piccola variazione della tensione di soglia del dispositivo. Questa è quindi na tecnica dosimetrica (cumulativa). Usando memorie SRAM invece si è notato che i neutroni possono provocare inversioni di bit in numero proporzionale al loro flusso. Questa tecnica da indicazioni in tempo reale ed è abbastanza semplice da realizzare (basta contare quanti bit variano al secondo o al minuto). Purtroppo però viste le varietà dei processi produttivi è impossibile conoscerne la risposta se non si fa una taratura con una sorgente di neutroni nota.
Credo che i metodi più economici consistano nel mettere qualcosa a base di boro davanti ad un normale geiger, o usare i CR-39, che però non costano poco e vanno inviati ad un centro specializzato per l'analisi.

Serve per rallentare i cicli macchina.

In realtà hanno implementato la UART in software.

GabriChan:
Credo che il convertitore max232 ti serva comunque.

Che modello di Arduino ha di preciso SGF?

[SGF]

il max non serve, l'arduino che ho acquistato (mega 2560) ha a bordo un chip usb che fa tutto, cioe, si usa per programmarlo prima e per la comunicazione dopo...

[GabriChan]

Ciao credo che per i neutroni si possa aspettare, è più importante il rilevamento dei gamma. Credo serva fare anche a un pwm per poter modulare la temperatura della resistenza e un'altro per modulare la ddp sugli elettrodi.

[BEPO]

Risalve a tutti, appena riemerso dal coma influenzale, ho dovuto "riallinearmi" leggendo quasi una settimana di post...

@GabriChan
Secondo me è molto interessante il fato di avere un client Modbus sull'Arduino (non lo conoscevo); questo permette una serie di opzioni molto piu' flessibili lato PC.

@Vettore
Dopo un entusiasmo iniziale tipo "scriviamo tutto da zero" ripensandoci bene e cercando meglio in rete ho cambiato idea; il fatto di avere gia' una libreria modbus sull'arduino cambia parecchio: in questo modo basta scrivere il firmware di acquisizione dei dati grezzi sull'Arduino (da fare comunque) e inviarli al PC con la libreria Modbus, potendo usare sul PC un qualsiasi sw di log/analisi compatibile Modbus.

@SGF
Ho visto anche io il sofware di cui parli (Winlog Lite), ma ha il difetto di essere una demo di un prodotto commerciale e quindi poco "maneggevole".
Cercando un po' in giro ho trovato altre possibili alternative sia in ambiente winzoz che in ambiente linux; le cose migliori che ho trovato sono:
- per windows IntegraXor (IntegraXor HMI/SCADA • Free Web SCADA for 128 Modbus I/O)
- per linux Mango (Mango, open source M2M)

A mio avviso la configurazione sw ottimale dovrebbe essere:
- su Arduino
+ firmware di acquisizione scritto "ad-hoc" in base alla configurazione di sensori (da sviluppare);
+ client Modbus per inviare i dati al PC (libreria già fatta);
- su PC;
+ software in grado di interpretare, loggare e graficare i dati in formato Modbus (sw open-sorce già pronto).

Questa configurazione riduce al minimo il lavoro di sviluppo necessario e garantisce il massimo di riproducibilità da parte di terzi (e quindi di trasparenza).

Da parte mia, avendo un paio di arduino in arrivo a breve per un altro progetto piu' "ludico", potrei dedicarmi all'integrazione tra il client Modbus e il software su PC (lo sviluppo e il debug dei protocolli di comunicazione, anche se di altro tipo, è il mio pane).

[SGF]

Negil States, se' ho capito bene, hanno la licenza per produrre con questa tecnologia un tot di Mw anno in Grecia produrranno,gli "scaldabagni" (20 Kw = un caldaia per casa = 2000 euro Kw X 20 Kw = 40000 euri = se spendo 1000 euro l'anno per riscaldare casa, con il catalyzer ammorto la spesa in 40 anni (sempre se sarò ancora vivo), il che vuol dire che chi vende "scaldabagni solari" puo stare tranquillo.

Ieri dopo un lunga odissea, sono riuscito a far comunicare arduino (per chi non lo sà con il mega 2560 bisogna fare acrobazie per installare il driver, nei manuali non ce scritto come fare, e io non sono un indovino).
Ho scritto 2 righe di codice , e sorpresa arduino comunica col pc, sul monitor del ide di arduino mi da direttamente il dato numerico, su yperteminal no, mi da simboli a casaccio, penso sara semplicemente da settare la codifica dei dati.
Quindi un piccolo passo e fatto !

@Bepo; Pu tardi do uno sguardo al software che hai postato e ti rispondo. Ora ho un po di fretta...
@Gabrican; Cosa aspetto...? Che il mio corpo passi ad un livello energetico superiore...!!! :-)

[SGF]

@BEPO; Ho frugato in lungo e in largo il programma del tuo link, benché ne abbia capito, a grandi linee, la struttura, tipo sito Web, non saprei dove mettere le mani, esempio, dove si settano protocolli e ingressi? Mi sembra non ci sia nessuna finestra che fa ciò, e che sia tutto da scrivere nel codice, html o simili... Che a me proprio...
Non so che dire, vedi un po anche con Vettore sé si può adattare facilmente o scriverne uno nuovo.

Intanto io vado avanti con il resto. Sto riflettendo se sia il caso di implementare un conteggio della potenza di ingesso, della pressione e della tensione di polarizzazione.

[Vettore]

@Vettore
Dopo un entusiasmo iniziale tipo "scriviamo tutto da zero" ripensandoci bene e cercando meglio in rete ho cambiato idea; il fatto di avere gia' una libreria modbus sull'arduino cambia parecchio: in questo modo basta scrivere il firmware di acquisizione dei dati grezzi sull'Arduino (da fare comunque) e inviarli al PC con la libreria Modbus, potendo usare sul PC un qualsiasi sw di log/analisi compatibile Modbus.

Per esperienza posso dire che trovare cose già pronte spesso non fa affatto risparmiare tempo e fatica, anzi... Bisogna studiarsele, capire come funzionano, capire il codice, riuscirlo a compilare, modificarlo, testarlo, incrociare le dita sperando che la parte pronta non sia bacata... Può essere un buon approccio solo quando hai materiale molto ben documentato e relativo a progetti complessi che sarebbe oggettivamente molto faticoso sviluppare in proprio.
In questo caso opterei per un approccio minimale, anche perchè lo sviluppo della parte di acquisizione non è il fine, ma solo il mezzo, e non deve assorbire energie che sarebbe meglio dedicare ad altro...
Però il mio è solo un parere, scegliete voi (in particolare SGF).

x SGF:
per misurare la potenza in ingresso si può utilizzare un sensore di corrente da collegare all'alimentazione dell'intero sistema, che si potrebbe leggere con uno degli ingressi analogici del micro. La tensione di rete si può ragionevolmente considerare costante. Considerando anche il tipo di risposta di questi sensori la misura che ne verrebbe fuori sarebbe conservativa.

[piolos]

varie

Salve a tutti...
In questi ultimi giorni non ho potuto seguire in dettaglio i progressi della discussione e avrò poco tempo, da qua in avanti dovendo dedicarmi intensivamente al lavoro (quello ufficiale).
Vorrei chiedere (SGF in particolare), se mi può ragguagliare in sintesi sullo stato del "work in progress".

In ogni caso sfrutterò i fine settimana per sperimentare sul "active core" lavorando sugli accessori al Nickel e sulle anisotropie eventualmente capaci di creare gradienti (chimici, termici ecc) all'interno del volume da attivare.

Vi aggiornerò sulle eventuali novità

Buon lavoro
Piolos

[SGF]

@Vettore, Potremo fare cosi; per ora potresti scrivere un programmino semplice semplice che mi aggiorna nel video in tempo reale il contenuto "crudo" del value di ogni stringa trasmessa da arduino, contenente il N° di canale e Value? In modo che io possa cominciare a lavorare sull'elettronica.
Poi senza fretta, in un secondo tempo, scriviamo il codice per allineare e tarare il Value in unita ingegneristiche.

@ Pilos; o cominciato ad assemblare la parete puramente meccanica, tubazioni pompa ecc... mi resta da definire l'interno del reattore, che non è nient'altro che un barilotto con flangia da una parte e tappo saldato dall'altra. Per la parete elettrica ho "raccattato" quasi tutto il materiale, compreso trasformatore AT..mi manca la sonda geiger, e il radrizatore AT (sere di 1N007 in muffola di resina e partitore resistivo per la misura AT).
In somma i tempi si rivelano lunghi...
Come completo il set up meccanico posto la foto con qualche dato, giusto per cominciare a vedere qual cosa...

[BEPO]

@Vettore
Sono d'accordo con te che dato il genere di approccio, la cosa migliore è partire da qualcosa di semplice e complicarsi la vita dopo, pero' è anche vero che data la "delicatezza" del tema, è necessario utilzzare strumenti ingegneristicamente inattaccabili. In questo senso l'ideale sarebbe una bella suite HW/SW di acquisizione, condizionamento e controllo dei segnali (tipo National/LabView), che è però evidentemente fuori budget... In mancanza di quello, la mia idea è che gli strumenti utilizzati dovrebbero essere il piu' possibile open (per dare garanzia di trasparenza) e basati su standard comuni e accessibili.

@SGF, @Vettore
Per un primo setup di sviluppo e di taratura della parte analogica di acquisizione del segnale, date un occhiata al protocollo Firmata (Arduino playground - Firmata Main Page - Firmata). Nelle ultime versioni di firmware di Arduino è già implementato nativamente e permette un minimo di controllo con dei programmini su pc (già pronti) di smanettare facilmente con gli I/O sia digitali che analogici di Arduino.

Nel frattempo domani sera dovrei avere il tempo di iniziare a vedere come integrare Arduino con un sistema di log e controllo piu' sofisticato "pescando" sempre nell'open source e nell'ottica di una maggiore ingengnerizzazione del tutto ...

[Vettore]

@Vettore, Potremo fare cosi; per ora potresti scrivere un programmino semplice semplice che mi aggiorna nel video in tempo reale il contenuto "crudo" del value di ogni stringa trasmessa da arduino, contenente il N° di canale e Value? In modo che io possa cominciare a lavorare sull'elettronica.
Poi senza fretta, in un secondo tempo, scriviamo il codice per allineare e tarare il Value in unita ingegneristiche.

Si, ok, questa è una cosa abbastanza semplice da fare...
Dovremmo decidere però la frequenza di campionamento che vogliamo: se è veloce (>10Hz) va gestita in hardware, se è lenta (secondi) può essere gestita dal software sul PC.

BEPO:
pero' è anche vero che data la "delicatezza" del tema, è necessario utilzzare strumenti ingegneristicamente inattaccabili. In questo senso l'ideale sarebbe una bella suite HW/SW di acquisizione, condizionamento e controllo dei segnali (tipo National/LabView), che è però evidentemente fuori budget...

Nella prima fase degli esperimenti le misure saranno prevalentemente "qualitative", nel senso che mireranno a rilevare la presenza di qualche effetto anomalo, non tanto a quantificare quanto energia si produce o cose simili. Se si ha una conferma in questo senso ci si potrebbe spingere su qualcosa di più "professionale". In ogni caso se si fanno bene le cose non è detto che la precisione delle misure sia inferiore con hardware "fatto in casa", anzi, il fatto di sapere ferfettamente com'è fatto e come funziona è un vantaggio notevole! Sai quanto spesso capita di prendere delle cantonate notevoli solo perchè non si è letto un paragrafetto del manuale di uno strumento super-costoso che dice che in certe condizioni le misure vengono male?

In mancanza di quello, la mia idea è che gli strumenti utilizzati dovrebbero essere il piu' possibile open (per dare garanzia di trasparenza) e basati su standard comuni e accessibili.

Pubblichi il firmware, il software e gli schemi: più "open" di così! E comunque i risultati devono essere verificati/bili con qualsiasi sistema di acquisizione, non sono con quello che utilizzeremo noi.

Per un primo setup di sviluppo e di taratura della parte analogica di acquisizione del segnale, date un occhiata al protocollo Firmata

Gli darò un'occhiata, magari fa già quello che ci serve dal lato firmware...

[jumpjack]

Ho scritto 2 righe di codice , e sorpresa arduino comunica col pc, sul monitor del ide di arduino mi da direttamente il dato numerico, su yperteminal no, mi da simboli a casaccio, penso sara semplicemente da settare la codifica dei dati.

Occhio a non confondere serial.print() con serial.write() !!!
Ma perche' impiccarsi con altre arduino che non siano la Uno! La inserisci, si installano i driver plug&play, e hai finito!

Ma di preciso cosa volete che faccia la arduino? Anch'io mi intendo di arduino e di visual basic for application (per Excel).

Quanto ai programmi di tracciamento, vedete un po' se qui c'e' qualcosa di utile (tutta roba free):
Peanut Software Homepage

[SGF]

Per ora, se funziona, posso arrangiarmi con il programmino postato da Bepo Arduino playground - Firmata.
Cosa voglio fare per ora; adattare i segnali dei sensori all' ingresso della scheda di arduino.
Esempio, per lm35 che arriva ad un temperatura max di 150 C°, deve dare al pin di acquisizione un segnale corrispondente a, -5C°= 0V / 110C° = 5V.
per la TC K 0C° 0 =V / 1000C° = 5V.
Perché questo? Sempre per una questione di precisione e meglio far lavorare l' ADC su tutta la scala.
Dirette voi, " per fare ciò ti basta un tester !", si, ma vorrei avere una visione dell'insieme per correggere a monte eventuali instabilità o fluttuazioni delle letture.

Mi sorge un dubbio per la lettura del geiger; Come effettua il conteggio arduino? leggendo il pin via Software, oppure ha un contattore indipendente?
Se è via software e in caso sia troppo lento bisogna prevedere un integrato di conteggio esterno.

Occhio a non confondere serial.print() con serial.write() !!!
Ma perche' impiccarsi con altre arduino che non siano la Uno! La inserisci, si installano i driver plug&play, e hai finito!

Ma di preciso cosa volete che faccia la arduino? Anch'io mi intendo di arduino e di visual basic for application (per Excel).

Il Problema dei driver non sussiste, ho scritto che comunica senza problemi con il PC, evidentemente et installato a dovere.

Quel che vogliamo fare e un sistema di acquisizione semplice ma preciso, per un impiantino sperimentale, che ci riporti lo storico in un grafico cartesiano multicanale, cioè con più tracce.

[Vettore]

Esempio, per lm35 che arriva ad un temperatura max di 150 C°, deve dare al pin di acquisizione un segnale corrispondente a, -5C°= 0V / 110C° = 5V.
per la TC K 0C° 0 =V / 1000C° = 5V.
Perché questo? Sempre per una questione di precisione e meglio far lavorare l' ADC su tutta la scala.

Un attimo, riguardo ai sensori: l'LM35 io lo userei così come esce, è già ottimizzato in quanto a linearità e risoluzione ed ha un range buono per essere letto come 0-5V. Per la termocoppia la cosa è più complicata, lei ti dà 0V a temperatura ambiente, tensione negativa (che non può essere letta) sotto la temperatura ambiente, e col coefficiente che abbiamo scelto 5V per circa 1200°C. Possiamo modificare questa cosa in modo da avere 0V a temperatura inferiore a quella ambiente, tanto poi occorrerà fare la cmpensazione.
Riguardo all'ADC, in primo luogo bisogna evitare le tensioni vicine a 0V e 5V, perchè gli amplificatori lavorano male vicino ai rail. Inoltre bisognerebbe utilizzare una reference di tensione. Non è il caso di utilizzare 5V, perchè questi non sono affatto stabili, anzi, non sono affatto un riferimento assoluto per come vengono generati. Quindi se vuoi fare lavorare bene l'ADC innanzi tutti occorre selezionare la REF interna dell'ATMega (quant'è? 2.5V mi pare?) e quindi scalare i segnali di conseguenza.
La risoluzione e la precisioone sono due concetti diversi. Credo che riguardo la prima, con 10 bit ne abbiamo anche più di quella che serve, la seconda dipende esclusivamente dalle caratteristiche dell'ADC e della reference. In ogni caso siamo molto sotto l'1% del fondo scala, quindi decisamente ad un buon livello per il tipo di misure che dobbiamo fare (ossia inutile spaccare il capello in 4).

Mi sorge un dubbio per la lettura del geiger; Come effettua il conteggio arduino? leggendo il pin via Software, oppure ha un contattore indipendente?

Si può fare in diversi modi, sia via software (che non sarebbe affatto lento, se gestito bene), sia via hardware, sfruttnado i contatori appositi.

[SGF]

Tutto apposto, Il protocollo/programmino "firma" e in funzione, per ora può bastare.
Ah proposito di capello :4, ho notato che la risoluzione è di 1023 punti...pochi...come fare?
Per le sonde calorimetro può andare, su 100 C° riusciamo ad ottenere una risoluzione di un decimo di C°, o quasi.
Ma per la TC K del nocciolo, niente virgola...? Se serve implementeremo con un ADC 16bit...!?

@jumpjack;
Citazione:
Originariamente scritto da tersite3
La scienza non è una fede.

Temo che tu abbia travisato la sostanza del pensiero di Tersite. Tanto meno a lasciato intendere ciò che gli contesti.

[BEPO]

@SGF
Per la misura della temperatura se la risoluzione a 10 bit risultasse troppo bassa, si potrebbe aggiungere al convertitore ADC di arduino un convertitore a maggior risoluzione (ma a minor frequenza di campionamento). Con i 10 bit di arduino si fa la misura "grossolana" al massimo possibile di frequenza (anche per implementare eventuali shutdown di emergenza in caso di aumento improvviso e inaspettato), mentre con un convertitore piu' preciso si puo' acquisire lo stesso segnale a minor frequenza di campionamento. L'ADC puo' essere semplicemente connesso e gesito all'Arduino via connessioni seriali SPI o I2C (entrambe direttamente supportate in modo nativo da Arduino).
Un paio di esempi a basso costo:
- Analog Devices AD7788ARMZ (16 bit risoluzione, 16 Hz frq camp., 5.70 Euro al pezzo su RS Components | componenti elettronici ed elettrici)
- Analog Devices AD7788BRMZ (24 bit risoluzione, 16 Hz frq camp., 6.20 Euro al pezzo su RS Components | componenti elettronici ed elettrici)