Go Down

Topic: TX dati + Alimentazione su unico filo (Read 808 times) previous topic - next topic

zoomx

Una vecchia discussione in proposito
http://forum.arduino.cc/index.php?topic=181337.0
A quanto pare c'è qualcosa di già pronto per i Picaxe
http://www.kranenborg.org/ee/picaxe/twowirenetwork.htm
E qui qualcuno ha avuto la mia stessa idea, usare modem per powerline
https://forum.arduino.cc/index.php?topic=382590.0

Diego67

Una vecchia discussione in proposito
http://forum.arduino.cc/index.php?topic=181337.0
A quanto pare c'è qualcosa di già pronto per i Picaxe
http://www.kranenborg.org/ee/picaxe/twowirenetwork.htm
E qui qualcuno ha avuto la mia stessa idea, usare modem per powerline
https://forum.arduino.cc/index.php?topic=382590.0
Ciao zoomx , ti ringrazio per aver fornito alcune informazioni richieste nel mio primo intervento.

Riguardo al primo link sinceramente non l'ho letto tutto ma ad un certo punto ho visto che si fa riferimento a quanto riportato sul secondo link.

Riguardo al secondo link, sarebbe bello capire se esistono già in commercio delle schede funzionanti ed eventualmente le loro caratteristiche circa la velocità di trasmissione dati . Ho guardato sul pdf presente sul sito ed ho trovato le seguenti frasi che mi sembrano, per quel che ci capisco, tra loro contrastanti.

Execution of time-consuming instructions: The PICAXE has a code interpreter, which implies that code instruction speed is relatively low (order of a millisecond for the PICAXES at moderate clock speed).

The network can be built according to any topology, as the network impedance (through Rpullup) is quite low and the communication speeds are low as well (2400 - 32600 baud).

Sarebbe interessante poi capire quali sono le capacità di pilotaggio in corrente. Da quanto ho potuto vedere nello schema elettrico la presenza sul master tra source e i +5v della resistenza R4 da 10 Ohm limiterebbe la corrente massima teorica a 500 mA ipotizzando una resistenza nulla della rete e una tensione di saturazione tra drain e source di 0 volt.

Per quanto riguarda il terzo link è una delle soluzioni note ma da me esclusa in partenza per l'elevato costo e la complessità.

zoomx

Il Picaxe è più vecchio di Arduino  (risale al 1999) ed è basato su PIC. Usa un interprete Basic da cui la lentezza di cui parla nella prima frase.
La seconda parla invece proprio della velocità di comunicazione della loro soluzione che va dai 2400 ai 32600 baud.



Hai visto il PDF?
http://www.kranenborg.org/ee/picaxe/SerialPower/V4.0/PicaxeSerialPowerNetwork_I_V4.0.pdf

L'ultima soluzione non mi è sembrata costosa, 5 chip su Aliexpress sono a 22 euro, dipende certo dal costo totale del nodo.

Penso che ci sarà qualcosa per l'IoT.

Diego67

Hai visto il PDF?
http://www.kranenborg.org/ee/picaxe/SerialPower/V4.0/PicaxeSerialPowerNetwork_I_V4.0.pdf
Si ho guardato quel file. le frasi riportate le ho estratte da li.

Per quanto riguarda la velocità spiegami una cosa perché sono duro di comprendonio e/o non mi è chiaro il significato di istruzione.
Se la loro soluzione è basata su PICAxe e questo esegue un'istruzione ogni millisecondo come fa a far commutare lo stato della linea almeno 2400 volte ogni secondo? Forse intendono la velocità da un PC a PICAxe che bufferizza e poi invia a velocità decisamente più basse? ( se fosse questa la spegazioni negli schemi non ho mai visto citate né interfacce seriali né PC )

Senza nulla togliere all'ultima soluzione, nel mio progetto, acquistando da Aliexpress l'Arduino e da altri siti il resto dei componenti ( da Ali non si trovavo tutti ) si spendono meno di 10€ per il master e ancor meno per gli slave avendo un Power Swich di meno. ( un BTF500601 incide da solo per 3,5€ )

