Show Posts
Pages: 1 2 [3] 4 5 ... 20
31  International / Hardware / Re: Schema triac e optotriac on: January 10, 2013, 02:02:27 am
Lo snubber non serve quando non si usa un carico induttivo come ad esempio un motore,se state pilotando carichi come una lampadina io non lo metterei....
Vi posto però un link interessante http://www.thierry-lequeu.fr/data/AN437.pdf
Dategli un occhio  smiley

sarebbe una lampada fluorescente da 150Watt quindi sarebbe un carico induttivo... imho notevolmente smorzato dal fatto che comunque è una lampada elettronica non il vecchio reattore.
Interessante il documento... da una distrattissima lettura ho visto che per un motore enorme mettevano uno snubber piccolissimo... poi me lo studio meglio... comunque per questa applicazione lo snubber non lo metterei neanche io.
32  International / Hardware / Re: Schema triac e optotriac on: January 09, 2013, 05:12:18 pm
ora sto provando un SSR, vedremo i risultati

allora ho riprovato... è vero la lampada (philips) lampeggia.... staccando lo snubber la lampada rimane spenta...
Ho notato mettendo in parallelo un altro condensatore che peggiora... al che per farlo migliorare ho messo una resistenza in serie (in pratica sono passato da 100 ohm a 300 sullo snubber) ed il fenomeno chiaramente scompare.
Lo scambio fase neutro non comporta alcun cambiamento nel mio caso...
...uwe dove sei?  smiley-red
Ho tolto di mezzo quindi tutto ed ho attaccato solo la lampada e lo snubber direttamente alla 220 e come pensavo lo fa lo stesso (no triac no fotoaccoppiatore nulla... solo filo lampada e R-C...
Allora: il mio pensiero è questo: lo snubber è un condensatore messo a cavallo di un interruttore che funziona (il triac): durante l'onda positiva il condensatore si carica, quando la tensione arriva a 0 il condensatore comincia a scaricarsi e quella misera corrente è sufficiente a generare il lampeggio.
Se metti lo snubber su un relay ti fa il lampeggio uguale... o si attenua lo snubber o non so.



33  International / Hardware / Re: Sensore di temperatura collegato con 10m di filo on: January 09, 2013, 08:14:58 am
Oppure se qs e Paolo decidono di lavorare con l'INTERNAL

farò...ma dovete portare pazienza... l'attesa sarà comunque ripagata in quanto domani mi arriva anche un altro lm35 col quale intendo fare dei confronti serrati.
Il problema è che alberto non ha le resistenze giuste... e neanche io le ho proprio perfette... ma non è tanto importante imho averle perfette quanto averle sempre uguali ed è chiaro che tra i miei dati, quelli di paolo e quelli di alberto ci saranno discordanze dovute a queste resistenze.
34  International / Hardware / Re: Sensore di temperatura collegato con 10m di filo on: January 09, 2013, 05:44:17 am
Scherzi a parte, stiamo cercando solo di risolvere il problema di Alberto, mentre tu hai solo dato risposta a qs, mi pare, che aveva fatto una prova simile ottenendo risultati strani.

ma strani... non più di tanto... però ho notato che tra sensori di diverse tipologie che dovrebbero essere tarati e sicuri eccetera ci sono gradi di differenza... il test di paolo lo conferma ulteriormente.
L'idea sui test di Michele non l'ho accantonata: ho anche tagliato i miei 10 metri di filo per vedere se ci sono differenze sulle lunghe distanze solo che sono "depresso" e "smotivato": questi sensori sono "belli" nel momento che tu li metti su e non serve correggere nulla... e già in configurazione tipica direi che la cosa non è confermata... in configurazione figura 8 ci sono (a memoria) 6-7 gradi di differenza e comunque diversi da quanto indicherebbe il datasheet... se ho da mettermi a tararli col ghiacchio tanto vale che compro una ntc qualsiasi.
Volevo però chiedere lumi a Michele: sul datasheet figura 8 si indica Tambiet +10 e 0.10Volt per grado... quel Tambient + 10 significa che io avrei da misurare 10 gradi più di quello che è? in pratica se ho una stanza da 20gradi misuro 30? Si però allora perchè il range è a -5 e non a -10?


35  International / Hardware / Re: Schema triac e optotriac on: January 09, 2013, 03:51:04 am

Ma tu la stai provando su breadborad ? perchè io, non fidandomi molto di questa, mi sono soffato un piccolo circuito sulla mille fori..
Grazie

no no mille fori e saldata bene anche: non so mica che contatti ci sono dentro la bread...
Stasera ri-provo... però spenta è stata a lungo con o senza alimentazione... e chiaramente non ho notato nulla... anche il discorso di invertire fase e neutro l'ho fatto ma non ho avuto nessun riscontro.... provo di nuovo comunque...
Una banalità: a parte che se guardi la luce diretta poi vedi luce per 10 minuti ma è abbastanza normale che permanga una certa fluorescenza del tubo per diversi minuti: non accensione vera e propria ma una tenue fluorescenza dovuta alla natura della patina fluorescente interna del tubo che rimane eccitata.
Altra cosa: nei fotoaccoppiatori spesso c'è un terminale che è la base/gate che non viene utilizzato... quello basta sfiorarlo ed accende il contatto a tradimento... su questo moc mi sono guardato bene dal provare a toccarlo (non so manco se c'è) per via della 220 ma volevo chiederti di assicurarti che non ci siano fili o contatti troppo lunghi che prendano elettricità per aria.
Un'altra cosa: vivi per caso in un forno a microonde?  smiley-lol (scherzo ovviamente)

