xbee e user guide

Il 26/12/2012 15:46, Marco Trapanese ha scritto:

Aggiungo anche altre due cose strane:

tramite X-CTU quando eseguo il comando "discovery" ottengo la lista dei due nodi quasi istantaneamente (max 1 secondo). Quando invio io il comando impiega minimo 5-6 secondi a rispondermi (sempre solo con l'indirizzo "sbagliato").

Inoltre di tanto in tanto ricevo dei pacchetti con il byte di status che assume valori non descritti nella guida. Lì sono infatti previsti i valori da 0 a 3. Mentre ho ricevuto dei pacchetti con valore 4 e 0x80.

Non riesco a trovare dove spiega il significato di questi valori...

Marco

beato te..io sono rimasto ai transistor al germanio

AAA CERCASI COPPIA OC 70/71 :-)

Il 26/12/2012 16:18, Marco Trapanese ha scritto:

Terza... Frame 0x95 (Node Identification Indicator)

Dopo il parent 16-bit address (0xFFFE) secondo la guida ci dovrebbe essere subito il checksum mentre io ho altri 6 byte prima di quello...

Marco

Un bel giorno Marco Trapanese digitò:

Non conosco i moduli, ma essendo rintontito dal cibo devo pur tentare di riattivare il cervello, magari puoi estrarre quasi casualmente qualche contributo utile:

Specificando una length a 16 bit mi sembra improbabile, avrebbero usato solo 8 bit. Potresti provare a spedire pacchetti sempre più lunghi e vedere quando il modulo ti restituisce picche. Oppure se il tuo obiettivo è gestire solo un subset di risposte delle quali conosci la dimensione, puoi semplicemente ricevere tutti i pacchetti "sconosciuti" senza memorizzarli ma solo calcolando il checksum e verificandolo alla fine.

Aspetti abbastanza? La documentazione dice che i moduli aspettano un tempo random prima di rispondere, e di default è un tempo lungo (13 s).

Sempre seguendo la logica del "se non è specificato è il massimo consentito", apparentemente ne puoi accodare quanti ne può contenere il pacchetto, quindi circa 64k di dati.

Qui non conosco i dispositivi e non ti so aiutare. Dipende anche da quanta memoria hai; se ne hai a volontà probabilmente ti conviene "riassemblare" tutti i pacchetti nella libreria, un po' come accade con TCP/IP. Specialmente se i pacchetti arrivano fuori ordine sarebbe sporco e brutto doverli gestire a livello applicazione...

Il 26/12/2012 18:37, dalai lamah ha scritto:

Ovviamente se i pacchetti li mando io il "payload" lo conosco e compongo il messaggio di conseguenza. Mi riferivo alle risposte dei comandi AT (inviati comunque via API).

Mi interessa sapere in questo caso quale può essere la massima lunghezza della risposta.

A naso: il parametro più lungo è NI (fino a 20 caratteri + \n). Il comando ND mi risponde con 18 byte fissi più l'NI. Da qui avevo dedotto circa 40 caratteri... ma non è scritto, o almeno non l'ho trovato.

Si, ne sono consapevole. Il pacchetto mi arriva dopo 5-6 secondi, ma se lascio il terminale aperto non accade più nulla nemmeno dopo parecchi minuti. Ho fatto la prova con un altro modulo e il comportamento è identico, per cui immagino che sbaglio qualcosa io, ma non riesco a capire dove.

Non mi è nemmeno chiaro se il modulo stesso debba rispondermi. La guida dice: "The following information is reported for each module discovered". Ma non ho bisogno di "scoprire" il modulo tramite cui invio il comando, non avrebbe senso. Anche perché non avrei modo (semplice) per distinguerlo dagli altri.

Dici? Mi piacerebbe vederlo scritto (non che mi servano 64k! ma giusto per conoscere i limiti). Certo che la documentazione è pessima... prova a trovare quale è la massima corrente che possono erogare i pin di I/O :-/

Mettiamola così: nel 99,9% dei casi ogni pacchetto contiene tutta l'informazione necessaria. Per cui sono rarissimi i casi in cui devo "riassemblare" più pacchetti.

Anche perché se il payload fosse distribuito su più pacchetti significa che è il contenuto a essere lungo. Ma quest'ultimo è di competenza dell'applicazione non certo della libreria di comunicazione.

Probabilmente potrei tranquillamente ignorarlo e lavorare con i timeout.

Ciao e grazie degli spunti! Marco

Il 26/12/2012 18:37, dalai lamah ha scritto:

Ho aperto un ticket alla Digi. Hanno risposto subito... ma ragazzi! Prima mi aveva detto che la risposta è di 1 solo byte. Poi gli ho fatto l'esempio del comando ND che può arrivare a quasi 40 byte e ha rettificato: "beh allora ti sei risposto già tu, sarà attorno a 40 byte" :-/

Qui era un errore mio: inviavo il comando come un remote AT request, anziché come comando locale. Per cui veniva eseguito dall'altro modulo che - correttamente - mi trovava quello a cui ero collegato!

Invece, cavandogli le informazioni poco a poco, si è scoperto che il massimo consentito è determinato dal buffer della UART: 200 byte...

assume valori non descritti nella guida. Lì sono infatti previsti i valori da 0 a 3. > Mentre ho ricevuto dei pacchetti con valore 4 e 0x80.

Per forza non riesco a trovarli... non sono scritti. Mi ha inviato il link a una pagina dove c'è un'applicazione java per comporre i pacchetti. E li ci sono anche questi valori.

subito

Idem anche qui. In realtà ci sono degli altri campi che sulla guida NON sono riportati mentre nell'applicazione java si.

Si è difeso dicendo che il datasheet non è sempre aggiornato ma il sito si...

Mah! E poi mi sento rispondere di andare a RTFM... sgrunt!

Marco