zoomx

Come scrivevo prima, il Picaxe usa un basic interpretato, la lentezza riguarda l'esecuzione delle istruzioni in Basic. Leggere e scrivere dalla seriale però non viene eseguito in basic ma in istruzioni native del PIC. Significa (credo, non conosco il Picaxe ma immagino che faccia così) che mentre viene interpretato il tuo comando gira anche un altro pezzo di programma che prende i caratteri che arrivano dalla seriale e li mette in un buffer, esattamente come fa l'Arduino.
Quando in Arduino leggi dalla Seriale in realtà leggi dal buffer dovo vengono messi i caratteri ricevuti e decodificati.
Significa anche che se arrivano più caratteri di quanti ne possa contenere il buffer, questi vanno persi.
Sul Picaxe avverrà lo stesso leggerai, lentamente, dal buffer.

In breve, non preoccuparti della lentezza del Picaxe ma trai ispirazione dagli schemi elettrici

In quel PDF quindi è interessante l'hardware, ho visto che presenta una soluzione a tre linee mentre quella a due non mi è sembrata molto chiara. Però non l'ho guardato con attenzione.

Standardoil

io ho pensato:
se si fa +24v per il trasferimento di energia, interrotta ciclicamente, si può mettere, attraverso un diodo un 5V in pull-up sulla stessa linea, a fare una trasmissione seriale a filo singolo, attiva bassa, negli istanti di OFF POWER
si fa con solo un regolatore (switching) step-down pwr ogni slave e per il master, un regolatore Step-up o Step-down come viene comodo, con switch-off per l'alimentazione, che potrebbe anche NON essere controllata dal master, temporizzazioni ottenute in HW dedicato (555 docet)
e aggiungere una rete di zener in antiserie (per garantire una caduta minima pari alla tensione di zener) che faccia da ingresso di sync del master e degli slave
volendo fare una cosa figa, con solo 2 transistor in più si fa anche una inibizione HW dello open-collector della seriale quando è presente il 24V
magari dopo faccio schizzo (io non so disegnare)
si eviterebbe tutta la menata di dover elevare e stabilizzare la tensione da 5 a 12 o 24V, con vari regolatori e mosfet distribuiti in giro
Prima legge di Nelson (che sono io): Non scambiare il fine con il mezzo: ricorda "cosa" devi fare, non "come" devi farlo

Non bado a studenti, che copino altrove

Tu hai problema-Io ti domando-Tu non mi rispondi: vuol dire che non ti serve più

Diego67

si eviterebbe tutta la menata di dover elevare e stabilizzare la tensione da 5 a 12 o 24V, con vari regolatori e mosfet distribuiti in giro
Ciao Standardoil, attendo il tuo schema in quanto dalla descrizione non ho capito i vantaggi che tu proponi rispetto allo schema da me condiviso. Ho utilizzato un elevatore per ottenere i 24v (switching step-up) in quanto solitamente nelle centrali antiintrusione( ero partito con questa idea ) risulta presente una batterie da 12v. Nessuno vieta comunque, avendo una fonte di 24v di utilizzare un regolatore switching step-down per ottenere una tensione di 12v per l'alimentazione dell'Arduino e l'invio dei dati o, come fatto lato slave, visto il basso consumo dell'Arduino e la bassa potenza richiesta per l'invio dei dati, inserire un semplicissimo 7812 ( ho allegato nuovo schema con questa configurazione ). Sempre dal mio vecchio schema puoi vedere che di elevatori ne ho utilizzato solamente uno e ricordo che si trovano già fatti a meno di 1€ e con dimensioni quasi identiche a quelle di un Arduino Nano.
Per evitare incomprensioni allego una foto di un modulino elevatore in confronto ad un Arduino Nano ( il modulo step-down è identico ) e una foto con 2 delle tipologie di Power Switch da me utilizzate in confronto ad un normale transistor in contenitore TO220. Questi 2 tipi di componenti possono essere pilotati direttamente dall'Arduino con una semplice resistenza limitatrice nel caso del foto accoppiatore.
Questa mattina ho provato poi, per aumentare la velocità di trasmissione, a dimezzare sia la durata dell'impulso di alimentazione che quella di trasmissione dei simboli. Allego una foto (poco chiara) fatta allo schermo di un vecchio oscilloscopio analogico (33 anni) dove si vede nella parte superiore il susseguirsi delle trame e in quella inferiore la traccia espansa (20us/Div) per vedere la qualità dei fronti. Il puntale è inserito lato Slave dopo la solita matassa di cavo da 0,5 mm2 lunga circa 80m.

