PJON - Multi-master, multi-media network protocol stack

[_nabla_]

Eh sei in una situazione non proprio tradizionale, per quello hai risultati così buoni.

Dalla tua parte hai la relativa lentezza della comunicazione e la banda (intesa come tempo nel quale il bus è in comunicazione rispetto a quanto è a riposo) bassa, cose che sicuramente giovano al riconoscere correttamente i livelli logici ed avere margini per una eventuale ritrasmissione del pacchetto senza sovrapporre i flussi dati.

Ma la cosa più importante è l'alimentazione che è veramente poco influenzata dalle spurie di rete. Non tutti possono contare su un sitema del genere. Magari hai pure la fortuna di non abitare a ridosso di industrie...

Il cavo di rete immagino sia STP (schermato) o comunque molto ben fatto perché sei in una situazione ancor più roesea di cosa potessi immaginare.

Il fatto che il cavo sia attorcigliato aiuta, ma l'effetto di protezione sarebbe decisamente migliore se al suo interno passasse una connessione bilanciata (come lo sono le connessioni Ethernet, RS485 ecc).

Visto come hai fatto la rete fisica, non avrai problemi a fare un upgrade ad un sistema bilanciato quando noterai errori di comunicazione.

Fossi in te metterei però almeno uno zener in ingresso di ciascun modulo per evitare che qualche spuria ti faccia fuori l'intera rete. Sono facilmente reperibili, costano pochissimo, e non fanno certo miracoli, ma un minimo di protezione la danno, per lo meno riesci a circoscrivere l'area danneggiata.

Se un domani dovessi decidere per aumentare la velocità del bus, con quella rete potresti trovarti errori dovuti alle riflessioni. In tal caso dovrai sperimentare inserendo dei terminatori (resistenze a massa) come si faceva sulle vecchie reti a stella con cavo coassiale.

[gioscarab]

Ciao!!
Allora, ho un pull down resistor o resistenza a massa da non mi ricordo quanti megaohm (controllo) perche' come scrivo nel readme di PJON aiuta a ridurre l'effetto delle reflections o riflessioni e riduce la tensione di eventuali carichi indotti da fonti elettromagnetiche esterne all'impianto!

Mi spieghi meglio che effetto ha e che diodo zener mi consigli?

L'impianto si trova nel centro di Milano, effettivamente capita che ci siano spurie di rete e si vedono le lampadine variare intensita' per qualche istante. Tutto il sistema e' alimentato dal generatore solare e le sue batterie, un po' come esperimento e un po' perche' la casa non muoia del tutto se salta la corrente.

Che tipo di accorgimenti mi consigli parlando di fulmini intorno alle batterie e i pannelli per evitare che la scarica possa arrivare in casa e dare fuoco a qualcosa? un semplice fusibile dici che basta o ci sono ulteriori guidelines da seguire in questo senso?
 

[_nabla_]

Sarò ciecato, ma non ho visto cenni alla resistenza nel readme che c'è su GitHub, per quello ti dicevo di metterla.

Lo zener impedisce allla linea di andare oltre una certa tensione. Se hai un bus a 5V e metti uno zener di valore superiore, di norma non interviene mai. Ma se qualche condizione esterna porta ad avere più di 5 volt sulla connessione, lo zener trasforma in calore questa energia in eccesso.
Ha solo il difetto di essere un po' lento e quindi si preferisce il TVS (comportamento simile ma più rapido).
In sostanza lo scopo è di non far fuori la porta del micro a causa di extratensioni in arrivo dall'esterno.
Il microcontrollore ha già di suo un po' di protezioni, ma sono per forza di cosa minime, quindi è meglio averne di esterne.

Se un fulmine colpisce in pieno l'impianto non c'è nulla da fare, quindi i fusibili da soli farebbero pocco. Hai fatto bene comunque a metterli perché è sempre meglio avere dei circuiti di sicurezza (es, proteggere da cortocircuiti accidentali)
Quello da cui guardarti è il caso di un fulmine non troppo distante, in quel caso potresti avere picchi di tensione di qualche decina di volta per pochi millisecondi, sufficienti a distruggere le porte del micro (ma niente incendi o cose di questo genere), in quel caso un semplice TVS ti salva la porta del mocrocontrollore.

