Arduino Forum

International => Italiano => Megatopic => Topic started by: gioscarab on Aug 07, 2015, 05:09 am

Title: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on Aug 07, 2015, 05:09 am
Ciao ragazzi, vi parlo a piu' riprese da anni delle mie peripezie con i protocolli di comunicazione custom scritti da me. Vivo da solo ormai da un po' e ho lavorato a casa mia per piu di due anni per l'automazione della casa. Per farlo ho avuto bisogno di una libreria comoda da usare per poter programmare una rete di arduino boards per comunicare assieme e a una scheda master il loro stato o saper rispondere a una richiesta.

Ho avuto modo di scrivere il readme che illustra in maniera piuttosto precisa come funziona:
https://github.com/gioblu/PJON (https://github.com/gioblu/PJON)

Spero che qualcuno di voi abbia piacere di testare questa libreria perche' e' davvero divertente con poche righe veder succedere cose piuttosto complesse!!


Ho costruito le pulsantiere delle luci di casa con un arduino integrato, alcuni sensori e la scheda relais. La cosa bellissima della libreria e' poter definere:

da un lato la pulsantiera che ogni 60 secondi trasmette la temperatura con un header identificativo T al device numero 123
Code: [Select]
network.send_command(123, "T", temperature, 60000000);

dall'altro lato, il codice del device 123 e' semplicemente:
Code: [Select]
network.add_reaction("T", update_temperature);

il tutto funziona in background e l'unica cosa da fare e' da un lato chiamare:
Code: [Select]
network.update();

e dall'altro
Code: [Select]
network.receive();

in ogni caso vi consiglio la lettura del readme per avere una visione piu' chiara perche' come al solito sono le 5 e alle 9.45 devo alzarmi e lavorare!!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 07, 2015, 08:02 am
Bentornato.

Perchè non converti la libreria nel formato 1.5?
--> https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification (https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification)
Sarebbe interessante aggiungere anche il .json e il .properties, oltre a cambiare le estensioni degli esempi da .pde a ino.

Library manager --> https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ (https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ)
Naturalmente tutto questo è per l'IDE 1.6.5 e successivi.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: vbextreme on Aug 07, 2015, 08:56 am
Commenti/Critiche, è un bel progetto e innanzitutto i miei complimenti.
Mi fa anche piacere vedere che hai usato la "mia" funzione di swap, anche se nel tuo caso la variabile temporanea deve essere settata come byte e non come int.
Usi un mix di tipi,  non che non si possa fare ma è poco elegante.
Code: ("at line 220 from PJON.cpp" ) [Select]

*string_pointer++;

Questo funziona per miracolo!
la forma corretta è
Code: [Select]

string_pointer++;

o in maniera più amata dai programmatori c:
Code: [Select]

++string_pointer;

Detto questo una buona rilettura sul capitolo dei puntatori non fa mai male.

Buona Vita
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: astrobeed on Aug 07, 2015, 09:11 am
Ciao ragazzi, vi parlo a piu' riprese da anni delle mie peripezie con i protocolli di comunicazione custom scritti da me.
In tutta franchezza non vedo la necessità di inventarsi un nuovo protocollo di comunicazione quando ne esistono molti free, perfettamente documentati, completi di librerie per Arduino stracollaudate e affidabilissime, tanto per citarne uno il modbus.
Far dialogare una rete con un sistema onewire sulle lunghe distanze, sopratutto in ambito casalingo, è volersi fare del male da solo, oltre alla eccessiva lentezza della linea c'è la scarsa affidabilità, anche in questo caso esistono soluzioni super collaudate e iperaffidabili, p.e. la RS485.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 07, 2015, 11:09 am
Oh il buon vecchio, che piacere.

Modbus ti permette di fare quello che fa PJON?
Contiene un packet manager?
E un reaction manager?

Come al solito e non e' la prima volta che te lo dico: Documentati prima di sparare a zero. Perche' scusami se te lo dico ma, vista la mia esperienza con Arduino se modbus o 1wire avesse fatto al caso mio l' avrei usato :).

E poi se qualcuno per passione costruisce qualcosa, anche se gia esistente e pluritestata io non lo mortifico dicendo "quello che hai fatto non vale nulla, e funziona anche peggio!!" ma anzi lo sprono con i miei complimenti, per esempio un amico sta costruendo un piccolo ultraleggero. Potrebbe comprare un acrobatico gia fatto e non rischiare la pelle su un oggetto costruito da lui, ma come si puo' non stimarlo per la sua passione e determinazione?




Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 07, 2015, 11:18 am
A casa mia con 30 metri di cavo nei muri di fianco a tutti i cavi della 220, passando dietro al frigo ecc non ha alcun problema e sono 18 Arduini a parlare in modalita' multimaster.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 07, 2015, 12:21 pm
Ciao Paolo, vbextreme vi ringrazio molto per i consigli.
Tendo a precisare che non ho un elevato background di c e cpp in particolare e credo questo traspaia dal codice che ho scritto, quindi se avete soluzioni piu' intelligenti di quelle che ho scelto, per favore fatemi sapere!!

Ho postato ieri per scherzo la libreria su hackernews. E' finita in prima pagina da ieri sera e continuo a ricevere star al repository e messaggi privati, non so che dire, sembra che alla community nerd stia piacendo  :o  :o  :o  devo per forza sistemarla!!!! hahah
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: astrobeed on Aug 07, 2015, 05:08 pm
Modbus ti permette di fare quello che fa PJON?
Ho citato modbus solo perché è il primo che mi è passato per la testa ed è il più diffuso, inoltre trovi una marea di device che lo supportano.

Quote
Come al solito e non e' la prima volta che te lo dico: Documentati prima di sparare a zero.
Potresti avere ragione se avessi criticato il tuo protocollo, cosa che non ho fatto, ho criticato il fatto che trovo inutile scoprire l'acqua calda ogni volta, ovvero di protocolli di comunicazione pronti ed affidabili ne trovi quanti ne vuoi.
Poi se ti sei divertito nel farlo allora questo non ha prezzo, per tutto il resto c'è ArduinoCard(tm).  :D
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 07, 2015, 05:27 pm
Ciao Astro. Scusami, ho probabilmente frainteso la tua opinione.
In ogni caso credo che anche tu abbia frainteso il contenuto di questa libreria, perche' non e' soltanto un protocollo di comunicazione, ma contiene anche un packet manager che si occupa della gestione dei pacchetti in background senza nessun effort dell utente e di un reaction manager che ti permette di correlare delle funzioni da eseguire quando viene ricevuto un determinato simbolo (o serie di simboli) definito dall'utente. Questo significa che in molti casi puo' agire da main scheduler di task.

In ogni caso sarei felice se dedicassi 10 minuti a leggere il readme e a dare un occhio al codice perche' ammiro la tua esperienza e le tue conoscenze e sono certo tu possa darmi ottimi spunti a cui io non ho pensato.

La libreria sta ottenendo un discreto successo all'estero.
Mi stanno tempestando di messaggi e pull request.

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 10, 2015, 05:11 pm
Ecco un video di uno dei test:
https://www.youtube.com/watch?v=JesqJ9_WJJs (https://www.youtube.com/watch?v=JesqJ9_WJJs)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: cyberhs on Aug 11, 2015, 12:40 am
Qualche domanda:

al pacchetto di dati viene aggiunto un carattere di checksum?
è possibile trasmettere un messaggio a tutti i dispositivi della rete, senza doverlo ripetere per ciascun nodo?
come fai a garantire la ricezione di un dispositivo occupato?
come gestisci le collisioni in caso di multi master?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 11, 2015, 09:01 am
Ho convertito la libreria per l'IDE 1.6.5 aggiungendo i file json e property. Stasera, tempo permettendo, faccio la pull request per l'integrazione.
Visto che però non sarà più compatibile con la versione 1.0.x e 00.x, forse è il caso di fare una nuova branch. Che dici?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 12, 2015, 02:07 pm
Ciao GioBlu,
se crei una nuova branch per la versione 1.5.x, faccio una pull-request con le modifiche.

(http://s13.postimg.org/5osvy135j/pjon.jpg)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 13, 2015, 07:59 am
Quote from: GioBlu
Hi Paolo! I would be able to maintain only one version of PJON for 0.x 1.x and 1.6x!
I would merge your contribution but I am not sure if I want to have digital write fast and PJON in the same arc directory! And also I can t get the sense of having the src directory! Generally is used in repos where u can / have to compile or maybe I am ignorant :)
La struttura della libreria tra 0.x, 1.x e 1.6.x è notevolmente cambiata.
La nuova struttura prevede che il codice della libreria si all'interno di una cartella "src", gli esempi nella cartella "examples", eventuali altri file come doc, pdf, schemi ecc nella cartella "extra" (che viene ignorata dall'IDE).
Nella directory principale andranno i file keyword, json e property. Questi file servono all'IDE per gestire la libreria sia nell'editor (colorazione delle funzioni e dei metodi) si per il library manager. (introdotto dalla versione IDE 1.6.4.
Le versioni 1.0.x ricercano i file anche nelle sottodirectory delle librerie per cui anche l'architettura nuova è utilizzabile.
Con le versioni 0.x invece c'è incompatibilità, ma sinceramente credo si possa smettere sviluppare librerie per una versione alpha dell'IDE continuando ad includere il Wcostant.h.

Quindi ecco perché ho messo tutto nella cartella src e creato i vari file di proprietà per l'IDE 1.6.x.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 13, 2015, 08:06 am
Una volta convertita la libreria nel formato 1.5.x si può chiede l'inclusione nel library manager.
--> https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ#how-can-i-add-my-library-to-library-manager (https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ#how-can-i-add-my-library-to-library-manager)

In particolare:
Quote
How can I add my library to Library Manager?

Ensure your library is complaint with 1.5 format
Tag it and push the tag, or create a release with github "releases"
Open an issue on Arduino's github, specifying the git repo (or github url) from where to download your library
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 13, 2015, 02:30 pm
Ciao Paolo!! Grazie mille del tuo supporto! Ho iniziato con una diecimila 7anni fa quindi forse sono un po' legato ai vecchi strumenti :)

Oggi creo una branch dove tu possa inviare la pull request!! Oki?

Ci vorrebbe più gente attiva come te nella community!! :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 13, 2015, 07:44 pm
La pull l'ho già inviata. Da gitHub puoi fare il merge sul branch invece che sul master.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 28, 2015, 04:05 pm
Ciao Paolo, non ho ancora accettato la tua pull request perche' devo ancora testare come viene compilato il codice con la 1.5. Ho notato che tutto il codice compilato con 0.x occupa decisamente piu spazio ma la cosa piu assurda e' che ci sia una netta differenza nel tempo di esecuzione del codice. Intendo dello stesso codice, compilato con una o l' altra versione. Infatti, lo stesso sketch di test di velocita' di PJON nella 0.x raggiunge quasi 4kB/s, nella 1.x 3kB/s questo credo, perche' e' cambiato il tempo di attuazione di tutte le funzioni base. Infatti come puoi vedere nella master attuale ho dovuto ricalibrare condizionalmente i delay di lettura tra la versione 0.x e la versione 1.x

A questo punto porterei la tua versione a master con alcune modifiche che intatto ho fatto sulla attuale master, e creerei una branch dedicata alle versione 0.x e 1.x pre 1.5

cosi' da retrocompatibilizzare qualsiasi sketch che usi PJON
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Aug 28, 2015, 04:26 pm
Per la velocità non so che dirti.
Riguardo lo spazio è possibile che la nuova toolchain Atmel integrata nelle ultime versioni dell'IDE sia meno esosa di risorse.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: simonenascivera on Aug 30, 2015, 06:52 pm

posso fare una domanda? sarei interessato nell'applicazione di questa libreria a network però di arduino collegati tramite bluetooth secondo voi è adattabile?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 07, 2015, 02:39 am
Ho adattato il layer fisico di PJON per funzionare con le coppie di rx e tx 433 mhz da 3 dollari e ho ottenuto 200 metri di range in ambiente cittadino (tra i palazzi). Quindi credo che si possa fare ma non conosco il mondo del bluetooth per darti una risposta affidabile, qui trovi il link della libreria con layer fisico radio:
https://github.com/gioblu/ASK_Slang (https://github.com/gioblu/ASK_Slang)

Fammi sapere come va!


Grazie Paolo per la pull request, l'ho accettata e ora ci lavoro un po' grazie ancora
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Sep 07, 2015, 09:06 am
Ho scambiato qualche battuta con Christian Maglie. Ho capito che sbagliavo a voler inserire la libreria nella sotto cartella SRC. Quella serve solo se si vuole creare una libreria esclusivamente per la nuova versione. Da 1.5.x in poi.
Se si vuole una libreria retrocompatibile, basta aggiungere semplicemente il file library.properties per il Library Manager e mettere gli esempi come file .ino.
Con la retrocompatibilità si perde la compilazione ricorsiva delle sottocartelle.
Inoltre devo ancora controllare la funzione della sottocartella UTILITY al posto della tua "include".
Non è necessario neanche il file .json che serve solo per i pacchetti del core.

Ho fatto una PR con le estensioni degli esempi aggiornate.

Ho fatto una prova e compila sia sulla 1.0.6 che sulla 1.6.5.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: simonenascivera on Sep 07, 2015, 11:44 am
@gbm per interfacciarlo con il modulino hai dato come pin di trasmissione  tx?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 09, 2015, 10:03 pm
Ciao @Paolo, grazie per il tuo supporto!! Senti ma hai mai testato PJON?? Mi farebbe piacere sapere cosa ne pensi vedendolo funzionare!! In ogni caso, ho letto attentamente la tua risposta. Ho risposto su github alla tua ultima pull request, ma ti scrivo anche qui:

Cosa ne dici di includere in examples gli esempi per entrambe le versioni?
Tipo dir 0.x_blink_example con .pde e 1.x_blink_example con i .ino?


@simonenascivera ciao! Cosa intendi? La libreria si istanzia con il pin utilizzato per la comunicazione in entrambi i casi (ricevitore e trasmettitore). Ho provato soltanto in configurazione monodirezionale, e ho ottenuto range intorno ai 200 metri in environment cittadino (attraverso palazzi) con una quarter wavelength dipole antenna autocostruita da entrambi i lati.

Ecco una foto dell'impianto:
(http://www.gioblu.com/GiO/space/2/images/building_in_profgress/DSC_1923.jpg)

fa parte di una micro radiosonda meteorologica che sto costruendo:
(http://www.gioblu.com/GiO/space/2/images/building_in_profgress/freezer-test.jpg)
(il grafico rappresenta l'esperimento con cui ho analizzato l'efficacia dell'isolamento termico della capsula, costruita in polistirolo e mylar militare)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: cyberhs on Sep 10, 2015, 08:15 am
In uno dei precedenti post che probabilmente ti è sfuggito, ti ho posto delle domande.

Te le riformulo:

- al pacchetto di dati viene aggiunto un carattere di checksum?
- è possibile trasmettere un messaggio a tutti i dispositivi della rete, senza doverlo ripetere per ciascun nodo?
- come fai a garantire la ricezione di un dispositivo occupato?
- come gestisci le collisioni in caso di multi master?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 11, 2015, 06:19 pm
Ciao mi devi scusare, hai ragione, mi e' sfuggita la tua risposta.

1) Al pacchetto viene aggiunto il CRC, (1 byte xor based)

2) Per trasmettere un messaggio a tutti i devices connessi puoi usare la costante BROADCAST al posto dell'id
che vuoi contattare

3) La ricezione non e' garantita, cio' che e' garantito e' che chi invia sia sicuro se o no il ricevente ha ricevuto correttamente grazie all'implementazione dell' ACK o acknowledge e del CRC precedentemente descritto.

4) Prima di trasmettere qualsiasi device ascolta il canale per un determinato periodo per capire se c'e' una trasmissione in corso oppure il canale e' occupato.

Ti consiglio di dare un occhio al readme della libreria che ho cercato di migliorare molto, e che e' stato di certo molto migliorato da chi ha contribuito al repository  :)
https://github.com/gioblu/PJON (https://github.com/gioblu/PJON)

Spero farai un test :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Sep 11, 2015, 06:34 pm
A questo punto porterei la tua versione a master con alcune modifiche che intatto ho fatto sulla attuale master, e creerei una branch dedicata alle versione 0.x e 1.x pre 1.5

cosi' da retrocompatibilizzare qualsiasi sketch che usi PJON
La 1.0.6 è deprecata ma ancora utilizzata, la 0.23 e precedenti sono semplicemente preistoriche. Io non perderei tempo con la retrocompatibilità per questa versione (0.23).
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 12, 2015, 02:58 pm
@PaoloP  ok considero il tuo consiglio, probabilmente hai ragione!!


In una branch locale sto provando un nuovo approccio possibile al reaction manager e volevo chiedervi quale implementazione preferite:

Attualmente il sistema funziona cosi': l'utente puo' inviare un comando (prendo per esempio lo short_command che manda a un determinato device un paccketto composto dalla costante CMD che determina che sia un comando e di un singolo byte (il tutto controllato con CRC) e aspetta l'acknowledge del ricevitore)

Code: [Select]
network.send_short_command(44, 'B');

Cosi' sto inviando alla board con ID 44 il carattere B.

Dall'altra parte e' possibile configurare una reazione a un determinato comando:

Code: [Select]


network.insert_reaction('B', blink_function);

void blink_function() {
  // Cicla i dati ricevuti
  for(int i = 0; i < max_package_length; i++)
    Serial.print(network.data[i]);
  Serial.println();

  digitalWrite(13, HIGH);
  delay(1000);
  digitalWrite(13, LOW);
}



In questo modo e' possibile per esempio nel mio sistema di home automation, definire che T e' un simbolo che rappresenta la temperatura e che ogni board nelle varie stanze invia T, il proprio id seguito dalla temperatura cosi' che il master possa aggiungere i dati in un database tramite POST su un server web.


Il nuovo approccio a cui ho pensato:

Definisco un puntatore a una funzione che venga chiamata quando qualsiasi messaggio e' ricevuto correttamente:
Code: [Select]
typedef void (*receiver)(int length, char *payload);

L'utente puo' gestire il routing e la reazione ai messaggi nel ricevitore in un unica funzione che riceve come parametri la lunghezza del paccketto e il contenuto, questi parametri verranno passati automaticamente dal sistema quando un messaggio verra' ricevuto, l'unica accortezza dell'utente e' quella di dover dichiarare la funzione come segue:

Code: [Select]

network.set_receiver(message_received);

receiver message_received(int length, char *payload) {
  // Ciclo i dati ricevuti
  for(int i = 0; i < lenght; i++)
    Serial.print(*payload[i]);

  Serial.println();

  if(payload[0] == 'B') {  // Stessa funzionalita' della reazione
    digitalwRITE(13, HIGH);
    delay(1000);
    digitalWrite(13, LOW);
  }
    
}



Quale soluzione pensate sia piu' sensata? Quale pensate che sia piu' comoda e semplice nell'uso per un utente anche meno esperto?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Sep 13, 2015, 04:46 pm
Ciao,
anche io alle prese con la domotica per casa mia, mentre stavo cercando informazioni sulle tecniche migliori per evitare le collisioni di pacchetti mi sono imbattuto in questa tua liberia.

Lato software ad una prima occhiata mi è sembrata fatta molto bene.

Personalmente ho preferito seguire la strada di implementare le funzioni aggiuntive (criptazione, controllo collisioni ecc) su protocolli noti, semplicemente per avere una egevole estendibilità della rete e avere almeno in parte la strada pronta per la coesistenza di oggetti di terze parti sullo stesso bus (conscio ovviamente che integrarli non sarà comunque una passeggiata).

Dal lato "Hardware" però ho serie perplessità. Mi pare di capire che in casa hai collegato direttamente gli Arduino, giusto? I microcontrollori si "parlano" passando in decine di metri di cavo e ti sei fidato solo delle protezioni onboard del microcontrollore?

E' questo che mi lascia molto perplesso. I miei prototipi hanno più componenti per la sezione di ingresso e filtraggio che in tutto il resto dalla board :)

Sarà anche che io ho a che fare con l'apertura della porta di casa e la gestione di antifurto e tapparelle, e sicuramente sarà che io non sono ottimista :) Ma arrivare a casa e non riuscire ad entrare perché il frigo si è attaccato nel momento sbagliato, o vedersi chiudere le tapparelle mentre si è sul balcone, mi spaventa non poco.
Ho perso davvero molto più tempo a studiare i possibili malfunzionamenti e a prevenire danni che a studiare il caso d'uso in cui tutto funziona.

Non dico di optoisolare tutto quanto ma secondo me dovresti almeno passare ad una RS485 come livello fisico (su cui potrai tranquillamente mantenere il tuo protocollo logico) e proteggere la linea con dei TVS, altrimenti al primo fulmine potresti avere sgradevoli sorprese.

Hai fatto un gran lavoro, ti manca davvero poco a trasfomarlo in qualcosa che abbia sapore di professionale e affidabile ;)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 13, 2015, 05:15 pm
Ciao! Grazie del tuo feedback!

L'impianto di casa mia si basa su una serie di cavi lan standard militare collegati in configurazione a stella, tutti i cavi sono collegati assieme e questo mi permette di avere in ogni stanza un connettore che esce dal muro o da dietro le pulsantiere con cui poter comunicare. Il cavo ha una lunghezza massima di una trentina di metri

Ho testato con al massimo 18 board arduino connesse e riescono a comunicare senza problemi.

Il tipo di isolamento nel cavo lan sommato al twisting dei cavi da un ottimo isolamento elettromagnetico, riesco a non avere interferenze passando dietro al generatore del frigo e vicino al forno a microonde.

L'alimentazione e' fornita da una coppia di cavi alimentati da due batterie da 12v 100a connesse a un pannello fotovoltaico da 200W ora. L'unica protezione reale che ho contro ai fulmini e' una serie di fusibili prima di entrare in casa con l'alimentazione e il cavo della comunicazione.


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Sep 13, 2015, 09:12 pm
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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 13, 2015, 11:56 pm
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?
 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Sep 14, 2015, 12:27 am
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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 14, 2015, 11:35 am
Hai ragione, la delucidazione riguardo le pull down c'e' solo nei commenti nel codice  :)
Grazie della segnalazione  :)

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 21, 2015, 12:18 pm
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  :o  :o
https://github.com/gioblu/PJON (https://github.com/gioblu/PJON)

Cosa ne pensate???
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Sep 22, 2015, 11:58 am
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 (https://github.com/blog/1547-release-your-software)

Mi serve un po' di tempo per testarla e comunque ho un probabile progetto dove utilizzarla.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: PaoloP on Sep 22, 2015, 01:40 pm
La libreria è stata aggiunta.
--> https://github.com/arduino/Arduino/issues/3837#issuecomment-142242947 (https://github.com/arduino/Arduino/issues/3837#issuecomment-142242947)

Come già detto manca la release.  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 01, 2015, 10:31 pm
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?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 02, 2015, 12:42 pm
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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 02, 2015, 01:36 pm
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?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 02, 2015, 02:10 pm
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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: icio on Oct 02, 2015, 03:45 pm
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
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 02, 2015, 06:06 pm
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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 03, 2015, 02:02 pm
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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 04, 2015, 12:03 am
Ohhh finalmente adesso PJON ha un porting stabile funzionante anche con i moduli radio ASK 433Mhz!!
https://github.com/gioblu/PJON_ASK (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.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 04, 2015, 08:11 pm
Praticamente stai reinventando Ethernet, TCP e IP :D

Scherzi a parte, quel che voglio dire è che stai facendo un lavoro molto promettente e sicuramente arricchirà molto il tuo bagaglio culturale.
Quindi, dal punto di vista "teorico" meriti sicuramente un encomio.

Dal lato strettamente pratico però devi tenere presente che sarà ben raro che una rete "casalinga" necessiti di centinaia di nodi.
Se proprio ad un progettista toccasse un simile problema, con ogni probabilità si affiderebbe a protocolli e bus fisici stra-noti e affidabili come quelli che ho citato, anche perché è un investimento lato hardware non indifferente e poter contare su parti "di serie" convincerebbe meglio il committente.

Stai rischiando di scoprire l'acqua calda o peggio di perdere tantissime ore a reinventare la ruota dandogli solo un altro nome.
Finché lo fai per cultura personale non ho niente da dire, ma non ti aspettare un grande successo del tuo protocollo quando la rete è così estesa. Successo che ovviamente ti auguro, sia chiaro, ma non ti nascondo il mio scetticismo riguardo il numero di possibili progetti che lo coinvolgeranno.

Anche se facessi tutto alla perfezione, il bus è relativamente lento: ottimo perché più è lento, meno errori di comunicazione hai. Ma quando pensi a centinaia di oggetti interconnessi, i tempi per inviare il messaggio si allungano (perché si presume che più oggetti interconnessi, più sia alta l'occupazione media del bus, mica saranno tutti moduli in attesa di istruzioni quelli che aggiungi). Non puoi premere un pulsante e accendere la lampadina 10 secondi dopo...

Oggigiorno tra reti cablate o radio già molto ben strutturate, in cui si sono già ben affrontati tutti i problemi di affidabilità della comunicazione, criptazione, auto routing in caso di nodi spenti, resilienza ai disturbi ecc ecc c'è più di una scelta "professionale" a costi relativamente contenuti.

Quel che manca è un modo di fare in modo economico, affidabile e "moderno" piccole reti di microcontrollori.

Ti suggerirei quindi di approfondire il mondo delle piccole reti. A PJON serve un layer software per l'auto indirizzamento delle periferiche, servono numeri reali (indicando esattametne le condizioni di test) sul reale transfer rate (hai indicato quasi tutti numeri teorici e hai un solo impianto di test a quanto pare), forse serve un sistema di correzione delle derive del clock, puoi potenziare la parte di checksum e auto retrasmit dei dati corrotti...  Insomma, il prototipo è perfetto ma di lavoro ce n'è ancora tanto.
Va benissimo riservarsi qualche byte nel protocollo per future espansioni come router ecc, ma lascia il tutto proprio solo a livello di spazio per future espansioni.

Per farla breve, date a Ethernet quel che è di Ethernet e date a PJON quei che è di MODBUS :D
 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 05, 2015, 01:27 am
Ok, ho capito. Non sei il primo che me lo dice.
In ogni caso fare in modo che supporti una rete di reti non e' cosi' complicato al massimo scrivero' un layer a parte dello stack in futuro  :). In ogni caso, cosa ne pensi dell'implementazione radio che ti ho linkato? Credo sia una discreta alternativa a VirtualWire!  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 05, 2015, 11:46 am
Ho un paio di quei modulini in un cassetto, nel prossimo weekend farò un test.

Mi pare molto promettente, ed è appunto quel che intendevo quando ti suggerivo di focalizzarti sulle piccole reti a basso costo.

Con una libreria del genere si riesce a far fare cose a quei modulini che fanno quasi solo gli xbee, ma ad una frazione del prezzo totale
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 05, 2015, 01:36 pm
Alcuni utenti mi richiedono l'auto addressing dei nodi, tu cosa ne pensi? soprattutto per la versione radio sarebbe molto utile.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 05, 2015, 02:56 pm
C'è più di un modo di farlo e devi valutare bene quale strada sia migliore.

Indirizzamento automatico significa sapere gestire i conflitti sugli indirizzi, specie se non dedichi un nodo ad essere un unico coordinatore degli indirizzi assegnati.

Secondo me potresti pensare a una qualche forma di auto indirizzamento minimale, con minimi impatti sulla libreria e lasciare il grosso del codice ad una applicazione di esempio. Così solo chi vuole la implementa nel suo codice.

Ad esempio attivare un comando "ping" che consumi pochi byte sul bus e a cui la libreria risponda sempre in automatico (senza che l'utilizzatore della libreria debba scrivere la parte software per la risposta).

Poi nella libreria fornisci una implementazione di esempio:

Al setup verifichi l'indirizzo presente in eeprom
- se è 0x00 o 0xFF allora vuole dire che la eeprom è intonsa (mai attribuìto un indirizzo). Parte allora un ciclo in cui si "pinga" il bus da 0x01 a 0xFE. Al primo ping che va in timeout, allora significa che quell'indirizzo è libero. Lo inserisce in eeprom.

- se non lo è, recupera l'indirizzo. Poi prova a pingarlo (la libreria deve evitare di auto-rispondersi, ma deve poter trasmettere fuori il proprio stesso indirizzo). Se nessuno risponde allora vuole dire che quell'indirizzo è ancora libero e continuerà ad usarlo. Se qualcuno risponde, allora significa che c'è un conflitto degli indirizzi (ad esempio un modulo è stato acceso mentre questo era spento). Con il ciclo di prima recuperi un nuovo indirizzo libero. Preferibilmente informi il bus (con un messaggio broadcast) che c'è stato un conflitto (indicando vecchio indirizzo e nuovo indirizzo), così i moduli che ad esempio si aspettavano un sensore di temperatura all'indirizzo 0x03 ora sanno che se lo troveranno al 0x05)

In realtà ci sono metodi anche molto più evoluti per gestire indirizzi e conflitti, ma questo mi pare abbastanza minimale da essere adatto al tipo di rete.

Una alternativa potrebbe essere che ogni modulo conserva una copia della lista degli indirizzi assegnati, quindi ciascuno sa sempre qual è il primo indirizzo libero: all'accensione fai il ping in loop, ammettiamo che il 0x01 non risponda, tu continui con il 0x02. Questo risponde al ping e ti dice che il primo libero è 0x05. Tu ti prendi 0x05 e con una chiamata broadcast dici che 0x05 è assegnato ( e tutti i moduli si segnano che non è più libero). Così hai evitato un conflitto su 0x01, 0x03, 0x04: moduli esistenti ma spenti o non raggiungibili in quel momento. All'accensione un modulo deve scaricarsi la lista aggiornata dal primo modulo che trova, in modo da avere una lista "fresca".
Questo metodo ha il vantaggio di essere molto efficace nell'evitare conflitti, ma consuma un po' di ram (almeno 32 byte solo per la lista).
Ovviamente bisogna anche prevedere il comando "disconnetti dalla rete" per informare il bus che l'indirizzo XYZ è nuovamente libero.

L'opzione di avere un coordinatore unico per tutto il bus è simile alla precedente ma c'è un solo microcontrollore che ha la copia della lista. Questo modulo risponderà sempre ad un indirizzo predefinito (es 0x01). In questo modo gli altri nodi sono più semplici, ma se il primo nodo non è raggiungibile, allora tutta la rete non accetta più aggiunte o rimozioni di moduli dalla rete.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 05, 2015, 04:08 pm
Ciao Nabia. Grazie dei consigli.

Io rimarrei su modalita' multimaster, (quindi senza un unico device in grado di fare l'addressing).
Quello a cui pensavo e' che quando un device si connette a una rete, estrae un numero casuale e pinga a quell'ID, finche' non ne trova uno libero. Se riceve un messaggio spedito con come mittente il proprio ID (anche dopo ore che si e' trovato il suo ID), dovrebbe abbandonare l'ID attuale e ricercarne uno nuovo.

Cosi' alla connessione di un device potresti avere una leggera perdita di banda, ma avresti dalla tua la cosa positiva di non doverti ricordare tutti gli id e non dover avvisare di esserti disconnesso.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 05, 2015, 04:31 pm
Eh sì ma il termometro che è "abituato" a sevegliarsi ogni 10 minuti e mandare la lettura della temperatura all'id 0x45  come fa a sapere che mentre dormiva è cambiato id ed ora deve mandare a 0x98?

Sopratutto se entri nel mondo della comunicazione radio è la norma (e non l'eccezione) che un dispositivo vada in sleep per contenere l'uso delle batterie quando non è strettamente necessario che sia acceso.

Guarda che la gestione dinamica dell'indirizzamento non è così semplice quanto sembri. Proprio per questo ti suggerivo di non mettere troppa roba nella libreria e affidarti ad un esempio, così si può personalizzare in base alle peculiarità della propria rete.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: chetto983 on Oct 05, 2015, 05:46 pm
Ciao a tutti,

Questa libreria è ottima  ma secondo me ha un problema di fondo:

void loop() {
  network.receive(1000);
}

non si ha mai la certezza che il dato sia ricevuto nel reciver.

Non si potrebbe usare un interrupt e mettere un  su buffer circolare i pacchetti ricevuti da leggere con comodo quando si ha tempo per farlo?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 05, 2015, 09:01 pm
La certezza ce l'hai. Come spiegato nel readme, devi usare il setter "set_receiver" passando come parametro la funzione che verra' chiamata ogni volta che un messaggio sara' correttamente ricevuto.
Il bello e il cuore di questa libreria e' proprio che non usa interrupt o timer hardware  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 05, 2015, 09:14 pm
Ciao nabia, ho analizzato la cosa, secondo me  la strada migliore e' avere una lista di id e il loro stato di utilizzo su ogni nodo, Ovviamente il nodo che si connette dovrebbe compilarla (partendo da un punto a caso della lista) finche' non ne trova uno libero. Se succede che il nodo sente un pacchetto inviato dal suo stesso ID dovrebbe rilanciare il processo di auto addressing...

cosa ne dici?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Oct 06, 2015, 09:26 am
Se devo avere una copia locale degli indirizzi occupati, tanto vale la si possa scaricare da altri nodi e non compilarla interamente da sé.
Così ti eviti i problemi di nodi temporaneamente non raggiungibili.
Poi ovviamente è da pensare quali strategie siano le migliori per tenerla aggiornata. Ad esempio messaggi broadcast per segnalare l'attivazione di un nuovo nodo + monitoraggio del bus: quando passano dati da un id (verso un qualunque altro dispositivo) verifico di averlo nella lista degli id attivi e se non lo è, lo aggiungo

A parte, si può pensare a come rimuovere dalle liste di ID. A parte uno specifico evento broadcast, potrebbe essere uno dei dispositivi che abbia qualche riga di codice in più. Quindi nessun intervento in libreria ma l'utente che a seconda della rete che installa, metterà nel nodo più "intelligente" qualche riga di codice.
Ad esempio se il tutto nelle intenzioni dello sviluppatore della rete è supervisionato da un pannellino con display per monitorare lo stato della domotica di casa, allora in quel pannellino ci sarà l'opzione avanzata di "ripulire" gli id che da settimane non si fanno sentire.

Bisogna ricordarsi che gli ID cambiano ogni morte di papa in una rete reale, e gli id disponibili sono molti di più dei dispositivi realmente connessi: va bene gli automatismi per gestire gli id, ma senza esagerare...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 16, 2015, 01:45 pm
Ciao ragazzi, non so se avete visto questo nuovo progetto di home automation di Michael Teuww che utilizza PJON come protocollo di comunicazione!!! :)

http://michaelteeuw.nl/post/130558526217/pjon-my-son (http://michaelteeuw.nl/post/130558526217/pjon-my-son)
http://michaelteeuw.nl/post/131017701882/prototyping-complete (http://michaelteeuw.nl/post/131017701882/prototyping-complete)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 27, 2015, 03:54 pm
Ciao ragazzi! In questi giorni ho reso compatibile anche l'Arduino Mega e ora sto lavorando a compatibilizzare l ATtiny!!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 29, 2015, 05:15 pm
Ciao! Buon Natale in ritardo.

Finalmente sono riuscito a rendere compatibile con PJON i seguenti processori:

- ATmega88/168/328/1280/2560
- ATtiny25/45/85

Sto lavorando a rendere compatibile anche l'architettura ESP8266 con Arduino IDE (boards molto interessanti).


Come potete vedere dal commit:
https://github.com/gioblu/PJON/commit/bdc0b570e2d017b56cd633dc48972805f9fc9e41 (https://github.com/gioblu/PJON/commit/bdc0b570e2d017b56cd633dc48972805f9fc9e41)
E' bastato cambiare leggermente i valori di timing dei device precedentemente non supportati.

In piu' ho portato avanti la mia versione di digitalWriteFast che ora supporta Arduino Mega e ATtiny45/85!! https://github.com/gioblu/PJON/blob/master/includes/digitalWriteFast.h (https://github.com/gioblu/PJON/blob/master/includes/digitalWriteFast.h)
(Avrei fatto una pull request a chi mantiene la libreria ma non esiste un repository ufficiale)

Questa ricerca mi ha portato a scoprire che, nessuna delle schede che usiamo genera con delay() e delayMicroseconds() dei delay precisi. Infatti per fare in modo di ottenere una timing accettabilmente simile su tutti i device ho dovuto per esempio sull'Arduino Mega settare la durata di un bit di 2 microsecondi piu' ridotta per matchare la timing del Duemilanove/Uno/Nano. Stessa cosa vale per ATtiny a 8Mhz (oscillatore interno) che produce dei delay decisamente piu lunghi delle altre due architetture, infatti ho dovuto settare la durata di un bit 4 microsecondi piu' corta per matchare quella di Mega e Uno.

La cosa impressionante ora e' vedere la semplicita' d'uso con reti con 3 diverse architetture!!  :)  :)
Accuratezza del segnale 99.9%

Questo e' il mio regalo di Natale per il forum  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 04, 2016, 09:23 am
Sto sperimentando le librerie Pjon per un progetto che ho in testa che richiede il collegamento di tre Arduino che dovrebbero scambiarsi dati ricevuti da altrettanti sensori.
Sono partito con l'esempio di base illustrato su Github che ho leggermente modificato:

TX
Code: [Select]
#include <PJON.h>
PJON network(7, 0); // network(Arduino pin used, selected device id)

void setup() {
network.send(1, "B", 1, 1000000);// invia carattere B a Id 1 ogni 1 secondo
network.send(2, "B", 1, 500000);// invia carattere B a Id 2 ogni 0,5 secondo
}

void loop() {
network.update();
}


RX1
Code: [Select]
#include <PJON.h>
PJON network(7, 1); // network(Arduino pin used, selected device id)

void setup() {
pinModeFast(13, OUTPUT);
digitalWrite(13, LOW);
Serial.begin(9600);
network.set_receiver(receiver_function);
}
void receiver_function(uint8_t length, uint8_t *payload) {
if(payload[0] == 'B') {
Serial.println("BLINK");
digitalWrite(13, HIGH);
delay(30);
digitalWrite(13, LOW);
}
}

void loop() {
network.receive(1000);
}


RX2
Code: [Select]
#include <PJON.h>
PJON network(7, 2);// network(Arduino pin used, selected device id)
long  tempo = 0;
long  oldTempo = 0;

void setup() {
pinModeFast(13, OUTPUT);
digitalWrite(13, LOW);
Serial.begin(9600);
network.set_receiver(receiver_function);
}

void loop() {
network.receive(1000);
}
void receiver_function(uint8_t length, uint8_t *payload) {
if(payload[0] == 'B') {
Serial.print("BLINK   ");
tempo= millis();
Serial.println(tempo - oldTempo);
oldTempo= tempo;
digitalWrite(13, HIGH);
delay(30);
digitalWrite(13, LOW);
}
}


Il TX invia ogni 1 secondo un comando di blink ad il RX ed ogni 0,5 secondi uno al RX1.
Ho notato le seguenti stranezze:

alimentando sia da USB che da fonte esterna prima di eseguire correttamente le funzioni per cui sono stati programmati,  il pin 13 di RX1 fa tre lampeggi in rapida successione e poi parte con il ciclo,
RX2 invece fa 5 serie di tre lampeggi per poi partire correttamente.  Come mai?

Vedo che nello sketch originario nel setup dei RX trovo dei PinModeFast, DigitalWriteFast: non li avevo mai trovati prima quindi a cosa servono?  Possono essere sostituiti nello specifico con i normali PinMode e DigitalWrite? Negli sketch allegati li ho sostituiti con le versioni "normali" e sembra funzionare tutto correttamente...

a circuiti collegati e funzionanti da ore, accendendo una lampada a braccio (con trasformatore) posizionata nelle vicinanze noto che alle volte i ricevitori si fermano per qualche secondo per poi ripartire con i lampeggi: ovviamente si tratta dell'interferenza provocata dalla lampada che si propaga in qualche modo. Preciso che il TX è alimantato tramite USB , Il TX1 tramite USB con la sua uscita a 5V che alimanta TX2.

Per ora questo poi avrò altre domande da fare sul codice ma voglio affrontare un problema per volta.
Grazie


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 04, 2016, 10:09 am
Franchelli fai una prova con tre alimentazioni diverse per i tre arduini.

Sto utilizzando ache'io questa libreria per comunicare diverse stringhe di valori tra vari arduini.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 04, 2016, 11:25 am
Franchelli fai una prova con tre alimentazioni diverse per i tre arduini.

Sto utilizzando anche'io questa libreria per comunicare diverse stringhe di valori tra vari arduini.

Ottimo, la prova da fare immagino è per limitare le interferenze, vero?
Posso farle tutte e tre separate sempre da USB?

Per il resto cosa mi puoi dire?

Gia che ci siamo:

hai detto che invii stringhe di valori: io per ora ho provato solo ad inviare il singolo carattere  ma sto tentando di capire la tecnica per mandare dei valori numerici come potrebbe essere quello in uscita da un sensore di tempreatura. Hai qualche spezzone di schema da inserire, magari commentato, per cercare di far chiarezza?
Grazie mille
Franco

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 04, 2016, 11:46 am
ciao,
sto usando anche io la libreria PJON per inviare e ricevere dati da vari sensori. Attualmente ho 5 mini pro collegati a varie distanze (max 15mt) e finora non ho avuto nessun problema.
Per inviare i dati dei sensori puoi guardare l'esempio di Gioblu "SendArbitraryValues" dove con pochi byte invia il valore di un sensore. Se invece vuoi inviare una stringa, io ho fatto così:

Code: [Select]

String Stringa_da_inviare = "Ciao Pippo";
int lunghezza=Stringa_da_inviare.length()+2;
char bufferTemp[lunghezza];
Stringa_da_inviare.toCharArray(bufferTemp, lunghezza); 
network.send(PinTrasmissione, bufferTemp, lunghezza);   


Se hai dubbi ti posto l'intero sketch..

ciao :)

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 04, 2016, 12:14 pm
Grazie mille per la risposta :
l'esempio lo sto analizzando e piano piano sto capendo il meccanismo anche se per ora sono riuascito ad inviare solo numeri interi... e non riesco a trovare il modo per inviare uin numero con decimali.

Il codice che mi hai postato è molto interessante solo credo che l'ultima riga sia errata e quella corretta sia questa (se ho capito come funziona  :smiley-mr-green: )
Code: [Select]

network.send(PinTrasmissione, Stringa_da_inviare, lunghezza);


Perchè quel +2 alla fine della seconda riga?
Grazie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 04, 2016, 12:43 pm
Grazie mille per la risposta :
l'esempio lo sto analizzando e piano piano sto capendo il meccanismo anche se per ora sono riuascito ad inviare solo numeri interi... e non riesco a trovare il modo per inviare uin numero con decimali.
Ti basta considerarli stringhe, ad esempio questo è quello che mi invia il mini in lavanderia: "LAV T21.6 U45.5 W276". LAV è il nome del sensore, T la temperatura, U l'umidità e W sono i watt attuali. Con le stringe si usano tanti byte, ma così è più semplice. :)

Il codice che mi hai postato è molto interessante solo credo che l'ultima riga sia errata e quella corretta sia questa (se ho capito come funziona  :smiley-mr-green: )
Code: [Select]

network.send(PinTrasmissione, Stringa_da_inviare, lunghezza);

No il codice è giusto, in pratica non puoi trasmettere una stringa intera  "ciao pippo" ma devi inserirla in un array. In questo caso "ciao pippo" tramite "toCharArray" diventa bufferTemp[0]=c, bufferTemp[1]=i, bufferTemp[2]="a", bufferTemp[3]="o" e via così.. dai un'occhiata al reference (https://www.arduino.cc/en/Reference/StringToCharArray)

Perchè quel +2 alla fine della seconda riga?
Il "+2"  è per aggiungere 2 byte alla stringa stringa inviata, penso li usi PJON, senza ti taglia la stringa...

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 04, 2016, 01:00 pm
Franchelli, poi per ricostruire la stringa fai così:

Code: [Select]

void receiver_function(uint8_t length, uint8_t *payload) {

String dati;

for (int i = 0; i < length; i++) {
    char tmp = payload[i];
    dati += String (tmp);
    }
   
Serial.print ("Dati PJON ricevuti --> ");
    Serial.println (dati);


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 04, 2016, 01:27 pm
Quote
Ti basta considerarli stringhe, ad esempio questo è quello che mi invia il mini in lavanderia: "LAV T21.6 U45.5 W276". LAV è il nome del sensore, T la temperatura, U l'umidità e W sono i watt attuali. Con le stringe si usano tanti byte, ma così è più semplice. :)
Ok, in pratica devo crearmi una stringa (la tua è un "enciclopedia...") che contiene tutto quello che voglio mandare e poi con il metodo che mi hai indicato, questo

Code: [Select]
String Stringa_da_inviare = "Ciao Pippo";
int lunghezza=Stringa_da_inviare.length()+2;
char bufferTemp[lunghezza];
Stringa_da_inviare.toCharArray(bufferTemp, lunghezza); 
network.send(PinTrasmissione, bufferTemp, lunghezza);

 invio tutto il pacco al ricevente.

Un po' macchinoso da capire ma senz'altro funzionale. Ci lavorerò su.
Potrebbe essere fattibile anche l'uso di una union?

Dato che il tuo sistema sembra nettamente più complesso del mio, hai mai notato problemi di "intasamento" del bus per concomitanza di pacchetti inviati da altrettanti dispositivi contemporaneamente?

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 04, 2016, 02:16 pm
i miei vari mini pro inviano i dati ogni 5 sec., durante il test con qualche mt. di cavo ne ho connessi 12 e ho rilevato solo un problema che ho segnalato a Gioblu che  ha prontamente risolto. Ecco a proposito, assicurati di usare l'ultima libreria master dal repository https://github.com/gioblu/PJON (https://github.com/gioblu/PJON), ne approffitto anche per ringraziare pubblicamente Gioblu per il lavoro svolto, mi ha fatto risparmiare un po' di 485 :)

ti allego un paio di sketch che ho usato per test, c'è un mini che riceve e visualizza le temperature su lcd e 3 mini che inviano la temperatura.


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 05, 2016, 08:47 am
Vi posto le linee di codice che utlizzo per inviare i dati con la lib PJON

Code: [Select]

  hu = dht.readHumidity();
  t = dht.readTemperature();
  sensors.requestTemperatures();
  double tempC = sensors.getTempCByIndex(0);
  if(millis() - time > 1000) {
    time = millis();
    dtostrf( tempC, 2, 2, contenuto);
    dtostrf( hu, 2, 2, conten);
    char cont[10] = {0};
    sprintf(cont,"%s %s",contenuto,conten);
    network.send(BROADCAST, cont, 10);


ho utilizzato un approccio diverso rispetto a mauroz per creare le stringhe, non so valutare se sia migliore il suo ol il mio ma sono entrambi validi.

Un grosso grazie a Gioblu per la libreria da lui creata !!!!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 05, 2016, 09:04 am
Io ho realizzato un "Termostato Avanzato" per la gestione dei fancoil di casa, in pratica leggono temperatura ed umidita ambientali, la temperatura dell'acqua che circola nel radiatore del faincoli e gestiscono l'accensione del motore che aziona la ventola, ho implementato un menu di gestione e la visualizzazione grafica sul lcd dei vari parametri impostati e rilevati.
Ora con l'aiuto della PJON tutti i termostati (per ora 3 ma in totale 9) comunicano tra di loro i vari valori rilevati in futuro vorrei impementare la possibile di settaggio "remoto" da qualsiasi termostato a qualsiasi termostato.

(http://s27.postimg.org/w7pd55pfn/IMG_20160205_084848.jpg) 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 05, 2016, 10:45 am
Un grazie a mauroz, a St_e  e ovviamente a Gioblu per il grossissimo aiuto che mi state dando in questa fase ed avrei da chiedere alcune cose :

@Mauroz

nel primo sketch di esempio che hai postato avevi scritto questa riga

Code: [Select]
int lunghezza=Stringa_da_inviare.length()+2;
e avevi detto che era necessaria per visualizzare la stringa nella sua completezza. In effetti senza i due bit aggiuntivi viene troncata
Nei successivi sketch però non hai messo il +2 
mi sfugge qualcosa?
Anche mettendo i due bit aggiuntivi la lettura appare strana con un . alla fine del valore
Forse i due sketch che hai postato sono in via di sviluppo e quindi non pienamente funzionanti?

@St_e

la funzione dtostrf non la conoscevo e mi sembra parecchio flessibile nel suo uso che ti permette di configurare in maniera semplice la stringa in uscita.
Ora sto provando anche la tua strada ma da super-profano penso che il tuo sistema sia, senza togliere nulla a Mauroz, leggermente più semplice. Bravi comunque tutti e due, non ci sarei mai arrivato da solo.



Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 05, 2016, 11:14 am
Non sapete che piacere enorme e' per me vedere che troviate utile quello che ho realizzato in questi 5 anni di sperimentazione nel mondo dei protocolli di comunicazione  :). Ci sono alcune novita' in arrivo, soprattutto in termini di compatibilita'. Infatti sto lavorando molto con ESP8266 e un altro utente di PJON sta lavorando con l'Arduino Zero.
Vorrei rilasciare la versione 2.0 di PJON a breve rendendo compatibili anche queste due architetture sommate a (se possibile) all'Arduino due.

Ho recentemente fixato un bug scoperto da un utente di nome Stephan (veramente un grande) che era nella codebase da anni. Di conseguenza consiglio a tutti di pullare PJON e aggiornare i firmware dei vostri device. Questo dovrebbe ridurre drasticamente i problemi di interferenze che avete lamentato e rimuovere alcuni comportamenti non voluti e assolutamente erronei che avvenivano solo in alcuni casi particolari solo se il destinaratio non era connesso.

Sarei molto felice di mostrare le vostre realizzazioni nella wiki del repository e nel sito della libreria, che sto proprio ora realizzando. Chiunque fosse interessato puo' postare in questo thread le info che vorrebbe rilasciare :)

Grazie a tutti per i complimenti e buona sperimentazione.
Fatemi sapere i vostri consigli / critiche.

 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 05, 2016, 11:18 am
Quei 2 sketch erano dei semplici test che stavo effettuando, semplificando il tutto puoi dimensionare l'array conoscendo la lunghezza della stringa da inviare, in questo caso "Ciao Pippo" sono 10 caratteri (compreso lo spazio) quindi:

Code: [Select]
String Stringa_da_inviare = "Ciao Pippo"; //stringa da inviare               
char bufferTemp[10]; //imposti l'array
Stringa_da_inviare.toCharArray(bufferTemp, 10); //converto la stringa
network.send(PinTrasmissione, bufferTemp, 10);  //invio la stringa con Pjon


come vedi tolta la stringa ed il network.send con 2 righe fai tutto :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 05, 2016, 12:36 pm
@Mauroz

Assolutamente il tuo sketch è funzionale peò mi sta dando qualche grattacapo:
con questa versione tratta dalla tua e modificata per le mie esigenze
Code: [Select]

if(millis() - time > 1000) {
 time = millis();
 sensors.requestTemperatures();  // Send the command to get temperatures
 stringVal=String(nomeSensore+float(sensors.getTempCByIndex(0)));// crea la stringa nomesensore + lettura
 int lun=stringVal.length(); // calcola lunghezza stringa
 char charVal[lun];   // crea array con lunghezza  della stringa
 stringVal.toCharArray(charVal,lun);//riempie  l'array con la stringa
 network.send(1, charVal, lun);   // invia al Id1 la stringa di lunghezza lun
}


La lettura ricevuta sul ricevente è la seguente:

Tm1 23.8.

Per avere una lettura corretta devo modificare la seguente riga così:

Code: [Select]

stringVal.toCharArray(charVal,lun+1);//riempie  l'array con la stringa

La letture quindi è questa:
Tm1 23.63
con due decimali.

Hai qualche idea ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 05, 2016, 03:07 pm
Se invii sempre "Tm1 xx.xx" ti conviene fare un buffer fisso a 10, fai riposare un po' il povero arduino :)

Code: [Select]

if(millis() - time > 1000) {
 time = millis();
 sensors.requestTemperatures();  // Send the command to get temperatures
 stringVal=String(nomeSensore+float(sensors.getTempCByIndex(0)));// crea la stringa nomesensore + lettura

#define Tot_Car 10           //totale caratteri della stringa da inviare

char charVal[Tot_Car];   // crea array con lunghezza  della stringa
stringVal.toCharArray(charVal,Tot_Car);//riempie  l'array con la stringa
network.send(1, charVal, Tot_Car);   // invia al Id1 la stringa di lunghezza lun
}
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 05, 2016, 03:34 pm
Si, ovvio ma dato che il valore nelle x è un valore di temperatura potrebbe perdere le decine e quindi crreare una lettura scorretta.
Cmq alla fine, diversamente da quanto detto prima e facendo delle prove, ho visto che la tua strada è la più user friendly per chi è alle prime armi come me.

Spiegami alcune cose che non mi sono chiarissime:

network.receive(1000);
come mai è settato ad 1 secondo mentre

network.update();
è libero di girare alla velocità del loop?

Il primo abilita la ricezione sul bus e quindi se un dispositivo deve solo trasmettere può essere omesso così come può essere omesso il secondo se deve solo ricevere, ho interpretato bene?


Questa riga che hai inserito

network.send(1, "*", 1, 10000000); //CONTROLLO OGNI 10sec. se l'id1 risponde

è a titolo di debug in quanto se c'è una mancata connessione comunque viene visualizzata sulla seriale/led del TX e potrebbe essere omessa? In pratica fa un ping per capire se c'è continuità di comunicazione in caso di silenzio di comunicazioni sul bus per periodi prolungati?


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 05, 2016, 04:01 pm
Si, ovvio ma dato che il valore nelle x è un valore di temperatura potrebbe perdere le decine e quindi crreare una lettura scorretta.
Cmq alla fine, diversamente da quanto detto prima e facendo delle prove, ho visto che la tua strada è la più user friendly per chi è alle prime armi come me.
In ogni caso con un buffer di 10 invia il dato che leggi, che sia 20.01, 20.00 o 1

Spiegami alcune cose che non mi sono chiarissime:
network.receive(1000);
come mai è settato ad 1 secondo mentre
Il master interroga ogni x sec. se gli slave rispondono, se questi perdono la connessione si accende il led (13), si può togliere tranquillamente il receive, tanto se non sono accesi alla fine lo capiscie perché non ti arriva nulla :)

network.update();
è libero di girare alla velocità del loop?
Si, nel readme di Gioblu c'è scritto:
"the update() function has to be called at least once per loop cycle. "

...
network.send(1, "*", 1, 10000000); //CONTROLLO OGNI 10sec. se l'id1 risponde

è a titolo di debug in quanto se c'è una mancata connessione comunque viene visualizzata sulla seriale/led del TX e potrebbe essere omessa? In pratica fa un ping per capire se c'è continuità di comunicazione in caso di silenzio di comunicazioni sul bus per periodi prolungati?
esatto si può togliere, se non ricevi nulla alla fine lo vedi :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: _nabla_ on Feb 05, 2016, 04:15 pm
Quando si parla di stringhe allocate sempre un byte in più. In C le stringhe sono terminate da un carattere ( "\0" )
Se non si tiene in considerazione questo, prima o poi ci si trova con qualche funzionamento anomalo e ci si perde la testa a capire il perché di certi comportamenti
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 05, 2016, 06:52 pm
@Mauroz

Quote
In ogni caso con un buffer di 10 invia il dato che leggi, che sia 20.01, 20.00 o 1
Ok ma se il dato da trasmettere è più breve delle dimensioni del buffer, oltre al dato verranno visualizzati altri simboli a caso (già testato) da cui l'importanza ad avere il buffer identico come dimensioni al dato da inviare.

Quote
Si, nel readme di Gioblu c'è scritto:
"the update() function has to be called at least once per loop cycle. "
Si, l'avevo letto pure io ma mi piaceva capirne il perché...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Feb 05, 2016, 07:16 pm
Quando si parla di stringhe allocate sempre un byte in più. In C le stringhe sono terminate da un carattere ( "\0" )

grazie :)

[/quote]
@Mauroz
Ok ma se il dato da trasmettere è più breve delle dimensioni del buffer, oltre al dato verranno visualizzati altri simboli a caso (già testato) da cui l'importanza ad avere il buffer identico come dimensioni al dato da inviare.
ecco io ancora non l'avevo notato, perché l'array lo creo sempre della giusta dimensione, per l'update() ti può rispondere solo GioBlu..
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 06, 2016, 06:47 pm
Ciao ragazzi! Nel readme consiglio di chiamare update() ogni ciclo perche' la libreria non e' interrupt-driven e quindi non assicura che i pacchetti schedulati vengano inviati nel momento richiesto nel futuro. Questa responsabilita' e' in un certo senso destinata all'utente, finche' update() non verra' chiamata, nessun pacchetto verra' instradato e quindi anche i pacchetti in attesa di essere inviati, potrebbero essere inviati in ritardo. Ovviamente in alcune applicazioni chiamare update() non e' necessario, per esempio se un device e' solo dedicato alla ricezione.

Se potete postate le vostre realizzazioni sono curioso di vederle  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 06, 2016, 08:27 pm
Quote
Ovviamente in alcune applicazioni chiamare update() non e' necessario, per esempio se un device e' solo dedicato alla ricezione.
Ma se ometto di inserire un
network.update();

in un dispositivo che deve solo ricevere, i pacchetti verranno comunque ricevuti?


Quote
Se potete postate le vostre realizzazioni sono curioso di vederle
Ci sto lavorando, ad appena avrò fatto qualcosa di condivisibile lo farò, scketch compresi (così mi potri dare un voto...  :)  )
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 06, 2016, 09:32 pm
Assolutamente. La ricezione e' eseguita dalla funzione receive().

Non vedo l'ora. Buona sperimentazione!  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 08, 2016, 12:25 pm
@ Gioblu

Cerca di avere pazienza...  ci sono alcuni passi che non mi sono chiari:


Code: [Select]
int response = network.receive(1000);
Cosa mi indica il valore che viene salvato nella variabile e come va interpretato?
Ho provato ad inserirlo nel mio loop di trasmissione e mi rende sempre come valore 256
Il valore 1000 può essere modificato ed in generale perchè bisogna inserire un tempo a differenza di network.update che non lo richiede?


Nell'esempio "NetworkAnalysis" in Trasmitter trovo questo spezzone di codice:

Code: [Select]
int response = network.send_string(44, content, 20);
if(response == ACK)
test++;
if(response == NAK)
mistakes++;
if(response == BUSY)
busy++;
if(response == FAIL)
fail++;


Come mai   .send_string   invece di .send  ?
int response viene aggiornato con i valori "ACK, NAK, BUSY, FAIL"  ma come funziona tutto ciò? Potresti spiegare meglio questo spezzone di codice?

Ultima domanda relativa ad un problema hw:

per collegare i vari Arduino in rete posso/devo utilizzare un cavo schermato? Pensavo di far transitare nello stesso cavo oltre al segnale anche l'alimentazione per gli Arduino quindi utilizzando un totale di 3 fili (segnale, +5V , GND)  E' una cosa fattibile considerando che in pratica il tratto più lungo sarà attorno ai 10, 14 mt?





Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 08, 2016, 06:29 pm
Un paio di domande a gbm

1)In una rete in cui i vari master trasmettono in modalità broadcast ed i vari (temporanei)slave che ricevono la trasmissione (stringhe) possono conoscere id del trasmettitore della stringa ricevuta ??
Ossia la librerie prevede gia di restituire id del master che ha trsmesso in broadcast ??

2)Posso leggere in esecuzione id assegnato ?? esiste una funzione della libreria che interrogata restituisca id ?

2a)Eventualmente posso riassegnare id in esecuzione ??

Per la prima domanda è solo uno scrupolo id lo si puo inviare nella stringa-dati di comunicazione.

GRAZIE
 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 09, 2016, 02:01 pm
Ciao Franchelli allora:
- il parametro della funzione receive() rappresenta quanto tempo in millisecondi vuoi dedicare alla ricezione.
Se verra' ricevuto un pacchetto l'esecuzione della funzione verra' terminata. In caso contrario il sistema rimarra' in ascolto per un tempo massimo equivalente al valore del parametro. Puo' essere utile dover schedulare questa durata, se nel tuo use case non e' necessario puoi chiamare direttamente receive() senza parametri per effettuare un solo attempt di ricezione.

La funzione receive() puo' ritornare ACK, NAK, BUSY, FAIL
ACK: ricezione corretta
NAK: ricezione incompleta o scorretta
BUSY: canale occupato (pacchetti in transito per altri device)
FAIL: ricezione assente

Per un tipo di applicazione come quella che hai descritto io utilizzerei se il tuo budget te lo permette un cavo LAN categoria 5 schermato, di cui utilizzerei i cavi di alimentazione standard per la power supply (se ti bastano in termini di sezione e quindi di amperaggio massimo supportato) e uno dei restanti per la comunicazione tramite PJON.

Ciao Ste:
Tempo fa avevo implementato all'interno del formato pacchetto standard anche l'id del mittente, ma alcuni utenti si sono lamentati perche' non e' per forza necessario doverlo sapere e occupa una parte cospicua della banda a disposizione. Per questo ho deciso di permettere l'utente di decidere se o no includerlo nel contenuto del pacchetto, se necessario. Puoi cambiare l'id del device in esecuzione usando il setter: void set_id(uint8_t id);. Effettivamente allo stato attuale non e' possibile leggere l'id perche' e' una variabile privata e non esiste un getter. Hai scoperto una mancanza non da poco  :) . Entro sera vedo di sistemare in modo che tu possa leggere in esecuzione l'id del device.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Nababbi on Feb 09, 2016, 02:04 pm
Buongiorno gbm

sono un neofita di arduino e vorrei poter far comunicare più schede tra di loro.
Il mio obbiettivo è riuscire ad implementare un piccolo sistema domotico a casa, non sono nuovo di domotica, devo far reagire sensori e rele di una scheda a input avuti da interruttori di un'altra scheda

Ho mappato casa con tre punti ethernet dove disporre tre schede ma il mio problema è farle dialogare e mi stò forse perdendo in un bicchier d'acqua

Puoi aiutarmi?

Grazie mille
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 09, 2016, 02:14 pm
Ciao Nababbbi! Anche io ho realizzato il mio impianto di home automation. Ho usato PJON come protocollo di comunicazione tra piu schede Arduino compatibili. All'interno dei muri ho tirato un impianto in configurazione a stella, composto da piu sezioni di un cavo di rete lan categoria 5. Uso uno dei cavi al suo interno per la comunicazione e una coppia per l'alimentazione delle schede.

Un sistema di home automation, soprattutto nel caso in cui tu sia un neofita nel mondo dell'elettronica e' un progetto piuttosto complesso da portare a termine in maniera soddisfacente, senza rischiare di dare fuoco a qualcosa. Se invece hai un background profondo di elettronica e elettrotecnica, ti bastera' studiare le applicazioni software e gli esempi che piu' sono compatibili con il tuo use case.

Sicuramente PJON e PJON_ASK sono due ottime soluzioni per quanto riguarda la interconnessione di piu schede Arduino compatibili, senza troppe complicazioni hardware e software.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Feb 09, 2016, 09:10 pm
@GBM

Quote
- il parametro della funzione receive() rappresenta quanto tempo in millisecondi vuoi dedicare alla ricezione.
pertanto se ho capito bene, maggiore  sarà la frequenza di invio pacchetti da/dai TX e minore (o assente) può essere il tempo di ricezione

Quote
La funzione receive() puo' ritornare ACK, NAK, BUSY, FAIL
ACK: ricezione corretta
NAK: ricezione incompleta o scorretta
BUSY: canale occupato (pacchetti in transito per altri device)
FAIL: ricezione assente
In linea di massima avevo capito il significato delle risposte mentre non avevo capito in che formato vengono resi questi messaggi. Presumo che siano dei valori numerici interi (li salva in un int) ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 10, 2016, 10:48 am
Ciao Franchelli! Allora cerco di essere piu' chiaro. Il parametro che passi a receive() rappresenta il tempo massimo che vuoi dedicare alla ricezione prima che la funzione ritorni e che il resto del codice possa essere eseguito.

Tutti i simboli sono singoli byte. Trovi l'indice dei simboli in PJON.h


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 11, 2016, 08:02 am
Ciao GBM

hai avuto modo di sistemare il problema della lettura in esecuzione del id ???
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 12, 2016, 05:55 pm
Ciao St_e ho pushato su master un commit che contiene l'aggiunta da te proposta che e' un semplice getter ( get_id() ) che ritorna la variabile privata (uint8_t) _device_id !! Non ho reso pubblica questa variabile per evitare collisioni e mantenere la classe il piu' possibile self contained e anche per evitare di modificare la velocita' di esecuzione del codice  :) spero possa esserti utile!

https://github.com/gioblu/PJON/commit/de10e6017bce75b005aa85f535fabd0feebb049b (https://github.com/gioblu/PJON/commit/de10e6017bce75b005aa85f535fabd0feebb049b)

(il resto delle modifiche e' relativo a una bug molto strana che porta al riavvio del microcontrollore se l'utente non inserisce con set_receiver una funzione da eseguire quando ricevuto un messaggio)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 13, 2016, 08:52 am
GRAZIE GBM !!!!

Ti riporto anche la mia esperienza di test della libreria con installazione in un ambiente molto ostile il termini di Radio Fraquenza dovuta a trasmettitori a 433 Mhz e molti alimentatori switching, ebbene avevo testato il collegamento di due master/client con 1 solo cavo dati volutamente non schermato

Risultato:
se la trasmissione si limitava a stringhe di 5 caratteri o ad invio di byte nessun problema, passando poi all invio di stringhe piu' complesse (25 caratteri) non c'era modo di riuscire a portare a termine 1 trasmissione.

Il problema è stato risolto semplicemente inserendo un secondo cavo per collegare le masse dei due master/client.
I cavi NON sono schermati, ma cosi strutturata la rete non presenta NESSUN problema di trasmissione/ricevione anche di stringhe complesse.

Complimenti ancora per la libreria

E.... Grazie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 13, 2016, 03:35 pm
Ciao St_e! Spiegami bene come e' strutturato il tuo test case.
L'alimentazione e' comune? Teoricamente senza una massa comune due devices non possono comunicare, anche se, se ho capitobene il tuo report, non sei il primo a cui funziona anche senza con pacchetti non troppo complessi, ma non dovrebbe proprio  :). La massa e' mandatoria!

Grazie dei complimenti!!  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Feb 13, 2016, 05:51 pm
GBM hai capito benissimo
i due master/client hanno alimentazione SEPARATA senza collegamento di massa la trasmissione aveva esito positivo con strighe di 5 caratteri e trasmissioni di byte.

Senza collegamento di massa con strighe complesse solo errori ma COLLEGANDO la massa nessun errore con stringhe complesse.
I master/client erano praticamente immersi in rf.

La libreria per trasmissioni semplice funziona egregiamente anche con masse separate elettricamente ossia con alimetazione diversa tra i vari master/client.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 13, 2016, 07:19 pm
Sei sicuro che la massa non finisca a essere comune tramite il tuo impianto 220v? Esempio un device alimentato da usb di un computer, altro device alimentato da un altro computer, che cmq hanno in comune la massa dell'impianto 220? Se e' cosi' e' normale che funzioni male perche' la massa e' "lontana", o piu tecnicamente c'e' una differenza di potenziale tra le due masse. Vedi ground loop: https://en.wikipedia.org/wiki/Ground_loop_(electricity) (https://en.wikipedia.org/wiki/Ground_loop_(electricity))
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 02, 2016, 12:41 pm
Ciao a tutti! Ho rilasciato qualche giorno fa la versione 1.1 stabile ti PJON.
Qui trovate il changelog e i bugfix: https://github.com/gioblu/PJON/releases (https://github.com/gioblu/PJON/releases)
Finalmente abbiamo compatibilita' completa con Arduino Mega e ATtiny85!!!  :)

Nella 1.2 arrivera' l'ESP8266 e alcune migliorie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Mar 02, 2016, 03:06 pm
ottimo, grazie, la sta testando da qualche giorno su 5 mini ed un mega, e non ho riscontrato problemi :) bel lavoro
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Mar 16, 2016, 10:12 am
Ciao gbm,

ho una difficoltà nel mio setup ho collegato piu arduino in modalità multimaster ed utilizzo la trasmissione BROADCAST della pjon, la difficoltà è questa se mi limito ad un master ed uno slave tutto bene i dati vengono tyrasmessi e ricevuti senza problemi, se inserisco in rete un altro master (2 master e uno slave quindi) la trasmissione si blocca o meglio lo slave riceve ogni tanto qualche dato............... no riesco a capire.
Cablaggi controllati nessun falso contatto.
L'unica cosa su cui ho un dubbio è il fatto di utilizzare un pin analogico per la comunicazione tramite pjon.

Protrebbe essere quello il problema ???

Help !!!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 17, 2016, 09:21 am
Ciao @St_e
spiegami meglio com'e' il tuo setup e ogni quanto trasmetti che tipo di stringhe
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Alessandro95 on Mar 30, 2016, 11:47 am
Salve ragazzi, ho bisogno di un vostro consiglio.

Sto realizzando una macchina elettrica telecomandata da un arduino attraverso moduli di frequenza a 433 MHz.
Dopo varie ricerche ed esperimento, mi è venuto fuori una incompatibilità tra Servo.h e VirtualWire.h. Ho provato a sostituire la Servo.h ma niente il servo motore non si sposta, così ho sostituito la VirtualWire.h con la PJON.h. Testando con gli esempi della libreria, i due moduli funzionano alla grande ma il problema nasce quando vado ad inviare un valore numerico. Il mio compito non è stato altro che sostituire al carattere 'B' un vettore di tipo char contenente la lettura analogica. In ricezione mi ritrovo sempre lo stesso valore anche se vado a modificare la posizione del potenziometro.

Sapreste darmi qualche suggerimento?
Grazie...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Mar 31, 2016, 07:44 pm
fai vedere la parte di codice tx e rx, o se vuoi dai un'occhiata a questo progettino (http://forum.arduino.cc/index.php?topic=383965.0) dove invio e ricevo dati da vari sensori e un powermeter...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Alessandro95 on Apr 07, 2016, 08:07 pm
Ciao mauroz,

ti allego i miei file riguardanti la trasmissione e la ricezione attraverso la PJON.h.

Spero che mi puoi aiutare grazie.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Apr 08, 2016, 02:32 pm
te li ho modicati al volo, prova così e ricevi un int (1234), mettici quello che vuoi..


TX
Code: [Select]
#include <PJON.h>        //includo la libreria PJON.h per la trasmissione di dati
#define P_id 1           //Definisco P_id con valore 1 che corrisponde all' id della rete "network"
#define P_pin 12         //Definisco P_pin con valore 12 che corrisponde al pin di trasmissione a cui è collegato il pin DATA del modulo
#define P_id_riceve 99   //Definisco P_riceve con valore 99 che corrisponde all' id del ricevitore
int pot_servo = A0;      //Dichiaro la variabile pot_servo dandogli il valore A0 che fa riferimento al potenziometro del servo motore

unsigned long time = millis();


PJON network(P_pin, P_id); //Inizzializzo la rete "network", utilizzando le variabili precedentemente dichiarate
void setup()
{
  pinMode( pot_servo , INPUT);   //Dichiaro la variabile pot_servo di tipo INPUT
  Serial.begin(115200);
}

void loop()
{
   if(millis() - time > 400) { //invia i dati ogni 400ms (no delay)
    time = millis();
    int lettura_pos = 1234;//analogRead(pot_servo);
    char invio_dati[2] = {lettura_pos >> 8, lettura_pos & 0xFF};
 
    network.send(P_id_riceve, invio_dati, 2);
  }

  network.update();
}


RX

Code: [Select]
#include <PJON.h>       //includo la libreria PJON.h per la trasmissione di dati

#define P_id 99          //Definisco P_id con valore 1 che corrisponde all' id della rete "network"
#define P_pin 12         //Definisco P_pin con valore 12 che corrisponde al pin di trasmissione a cui è collegato il pin DATA del modulo

PJON network(P_pin, P_id); //Inizzializzo la rete "network", utilizzando le variabili precedentemente dichiarate

void setup(){
Serial.begin(115200);
network.set_receiver(receiver_function);

}

static void receiver_function(uint8_t length, uint8_t *payload)
{
  Serial.print("\n---Trasmissione ricevuta---\n");
  Serial.print("Dati Ricevuti: ");
  Serial.println(payload[0] << 8 | payload[1] & 0xFF);
}


void loop()
{
  network.receive();
}
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gpb01 on Apr 08, 2016, 02:49 pm
@Alessandro95:  non avendolo tu ancora fatto, ti chiedo cortesemente di presentarti QUI (http://forum.arduino.cc/index.php?topic=113640.0) (spiegando bene quali conoscenze hai di elettronica e di programmazione ... possibilmente evitando di scrivere solo una riga di saluto) e di leggere con attenzione il REGOLAMENTO (http://forum.arduino.cc/index.php?topic=149082.0) ... Grazie. :)


Guglielmo
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Alessandro95 on Apr 11, 2016, 11:03 am
Ciao Gugliemo,

forse non hai letto bene la mia prima domanda o forse sono io a non aver capito bene il regolamento. Non si preoccupi dalla mia prossima domanda seguirò l regolamento. Per quanto riguarda la mia presentazione lo farò immediatamente. Grazie.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 07, 2016, 10:28 am
Riprendo in mano questo tread a seguito della uscita della nuova versione, la 3, di questo interessantissimo protocollo di comunicazione.

Cercando di capire un po' il funzionamento vedo che si parla di "strategie": purtroppo per chi non è ferratissimo la spiegazione è un po' scarna e si danno per scontato parecchie cose. Se magari se si potessero spendere un po' di parole in più non sarebbe male.
Giovanni, ci sei ? Illuminaci. :-)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jun 07, 2016, 05:28 pm
Ciao a tutti, scusate la scomparsa. Gestire un repository del genere inizia a diventare un lavoro e autofinanziarne lo sviluppo implica fare un altro lavoro  :). In ogni caso, ci sono tantissime novita':

- Lo Standard ora include la possibilita' di definire un bus id, che permette di far coesistere piu' bus sullo stesso medium (i.e. due bus sullo stesso filo o sulla stessa frequenza radio). Questo permette di poter utilizzare con altri lo stesso mezzo di comunicazione senza incappare in interferenze e collisioni non volute.
Per esempio utilizzando i modulini cinesi 433 che sono channel less (tutti sulla stessa frequenza), due utenti PJON potrebbero avere grossi problemi per colpa della collisioni di device id presenti nel range di ricetrasmissione, parte di due reti differenti.

Vedi: https://github.com/gioblu/PJON/wiki (https://github.com/gioblu/PJON/wiki) e https://github.com/gioblu/PJON/wiki/PJON-instance (https://github.com/gioblu/PJON/wiki/PJON-instance)

PJON_ASK e' stato integrato nel repository di PJON.
Per farlo ho dovuto rendere la classe PJON una templated class in grado di essere istanziata ricevendo il tipo di strategia scelta dall'utente (o quella di default che si basa su quella normalmente utilizzata dal repository PJON, quindi ottimizzata per comunicazione su filo). Grazie a questo e' possibile scegliere se utilizzare lo standard PJON comunicando via radio o via filo selezionando la strategia preferita, vedi:
https://github.com/gioblu/PJON/wiki/PJON-instance (https://github.com/gioblu/PJON/wiki/PJON-instance) e https://github.com/gioblu/PJON/wiki/Strategies (https://github.com/gioblu/PJON/wiki/Strategies)

Qui trovate la documentazione dedicata alla strategia dedicata ai moduli radio, chiamata OverSampling, perche' utilizza il metodo dell'oversampling per avere una maggiore performance su media fortemente affetti da noise e interferenze: https://github.com/gioblu/PJON/wiki/OverSampling (https://github.com/gioblu/PJON/wiki/OverSampling)

Nell ultimo link trovate anche una sorta di design reference per costruire una PJON packet radio :).
Spero che vi piaccia il nuovo logo e le illustrazioni presenti nella wiki!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 08, 2016, 08:51 am
Grazie Giovanni, le illustrazioni e ed il logo sono belli ma servirebbe anche aggiungere degli esempi in modo da far capire anche a chi non è ferratissimo (siamo in molti...) come utilizzare tutti gli gli strumenti che hai creato per realizzare strategie diverse da quelle di default.

Gia che ci siamo: io ho degli sketch realizzati utilizzando le librerie pre V3 e ti chiedo se con la nuova libreria funzioneranno ancora.
Grazie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 08, 2016, 12:21 pm
Un'altra domanda più generica:

lato trasmittente:

Code: [Select]

#include <PJON.h>
uint8_t bus_id[] = {0, 0, 0, 1};// Bus id definition
PJON<> bus(bus_id, 45);// PJON object
String prefisso = "M1";

void setup() {
  bus.set_pin(12);
  bus.begin();
  bus.set_error(error_handler);
  Serial.begin(115200);
}

void error_handler(uint8_t code, uint8_t data) {
  if(code == CONNECTION_LOST) {
    Serial.print("Connection lost with device id ");
    Serial.println(data);
  }
}
void loop() {

  if(millis() - time > 3000) {
    time = millis();
   
    long watt= 32769;
    String stringVal = String(prefisso+watt);   // crea la stringa unendo nomesensore + lettura
    int lun = stringVal.length();               // calcola lunghezza stringa
    char charVal[lun];                          // crea array con lunghezza  della stringa
    stringVal.toCharArray(charVal,lun);         // riempie  l'array di char con la stringa
    bus.send(44, charVal, lun);
    //debug
    Serial.print ("STRNGVAL:  ");
    Serial.println(stringVal);
    Serial.print("LUN:  ");
    Serial.println(lun);

  }

  bus.update();
};


lato ricevente:

Code: [Select]
#include <PJON.h>

// Bus id definition
uint8_t bus_id[] = {0, 0, 0, 1};

// PJON object
PJON<> bus(bus_id, 44);

void setup() {
  bus.set_pin(12);
  bus.begin();
  bus.set_receiver(receiver_function);
  Serial.begin(115200);
};

void receiver_function(uint8_t id, uint8_t *payload, uint8_t length) {
// == Lettura stringa temperatura ==
  if(payload[4] == 'M') {
    String dati;      //creo una stringa dai dati ricevuti
    for (int i = 4; i < length; i++) {
      char tmp = payload[i];
      dati += tmp;
    }
 
    Serial.println(dati);

  }
}

void loop() {
  bus.receive(1000);
};


Mi aspetto di ricevere sulla seriale del ricevente la seguente risposta:

M132769

invece ricevo sempre  questo:

M13276.

Mi taglia sempre l'ultima cifra e mi aggiunge un punto.
Non riesco a venirne fuori anche perchè la comunicazione tra due arduini è priva di errori.
Idee o suggerimenti?
Grazie

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Jun 08, 2016, 02:51 pm
Aggiungi un +1 per il carattere di return quando imposti il totale dei caratteri nella stringa..

Code: [Select]
int lun = stringVal.length() +1;

guardando il ricevente vedo un:
Code: [Select]
if(payload[4] == 'M') {, non  dovrebbe essere payload[0] per trovare il carattere M? :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jun 08, 2016, 04:00 pm
Come al solito Mauro mi hai preceduto!!  :)

Hai ragione, il carattere di return non e' tenuto in considerazione e non aggiunto alla length di lun.

In questo caso, avendo definito un bus id, payload[0], payload[1], payload[2], payload[3] contengono il bus id (quindi 4 byte) del ricevitore del messaggio.

Trovate che sia scomodo trovare il recipient bus id nel payload e non astratto in un parametro della funzione ricevente? Purtroppo non riesco a immaginare come gestire il caso e local e network con due diverse funzioni riceventi (con differenti parametri, i.e. con e senza bus id)

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 09, 2016, 09:25 am
@ Giovanni

a mio modestissimo parere, penso sia meglio lasciare il payload più pulito possibile e quindi senza id trasmittente. Non avendo capito ancora benissimo la differenza tra local ed network non saprei come risponderti al come fare. Se ci sono problemi a fare questa modifica, va bene come gia funziona ora però va specificato nelle wiki.

Aggiungo gli sketch funzionanati modificati e funzionanati:

TX
Code: [Select]
#include <PJON.h>
uint8_t bus_id[] = {0, 0, 0, 1};  // Bus id definition
PJON<> bus(bus_id, 45);           // PJON object
String prefisso = "M1";
unsigned long time = millis();    // Inizializzo Time

void setup() {
  bus.set_pin(12);
  bus.begin();
  bus.set_error(error_handler);
  Serial.begin(115200);
}

void error_handler(uint8_t code, uint8_t data) {
  if(code == CONNECTION_LOST) {
    Serial.print("Connessione persa con dispositivo ID:  ");
    Serial.println(data);
  }
}
void loop() {

  if(millis() - time > 3000) {
    time = millis();

// == Creazione stringa ==
    long watt= 32769;
    String stringVal = String(prefisso+watt); // crea la stringa unendo nomesensore + lettura
    int lun = stringVal.length()+1;           // calcola lunghezza stringa
    char charVal[lun];                        // crea array con lunghezza  della stringa
    stringVal.toCharArray(charVal,lun);       // riempie  l'array di char con la stringa
    bus.send(44, charVal, lun);

    //debug
    Serial.print ("STRNGVAL:  ");
    Serial.println(stringVal);
  }
  bus.update();
}


RX
Code: [Select]
#include <PJON.h>
uint8_t bus_id[] = {0, 0, 0, 1};  // Bus id definition
PJON<> bus(bus_id, 44);   // PJON object

void setup() {
  bus.set_pin(12);
  bus.begin();
  bus.set_receiver(receiver_function);
  Serial.begin(115200);
}

void receiver_function(uint8_t id, uint8_t *payload, uint8_t length){
 
// == Lettura stringa ==
  if(payload[4] == 'M') {
    String dati;            //creo una stringa dai dati ricevuti
    for (int i = 4; i < length-1; i++) {
      char tmp = payload[i];
      dati += tmp;
    }
    Serial.println(dati);
  }
}

void loop() {
  bus.receive(1000);
}


Per avere una stringa rispondente a quella in partenza è necessario nel ricevitore NON far leggere l'ultimo carattere (return) che viene inviato con un -1

Code: [Select]
    for (int i = 4; i < length-1; i++) {
      char tmp = payload[i];
      dati += tmp;
    }



Domande:

 -  è necessario inserire l'id del bus oppure in applicazione con un due dispositivi soli che comunicano si può in qualche modo omettere? Se si coma vanno modificati gli sketch di cui sopra?

 - potresti chiarerire il concetto di "local" e "network" ?
Grazie mille
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jun 09, 2016, 11:20 am
Ciao Franchelli, grazie per aver postato il codice ricorretto, anche per gli altri utenti.

Se istanzi un bus PJON senza definire il suo bus id, questo sara' local. Cioe' il suo bus id e' settato a 0.0.0.0 o localhost (il corrispettivo di 127.0.0.1 su ip). Nel payload il bus id ovvio e ridondante viene escluso, e tutti i device della rete locale trasmetteranno omettendo localhost.

Se pero' questo bus per esempio comunica su medium radio, specialmente con i modulini cinesi 433 / 315 channel less, c'e' un elevato rischio che due utenti PJON possano istanziare due reti locali nel loro range di ricetrasmissione. Questo implica che il device 1 del bus di Mario potrebbe ricevere un messaggio inoltrato al device 1 del bus di Andrea, creando cataclismi potenziali non da poco.

Per isolare la propria rete da quella altrui basta definire un bus id, cosicche PJON lo includa nel payload e permetta a device di bus diversi di discenere per quale bus e quindi per chi e' un determinato pacchetto.

Questo implica anche la possibilita' di networking tra bus, permettendo un maggiore range di trasmissione.

Ovviamente, nel caso in cui il tuo medium sia air-gapped (un semplice filo completamente disgiunto dall'ambiente esterno e senza possibilita' di interferenza esterna o una frequenza radio dedicata) puoi istanziare il bus senza bus id perche' in questo caso non hai la necessita' di isolare il tuo traffico.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 09, 2016, 12:40 pm
Ora è chiarissimo, quindi su bus unifilare tra due Arduino può andare benissimo non indicare il bus Id e quindi essere in modalità "local" (magari nel wiki sarebbe importante fare questa precisazione).

Abbi pazienza ma ci saranno prossimamente altre domande e chiarimenti specialmente riguardo le strategie...

Grazie per la disponibilità.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 13, 2016, 08:27 am
@Giovanni

In questi giorni sto cercando di far funzionare il tuo protocollo di trasmissione in  uno sketch perfettamente funzionante che legge tramite RS485 dei parametri in un contatore di energia .

Il contatore è il seguente http://www.flanesi.it/blog/2015/02/13/contatore-eastron-sdm120c-modbus-per-monitoraggio-energetico/  ma non utilizzo le procedure indicate  sul sito suddetto. Su un sito spagnolo di domotica alcuni ottimi programmatori hanno sviluppato una libreria dedicata alla lettura dei registi del contatore che inserisco in allegato . Provando a unire la tua libreria mi escono un sacco di errori di compilazione secondo me non dovuti allo sketch che ho assemblato ma a come sono strutturate le librerie. Ora, data la mia ancora poca, molto poca esperienza nel campo della programmazione ti chiedo se sai dirmi come potrei risolvere il (grosso) problema. DI seguito lo sketch che da errori
Code: [Select]
/* -------------( INFO )--------------

>>>> ULTIMO AGGIORNAMENTO: 9/06/16 <<<<

- COSA FA:

  Elabora ed invia tramite bus PJON dati di consumo da contatore energia SDM 120C
  
  ----------------------------------------------------

- MATERIALI:
  Arduino UNO
  Modulo RS485
  ----------------------------------------------------

- CONNESSIONI:
  Arduino pin >>> Modulo RS485 pin
  0 RX            RO (receive out)  
  1 TX            DI (data in)
  7               DE/RE (data enable/receive enable).
  Libreria SimplemodbusMasterV2:
  versione 0.0.2 by @Franchelli
  based on version 0.0.1 by @peninquen
  based on version 0.0.4  by @cosmopaco
  ====================================================
  >>DEBUG "mySerial"
  Arduino pin >>> Convertitore USB-TTL
  12 RX           TX
  13 TX           RX
  ====================================================
    >>BUS COMUNICAZIONE PJON  
  Arduino pin >>> BUS
  9
  ====================================================*/

#include "SimpleModbusMasterV2.h"
#include "SoftwareSerial.h"
#include "elapsedMillis.h"
#include <PJON.h>


#define PWR_ADR 0X000C    // Potenza Attiva

PJON<SoftwareBitBang> bus(2);// <Strategy name> bus(Id dispositivo PJON)

// Parametri del contatore SDM120C
#define SDM120C_METER_NUMBER   1            // ID contatore
#define SDM120C_BAUDRATE       2400         // baudrate del contatore
#define SDM120C_BYTEFORMAT     SERIAL_8N2   // parità del contatore

SoftwareSerial mySerial(12, 13);          // Seriale software RX - TX - DEBUG

elapsedMillis lettura;

#define TIMEOUT 1000
#define POLLING 3000           // Tenpo di aggiornamento tra le letture
#define RETRYCOUNT 10          // Numero di tentativi, per cambiare la variabile "connection" su true.
#define TXENPIN  7             // Pin di scambio ricezione/trasmissione per il driver RS485
float watt;
String prefisso = "M1# ";

enum
{
  PACKET3,  // Potenza (pwr)
  TOTAL_NO_OF_PACKETS
};

Packet packets[TOTAL_NO_OF_PACKETS]; // Crea un array di pacchetti da configurare
packetPointer pwrPacket = &packets[PACKET3]; // Potenza

union datas{ // Union
  float f;
  unsigned int array[2];
} vol, cur, pwr, apo, rpo, pfa, fre, pen, ren, ten, tre, ire, ere;

void setup(){
  bus.set_pin(9);              // pin di connessione al bus PJON
  bus.begin();                 //inizializza PJON
  bus.set_error(error_handler);//gestione errori di comunicazione PJON

  modbus_construct(pwrPacket, SDM120C_METER_NUMBER, READ_INPUT_REGISTERS, PWR_ADR, 2, pwr.array); // Potenza
  modbus_configure(&Serial, SDM120C_BAUDRATE, SDM120C_BYTEFORMAT, TIMEOUT, POLLING, RETRYCOUNT, TXENPIN, packets, TOTAL_NO_OF_PACKETS); //Inizia la comunicazione modubus SERIAL Arduino UNO.

  mySerial.begin(9600);    // inizializza per debug
 
}

void loop(){
  modbus_update();
  if (lettura > POLLING){
    watt = pwr.f,0; //la cifra dopo la virgola visualizza quanti decimali
    String stringVal = String(prefisso+watt); // crea la stringa unendo nomesensore + lettura
    int lun = stringVal.length()+1;           // calcola lunghezza stringa
    char charVal[lun];                        // crea array con lunghezza  della stringa
    stringVal.toCharArray(charVal,lun);       // riempie  l'array di char con la stringa
    //debug
    Serial.print ("STRNGVAL:  ");
    Serial.println(stringVal);
    lettura = 0;
  }
}

/*-----( Dichiara funzioni scritte da utente )-----*/

void error_handler(uint8_t code, uint8_t data){ // == rileva errori connessione PJON ==
  if(code == CONNECTION_LOST) {
    mySerial.print("Connessione persa con dispositivo ID:  ");
    mySerial.println(data);
  }
}


Nel prossimo post che inserisco ci sono gli errori di compilazione .
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 13, 2016, 08:32 am
Ecco cosa esce se tento di compilare lo sketch precedente
Code: [Select]
In file included from G:/Box Sync/ARDUINO/Sketch/Sketch in uso CASA/Mansarda/Contatore produzione ARDU UNO/Contatore ProduzioneARDUUNO.ino:35:0:

C:/Program Files/Arduino/libraries/PJON/PJON.h:85:10: error: using typedef-name 'Packet' after 'struct'

   struct Packet {



In file included from G:/Box Sync/ARDUINO/Sketch/Sketch in uso CASA/Mansarda/Contatore produzione ARDU UNO/Contatore ProduzioneARDUUNO.ino:32:0:

C:/Program Files/Arduino/libraries/SimpleModbusMasterV2/SimpleModbusMasterV2.h:125:3: note: 'Packet' has a previous declaration here

 } Packet;



In file included from G:/Box Sync/ARDUINO/Sketch/Sketch in uso CASA/Mansarda/Contatore produzione ARDU UNO/Contatore ProduzioneARDUUNO.ino:35:0:

C:/Program Files/Arduino/libraries/PJON/PJON.h: In member function 'void PJON<Strategy>::acquire_id()':

C:/Program Files/Arduino/libraries/PJON/PJON.h:155:34: error: 'struct Packet' has no member named 'state'

           while(packets[ping_id].state != 0 && (time + MAX_ID_SCAN_TIME > micros()))

                                  ^

C:/Program Files/Arduino/libraries/PJON/PJON.h: In member function 'void PJON<Strategy>::remove(uint16_t)':

C:/Program Files/Arduino/libraries/PJON/PJON.h:264:26: error: 'struct Packet' has no member named 'content'

         free(packets[id].content);



C:/Program Files/Arduino/libraries/PJON/PJON.h:265:21: error: 'struct Packet' has no member named 'attempts'

         packets[id].attempts = 0;



C:/Program Files/Arduino/libraries/PJON/PJON.h:266:21: error: 'struct Packet' has no member named 'device_id'

         packets[id].device_id = 0;


C:/Program Files/Arduino/libraries/PJON/PJON.h:267:21: error: 'struct Packet' has no member named 'length'

         packets[id].length = 0;


C:/Program Files/Arduino/libraries/PJON/PJON.h:268:21: error: 'struct Packet' has no member named 'registration'

         packets[id].registration = 0;



C:/Program Files/Arduino/libraries/PJON/PJON.h:269:21: error: 'struct Packet' has no member named 'state'

         packets[id].state = 0;



C:/Program Files/Arduino/libraries/PJON/PJON.h: In member function 'uint16_t PJON<Strategy>::send(uint8_t, const char*, uint8_t, uint32_t)':

C:/Program Files/Arduino/libraries/PJON/PJON.h:302:25: error: 'struct Packet' has no member named 'state'

           if(packets[i].state == 0) {



C:/Program Files/Arduino/libraries/PJON/PJON.h:303:24: error: 'struct Packet' has no member named 'content'

             packets[i].content = str;



C:/Program Files/Arduino/libraries/PJON/PJON.h:304:24: error: 'struct Packet' has no member named 'device_id'

             packets[i].device_id = id;



C:/Program Files/Arduino/libraries/PJON/PJON.h:305:24: error: 'struct Packet' has no member named 'length'

             packets[i].length = length;



C:/Program Files/Arduino/libraries/PJON/PJON.h:306:24: error: 'struct Packet' has no member named 'state'

             packets[i].state = TO_BE_SENT;


C:/Program Files/Arduino/libraries/PJON/PJON.h:307:24: error: 'struct Packet' has no member named 'registration'

             packets[i].registration = micros();



C:/Program Files/Arduino/libraries/PJON/PJON.h:308:24: error: 'struct Packet' has no member named 'timing'

             packets[i].timing = timing;



C:/Program Files/Arduino/libraries/PJON/PJON.h: In member function 'void PJON<Strategy>::set_default()':

C:/Program Files/Arduino/libraries/PJON/PJON.h:406:22: error: 'struct Packet' has no member named 'state'

           packets[i].state = 0;


C:/Program Files/Arduino/libraries/PJON/PJON.h:407:22: error: 'struct Packet' has no member named 'timing'

           packets[i].timing = 0;



C:/Program Files/Arduino/libraries/PJON/PJON.h:408:22: error: 'struct Packet' has no member named 'attempts'

           packets[i].attempts = 0;


C:/Program Files/Arduino/libraries/PJON/PJON.h: In member function 'void PJON<Strategy>::update()':

C:/Program Files/Arduino/libraries/PJON/PJON.h:480:25: error: 'struct Packet' has no member named 'state'

           if(packets[i].state == 0) return;


C:/Program Files/Arduino/libraries/PJON/PJON.h:481:36: error: 'struct Packet' has no member named 'registration'

           if(micros() - packets[i].registration > packets[i].timing + pow(packets[i].attempts, 3))



C:/Program Files/Arduino/libraries/PJON/PJON.h:481:62: error: 'struct Packet' has no member named 'timing'

           if(micros() - packets[i].registration > packets[i].timing + pow(packets[i].attempts, 3))



C:/Program Files/Arduino/libraries/PJON/PJON.h:481:86: error: 'struct Packet' has no member named 'attempts'

           if(micros() - packets[i].registration > packets[i].timing + pow(packets[i].attempts, 3))



C:/Program Files/Arduino/libraries/PJON/PJON.h:482:24: error: 'struct Packet' has no member named 'state'

             packets[i].state = send_string(packets[i].device_id, packets[i].content, packets[i].length);



C:/Program Files/Arduino/libraries/PJON/PJON.h:482:55: error: 'struct Packet' has no member named 'device_id'

             packets[i].state = send_string(packets[i].device_id, packets[i].content, packets[i].length);


C:/Program Files/Arduino/libraries/PJON/PJON.h:482:77: error: 'struct Packet' has no member named 'content'

             packets[i].state = send_string(packets[i].device_id, packets[i].content, packets[i].length);



C:/Program Files/Arduino/libraries/PJON/PJON.h:482:97: error: 'struct Packet' has no member named 'length'

             packets[i].state = send_string(packets[i].device_id, packets[i].content, packets[i].length);



C:/Program Files/Arduino/libraries/PJON/PJON.h:485:25: error: 'struct Packet' has no member named 'state'

           if(packets[i].state == ACK) {


C:/Program Files/Arduino/libraries/PJON/PJON.h:486:28: error: 'struct Packet' has no member named 'timing'

             if(!packets[i].timing)



C:/Program Files/Arduino/libraries/PJON/PJON.h:489:26: error: 'struct Packet' has no member named 'attempts'

               packets[i].attempts = 0;


C:/Program Files/Arduino/libraries/PJON/PJON.h:490:26: error: 'struct Packet' has no member named 'registration'

               packets[i].registration = micros();



C:/Program Files/Arduino/libraries/PJON/PJON.h:491:26: error: 'struct Packet' has no member named 'state'

               packets[i].state = TO_BE_SENT;



C:/Program Files/Arduino/libraries/PJON/PJON.h:495:25: error: 'struct Packet' has no member named 'state'

           if(packets[i].state == FAIL) {


C:/Program Files/Arduino/libraries/PJON/PJON.h:496:24: error: 'struct Packet' has no member named 'attempts'

             packets[i].attempts++;


C:/Program Files/Arduino/libraries/PJON/PJON.h:497:27: error: 'struct Packet' has no member named 'attempts'

             if(packets[i].attempts > MAX_ATTEMPTS) {



C:/Program Files/Arduino/libraries/PJON/PJON.h:498:29: error: 'struct Packet' has no member named 'content'

               if(packets[i].content[0] == ACQUIRE_ID) {



C:/Program Files/Arduino/libraries/PJON/PJON.h:499:41: error: 'struct Packet' has no member named 'device_id'

                 _device_id = packets[i].device_id;



C:/Program Files/Arduino/libraries/PJON/PJON.h:502:57: error: 'struct Packet' has no member named 'device_id'

               } else _error(CONNECTION_LOST, packets[i].device_id);



C:/Program Files/Arduino/libraries/PJON/PJON.h:504:30: error: 'struct Packet' has no member named 'timing'

               if(!packets[i].timing)



C:/Program Files/Arduino/libraries/PJON/PJON.h:507:28: error: 'struct Packet' has no member named 'attempts'

                 packets[i].attempts = 0;


C:/Program Files/Arduino/libraries/PJON/PJON.h:508:28: error: 'struct Packet' has no member named 'registration'

                 packets[i].registration = micros();


C:/Program Files/Arduino/libraries/PJON/PJON.h:509:28: error: 'struct Packet' has no member named 'state'

                 packets[i].state = TO_BE_SENT;


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 13, 2016, 01:03 pm
Qualora Giovanni (o qualche altra anima pia) avesse voglia e tempo di aiutarmi:

nello sketch sopra indicato ho provato a modificare la posizione delle dichiarazioni di libreria
 e con questa disposizione
Code: [Select]

#include <PJON.h>
#include "SimpleModbusMasterV2.h"
#include "SoftwareSerial.h"
#include "elapsedMillis.h"


Gli errori sono molti meno e sono questi:

Code: [Select]
In file included from G:/Box Sync/ARDUINO/Sketch/Sketch in uso CASA/Mansarda/Contatore_ConsumoARDUUNO1/Contatore_ConsumoARDUUNO1.ino:36:0:

C:/Program Files/Arduino/libraries/SimpleModbusMasterV2/SimpleModbusMasterV2.h:125:3: error: conflicting declaration 'typedef struct Packet Packet'

 } Packet;

In file included from G:/Box Sync/ARDUINO/Sketch/Sketch in uso CASA/Mansarda/Contatore_ConsumoARDUUNO1/Contatore_ConsumoARDUUNO1.ino:35:0:

C:/Program Files/Arduino/libraries/PJON/PJON.h:85:10: error: 'struct Packet' has a previous declaration as 'struct Packet'

   struct Packet {




Qualche consiglio?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Jun 14, 2016, 01:56 am
Franchelli, prova così:

modifica il file pjon.h alla riga 85 in "struct Packetj {"
e la riga 517 in "packetj  packets[MAX_PACKETS];"

da me compila senza problemi e invia dati regolari.


x Gioblu: cambia il nome della struct packet per le future release così eviti problemi con la SimpleModbusMasterV2 o altre librerie simili :)




Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jun 14, 2016, 08:43 am
Hehehe come potrei fare senza @mauroz!
Assolutamente corretto, stanno saltando fuori varie incompatibilita' di questo tipo per colpa del common scope. forse l'uso di un prefisso inusuale potrebbe aiutare, o la sequela di underscore come fanno molti, anche se la leggibilita' e chiarezza del codice e' molto importante, soprattutto in un progetto del genere. Quindi sono un po' combattuto sul da farsi, voi cosa ne pensate?

In piu' questo problema e' stato introdotto da me di recente  >:(
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 14, 2016, 10:00 am
@mauroz
grazie mille, la tua dritta fa caricare senza errori lo sketch, ora bisogna vedere se il tutto gira correttamente.

@Giovanni
a mio modesto parere da profano, qualunque modifica "fuori standard" al codice per aumentare la compatibilità con altre librerie è utile così come è utile, se non fondamentale, aggiungere abbondanti commenti a queste "singolarita" per poterne capire le funzioni e nel caso apportare modifiche. Anche in ambito lavorativo,per esperienza, ho capito che la documentazione annessa a qualsiasi progetto (elettronico, meccanico, edile ecc. ecc) è di fondamentale importanza e quanto più è completa ed esplicativa tanto più è utile in caso di modifiche o variazioni successive.

Grazie a tutti e due.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jun 14, 2016, 05:37 pm
Ecco il fix al problema riportato. Grazie a tutti per il vostro supporto a questo progetto:
https://github.com/gioblu/PJON/commit/c7c1d8d6b8af19328e32613f5353ee44da1df5cf (https://github.com/gioblu/PJON/commit/c7c1d8d6b8af19328e32613f5353ee44da1df5cf)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mauroz on Jun 15, 2016, 10:51 am
ottimo grazie come sempre per il supporto
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jun 20, 2016, 09:41 am
ottimo grazie come sempre per il supporto
Mi associo, assolutamente!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 02, 2016, 03:07 pm
Ciao Ragazzi, volevo informarvi di alcune grandi novita'. PJON versione 4.1  :)

Tante novita':
- Aggiunto header di 1 byte
- Funzione reply() per rispondere a un paccketto ricevuto (se sono incluse le info di chi invia)
- Possibilita' di includere le info di chi invia all'interno del pacchetto
- Aggiunta la Stragegia ThroughHardwareSerial che permette di comunicare con PJON tramite la porta seriale

vedi:https://github.com/gioblu/PJON (https://github.com/gioblu/PJON)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 06, 2016, 01:04 am
Ciao a tutti  :)  abbiamo finito e pubblicato il primo video dimostrativo di PJON:
https://www.youtube.com/watch?v=vjc4ZF5own8 (https://www.youtube.com/watch?v=vjc4ZF5own8)
Cosa ne pensate?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Aug 06, 2016, 10:11 am
Complimenti il video chiarisce molto bene le potenzialità della libreria.

Ma.......servirebbero molti esempi pratici (e ben commentati) di utilizzo
non dimentichiamo che molti utilizzatori di arduino sono dei principianti ed hobbisti (come il sottoscritto) che traggono molte idee e spunti dagli esempi d' impiego delle librerie.


 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 08, 2016, 12:21 pm
Ciao S_te, hai dato un occhiata agli esempi proposti presenti nella libreria?
Ti sembra sia necessario aggiungere esempi piu' pratici???
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Aug 09, 2016, 08:25 am
Ciao S_te, hai dato un occhiata agli esempi proposti presenti nella libreria?
Ti sembra sia necessario aggiungere esempi piu' pratici???

Ciao gbm e grazie per il tuo lavoro,

a mio avviso SI servirebbero piu esempi pratici di utilizzo

per esempio inviare letture da sensori di temperatura con valori decimali es.(23,15 gradi)
quale è il modo migliore per creare l'arrey di char ????

inviare stringhe complesse di valori es.(23,15+AABB+01110)

questi sono due spunti che penso bene o male potrebbero essere utilizzati in una miriade di impieghi.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: st_e on Aug 09, 2016, 08:36 am
Gbm non sarebbe possibile avere una versione "super lite" della pjon solo con il minimo indispensabile (in termini di occupazione di memoria arduino) in cui fossero implementate solo la trasmissione e ricezione ??

 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 09, 2016, 04:31 pm
Ciao St_e! Hai problemi a far stare tutto il codice di cui hai bisogno e PJON nel device che hai selezionato?
Cosa stai costruendo? Ti faccio queste domande per capire in quale tipo di use case "cade" la tua applicazione
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 09, 2016, 04:36 pm
Se non hai bisogno o non vuoi utilizzare il packet manager di PJON, basta utilizzare la funzione di basso livello send_string() che si occupa solamente di inviare i dati, senza salvare o gestire un pacchetto (questo viene eseguito dalla funzione send o dispatch) e definisci prima di includere PJON, MAX_PACKETS a 1 (riducendo la grandezza del buffer dei pacchetti a 1). Grazie all'ACK sincrono avrai comunque feedback sull esito della trasmissione.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mdr04 on Aug 29, 2016, 05:27 pm
Ciao a tutti, ho integrato il mio progetto di domotica su mega con una centralina antifurto basata su arduino micro, ora vorrei usare questa libreria per la comunicazione tra i due.
Il micro invia ed il mega riceve ad una distanza di circa 15m.
Ho un paio di dubbi.
Sul micro devo mettere l'istruzione bus.update(); dopo ogni bus.send(); o ne basta una alla fine ed invia i vari pacchetti consecutivamente?
Altra cosa, il mega ha un loop abbastanza lungo e se metto bus.receive(); senza specificare il tempo di ascolto rischio di perdere il pacchetto?
Grazie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 01, 2016, 04:30 pm
Ciao mdr04!

L'istruzione .update() quando viene eseguita, invia i pacchetti che sono da inviare, come quelli da inviare ciclicamente per esempio. Io consiglio di chiamare questa funzione una volta sola, nel loop.

bus.receive() prova a ricevere una sola volta, un pacchetto. E' un timeframe di ascolto sul canale piuttosto corto, quindi si, lasciando un lungo periodo tra le due letture sul canale (la durata delle altre operazioni) e' possibile che molti dei messaggi inviati cadano in questi periodi dove il micro non e' dedicato alla ricezione, ma non sono pacchetti persi; grazie al packet manager integrato in PJON questi vengono in ogni caso recapitati con successo dopo alcuni tentativi. Il reale problema in questo caso e' un calo di bandwidth per colpa di una elevata probabilita' che ogni singolo pacchetto venga ripetuto piu' volte prima che venga recapitato con successo, diminuendo la reale quantita' massima di pacchetti recapitati/secondo. Aumentare il tempo di ascolto sul canale passando il valore in microsecondi, come parametro a receive() puo' essere un modo di risolvere questa questione se inizia a diventare un problema  :).

Ti consiglio in ogni caso di dare un occhiata alla wiki:
https://github.com/gioblu/PJON/wiki (https://github.com/gioblu/PJON/wiki)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: mdr04 on Sep 07, 2016, 10:33 pm
Grazie per la spiegazione, è come pensavo.
Ora ho acquistato alcuni nano per ridurre il codice sul mega ed accorciare il tempo di esecuzione del loop che ora è di minimo 6 millisecondi e che aumenta quando mi collego al web server. A quanto mi consigli di arrivare?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 16, 2016, 10:32 pm
Complimenti gbm per l'ottimo protocollo!

Sarei interessato ad usarlo in una configurazione HW con RS485. Ho letto di recente una tua discussione per creare il meccanismo corretto.

Attualmente, impostando a mano i pin DE/RE su HIGH o LOW è fattibile oppure ancora no?

Io ho provato una configurazione di questo tipo:


Ho collegato 2 Arduino, una Mega e una nano con due schedine RS485, coi due pin DE RE uniti e collegati al pin2 delle schede.
La Mega a sua volta è collegata al pc tramite la USB con la Serial.
La Mega usa la Serial1 per la RS485.
La nano usa la sua Serial per la RS485.
Tutte le varie risposte le leggo da prog su pc (quelle della nano, prima arrivano alla Mega, poi lei le invia al pc).
Ho provato una connessione RS485 usando il tuo protocollo JPON, inserendo manualmente il pin 2 HIGH e LOW in trasmissione e ricezione.


La corretta trasmissione dovrebbe essere così:

1) il PC invia un comando alla Mega con la Seriale USB ogni 5s
2) la Mega risponde al Pc che lo ha ricevuto (Seriale USB)
3) la Mega invia un comando alla nano (RS485)
4) la nano risponde alla Mega che l'ha ricevuto (RS485)
5) la Mega risponde al pc col messaggio della nano (Seriale USB)

Sul pc leggo i bytes ricevuti sulla porta COM collegata alla Mega ogni 10ms.
(Tra l'altro, se aumento anche solo a 12ms in su, il risultato del trasferimento dei dati dalla Mega al pc tramite USB, passa da 300ms circa a 600ms o anche molto peggio... Però meno di 300ms non sono riuscito, neanche mettendo una ricezione ogni 2ms. Anche se sono a 115200.)

ad es dovrebbe sempre essere:
_______0 invio da PC a Mega ---0.0110842079594466ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 332.081638886357ms AbsoluteTimer: ---1037.38990713076ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 512.076449834927ms AbsoluteTimer: ---5263.60463369156ms

Invece ho ad esempio nel log del pc (in maiuscolo miei commenti):

Quote
_______0 invio da PC a Mega ---0.0110842079594466ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 332.081638886357ms AbsoluteTimer: ---1037.38990713076ms
NESSUNA RISPOSTA NANO

_______1 invio da PC a Mega ---5002.48122047803ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 512.076449834927ms AbsoluteTimer: ---5263.60463369156ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 331.966281018335ms AbsoluteTimer: ---6105.5171439855ms
ARRIVA PRIMA LA RISPOSTA DELLA NANO INVECE DI QUELLA DELLA MEGA

_______2 invio da PC a Mega ---10009.7762714202ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 537.043833526691ms AbsoluteTimer: ---10353.7787707039ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 330.837744437575ms AbsoluteTimer: ---11167.7783716724ms

_______3 invio da PC a Mega ---15013.9673336076ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 518.031543192695ms AbsoluteTimer: ---15401.9490963907ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 336.969364070253ms AbsoluteTimer: ---16239.0251972784ms

_______4 invio da PC a Mega ---20020.1909111137ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 510.033671360623ms AbsoluteTimer: ---20460.236430261ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 363.07883170806ms AbsoluteTimer: ---21332.3751651342ms

_______5 invio da PC a Mega ---25028.4100565787ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 516.082775222936ms AbsoluteTimer: ---25534.4583393886ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 335.192196060755ms AbsoluteTimer: ---26371.9035033487ms

_______6 invio da PC a Mega ---30028.6510354703ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 518.945785086239ms AbsoluteTimer: ---30597.6637773831ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 331.0799549078ms AbsoluteTimer: ---30938.7322457673ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 516.048701546616ms AbsoluteTimer: ---32607.7643645177ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 513.138481167931ms AbsoluteTimer: ---34614.8213102519ms
3 RISPOSTE DELLA NANO INVECE DI UNA SOLA

_______7 invio da PC a Mega ---35037.8049491399ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 528.186319788431ms AbsoluteTimer: ---36647.1321869799ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 335.007869787651ms AbsoluteTimer: ---36992.0444123687ms

_______8 invio da PC a Mega ---40047.162483815ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 525.22149942239ms AbsoluteTimer: ---41693.0175237223ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 334.983238214408ms AbsoluteTimer: ---42038.1855069465ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 520.053795355963ms AbsoluteTimer: ---44733.3496722769ms
2 RISPOSTE DELLA NANO INVECE DI UNA SOLA

_______9 invio da PC a Mega ---45047.5377047807ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 530.935203362374ms AbsoluteTimer: ---47795.4405315822ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 353.027097193725ms AbsoluteTimer: ---48158.4906264548ms

_______10 invio da PC a Mega ---50047.5257995203ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 331.057786491881ms AbsoluteTimer: ---52654.7248694321ms
NESSUNA RISPOSTA DELLA NANO

_______11 invio da PC a Mega ---55054.8282399345ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 334.675754075088ms AbsoluteTimer: ---58721.9813801727ms
Pc riceve:Mega Packet buffer is full, has now a length of 5
 bytes ricevuti in 521.018531974656ms AbsoluteTimer: ---59252.9974572006ms
Pc riceve:Possible wrong bus configuration!
 bytes ricevuti in 345.104351660045ms AbsoluteTimer: ---59608.1157749627ms
Pc riceve:higher MAX_PACKETS in PJON.h if necessary.
 bytes ricevuti in 439.04629832612ms AbsoluteTimer: ---60057.0803867814ms
COMINCIANO GLI ERRORI DI BUFFER INVIATI DALLA MEGA AL PC

_______12 invio da PC a Mega ---60057.1255446657ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 333.010249197626ms AbsoluteTimer: ---64796.2599419187ms

_______13 invio da PC a Mega ---65058.3579443803ms
Pc riceve:Mega Packet buffer is full, has now a length of 5
 bytes ricevuti in 502.027589004137ms AbsoluteTimer: ---65308.2797391352ms
Pc riceve:Possible wrong bus configuration!
 bytes ricevuti in 341.980247120364ms AbsoluteTimer: ---65660.3166470846ms
Pc riceve:higher MAX_PACKETS in PJON.h if necessary.
 bytes ricevuti in 445.079802192046ms AbsoluteTimer: ---66115.3455522358ms
RIPETE SEMPRE GLI ERRORI DI BUFFER INVIATI DALLA MEGA AL PC
Quindi a volte non arriva il messaggio alla/dalla nano, a volte arriva sulla mega troppe volte il messaggio dalla nano, finché alla fine dice che ci sono problemi di buffer.

Allego i 2 sketch sulla Mega e sulla nano.

Sarebbe ottimo se gbm riuscissi a realizzare un collegamento ben funzionante in RS485.
Ciao

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 19, 2016, 05:13 am
Ciao Franketto, che versione di PJON stai utilizzando?
Dalla tua descrizione sembra proprio che la nano ogni tanto non riceva correttamente l'ACK e quindi ripeta il messaggio piu volte. Dall'altra parte il mega invece, riceve erroneamente questi messaggi multipli.

Per prima cosa, ti consiglio di aggiornare alla versione master (non l'ultima release 5.0) che contiene alcuni fix proprio alla strategia che tu stai utilizzando ed effettuare un ulteriore test!

Su due piedi io proverei a visualizzare il risultato usando il led 13 invece che due seriali in parallelo, perche' questo potrebbe essere un problema, ma mi devo documentare piu' precisamente! Un test che farei e' passare una durata a receive() invece che chiamarla eseguendo la ricezione una sola volta, forse nel tuo caso particolare e' necessario dedicare piu' tempo alla ricezione, il che e' strettamente dipendente dal tipo di strategia, velocita' di trasmissione e natura del medium che stai utilizzando!

Fammi sapere e non esitare a scrivere alla mia mail personale che trovi sul repo. In bocca al lupo!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 19, 2016, 08:48 pm
Ho installato la PJON master.

0) Ho provato il receive(1000), ma non risolve.

1) Ora vedo una:
PJON<ThroughSerial>
invece di quella di prima:
PJON<ThroughHardwareSerial>
funziona ugualmente con le seriali HW?

2) Adesso la nano riceve il messaggio dalla Mega e la Mega riceve sempre il messaggio di risposta dalla nano: bene.
Però lo riceve in continuazione...
La Mega invia una sola volta il messaggio alla nano, altrimenti me lo stamperebbe più di una volta.
La nano invece continua a reinviare il messaggio, evidentemente ci sono continue chiamate alla receiver_function... Tipo il buffer che non si svuota dopo aver trasmesso la prima volta?
Oppure, più probabile non gli arriva la conferma del messaggio ricevuto dalla Mega e quindi continua a inviarlo.

Forse ho capito: il chip RS485 deve usare:
digitalWriteFast(EnablePin485,HIGH);
prima di iniziare a inviare i dati; una volta finito, bisogna risettare il pin a low per permettere di ricevere::
digitalWriteFast(EnablePin485,LOW);

Queste righe le ho inserite a mano quando dovevo trasmettere qualcosa, ma il messaggio ACK avviene in funzioni interne alla libreria in automatico, ma appunto non viene attivato quel pin e quindi il messaggio non parte!

3) Però, anche i messaggi di errore tramite RS485 non sono arrivati alla Mega dalla nano:
la nano ha attivato la func degli errori perché avevo fatto accendere il led dentro al caso "connection lost", ma alla Mega non è arrivato nulla, eppure lì avevo inserito le righe apposite per la RS485... Mah.
Forse non riusciva ad inviare il messaggio di errore perché la linea era impegnata a inviare continuamente il messaggio del receive.

4) Dovresti fare questa modifica alla libreria:
Chi vuole usare la lib con la RS485 deve inserire una variabile indicando dove ha collegato i pin DE-RE da mettere HIGH/LOW, tipo:
int EnablePin485 = x;

Poi all'interno della lib, fai un check se questa variabile è stata settata, quindi ogni func che deve inviare dei dati, gli devi attivare il pin per l'invio:
digitalWriteFast(EnablePin485,HIGH);
Al termine dell'invio, lo rimetti LOW:
digitalWriteFast(EnablePin485,LOW);

Non so se ne hai bisogno o se hai già provveduto a vedere quando la seriale HW ha terminato l'invio, nel caso volessi esserne sicuro, puoi usare questo codice, prima di rimettere il pin LOW:
while (!(UCSR0A & (1 << UDRE0)))   // Wait for empty transmit buffer
UCSR0A |= 1 << TXC0;                    // mark transmission not complete
while (!(UCSR0A & (1 << TXC0)));    // Wait for the transmission to complete

Questo, normalmente per le Arduino con la sola Serial. Se è per la Mega devi fare un ulteriore controllo su quale Serial è stata collegata al bus nel setup e di conseguenza aggiungere il codice corretto.
Ad es. per la Serial1:
while (!(UCSR1A & (1 << UDRE1)))   // Wait for empty transmit buffer
UCSR1A |= 1 << TXC1;                    // mark transmission not complete
while (!(UCSR1A & (1 << TXC1)));    // Wait for the transmission to complete
Per la Serial2, diventa UCSR2A, UDRE2, TXC2 , idem per la 3, etc etc

Se fai queste modifiche, poi la riprovo, vediamo se c'ho azzeccato ;)
Ciao e grazie

Quote
_______0 invio da PC a Mega ---0.0114946869914627ms
Pc riceve:Mega riceve da PC e invia a Nano
 bytes ricevuti in 351.064572225224ms AbsoluteTimer: ---360.629793900262ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 526.062150130465ms AbsoluteTimer: ---896.670153388387ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 551.079925842848ms AbsoluteTimer: ---1457.63058374947ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 510.072630000805ms AbsoluteTimer: ---1977.67115999455ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 519.087338273859ms AbsoluteTimer: ---2506.74902336213ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 542.129259397317ms AbsoluteTimer: ---3058.77726088177ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 544.883057980843ms AbsoluteTimer: ---3613.76702239986ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 515.955446593221ms AbsoluteTimer: ---4139.70273097342ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 509.978619882196ms AbsoluteTimer: ---4659.75890715084ms

_______1 invio da PC a Mega ---5004.75797936539ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 535.081784697944ms AbsoluteTimer: ---5204.84065900683ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 516.04945671183ms AbsoluteTimer: ---5730.89500917112ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 533.028751496362ms AbsoluteTimer: ---6273.86461229242ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 551.986364017032ms AbsoluteTimer: ---6835.82343832361ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 512.994743643849ms AbsoluteTimer: ---7358.85468580915ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 533.495107368587ms AbsoluteTimer: ---7902.51643329715ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 539.421029037222ms AbsoluteTimer: ---8451.37172668262ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 515.843373395054ms AbsoluteTimer: ---8976.99256293752ms
Pc riceve:Ho ricevuto dal nano: ricevuto Ciao!   device_id:2
 bytes ricevuti in 548.025212774867ms AbsoluteTimer: ---9535.03005860648ms
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 19, 2016, 11:58 pm
Ciao Franketto!

1) Si ThroughSerial e' in grado di gestire sia seriale software che hardware indistintamente.

2) Sembra che il problema sia rimasto lo stesso, cioe' che il mega riceve i messaggi ma il nano non riceve l'ACK del mega.

Attualmente RS485 e' supportata tramite seriale in modalita' auto-tx. La tua e' una proposta interessante e possiamo provare ad aggiungere i necessari setter e le chiamate a funzione necessarie per settare i pin in modo corretto anche nelle altre modalita' dove l'uso dei pin di stato e' necessario!

Per la questione di aspettare l'invio su seriale, sbaglio o la chiamata a flush() dovrebbe ottenere questo risultato?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 20, 2016, 12:11 am
Qui uno schema di come e' configurato un modulo come quello che tu usi in modalita' auto-tx:
(https://cloud.githubusercontent.com/assets/10582029/17731267/e08d3e9a-646c-11e6-991d-417d4b817a6b.png)

In poche parole, ogni volta che il data pin e' high il modulo viene messo in modalita' di trasmissione dallo stesso bit che viene inviato, adottando un transistor aggiuntivo.

In ogni caso, i setter possono essere comodi e sono assolutamente aperto a sperimentare in questo senso per semplificare l'uso agli utenti
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 20, 2016, 08:37 am
Sì, hai ragione il flush dovrebbe essere lo stesso e semplifica parecchio...

Ma, la Mega quando invia il ACK al nano? Quando viene chiamata la bus.update()?
Perché se lo fa in quel momento, avevo effettivamente inserito a mano il pin HIGH prima dell'update e quindi sì dovrebbe inviarlo correttamente.
Altrimenti se lo fa in altro momento il pin è sempre LOW per cui non dovrebbe partire il pacchetto.

Se lo fa nell'update, perché il nano non riceve l'ACK (mentre riceve i normali messaggi)?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 20, 2016, 08:41 pm
Ciao, ogni invio e' composto da 3 fasi, analisi del canale, trasmissione e ricezione dell'eventuale acknowledge. Quindi, visto che in ogni send avvengono queste 3 fasi, non e' possibile da fuori dalla libreria settare i pin correttamente.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 20, 2016, 08:50 pm
Ecco, appunto, lo sospettavo che era questo il problema.
Quindi mi affido alle tue modifiche ;)
Facci sapere che poi la proverò.
Ciao
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 21, 2016, 02:50 pm
Ho dato un'occhiata veloce alla lib: la modifica potrebbe essere qualcosa simile a questo nella throughSerial.h:

Code: [Select]
/* Send a byte and wait for its transmission end */

    int EnableRS485 = -1;

    void send_byte(uint8_t b) {
      if (EnableRS485 != -1) digitalWriteFast(EnableRS485, HIGH);
      serial->write(b);
    };


    /* Send byte response to the packet's transmitter */

    void send_response(uint8_t response) {
      send_byte(response);
      serial->flush();
      if (EnableRS485 != -1) digitalWriteFast(EnableRS485, LOW);
    };


    /* Send a string: */

    void send_string(uint8_t *string, uint8_t length) {
      for(uint8_t b = 0; b < length; b++)
        send_byte(string[b]);
      serial->flush();
      if (EnableRS485 != -1) digitalWriteFast(EnableRS485, LOW);
    };


Non l'ho provata: cosa ne dici?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 21, 2016, 06:02 pm
Ciao Franketto, si infatti e' una piccola modifica che permetterebbe tanti use cases  :), grazie per il tuo contributo.
Anche io stavo guardando e pensavo che forse sarebbe carino creare una nuova strategia chiamata ThroughSerialRS485 che inheriti ThroughSerial, cosi' da avere tutta la funzionalita' della libreria attuale piu' i setter necessari e la variabile che tu indichi nell' esempio, che potrebbe essere un semplice boolean, quindi se in modalita' auto-tx o con state pins. Tu cosa ne dici?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 21, 2016, 06:23 pm
Bè se è in auto-tx HW si può già usare la normale ThroughSerial (ma credo sarà un uso meno frequente: in genere penso si comprino le schedine RS485 e si usa lo stato del pin manualmente via SW); invece per i state pins, è sufficiente settare la var relativa e poi essa stessa fa da check per usare o meno i pin RS485 in invio dati. Se anche fai una strategy dedicata, andrà comunque fatto inserire a mano dall'utente quale pin ha usato.
Non so, a me pare sufficiente la serial che c'è già con queste aggiunte: rimane una cosa anche più "pulita", trasparente. Comunque, tu che la conosci meglio, sai meglio cosa fare ;)
L'importante è che me la fai funzionare :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 21, 2016, 06:33 pm
Ok, allora qualcosa del genere?
Code: [Select]

uint8_t enable_RS485 = NOT_USED;


void set_pin_enable_RS485(uint8_t pin) {
  enable_RS485 = pin;
}


void send_byte(uint8_t b) {
  serial->write(b);
};


/* Send byte response to the packet's transmitter */

void send_response(uint8_t response) {
  if (EnableRS485 != -1) digitalWriteFast(EnableRS485, HIGH);
  send_byte(response);
  serial->flush();
  if(enable_RS485 != NOT_USED) digitalWriteFast(enable_RS485, LOW);
};


/* Send a string: */

void send_string(uint8_t *string, uint8_t length) {
  if(EnableRS485 != -1) digitalWriteFast(EnableRS485, HIGH);
  for(uint8_t b = 0; b < length; b++)
    send_byte(string[b]);
  serial->flush();
  if(enable_RS485 != NOT_USED) digitalWriteFast(enable_RS485, LOW);
};
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 21, 2016, 06:54 pm
Sì, uniformando tutte le var di controllo alla nuova var usata:
enable_RS485 != NOT_USED

Mi pare ottimo, uno chiama la func:

Code: [Select]
bus.set_pin_enable_RS485(2);

ed è apposto.


Spero di provarla stasera, così ti so dire.

Ciao

PS:
una cosa: abbiamo visto che se chi invia non riceve un messaggio di ACK continua sempre a reinviare il pacchetto, però così mi intasa la rete e nessuno può più comunicare...
Quanto dura questo stato di "reinvio", quando si ferma? Per far poi procedere la rete col resto dell'attività, magari segnalando l'anomalia con un messaggio di ERR, anche broadcast e poi fermandosi?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 21, 2016, 06:57 pm
Questo e' il codice completo, compila correttamente ma non ho modo di provarlo con questo setup, se puoi provalo  :)
Code: [Select]

/* ThroughSerial digital communication data link layer
   used as a Strategy by the PJON framework (included in version v4.1)

   Contributors:
    - Fred Larsen, Development, testing and debugging
    - Zbigniew Zasieczny, collision avoidance multi-drop RS485 (latency)
      and SoftwareSerial compatibility
   ____________________________________________________________________________

   ThroughSerial, Copyright (c) 2016 by Giovanni Blu Mitolo All rights reserved.

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License. */

#include <Arduino.h>
#include <SoftwareSerial.h>

#define THROUGH_SERIAL_MAX_BYTE_TIME        10000  // Wait up to 10 milliseconds for an incoming byte
#define THROUGH_SERIAL_FREE_TIME_BEFORE_START 500  // 0.5 milliseconds of free channell before sending

class ThroughSerial {
  public:
    Stream *serial = NULL;

    boolean can_start() {
      if(serial->available()) return false;

      if(
        (uint32_t)(micros() - _last_reception_time) <
        random(THROUGH_SERIAL_FREE_TIME_BEFORE_START, 2 * THROUGH_SERIAL_FREE_TIME_BEFORE_START)
      ) return false;

      return (serial != NULL);
    };


    /* Try to receive a byte with a maximum waiting time */

    uint16_t receive_byte() {
      uint32_t time = micros();
      while((uint32_t)(micros() - time) < THROUGH_SERIAL_MAX_BYTE_TIME)
        if(serial->available()) {
          _last_reception_time = micros();
          return (uint8_t)serial->read();
        }
      return FAIL;
    };


    /* Receive byte response */

    uint16_t receive_response() {
      return receive_byte();
    };


    /* Send a byte and wait for its transmission end */

    void send_byte(uint8_t b) {
      serial->write(b);
    };


    /* Send byte response to the packet's transmitter */

    void send_response(uint8_t response) {
      if(_enable_RS485_pin != NOT_ASSIGNED)
        digitalWriteFast(_enable_RS485_pin, HIGH);

      send_byte(response);
      serial->flush();

      if(_enable_RS485_pin != NOT_ASSIGNED)
        digitalWriteFast(_enable_RS485_pin, LOW);
    };


    /* Send a string: */

    void send_string(uint8_t *string, uint8_t length) {
      if(_enable_RS485_pin != NOT_ASSIGNED)
        digitalWriteFast(_enable_RS485_pin, HIGH);

      for(uint8_t b = 0; b < length; b++)
        send_byte(string[b]);
      serial->flush();

      if(_enable_RS485_pin != NOT_ASSIGNED)
        digitalWriteFast(_enable_RS485_pin, LOW);
    };


    /* Pass the Serial port where you want to operate with */

    void set_serial(HardwareSerial *serial_port) {
      serial = serial_port;
    };

    void set_serial(SoftwareSerial *serial_port) {
      serial = serial_port;
    };

    void set_enable_RS485_pin(uint8_t pin) {
      _enable_RS485_pin = pin;
    };

  private:
    uint32_t _last_reception_time;
    uint8_t  _enable_RS485_pin = NOT_ASSIGNED ;
};
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 21, 2016, 07:58 pm
Provata. Funziona alla perfezione!

Unica modifica:


Code: [Select]

    void set_enable_RS485_pin(uint8_t pin) {
      _enable_RS485_pin = pin;
      pinModeFast(_enable_RS485_pin,OUTPUT);
    };



Poi, basta chiamare il tutto nel setup, con:

Code: [Select]
  bus.strategy.set_enable_RS485_pin( x );


Grazie mille gbm.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 21, 2016, 08:44 pm
Hehehe e' un piacere, grazie a te, ho aggiunto la tua precisazione, lo ritesto e stasera lo pusho.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 21, 2016, 11:18 pm
Qui trovi il commit: https://github.com/gioblu/PJON/commit/71e59a0218dd253584c7a26e735930f56ea8c698 ho messo l acknowledge usando il tuo username, se preferisci che usi il tuo vero nome, comunicamelo.

Ho effettuato un test via Seriale e SoftwareSerial e funziona correttamente.
Potresti ri-testare la master e darmi un ack?  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 22, 2016, 11:34 am
Sì, confermo, funziona tutto bene.


Però per settare il pin RS485, è necessario scrivere:

bus.strategy.set_enable_RS485_pin( x );

NON

bus.set_enable_RS485_pin( x );

come scritto nel readme.
Ciao
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 22, 2016, 02:36 pm
Corretto, grazie  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 24, 2016, 05:06 am
Potresti fare un video velocissimo, o qualche foto per documentare come funziona?
Sono curioso!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 24, 2016, 02:42 pm
Va bene, ti ho fatto un video velocissimo... :)
PJON RS485 tapparella (https://youtu.be/dUu4A0a6p-Y)

HW è: pc->Mega con USB; Mega e nano (su cassonetto tapparella) + 2x modulini RS485 collegati su cavo cat5e.

All'inizio, a sinistra avvio il programma di test su PC che invia un codice tramite seriale USB alla Mega (due bytes: uno riferito al punto della casa sul quale bisogna fare qualcosa, il secondo cosa fare appunto: es. 10,40).
La Mega riceve e reinvia al PC che ha ricevuto il messaggio di far aprire la tapparella di una detrerminata stanza al 40% (il codice di ricezione della Mega è a destra dello schermo) e nel frattempo invia alla Nano tramite RS485 il codice per alzare la tapparella.
La nano riceve e attiva la tapparella.
La nano invia alla Mega che ha ricevuto ed eseguito.
La Mega invia al pc il messaggio ricevuto dalla nano.
Alla fine, raggiunto il 40% di apertura la nano ferma la tapparella e invia la posizione corrente della tapparella alla Mega (40%).
La Mega riceve e invia al pc la posizione.

Molti messaggi si potranno eliminare alla fine, è una modalità "verbose" per test.
Praticamente si invierà il comando da pc e si riceverà solo lo stato finale dell'elemento modificato per poter aggiornare il programma principale che deve sapere ogni elemento nel suo stato attuale.
Oppure se ci sarà un allarme, una nano comunicherà alla Mega e quindi al pc l'avvenuta modifica di sensore. E così via.
Ho usato la modalità broadcast in modo che se c'è qualche comando particolare, tutti lo vedono e possono agire autonomamente di conseguenza senza aspettare un comando specifico centrale, invece di inviare singoli comandi a ogni singola nano. (Questo avviene comunque all'interno dei bytes di comando...)


Ne approfitto per ulteriori domande:
1) Se la linea è temporaneamente occupata e qualcuno deve comunicare qualcosa, automaticamente riprova finché non si libera, senza collisioni, giusto? In pratica dò il comando locale e non mi preoccupo più: arriverà il prima possibile.
2) Nel caso un modulo si rompesse e non riceve il messaggio per lui, abbiamo visto che l'ACK non arriva e quindi continua a rimandare il messaggio: più sopra avevo fatto un PS che non hai risposto: chiedeva appunto quando si ferma nell'insistere con le risposte senza ACK? Perché questo bloccherebbe tutta la linea a lungo... A meno che tra una chiamata e l'altra non ci sia una pausa che permetta comunque a qualcunaltro di inviare un messaggio e poi ricomincia a reinviare i suoi messaggi: comunque prima o poi si fermerà, no?
3) e in modalità broadcast? Chi deve reinviare l'ACK? Se ne fa a meno o risponde solo uno?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 24, 2016, 02:59 pm
Ciao Franketto! Grazie! Bellissimo! Sarebbe bello renderlo un esempio con codice e foto nella wiki, se tu avessi il tempo di fornirmi i materiali io potrei tradurli e inserirli negli esempi d'uso.

1) Se la linea e' occupata send_packet o receive ritornano BUSY, e l'invio posticipato.
2) Se il messaggio e' stato inserito nella lista con send, dopo 1.9 secondi di assenza di risposta di uno dei device cancella il pacchetto e lancia un errore CONNECTION_LOST passandoti con quale device ha perso la connessione. Se succede con send_repeatedly per ora ho lasciato che il messaggio non viene cancellato ma posticipato al prossimo intervallo. Se questo intervallo e' molto corto, potrebbe saturare la rete.
3) In modalita' BROADCAST nessuno ACKA per evitare collisioni!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 24, 2016, 03:31 pm
Ciao gbm, ecco il tutto:

Codice Mega:
Code: [Select]
#include <PJON.h>
#include <PJONDefines.h>
PJON<ThroughSerial> bus(1); // 2 pin over-sampled data link layer

void setup() {

  Serial.begin(115200);   // Nella Mega: Serial USB con PC

  bus.set_receiver(receiver_function);
  bus.set_error(error_handler);
 
  Serial1.begin(115200);  // stessa velocità in tutti gli Arduino  // Nella Mega uso Serial1 per RS485
  bus.strategy.set_serial(&Serial1);
  bus.strategy.set_enable_RS485_pin(2); // settare il pin al quale avete collegato RS485
}

void loop() {
  //************ RS485: *************
  bus.update();
  int response = bus.receive();

  // PC communication USB Serial:
  if (Serial.available() == 2) { // comunicazione con due byte per ogni pacchetto
 
    byte msg [2];
    msg[0] = Serial.read();
    msg[1] = Serial.read();
    switch (msg[0]) {
      case 10: {
            Serial.println("Mega riceve da PC e invia a Nano TappF: aprila di %");
            uint8_t data[2] = {10, msg[1]};
            bus.send(2, data, 2);
break;
      }
      case 11: {
          if (msg[1] == 254) {
            Serial.println("Mega riceve da PC e invia a Nano TappF: % aperta la tapp?");
            uint8_t data[2] = {11, 254};
            bus.send(2, data, 2);
          }
         break;
      }
    }
  }

} // end loop


Codice nano:
 
Code: [Select]
#include <PJON.h>
#include <PJONDefines.h>
PJON<ThroughSerial> bus(2); // 2 pin over-sampled data link layer

String dati;

void setup() {
 bus.set_receiver(receiver_function);
 bus.set_error(error_handler);
 Serial.begin(115200); // stessa velocità in tutti gli Arduino
 bus.strategy.set_serial(&Serial);
 bus.strategy.set_enable_RS485_pin(2);    // settare il pin al quale avete collegato RS485
}


void loop() {
 //************ RS485: *************
 bus.update();  // serve per aggiornare bus per INVIARE (se si riceve solo non serve)
 int response = bus.receive();
 
 // do other things...
} // end loop

// RS485  Func receive DATA:
void receiver_function(uint8_t *payload, uint8_t length, const PacketInfo &packet_info) {

    switch(payload[0]){
        case 10:
          //bus.send(1, "ricevuto tapp %", 15); // risposta facoltativa di ricevuto messaggio
         if (payload[1] > xxxxx ) { // controllo il secondo byte
           // fai qualcosa
         }
         else if (payload[1] < xxxxxx ) {
           // fai qualcos'altro
          }
         break;
         
       case 11:
         if (payload[1] == 254 ) { // controllo il secondo byte ricevuto
             uint8_t data[2] = {11,tappAperta};
             int broadcastTest = bus.send(BROADCAST,data, 2); // esempio di risposta (facoltativa) broadcast
         }   
         break;
     }   
}; // fine receiver



Poi allega il video e dovrebbe essere ben documentato il tutto. Magari aggiungi il link delle schedine RS485 come esempio HW.



per la 2), se è così andrebbe bene: però chiedevo perché appunto quando ancora la libreria non era apposto con RS485, continuava però a inviare all'infinito il messaggio... Probabilmente era un po' tutto sballato per via del pin...

3) ok, però non è un po' troppo "insicuro"? Cioè diventa possibile che il messaggio non arrivi mai e nessuno se ne accorge... In un sistema basato tutto sul broadcast, sarebbe troppo vulnerabile... Magari prevedere almeno una risposta di un ACK di uno solo deciso a priori, a quello che ha inviato il broadcast? Se l'ha ricevuta lui, si supponga l'abbiano ricevuta tutti. Cosa ne dici?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 24, 2016, 04:13 pm
2)Esatto, devi solo eventualmente gestire l'errore, se avviene.

3)Un pacchetto broadcast, in un ambiente privo di ACK asincrono, non puo' ricevere un ACK, perche' non c'e' modo che i tanti che ricevono possano organizzarsi su chi deve inviare l'ACK e in ogni caso, l'informazione contenuta in quell'ACK non avrebbe molto valore (chi effettivamente ha ricevuto?).

Perche' includi PJONDefines.h? Dovrebbe essere auto-incluso da PJON.h!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Sep 24, 2016, 04:52 pm
Sì, in effetti ripensandoci... quindi per messaggi di priorità di sicurezza più alta sarà bene usare il sistema normale.

Il defines non l'ho inserito io, è  l'IDE di Arduino che l'ha messo in automatico dal menu delle librerie. Poi mi sono dimenticato di toglierlo.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Sep 25, 2016, 02:12 pm
Ah ok, non avevo notato!

Versione 5.1 rilasciata con modifiche da te proposte: https://github.com/gioblu/PJON/releases
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 06, 2016, 05:16 pm
Rilasciata la versione 5.2 (https://github.com/gioblu/PJON/releases/tag/5.2) contenente:
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Oct 06, 2016, 05:41 pm
Bello!
Correggi il link...

Un'altra cosa: per ora non ho provato con più di due nodi RS485,  però per quel discorso del broadcast, si potrebbe fare una cosa così:
quando si invia un messaggio a un nodo specifico, ora penso che il messaggio venga ignorato da tutti gli altri.

Invece si potrebbe mettere un flag per inviare un messaggio indirizzato a un nodo specifico, ma permettere anche a tutti gli altri di leggerlo.
Così si avrebbe un misto di messaggio specifico e broadcast, col vantaggio di avere almeno un ACK di risposta dal nodo interessato: un minimo di sicurezza in più rispetto al broadcast e un po' più di versatilità rispetto ai messaggi singoli.

Che ne dici?
Ciao
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 06, 2016, 06:02 pm
Ciao Franketto, non sono sicuro possa essere effettivamente utile, perche' non potresti essere sicuro se gli altri abbiano ricevuto o no, e mi sembrerebbe un modo per mischiare due diverse funzionalita' senza ottenere un risultato pulito in nessuno dei due casi. Se hai bisogno di ascoltare i messaggi anche degli altri device, puoi utilizzare set_router(true) per fare un modo che il device riceva sempre i messaggi, indipendentemente dal destinatario.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Oct 06, 2016, 06:36 pm
Può essere sia una cosa inutile... ci sto solo ragionando su.
esempio pratico con 10 nodi:

1) pc dovrebbe mandare un comando a ognuno dei 10 nodi per far eseguire ognuno un compito e poi ricevere il risultato del compito: pc->10xMessaggi+10xACK; 10nodi->pc: 10xSettaggi+10xACK  tot: 40 messaggi
2) pc invia al nodo 1, gli altri leggono lo stesso: 1mess+1ACK; si suppone tutti i 9 restanti abbiano letto, poi tutti inviano settaggi: 10xMess+10xACK tot: 22messaggi.
SE il pc non riceve uno o più dei restanti 9 messaggi di settaggio, allora sa che nodoX non ha ricevuto, allora provvede a inviare il comando specifico.

Insomma, si risparmierebbe quasi la metà dei messaggi. Certo, non è chissaché, però... In effetti però si complica la programmazione lato SW... mah, probabilmente non ne vale la pena, avendo la banda quasi sempre libera. Forse con molti nodi in più.

Comunque, col set_router si ottiene la stessa cosa, ottimo.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 06, 2016, 07:00 pm
Ciao Franketto, questo e' un possibile livello applicazione che puo' essere ottenuto "sopra", con la libreria standard, settando la configurazione per ottenere questo risultato. Come ti dicevo per fare in modo che un device riceva tutti i pacchetti set_router(true).

Se tutti i nodi devono ciclicamente spedire un messaggio, non e' per forza la scelta piu' efficiente usare un sistema master-slave polling, proprio perche meta' dei messaggi sono del master che richiede il nuovo valore. Per evitarlo potresti comunque avere un master, ma lasciare che i device comunichino il loro stato aggiornato in modalita' multimaster, ciclicamente in maniera autonoma senza bisogno della richiesta del master.

 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 07, 2016, 02:06 am
Per favore, spiegami meglio se ho franteso la tua proposta / richiesta  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Oct 07, 2016, 09:14 am
Ciao gbm, allora la situazione è questa:
il pc-cuore del sistema, x nodi, una Mega che fa da Master per poter fare da ponte col pc.

1) il pc gestendo il tutto, spesso invierà dei singoli comandi a singoli nodi, oppure dovrà mandare comandi a tutti i nodi contemporaneamente.
2) i nodi dovranno anche agire autonomamente localmente
3) quando localmente si verificherà una situazione y, devono comunicare al Master->pc un determinato loro stato. Però, a seguito di questo, il pc potrebbe voler comandare a tutti di fare qualcosa. Per cui dovrebbe inviare a tutti dei comandi e ricevere poi l'avvenuta esecuzione o i settaggi aggiornati.

Quindi abbiamo una configurazione con un Master, ma anche una situazione multimaster con nodi che comunicano quando serve autonomamente. Ma potrebbe essere *forse* utile anche l'attuazione di un broadcast, per fare sempre sapere a tutti i nodi quali sono i comandi, quali settaggi hanno gli altri nodi etc
In certe situazioni si risparmierebbero vari messaggi, come mostrato sopra. Non so quanto sia utile, data anche l'insicurezza del broadcast... Altrimenti quand'è che lo usiamo/a cosa serve?

Certo che se mi implementi degli ACK asincroni... ;)
Potresti gestirli, in seguito a un broadcast, dando uno slot temporale ad ogni nodo in sequenza per evitare collisioni, tipo quello che ha fatto gammon con il rolling master. Magari inviando gli ACK tutti al Master invece che all'autore del messaggio broadcast. Se non arrivano xACK sappiamo che non l'ha ricevuto, perciò inviamo messaggio manualmente.
Però mi pare sia una situazione possibile, ma rara: in teoria se normalmente i singoli messaggi a singoli nodi vanno sempre a buon fine, tutta la rete dovrebbe normalmente leggere ogni singolo messaggio: per questo pensavo anche a un singolo ACK di risposta. Certo, tutti gli ACK è meglio.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 07, 2016, 06:47 pm
Allora, l'architettura descritta ha alcuni tratti simili al setup che ho realizzato a casa mia.
Sono d'accordo e mi sembrano scelte sensate.

Parlando di una applicazione utile del broadcast vedi la classe PJONMaster che ne fa uso:
PJONMaster (https://github.com/gioblu/PJON/blob/master/PJONMaster.h)

Parlando dell'ACK asincrono, si, e' una funzionalita' che sara' implementata nella versione 6  :).

Implica un leggero aumento della memory footprint della libreria anche per setup piu basici ma e' una feature molto importante per alcuni casi ed in generale puo' essere una soluzione scelta dall'utente e sarebbe sensato comprenderla nella specifica.

Questa espansione della specifica e il conseguente update dell'implementazione permetteranno di ottenere questo risultato, per esempio settando il bit ACK_MODE dell'header a 1, potrai mandare un broadcast, richiedendo un ACK asincrono che forzatamente avra' SENDER_INFO bit a 1 (quindi contenendo le info dell inviante). Con questa semplice scelta di configurazione potrai ottenere il risultato di ricevere n pacchetti di acknowledge asincrono da tutti i device che hanno ricevuto.

Ovviamente in qualche forma va espansa anche la classe PJONMaster conseguentemente...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Oct 07, 2016, 06:59 pm
Ottimo.
Ma allora farai anche un check automatico dietro le quinte per verificare che tutti i nodi abbiano ricevuto? (Avendo settato il numero totale inizialmente). Reinviando poi, sempre in automatico, il messaggio ai nodi che non hanno inviato l'ACK?
Fatta così sarebbe perfetta. Si avrebbe la certezza della ricezione da parte di tutti in automatico. Se non si riesce genera messaggio di errore corrispondente segnalando quale nodo non risponde più: ma allora si capisce che non è più in grado di ricevere nessun messaggio, neppure non broadcast.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 08, 2016, 09:18 am
Ciao gbm, stai lavorando alla 6?  :)

Ho riscontrato un problema tra la trasmissione di PJON e la libreria per pulsanti capacitivi CapacitiveSensor.h

Se nel loop c'è la

Code: [Select]
total1 =  cs_9_10.capacitiveSensor(30);

l'invio di messaggi dall'unità con il sensore capacitivo con RS485 non funziona più bene: ne deve inviare 3-4 prima di ricevere un ACK...
Cioè, invio comando da pc, dovrebbe eseguire un'operazione e inviare risposta alla Mega che poi me la invia al pc, invece mi invia troppi messaggi alla Mega, evidentemente senza ricevere subito un ACK.

Puoi provare? A me servirebbe proprio l'uso di pulsanti capacitivi...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 10, 2016, 04:18 pm
ops!
Scusa, ho fatto uno sketch di test con solo PJON e lib capacitiva e sembra andare...
Dev'essere qualcosa relativo agli interrupt nel resto dello sketch, dato che la lib li disabilita/riabilita ad ogni ciclo...

Ricontrollerò meglio.

Ciao
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Nov 10, 2016, 04:27 pm
Modbus ...
Contiene un packet manager?
E un reaction manager?
come protocollo di trasporto No
pero' sul layer superiore
nell'industria sono note soluzioni simili

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Nov 10, 2016, 04:32 pm
Al pacchetto viene aggiunto il CRC, (1 byte xor based)
debole, molto meglio il checksum polinomiale
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 10, 2016, 09:43 pm
ops!
Scusa, ho fatto uno sketch di test con solo PJON e lib capacitiva e sembra andare...
Dev'essere qualcosa relativo agli interrupt nel resto dello sketch, dato che la lib li disabilita/riabilita ad ogni ciclo...

Ricontrollerò meglio.

Ciao

Sono qua di nuovo...
mi ri-correggo!
Il problema c'è!

Evidentemente non è nella nano che invia un comando, ma nella routine del receive: quando il pc invia un comando, la Mega lo riceve, poi lo invia alla nano, ma non arriva una sola volta, ma molte, evidentemente è l'invio dell'ACK di risposta verso la Mega che non va a buon fine e quindi la Mega continua a reinviare lo stesso comando? Finché dopo 4-5 volte si ferma.

Con questo codice si può testare bene il problema:

Code: [Select]
#include <PJON.h>
PJON<ThroughSerial> bus(2);
int response;

#include <CapacitiveSensor.h>
            CapacitiveSensor   cs_5_6 = CapacitiveSensor(5,6);

              const byte  rele2 = A2;

long total1;

void setup() {

  pinMode(rele2, OUTPUT);
  
  bus.set_receiver(receiver_function);
  bus.set_error(error_handler);
  Serial.begin(115200);
  bus.strategy.set_serial(&Serial);
              bus.strategy.set_enable_RS485_pin(2);
}

void loop() {

 //************ RS485: *************
  bus.update();
  response = bus.receive();
//************ END  RS485 *************

  total1 =  cs_5_6.capacitiveSensor(30);

} // fine loop


// RS485  Func receive DATA:
void receiver_function(uint8_t *payload, uint8_t length, const PacketInfo &packet_info) {

     switch(payload[0]) {
      
           case 10:
            bus.send(1, "ricevuto", 8);

            if (digitalRead(rele2) == HIGH)
                digitalWrite(rele2, LOW);
            else
                digitalWrite(rele2, HIGH);

            break;
            
      } // end switch
      
}; // fine receiver

void error_handler(uint8_t code, uint8_t data) {
  if(code == CONNECTION_LOST) {
    Serial.print("nano Connection with device ID ");
    Serial.print(data);
    Serial.println(" is lost.");
  }
  if(code == PACKETS_BUFFER_FULL) {
    Serial.print("Nano Packet buffer is full, has now a length of ");
    Serial.println(data, DEC);
    Serial.println("Possible wrong bus configuration!");
    Serial.println("higher MAX_PACKETS in PJON.h if necessary.");
  }
  if(code == CONTENT_TOO_LONG) {
    Serial.print("Nano Content is too long, length: ");
    Serial.println(data);
  }
}// fine err handler


e questo è il log:
Quote
domotica invia:10,100
Pc riceve:   ricevuto
domotica invia:10,0
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
domotica invia:10,100
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
domotica invia:10,100
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
domotica invia:10,0
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
Pc riceve:   ricevuto
I vari "ricevuto" sono velocissimi: il relè fa una raffica on/off.

Fammi sapere, che appunto i pulsanti capacitivi mi servirebbero.
Sospetto sia in qualche modo l'uso del nointerrupt/interrupt in una func della lib capacitivesensor...
Magari fa impallare qualche tuo ciclo con millis?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 11, 2016, 09:57 am
Non è il nointerrupts: ho provato a toglierli, fa lo stesso il problema...

Ok, ho escluso altri punti della funzione e ho concluso che il problema si manifesta in questo punto della func
int CapacitiveSensor::SenseOneCycle(void)

Code: [Select]
while ( DIRECT_READ(rReg, rBit) && (total < CS_Timeout_Millis) ) {  // while receive pin is HIGH  AND total is less than timeout
 total++;
 }


Con quella riga, crea il problema. Probabilmente blocca ogni operazione per un tot di tempo, forse fa scattare qualche timeout degli ACK nella tua lib e così prova a reinviare il comando. Può essere?
Come risolviamo?

BTW: ho riscritto la func della lib capacitiva in modo più "leggibile" con i digitalWriteFast, eventualmente se serve...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 01:09 pm
Ciao Y888099 scusa se ti rispondo in ritardo. Nelle versioni deprecate di PJON all'inizio del suo sviluppo era presente un xor based CRC, molto leggero in termini di tempi computazione ma sicuramente insicuro per pacchetti lunghi. Per questo nelle versioni successive e' stato sostituito dal crc8 bit e recentemente e' stato aggiunto il supporto al crc32, opzionalmente richiesto dall'utente o automaticamente settato oltre 255 caratteri.

Ciao Franketto, mi e' sfuggita la tua segnalazione, proprio per il mio completo focus sul development della 6.
Sembra che la funzione DIRECT_READ(rReg, rBit) rompa il meccanismo. Che strategia stai utilizzando?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 14, 2016, 01:23 pm
ciao gbm
uso la

Code: [Select]
#include <PJON.h>
PJON<ThroughSerial> bus(2);


con la RS485.
come ho indicato nello sketch di test postato sopra.

In ogni caso anche sostituendola con un digitalReadFast è lo stesso:

 
Code: [Select]

while ( (digitalReadFast(capacInp)== HIGH) && (total < CS_Timeout_Millis) ) {  // while receive pin is HIGH  AND total is less than timeout
              total++;
}


Quindi il problema sembra il ciclo While.

Anche perché il pin dove fa il Read non ha relazione col pin2 usato per la RS485.
Nel mio caso uso infatti il pin 6 come input receive e il 5 come output.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 01:40 pm
C'e' qualcosa di questa funzione che non mi torna, CS_Timeout_Millis, non e' un valore in millisecondi, ma semplicemente la quantita' di volte che il while ha girato, che dipende dal tempo di esecuzione della lettura digitale, dal clock e dall'architettura utilizzata. La prima cosa che mi viene in mente e' di aggiungere yield(); dopo l'addizione a total e vedere se aiuta.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 01:53 pm
Altro potenziale caso potrebbe essere il THROUGH_SERIAL_MAX_BYTE_TIME troppo ridotto se la durata della lettura e' maggiore e cade proprio tra ricezione e invio dell'ACK.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 14, 2016, 02:08 pm
Niente da fare: ho provato entrambi i metodi sia il yeld(), sia mettendo 150000 invece di 10000 nel THROUGH_SERIAL_MAX_BYTE_TIME, rimane il problema.

Tra l'altro però provando la funzione riscritta col digitalWrite/ReadFast il relé si accende/spegne con un suono più lento della raffica che fa col DIRECT_READ(rReg, rBit)!
Pensavo che digitalReadFast fosse equivalente come velocità alla lettura in linguaggio a basso livello, invece sembra che il metodo DIRECT_READ sia più veloce...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 02:44 pm
Non credo che tu possa valutare la differenza tra le due funzioni sonoramente con dei relays, per certo PJON in modalita' standard trasmette byte potenzialmente switchando 1 0 attorno 16000 volte al secondo. Puo' un relays risonare nominalmente a quella frequenza?

Per il problema della libreria, ti consiglierei di provare una delle tante altre alternative e vedere se il problema sussiste! Potrebbe anche essere un problema hardware, potrebbe essere necessario adottare un semplice diodo di soppressione a monte dei sensori.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 02:49 pm
Ah mi sono dimenticato di chiederti la tua opinione sulla versione 6  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 14, 2016, 04:42 pm
Ho provato a cambiare il pin RS485 dal 2 al 10, è uguale.

Quote
Per il problema della libreria, ti consiglierei di provare una delle tante altre alternative e vedere se il problema sussiste!
Quali altre lib esistono per i capacitivi? Io ho trovato solo questa:
http://playground.arduino.cc/Main/CapacitiveSensor?from=Main.CapSense

Potrebbe anche essere un problema hardware, potrebbe essere necessario adottare un semplice diodo di soppressione a monte dei sensori.
Però a livello hardware la libreria funziona molto bene se non utilizzo la funzione receive della PJON...
Il pulsante capacitivo funziona ok.
E anche l'invio di dati sul bus RS485, tipo nel loop una func così funziona senza problemi, senza nessun doppione di messaggio arrivato. Evidentemente lì funzionano anche gli ACK.

Code: [Select]

if (millis() - timerTest <  5*1000) {
   counter++;
   uint8_t data1[2] = {110, counter}
   bus.send(1, data1, 2);
}


E' solo il receive della RS che crea problemi, con messaggi ripetuti, forse per problemi di ACK! Perciò escluderei un problema HW, altrimenti si dovrebbe manifestare anche nel semplice invio di messaggi.

Quote
Ah mi sono dimenticato di chiederti la tua opinione sulla versione 6
ahh, ma è uscita la 6! Stasera/domani la installo.
Allora hai implementato il broadcast con gli ack asincroni?
Si usa sempre il comando:
Code: [Select]
int broadcastTest = bus.send(BROADCAST, "Message for all connected devices.", 34);
e in background fa gli ACK in automatico?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 09:03 pm
Ciao Franketto, questo week end faro' una prova con i capacitivi e la libreria di cui parli, vediamo cosa ne salta fuori.

Si la 6 e' stata rilasciata ormai quasi 20 giorni fa, non ho postato qui perche' e' ancora in fase di betatesting.

Cosa ne pensi??  :)

ACK asincrono arrivera' con la 6.1
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 14, 2016, 10:18 pm
Bè, direi che più va avanti meglio è. Bravo!
Come sai, attendo di provare la 6.1... ;)

Ho installato la 6beta: però c'è un problema che non mi vede più la nano nel bus,  CONNECTION_LOST!

Usando lo stesso sketch con la 5.1 invece la vede bene.

Quindi qualcosa è cambiato nella 6...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 14, 2016, 11:02 pm
Considera che la 6.0 necessita un update di tutti i device connessi perche' e' l'header e la lunghezza sono stati invertiti di posizione per supportare la lunghezza di due caratteri e quindi supportare pacchetti piu lunghi di 255 caratteri.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 15, 2016, 02:13 pm
OK.

Quindi ora abbiamo pacchetti>255 e CRC32.
E' previsto in futuro l'eliminazione del conteggio della length da fare a mano? Niente di che, ma ogni volta doverlo inserire... Non che mi riguardi molto perché uso quasi sempre un array di bytes, per cui inserisco quasi sempre 2 o 3, ma se uno dovesse inviare parecchi messaggi lunghi direttamente in stringa...

Mi raccomando, ci conto sul check della capacitiva ;)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 15, 2016, 03:22 pm
incollami il codice, lo provo se posso questa sera.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 15, 2016, 04:27 pm
Grazie gbm!

L'ho già postato qui (http://forum.arduino.cc/index.php?topic=340419.msg2995673#msg2995673).  ;)

Io lì ho usato dei relè fisici anche per sentire fisicamente il clik clak dell'errore, ma è sufficiente monitorare con un monitor seriale o con gli stessi messaggi inviati nel bus che invece di un solo receive ne arrivano molti. Per cui l'azione corrispondente al contenuto del payload che arriva viene eseguita molte volte invece di una sola.
Come infatti ho allegato nel log, sempre nello stesso messaggio.
Ciao e grazie.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 15, 2016, 06:40 pm
Riguardo al parametro lunghezza, l'inserimento manuale e' l'unico modo di avere la certezza di inviare l'intera stringa. Utilizzando strlen() o in ogni caso la strategia del NULL terminator, rischi, per colpa di un byte di valore 0 in mezzo alla stringa (inviando dati non puoi essere certo che non succeda) che questa venga troncata allo 0 invece che al suo termine reale.
 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 15, 2016, 07:10 pm
Ma un byte 0x0 non dovrebbe essere di tipo differente dal NULL '\0' ?
In quel caso un === invece di un == dovrebbe accorgersene confrontando anche i tipi.
Oppure un:
if () == NULL
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 16, 2016, 11:39 am
Se parli di una Stringa di C o C++ il tuo ragionamento funziona, non vale per gli array di byte o caratteri.
Potremmo aggiungere un nuovo metodo che overloadi i normali send per il tipo stringa?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Nov 16, 2016, 12:31 pm
Ma un byte 0x0 non dovrebbe essere di tipo differente dal NULL '\0' ?
in C le stringhe non sono un vero tipo, sono un array di char
in C++ le stringhe sono un vero tipo, una classe con tanto
di metodi associati, pero' il campo context e' un banale array
di char, e si ricade nel problema del C

ovvero '\0' e' una convenzione, de facto pari a 0x00
anche NULL e' una convenzione, de facto pari a 0x0000.0000
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 20, 2016, 08:52 pm
Ciao gbm, novità con la capacitiva?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 22, 2016, 06:53 pm
Ciao, negli ultimi giorni mi sono dedicato a grossi bugfix di basso livello.
Grazie a un fix di poche righe SoftwareBitBang non necessita piu' dell'uso di una pull down resistor, è molto piu' affidabile e questo ha reso possibile aumentare la velocità di trasmissione.

Spero di riuscire a testare il tuo report questa sera
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Nov 24, 2016, 02:46 pm
Ciao gbm!
Io programmo arduino per hobby e il mio livello di conoscenza di questo argomento non e dei più alti.
E da giorni che lego post riferiti alla tua libraria e voglio solo dire che sei proprio bravissimo.
Non solo come creatore di questo protocollo, ma anche come persona sempre disponibile ad acetare critiche e consigli. BRAVO!
E bellissimo vedere che finalmente qualcuno crea qualcosa di nuovo nel mondo dei protocolli.
Ho fatto un po' di test con simulatore Proteus e volevo poi riversare il tutto su un sistema" mini demotico" per controllare termostati ambiente, tapparelle, eventuale luci.. in casa.
Vorrei collegare il tutto con un Arduino 'centrale' ma anche avere la possibilità di comunicare da qualunque punto con altri.
Un idea l'avrei, però prima di avventarmi e prendere la strada sbagliata, volevo chiederti qualche consiglio.
Prevedo che la mia rete avrà la lunghezza massima dei singoli cavi di circa 15mt.
Secondo te per collegare una decina di Arduino che "strategia" dovrei usare?
Pensavo al "ThroughSerial-con SoftSerial" in modo che eventualmente se ho problemi poi posso mettere dei rs485?
Tu cosa ne dici?
Poi quando inizio eventualmente ti farò altre domande, come x esempio qual è il modo migliore per trasmettere il RTC Time da un centrale a i 'Slave'?
Quale e il tuo consiglio sul uso delle Strutture di dati ("struct") nel tuo protocollo??
Grazie in anticipo e buon lavoro!!
Saluto anche Franketto che vedo molto utile nello sviluppo della Library
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gpb01 on Nov 24, 2016, 02:49 pm
>Cina:   essendo il tuo primo post, nel rispetto del regolamento, ti chiedo cortesemente di presentarti QUI (http://forum.arduino.cc/index.php?topic=113640.0) (spiegando bene quali conoscenze hai di elettronica e di programmazione ... possibilmente evitando di scrivere solo una riga di saluto) e di leggere con attenzione il su citato REGOLAMENTO (http://forum.arduino.cc/index.php?topic=149082.0) ... Grazie.

Guglielmo
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Nov 24, 2016, 04:08 pm
Guglielmo, grazie del consiglio.
Mi sono presentato.
Spero che la mia domanda non e stata fraintesa.
Vorrei, fare questa piccola "rete" anche per testare la libreria ...
Grazie ancora
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gpb01 on Nov 24, 2016, 04:47 pm
...
Spero che la mia domanda non e stata fraintesa.
No, no, tranquillo, e grazie per la presentazione :)

Guglielmo
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 24, 2016, 11:37 pm
Ciao Cina, è un piacere conoscerti e ricevere cosi' tanti complimenti :)

Come ti trovi a simulare PJON con Proteus?

Un utente russo ha creato una issue a riguardo dicendo che in un certa configurazione riceve un errore.

Molti utenti me compreso hanno cavi di decine di metri con dozzine di devices con strategia SoftwareBitBang, altri usando lo stesso numero di device con strategia ThroughSerial e i modulini RS485 o radio.

Dai uno sguardo a questo progetto molto interessante chiamato ModuleInterface, che permette di creare una sorta di session tra un master e degli slave con una configurazione molto flessibile e chiara: https://github.com/fredilarsen/ModuleInterface (https://github.com/fredilarsen/ModuleInterface).

Franketto, ho terminato di implementare l'ack asyncrono e il pattern di ack ricorsivo funziona  :)
Ora mi sono reso conto che ho raggiunto il momento in cui il file PJON.h va splittato in PJONCore dove includere solo la parte di ricezione invio e parsing e in PJON.h dove mettere la parte di handling dei pacchetti, per readability ma soprattutto per permettere in alcuni use case di poter includere solo il necessario e risparmiare memoria. Per colpa di cio' ho dovuto delayare la tua richiesta a questo week end dove spero di poter metterci le mani pre prossima release e includere il fix.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Nov 25, 2016, 03:05 pm
Forse il problema potrebbe essere questo:
Code: [Select]

#define THROUGH_SERIAL_MAX_BYTE_TIME        10000  // Wait up to 10 milliseconds for an incoming byte
#define THROUGH_SERIAL_FREE_TIME_BEFORE_START 500  // 0.5 milliseconds of free channell before sending


Come puoi vedere dal codice, un eventuale altro trasmettitore non aspetta il tempo massimo possibile che potrebbe intercorrere tra trasmissione del pacchetto e trasmissione dell'ack, dovuto ai tempi di latenza e calcolo del CRC e imposto da THROUGH_SERIAL_MAX_BYTE_TIME (vedi receive_response e quindi receive_byte). La soluzione mi sembra potrebbe essere fare in modo che il tempo che deve intercorrere tra l'ultimo carattere ricevuto e il tempo attuale debba essere almeno uguale a THROUGH_SERIAL_MAX_BYTE_TIME prima di trasmettere quindi, consiglio di settare a 10000 THROUGH_SERIAL_FREE_TIME_BEFORE_START ed eseguire un test  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Nov 25, 2016, 07:19 pm
Grazie gbm.
Ho sfogliato un po il ModuleInterface e forse fa al caso mio.
Devo per studiarlo meglio in quanto mi sembra che la base e sempre la tua PJON e quella avevo iniziato a capirla, invece altro devo vedere come fare...
Ero quasi più contento di usare solo la Tua lib.  ;) .
Proteus lo uso da un pò perchè ha un ottimo simulatore per arduino.
Prima dovevo fare vari collegamenti e saldature HW, per ogni modifica del codice o altro ...
Adesso con Proteus disegno tutto e lavoro come se avessi collegati vari arduino, LCD, sensori e altro e poi quando tutto funziona semplicemente costruisco e riverso sul HW.

Tempo fa avevo già fatto un sistema che con un Arduino Nano e ESP866-12 comunicando tra loro eseguivano certe azioni via wifi ...
Volevo usare la tua lib, ma non era disponibile per ESP. Adesso che lo e vedo di usarla :) 

Se riesco fare qualcosa di interessante lo posto qui.

Con la Tua libreria , hai ragione, in alcuni casi Arduino Ide lo compila bene, invece nel Proteus si blocca.
Non capisco il x che ...
Appena ho più info ti scrivo.

Quella che dicevi a Franketto mi sembra una buona idea, perchè adesso la library sta occupando sempre + memoria...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Nov 26, 2016, 06:47 pm
Ciao Cina, grazie, concordo anch'io sulla disponibilità di gbm: risponde sempre impeccabilmente :)
Adesso vediamo se riusciamo a risolvere questo bug via PM...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 03, 2016, 03:48 pm
Rilasciata finalmente la versione 6.1 (https://github.com/gioblu/PJON/releases/tag/6.1) che include l'implementatione dell'acknowledge ricorsivo. Cosa ne pensate di questo nuovo pattern proposto? Da parte mia, grazie alla presenza duplice di ack sincrono ed asincrono, sembra essere piu' efficiente del pattern proposto da altri protocolli, come per esempio Ethernet.

Riguardo la issue riportata da franketto con ThroughSerial, sembra necessario avere un tempo massimo di wait di un byte non inferiore al delay piu' lungo inserito nello sketch, sto predisponendo ora alcuni test per chiarificare la questione una volta per tutte
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 03, 2016, 09:00 pm
Ciao gbm, finalmente ci siamo con l'agognato ACK async ;)

Ho cominciato a provarla:
1) con un uso normale (senza delay nel loop), funziona bene. Bravo! Però per ora ho provato solo un messaggio alla volta in multimaster: proverò più avanti un broadcast con uso normale senza delay.

2) ho provato il problema del delay (col solito codice che ti ho già postato sia per la nano che per la Mega)... Qui le note dolenti :)
2a)  è migliorato perché non fa più raffiche di relé on/off, cioè effettivamente esegue il comando che gli arriva una sola volta. ottimo! Provato con delay 300, 1000.
Però... purtroppo, salendo col delay, tipo con 3000 succede anche che continua a fare on/off ripetuti per un po'. A volte, inoltre, non riceve neppure il messaggio e quindi non agisce sul relé e neppure dà messaggio errore lost.
2b) però... ad esempio nel receive della nano, avevo messo anche l'invio di un messaggio di risposta sul bus: quasi sempre non arriva alla Mega! Senza il messaggio, fa solo gli errori di 2a
2c) inoltre dopo aver acceso/spento il relé, la Mega mi comunica il messaggio di errore di aver perso la nano dal bus: lost. Anche se comunque se poi reinvio un altro messaggio la vede ancora e poi ripete il lost.

Insomma... non ci siamo ancora per il bug del delay.
Coraggio, che prima o poi lo eliminiamo ;)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 03, 2016, 09:52 pm
Provato il broadcast async con 1 Mega e 2 nano: perfetto!! Bravissimo!

Funziona anche con il reinvio da parte di ciascuna nano di un messaggio di risposta. Il relè fa on/off una volta sola.
Meglio di così...



(Ovviamente con delay, non funziona bene... ma quello è un altro problema)
Anche se la 2° nano inserita, non mi ha dato errori di CONNECTION_LOST come la 1° (??)

Scusate, ma c'è nessun altro che può provare questo bug del delay?
Abbiamo scoperto che non era un problema della lib capacitiva, ma semplicemente che la PJON ha un problema a gestire la ricezione di messaggi se il loop impiega un po' di tempo nel loop.
Per cui per fare un test di questo bug, basta aggiungere al loop solo questa riga:
delay(1000); // o più alto

Poi, io, per valutare meglio il problema avevo collegato un relé da far accendere o spegnere ad ogni ricezione del messaggio: se il messaggio viene ricevuto correttamente, il relè si aziona una sola volta, altrimenti vedi messaggio precedente per gli errori.
Il dubbio è che l'errore si manifesti solo con l'uso della RS485... qualcun altro può provare? Sia con Rs485 che con altre strategie?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Dec 04, 2016, 06:11 pm
Ciao Franketto. Io posso forse provare il tutto nel modo 'virtuale' con Proteus. Se mi mandi la tua configurazione HW e il codice posso disegnare e provare quello che vuoi ... Di solito questo simulatore fa esatamente quello che in realta acade...
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 05, 2016, 09:17 am
Ciao Cina, mah non so se riesce a simulare una schedina RS485??
Comunque, appunto l'HW sono 2 Arduini con il pin 2 collegato al DE/RE (2 pin saldati assieme) della schedina RS485 e i pin TX al DI e RX al R0. Non so se sia possibile simularlo...

Per il resto, puoi scaricare la PJON 6.1 e usare negli examples->Network->asyncAck, i due sketches.
In entrambi aggiungi questa riga nel setup:
Code: [Select]
bus.strategy.set_enable_RS485_pin(2);

e nel loop del receiver aggiungi un delay(300); se tutto va bene poi provi anche più alto sui 1000

Per il resto non credo si possa vedere bene l'errore col lampeggio del led che si accende/spegne...
Io modificherei così la funzione receiver_function:
Code: [Select]

if(payload[0] == 'B') {
  
   bus.send(); // qui lo riempi per mandare un messaggio di risposta...

   if (digitalRead(13) == HIGH)
        digitalWrite(13, LOW);
    else
        digitalWrite(13, HIGH);

    delay(500);
  }

In questo modo, quando il codice funziona senza errori, ad ogni ricezione si dovrebbe vedere il led che si accende O si spegne una sola volta per almeno mezzo secondo e chi ha inviato deve mostrare il messaggio di risposta.

Se non funziona, il messaggio non arriva, oppure vede la scheda come lost oppure il led si accende(o si spegne) e poi si rispegne(o si riaccende) perché la ricezione è avvenuta più volte.

Se non simula la RS485, prova a farlo con una strategia diversa, vediamo se lo fa anche lì oppure no.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Dec 05, 2016, 05:42 pm
Freanketto,
ho fatto un pò di prove ... volevo postarle, ma non sono molto pratico...
Comunque la configurazione e come l'hai chiesto ... come vedi da foto.. e sembra che con codice in allegato funziona...
Il led si accende e spegne ...
Ho aggiunto la comunicazione seriale per vedere i due COM ... e funziona...

Con RS485 devo ancora provare in quanto servono resistenze e altro ...
Se trovo il modo posto anche un video della simulazione ...
Se mi consigli come fare, mi aiuti molto :-)



Sotto il codice:

/* Include Async ACK code setting INCLUDE_ASYNC_ACK as true before including PJON.h */
#define INCLUDE_ASYNC_ACK true

#include <Ethernet.h>
#include <SPI.h>
#include <PJON.h>
#include <SoftwareSerial.h>
SoftwareSerial mySerial(11, 10); // RX, TX

uint8_t bus_id[] = {0, 0, 0, 1};

// <Strategy name> bus(selected device id)
//PJON<SoftwareBitBang> bus(bus_id, 44);
PJON<ThroughSerial> bus(bus_id, 44);

void setup() {

  Serial.begin(9600);
  pinModeFast(13, OUTPUT);
  digitalWriteFast(13, LOW); // Initialize LED 13 to be off
  mySerial.begin(9600);
  bus.strategy.set_serial(&mySerial); // Pass the Serial object you want to use for communication
  // bus.strategy.set_pin(12);
  bus.begin();
  bus.set_receiver(receiver_function);
  bus.strategy.set_enable_RS485_pin(2);
  Serial.println("RICEVITORE");
};

void receiver_function(uint8_t *payload, uint16_t length, const PacketInfo &packet_info) {
if(payload[0] == 'B') {
   Serial.println("Arrivato B");
 //  bus.send(); // qui lo riempi per mandare un messaggio di risposta...
// se abbilito questa righa mi da errore
 if (digitalRead(13) == HIGH)
        digitalWrite(13, LOW);
    else
        digitalWrite(13, HIGH);

    delay(500);

 }
}

void loop() {
  bus.update();
  bus.receive(1000);
};


Secondo Arduino:



/* Include Async ACK code setting INCLUDE_ASYNC_ACK as true before including PJON.h */
#define INCLUDE_ASYNC_ACK true
#include <Ethernet.h>
#include <SPI.h>
#include <PJON.h>
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX

uint8_t bus_id[] = {0, 0, 0, 1};

// <Strategy name> bus(selected device id)
//PJON<SoftwareBitBang> bus(bus_id, 44);
PJON<ThroughSerial> bus(bus_id, 43);

void setup() {

Serial.begin(9600);
  pinModeFast(13, OUTPUT);
  digitalWriteFast(13, LOW); // Initialize LED 13 to be off
  mySerial.begin(9600);
  bus.strategy.set_serial(&mySerial); // Pass the Serial object you want to use for communication
// bus.strategy.set_pin(12);
bus.strategy.set_enable_RS485_pin(2);
  /* A packet containing the id of every packet received will be sent back
     by this device to the packet's sender to acknowledge packet reception. */
  bus.set_asynchronous_acknowledge(true);
  bus.begin();
Serial.print("TRASMETITORE");

  bus.send_repeatedly(44, "B", 1, 1000000); // Send B to device 44 every second
}

void loop() {
  bus.update();
  bus.receive(1000);
};


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Dec 05, 2016, 06:09 pm
Franketto, ecco il video  :) fammi sapere se si capisce
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 05, 2016, 07:43 pm
Grazie Cina!
Alcuni consigli/correzioni:

Per il video, ci vuole:
1) una risoluzione maggiore, tipo 1280x720 (o meglio ancora 1920x1080) o/e un maggiore bitrate, cioé una minore compressione: si vedrà meglio, anche se sarà un file più grande... Gioca un po' coi valori fino a un risultato accettabile. Dato che l'upload qui sul forum è solo di 1MB, puoi fare un upload su youtube:lì non hai limiti.

2) il codice, ha un errore:
nel primo ricevitore Arduino, manca la riga nel setup:
Code: [Select]
bus.set_asynchronous_acknowledge(true);
Siccome non è più un solo ricevitore, perché dobbiamo inviare anche da lì dei byte, bisogna mettergli anche a lui l'async. PERO' devi mettere anche nel Trasmettitore una func per la ricezione...

Hai scritto:
Code: [Select]
//  bus.send(); // qui lo riempi per mandare un messaggio di risposta...
// se abbilito questa righa mi da errore

Certo che ti dà errore! ;) Ho scritto infatti che lo devi riempire nel modo giusto...

Ad esempio, se metti all'inizio nel TRASMETTITORE un:
Code: [Select]
PJON<ThroughSerial> bus(3);
poi dovrai mettere un messaggio di risposta nel RICEVITORE, un:
Code: [Select]
bus.send(3,"ricevuto",8);

In sostanza:

Code: [Select]

// TRASMETTITORE:
PJON<ThroughSerial> bus(3);
....
// nel setup:
bus.set_receiver(receiver_function);
....
//nel loop:
bus.send_repeatedly(2, "B", 1, 1000000); // Send B to device   2    every second
....
//creare func:
void receiver_function(uint8_t *payload, uint16_t length, const PacketInfo &packet_info) {

      for (uint8_t i = 0; i < length; i++) {
        Serial.print(payload[i]);
      }
      Serial.println("");

}
....

//RICEVITORE:
PJON<ThroughSerial> bus(2);
....
bus.send(3,"ricevuto",8);
 if (digitalRead(13) == HIGH)
etc.....


3a) Per usare un RS485, non serve usare un bus id, stile Ethernet, per cui invece di

Code: [Select]
uint8_t bus_id[] = {0, 0, 0, 1};
PJON<ThroughSerial> bus(bus_id, 43);


si può scrivere un
Code: [Select]
PJON<ThroughSerial> bus(3);

3b) Se non usi la simulazione corretta del RS485, devi togliere in entrambi la riga corrispondente nel setup:
Code: [Select]
bus.strategy.set_enable_RS485_pin(2);

4) E' vero che ho già messo un delay sul receive, ma il test andrebbe fatto con un delay nel LOOP dell'Arduino ricevitore.




In ogni caso, bravo, continua così.

PS: per postare codice, usa il tag </> in alto a sinistra
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 05, 2016, 08:05 pm
Un'altra cosa:
dato che mettiamo un delay nel loop del ricevitore, e che dobbiamo controllare se ci sono continui errori di ri-invio di pacchetti, meglio fare un send ripetitivo più distanziato nel trasmettitore, tipo:
Code: [Select]
bus.send_repeatedly(2, "B", 1, 8000000); // Send B to device   2    ogni 8 secondi
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Dec 05, 2016, 09:43 pm
Ha,ha,ha... Hai proprio ragione, franketto.
Il video l'ho fatto, ma era 4mb e allora ho diminuito, ma si vedeva pochissimo.
Volevo farti vedere le possibilità, poi sistemeremo ...
Su Youtube devo vedere come fare... Non mi sembrava una cosa importante/ interessante per youtube..
Il codice che ho usato è quello che ho trovato come esempio, addatandolo con tuoi suggerimenti, ma non ho neanche fatto caso che cosa in realtà fa :-)

Questo:
Code: [Select]

uint8_t bus_id[] = {0, 0, 0, 1};
PJON<ThroughSerial> bus(bus_id, 43);

 l'ho lasciato per "non si sà mai"  ;)  ;)

Adesso mi metto e vedo cosa fa il progr., aggiungo i tuoi appunti e poi ti informo sul risultato.

Io stavo sviluppando in realtà un sistema nel quale volevo far comunicare vari arduino nano con un centrale (mega o anche ESP8266) che poi comunicherebbe con un PC in una rete wifi, eventualmente poi connessa a internet in modo che a distanza posso interrogare vari arduino e fargli fare alcune operazioni ...
L' idea era che funzionino indipendentemente, ma che ognuno "sà" cosa fanno i altri ... :-)
Avevo già creato qualcosa di simile con un arduino e un ESP, caricando una pagina web sul ESP, mi mostrava risultati in una serie di manometri e "orologi" per la temperatura ...
Per questo usavo la library "EasyTransfer" ...
Adesso volevo usare la PJON, perché mi sembra molto più versatile ed e anche una simpatica innovazione open source, nel mondo di protocolli.
Certo però che non e facile capire tutto...

Esempio: Volevo collegare i 2 arduino nano con il mega, usando SoftSerial e PJON, ma (ti farò ridere) quando connetto primo con il secondo:
Esempio: D10 a D11 e D11 a D10 (tx-rx e rx -tx) come collego il terzo?? 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 05, 2016, 10:04 pm
Praticamente devi creare un bus, cioè un unico filo (o al massimo 2 se lo vuoi full duplex) al quale tutti i nano si collegano sullo stesso pin, non con Rx e Tx.
Prova a vedere il video (https://www.youtube.com/watch?v=vjc4ZF5own8).
Leggi anche la wiki di PJON.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 05, 2016, 10:07 pm
Questo è ancora più chiaro nell' HW (https://www.youtube.com/watch?v=Y-CRYJ8_Kf0).
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 06, 2016, 01:43 am
Ciao ragazzi, scusate per essermi dilungato, ho appena fixato una piccola inconsistenza in un paio di esempi trovata da un utente estero (mancava una linea di configurazione) e sto cercando di rispondere a tutte le richieste di info / complimenti / flame, ho postato su hackernews questo weekend la nuova release e sono arrivate migliaia di visite... non sapete che piacere mi fa vedere questo thread attivo.

Franketto, sarebbe interessante in effetti invece che consigliare agli utenti di settare un massimo tempo di attesa di un byte, superiore al delay piu' lungo utilizzato nel loro sketch, capire perche' l'ack non viene ricevuto.
Credo pero' che per avere il parere degli altri utenti, forse dovremmo creare un thread dedicato dove chiedere supporto anche dei guru del forum.

Che ne dici? Se si d'accordo domani raccogliamo le idee e lo posto.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 06, 2016, 08:37 am
Quote
ho postato su hackernews
link? questo (https://news.ycombinator.com/item?id=10283028) mi sembra vecchio


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 06, 2016, 12:05 pm
Franketto, sarebbe interessante in effetti invece che consigliare agli utenti di settare un massimo tempo di attesa di un byte, superiore al delay piu' lungo utilizzato nel loro sketch, capire perche' l'ack non viene ricevuto.
Credo pero' che per avere il parere degli altri utenti, forse dovremmo creare un thread dedicato dove chiedere supporto anche dei guru del forum.

Che ne dici? Se si d'accordo domani raccogliamo le idee e lo posto.
Certo, per me va benissimo.

Un altro miglioramento che si potrebbe fare, era quello che avevo suggerito un mesetto fa, di avere una segnalazione di quale nodo non ha risposto a messaggi broadcast. Magari bisognerà fare un array indicando quali nodi sono presenti nel bus e poi controllare se uno non ha risposto.
In effetti non ho capito bene come fa attualmente a capire che un nodo è lost: per un timeout? In ogni caso, in messaggi non broadcast, nel messaggio c'è il nodo di destinazione, per cui si sa che è quello che non ha risposto.
Nel broadcast invece come si fa a saperlo?
Stranamente, come ho scritto sopra, il lost, su un nodo me lo segnala, su un altro no... (però con messaggi normali, non broadcast).
Con una lista dichiarata di nodi forse può essere più sicuro?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 06, 2016, 12:13 pm
Quote
con una lista dichiarata di nodi
forse può essere più sicuro?
secondo me la topologia della
rete dovrebbe essere nota, in
qualche modo.

questa me la segno e vediamo
come evolve :D
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 06, 2016, 12:32 pm
Code: [Select]


[!] show
   A  B  C  D  E  F  G 
A  *  9  -  -  3  -  -
B  9  *  2  -  1  9  -
C  -  2  *  1  1  -  -
D  -  -  1  *  -  3  2
E  3  1  1  -  *  9  -
F  -  9  -  3  9  *  4
G  -  -  -  2  -  4  *
[!] cover_tab show
source = A
node:  from   cost  path
  A:    A      -
  B:    E      4    AEB
  C:    E      4    AEC
  D:    C      5    AECD
  E:    A      3    AE
  F:    D      8    AECDF
  G:    D      7    AECDG
[!] cover_tab show
source = B
node:  from   cost  path
  A:    E      4    BEA
  B:    B      -
  C:    E      2    BEC
  D:    C      3    BECD
  E:    B      1    BE
  F:    D      6    BECDF
  G:    D      5    BECDG
[!] cover_tab show
source = C
node:  from   cost  path
  A:    E      4    CEA
  B:    E      2    CEB
  C:    C      -
  D:    C      1    CD
  E:    C      1    CE
  F:    D      4    CDF
  G:    D      3    CDG
[!] cover_tab show
source = D
node:  from   cost  path
  A:    E      5    DCEA
  B:    E      3    DCEB
  C:    D      1    DC
  D:    D      -
  E:    C      2    DCE
  F:    D      3    DF
  G:    D      2    DG
[!] cover_tab show
source = E
node:  from   cost  path
  A:    E      3    EA
  B:    E      1    EB
  C:    E      1    EC
  D:    C      2    ECD
  E:    E      -
  F:    D      5    ECDF
  G:    D      4    ECDG
[!] cover_tab show
source = F
node:  from   cost  path
  A:    E      8    FDCEA
  B:    E      6    FDCEB
  C:    D      4    FDC
  D:    F      3    FD
  E:    C      5    FDCE
  F:    F      -
  G:    F      4    FG
[!] cover_tab show
source = G
node:  from   cost  path
  A:    E      7    GDCEA
  B:    E      5    GDCEB
  C:    D      3    GDC
  D:    G      2    GD
  E:    C      4    GDCE
  F:    G      4    GF
  G:    G      -



una cosa carina che avevo
implementato nel 2001, al
corso di telematica, e' il
min-path distribuito, dove
ogni nodo si crea la propria
tabella di instradamento a
costo minimo

il costo puo' essere qualsiasi
cosa, sia la capacita' del link
che la distanza in metri, o
il suo livello di traffico medio


la cosa interessante e' che da
questo approccio emerge anche
la topologia della rete :D
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 06, 2016, 05:11 pm
Ciao Franketto, mi sembra proprio strano tu non riceva un error per un device non presente ma per un altro si, perche' la funzionalita' e' una. Sei sicuro che tu non stia manualmente nel tuo sketch filtrando il risultato nella funzione error?

Il messaggio di errore x device non presente viene tirato nel caso in cui un pacchetto con richiesta di acknowledge venga ripetuto 42 volte senza aver ricevuto ACK con un backoff esponenziale di quarto ordine.

Ciao Y888099 sto per iniziare la parte del routing per ora non presente mi farebbe piacere fare due chiacchiere con te a riguardo, vorresti spiegarmi meglio l'implementazione che proponi??

Ciao Cina, grande e' un piacere vedere PJON simulato in Proteus, cosa che non ho mai provato a fare, per ora, il tempo e' sempre poco  :), ma in alcuni casi potrebbe essere comodo per testare alcuni use case scomodi.

Hai ancora problemi di comunicazione con Proteus o con la 6.1 fila tutto liscio?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 06, 2016, 05:44 pm
non propongo nulla :D

dicevo solo che a telematica (ing elettronica
informatica, telecom/A, automatica: corso
comune della triennale) si fanno algoritmi
distribuiti per ricavare la struttura topologica
ottima per il routing; io mi ricordo ben poco,
a parte qualcosa che avevo implementato per
passare il laboratorio ai tempi obbligatorio

quello qui sopra e' il log del mini simulatore
dove la matrice dice come sono connessi i vari
nodi e questi iterativamente si parlando tra di
loro per ricavare ciascuno il path ottimo verso
gli altri nodi quando possibile, ovvero quando
la distanza non e' infinita: { link rotto, caduto,
super congestionato, fisicamente inesistente }

-> che ci siano in giro ancora slide a riassunto
del corso? mumble X_____X
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 06, 2016, 05:46 pm
ti chiedevo un link alla discussioni che
hai fatto su hackernews; con google
non trovo nulla piu' recente di 400 e
rotti giorni fa X____X
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 06, 2016, 06:58 pm
Questo e' il post https://news.ycombinator.com/item?id=13096970 (https://news.ycombinator.com/item?id=13096970) che ho submittato questo week end che ha portato migliaia di visite e mi ha impestato la casella di posta.

Riguardo al routing, sto studiando le varie tecniche preesistenti e sperimentando alcune cose, ma non credo che verra' fuori un pattern rivoluzionario come per esempio IMHO il recursive acknowledgment pattern.
Vediamo  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 06, 2016, 07:22 pm
ciao gbm,
sì, scusa, tra le varie prove, avevo modificato il codice e non lo mandava all'altra nano... lo faceva solo col broadcast...
In ogni caso rimane il fatto che si ha un lost col bug del delay: appunto non arriva l'ack. (però mi pare di ricordare che con gli ack sincroni, non dava neppure messaggio di lost... per cui è un'altra novità)
E rimane l'altro problema di cui avevamo parlato, che con questa implementazione, il broadcast non è ancora sicuro, dato che non sa chi non ha risposto.

Oppure ora lo sa?

Perché tempo fa dicevi:
Quote
3)Un pacchetto broadcast, in un ambiente privo di ACK asincrono, non puo' ricevere un ACK, perche' non c'e' modo che i tanti che ricevono possano organizzarsi su chi deve inviare l'ACK e in ogni caso, l'informazione contenuta in quell'ACK non avrebbe molto valore (chi effettivamente ha ricevuto?).
Ora c'è l'ACK asincrono, ergo...

Io avevo detto:
Quote
Ma allora farai anche un check automatico dietro le quinte per verificare che tutti i nodi abbiano ricevuto? (Avendo settato il numero totale inizialmente). Reinviando poi, sempre in automatico, il messaggio ai nodi che non hanno inviato l'ACK?
Fatta così sarebbe perfetta. Si avrebbe la certezza della ricezione da parte di tutti in automatico. Se non si riesce genera messaggio di errore corrispondente segnalando quale nodo non risponde più: ma allora si capisce che non è più in grado di ricevere nessun messaggio, neppure non broadcast.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 06, 2016, 08:23 pm
Andiamo con ordine.

L'unica bug di cui abbiamo parlato, se non ho capito male e' che se c'e' un delay piu lungo di THROUGH_SERIAL_MAX_BYTE_TIME l'ack non viene ricevuto da parte del trasmettitore e il messaggio viene ripetuto anche se il ricevitore lo riceve, in piu' tu riporti che il messaggio di errore non viene lanciato?

Parlando del pacchetto di broadcast con ack asincrono e' di sicuro una funzionalita' interessante, ci devo pensare un secondo e capire se e come e' possibile implementarla senza ampliare troppo la progmem e la ram.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 06, 2016, 08:37 pm
Quote
in piu' tu riporti che il messaggio di errore non viene lanciato?
Sì, il nano lost con il vecchio ack sincrono era solamente saltuario, non continuo, probabilmente il meccanismo di reinvio del messaggio e i vari ack che non arrivavano bloccavano anche il discorso del lost. O forse lo inviava solo dopo molto tempo e molti tentativi?
Ora invece con l'ack asincrono, il lost avviene per ogni messaggio senza ack ricevuti.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 06, 2016, 09:08 pm
Credo che gli errori saltuari del primo caso fossero causati dai 3 secondi di backoff massimo tra ogni errore sommato ad altri pacchetti che finivano per essere ritrasmessi, sommati al normale traffico della rete o filtro nello sketch, non dovrebbe esserci modo perche' si perda un errore.

Ok devo solo capire la question del delay.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 06, 2016, 11:36 pm
recursive acknowledgment pattern
non ho ancora guardato la faccenda

al momento sono preso con la parte
rete su concentratori in fibra ottica
Base 1000 SX multi modale SC SC
dove ho un sacco di problemi con il
tcp/ip, sopratutto con il congestion
avoidance e lo slow start @___@

appena ho sbolognato questa rogna
guardo meglio la tua lib :D
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Y888099 on Dec 07, 2016, 12:28 am
poi c'e' la questione
del cosa fare quando
si perde un pacchetto
o quando non arriva
un ack: a) Go-Back-N
o b) Selective Repeat
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Dec 07, 2016, 09:19 pm
Ciao Franketto,
vedi che imparo veloce …  :)  :)   ho inserito tag "quote e </>" .. grazie a te!!  :)
Quote
In ogni caso, bravo, continua così.
PS: per postare codice, usa il tag </> in alto a sinistra
Ho provato varie configurazioni, ma mi blocco sempre perché la simulazione non funziona bene.
E probabile che uso la libreria in modo errato, o la connessione non e OK…
Finché si tratta di due Arduino connessi funziona abbastanza bene, quando però connetto il terzo ci sono blocchi …
Per questo ho fatto un semplice esempio e mi chiedo cosa e sbagliato.
Se hai un attimo di tempo verificami se OK, ed eventualmente mi consigli come fare … cosi proseguo con le cose più complesse.
Semplicemente ho connesso il pin D12 di tutti e tre Arduino insieme.
Connessione in allegato:
Ecco i 3 sketch:
1.
Code: [Select]

///
///master ID_42
// TRASMETTITORE iniziale
//
// configurazione HW i tre D12 sono collegati insieme
#define INCLUDE_ASYNC_ACK true

#include <Ethernet.h>
#include <SPI.h>
#include <PJON.h>
//#include <SoftwareSerial.h>
//SoftwareSerial mySerial(11, 10); // RX, TX

uint8_t bus_id[] = {0, 0, 0, 1};

// <Strategy name> bus(selected device id)
PJON<SoftwareBitBang> bus(bus_id, 42);
//PJON<ThroughSerial> bus(bus_id, 42);

void setup() {

  Serial.begin(9600);
  pinModeFast(13, OUTPUT);
  digitalWriteFast(13, LOW); // Initialize LED 13 to be off
  //mySerial.begin(9600);
  //bus.strategy.set_serial(&mySerial); // Pass the Serial object you want to use for communication
 bus.strategy.set_pin(12);
  // bus.strategy.set_enable_RS485_pin(2);
  bus.set_receiver(receiver_function);
  bus.set_asynchronous_acknowledge(true);
  bus.begin();
  Serial.println("SONO TRASMETTITORE");
// se abbilito questo sotto non ricevono niente i due
//bus.send_repeatedly(43, "B", 1, 1500000); // Send B to device 43 every 1.5 second
//bus.send_repeatedly(44, "B", 1, 1000000); // Send B to device 44 every  second
}

void receiver_function(uint8_t *payload, uint16_t length, const PacketInfo &packet_info) {
  if (payload[0] == '4' & payload[1]=='4' ) {
   Serial.println("Risposta ricevuto da 44");}
  if (payload[0] == '4' & payload[1]=='3' ) {
   Serial.println("Risposta ricevuto da 43");}
}

void loop() {
// con questo ricevono il primo "giro" e poi si "impapina" e i due non ricevono più, come neanche trasmettitore
//bus.send(BROADCAST,"B",1);
bus.receive(1000);
bus.update();
}


2.
Code: [Select]

///
//receive 44 - nr1
////
// RICEVITORE iniziale
//
// configurazione HW i tre D12 sono collegati insieme
#define INCLUDE_ASYNC_ACK true

#include <Ethernet.h>
#include <SPI.h>
#include <PJON.h>
//#include <SoftwareSerial.h>
//SoftwareSerial mySerial(10, 11); // RX, TX

uint8_t bus_id[] = {0, 0, 0, 1};

PJON<SoftwareBitBang> bus(bus_id, 44);
//PJON<ThroughSerial> bus(bus_id, 44);

void setup() {

  Serial.begin(9600);
  pinModeFast(13, OUTPUT);
  digitalWriteFast(13, LOW); // Initialize LED 13 to be off
  // mySerial.begin(9600);
  // bus.strategy.set_serial(&mySerial); // Pass the Serial object you want to use for communication
  bus.strategy.set_pin(12);
  bus.set_asynchronous_acknowledge(true);
  bus.begin();
  bus.set_receiver(receiver_function);
  // bus.strategy.set_enable_RS485_pin(2);
  Serial.println("SONO RICEVITORE 44");
}
void receiver_function(uint8_t *payload, uint16_t length, const PacketInfo &packet_info) {
  //Serial.println("Arrivato");

  if (payload[0] == 'B') {
    Serial.println("Arrivato B e rispondo");
    bus.send(42, "44 Ricevuto OK", 14);

    if (digitalRead(13) == HIGH)
      digitalWrite(13, LOW);
    else
      digitalWrite(13, HIGH);
    delay(500);
  }
}

void loop() {
  bus.update();
  bus.receive();
  //bus.receive(1500);
}


3.
Code: [Select]

///
///
//receive 43 - nr2
////
// RICEVITORE iniziale
//
// configurazione HW i tre D12 sono collegati insieme
#define INCLUDE_ASYNC_ACK true

#include <Ethernet.h>
#include <SPI.h>
#include <PJON.h>
//#include <SoftwareSerial.h>
//SoftwareSerial mySerial(10, 11); // RX, TX

uint8_t bus_id[] = {0, 0, 0, 1};

PJON<SoftwareBitBang> bus(bus_id, 43);
//PJON<ThroughSerial> bus(bus_id, 43);

void setup() {

  Serial.begin(9600);
  pinModeFast(13, OUTPUT);
  digitalWriteFast(13, LOW); // Initialize LED 13 to be off
  // mySerial.begin(9600);
  // bus.strategy.set_serial(&mySerial); // Pass the Serial object you want to use for communication
  bus.strategy.set_pin(12);
  bus.set_asynchronous_acknowledge(true);
  bus.begin();
  bus.set_receiver(receiver_function);
  // bus.strategy.set_enable_RS485_pin(2);
  Serial.println("SONO RICEVITORE 43");
}
void receiver_function(uint8_t *payload, uint16_t length, const PacketInfo &packet_info) {
  //Serial.println("Arrivato");

  if (payload[0] == 'B') {
    Serial.println("Arrivato B e rispondo");
    bus.send(42, "43 Ricevuto OK", 14);

    if (digitalRead(13) == HIGH)
      digitalWrite(13, LOW);
    else
      digitalWrite(13, HIGH);
    delay(500);
  }
}

void loop() {
  bus.update();
  bus.receive();
  //bus.receive(1500);
}


Quote
Ciao Cina, grande e' un piacere vedere PJON simulato in Proteus, cosa che non ho mai provato a fare, per ora, il tempo e' sempre poco  :), ma in alcuni casi potrebbe essere comodo per testare alcuni use case scomodi.
Ciao Giovanni,
si la simulazione con Proteus e molto più avanti di qualunque altro simulatore Arduino in "giro".
Puoi x esempio monitorare vari Arduino o altri processori con ognuno il suo terminale e altre "periferiche" (LCD, sensori…)
Vedi esempio che sto testando con il codice sopra …
Penso che sarebbe comodissimo anche x te in quanto in ogni momento puoi mettere in pausa il codice e vedere esattamente ogni variabile, parametro e stringa che "gira" nel circuito di ognuno dei Arduini …
Ci sono un mucchio di esempi inclusi nel programma.
Finora funzionava tutto come nella realtà.
Adesso con la PJON ho un po' di confusione con la connessione, ma spero di risolvere (con aiuto di te, Franketto e altri.. :) ).
La versione 6.1 ha migliorato di molto la compilazione e esecuzione del codice, anche se ogni tanto vengono fuori errori riferiti alla libraria, che forse solo te puoi capire  :)
Questi comunque non bloccano la compilazione.

Credo che il Y888099 potrebbe aiutare molto lo sviluppo ulteriore della lib (GRAZIE in anticipo anche da parte mia)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 10, 2016, 05:30 pm
Ciao Cina,
l'unica cosa che è sbagliata è nel codice 1:
Code: [Select]

if (payload[0] == '4' & payload[1]=='4' ) {
   Serial.println("Risposta ricevuto da 44");}
  if (payload[0] == '4' & payload[1]=='3' ) {
.......


Devi mettere in entrambi un "&&", non un solo "&"

Per il resto mi sembra che vada bene. Al limite puoi provare a togliere all'inizio i 2 delay(500) dopo l'accensione/spegnimento del led 13, dato che quel delay potrebbe appunto essere il bug che blocca il tutto ed è da verificare: prima prova senza nessun delay, poi aggiungilo per testare il presunto bug.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 10, 2016, 06:05 pm
Ciao Cina, dai un occhiata alla documentazione riguardo la ricezione:
https://github.com/gioblu/PJON/blob/master/documentation/data-reception.md (https://github.com/gioblu/PJON/blob/master/documentation/data-reception.md)

Puoi usare:
Code: [Select]
packet_info.sender_id per sapere chi ha inviato il messaggio ricevuto!

Quindi invece di quello che hai scritto che invia 2 bytes sotto forma di stringa o 3 , se vai nelle centinaia, scomodo da gestire dinamicamente, puoi usare
Code: [Select]
if(packet_info.sender_id == 43) ecc..
 che occupa un solo byte (sender id) e fa parte della funzionalita' di PJON!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 10, 2016, 06:20 pm
Facci sapere come vanno i test!

Franketto, oggi sto sistemando una issue aperta da un utente di recente su PJONMaster e PJONSlave, e poi ci sono, totalmente dedicato a sistemare il problema del delay. Questi sono i risultati delle mie analisi. Quello che credo succeda e' che il nostro ricevitore che sta eseguendo il delay, non essendo interrupt driven (e non vogliamo che lo sia o se no sarebbe interrotto da qualsiasi comunicazione nel canale), ricevera' il pacchetto ricevuto (dalla seriale hardware in maniera autonoma e storato nel buffer di serial) mentre lui stava delayndo solo alla fine del delay stesso e alla prossima chiamata della funzione receive. Questo implica che se il tempo di attesa dell'ack e' inferiore al massimo blind time della macchina ricevente o superiore al massimo wait time di altri device prima di trasmettere, c'e' la possibilita' della mancata ricezione dell'ack sincrono o di interferenze third-party. Questo implica che, i device che hanno necessita' di avere lunghi blind time per requirement possono evitare di utilizzare l'ack sincrono e utilizzare il solo ack asincrono come meccanismo di acknowledgment:
Code: [Select]

bus.set_asynchronous_acknowledge(true);
bus.set_synchronous_acknowledge(false);

Una parziale soluzione e' sconsigliare l'uso dei delay e offrire una funzione alternativa interna a PJON dove internamente viene chiamato receive e update per ricezione e invio di messaggi, risolvendo questo problema. Ovviamente alcuni casi limite dove il delay puo' essere lungo piu di un secondo, dove magari la maggiorparte del tempo e' occupato a fare calcoli o leggere sensori,  puo' essere sconsigliabile l'uso dell'ACK sincrono (nel caso particolare della strategia ThroughSerial, perche' SoftwareBigBang e' immune da questo problema).
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 10, 2016, 07:09 pm
Ciao gbm,
ho provato a settare come suggerito sia async true e sync false (prima avevo messo solo async true), ma nulla da fare... anzi è anche peggio di prima, funziona solo il primo comando che accende il relé, poi tutti i successivi o arrivano dopo molti secondi (anche se il delay è di solo 100-200ms) o non arrivano proprio.

Sembra non sia questo il problema, oppure anche l'async ha problemi col delay (basta anche un delay(200) )...

Tra l'altro, NON mi segnala nessun lost, mentre quando comincio a ricaricare un nuovo sketch con l'IDE, allora dopo arrivano i vari messaggi di lost cumulativi quanti messaggi non risposti avevo inviato prima!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 11, 2016, 02:00 pm
Ciao Franketto, per poter avere un risultato coerente al tuo test dovresti assicurarti che tutti i device siano stati aggiornati all'ultima versione, perche' visto lo sviluppo veloce della libreria potresti avere dei device programmati con vecchie versioni non a conoscenza dei nuovi pattern aggiunti di recente come proprio l'asinc ack. Potresti spiegarmi meglio il comportamento di cui parli durante l'upload O_O??
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 11, 2016, 02:17 pm
Ciao gbm, no, tutti i device della prova sono con la stessa versione 6.1, tutti con lo stesso codice di include async all'inizio e nel setup le due righe async true e sync false (l'ultima aggiunta, prima invece era solo la async=true).
Ho inviato alla nano un primo messaggio al quale ha correttamente acceso il relé, poi gli altri messaggi inviati hanno appunto il comportamento anomalo descritto (nessun cambiamento nel relé, oppure dopo molti secondi (nonostante un delay di soli 200ms) ri-riceve il messaggio del relé, accendendolo/spegnendolo anche se non dovrebbe; inoltre nessun messaggio inviato dalla nano alla ricezione del messaggio nella func receive, arriva alla Mega)
MA nessuna connection_lost, anche aspettando *molti* secondi.

Poi, magari cambio il valore del delay nello sketch e faccio upload dall'IDE sulla nano: alla fine dell'upload corretto, mi appaiono tot messaggi connection_lost  da parte della Mega, tanti quanti messaggi avevo inviato prima, con comportamento errato!

Mentre, se non aggiungevo la sync=false, lasciando solo la async=true, prima come già riportato, ad ogni messaggio andato male, mi dava subito, correttamente, il messaggio lost...

Quindi, l'accoppiata async=true e sync=false NON va bene. E sembra quindi che anche l'async da solo abbia problemi (diversi e più gravi) col solito delay.

Comunque, gbm, visto che sembra che al di fuori della RS485, non dia problemi, l'unica è che ti compri due schedine RS485, economiche, per testarlo anche tu ;)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 11, 2016, 02:25 pm
Infatti, purtroppo sembra essere un caso limite di PJON over Serial over RS485 hehe. Le sto comprando ora.

Assicurati di dare un tempo di ricezione da tutte le parti abbastanza lungo da ricevere i messaggi, la chiamata receive() senza parametri prova a ricevere una singola volta, con delay molto lunghi puo' non essere abbastanza da una o piu delle parti.

Che ti appaiano le info del test precedente dopo l'upload del codice sembra piuttosto strano perche' l'errore viene generato da chi invia, quindi chi e' stato appena resettato e riprogrammato!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 11, 2016, 03:26 pm
Quali sono le tue?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 11, 2016, 03:43 pm
Sono come queste:
http://www.ebay.it/itm/Convertitore-TTL-RS485-MAX485-shield-per-arduino-pic-RS-485-ART-CL03-/331263261219?hash=item4d20d43a23:g:F-MAAOSwNSxU7Yjk (http://www.ebay.it/itm/Convertitore-TTL-RS485-MAX485-shield-per-arduino-pic-RS-485-ART-CL03-/331263261219?hash=item4d20d43a23:g:F-MAAOSwNSxU7Yjk)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 12, 2016, 09:27 pm
Oggi ho avuto un po' di tempo per fare un analisi piu' accurata con oscilloscopio e logic analyzer. Grazie al tuo report ho trovato un errore nella gestione del backoff nel caso dei pacchetti con ack asincrono, e' un fix veramente di due righe, pero' creava alcuni problemi, probabilmente quelli di cui ti sei lamentato in uno degli ultimi post, provando il solo asinc ack all'opera. Innanzitutto grazie per aver testato estensivamente la libreria e aver pazientemente riportato i problemi con accuratezza! ecco il commit https://github.com/gioblu/PJON/commit/d08a1ecf4266355de1bdc38aae671600fcfa8ffa (https://github.com/gioblu/PJON/commit/d08a1ecf4266355de1bdc38aae671600fcfa8ffa)

Fammi sapere  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: yakuma on Dec 13, 2016, 09:40 am
Non ho ben capito la differenza tra cio' che chiami ack sincrono e ack asincrono: il sincronismo e' riferito a che cosa ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 13, 2016, 12:24 pm
L'ACK sincrono consiste, dopo la ricezione di un pacchetto, nell'invio di un singolo byte valore 6 in caso di corretta ricezione o 21 in caso di errore.

L'ACK asincrono consiste, dopo la ricezione di un pacchetto, nell'invio di un vero e proprio pacchetto contenente l'indice univoco del pacchetto ricevuto e le info necessarie per confermare la corretta ricezione.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: yakuma on Dec 13, 2016, 01:41 pm
io li avrei chiamati "corto" e "lungo"; "sincrono" fa pensare che sia legato al clock, difatti non si capiva

altra cosa, nella parte PHY faresti molto meglio ad usare la Codifica Manchester NRZ, cosi' puoi usare direttamente anche roba IRDA, che dire che ingolosisce molto per il wireless.

in ogni caso, a parte lo sperimentare e fare roba tua, non ho capito che senso abbia aggiungere nuovi standard a quanto gia' esistente: punti a creare un tuo standard corredato da App e servizi ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 13, 2016, 05:49 pm
Ciao yakuma, l'uso del termine sincrono e asincrono per questo tipo di costrutti e' enormemente usato in informatica e per questo ho scelto questo tipo di nomenclatura. L'acknowledge sincrono viene inviato dal ricevente sincronizzato a un onda quadra generata dal trasmettitore del messaggio, questa esiste per evitare che altri utenti del medium possano decidere di trasmettere nella fase tra trasmissione del pacchetto e trasmissione dell'acknowledge sincrono da parte del ricevente. Il ricevente percepisce l'onda quadra, si sincronizza sull'ultima transizione da 1 a 0 e invia il byte 6 se ha computato CRC correttamente o 21 in caso contrario.

Non sono troppo d'accordo sulla tua proposta a livello di nomenclatura "lungo" "corto".
Il meccanismo dell'acknowledge sincrono e' specificato ed e' parte integrante del physical layer usato di default da PJON che si chiama SoftwareBitBang https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/specification/padded-jittering-protocol-specification-v0.1.md (https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/specification/padded-jittering-protocol-specification-v0.1.md)

Come puoi vedere l'ack sincrono e' una transazione multidirezionale tra due device a livello di byte e non implica l'invio di un pacchetto.

L'ack asincrono invece e' un vero e proprio pacchetto che puo' essere inviato tra reti (permettendo gli hops, cosa che un semplice byte 6 non puo' fare), puo' essere ripetuto se non ricevuto correttamente e cosi' via (vedi ethernet).

La specifica 1.0 del protocol e network layer di PJON contiene un bit dedicato all'encoding del pacchetto:
https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/specification/padded-jittering-protocol-specification-v0.1.md (https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/specification/padded-jittering-protocol-specification-v0.1.md)
Ma non c'e' ancora alcuna implementazione dedicata all'encoding anche se sono d'accordo e' una parte molto interessante e importante.

L' OSI model e' piuttosto datato, e composto da una somma di protocolli incompleti, limitati e realizzati con grande fretta, antiche tecnologie, requirements obsoleti, limiti infrastrutturali non piu' esistenti e soprattutto una topologia totalmente diversa dalla rete di oggi. Sopra di cio' e' stato implementato un layer applicazione e hardware da diverse multinazionali con un fortissimo conflitto di interessi in relazione alla privacy e alla deriva commerciale della rete, generando l'inferno dantesco che e' cio' che fa girare la nostra societa'.

Secondo la mia modesta opinione siamo vicini a un punto in cui scrivere una nuova applicazione sopra a un sistema in avanzato stato di decomposizione non sara' la scelta piu' favorevole. Secondo me la vera innovazione verra' con un nuovo paradigma ideato in tempi piu' recenti osservando gli errori e i limiti della specifica e dell'implementazione dell'OSI attualmente a pieno regime, e con un nuovo paradigma intendo buttare via il grosso e rifare il grosso da capo.

Su app e servizi, credo che per fare qualcosa di nuovo non ci debba essere la deriva o bias commerciale, che ha dimostrato essere un major problem nei vari casi osservati. Quindi per rispondere alla tua domanda su app e servizi, non ho alcuna intenzione di rendere questo progetto una fonte di guadagno per me in questo momento, perche' lo distruggerebbe, quello che vorrei riuscire a fare e' proporre uno Standard piu efficiente di quelli attualmente presenti perche' non mi soddisfano e grazie al cielo la comunita' di github, soprattutto all'estero sta andando fuori per PJON da un anno a questa parte, in maniera molto divisa (c'e' chi e' inorridito e scosso e chi illuminato) e sto ricevendo un sacco di support nel testing ma soprattutto nel development!

Vedo interessante provare a scrivere un implementazione leggibile, e concepibile per un umano che al contrario di quasi tutte non cerchi di nascondere degli 0 days venduti a qualcuno, ma che sia scritta per evitare che ci siano 0 days e che l'utente possa concepirne l'intero funzionamento e possa ricordarlo con facilita' (la base per il successo di uno Standard).
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: yakuma on Dec 13, 2016, 06:24 pm
l'uso del termine sincrono e asincrono per questo tipo di costrutti e' enormemente usato in informatica
si e' usato, ma non ha il significato che hai usato tu, difatti abbiamo letto la tua doc in molti e nessuno ha capito o trovato riferimenti idonei all'ack sincrono descritto come l'hai descritto.

cmq ora e' chiaro.

io avrei riservato un byte fisso da usare per l'ack-corto (opzionale); fare un frame ballerino e' sempre una pessima idea.

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 13, 2016, 06:30 pm
Ciao Yakuma, cosa intendi dire? in che senso non e' usato come lo uso io?
Avete letto la specifica? sono poche pagine ma include dettagliatamente quello che ti ho spiegato:
https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-specification-v1.0.md#basic-concepts (https://github.com/gioblu/PJON/blob/master/specification/PJON-protocol-specification-v1.0.md#basic-concepts)
l'ultima voce della lista basic concepts ti porta alle due speifiche.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 13, 2016, 06:31 pm
Che cos'e' un frame ballerino  :) ??

Utilizzare un byte "fisso" se intendi nel tempo rispetto al pacchetto non si puo' fare, perche' chi computa il crc, dipendentemente da quale crc e quale architettura puo' avere bisogno di piu' o meno tempo per sapere se il pacchetto e' stato ricevuto correttamente e quindi non e' detto che sia in grado di avere il risultato in tempo per rispondere, in piu' inserendolo fisso aggiungeresti 1byte di overhead inutilmente. Per ovviare al problema di temporizzazione dato da latenza e tempo di computazione e' presente l'onda quadra di cui ti parlavo.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: yakuma on Dec 13, 2016, 06:48 pm
grazie al cielo la comunita' di github, soprattutto all'estero sta andando fuori per PJON da un anno a questa parte, in maniera molto divisa
dove posso trovare commenti al riguardo?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 13, 2016, 06:55 pm
L'effettivo risultato del supporto della comunita' e' fruibile sul repository di github, dove in genere io gestisco molta della conversazione con i supporters tramite le issues. Infatti volevo consigliarti, se vuoi proporre delle aggiunte o riportare un' inconsistenza / qualcosa che ritieni incoerente o che puo' essere migliorata puoi farlo anche li: https://github.com/gioblu/PJON/issues (https://github.com/gioblu/PJON/issues) piu' che altro cosi' e' possibile che anche gli altri utenti della comunita' leggano la tua opinione e la supportino se valida.

Nell' header del file di PJON trovi una lista dei major contributors e delle bug riportate dalla comunita'.

Ah e dimenticavo nella wiki c'e' una lista delle pubblicazioni riguardo PJON.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 13, 2016, 10:00 pm
Eccomi qua :)

Allora, piano piano la cosa sta migliorando.

Dalle mie prove, usando l'ultimo codice e async=true + sync=false, il delay non dà più problemi in RICEZIONE! Nel senso che riceve ed esegue solo una volta.
Però, continua ad esserci un problema di ack, penso, perché *ogni* invio mi dà, dopo i 3 secondi, connection_lost (anche se il messaggio è stato ricevuto ed eseguito correttamente)...
Se non altro hai risolto il mancato lost nei messaggi e i vari messaggi lost al nuovo upload dell'ide, ok.

Inoltre, se alla ricezione, eseguo un INVIO, non arriva alla Mega... in tempi accettabili. O addirittura non arriva.
Ho messo un receive(6000) su entrambe e provato con delay anche fino a 2500.

Es:
receive6000
delay2000
il messaggio inviato in risposta al receive impiega 17secondi per arrivare alla Mega!! (E quindi lo mostra molto dopo il solito lost dopo i 3secondi)

Con delay più "normali"
receive6000
delay200
il messaggio inviato in risposta al receive impiega 5 secondi per arrivare alla Mega. E a volte, appunto non arriva.

Questo aspettando con calma che arrivino...
Se invece faccio più invii senza aspettare i suoi comodi, perde proprio alcune risposte.

Anche con async=true senza il sync=false, idem: lost ogni volta e niente messaggi di risposta o rari.

Quindi... ancora non ci siamo del tutto.


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 15, 2016, 07:34 pm
allora, ho fatto un po' di ricerca, test e chiesto inutilmente aiuto al forum inglese.
Da parte mia il problema e' solo questo:

se tu metti un delay di 1 secondo e un massimo tempo di attesa di mezzo hai buone probabilita' che il pacchetto sia ricevuto dalla seriale hardware mentre il processore sta eseguendo il delay e il limite di tempo massimo di attesa dell'ack viene superato, il messaggio recepito dal ricevitore ma l'ack perso. per evitare questo problema basta che l'intervallo medio tra ogni chiamata a receive non superi il tempo massimo di attesa, oppure se questo e' necessario per requirement,  usare l'asinc ack!

Il problema 2 e' che se il tempo di attesa prima di trasmettere e' stato settato minore del tempo di attesa di un byte e' possibile che un terzo device decida di iniziare a trasmettere la in mezzo rompendo la transazione!

Quindi il tempo di attesa di un byte deve essere sempre INFERIORE al tempo di attesa prima di trasmettere per evitare collisioni. Ovviamente questo vale solo nel caso del multi-master, in master slave non il tempo prima di trasmettere puo' essere azzerato. Quindi, questi tempi dipendono molto dal tipo di utilizzo.Forse potrebbe essere sensato aggiungere dei setter per evitare l'uso dei define che in questo caso sono inutili.

Sto scrivendo documentazione a riguardo e sto effettuando i necessari change alla configurazione di default.

Tu che configurazione metteresti di default??
Forse dovrei proporre commentata anche la conf master-slave
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 15, 2016, 09:19 pm
Io opterei per una configurazione, la più sicura e la più automatica, nonché la più semplice per l'utente.
Quindi metterei di default l'async e, al massimo, un setter in cui mettere il tempo di attesa di un byte. Poi il prog dovrebbe calcolarsi automaticamente un valore un po' più alto per il send. Ma metterei già di default un tempo max su 1 secondo, per andare sul sicuro. Sì, è tanto, ma se appunto usi una libreria tipo la capacitiva, fai presto a raggiungere timing alti quando tocchi il pulsante.

Già questo però lo vedo una limitazione per un utente "medio" che non so quanto avrà voglia/saprà calcolarsi/provare vari timing...
Voglio dire, non so gli altri protocolli come facciano, ma visto che mi sembra facciano tutto in automatico, bisognerebbe imitarli in questo.

Oppure meglio di tutto, inventarsi un meccanismo di automazione nel calcolo dei delay effettivi di un loop.
Ad es. potresti creare una func per calcolare quanto impiega ogni ciclo di loop e settare in automatico un timing "personalizzato". L'ideale sarebbe fare sempre un check di quanto impiega ogni loop e aggiornare il valore del timing al valore massimo registrato + qualcosa (e aggiornare automaticamente anche il send correttamente)!
Così dovremmo essere sempre "coperti".

Per il multimaster (direi irrinunciabile) idem, settare il valore di send a seconda del valore di receive appena calcolato.
Però non mi è ancora ben chiaro quanto incidono questi timing... E' solo un valore max di attesa (e quindi non dovrebbe influire sulle prestazioni) oppure, come temo, rallenta anche le prestazioni effettive di sending dato che deve sempre attendere l'attesa massima, prima di inviare? Spero almeno che, una volta arrivato l'ack, possa iniziare subito il send...


In  ogni caso, lo sto testando con la famosa capacitive:
receive6000
solo async
timing 1000000//500

Avendo messo un timing max alto, non mi dà più connection_lost, riceve correttamente una sola volta, e anche riesce a fare un send oltre che ricevere, quando serve.
PERO' c'è ancora qualche problema coi send: ad es. in una funzione avevo messo due invii consecutivi distanziati da poco delay, tipo:
bus.send(1, data1, 4);
delay(20);
bus.send(1, data2, 4);

Il data1 arriva sempre, mentre il data2 non arriva quasi mai, solo pochissime volte. Però non mi dà mai nessun messaggio di lost.
Tra l'altro, come si fa a sapere se un messaggio non arriva? Dovrebbe segnalare un ack mancante con messaggio di connection_lost (dopo i famosi 3s), anche se gli altri messaggi arrivano correttamente?
Cioè, magari dovrebbe inviare un lost per il data2, ma siccome gli arriva il data1 pensa che il nodo sia funzionante?
In ogni caso, così non è ancora una trasmissione sicura, né c'è il controllo corretto degli errori.
Oppure appunto devo settare il timing di send a, tipo 1000000//1100000, però non vorrei come detto sopra che rallentasse ogni invio...
Però questo che hai detto, lo hai ipotizzato per più di 2 device in multimaster, qui invece è sempre lo stesso nodo che invia... quindi non dovrebbe avere questi problemi.

PS
Ti sono arrivate le schedine RS485? Attendo i tuoi test su RS ;)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 16, 2016, 10:45 am
!!!!!   ATTENZIONE !!!!!!

Modificando i valori di default dei timing da 10000/500 a per es. 1000000/500, la normale funzionalità di Arduino non va più !!! Sia in sync che in async.
Mi ha fatto *impazzire* per capire cosa c'era che non andava (viste tutte le varie prove fatte non ricordavo più l'ultima modifica e poi non pensavo fosse PJON)....

Ad es. non è più in grado di accorgersi di bottoni meccanici premuti etc...

Per cui, purtroppo, PJON fuori dai timing di default NON è usabile! Ma allora rimangono i problemi del delay!!...

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 16, 2016, 07:24 pm
Ciao Franketto, ho cercato di documentare meglio il problema negli ultimi commit, vedi: https://github.com/gioblu/PJON/tree/master/strategies/ThroughSerial (https://github.com/gioblu/PJON/tree/master/strategies/ThroughSerial)

Il problema che lamentavi di mancanza dell'errore non e' una mancanza dell'errore, ho fatto tutti i test e gli errori ci sono, sono solo postposti nel tempo per colpa del tempo massimo di attesa, e PJON sopra la strategy prova 42 volte a mandarlo, ma se puo' mandarne al massimo 1 al secondo (se setti 1 secondo di tempo prima di poter trasmettere) ci vogliono 42 secondi!

La Seriale hardware non permette il set manuale dei pin, il che non mi permette di ri-implementare cio' che SoftwareBitBang offre tra le sue features, cioe' l'ack sincrono. Nel caso della serial (come nel caso della strategia EthernetTCP https://github.com/gioblu/PJON/blob/master/strategies/EthernetTCP/EthernetTCP.h#L79 (https://github.com/gioblu/PJON/blob/master/strategies/EthernetTCP/EthernetTCP.h#L79), credo che forse sia meglio sconsigliarne l'uso e o disabilitarla del tutto e portare l'utente ad optare per l'async ACK e riportare il setup di default a valori piu' ridotti. Tu cosa ne dici?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 16, 2016, 09:02 pm
Ciao gbm,

1) Per l'errore mancante di messaggio non arrivato, ha un codice particolare? Negli esempi ho visto solo il "CONNECTION_LOST" e altri due di PACKETS_BUFFER_FULL o CONTENT_TOO_LONG.
Ma, in ogni caso, ho rifatto la prova (async puro) con i timing di default e su 15xdata1, sono arrivati solo 2xdata2 e nessun errore segnalato dalla Mega. (mentre se c'è un connection_lost o buffer full o content too long me lo segnala). In sostanza ha perso 13 messaggi e non mi ha detto nulla (ho aspettato a lungo per vedere se appariva qualcosa: niente).
Quindi mi pare che qualcosa non funzioni... In ogni caso si perdono messaggi anche in configurazione con timing di default: non va bene.

2) Per il sync: sicuramente meglio non rischiare con il sync se può non funzionare bene (con i casi di delay), meglio usare solo l'async di default, come ti suggerivo sopra. Vanno bene pure i timing di default.
MA allora bisogna che disabiliti il valore del max time, perché mettiamo che uno lo abbia settato alto per qualche motivo usando il sync, se poi lascia un valore alto, così com'è ora, anche se hai settato async=true e sync=false, PJON blocca il loop di Arduino, anche se non ne ha bisogna perché lavora in async!!
Per cui devi fare in modo che quando sync=false, deve ignorare i timing settati (che dovrebbero servire appunto solo per il sync).
Infatti, come ti ho scritto sopra, anche se lavoravo in async puro, lo stesso il loop veniva bloccato per il max time di 1000000. Il che non va bene.
In ogni caso il testo scritto nella wiki non va bene, perché suggerisci di alzare i timing di default per la sync, ma se li alzi blocca il loop e non è più usabile...: non è una soluzione.

3) Adesso sto provando coi classici 10000/500 in async puro e mi sembra vada abbastanza bene con la capacitiva.
Però, come segnalato sopra, spesso dà connection_lost dopo i 3s anche se ha ricevuto (e inviato) correttamente.
Con un leggero delay aggiuntivo, tipo 200/300ms, si blocca proprio... Quindi anche se si lavora in async puro, rimane il problema del delay.

4) o usare un interrupt per effettuare update e receive molto spesso senza interrompere il loop. Però nascono problemi se uno ne usa già a causa di altre lib (io ne uso già 2 (servo e 38kHz), per cui non credo potrei usarne di più...)

5) oppure non si potrebbe cambiare approccio con la RS485 e fare come il rolling master della lib di gammon? Con uno slot time fisso per ogni nodo, nel quale solo l'x nodo può parlare e gli altri ascoltano? Si evitano i conflitti, si sa quando qualcuno trasmette etc
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 16, 2016, 09:48 pm
Ciao Franketto, il codice se un pacchetto non arriva e' CONNECTION_LOST.
Di conseguenza quello che dici credo sia fuorviato dalla mancanza di questa info.

In qualsiasi caso, l'errore connection lost viene tirato se superati i MAX_ATTEMPTS.
Considera che mettendo delay alti avrai come ti ho spiegato tempi di consegna lunghi, che moltiplicati per 42 potrebbero nascondere l'errore. Per evitare il problema, puoi settare MAX_ATTEMPTS a un numero molto basso se usi delay molto lunghi per ottenere l'errore prima.

2) Hai assolutamente ragione riguardo al timing lungo di default che puo' creare problemi e per il testo della documentazione, sistemo grazie.

Stai usando PJONMaster e PJONSlave o la classe PJON base?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 16, 2016, 09:51 pm
In ogni caso io proverei:
- sync ack, tempi alti MAX_ATTEMPTS 3 vedrai che ti salta fuori l'errore e dovrebbe funzionare
- async ack potrebbe aiutare ridurre i tempi.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 16, 2016, 09:59 pm
Nel caso di serial, essendo interrupt driven difficilmente si parla di dover ritrasmettere perche' il messaggio arriva "sempre" dall'altra parte, quindi in questo caso potrebbe avere senso settare di ritrasmetterlo un massimo di 3 volte (potenziali interferenze durante la trasmissione)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 16, 2016, 10:52 pm
No, nell' error_handler avevo già quel codice di errore "CONNECTION_LOST", per cui se fosse arrivato me lo avrebbe mostrato (come infatti me lo mostra in altre occasioni come riportato sopra).

Allora, ho ridotto a 3 Max_attempts usando solo ack async, ma come detto, ora uso i timing di default, quindi non lunghi, NON ricevo nessun errore: 25xdata1, 7xdata2 e nessun messaggio di errore dalla Mega.
Detto questo, non che sia così importante che IO veda l'errore, quello che conta è che LUI si accorga che dei messaggi non sono arrivati e che quindi li debba reinviare (credo che finché non riceve l'ack dell'avvenuta ricezione li tenga in memoria, no?), cosa che evidentemente non fa. Se poi dici che arrivano di sicuro, bhé allora come mai non li "prende"?: dovrebbero essere nel buffer della seriale HW.

A me, con una seriale (lenta a 9600) dà quello che ti ho detto.

EDIT: ho provato con un 115200: funziona meglio, ma non perfetto!
Anche se non perfetto: 39xdata1, 14xdata2+22xlost ,ne  mancano  però 25
altro test 15xdata1, 9xdata2 + 15lost, mancano 6
(rimettendo max_attempts = 42, ho 15xdata1 e 3xdata2 + 16lost, mancano 12)

Comunque così almeno è "vivo"... il problema era la velocità della seriale a 9600!! Da tenere presente anche questo.

Ho provato con un solo send, invece di due vicini: lo stesso... Ha perso almeno 9 messaggi su 31 con 27lost. Inoltre ne sono arrivati 2 uguali.

Il log:
110, xxx = numeri progressivi dei messaggi
253, 2    =  lost nano n° 2

Quote
Pc riceve:   110,1
Pc riceve:   110,2
Pc riceve:   110,6
Pc riceve:   253,2
Pc riceve:   110,4
Pc riceve:   110,9
Pc riceve:   253,2
Pc riceve:   110,8
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,5
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,11
Pc riceve:   253,2
Pc riceve:   110,10
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,14
Pc riceve:   253,2
Pc riceve:   110,13
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,17
Pc riceve:   253,2
Pc riceve:   110,16
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,20
Pc riceve:   253,2
Pc riceve:   110,19
Pc riceve:   110,9
Pc riceve:   253,2
Pc riceve:   110,8
Pc riceve:   253,2
Pc riceve:   110,23
Pc riceve:   253,2
Pc riceve:   110,22
Pc riceve:   110,5
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,26
Pc riceve:   253,2
Pc riceve:   110,25
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,29
Pc riceve:   253,2
Pc riceve:   110,28
Pc riceve:   253,2
Pc riceve:   253,2
Pc riceve:   110,31
Fatto sta che rimane il problema che si accorge che c'è qualcosa che non va con qualche messaggio ma non riesce a recuperarli dal buffer della Mega, o non sono proprio partiti come send dalla nano? Comunque non va ancora bene, perdere tutti questi messaggi.



Uso la classe Pjon normale, #include <PJON.h>

Se faccio multimaster devo usare quella no?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 12:05 am
Leggendo il codice mi sembra impossibile possa perdersi un errore.
Quello che puo' succedere e' che temporaneamente il buffer puo' riempirsi per colpa di un interferenza / collisione e quindi un pacchetto non inviato e l'errore packets buffer full tirato.

Prova a mandarti un valore crescente da incrementare a ogni giro, almeno sei sicuro
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: dally on Dec 17, 2016, 01:02 am
@gbm
hai scritto che lo stato dell'arte attuale non ti soddisfa, c'e' da qualche parte una critica dettagliata di cosa hai considerato e di cosa non ti soddisfa ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 02:19 am
Ciao daily, quello su cui stiamo lavorando e' prettamente non disponibile e non vedo alternative indicabili per comparison, almeno attualmente. Intendo, alcune delle funzionalita' di PJON non sono disponibili in Ethernet (come il sinc ack o il recursive acknowledgment pattern) e altre esistono in entrambe ma sono implementate diversamente. Quello che posso fare e' farti una lista delle cose che mi mancavano e che mi hanno portato a iniziare a lavorare a PJON ormai anni fa quando era all'universita' :'(.

- Un protocollo arduino compatibile con un implementazione capace di trasmettere sempre lo stesso protocol layer, switchando con estrema facilita' il data link layer (ci stiamo lavorando, PJON ThroughSerial over RS485 di cui puoi leggere qui sopra, e' un caso limite un po' ostico)

- Un protocollo semplice da usare che supporti piu' feature e che sia abbastanza universale da coprire molti dei possibili use cases, la cui implementazione possa essere istanziata in parallelo con diversi data link layers senza problemi e occupando poca memoria anche grazie al CRTP e in generale all'uso dei template. Che supporti crc8 o crc32, pacchetti di al massimo 256 o 65535 bytes, indicizzazione dei device a uno o due livelli (device e gruppo), ma cosi' ti sto fondamentalmente sintetizzando la specifica  :) 

- Un data link layer (SoftwareBitBang) compatibile con le schede piu' utilizzate (connette due arduino nano con 3.35kB/s di banda su un singolo filo senza alcun hardware aggiuntivo). che non necessiti di interrupt, che supporti fino a 255 device su uno o piu fili, o miliardi (in un network di bus) e che integri la feature di acknowledge sincrono.

- Un pattern di acknowledgment asincrono totalmente nuovo chiamato recursive acknowledgment pattern.

- Implementazione scritta in modo che possa essere capita e letta e non perche' il meccanismo sia difficile da comprendere o perche' qualche bug rimanga dov'e'.

- Aspetto didattico (per me) e per l'utente, che puo' creare una rete e configurarla nei minimi dettagli secondo i tuoi requirements, configurando il contenuto del pacchetto, grazie all'header (in modo tale da ridurre al minimo l'overhead). i tempi di invio e ricezione ma soprattutto le reazioni a determinate ricezioni con un pratico sistema a callback.

Non per ultima, cosa molto importante, PJON e' stato specificato in modo che n bus configurati diversamente possano condividire il medium di comunicazione senza collisioni e/o cooperare attivamente alla creazione di un network di bus.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 02:47 am
Ok, franketto, per la storia dell'errore dilungato nel tempo esiste un fix possibile piuttosto semplice che faro' in ogni caso questa sera, grazie del tuo report e dell'insistenza  :)

Farei in modo che se per colpa di una configurazione estrema dell'utente come in questo caso particolare, l' errore venga emesso allo scadere del tempo limite, anche se non essendoci stato il tempo fisico, non e' stata effettuata potenzialmente, alcuna ripetizione. Sei d'accordo? Di fatto in ogni caso questo e' un bug report, grazie ancora.

Per il resto non potendo vedere il tuo sketch non posso dirti molto di piu' che proverei a spedirmi una variabile che continuerei incrementare ad ogni invio e proverei a stamparmi il packet id per accertarmi se effettivamente possa essere ricevuto due volte lo stesso pacchetto.

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Dec 17, 2016, 10:19 am
1) La prova era già con una variabile incrementale inviata ad ogni ciclo...
Una cosa semplice come:

Code: [Select]

  if (count < 30) {
       count++;
       uint8_t data3[2] ={110,count};
       bus.send(1, data3, 2);
  }


Rifatto upload alla Mega e messa seriale 38400 sembra bene. Vediamo come va.
E' normale che a volte mostri prima un messaggio in realtà inviato dopo?
tipo invio 2, 3, 4, 5, 6 lui stampa nel monitor seriale 2, 4, 3, 5, 6.

2) Comunque, confermo che, con un delay di circa soli 120ms dovuto alla lib capacitiva, quando invio un comando, lo riceve, nella func receive della nano c'è anche un messaggio di risposta, lo invia, c'è un lost, poi il messaggio arriva correttamente oppure a volte, più grave, non arriva proprio.
Questi lost non dovrebbero esserci, sono dovuti al delay!! Senza delay tutto ok. Async ack solo.
Mentre se c'è solo invio continuo da parte della nano (tipo la sequenza sopra), non ci sono messaggi lost, anche col delay.
Col delay, quello che li fa è la combinazione ricevo-invio subito dopo, mentre il solo ricevo o il solo invio sembrano andare bene.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 01:35 pm
Grazie franketto :)! Oggi sistemo:

Dopo di che mi dedico al tuo ultimo report. Riguardo l'ordine PJON non supporta l'invio ordinato di default.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: dally on Dec 17, 2016, 02:49 pm
secondo me ti sei documentato poco, sei partito in quarta con il facciamo; se ti fossi preoccupato di guardare nel mondo dei PLC industriali avresti visto che esiste p.e. EtherCat (https://en.wikipedia.org/wiki/EtherCAT) da diversi lustri, utilizza il PHY ethernet 100BASE-T (volendo anche fibra ottica), cosa che per altro e' fruibile al lato pratico (=$$$) perche' da una parte porta garanzie solide e dall'altra fa risparmiare di costi di installazione e sviluppo, usando per altro comune macchine linux come master, macinini 8-16-32 bit come nodi, e normali cavi CAT5, a cui altro garantisce specifiche soft real time.

E' stra-ottimo per il mondo delle macchine industriali e qualcuno ha iniziato ad usarlo anche in demotica, sicche' rispetto ad EtherCat (studiarlo, usarlo), che vantaggi concreti ha ripartire da zero con PJON ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 03:30 pm
Mi fa piacere sapere che tu conosca quanto io mi sia documentato e quanto approfonditamente.

EtherCat e' piuttosto conosciuto e non e' per niente mal fatto, sono d'accordo. Ma, come spesso succede, in analisi di questo tipo, non dimenticarti dei requirements di cui mi hai chiesto info e che ti ho descritto.



Secondo me soprattutto in un progetto di domotica non ha alcun senso ed anzi e' ogni giorno piu' rischioso utilizzare Ethernet. In ogni caso, rispetto la tua opinione senza speculare sulle tue reali capacita' e conoscenze tecniche.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: dally on Dec 17, 2016, 05:49 pm
EtherCat e' piuttosto conosciuto
Parlavi di "ethernet" quando criticavi l'attuale stato dell'arte. EtherCat l'ho citato io, perche' ci lavoro spesso sui PLC, controllo motori, pistoni, servi, tutto in softreal time, ho diverse possibilita' di topologia e non ho mai somatizzato alcun problema ne limitazione da spingermi a cercare una diversa soluzione.

Ho letto PJON dal foro, e guardato un po' la doc, e non mi ha colpito, per nulla perche' oggettivamente non vedo nessuna innovazione, nessun vantaggio, l'ennesimo progettino didattico che .. e' appunto un progettino didattico, mentre tu qui sopra lo dipingi come una roba rivoluzionaria. Ack sincroni. Evabbe.

Nell'ultima fiera dell'automazione in Germania (Ottobre 2016) EtherCat e' stato definito da tutti come *LA* soluzione industriale di riferimento: tutti sanno sanno cosa sia, tutti lo usano, tutti lo implementano, non trovi un PLC che non lo abbia a corredo, ci sono librerie che girano su diverse MPU, ci sono tonnellate di tools di analisi, c'e' pure supporto per Matlab®, LabView®,  ecc, gira pure su linux, su VxWorks, e gira anche su fibra ottica in ambienti critici

cosa vuoi di piu' :D ?

sopratutto, oggi che le MPU sono a 32 bit, la roba come ColdFire o gli Infineon XM4500 hanno la base-T lan built-in e costano meno di una confezione familiare di pacchetti di patatine


EtherCat e' in grado di funzionare su n medium diversi senza dover cambiare nulla dell'implementazione utilizzando lo stesso codice lato utente?
di base questa domanda non ha alcun senso visto che questa e' una faccenda del tutto applicativa, di fatto lato trasporto gira ovunque giri Ethernet, lato PHY sia base-T che base-SX, addirittura ADFX (quest'ultimo e' usato in avionica, dove lavoro io)

(https://upload.wikimedia.org/wikipedia/commons/0/00/ISO_OSI_Model_for_EtherCAT.png)

ovviamente non gira su wifi, per quello serve altro, ma ha poco senso vista la natura applicativa, o meglio c'e' gia' altro, come e' stato ampiamente spiegato per altro su EEvBlog (http://www.eevblog.com/forum/microcontrollers/souliss-an-open-source-alternative-to-zigbee-and-z-wave/) parlando di protocolli e soluzioni wireless

Quote
Problem: There are 14 competing standards...
Solution: We'll create a new, open standard that encompasses all their abilities!
Problem: There are 15 competing standards…
e mr.Timb l'ha riassunto spassosamente :D

beh, dai, ha ragione, in effetti per la roba wireless e' cosi'


Ethernet e' molto piu' pesante di PJON sia in termini di overhead. che in termini computazionali, di memoria ma soprattutto in termini energetici
Avere Ethernet su ogni nodo IMHO e' stupido, poco efficiente e pericoloso
bah, per me stai parlando di quisquilie ridicole, sopratutto se ti metti a tirare in ballo l'aspetto energetico e l'overhead computazione; guarda che con EtherCat riusciamo a gestire Airbus Test Rig con 1000 nodi per loop e pacchetti elaborati al volo.

Secondo me soprattutto in un progetto di domotica non ha alcun senso ed anzi e' ogni giorno piu' rischioso utilizzare Ethernet
Capisco che lo vuoi motivare perche' e' il *tuo* progetto, nessuno ti dice nulla, pero' non puoi nemmeno fare certe affermazioni se poi non le argomenti con validi motivi in cui dimostri perche' uno dovrebbe usare PJON piuttosto che Ethernet o EtherCAT o altro che tu trovi "non adatto alle tue esigenze".

Te l'hanno detto esplicitamente anche su EEvBlog, e per me ti hanno consigliato bene: dovresti scriverlo nella primissima pagina che introduce PJON.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 07:56 pm
Sono un apprendista pilota privato, grande appassionato di aeronautica e aerospazio, figlio di un pilota ricognitore di f104 credo quindi di avere un minimo di esperienza nell'ambito, piu' che altro inevitabilmente in termini burocratici e legali, e credo, considerando lo stato di maturita' attuale dell'implementazione di PJON, sia prematuro considerare di applicarla nel mondo dell'avionica e poi dai sarebbe un potenziale suicidio professionale e un potenziale omicidio di massa  :) applicare un'implementazione in fase di sviluppo su un oggetto volante. A parte gli scherzi parlando seriamente invece della specifica mi sembra oltremodo ignorante anche solo considerarlo, vista la pila di certificazioni e regole necessarie per poter applicare un sistema di questo tipo nell'ambito. PJON non e' mai stato scrutinato per questo tipo di applicazione e non e' uno Standard in alcun modo certificato o testato (cosa che spesso in questi casi necessita anni), quindi, la tua intera argomentazione non ha alcun senso e mi sembra piu' un flusso di coscienza poco gentile.

Allo stesso modo considerare:
Quote
quisquilie ridicole
(e quindi negare) il fatto che Ethernet sia pesante e complicato da gestire su ogni nodo e' folle:

questo e' un esempio realizzato quasi un anno fa con l'utente del forum mauroZ: https://www.youtube.com/watch?v=Y-CRYJ8_Kf0 (https://www.youtube.com/watch?v=Y-CRYJ8_Kf0), quindi un ambito applicazione piu' vicino al topic, visto che qui, stiamo parlando di arduino, la tua proposta e' quella di aggiungere 15 ethernet shield perche' funzioni meglio e usare EtherCat perche' sia una soluzione piu' elegante ed affidabile? Secondo me ti sbagli. Costerebbe di piu' e sarebbe meno affidabile, tralasciando i problemi pratici legati all'hardware (la ethernetshield in particolare) che affliggono la comunita' e i bug software dei chip che gestiscono ethernet (vedi wiznet), ma soprattutto vogliamo comparare il costo e il consumo di 15 Ethernet shield contro un cavo di rame hehe?

Mi spiace vedere tra le righe un tuo sfogo emotivo contro il mio lavoro e quello di tanti altri contributori al progetto. Sono sicuro che tu abbia ben chiaro che qualsiasi lavoro, parte da un progettino didattico o sperimentale e in genere dipendentemente dalla sua bonta', effettiva efficacia e tenacia nello sviluppo si sedimenta nella societa' come strumento tecnico. Il tempo e il supporto della comunita' rispondera' a molte domande e spero contraddira' molte convinzioni tra cui la tua.


Di conseguenza, la tua convinzione a riguardo mi e' chiara, se hai qualche effettiva critica pratica alla specifica o all'implementazione, sarei felice di poterne usufruire per migliorare questo lavoro aggiungendo parte della tua esperienza in maniera costruttiva.

EDIT: Per favore cerchiamo di non fare disinformazione, il link che hai postato su EEVblog riguarda souliss che e' un altro bellissimo progetto di una persona con cui peraltro ho avuto modo di discutere. Utilizzare meme ritriti di avatar di un forum come comandamenti all'ingegneria e' la piu' grossa forma di ignoranza generalizzata (e rimane in ogni caso un opinione), secondo il mio modesto parere.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: dally on Dec 17, 2016, 08:59 pm
Sono un apprendista pilota privato
questo cosa centra?

sto parlando cio' che ha un perche' nel mondo del lavoro: problema -> soluzione

tu invece stai creando nuovi problemi a cui dare nuove soluzioni

mi sembra oltremodo ignorante anche solo considerarlo, vista la pila di certificazioni e regole necessarie per poter applicare un sistema di questo tipo nell'ambito
le certificazioni e tutte le trafila servono per fare in modo che ci mettano le mani solo persone qualificate, con soluzioni altrettanto rodate, ed ha uno preciso perche'

problema -> soluzione

visto che c'e' tanta complexity in ballo e le risorse sono limitate, questo pero' non lo capiscono gli accademici, loro pensano di averle infinite, e nessuna deadline da rispettare, quindi creano nuovi problemi per dare loro nuove soluzioni

PJON non e' mai stato scrutinato per questo tipo di applicazione e non e' uno Standard in alcun modo certificato, quindi, la tua intera argomentazione non ha alcun senso e mi sembra piu' un flusso di coscienza poco gentile
se ti permetti di criticare ethernet perche' ha dei difetti che PJON risolve, io ti chiedo cosa e' che PJON porta come vantaggi, e tu mi rispondi?

usare EtherCat perche' sia una soluzione piu' elegante ed affidabile? Secondo me ti sbagli. Costerebbe di piu' e sarebbe meno affidabile, tralasciando i problemi pratici legati all'hardware
e tu mi rispondi: cavolate.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: dally on Dec 17, 2016, 09:07 pm
Mi spiace vedere tra le righe un tuo sfogo emotivo contro il mio lavoro
ti sbagli, nessuno sfogo emotivo, tu qui sopra hai attaccato Ethernet, e le motivazioni sono … fuffa.

il link che hai postato su EEVblog riguarda souliss
questo e' invece uno sfogo emotivo, pizzicata di ego burst, non hai nemmeno capito che ho citato quel link per la parte wireless: se rileggi cosa ho scritto e cosa hanno scritto stavamo semplicemente notando che e' dispersivo creare roba nuova quando c'e' gia' roba esistente, e si torna a quello che dicevo qui sopra.

a meno di veri vantaggi oggettivi, che qui io non vedo.

difatti nota che nessuno ti ha degnato di una risposta (http://www.eevblog.com/forum/microcontrollers/pjon-padded-jittering-operative-network-multi-master-multi-media-lan/): ti sei chiesto il perche'?  Te l'hanno scritto molto chiaramente: la gente con mentalità problem-solving (problema->soluzione) lo vede come l'n+1 standard (per altro rolling), agli n standard esistenti (alcuni consolidati, altri di ricerca), con n-m problemi da risolvere.

Utilizzare meme ritriti di avatar di un forum come comandamenti all'ingegneria sono la piu' grossa forma di ignoranza generalizzata (e rimangono in ogni caso un opinione)
Questo rimbalzo dialettico faccio finta di non averlo nemmeno letto.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 17, 2016, 09:09 pm
Centra con il fatto che conosco questo mondo da quando sono piccolo e so quanto e' difficile produrre, ma soprattutto superare tutte le barriere burocratiche e legali riguardo a qualcosa che venga applicato alla costruzione o alla manutenzione di un aeromobile.

Non vedo alcuna critica costruttiva in alcuna delle tue risposte. Ti ringrazio in ogni caso per l'opinione, buon week end.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Cina on Dec 17, 2016, 09:36 pm
Quote
Ho letto PJON dal foro, e guardato un po' la doc, e non mi ha colpito, per nulla perche' oggettivamente non vedo nessuna innovazione, nessun vantaggio, l'ennesimo progettino didattico che .. e' appunto un progettino didattico  
Non sono d'accordo dally ! e non capisco a cosa serve il tuo intervento...
Non mi intendo molto di questi protocolli o aerei,ma nel tuo intervento vedo solo la solita battuta che esiste dal inizio dei tempi :"A cosa serve se esiste gia questo..." e "Non inventarti altro che così va bene..."...ma se tutti facevano  e pensavano così eravamo ancora nelle caverne... Forse PJON non ha molto di più di altri protocolli gia esistenti, ma e un open source, non chiede "soldi" a nessuno, si presta ad essere criticato e aiutato,quindi non vedo dove sta il problema... Se veramente non serve a niente e non funziona il tempo lo giudicherà e si estinguerà... Neanche Arduino non serviva inventarlo... si poteva fare già tutto con PLC e anche meglio... Eppure esiste e ha molto seguito... Sappiamo tutti il perchè ... Entrare poi in conflitto con gbm e quasi impossibile perche e una persona che acceta crittiche anche quando non hanno nessun fondamento... Consiglio quindi di dare il tuo utile contributo (visto il tuo livello)..al progetto in modo che diventi qualcosa di piu dei attuali protocolli... Grazie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: dally on Dec 18, 2016, 04:29 pm
Non mi intendo molto di questi protocolli o aerei
Sopra ho fatto un discorso ben preciso, ovvero ho sottolineato che serve tempo e risorse ogni volta che si introduce qualcosa di nuovo che abbia la pretesa di migliore qualcosa di esistente. Se fosse invece una cosa didattica fine a se stessa, ovvero se non attaccasse lo stato dell'arte attuale, io non avrei nulla da ridire,  semplicemente che a me non interessa.

Invece viene detto che lo stato dell'arte attuale e' topo uno cadavere che cammina in punta di piedi sull'orlo del collasso, e solo PJON sarebbe la cura, la soluzione ad uno stato telematico in decomposizione (cosi' ha detto, no?), con poi tutta una serie di cose sull'opensource.

Ora ha senso dire opensource nel domotico quando quasi tutti gli elettro domestici ti arrivano a scatola nera, con dentro protocolli semi/totalmente proprietari? Bah … forse, in fin dei conti nessuno vieta di fare hacking selvaggio e reversing per poi attaccare un macinino opensource (tipo RPI?) in backend all'elttrodomestico, pero' non e' questo il punto.

Il tuo intervento < se tutti *avessero fatto cosi'*saremmo ancora nelle caverne* > (riferito allo sperimentare roba nuova) e' retorica ottocentesca con le macchine a vapore, perche' non siamo nemmeno albori di ArpaNet (prima ancora di internet) dove non esisteva niente, non c'erano sono strumenti, documentazione, tools, nessuno sapeva cablare nulla; oggi siamo nel 2016(quasi 2017), con una rete ben consolidata, varie problematiche, e varie soluzioni.

C'e' quindi bisogno di un nuovo protocollo?  Forse.

Di sicuro per il wireless serve qualcosa, ma per il wired siamo abbastanza soddisfatti.

Qui sopra e' stato affermato che non esiste nulla che soddisfi le esigenze personali, alche' mi chiedo quali siano, visto che esiste gia' EtherCat, fork di Ethernet, nato proprio per venire in contro alle esigenze industriali, con tanto di constraints real time, phy predisposto per la fibra ottica (ottima quando devi muoverti tra motori industriali che accoppiano disturbi nei cavi), e la cosa non solo funziona benissimo, ma ti permette di riciclare know/how, codice, strumenti, e cablaggi di quanto gia' esiste senza il bisogno di inventare nulla.

Ora, anche nei confronti di EtherCat e' stato affermato che PJON e' meglio. Per quale motivo? Questa la precisa domanda che ho posto, e le risposte fino ad ora sono tutte inconsistenti.

Tutte, eccetto l'aspetto didattico, unica cosa che mi convinto, ma se permetti decido IO dove allocare le mie risorse. Ho postato per farmi una precisa idea di PJON, non mi interessa ne fare polemica, ne altro, volevo togliermi il dubbio, e me lo sono tolto: PJON a me non interessa, e vi auguro buone cose.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Dec 18, 2016, 06:46 pm
Quote
Ora ha senso dire opensource nel domotico quando quasi tutti gli elettro domestici ti arrivano a scatola nera, con dentro protocolli semi/totalmente proprietari? Bah … forse, in fin dei conti nessuno vieta di fare hacking selvaggio e reversing per poi attaccare un macinino opensource (tipo RPI?) in backend all'elttrodomestico, pero' non e' questo il punto.
Invece e' proprio questo il punto! (tralasciando il fatto che stai attualmente negando la tua posizione riguardo alla creazione di nuovi standard comunicata con un meme di elevato livello culturale) Hai dato un occhiata al sito? Hai notato nella headline della pagina "why" la frase "Observing humanity of today dealing with IOT and the internet's future reminds me of the old story about the Tower of Babel. Is there a solution? Can we provide the community with one?" Esprime, seguendo il tuo modo di ragionare tanto esposto "problema -> soluzione" uno statement piuttosto chiaro sulla direzione e purpose del progetto. Il problema e' proprio che tutti per colpa di bias date dalla purpose commerciale di questi prodotti hanno creato un ambiente scomodo, complicato e reso assolutamente inutile dall'assenza di possibile interoperabilita' e privacy. PJON essendo un progetto non a fini di lucro, e' realizzato bottom to top ed implementato su macchine estremamente minimali e poco performanti (come puo' essere un Arduino Duemilanove) permette l'analisi e l'esplorazione di un nuovo paradigma grazie anche alla sua estrema economicita' in termini di interfacing e assoluta gratuita' e totale astrazione (se necessario) dal mondo Ethernet.

Secondo me tutto cio' che sta on top of Ethernet e propone di risolvere il problema che hai esposto e' solo roba trita e ritrita. Secondo me chi risolvera' il problema sara' chi riuscira' a creare uno strumento abbastanza universale estremamente leggero, a basso consumo energetico e semplice (non pensato per un ingegnere ma a prova di maker) che permetta totale interoperabilita' e abbia totale indipendenza dalle derive e influenze della ormai vecchia economia che abbiamo ereditato. Ah e che ovviamente proponga un'alternativa a Ethernet buttando nel gabinetto i 60 byte di overhead per pacchetto di ipv6, il tempo e costo di computazione e gli altri malus descritti precedentemente.

Riguardo al punto EtherCat vs PJON, se si sta comparando il physical layer quindi ethernet, contro SoftwareBitBang, io credo sia chiaro a chiunque stia leggendo che, ovunque non ci sia a disposizione una o piu' turbine da migliaia di cavalli capaci di generare corrente per un intero isolato, avere una ethernet shield / chip ethernet integrato per nodo e' una pazzia in termini di consumo energetico, infatti sono sicuro che se facessimo un poll qui sul forum scopriremmo che la maggiorparte dei progetti di domotica realizzati dagli utenti si basano su un solo device in rete connesso tramite un bus a piu' basso livello che sia 1-Wire, Seriale o RS485. SoftwareBitBang e' proposta come un' alternativa opensource a questo tipo di layer fisici.
Quale maker userebbe mai ethercat quando puo' usare un doppino con due modulini cinesi e avere Serial over rs485 o un solo filo in comune per tutti come nel caso di 1-wire o SoftwareBitBang?

Cercando di fare una critica costruttiva a una delle poche cose che hai effettivamente condiviso nelle tue risposte e non per fare l'ingegnere che non sono, ho il sentore che con 1000 nodi connessi via ethernet nel vostro aereo, potreste scoprire che i requirement legati alla potenza generata richiesta alla vostra APU potrebbero calare utilizzando un bus a piu' basso consumo energetico, riducendo il volume e il peso della APU e delle batterie necessarie probabilmente aumentando l'efficienza totale del mezzo. Mi spiace e preoccupa scoprire che quantomeno alcuni degli addetti ai lavori legati ai mezzi che volano il mio sedere in giro per il mondo abbiano questo mindset (intendo il tuo atteggiamento nei confronti della ricerca).

Chiuderei qui se possibile questa discussione, perche' ho davvero necessita' di dedicarmi al fix che permettera' a PJON di funzionare nominalmente anche throughSerial over RS485, grazie al prezioso supporto di Franketto. Buona fortuna.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 13, 2017, 04:31 pm
Ciao gbm, sto provando la tua libreria su arduino due, ma non riesco a farla funzionare, pensi possa essere dovuto alla differenza dei livelli di funzionamento?

ALfio
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 13, 2017, 04:54 pm
ho fatto anche un controllo con i livelli e non superano mai i due volt quindi non penso sia un problema fra differenze di tensione di lavoro.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 14, 2017, 12:38 pm
CIao Alfio, grazie dei tuoi complimenti.

Le diverse tensioni possono di certo creare un problema, non e' detto che tu possa raggiungere in entrambi il threshold di entrambe le schede.

Una volta avendo collegato correttamente i due device con dei level shifter, il problema conseguente e' la probabile differenza nel tempo di esecuzione del codice, tra un normale arduino duemilanove e una due.

E' probabile che la Due necessiti di dei valori di timing ad hoc https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/Timing.h (https://github.com/gioblu/PJON/blob/master/strategies/SoftwareBitBang/Timing.h) per il tipo di architettura / cpu che ti stai utilizzando.

Se vuoi provare a portare la Due, dovresti scovare come si chiama la costante che legata alla scheda (vedi il file timing linkato sopra) e poi ridefinire le tempistiche secondo le attuali necessita'. Con un oscilloscopio e' molto semplice, si misura le durate dei bit e di bit spacer, e si cerca di modificare i valori immessi in Timing.h (relativi alla due) per ottenere una durata il piu simile possibile a quella di un duemilanove standard (la cui timing e' considerata la "mastro").

Potrebbe essere necessario anche, inserire in https://github.com/gioblu/PJON/blob/master/utils/PJON_IO.h (https://github.com/gioblu/PJON/blob/master/utils/PJON_IO.h) le macro necessarie per accedere piu velocemente ai pin della Due (cerca digitalWriteFast)
 
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 14, 2017, 12:40 pm
Mi sono dimenticato, ma perche' non usare la strategia ThroughSerial?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 14, 2017, 04:28 pm
Per la ThroughSerial se non ho capito male, sono costretto ad usara una connessione rs232 o megli rs485, cosa che volevo evitare per minimizzare l'hardware al massimo.

Il mio progetto è legato alla domotica, ho gia il sistema funzionanate in una parte di casa, in un altra parte non riesco a passare i cavi necessari per i pulsanti interruttore quindi la mia idea era quella di inserire in ogni pozzetto interruttori una arduino nano ed usare la tua libreria per la comunicazione.
Siccome anche i pozzetti sono piccoli non ho troppo spazio e mettere arduino nano e convertitore rs458, mi viene un po male.
Purtroppo non posso vedere la durata del bit perche non ho a disposizione un oscilloscopio.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 14, 2017, 08:04 pm
Per quale motivo hai scelto la due come "master" ?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 14, 2017, 08:06 pm
In ogni caso, ThroughSerial funziona tramite una qualsiasi porta seriale emulata o hardware (dovrebbe funzionare anche con la due senza problemi), l'rs485 puo' essere utilizzato nel caso in cui usi due convertitori seriale -> rs485.

Quello che puoi provare a fare se non riesci a portare SoftwareBitBang su Due, (cosa che bolle in pentola, ma non ho il tempo di inserire nella tranche di modifiche della prossima release (la 7)) e' usare la seriale per parlare dalla due a un device che possa parlare anche SoftwareBitBang e usarlo come "router".
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 14, 2017, 08:26 pm
Per quale motivo hai scelto la due come "master" ?
ho scelto la due per la cpu piu veloce ed il maggio spazio per il codice.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 14, 2017, 08:36 pm
In ogni caso, ThroughSerial funziona tramite una qualsiasi porta seriale emulata o hardware (dovrebbe funzionare anche con la due senza problemi), l'rs485 puo' essere utilizzato nel caso in cui usi due convertitori seriale -> rs485.

Quello che puoi provare a fare se non riesci a portare SoftwareBitBang su Due, (cosa che bolle in pentola, ma non ho il tempo di inserire nella tranche di modifiche della prossima release (la 7)) e' usare la seriale per parlare dalla due a un device che possa parlare anche SoftwareBitBang e usarlo come "router".

ho fatto andare la ThroughSerial con una porta rs232 fisica del DUE ed una software su UNO e NANO, e riesco ad inviare i dati. ho anche fatto fare da router ad una UNO che comunica in Serial con la DUE ed usato in SoftwareBitBang la UNO "router" e la nano, e va senza problemi.
Ovviamente preferisco la ThroughSerial  per avere un arduino in meno che lavori. Adesso devo vedere con collegare diverse UNO e NANO in rs232.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 14, 2017, 11:52 pm
Che bello, ottima notizia   :)  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 17, 2017, 10:31 am
nuovo problema.
Fin che nell arduino due non girava niente andava tutto bene, ma una volta caricato anche il resto del software l'arduino non riesce piu ad eseguire niente.

con il software mio ad effettuare un loop completo ci vogliono 25ms, invece appena metto la bus.receive(100) esegue solo le richieste che arrivano dalla seriale, il resto del softwre non riesce piu a fare niente ed un loop adesso dura 200ms tempo troppo lungo nel quale non riesce piu a leggere i pulsanti direttamente collegati all'arduino due
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 17, 2017, 01:35 pm
Ciao Alfio, prova ad aumentare la velocita' di trasmissione e ridurre il tempo passato a receive!
I bottoni hanno il debounce?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 17, 2017, 02:20 pm
Un altra soluzione potrebbe essere utilizzare gli interrupt per detectare la pressione del bottone
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 18, 2017, 11:39 am
ciao, si i bottoni hanno il debounce ma non ci sono delay
per la velocita ho provato in diversi modi e l'errore è sempre uguale, anche cambiando il tempo dedicato all'ascolto la cosa non cambia (es. 1 ns) e il ritardo è uguale anche se non collego niente alla seriale.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Feb 23, 2017, 02:30 pm
Ciao Alfio, scusa il ritardo nella risposta, ma sono stato presissimo dalla release della 7 che era imminente.
Mi allegheresti qui il codice? Probabilmente possiamo ridurre il loop time e le timing di ThroughSerial perche' funzioni correttamente, l'utente franketto ha una discreta esperienza su PJON -> ThroughSerial -> RS485 ti puo' dare di certo un consiglio!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: alfio76 on Feb 28, 2017, 09:56 am
ciao, vuoi allegato tutto il codice del sistema? è molto lungo ed utilizza diversi file ed anche diversi file di configurazione che vanno posizionati su SD
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gpb01 on Mar 01, 2017, 03:13 pm
>gbm:  Ritenendo il software qui descritto, ben collaudato e ben manutenuto, nonché di interesse per molti che hanno l'esigenza di porre in colloquio più "Arduino" tra di loro, ho ritenuto opportuno marcarlo "sticky" facendo in modo che sia sempre tra i thread di testa della sezione "Software" ;)

Guglielmo
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: scoprire on Mar 03, 2017, 06:17 pm
Innanzitutto complimenti per l'immane e ottimo lavoro che hai fatto.

Devo mettere in comunicazione 2 o al massimo 3 Arduino ed avevo optato per la SoftwareBitBang e guardavo gli sketch di esempio su GitHub
PJON/examples/Local/SendAndReceive
e
PJON/examples/Local/BlinkWithResponse

Al arduino "slave" sono collegati vari sensori che, mi serviva che a seconda del comando che il "master" invia venisse risposto con la lettura di un diverso sensore.

Avevo pensato a questo codice
Code: [Select]

void receiver_function(uint8_t *payload, uint16_t length, const PJON_Packet_Info &packet_info)
{
  double as = mlx1.readObjectTempC();
  double ac = mlx2.readObjectTempC();
  double ad = mlx3.readObjectTempC();
  double ps = mlx4.readObjectTempC();
  double pc = mlx5.readObjectTempC();
  double pd = mlx6.readObjectTempC();
  
  if(payload[0] == '1')
  {
    bus.reply(as, 1);
  }
   if(payload[0] == '2')
  {
    bus.reply(ac, 1);
  }
   if(payload[0] == '3')
  {
    bus.reply(ad, 1);
  }
   if(payload[0] == '4')
  {
    bus.reply(ps, 1);
  }
   if(payload[0] == '5')
  {
    bus.reply(pc, 1);
  }
   if(payload[0] == '6')
  {
    bus.reply(pd, 1);
  }
}


ma con reply, a quanto mi sembra di aver capito, posso trasmettere solo un const char, quale funzione mi conviene usare
e come faccio a dire al "master", che successivamente dovrà leggere un altro sensore, di aspettare una risposta prima di inviare un nuovo comando?
Grazie mille
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 07, 2017, 08:42 pm
Ciao Guglielmo, grazie mille!

Ciao Scoprire, guarda l'esempio SendArbitraryValues: https://github.com/gioblu/PJON/tree/master/examples/Local/SendArbitraryValues (https://github.com/gioblu/PJON/tree/master/examples/Local/SendArbitraryValues)
Mostra come mandare una int.

Il metodo reply dispatcha un pacchetto che verra' inviato alla prossima chiamata ad update().

Sopra l'infrastruttura PJON tu dovresti organizzare il protocollo, l'ordine e la successione della comunicazione tra i tuoi device a livello applicazione. Con questo intendo, nel caso particolare di essere sicuro di aver ricevuto un valore di un sensore prima di leggerne un altro, di implementare una "state machine" che gestisca lo stato di ricezione di ogni sensore semplicemente con dei boolean (bool receivedLightSensorValue = false, quando ricevi nuova setti true, dopo un tempo limite tutti tornano a false e cosi' via). Se non hai voglia di riscrivere questa parte, o hai bisogno di ispirazione, dai un occhio al lavoro che ha fatto Fred Larsen, ModuleInterface: https://github.com/fredilarsen/ModuleInterface (https://github.com/fredilarsen/ModuleInterface)

Questo puo' essere un buon modo per familiarizzare con lo strumento, anche se potrebbe essere sensato semplicemente spedire tutti i dati insieme con un intervallo regolare, o richiederli lato master in base alle necessita'.

Non utilizza le classi PJONMaster e PJONSlave ma la classe base PJON.h ed implementa un sistema master-slave che supporta aggiornamento automatico dei valori (basato su un collaudato e sicuro sistema di contratti), eventi, handling delle failure dei nodi e un'interfaccia molto ben fatta per la visualizzazione dei dati in diversi formati.

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 08, 2017, 10:22 am
Ciao Giovanni
dopo parecchio tempo ho ripreso mano ad un progetto che avevo in testa utilizzando il tuo sistema di comunicazione.
Per rinfrescarmi le idee ho provato ad utilizzare un tuo esempio cioè quello in local/Blink test nella cartella degli esempi.
Installate le tue librerie e provando a caricare il file Transmitter.ino mi escono questi errori:

Code: [Select]
In file included from C:/Program Files/Arduino/libraries/PJON/strategies/EthernetTCP/EthernetTCP.h:23:0,

                 from C:/Program Files/Arduino/libraries/PJON/PJON.h:109,

                 from C:/Program Files/Arduino/libraries/PJON/examples/Local/BlinkTest/Transmitter/Transmitter.ino:1:

C:/Program Files/Arduino/libraries/PJON/strategies/EthernetTCP/EthernetLink.h:131:24: fatal error: Ethernet.h: No such file or directory

   #include <Ethernet.h>


Dichiarando in aggiunta alla libreria Pjon.h anche

le seguenti librerie
#include <Ethernet.h>
#include <SPI.h>
il tutto funziona.

Così anche per il file Transmitter.ino

Hai qualche idea?
Grazie

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 08, 2017, 04:13 pm
CIao Franchelli, grazie per il report. Che versione di PJON e arduino IDE usi?
Grazie ancora, sistemiamo subito  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 09, 2017, 10:01 am
Come sempre super disponibile...  :)

la versione Pjon è l'ultima presente su Github mentre l'IDE Arduino e l'ultima  1.8.1.

Cominciamo con le domande:

nella sezione Configurazioni in Documentazione vedo che

sono presenti (dove sono presenti ?) tutte le strategie ma è possibile indicare/utilizzare una sola definendo una stringa del tipo 
Code: [Select]
#define PJON_INCLUDE_SWBB
Questa va inserita in fase di definizione coiè prima del setup?
Automaticamente esclude tutte le altre?
Quali vantaggi si hanno a definire solo una strategia?

Inserendo questa stringa
Code: [Select]
#PJON_INCLUDE_NONE
cosa avviene?


Con questa
Code: [Select]
  bus.set_shared_network(true);
 (o false) si definisce se le comunicazioni avvengono su media che condividono o meno piu bus di comunicazione.
E' sempre necessario aggiungere questa stringa? Se non la si aggiunge quale sarà il comportamento di default della comunicazione?


Code: [Select]
  bus.set_communication_mode(PJON_SIMPLEX);
  bus.set_communication_mode(PJON_HALF_DUPLEX);

Stessa domanda del quesito precedente.
In quali casi si usa l'una o l'altra?


Non è per niente chiara la questione " synchronous acknowledge".
Potresti chiarire brevemente scopo, casi di utilizzo ?


Code: [Select]
bus.set_router(true);
Code: [Select]
bus.set_packet_auto_deletion(false);

Come sopra, una spiegazione un po' meno stringata aiuterebbe molto a capire scopi, ventaggi ed usi di talune stringhe di configurazione.

Grazie per la pazienza.

A seguire altre domande....



Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 09, 2017, 04:54 pm
Ciao, qualsiasi costante di configurazione con #define va messa prima dell' #include PJON.h cosi' da permettere a PJON di trovare definite quelle costanti. PJON_INCLUDE_NONE non include alcuna strategia, e ti permette potenzialmente di definirne una ad hoc e testarla passandola a PJON<tuaStrategia> se definita prima di PJON ovviamente. Se vuoi solo una strategia per esempio SWBB definisci PJON_INCLUDE_SWBB prima di #include PJON.h

bus.set_shared_network(bool) ti permette di decidere se vuoi includere nei pacchetti il nome gli id dei bus, quindi se hai configurato per esempio piu' gruppi di device (gruppo 0.0.0.1 e 0.0.0.2), passando true o se includere solo l'id del device nel pacchetto. Se non ti servono i gruppi puoi risparmiare 4 byte di overhead + 4 se includi le info dell'inviante.

bus.set_communication_mode ti permette di settare se vuoi poter trasmettere bidirezionalmente o monodirezionalmente, se PJON_SIMPLEX monodirezionale, se PJON_HALF_DUPLEX bidirezionale

L'acknowledge quindi la conferma di corretta ricezione e' disponibile in due varianti, un meccanismo sincrono, dove il trasmettitore aspetta (blocking) che un singolo carattere (6 ACK o 21 NAK) venga spedito dal ricevitore dopo la computazione del pacchetto. La versione asincrona invia un intero pacchetto contenente un id (che permette di riconoscere a quale pacchetto si riferisce la conferma) che permette al trasmettitore di inviare (non-blocking) fare altro e aspettare la conferma in un tempo futuro. Questo meccanismo per esempio permette a una conferma di poter fare piu di un hop, cosa che un ACK sincrono non puo' fare per ovvi motivi. La cosa interessante e' che possono essere usati assieme, vedi recursive acknowledgment pattern nella specifica di PJON.


Se setti router true puoi fare in modo che la funzione di ricezione venga chiamata in ogni caso alla ricezione di qualsiasi pacchetto e quindi per esempio rispedirlo su un altra linea PJON.

set_packet_auto_deletion se settato false (di default true) ti permette di poter evitare che i pacchetti vengano eliminati quando spediti o ricevuta conferma di ricezione, per eventualmente poter gestire a basso livello la libreria per usi particolari
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 13, 2017, 02:21 pm
Ciao,
stavo leggendo gli esempi riguardanti la strategia "Serial" e mi sono chiesto se è possibile utilizzare invece che la seriale hw a bordo, una seriale emulata tramite libreria SoftwareSerial.

In caso affermativo potresti postare lo spezzone di codice modificato allo scopo ?
Grazie mille
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 13, 2017, 03:12 pm
Ciao Franchelli, istanzia SoftwareSerial, chiama begin al baudrate che preferisci e passa l'oggetto a set_serial esattamente come fai con Serial standard, dovrebbe funzionare in maniera totalmente agnostica.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 14, 2017, 09:02 am
Qualche post fa avevo segnalato che alla compilazione di uno sketch preso
tra i tuoi esempi mi esce un errore per la mancanza nello stesso di due librerie (SPI ed ETHERNET).
Volevo sapere se sono gli esempi da aggiornare oppure c'è qualche dettaglio che mi sfugge...
Io uso le librerie alla ultima versione disponibile così come l'IDE Arduino.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 14, 2017, 05:43 pm
ciao Franchelli!

Rileggendo dici che aggiungendo alla libreria Pjon.h anche

le seguenti librerie
#include <Ethernet.h>
#include <SPI.h>

il tutto funziona.

Dove aggiungi queste due righe?
Strano, non capisco come sia possibile io non riesco a replicare questo problema, anche se un utente russo ha riportato lo stesso problema (ma senza proporre come hai fatto tu una soluzione). Sarebbe di certo carino inquadrare perche' succede.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 14, 2017, 07:10 pm
Le aggiungo all'inizio dello sketch dove dichiaro la libreria PJON.h


---------------------------------------------------------------

Oggi ho perso praticamente tutta la giornata per capire come far funzionare una comunicazione tra 3 arduino ora mi spiego :

2 trasmettitori ed un ricevitore in modalità Local  utilizzando la strategia SoftwareBitBang unifilare

ho provato ad utilizzare gli esempi allegati ( BlinkTest) caricando due trasmettitori ed un ricevitore sui 3 Arduino.
Configurato tutto in maniera opportuna la comunicazione avviene correttamente tra i tre attori. Il problema inizia quando voglio inviare dati non in maniera ripetitiva
Code: [Select]
bus.send_repeatedly(44, "B", 1, 1000000); // Send B to device 44 every second
ma in maniera "comandata" .  Volendo utilizzare solo
Code: [Select]
bus.send(44, "B", 1, 1000000); // Send B to device 44 every second

non riesco proprio a far andare nulla. La comunicazione non avviene .Cortesemente potresti indicarmi dove inserire questo comando e soprattutto se utilizzare o meno nel loop
Code: [Select]
bus.update();

Vedo che i dati inviati sono trattati come Stringhe  (racchiusi tra doppio apice) : l'invio dei dati è sempre trattato come stringa? Cioè quasiasi tipo di informazione da inviare deve essere preventivamente convertita in stringa?

Se posso darti un consiglio da super profano:

gli esempi sono molti ma sono molto simili. Sarebbe molto utile ai non esperti come me, realizzare delle semplici funzioni che aiutino a capire i meccanismi basilari come per esempio creare una stringa da un valore numerico sommarla ad un prefisso(o suffisso) ed inviarla nella modalità più semplice ad un ricevitore che la salva in una costante facendola stampare su seriale.

Insomma cercare di creare tanti piccoli esempi base che spieghino uno alla volta le principali funzioni.
Scusa se mi sono permesso ma cotanta sofisticazione è inutilizzabile (almeno a chi è principiante) se non accompagnata da abbondante documentazione. Grazie ancora per il lavoro che stai facendo.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 14, 2017, 10:22 pm
Ciao Frankelli, qui trovi la documentazione: https://github.com/gioblu/PJON/blob/master/documentation/data-transmission.md (https://github.com/gioblu/PJON/blob/master/documentation/data-transmission.md)

il comando .update() serve per inviare i pacchetti inseriti nella coda (cosa che avviene chiamando send o send_repeatedly) e va chiamato ogni loop cycle. Invece chiamando send_packet e send_packet_blocking l'invio avviene istantaneamente e non e' necessario chiamare update.

send o send_repeatedly vanno usati se si vuole avere la certezza di invio, ricezione, retry in caso di mancata risposta e il log degli errori ad alto livello.

send_packet puo' essere utilizzato nel caso in cui ti interessa inviare un pacchetto una volta sola (per esempio nel cavo vuoi inviare un BROADCAST) oppure nel caso in cui stai lavorando a basso livello, cioe' inviando il pacchetto, controllando il risultato della funzione e agendo di conseguenza.

send_packet_blocking esegue la stessa trafila di invio, retry fino a max tentativi come send, ma in maniera blocking, quindi non ritornando fino alla corretta ricezione o errore e in questo caso non serve chiamare update.

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 14, 2017, 10:23 pm
Per la funzione invio dati vedi: https://github.com/gioblu/PJON/blob/master/examples/Local/SendArbitraryValues/Transmitter/Transmitter.ino (https://github.com/gioblu/PJON/blob/master/examples/Local/SendArbitraryValues/Transmitter/Transmitter.ino)
Questo esempio di un voltage tester device che invia V + voltaggio in formato integer rilevato da porta analogica.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 17, 2017, 08:56 am
Ciao Giovanni,
facendo dei test di trasmissione tra 3 arduino ho notato che uno, inviando una stringa di valori, mi restituisce un errore di comunicazione PJON_PACKETS_BUFFER_FULL

Mi puoi spiegare cosa vuol dire, da cosa è dovuto e come posso risolvere ?
Il pacchetto ha in tutto 11 caratteri.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 17, 2017, 07:00 pm
Ciao Franchelli!
Allora, utilizzando la funzione
Code: [Select]
send, se chiedi a PJON di inviare piu' pacchetti di quanti possano essere fisicamente inviati (i.e. in ogni giro di loop chiedi di inviare un pacchetto), puoi riempire il buffer dei pacchetti e ottenere l'errore che riporti. Se invece stai cercando di inviare piu' di 5 pacchetti alla volta, definisci
Code: [Select]
PJON_MAX_PACKETS con il valore che preferisci.

Vedi linea 18 e 43 di questo esempio: https://github.com/gioblu/PJON/blob/master/examples/Local/SendAndReceive/Device1/Device1.ino (https://github.com/gioblu/PJON/blob/master/examples/Local/SendAndReceive/Device1/Device1.ino)

come puoi vedere,
Code: [Select]
send ritorna la posizione del pacchetto all'interno del buffer, in questo esempio viene creata una catena di invii a pin-pong tra due device, prima di inviare una risposta a un eventuale pacchetto ricevuto e quindi continuare il ping-pong, entrambi i device controllano di non avere ancora un pacchetto di risposta rimasto da inviare da cicli precedenti per qualsiasi motivo (errore, canale occupato, interferenza).

Questa cosa puo' essere fatta in maniera piu' semplice anche con la funzione
Code: [Select]
send_packet_blocking che non ritorna finche' il pacchetto non e' stato inviato o il tempo massimo di back-off e' stato raggiunto, e ritorna il risultato della trasmissione, sicuramente piu' facile da utilizzare, ma meno performante per natura essendo blocking e perche' durante il periodo di trasmissione e delay non effettua alcuna ricezione, ma per la maggior parte dei casi puo' essere la via piu' semplice da capire ed implementare non necessitando l'uso del gestore dei pacchetti (quindi non e' necessario chiamare update()):

Code: [Select]

if(bus.send_packet_blocking(10, "All is ok?!", 11) == PJON_ACK)
  Serial.println("10 is ok!");


Se la funzione ritorna PJON_ACK la comunicazione e' andata a buon fine dopo uno o piu' retry, il CRC e' stato computato correttamente lato ricevitore e l'acknowledge e' stato ricevuto lato trasmettitore!

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Mar 20, 2017, 09:05 am
Tanto per capire meglio:

per ..."se chiedi a PJON di inviare piu' pacchetti di quanti possano essere fisicamente inviati (i.e. in ogni giro di loop chiedi di inviare un pacchetto)"

 intendi per pacchetto quanto contenuto in una riga di codice simile:

Code: [Select]
bus.send(45, "B", 1); dove il pacchetto è in pratica "B" ma potrebbe essere anche una stringa più lunga tipo  "ABCDEFG".

Non capisco come si possano inviare più pacchetti alla volta se ogni riga di codice ne invia uno.


Ho trovato nel tuo esempio questo codice

bus.reply("B", 1);
come funziona?

(bus.packets[packet].state)
invece cosa ti restituisce?


Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Mar 20, 2017, 03:02 pm
Ciao Franchelli, buon inizio settimana.
Allora un modo per riempire il buffer puo' essere di chiamare send piu volte senza chiamare update:
Code: [Select]

bus.send(12, "ciao", 4);
bus.send(13, "ciao", 4);
bus.send(14, "ciao", 4);
bus.send(15, "ciao", 4);
bus.send(16, "ciao", 4);
bus.send(17, "ciao", 4);

bus.update();

Se chiami send (senza effettuare update) un numero uguale o superiore a PJON_MAX_PACKETS otterrai l'errore PJON_PACKETS_BUFFER_FULL, perche' stai accumulando nella memoria tanti pacchetti quanti lo spazio a disposizione. Dovresti provare a inviarli ogni volta che ne inserisci uno (chiamando update() ogni ciclo, come consigliato dalla documentazione).

Se ricevi un pacchetto da parte di un device che ha incluso anche le informazioni di chi ha inviato nei metadati del pacchetto (di default sono inclusi) e' possibile chiamare reply dall'interno della funzione callback di ricezione per rispondere a un eventuale messaggio, senza dover inserire i dati del destinatario.

bus.packets[packet].state puo' valere PJON_TO_BE_SENT, o 0 se 0 vuol dire che il pacchetto e' stato inviato con successo e cancellato. Ovviamente se prima di questo controllo, viene chiamata update e effettuato un eventuale inserimento di un nuovo pacchetto, questo potrebbe prendere il posto del pacchetto precedentemente consegnato, quindi il controllo dello stato del pacchetto va fatto solo nel caso in cui il ciclo di invio e ricezione e' noto, considerato e coordinato da te.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Apr 10, 2017, 01:04 pm
Ciao,

sto testando la funzionalità di conferma ricezione utilizzando questo esempio

Code: [Select]
if(bus.send_packet(10, "All is ok?!", 11) == PJON_ACK)
  Serial.println("10 is ok!");


e più o meno ciclicamente a terminale non mi viene inviata conferma di ricezione per 10 12 volte consecutive.


Per fare questo test provo ad inviare un pacchetto di dati lungo circa 25 caratteri e con cadenza 5 secondi, composto da alcune variabili che variano abbastanza velocemente (letture da termometri) e nonostante non mi venga data conferma di ricezione da parte del ricevitore, i valori vengono correttamente trasferiti ... mi sfugge qualcosa....

Questa è la sezione di codice che crea, invia e controlla la corretta ricezione dei dati
Code: [Select]

if(pollingMetro.check() == 1){// ogni 5 secondi...
  sensors.requestTemperatures(); // Invia comando per rilevare temperatura a tutti i dispositivi sul bus
  Temp =  sensors.getTempCByIndex(0);
  String readWatt = String(watt);//crea una stringa da un valore float con 0 posti decimali >>WATT<<
  String readTemp = String(Temp,1);//crea una stringa da un valore float con 1 posti decimali >>TEMPERATURA<<
  String stringTmp = String(prefix + '_' + separaTors0 + readWatt +','+ separaTors1 + val1 +','+ separaTors2 + val2 +','+idTemp + readTemp +','+ separaTors3 + val3 + ','+ endPacket); //prepara la stringa con prefisso  + lettura
  int lun = stringTmp.length(); //salva nella variabile la lunghezza della stringa appena creata
  char stringBuf[lun];//crea un array di char con lunghezza <lun>
  stringTmp.toCharArray(stringBuf, lun+1);//converte la stringa in array di char con lunghezza <lun> +1 (carattere fine riga)

  // debug dati in trasmissione
  Serial.print(F("Dati CONSUMO: "));
  for(int i=0; i<lun; i++){
      Serial.print(stringBuf[i]);
}
Serial.println();
bus.send(1, stringBuf, lun);//invia l'array di char al dispositivo con ID 3 con lunghezza <lun>
if(bus.send_packet(1, "All is ok?!", 13) == PJON_ACK){
   Serial.println("13 is ok!");
}
}
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Apr 13, 2017, 08:01 am
Ho notato che  con la pubblicazione dell'ultima versione delle librerie, la 8.0, la compilazione degli sketch provoca una marea di errori... ovviamente con la versione precedente delle librerie questo non accade.
Ho un po' cercato nel sito ma non ho trovato nessun riferimento. Quali sono stati i cambiamenti?

Grazie
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Apr 17, 2017, 04:07 pm
Ciao Franchelli, buona pasqua. Potresti postare gli errori che ottieni compilando con la v8?
Altra cosa, che strategia utilizzi? Che hardware utilizzi? Potresti postare qui il codice per intero cosi' che io possa debuggarlo? Se utilizzi SWBB hai provato ad aggiungere come consigliato la resistenza di pull-down? vedi README SoftwareBitBang. Se utilizzi ThroughSerial, ovviamente dovresti evitare di utilizzare la Serial utlizzata da PJON per il debug o print dei dati!
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Apr 18, 2017, 12:29 pm
Buona Pasqua pure a te...

Purtroppo gli errori sono in quantità tale che non riesco a inserirli qui. Intanto di indico la situazione:

Arduino IDE 1.6.8
Libreria PJON 8.0 l'ultima.

Normalmente uso l'editor Sublime Text 3 con il plugin Stino per scrivere e caricare gli sketch su Arduino e fino ad oggi non aveva mai dato nessun problema. Giorni fa ho installato la nuova versione del plugin Stino  e da li sono sorti i problemi. Usando L'ide di Arduino indicata non rci sono problemi mentre con Sublime Text3 + Stino succede il finimondo. Ovviamente tu mi dirai che è un problema di Stino (e molto probabilmente avrai ragione  :) ) ma è uno strumento veramente valido e mi dispiacerebbe privarmene. Se mi dici dove posso caricare gli screenshot degli errori te li faccio avere. In ogni caso usando la tua libreria V. 7.1 non appaiono errori solo se aggiungo questa  dichiarazione #include <Ethernet.h> oltre alla solita #include <PJON.h>
Grazie ancora

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jun 29, 2017, 02:00 pm
Ciao Frankelli, ho avuto un bel po' di cose da fare e non ho avuto tempo di approfondire il tuo report.
Finalmente mi sono ritagliato un po' di tempo per farlo, per caso hai risolto o sei passato ad utilizzare l'IDE standard?

Sto lavorando alla cartella "devices" nel repository, dove proporre anche qualche esempio delle possibili applicazioni di PJON nel mondo reale.

Il primo esempio e' un sensore di prossimita' basato su reflettometria e soli due LED a luce visibile o infrarossi per determinare la distanza di un ostacolo. Nel sensore viene integrato un ATtiny85 capace di contene l'intero stack PJON (quindi e' possibile assegnare un determinato id al sensore e connetterlo allo stesso filo a cui tutti gli altri sono connessi), funzioni di determinazione della distanza e configurazione + salvataggio conf su EEPROM.

Ho sperimentato per alcuni anni con interesse le interessanti capacita' foto-elettriche di normali LED pensati per emettere luce (probabilmente alcuni di voi mi hanno seguito in passato su www.gioblu.com). il LEDAR e' il risultato di questi esperimenti e permette un range potenziale di oltre 6 metri nella migliori condizioni:

https://github.com/gioblu/PJON/tree/master/devices/sensors/LEDAR (https://github.com/gioblu/PJON/tree/master/devices/sensors/LEDAR)

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jul 26, 2017, 10:48 am
Ciao Giovanni,

purtroppo per usare Pjon devo caricarlo tramite IDE Arduino e non con Sublime Text e la cosa è parecchio fastidiosa. Peccato.

Sto continuando col mio progetto e con Pjon ed ora avrei da chiederti un ulteriore info:

oltre che la strategia SBB vedo anche quelle tramite UDP e  TCP quindi ti chiedo quali differenze pratiche comporta l'una rispetto alle altre.
Grazie e a presto con altre richieste.... :-)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jul 26, 2017, 11:17 am
Aggiungo al mio post predente,
sto tentando di far andare il tuo esempio LOCAL/UDP/PING PONG con due moduli WEMOS D1 mini (dovrebbero essere equivalenti al NODEMCU) solamente che non riesco a capire alcune cose:

i due esempi sono già completi e pronti per essere caricati sui dispositivi, dopo aver settato i vari parametri di rete? Ho provato ma aperta la seriale vedo dei continui riavvi del modulo WEMOS.

se devo caricarli su moduli che montano ESP8266 dovrei anche aggiungere librerie aggiuntive(quali) e soprattutto manca tutta la parte di codice per la configurazione della rete wifi a cui devono agganciarsi...

gli esempi che hai inserito sono chiari per quanto riguarda il protocollo Pjon ma nessuna parola per adattarli ai vari dispositivi che lo possono utilizzare.

Grazie se riuscirai a spendere due parole per chiarire questi aspetti fondamentali.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jul 30, 2017, 12:52 am
Ciao Frankelli, ETCP e LUDP sono due strategie che possono essere utili per connettere due o piu' device senza alcuna connessione fisica diretta, utilizzando internet. In molti casi vengono usate dagli utenti per connettere a un bus SWBB device che si muovono o che sono troppo distanti o complicati da connettere via SWBB.

Attualmente il creatore, Fred sta considerando di estendere il supporto a ESP8266, che attualmente NON E' supportato da ETCP, ma a breve lo sara'. Attualmente solo Uno, Duemilanove, Mega credo siano supportati con l'uso dell'ethernet shield. Mi hai fatto notare anche che non e' presente la sezione "Compatibility" che adesso aggiungo, grazie mille  :)


Giuro che ritaglio un po' di tempo questa settimana per riinstallare sublime e provare a capire dov'e' il problema con stino.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jul 30, 2017, 01:00 am
Che cosa stai costruendo??  :)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jul 30, 2017, 07:23 pm
Ciao,

forse ti è sfuggito (o io non ho capito bene... probabile....) ma seguendo il seguente percorso PJON/strategies/EthernetTCP/

leggo:  Medium: Ethernet port, wired or WiFi

Io lo intendo che i medium di trasmissione comprende anche il collegamento wifi.

Sbaglio? Come lo potrei fare se non con un ESP ?

Quello che sto realizzando è un sistema per ottimizzare l'autoconsumo su un impianto fotovoltaico che attiva in maniera automatica e proporzionale all'eccedenza di produzione, un boiler tramite treni di impulsi. Questo sistema si avvale di un modulo ESP 8266 con firmware Upanel http://www.miupanel.com/overview/
che mi permette di creare un'interfaccia grafica per visualizzare vari parametri su un tablet dismesso utilizzato solo come visualizzatore. Il ruolo di Pjon e quello di connettere tramite SWBB unifilare due contatori SDM 120C posti in posizioni "scomode" che misurano produzione e consumo. I dati prodotti da questi due dispositivi (ed i loro relativi Arduino che elaborano i dati e gestiscono la comunicazione Pjon) vengono inviati ad un Arduino MEGA che con a bordo Upanel gestisce l'interfaccia grafica. A margine ed un secondo tempo vorrei, sempre tramite Pjon, (e qui i miei tentativi di utilizzarlo con ESP) poter controllare e comandare delle altre utenze  disposte in giro per la casa. Potrei probabilmente farlo anche  con il protocollo Upanel ma onestamente con Pjon ormai ci ho preso un po' la mano e il tuo protocollo sino ad ora non mi ha riservato sorprese andando egregiamente bene. Se poi riusciste ad implementarlo anche con l' ESP sarebbe perfetto ampliando ancora il già enorme range di utilizzo.

Rimango in attesa di sviluppi con Pjon+ ESP.
A presto
Franco

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Jul 30, 2017, 08:17 pm
Ciao Franco! Grazie dei complimenti, credo fred abbia incluso il medium wireless perche' da ethernet poi puoi passare ovviamente tramite un router wireless, in ogni caso, credo appena avra' un po' di tempo si dedichera' al port completo dell'ESP8266.

Qual'e' la lunghezza massima del bus unifilare SWBB che hai posto?
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: Franchelli on Jul 31, 2017, 07:22 pm
Qual'e' la lunghezza massima del bus unifilare SWBB che hai posto?

Il tratto più lungo è una 15na di metri.
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Aug 01, 2017, 06:12 pm
Ho rilasciato ora la 8.2: https://github.com/gioblu/PJON/releases (https://github.com/gioblu/PJON/releases)
Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: gioscarab on Oct 30, 2017, 06:31 pm
Ciao ragazzi, finalmente la versione 9 e' online: https://github.com/gioblu/PJON/releases/tag/9.0 (https://github.com/gioblu/PJON/releases/tag/9.0)

Abbiamo lavorato ad ampliare la compatibilita', finalmente le stesse 1000 righe della classe PJON possono operare su un piccolo ATtiny85 come su un sistema operativo real time Windows o Linux ed eseguire il network stack indipendentemente dal data link utilizzato. Molto effort e' stato dedicato anche a rendere piu' affidabile e sicuro il network protocol stack facendo alcune modifiche chiave all'implementazione e alle specifiche.

Vi consiglio di dare un' occhiata alla nuova tecnologia proposta, che permette la comunicazione wireless bidirezionale tra device con un range massimo di 6 metri in condizioni ottimali utilizzando solo un LED a luce visibile o infrarossa per device, utilizzato come rice-trasmettitore di radiazioni luminose (essendo il LED un fotodiodo e' utilizzato come un fotodiodo nella fase di ricezione) a una massima velocita' di 1528 B/s o 1.5kB/s. Questo e' il risultato di anni di studi sul comportamento dei LED e della loro duplice natura, spero possa esservi utile  :) .

Title: Re: PJON - Protocollo di comunicazione opensource TEST/COMMENTI/CRITICHE
Post by: franketto on Oct 30, 2017, 07:59 pm
Aggiungiamo pure che finalmente è perfettamente usabile in una configurazione RS485 con la modalità async per ricevere gli ack di conferma dei messaggi inviati.
Pure in configurazioni multimaster di molte decine di metri.
Testato per ora con 4 nodi: 3nano e 1Mega, comandati da pc in un contesto di domotica di una 50a di metri.
Ogni nodo può gestire le temperature, dei motori di apertura porte, illuminazione, riscaldamento, sensori di allarme o presenza, apertura tapparelle etc etc
Ogni nodo può ricevere comandi dal pc (che a sua volta può darli da smartphone, da pc stesso o da remoto) e/o inviare comandi autonomamente o di risposta a interrogazioni di stato, oltre che essere comandato in locale con pulsanti vari.
Prima ho usato sistemi con centralina centralizzata, poi comunicazione 1-wire, adesso finalmente RS485 con nodi Arduino sparsi.
Ringrazio quindi gioscarab per avermi permesso di realizzare quest'ultima versione del sistema in questa modalità più sicura e versatile!
Ottimo lavoro! ;)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: luigi67 on Dec 08, 2017, 10:22 pm
Ciao
Vorrei utilizzare la tua libreria per inviare da un Arduino Yun messaggi di allarme su una mail qualora un sensore (gas, acqua etc.) sia in allarme, è utile in questo caso?
Ciao
Luigi
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on Feb 16, 2018, 09:13 am
Gioscrab,esiste una guida in italiano della tua interessantissima libreria?
Vorrei utilizzarla per scambiare dati seriali con due arduini uno, utilizzando una rs422 in maniera che entrambi siano sia master che slave in maniera alterna (al bisogno)...
Pensi sia fattibile?
Se si come posso fare??
Grazie.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on Feb 16, 2018, 09:29 am
Vorrei utilizzarla per scambiare dati seriali con due arduini uno, utilizzando una rs422 in maniera che entrambi siano sia master che slave in maniera alterna (al bisogno)...
>manolomao: ... credo tu abbia le idee poco chiare, vai prima a leggere la risposta che ti ho dato nell'altro thread sul concetto di master/slave e sulla RS422/RS485.

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on Feb 16, 2018, 11:07 am
 :o  Ok Guglielmo...
Scusa...
però se esiste una guida in italiano sulla libreria ne sarei grato..
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on Feb 20, 2018, 04:51 pm
Ciao Maolomao! Scusate il ritardo nella risposta. Siamo in corsa per il rilascio della versione 11, che conterra' moltissime novita' tra cui il supporto per network switch e router (entrambi in grado di funzionare trasparentemente qualsiasi esso sia il datalink in uso tra quelli supportati).

Purtroppo anche se sono italiano  :) , non ho avuto il tempo di scrivere una guida o la documentazione in italiano.

Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on Apr 27, 2018, 01:28 pm
Ciao tutti.
Dopo svariati tentativi e sbattimenti di testa contro il muro, sono riuscito a far scambiare i dati tra i due arduino con PJON.
Però c'è qualcosa che non mi convince...se premo un pulsante mi aspetto che dall'altra parte reagisca accendendo il relè, ma questo lo fa con un ritardo o a volte rimbalza; ho guardato sul monitor seriale ed ho visto che ci sono tanti errori e credo che il fatto di attuare in ritardo sia dovuto a questo, tanti pacchetti vengono persi o arrivano in ritardo...non so..
il monitor seriale mi dice :
Code: [Select]
Packet buffer is full, has now a length of 5
Possible wrong bus configuration!
higher PJON_MAX_PACKETS if necessary.

e a volte anche di aver perso la comunicazione con ID 20 (che sarebbe uno dei due arduino).
Quindi quando va a buon fine funziona perfettamente, quando compaiono tutti questi errori si rallenta il tutto...
Chi può aiutarmi a districarmi in questo problema??Date le mie scarse capacità da programmatore, sono in un vicolo cieco...
Per farvi capire.....ho provato a partire con un semplice pulsante, per poi mandare una stringa con diversi comandi e ricevere dati da sensori di temperatura... quindi sono partito dal facile, ma gli errori li ho sempre avuti...
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on May 02, 2018, 10:52 pm
Ciao manolomao, controllerei il rate di trasmissione di ogni modulo e cercherei di ridurlo al minimo necessario. Se tutti i device trasmettono ininterrottamente e' facile che avvengano delle collisioni e un invio non vada a buon fine. Ma avrei bisogno di dare un occhio al tuo codice per darti consigli piu' precisi, per favore postalo qui in modo che possa darci un' occhiata.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on May 03, 2018, 04:56 pm
Ciao Mauro ho dato un'occhiata al tuo codice. Stai spedendo un pacchetto ogni giro di loop, cosi' non puo' funzionare. busRS485.update(); ritorna il numero di pacchetti che sono ancora da spedire, quindi se invii con send un pacchetto, update ritornera' 1 finche' quel pacchetto non e' stato inviato con successo. Invece che chiamare send a ogni ciclo, chiama come in quasi tutti gli esempi viene mostrato:
 
if(!bus.update()) // If all packets are delivered, send another
    bus.send(44, content, 20);

Cerca anche di avere una sola chiamata a receive e update per loop, usane di piu' solo se strettamente necessario cosi' hai chiaro cosa sta succedendo e in che ordine.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: Cina on Jun 19, 2018, 05:53 pm
Ciao Guglielmo!
Seguo con interesse i tuoi post e sono contento che ce ancora gente che ha voglia di inventare cose nuove..come Te.
E da un po' di tempo che provo a fare una rete con il tuo bellissimo  :)  protocollo.
Purtroppo non essendo un grande esperto mi trovo con qualche bel insuccesso.
Mia idea e collegare 4-5 Arduino Nano (slave) con uno Master in una rete usando SoftwareBitBang (un cavo) e tutti collegati tra loro su pin D12.
Sulla stessa scheda del Master si trova anche un Nodemcu ESP8266 che mi serve per trasmissione via WiFi.
Arduino Nano (Master) raccoglie dei dati dai vari Slave e da i sensori Analogici e "passa i dati al Esp8266.
In questo momento sto testando la trasmissione tra Master e Esp8266.
Riesco ad inviare e ricevere, ma una quantità di dati molto piccola.
Quindi se invio un numero lo ricevo, ma volendo inviare 16 valori di ingressi analogici da Master (Arduino Nano) al Esp8266 su stessa scheda ci vuole molti secondi per riceverli tutti e spesso non li ricevo neanche.
Sono sicuro che il modo ce, ma da qualche parte sbaglio e non riesco comunicare.
Ti chiedo quale sarebbe il  modo più giusto per inviare da Nano a Esp8266 questi 16 valori analogici.
Chiedo inoltre se possibile e in che modo trasmettere/ricevere una struttura (Struct) , e di che dimensione massima può essere … con il tuo protocollo.
Grazie mille per la risposta e mi scuso in anticipo se chiedo cose ovvie.
Allego i due codici (ridotti).
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on Jun 19, 2018, 06:05 pm
Ciao Guglielmo!
... stai confondendo le persone ... io non c'entro nulla ... ::)

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: Cina on Jun 20, 2018, 12:19 pm
... stai confondendo le persone ... io non c'entro nulla ... ::)

Guglielmo
Hai ragione! Scusa... Il mio era rivolto al gioscarab...
Ringrazio anche Te perchè i Tuoi post, spesso mi hanno aiutato.
Spero che gioscarab, mi risponde al post precedente...
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on Jul 13, 2018, 01:39 pm
Ciao Cina, scusami tanto per il ritardo nella risposta. Ho letto il codice che hai linkato. Vedo che utilizzi nel setup del master usi:
Code: [Select]
bus.set_asynchronous_acknowledge(true);
 

Considera che di default PJON utilizza l'acknowledgment sincrono, che puo' essere opzionalmente disattivato. L'utilizzo della combinazione acknowledge sincrono + asincrono e' definito come "Recursive acknowledgment pattern" che e' pensato per soddisfare requirement di reti complesse e non credo sia per te necessario. Il Recursive acknowledgment pattern puo' essere utile quando uno slave in una rete complessa composta da tanti nodi, switch o router interconnessi vuole avere la sicurezza di aver passato il messaggio alla piu' vicina fonte di connettivita', per poi aspettare un pacchetto di acknowledgment asincrono che confermi la ricezione da parte del destinatario. Questa procedura puo' ridurre la quantita' di overhead e ritrasmissioni che possono avvenire in alcuni casi utilizzando il solo ack asincrono.

In sintesi io proverei a non utilizzare l'ack asincrono e vedere cosa succede.
Fammi sapere, se hai bisogno di supporto real time scrivimi su gitter.

Se ti serve configura PJON per assegnare un id ad ogni pacchetto, vedi documentation/configuration: https://github.com/gioblu/PJON/blob/master/documentation/configuration.md (https://github.com/gioblu/PJON/blob/master/documentation/configuration.md)
Title: PJON Raspberry + Arduino
Post by: cesco on Sep 05, 2018, 10:03 pm
Un saluto a tutti.

Una domanda a livello di logica.

Vorrei provare a realizzare una piccola rete di sensori di temperatura (3 arduino mini pro con DS18B20) e vorrei utilizzare la libreria PJON. Come "Master" vorrei usare una Raspberry per creare una pagina WEB di controllo e di comando per i led delle schede Arduino.
Per raspberry ho visto che bisogna usare wiringPi (https://github.com/gioblu/PJON/wiki/Raspberry-Pi-interfacing) quindi per la stampa sulla pagina web potrei utilizzare l'output dello script in esecuzione su raspberry, ma se volessi "comandare", quindi inviare un comando ad uno degli arduino per l'accensione del led, come potrei fare dalla raspberry (lato web non è un problema il come), mi interessava proprio come inviare dei comandi allo script che è in esecuzione con wiringPi.

Grazie per i suggerimenti.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on Sep 06, 2018, 06:30 am
>cesco: ho riunito io il tuo thread con quello relativo alla PJON dato che è quello dove l'autore fornisce supporto ...

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on Sep 06, 2018, 09:24 am
mi interessava proprio come inviare dei comandi allo script che è in esecuzione con wiringPi.

Grazie per i suggerimenti.

Se per script in esecuzione intendi la pagina web visualizzata nel browser (e relativo javascript) direttamente non riesci è proprio impossibile tecnicamente, deve essere la pagina che interroga il server per sapere se occorre fare qualcosa (AJAX, reload, ecc. a te la scelta).
Lato server io ho affrontato la cosa creando un demone che si occupa di inviare i messaggi via seriale, e quindi poi con relativo adattatore sulla rete RS485) ai dispositivi e nel contempo controlla che non ci siano messaggi in arrivo (tramite la libreria PJON), nel caso vi siano messaggi da processare richiama delle apposite pagine (PHP nel mio caso) che si occupano di aggiornare il database con le informazioni in arrivo (attivazioni, temperature, ecc.).
Lato client via javascript tramite timer ogni minuto circa vado a invocare (AJAX) una pagina sul server che mi restituisce le informazioni aggiornate per la sezione di pagina che mi interessa.
Per il momento sta funzionando tutto bene con le sole temperature, ma ho dovuto impostare PJON con l'acknowledge sincrono e asincrono disattivato per non ricevere errori in ricezione/trasmissione dei pacchetti in quanto il demone per non sovraccaricare la CPU effettua il polling dei dati una volta al secondo.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: cesco on Sep 06, 2018, 08:50 pm
Grazie,. Scusa ma avevo paura fosse off topic.

>cesco: ho riunito io il tuo thread con quello relativo alla PJON dato che è quello dove l'autore fornisce supporto ...

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: cesco on Sep 06, 2018, 08:57 pm
Se per script in esecuzione intendi la pagina web visualizzata nel browser (e relativo javascript) direttamente non riesci è proprio impossibile tecnicamente, deve essere la pagina che interroga il server per sapere se occorre fare qualcosa (AJAX, reload, ecc. a te la scelta).
Lato server io ho affrontato la cosa creando un demone che si occupa di inviare i messaggi via seriale, e quindi poi con relativo adattatore sulla rete RS485) ai dispositivi e nel contempo controlla che non ci siano messaggi in arrivo (tramite la libreria PJON), nel caso vi siano messaggi da processare richiama delle apposite pagine (PHP nel mio caso) che si occupano di aggiornare il database con le informazioni in arrivo (attivazioni, temperature, ecc.).
Lato client via javascript tramite timer ogni minuto circa vado a invocare (AJAX) una pagina sul server che mi restituisce le informazioni aggiornate per la sezione di pagina che mi interessa.
Per il momento sta funzionando tutto bene con le sole temperature, ma ho dovuto impostare PJON con l'acknowledge sincrono e asincrono disattivato per non ricevere errori in ricezione/trasmissione dei pacchetti in quanto il demone per non sovraccaricare la CPU effettua il polling dei dati una volta al secondo.
Grazie delle info. Immaginavo un qualcosa del genere, ma da riga di comando come passo i dati al demone, non mi interessa la sintassi, più che altro capire come tramite wiringPI posso leggere stringhe (dati) inviate da riga di comando, o qualcosa del genere insomma.volevo provare a non usare rs485 ma SoftwareBitBang. Grazie
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on Sep 07, 2018, 09:07 am
Stai mischiando pere e mele, se sei su linea di comando non ti serve il demone (quello serve per stare in ascolto in maniera continuativa dei messaggi in arrivo) ma un semplice programma in C che lo richiami con i parametri che ti servono, all'avvio leggi gli argomenti passati dalla linea di comando e li trasmetti via PJON (che ti rende trasparente il mezzo fisico di trasmissione, fai la send che poi PJON sia configurato per il bitbang, seriale, ecc. a livello di programmazione non ti cambia nulla).
Se invece da un cliente cha sta visualizzando la pagina web ti viene richiamata una pagina sul server per effettuare qualcosa e quest'ultima deve trasmettere qualcosa con PJON allora entra in gioco il demone che essendo sempre attivo starà in ascolto delle tue richieste e invierà tramite PJON il comando (come prima il mezzo fisico non importa).
Come può ascoltarti un demone? Sta a te deciderlo, il modo più rozzo possibile (mi vergogno quasi a scriverlo) è che la pagina web scriva una file con un nome a caso su un determinato percorso e il demone ogni tanto va a vedere se nel percorso c'è almeno un file da processare, lo legge e invia il comando. Perché fa schifo? Perché è asincrono, la pagina web deve stare li ad aspettare che qualcuno le dica che il comando è stato processato (Es. aspetta che il file venga cancellato, aspettache un altro file venga creato e lo cancella, ecc.) ma è la via più semplice da programmare per chi ha poca esperienza di C ecc.
Altra strada è aprire un socket dalla pagina web inviare il comando e in base alla risposta comuicare che il comando è stato eseuguito e se è fallito oppure no. Il demone dal canto suo aspetta la connesione tramite socket, la acetta, riceve il comando da inviare, lo trasmette con PJON e sul medesimo socket comunica ciò che è successo (comando OK, comando trasmetto p quello che più ti piace), non è difficile neppure questo, si trovano esempi a iosa su internet ma dipende chiaramente dalla tue capacità/aspetative.
Comuque per iniziare scordati pure la parola demone, puoi fare il tuo programma lanciarlo da linea comando di un terminale, apri la pagina web o un altro terminale e provi ad interagire (crei il file, il socket o la "cosa" che hai deciso di usare per comunicare con il tuo programma, questo potrà scriverti nella console che sta ricevendo la connessione, processando il comando, ecc., invia su PJON (e l'avvenuto invio lo verifichi sul ricevente) in modo da renderti più facile la vita di "debugger", in un secondo momento lo "trasformi" in demone
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: cesco on Sep 07, 2018, 03:13 pm
Ok grazie mille, spiegazione esaustiva, spero di riuscire presto a fare delle prove e condividere l'esperienza. Per caso si sa se la SoftwareBitBang verrà introdotta su Raspberry, o comunque su Linux in generale?

Grazie
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on Sep 28, 2018, 02:08 pm
Ciao Cesco, scusa la risposta in mega ritardo. Su RPI non stiamo attivamente lavorando ad implementare SoftwareBitBang. Ad oggi e' necessario avere un qualsiasi altro mcu supportato che faccia da switch:
Code: [Select]
SoftwareBitBang <-> SWITCH <-> ThroughSerial <-> Raspberry Pi
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on Oct 29, 2018, 08:16 am
Ciao, vorrei fare una domanda sulla gestione degli errori: quando inteviene l'errore "CONNECTION_LOST"?
Ho provato a far visualizzare questo errore per marcare la mancanza di comunicazione tra due arduini, ma non mi appare...ho seguito il setting degli errori come da specifica, poi ho tolto il cavo che mette in comunicazione i due arduini e nulla...non mi segnala nulla.
mentre se ricollego il cavo parte a comunicare correttamente...
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gioscarab on Nov 05, 2018, 06:21 pm
Ciao manolomao se stai usando send_packet or send_packet_blocking e' normale peche' queste chiamate blocking usano il loro valore di ritorno per comunicarti il risultato della trasmissione, vedi:
https://github.com/gioblu/PJON/blob/master/documentation/data-transmission.md

Rileggendo la documentazione mi rendo conto che non e' specificato che gli errori vengono emessi solo dalle chiamate non-blocking, aggiorno subito aggiungendo la specifica mancante, grazie mille :)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on Nov 06, 2018, 08:00 am
Ciao Gioscarab,uso questa istruzione:
Code: [Select]
busRS485.send(20,car_buffer,strlen(car_buffer));
Quello che volevo fare è gestire la mancanza di comunicazione....una volta che cade, mi visualizza l'errore di comunicazione...
Come posso fare???
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on Nov 06, 2018, 09:54 am
Come posso fare???
Come gestire l'errore sta a te, ovvero la libreria prevede un segnale di acknowledge sincrono, asincrono oppure anche senza segnale di "messaggio ricevuto", in base a come la si configura.
Se non ridefinito è previsto l'acknowledge sincrono, quosto significa che se un dispositivo non è disponibile manca il ritorno e la libreria tramite la callback dell'errore te lo segnala, a questo punto sta a te decidere cosa fare, ad esempio potresti prevedere un certo numero di tentativi di reinoltro del messaggio (magari distanziando gli invii con scala logaritmica un po' come fanno i cellulari quando richiamano in automatico un numero occupato) e doco questo numero di invii segnali la cosa. Oppure potresti subito segnalare l'anomalia senza tentare l'invio successivo, insomma dipende da cosa fanno i tuoi dispositivi e da quanto è grave l'assenza di comunicazione per il corretto funzionamrnto del tutto.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on Feb 21, 2019, 04:47 pm
Domanda: posso inviare una struct come payload in PJON?
Se si, come fare?
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on May 07, 2019, 02:00 pm
Ciao tutti, sto vedendo di fare un restaling di un mio progetto vecchio, in cui erano previsti tre arduino che dialogavano tra di loro utilizzando la PJON e il bus RS485.
Tutto bene, e mi ha dato modo di approfondire la conoscenza di questo protocollo...
Ora vorrei cambiare la gestione della comunicazione e vi chiedevo se fosse possibile farlo: un arduino monta l'HC12, uno RS485 ed il terzo (diciamo il centrale) ha sia un RS485 che l'HC12.
Pensate che sia gestibile con PJON?
Il mio dubbio è il micro nel "mezzo" che deve gestire due porte softgwareserial con due interfacce diverse (RS485 e HC12)...
Come posso fare??
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 07, 2019, 02:16 pm
PJOn sicuramente può gestire la cosa, tra le altre cose l'arduino "centrale" può avere a bordo PJOn in configurazione "brigdeswitch" o "router" che fa si che si possa occupare nativamente di instradare le comunicazioni da verso due reti differenti come nel tuo caso (wired/wirless ma anche due bus wired ad esempio) in  modo del tutto trasparente, ovvero non dovrai scrivere manco mezza linea di codice se non quelle per configurare la libreria PJON.
Il vero problema sono le due softwareserial che non possono coesistere nel modo a cui servono a te. Ovvero puoi definire N softwareserial ma solo una è attiva e abilitata alla ricezione dei dati, è stato l'inghippo che mi ha costretto a passare da una uno a una mega in un mio progettino.
Ti consiglio quindi di pensare a sostituire l'arduino "cenrale" che penso sia una uno o una nano con un'altra shceda con almeno due seriali hardware in questo modo la seriale 0 la tieni libera per debug e caricamento firmare, la seriale 1 ci attacchi ad esempio la RS485 e con la softwareserial gestisci l'HC12.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 07, 2019, 02:18 pm
Se cerchi un'alternativa con form factor piccolo prova a guardare questa (https://www.futurashop.it/Pro-Midi-1284P-7300-PROMIDI1284P) chi l'ha fatta sa il fatto suo  ;)  :)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 07, 2019, 02:25 pm
Ho usato un termine errato non è bridge ma switch se cerchi la documentazione relativa è qui (https://www.pjon.org/routing.php)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on May 07, 2019, 04:49 pm
PJOn sicuramente può gestire la cosa, tra le altre cose l'arduino "centrale" può avere a bordo PJOn in configurazione "brigdeswitch" o "router" che fa si che si possa occupare nativamente di instradare le comunicazioni da verso due reti differenti come nel tuo caso (wired/wirless ma anche due bus wired ad esempio) in  modo del tutto trasparente, ovvero non dovrai scrivere manco mezza linea di codice se non quelle per configurare la libreria PJON.
Il vero problema sono le due softwareserial che non possono coesistere nel modo a cui servono a te. Ovvero puoi definire N softwareserial ma solo una è attiva e abilitata alla ricezione dei dati, è stato l'inghippo che mi ha costretto a passare da una uno a una mega in un mio progettino.
Ti consiglio quindi di pensare a sostituire l'arduino "cenrale" che penso sia una uno o una nano con un'altra shceda con almeno due seriali hardware in questo modo la seriale 0 la tieni libera per debug e caricamento firmare, la seriale 1 ci attacchi ad esempio la RS485 e con la softwareserial gestisci l'HC12.
Mi sembrava che non fosse così semplice  :smiley-sweat:
Grazie Fabpolli, sempre molto gentile...
Dovrò rivedere la cosa e valutare come muovermi...
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 07, 2019, 05:05 pm
Mi sembrava che non fosse così semplice  :smiley-sweat:
Grazie Fabpolli, sempre molto gentile...
Dovrò rivedere la cosa e valutare come muovermi...

Se metti qui le caratteristiche del centrale e eventuali dubbi che non ti permettono un rapido cambio di piattaforma si può vedere se in molti si trova una soluzione migliore.
Per la parte software più semplice di come PJON ti permette non mi viene in mente nulla, puoi usare due bus separati e gestire tu quli e qunado inviare messaggi tra un bus e l'altro o demandare il tutto alla libreria in modo automatico, meglio di così :)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on May 08, 2019, 10:41 am
Thread "promosso" alla sezione Megatopic. :)

Buona continuazione.

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on May 16, 2019, 01:20 pm
Se metti qui le caratteristiche del centrale e eventuali dubbi che non ti permettono un rapido cambio di piattaforma si può vedere se in molti si trova una soluzione migliore.
Per la parte software più semplice di come PJON ti permette non mi viene in mente nulla, puoi usare due bus separati e gestire tu quli e qunado inviare messaggi tra un bus e l'altro o demandare il tutto alla libreria in modo automatico, meglio di così :)
Fabpolli pensavo di creare a questo punto una rete con gli NRF24,però a questo punto credo debba abbandonare PJON...
Tornando al discorso PJON con gli HC12 (anche per future applicazioni) ho messo sul device 1 questo setting
Code: [Select]

#include <LiquidCrystal_I2C.h>//Libreria LCD I2C
#include <SoftwareSerial.h>
#include <EEPROM.h>           
#include <Wire.h>

#define PIN_RX_HC12 11
#define PIN_TX_HC12 10
#define busHC12_ID 30             //display
#define bus_HC12_LATENCY 1000

#define TS_RESPONSE_TIME_OUT 200000

#define PJON_PACKET_MAX_LENGTH 63  //aggiunto
#include <PJON.h>

poi questo
Code: [Select]

LiquidCrystal_I2C lcd(ind_lcd, 20, 4);   
SoftwareSerial HC12Serial(PIN_RX_HC12,PIN_TX_HC12);
PJON<ThroughSerial> busHC12 ;

Nel setup
Code: [Select]
busHC12.set_error(error_handler);                       
  busHC12.set_receiver(receiver_function);               
  busHC12.set_synchronous_acknowledge(false);
  busHC12.begin();     //avvia PJON

Poi nel loop
Code: [Select]

busHC12.receive(TS_TIME_IN + bus_HC12_LATENCY);
busHC12.update();
....
....
//per spedire il dato
if(!busHC12.update()){
 busHC12.send(20,caratteri,strlen(caratteri)+1);}

Funziona??
o non ho capito nulla???
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 16, 2019, 02:03 pm
Non funziona non hai associato la seriale dell'HC12 alla libreria, guarda l'esempio dell'IDE PJON->ARDUINO->Local->ThroughSerial->HC-12-Blink (o ogni altro esempio presente basato su HC12) oppure anche qui (https://www.pjon.org/ThroughSerial.php)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on May 16, 2019, 03:15 pm
Nel setup
Code: [Select]

bus.strategy.set_serial(&busHC12);

Giusto??
Tornando sul discorso
Se metti qui le caratteristiche del centrale e eventuali dubbi che non ti permettono un rapido cambio di piattaforma si può vedere se in molti si trova una soluzione migliore.
Per la parte software più semplice di come PJON ti permette non mi viene in mente nulla, puoi usare due bus separati e gestire tu quli e qunado inviare messaggi tra un bus e l'altro o demandare il tutto alla libreria in modo automatico, meglio di così :)
Arduino centrale (chiamo2) dovrebbe comunicare con arduino 1 via radio (o wi-fi) e arduino 3 via rs485 (o anch'esso via radio-wi-fi). Arduino 2 ha degli attuatori su I2C (con due PCF8574) e due uscite digitali che comandano dei led.
Arduino 2 legge una tensione sull'analogica ed invia a arduino 1 lo stato di questo segnale (se supera una soglia imposta).
Ovviamente arduino 2 fa da trammite quando i dati sono destinati da arduino 1 a arduino 3.
Spero di essere stato chiaro sulle caratteristiche e funzionamento.
I miei dubbi sono:
-lavorare con due softwareserial su arduino nano
-configurare correttamente i tre arduino per farli parlare a dovere (come già fanno ora con la rs485)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 16, 2019, 04:06 pm
Mi sono perso nella tua descrizione  :)
Comunque le risposte ai tuoi dubbi sono:
Non puoi lavorare con due SoftwareSerial contemporaneamente, o meglio solo una è in ascolto quindi se da una ricevi e basta e con l'altra invii e basta allora si puoi ma se devi contemporaneamente ricevere da entrambe e senza saperlo con altri mezzi allora non funziona (che è la cosa che mi ha fatto spostare su una Mega per un mio progetto)
Configurare i tre arduino sicuramente puoi se quello che fa da "ponte" lo configuri come switch come ti ho indicato (se non ricordo male) seguendo la documentazione di PJON sul relativo sito di riferimento, magari in fase iniziale non ti tornerà tanto semplice ma non è impossibile o troppo difficile da fare, se poi puoi farti un progetto demo con tre arduino per fare le prove allora è ancora meglio  ;)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: manolomao on May 16, 2019, 04:12 pm
Mi stai illuminando!!!
Arduino 2 comunica con arduino 1 in maniera bidirezionale, mentre arduino 2 con arduino 3 trasmette solo...
Quindi secondo te riesco a gestire il tutto????
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 16, 2019, 04:16 pm
Si ma quando stai trasmettendo da arduino 2 ad arduino 3 se ti arrivano messaggi da Arduino 1 li perdi irrimediabilmente, se invece Arduino 1 ti invia qualcosa solo su richiesta di Arduino 2 allora riesci a gestirlo.
Io comunque passerei ad una scheda con almeno due seriali hardware in modo da averne solo una software, una HW per il debug e l'altra HW per sostituire una SW, tanto esiste una scheda con form factor molto simile al nano ma con due seriali HW, poi vedi tu
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: Standardoil on May 16, 2019, 04:43 pm
Se ricordo bene c'è una libreria, la "altsoftserial" che permette trasmissione r ricezione contemporanee su più canali
https://www.pjrc.com/teensy/td_libs_AltSoftSerial.html (https://www.pjrc.com/teensy/td_libs_AltSoftSerial.html)
provate a darci uno sguardo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: fabpolli on May 16, 2019, 04:47 pm
Interessante, ma da quel che ho letto ha vincoli stringenti sul baudrate per usarle in contemporanea occorre prestarvi attenzione! OP Avvisato mezzo salvato ;) :)
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: steve-cr on May 17, 2019, 07:15 pm
In tutta franchezza non vedo la necessità di inventarsi un nuovo protocollo di comunicazione quando ne esistono molti free, perfettamente documentati, completi di librerie per Arduino stracollaudate e affidabilissime, tanto per citarne uno il modbus.
Far dialogare una rete con un sistema onewire sulle lunghe distanze, sopratutto in ambito casalingo, è volersi fare del male da solo, oltre alla eccessiva lentezza della linea c'è la scarsa affidabilità, anche in questo caso esistono soluzioni super collaudate e iperaffidabili, p.e. la RS485.
Scusate, ma non ho resistito !!! Per la serie "Non ragioniam di lor, ma guarda e passa..."

Ho visto solo adesso questo thread e lo trovo notevole!
Cioè, abbiamo un genio qui dentro e non lo sapevo?
Complimenti davvero! Con calma comincerò dall'inizio il thread, me lo leggerò tutto e mi farò una cultura anche su PJON
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: ivanmeneo on May 27, 2019, 10:30 am
Come consigliatomi da Guglielmo in risposta ad un mio post https://forum.arduino.cc/index.php?topic=616932.0 (https://forum.arduino.cc/index.php?topic=616932.0), faccio i complimenti all'autore del thread e a tutto lo studio e l'apporto degli altri utenti per lo sviluppo di questo metodo di comunicazione.
Ho iniziato ad interessarmi da poco e lo trovo molto stimolante.
Vorrei applicarlo appunto al mio progetto che si propone di far comunicare tra loro circa una ventina di MCU's Arduino in modalità Slave, con un Master (..inizialmente pensavo ad uno Yun Rev2) che richiede ad ogni Slave le informazioni ricavate da un pacchetto di sensori uguali, posti appunto su ogni Slave.

Avevo pensato ad una comunicazione wireless in alternativa ad una I2C wired.
Sto ancora studiando che tipo di moduli hardware utilizzare (...tipo BT HC-05 oppure nRF24, per non spendere troppo il budget con gli XBee), perché ero partito con degli Arduino WiFi Rev2 ma ho trovato non poche difficoltà!

Resto in ascolto per suggerimenti ed intanto mi rileggo bene la comunicazione PJON!  ;)

Grazie in anticipo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on May 27, 2019, 10:40 am
... in alternativa ad una I2C wired.
... questa cosa dimenticala subito! Il bus I2C è nato per collegare chip sulla stessa board, poi utilizzato anche per sensori a piccola distanza (parliamo di 10/20 cm) ma certamente NO per fare collegamenti a distanza (... anche se esistono chip dedicati per poter collegare sensori a distanze superiori).

Se puoi "cablare", allora pensa ad una molto più robusta ed affidabile RS485 che metti in piedi semplicemente con un doppino telefonico ;)

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: Standardoil on May 27, 2019, 10:54 am
Parzialmente OT
Futura regola tre dello aiutateci ad aiutarvi:
Descrivi il problema, non incaponirti su una soluzione
Che si può cablare è cosa nuova?
Non me lo ricordavo
Fine OT
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: ivanmeneo on May 27, 2019, 10:57 am
... questa cosa dimenticala subito! Il bus I2C è nato per collegare chip sulla stessa board, poi utilizzato anche per sensori a piccola distanza ...
Grazie per la precisazione, sempre utilissima Guglielmo!
Purtroppo in rete molte volte trovi info discordanti o approssimative, che mi avevano indotto a pensare di poter collegare tutti  i microcontrollori su una rete cablata I2C, ipoteticamente con 2 semplici fili, per intenderci.
Ora sto studiando la comunicazione wireless, perché la wired mi crea non pochi problemi. Ma non lascio nulla al caso, visto che comunque, utilizzando per esempio moduli nRF24, il budget andrebbe comunque a crescere, moltiplicato per schede wireless, adattatori SPI e dispositivi vari.

Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on May 27, 2019, 11:27 am
Due cose ...

1. Quando si quota un post, NON è necessario riportarlo (inutilmente) tutto; bastano poche righe per far capire di cosa si parla ed a cosa ci si riferisce. Gli utenti da device "mobile" ringrazieranno per la cortesia ;)

2. prova a prendere in considerazione gli economici, ma potenti HC-12.

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: Standardoil on May 27, 2019, 11:35 am
Mi domandavo infatti perché tra tutti quelli che lo OP aveva preso in considerazione mancassero proprio HC12 e i loro gemelli HC11
Che però qui sarebbero un po' OT, visto che non serve molto SW per farli andare
Se lo OP da uno sguardo, magari, al mio "era stagione di pin remoti" trova idee a cariolate
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: ivanmeneo on May 27, 2019, 12:29 pm
Si Guglielmo, errori da nuovo utente il fatto del quote!
Aggiungo che nella mia ricerca ho incluso gli HC-08, con un riferimento ad un tuo post dove ne spiegavi il funzionamento in merito a questi moduli. E sono andato avanti fino agli HM-10. Gli HC-12 gli avevo scartati in un primo momento perché mi ero focalizzato sugli HM-10 (che però se non erro credo siano di tipo BLE), e vedendoli provvisti di antenne per un uso "long range" e con costi superiori, mi erano parsi sovradimensionati per le mie esigenze.
Però se me li consigli mi studio il software di funzionamento e faccio qualche prova.
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: gpb01 on May 27, 2019, 12:40 pm
... e vedendoli provvisti di antenne per un uso "long range" e con costi superiori ...
... costi superiori? :o

Stiamo parlando di moduli che si trovano normalmente (dagli "spacciatori" cinesi :D) intorno ai 2.5 US$ !

Guglielmo
Title: Re: PJON - Multi-master, multi-media network protocol stack
Post by: ivanmeneo on May 27, 2019, 01:10 pm
Guglielmo di solito tendo a non utilizzare "spacciatori" cinesi con tempi di attesa consegna moduli superiori a 10gg, perché vorrei ridurre i tempi il più possibile. Infatti mi ero imbattuto su amazon in moduli da circa 9/14 euro.