Standardoil

ah, sì chiaro adesso
in effetti considerando che sulle centraline hai 12V, è giusto
Prima legge di Nelson (che sono io): Non scambiare il fine con il mezzo: ricorda "cosa" devi fare, non "come" devi farlo

Non bado a studenti, che copino altrove

Tu hai problema-Io ti domando-Tu non mi rispondi: vuol dire che non ti serve più

Diego67

Buonasera a tutti. ho visto che tante persone hanno letto il thread in oggetto ma poche (4 in tutto che ringrazio) hanno dato un loro contributo. Prima di perdere ulteriore tempo in ottimizzazioni software/hardware mi piacerebbe capire se il ridotto numero di interventi derivi da una mancanza di chiarezza o da errori macroscopici nel progetto che gradirei conoscere.

Ringrazio anticipatamente quanti vorranno aiutarmi a capire.  :)

pippo72

mi piacerebbe capire se il ridotto numero di interventi derivi da una mancanza di chiarezza o da errori macroscopici nel progetto ... 
Secondo me dipende semplicemente dal fatto che ci sono poche persone che hanno la competenza per risponderti (io per primo)

Ciao
Pippo72

gpb01

#25
Apr 03, 2019, 08:20 pm Last Edit: Apr 03, 2019, 08:20 pm by gpb01
... mi piacerebbe capire se il ridotto numero di interventi derivi da una mancanza di chiarezza o da errori macroscopici nel progetto ...
... aggiungo a quanto detto da pippo72 che, inoltre, non è esattamente argomento di interesse generale (anzi, è piuttosto specifico) e chi, pur avendo le dovute competenze, non è interessato alla cosa ... difficilmente interverrà. ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

Standardoil

E io aggiungo:
Non è chiaro se stai condividendo o chiedendo
Hai fatto un prototipo e va?
Hai postato gli schemi quindi credo di sì
E allora posta anche il codice, e condividi la tua esperienza.
Cerchi invece delle soluzioni ad un problema?
In questo caso dicci quali sono le tue necessità, prescrizioni, limitazioni
Io avevo capito che cercavi suggerimenti, invece dalle tue risposte ho poi capito che hai già ben chiara la parte hw.
Quindi non so più a che domande dovrei rispondere....
Prima legge di Nelson (che sono io): Non scambiare il fine con il mezzo: ricorda "cosa" devi fare, non "come" devi farlo

Non bado a studenti, che copino altrove

Tu hai problema-Io ti domando-Tu non mi rispondi: vuol dire che non ti serve più

Diego67

Ringrazio pippo72 e gpb01 per il loro chiarimento e cerco di rispondere a Standardoil.

Inizialmente, descritto il funzionamento del "protocollo", chiedevo se esistesse già qualcosa di simile già fatto, testato e funzionante da poter acquistare ( a pochi soldi ) ed utilizzare. Non avendo ricevuto risposte chiare in merito ho cercato di esplicitare meglio cosa volevo ottenere e come io l'ottenevo.
Nel mio ultimo intervento faccio riferimento in modo particolare al "protocollo" di trasmissione/ricezione ( quello che ho chiamato PID ). Non mi sono soffermato tanto sull'hardware ed il software perché sono strettamente legati al protocollo e se questo ha dei possibili problemi che lo rendono inutilizzabile anche l'hardware ed il software divengono inutili. Come già detto Il progetto l'ho realizzato e testato su breadboard e funziona. Purtroppo però questo non basta per dire che è realizzabile e sfruttabile su "larga" scala.