[gioscarab]

Hai ragione, la delucidazione riguardo le pull down c'e' solo nei commenti nel codice 
Grazie della segnalazione 

[gioscarab]

Ciao a tutti, ciao Paolo!  
Come puoi vedere ho accettato la tua pull request e modificato estensivamente la libreria. Attualmente in master sono finalmente presenti le modifiche a cui stavo lavorando in locale da tempo. Finalmente esiste un readme decente e degli esempi funzionanti. Grazie per il tuo supporto.

Posso dire di essere vicino alla release della 1.0    
https://github.com/gioblu/PJON

Cosa ne pensate???

[PaoloP]

Ho fatto la richiesta (spero non ti dispiaccia) per l'inserimento nel library manager.
Però devi creare una release.
--> https://github.com/blog/1547-release-your-software

Mi serve un po' di tempo per testarla e comunque ho un probabile progetto dove utilizzarla.

[PaoloP]

La libreria è stata aggiunta.
--> https://github.com/arduino/Arduino/issues/3837#issuecomment-142242947

Come già detto manca la release. 

[gioscarab]

Ciao Paolo, grazie del tuo supporto!!   
Sono stato molto preso dal lavoro e nel gestire tutte le richieste, commenti e proposte relative a PJON grazie a un post su hackernews rimasto in prima pagina per piu' di un giorno  . Mi hanno chiesto molto insistentemente di documentare lo "Standard" PJON per permettere una facile implementazione o porting su altri dispositivi. Ci sono gia 3 issues per compatibilita' ARM, raspberry e attiny.

Qui trovate la wiki:
https://github.com/gioblu/PJON/wiki

Cosa ne pensate?

[_nabla_]

Mi pare di capire che, per distinguere i singoli bit in arrivo, non usi il classico oversalpling (quello che si usa nella RS232 per intenderci) ma ti affidi "solo" a dei loop di attesa.

Dovresti provare a mettere nel bus una scheda con il clock volutamente un po' fuori tolleranza (a parte cambiare quarzo, ci in genere ci sono modi per variare il clock tramite i registri interni dei microcontrollori, credo che questo valga anche per Arduino) e vedere cosa capita.

Specie se intendi fare  il porting (o  approvare ufficialmente porting fatti da terzi) su altri microcontrollori, ti accorgerai che il clock nel mondo reale può avere forti tolleranze dovute a fattori su cui non puoi avere controllo. E' necessario che la libreria sappia deformare (entro certi limiti) ed in tempo reale i tempi di attesa per riconoscere gli "1" dagli "0".

Nel caso di errori dovresti implementare quello che per la RS232 è il frame synchronization.

Ti suggerirei (ma questo non è un bug ma una proposta per migliorare la libreria) di prevedere qualche forma di auto-indirizzamento. Almeno prevederla a livello di protocollo. Poi se e come usarla puoi farlo in un secondo tempo.

[gioscarab]

Grazie degli utili consigli ed e' un piacere vedere che tu ti sei interessato e abbia letto lo standard e la documentazione. Allora, quello di cui sono abbastanza convinto e' che per esempio, la raspberry avra' una "percezione del tempo" diversa da un arduino e quelli che sono 10 microsecondi per arduino potrebbero essere 8 o 12 per la rasp (dico numeri a caso). Per ovviare al problema il primo approccio a cui ho pensato e' variare   la definizione della durata di un bit nella raspberry fino ad ottenere una durata identica a quella generata dall'arduino. A quel punto nel porting avrai una definizione di lunghezza del bit diversa da quella presente nell implementazione dell arduino che pero' avra' effettivamente la stessa durata. Un'altra soluzione e' di certo quella proposta da te. Cosa ne pensi?