36  International / Hardware / Re: Schema triac e optotriac on: January 09, 2013, 02:59:46 am
Si.. sono lampade particolari per le piante da 20000 lux ciascuna.. Quella che tu usi mi brucerebbe le piante nel giro di 2 secondi con il calore che fa  smiley-grin
Non sono esattamente pompe per gli acquari ma per nebulizzare e quindi con molte bar... mentre si .. le resistenze sono naturalmente carichi resistivi... ma per fortuna non di molti watt  smiley-wink

mi è passata la voglia dell'acquario... ma quanto paghi di enel?  smiley-lol
...però non mi è passata la voglia di venire a capo di 'sto triac... allora ti dicevo ieri sera ho ricomposto su il circuito con il triac ed il moc... la prima versione è un triac BC???, una resistenza, un MOC30vattelapesca. La resistenza è tra il moc ed il gate giusto per non saper ne leggere ne scrivere....mi pare ma non mi ricordo esattamente che sia da 1k... non c'è altro.
la seconda versione è uguale alla prima ma ha tra T1 e T2 una resistenza da 100ohm e un condensatore ceramico da 0.01uF.
Ho attaccato due tipi di lampade: una osram normale da 14W ed una cinesata a palla gigante da 35Watt.. ho lanciato il programma blink e blinkano tra l'altro con sorprendente regolarità (in considerazione che l'accensione non è una fase immediata ed infallibile)... non mi è sembrato il caso di protrarre l'esperimento per più di 30-40 secondi perchè le fluorescenti soffrono l'accensione e lo spegnimento... sarebbe da tenerle accese almeno 15 minuti...
Comunque vanno sia con l'attenuatore che senza attenuatore. La differenza con il tuo circuito iniziale è la resistenza che tu metti tra gate e T1 che trovo in tanti circuiti ma non in tutti (e probabilmente i valori dei componenti sparsi per il circuito): non ho avuto modo di provare questa cosa per motivi di tempo (lo so sono 3 secondi ma ho famiglia...)...magari provo stasera

37  International / Software / Re: acquisizione segnale analogico e misurazione della frequenza on: January 09, 2013, 02:30:29 am
@ qsecofr
Cosa serve un sistema antirimbalzo per un segnale creato elettronicamente?
@carloandrea
Puoi misurare il tempo tra 2 battiti e calcolarti in questo modo la frequenza cardiaca. Il vantaggio é che la misura é piú veloce.
Ciao Uwe


ho letto distrattamente come era fatto il sensore: c'è il classico led trasmettitore ed il ricevitore e c'è un operazionale che amplifica questo segnale... chiaramente questo segnale è molto molto flebile di suo... non so se dentro avesse dispositivi per stabilizzare il segnale ma mi è parso di no...mi è parso che fosse abbastanza terra terra come sensore... al che ho pensato che il minimo movimento o il dito freddino potessero fare dei rimbalzi non corrispondenti al battito cardiaco....diremo che ho pensato più ad un filtro passa basso che ad un antirimbalzo.
eppoi siccome siamo tutti malati di cuore in famiglia potrebbero esserci dei casi di extrasistole: mettendo il ramo else sull'antirimbalzo ed un flag forse li becchiamo  smiley-mr-green

38  International / Software / Re: acquisizione segnale analogico e misurazione della frequenza on: January 08, 2013, 04:20:16 pm
prova questo... pinCardio = A0...
Dai un occhio al sistema di antirimbalzo ho messo 10ms... forse per il cuore sarebbe meglio mettere 100...
Si basa sul fatto che l'input è comunque digitale altrimenti bisogna sostituire il digitalread con l'analog e settare dei livelli di high e low.