Aspettavo e temevo che qualcuno mi riportasse una o più delle seguenti obiezioni:
 
- Il sistema è troppo sensibile ai disturbi non essendo i dati tramessi in forma differenziale  come  ad esempio nella RS-485.

- I picchi di corrente per la carica dei condensatori negli slave porta a notevoli dispersioni di energia su linee di una certa lunghezza e piccola sezione.

- Gli impulsi di alimentazione possono portare a disturbi di tipo elettromagnetico dannosi per appartati di tipo a,b,c. ( lettere casuali )

- La componente continua in linea porta , col passare del tempo, ad ossidazione e riduzione della linea in rame con possibile interruzione dei collegamenti.

Ecc. ecc.

Per quanto riguarda il software non ho problemi a pubblicarlo anche se non ancora giunto ad una versione definitiva. Certo è che come ho descritto questo era pensato per la gestione di una scheda per la remotizzazione di ingressi/uscite per una centrale antiintrusione. Risulta quindi un argomento specifico che non interessa a molti. L'analisi del protocollo si presta invece ad applicazione di uso più generale.
Riporto comunque di seguito alcune funzioni su cui si basa il progetto per quanto riguarda il Master. Come si può vedere il codice risulta banale e si basa in ricezione sulla funzione pulsein.
Master -> Blocco2, Slave -> Blocco3.

Code: [Select]


unsigned int BaseTempi = 4; // Microsecondi riferimento
unsigned int BaseTempiMax = 100;
unsigned int T_Power = 1000; // Tempo per ricarica condensatore alimentazione blocco 3
unsigned int T_0 = 10 * BaseTempi;
unsigned int T_1 = 20 * BaseTempi;
unsigned int T_2 = 30 * BaseTempi;
unsigned int T_3 = 40 * BaseTempi;

void TX_ImpulsoLibero(int Pin , unsigned int T_Impulso)
{
   digitalWrite(Pin, HIGH);
   if (T_Impulso<16000)
     delayMicroseconds(T_Impulso);
   else
     delay(T_Impulso/1000);
   digitalWrite(Pin, LOW);
}

void TX_ImpulsoPredefinito( int Pin, byte Valore)
{
   unsigned int usImpulso;
   if (Valore==0)
     usImpulso=T_0;
   else if (Valore==1)
     usImpulso=T_1;
   else if (Valore==2)
     usImpulso=T_2;
   else if (Valore==3)
     usImpulso=T_3;
   TX_ImpulsoLibero(Pin, usImpulso);
   delayMicroseconds(T_Pause);
}

void TX(int Pin ,unsigned int *s, byte N_Bit_Write)
{
   unsigned int Dato = *s;
   for(int n=0; n < N_Bit_Write; n+=2)
    {
      byte Valore = bitRead(Dato, n) + 2 * bitRead(Dato, n+1);
      TX_ImpulsoPredefinito(Pin,Valore);
    }
}

byte TX_Doppio(int Pin ,unsigned int DatoTX, byte N_Bit_Write, bool AttesaEsitoLettura)
{
   unsigned int EsitoScrittura = Scrittura_OK;
   DatoTX += (DatoTX << 8); // Copia il LSB sul MSB per permettere a blocco 3 di controllare eventuali errori di trasmissione
   TX(UscitaDati, &DatoTX, N_Bit_Write); // Trasmette N_Bit_Write bit
   
   if (AttesaEsitoLettura) EsitoLettura = RX(IngressoDati,&EsitoScrittura, 2);  //resta in attesa di un segnale in ricezione da Blocco 3
   return EsitoScrittura + EsitoLettura << 1 ;
}