[_nabla_]

In teoria non fa una piega, in pratica però c'è da testare un po' di cose.

Raspberry non è un microcontrollore semplice ma ha un layer software molto complesso (ci gira linux, non quattro routine C in croce come siamo abituati con i micro a 8 bit...)
Ne consegue che una implementazione software delle temporizzazioni potrebbe essere o estremamente precisa (ci sono risorse in abbondanza per gestirla) o estremamente scostante (perché qui hai un vero multitasking e quindi le temporizzazioni seguono concetti base molto differenti), dipende da come è scritta la routine di delay e da come la distribuzione linux gestisce il multitasking.

Hai buone probabilità che la tua soluzione funzioni, ma non potrei scommetterci su. Devi provare.

[icio]

Tutte le problematiche in relazione al time-shift vengono risolte con un hardware appropriato che con contatori multipli al data-rate compensano differenze dovuti a quarzi da 50-200ppm e impedenze di linea dati, quì invece siamo di fronte a un protocollo totalmente software basato su un hardware standard minimale, per tenere leggero il carico software del protocollo una certa rigidezza sul timing penso sia più che tollerabile

[_nabla_]

Mah, l'versapling sulla rs232 veniva fatto via software sugli ST6 a 8 bit... non è niente di complicato. Si legge lo stato di una porta più volte al secondo di quanto servirebbe in teoria, e poi si conta se il passaggio da zero a uno e viceversa è capitato prima o dopo una certa soglia.
Alla fine è una manciata di righe di codice.
Certo bisogna vedere se davvero serva o no (per questo chiedevo un test esasperando un po' l'errore del quarzo), ma quanto a "carico software" si tratta di un impatto minimo.

[gioscarab]

Ciao! Sto ragionando a una nuova parte di questo standard che permetta la creazione di un unica grandissima rete, fatta di n bus con max 255 nodi, tutti connessi assieme tramite routers (un po' come internet).

Per supportare la possibilita' di comunicare da qualsiasi nodo di un bus a un altro nodo di un altro bus e' necessario:

-sapere identificativo univoco bus (BID)
-sapere identificativo univoco pacchetto (PID)
-sapere identificativo univoco device destinatario (DID)
-Il router deve conoscere gli identificativi dei bus ai quali e' connesso

quindi un pacchetto potrebbe essere fatto cosi:

simbolo pacchetto outbound (non per un device all'interno del bus locale) 1 byte
BID (4 byte)
DID (1 byte)
PID (2 byte)
contenuto
CRC

Il pacchetto verra' inviato al router presente nel bus del device trasmittente. Questo lo inviera' ai router presenti nei bus ai quali e' connesso e cosi' via, finche' uno dei router che ricevera' il messaggio all'interno della rete avra' nella lista degli identificativi bus conosciuti quello richiesto. A questo punto dovra' solo inviare un pacchetto locale (quello con cui ora funziona PJON) e comunicare all'identificativo del device all'interno del bus. Un pacchetto ACK partira' dal destinatario verso il mittente, e fara' la strada inversa all'interno della rete contenendo ACK e l'id del pacchetto cosi' da permettere il mittente di avere la sicurezza di aver ricevuto il messaggio.

Cosa ne pensate?? Offrendo una struttura del genere se un sacco di gente lo usasse, sarebbe possibile creare un sistema come APRS per comunicare pacchetti dovunque sia presente la rete.

[gioscarab]

Ohhh finalmente adesso PJON ha un porting stabile funzionante anche con i moduli radio ASK 433Mhz!!
https://github.com/gioblu/PJON_ASK

Fatemi sapere cosa ne pensate!! Con queste due librerie e' possibile realizzare un router che puo' spostare pacchetti in arrivo da radio a filo o ancora peggio su internet (includendo una libreria per ethernet shield), un po' come funziona APRS!

Pero' devo decidere come definire i pacchetti outbound come dicevo nella risposta precedente per poter definire questa parte.