prima dei 15 secondi sulla seriale non esce nulla ovviamente... e va di 15 in 15... che non mi piace tanto ma per il momento vedi se puoi digerirlo...




Code:
const int  CardioPin = A0;    
const int ledPin = 13;      

long oldMillis;
long oldMillis_antiBounce;

byte contatore = 0;
byte stato = 0;
byte ultimoStato = 0;


void setup() {

  pinMode(CardioPin, INPUT);
  pinMode(ledPin, OUTPUT);
  // initialize serial communication:
  Serial.begin(9600);
  oldMillis = millis();
  oldMillis_antiBounce = oldMillis;
  
}


void loop() {
  
  stato = digitalRead(CardioPin);
  if (stato != ultimoStato) {

    if (stato == HIGH) {
      //sistole...fronte di salita...
      digitalWrite(ledPin, HIGH);
      if ( millis()- oldMillis_antiBounce  > 10)
              {  // se impiega meno di 10 millisecondi per cambiare di stato è un rimbalzo e non lo conto
              contatore ++;
              oldMillis_antiBounce = millis();

              };
                    
      } else {
      // else stato = low significa che sono in diastole
              digitalWrite(ledPin, LOW);
    
      
    }
    ultimoStato = stato;  // lo stato è variato
  }

   if ( millis()- oldMillis  > 15000) {
     //15 secodi di statistica... calcolo media
     Serial.print ("bpm:");
     Serial.println ( contatore * 4);
     contatore = 0;
     oldMillis = millis();
     oldMillis_antiBounce =      oldMillis;
     }

  
}



39  International / Software / Re: acquisizione segnale analogico e misurazione della frequenza on: January 08, 2013, 02:21:16 pm
ho fatto delle prove e i ho concluso che il segnale essendo simile ad un onda quadra viene letto anche in digitale

quindi sei a posto? vuoi sapere come si fa a calcolare la frequenza?
40  International / Hardware / Re: [RISOLTO] Problema con sonda on: January 08, 2013, 02:17:21 pm
Allora,
Si, ho notato che posso triggerare l'evento che voglio (RAISE, FALL ecc)... 
in sostanza devo contare gli impulsi per sapere la quantità di liquido versato.
Come frequenza, anche spremendola al massimo cioè 15 litri al minuto, ho 0,25 litri al secondo cioè  207 Hz al massimo. (830 impulsi al litro)
Mi chiedevo se usando l'interrupt avrei avuto una precisione maggiore o una misura più "certa" in qualche senso...
Grazie