byte RX( int Pin, unsigned int *s, byte N_Bit_Read) // Ritorna 0 se riesce a leggere correttamenti i dati
{
  boolean EsitoLettura = Lettura_OK;
  unsigned int T_Imp=0;
  unsigned int DatoRX = 0;
   
      for(byte n=0; n < N_Bit_Read; n+=2)
         {   
            T_Imp = pulseIn(Pin, HIGH, T_Max_Wait);
            if (T_Imp == 0)
                EsitoLettura = Lettura_KO;
            else if (T_Imp > (T_0 - T_Delta_Neg) && T_Imp < (T_0 + T_Delta_Pos))
              {
                bitWrite(DatoRX, n, 0);
                bitWrite(DatoRX, n+1, 0);
              }
            else if (T_Imp > (T_1 - T_Delta_Neg) && T_Imp < (T_1 + T_Delta_Pos))
              {
                bitWrite(DatoRX, n, 1);
                bitWrite(DatoRX, n+1, 0);
              }
            else if (T_Imp > (T_2 - T_Delta_Neg) && T_Imp < (T_2 + T_Delta_Pos))
              {
                bitWrite(DatoRX, n, 0);
                bitWrite(DatoRX, n+1, 1);
              }
            else if (T_Imp > (T_3 - T_Delta_Neg) && T_Imp < (T_3 + T_Delta_Pos))
              {
                bitWrite(DatoRX, n, 1);
                bitWrite(DatoRX, n+1, 1);
              }
            else 
                EsitoLettura = Lettura_KO;
          }

      *s = DatoRX;
      DatoRX = 0;   
         
  return EsitoLettura;
}

void TX_Power(int Pin)
  {
    TX_ImpulsoLibero(Pin,T_Power); // Trasmette impulso per alimentazione
    delayMicroseconds(T_Pause_Power); 
  }

zoomx

Non chiamare il protocollo PID che è già l'acronimo del  controllo Proporzionale-Integrale-Derivativo.

Per il resto vedo che tu già ne sai molto più di me.

Il problema disturbi  non è semplice da affrontare e potrebbe essere determinante ma anche qui non saprei aiutarti se non suggerirti di usare uno scanner per controllare eventuali disturbi emessi, io ne uso uno realizzato con una pennetta per TV digitale con driver modificati.

Claudio_FF

#29
Apr 04, 2019, 06:13 pm Last Edit: Apr 04, 2019, 06:21 pm by Claudio_FF
Il sistema è troppo sensibile ai disturbi non essendo i dati tramessi in forma differenziale  come  ad esempio nella RS-485.
Non è detto, nella 485 si usano livelli mark/space decisamente inferiori, e quindi maggiormente alterabili.

Quote
I picchi di corrente per la carica dei condensatori negli slave porta a notevoli dispersioni di energia su linee di una certa lunghezza e piccola sezione.
Mi sembra che sia un problema solo usando basse tensioni, con 24V non vedo problemi.

Quote
Gli impulsi di alimentazione possono portare a disturbi di tipo elettromagnetico
Un doppino ben intrecciato li dovrebbe evitare (sia emessi che ricevuti), mentre la schermatura serve di più per il campo elettrico/elettrostatico.

Quote
La componente continua in linea porta , col passare del tempo, ad ossidazione e riduzione della linea in rame con possibile interruzione dei collegamenti.
Passo  :D


Quello che temo di più in un sistema così sono invece disturbi condotti, ground bouncing, noise loop, sourge burst. In sostanza se alle estremità remote ci sono altri alimentatori con masse in comune, dal punto di vista dei disturbi si potrebbero creare anelli di cui il bus in questione è uno dei pezzi, e gli altri pezzi sono gli alimentatori e i cavi energia con le eventuali terre. Potrebbero essere necessarie anche delle ferriti per bloccare la RF. Nota, i disturbi burst ad alta frequenza possono attraversare tranquillamente anche gli optoisolatori (che vengono visti come piccoli condensatori).
* * * *    'if' e 'case' non sono cicli   * * * *
* * * Una domanda ben posta è già mezza risposta. * * *
* La corrente si misura in 'mA', la quantità di carica in 'mAh' *

Go Up