ok...lo fai anche senza interrupt... se non ti metti a fare delay e stupidate per i tasti... comunque la soluzione interrupt è "da campioni"  smiley-mr-green
l'unica cosa è il deboucing... che però se sai come si fa è una stupidata... e se non sai come si fa si fa come ha fatto questo signore:
http://arduino.cc/forum/index.php/topic,45000.0.html
41  International / Hardware / Re: problema con sonda on: January 08, 2013, 01:30:44 pm
l'interrupt ti permette di gestire l'evento (anche il change se vuoi) senza perderne mai neanche uno... ossia quando il pin sale qualsiasi cosa stia facendo il codice lui si ferma e fa quello che dici tu (che verosimilmente sarà l'incrementare un contatore).
Dipende da quello che devi fare: imho è un buon metodo per contare molto rapidamente e molto "certamente" senza che il resto del programma interferisca... però se ti funziona anche senza gli interrupt ed il segnale non è comunque velocissimo o non ti serve una precisione assoluta puoi anche tenerlo così
42  International / Software / Re: Velocità del loop on: January 08, 2013, 07:52:28 am
al contrario, l'overhead del mega lo senti di più più usi le sue periferiche: la digitalWrite è molto più lenta dell'uso dei registri per via dei check. Ora, su una mega hai più check da fare (o meglio, più registri su cui cercare quello che ti serve), quindi più overhead. un loop vuoto, con interrupt al minimo, dovrebbe dare l'identico risultato, salvo black magic del compilatore

si hai ragione: per l'operazione di i/o puro si (digital read/write)... però in un programma ci sono anche chiamate a funzioni, calcoli, stringhe... quando non ci infiliamo addirittura dei delay. In questo senso penso che nel 99% dei casi di questo overhead aggiuntivo del mega non ce ne freghi assolutamente un piffero.... poi sicuramente per la legge di murphy quell'1% è l'1% che ti tiene sveglio la notte e non ti permette di terminare il programma  smiley-lol
Mi piacerebbe sapere per esempio ripetendo allo sfinimento un lcd.print (che è un'operazione pesantina proprio sull'i/o) in quanto consiste la differenza tra uno e mega.... il protocollo hitaci prevede che il display abbassi qualcosa per capire se ha ricevuto il dato?

43  International / Hardware / Re: Schema triac e optotriac on: January 08, 2013, 07:38:32 am
Non sono proprio 25 watt... ma sono 3 lampade da 125watt effettivi.. naturalmente comandate separatamente...
poi oltre alle lampade ho altri dispositivi da pilotare, tra cui due pompe, delle resistenze di calore , un umidificatore ad ultrasuoni.. d
Ok fai pure la prova e speriamo che uwe mi dia qualche consiglio, perchè vorrei togliermi dalle scatole i "vecchi" relè meccanici... on con i triac o con gli RSS.

cosa intendi per effettivi? tre lampade fluorescenti da 125W cadauna??? Il faro che mi illumina un lato della  casa di notte fa 70W (ioduri metallici)... fa la luce di una alogena da 500W... è come un faro della strada... smiley-eek
Le pompe da acquario anche li hanno pochissimi watt ma comunque sono carichi induttivi ai quali prestare attenzione, le resistenze sono carichi resistivi pressochè puri... e li si si sale facilmente di watt...
44  International / Software / Re: Velocità del loop on: January 08, 2013, 07:03:54 am

Posso pure confermare il dato rilevato da Pablos con lo sketch di Tuxduino, pure sula mia 2560 gira a circa metà velocità, e questo si che è preoccupante perché da un punto di vista teorico non dovrebbe essere possibile.
Per capirci qualcosa tocca analizzare l'assembly del programma compilato per la UNO e quello per la 2560, per i test ho utilizzato l'IDE 1.0.3 con il compilatore di serie.


questa sera spero di trovare il tempo per fare due prove: vediamo qualcosa di assembler... ma non sarà facile: il cliclo di "cont++" fatto sul programma lestro che ho provato ieri sera veniva ottimizzato... o meglio veniva proprio tolto tant'è che 65000 incrementi impiegavano 0 microsecondi mentre sommando una variabile (contenuto 1) il compilatore non poteva ottimizzare e segnava diversi microsecondi... come avrebbe dovuto essere.
L'altra prova è di staccare gli interrupt che non sono essenziali al codice o meglio staccare tutti i  timer tranne lo 0.
Inoltre non so cosa succeda sugli i/o... ossia quando alzo un pin di arduino lui occupa cicli di clock per spostare questo dato sul PORTx oppure è una cosa hardware che funziona indipendentemente?... qui ho un dubbio.
Una cosa comunque per me è abbastanza chiara: c'è un overhead più grande sul mega ma il fatto che noi misuriamo tempi doppi non significa che l'uno sia il doppio più veloce... in pratica quando misuriamo con i programmi di tuxduino o lestro i tempi misuriamo un (imho) 20% di nostro codice ed un 80% di overhead: però i ns programmi sono ben più seri di un ciclo vuoto: in questi casi diluiamo questo overhead e quindi le differenze tra mega e uno si assottigliano paurosamente.... non so se mi sono spegazzato...
 
45  International / Software / Re: Velocità del loop on: January 08, 2013, 06:17:47 am
lo speed test è chiaramente un buon test ma imho non è veritiero di talune situazioni: non perchè sia fatto male ma perchè è studiato in modo differente e pertanto lascia dei dubbi.

Se il dubbio è: il processore dell'UNO è più lento del processore del Mega la risposta è chiaramente NO... ma probabilmente non c'era neanche bisogno di stare qui a discutere: è banale la cosa, la frequenza è uguale, l'operazione di nop per definizione occupa la cpu in un ciclo di clock... non c'è altro da inventarsi...
In probabilità, ma senza curiosare molto sui manuali atmel, possono esistere delle operazioni assembly che richiedono un ciclo in più o in meno nei due processori ma le differenze, ammesso che ci siano,  saranno del tutto secondarie.
Ma allora se il processore è pressochè uguale la uno va come la mega? No: dipende da cosa ha da fare il processore in più rispetto al programma: la mega ha più porte da controllare (ed imho tanto tanto incidono i timer però attendo di fare le prove stasera). Oppure il compilatore fa delle cose "impreviste" nelle due versioni: purtroppo i primi programmi fatti da lestro e da me testati saranno pure "congetture" ma hanno evidenziato che il compilatore fa delle ottimizzazioni "non scontate" e che lo stesso codice su due board differenti porta a risultati nettamente differenti....probabilmente non per colpa dei tempi di esecuzione del codice nostro ma per i tempi di gestione (codice degli interrupt, controllo delle porte... non so)
Pages: 1 2 [3] 4 5 ... 20