Micro in Wireless
Moderatori:
carloc,
g.schgor,
BrunoValente,
IsidoroKZ
0
voti
Va bene, era per dire che il modulo MASTER è collegato al micro, non è il BT del computer
Visita il mio sito : http://www.raffotech.altervista.org
0
voti
È sicuro che con questa scheda , configurata come master, io possa collegarmi a diverse schede contemporaneamente ?
Sul datasheet leggo :
NOTE: Only one client can make connection to FireFly slave at a time. As a master, it is possible to make multiple connections from FireFly, but only in a point-to-point, serialized fashion. At this time Roving Networks devices do not support multipoint master mode.
Visita il mio sito : http://www.raffotech.altervista.org
1
voti
Io non ho mai detto contemporaneamente e ai fini pratici non ti serve nemmeno - ho anche specificato che contemp. lo avevi in PAN - ma la RN non ha ne PAN ne multipoint
comunque il controllo di p.es 100 slave impiega ca. 45 secondi o meno e puoi far scalare il problema come ti dicevo prima - generali multi scheda
comunque il controllo di p.es 100 slave impiega ca. 45 secondi o meno e puoi far scalare il problema come ti dicevo prima - generali multi scheda
0
voti
Vado a vedermi allora che significa PAN.
In che senso ai fini pratici non mi serve ?
Tu come faresti?
Ogni qualvolta mi serve di ad esempio accendere una luce,mi devo ogni volta prima connettere al modulo, e poi inviare i comandi necessari ?
In che senso ai fini pratici non mi serve ?
Tu come faresti?
Ogni qualvolta mi serve di ad esempio accendere una luce,mi devo ogni volta prima connettere al modulo, e poi inviare i comandi necessari ?
Visita il mio sito : http://www.raffotech.altervista.org
1
voti
una volta che il master e gli slave si conoscono (pairing) le successive connessioni sono praticamente istantantee
btw - si
una cosa del tipo
master:
slaves { luce_1, luce_2, luce_n }
for (Slave s : slaves)
{
s.connect
s.do ("abcdef")
s.close
}
e se servono performances elevate il master può avere più schede o delegare i "generali"
es.
master:
group1.connect
group.do ("s1: on, s2: off, s3: on");
group1.close
btw - si
una cosa del tipo
master:
slaves { luce_1, luce_2, luce_n }
for (Slave s : slaves)
{
s.connect
s.do ("abcdef")
s.close
}
e se servono performances elevate il master può avere più schede o delegare i "generali"
es.
master:
group1.connect
group.do ("s1: on, s2: off, s3: on");
group1.close
0
voti
Ho capito. Quindi connessione ogni volta!
Visita il mio sito : http://www.raffotech.altervista.org
1
voti
beh le connessioni persistenti sono comunque sconsigliabili - che poi l'hw ti nasconda la creazione di nuove connessioni presentandoti una connessione persistente o che effettui il multicast è solo sugar
quanti saranno statisticamente i casi in cui devi controllare centinaia di slave nello stesso momento ? - secondo te
con buona approssimazione controllerai 3-4 slave nel caso peggiore
ai fini pratici non mi serve
quanti saranno statisticamente i casi in cui devi controllare centinaia di slave nello stesso momento ? - secondo te
con buona approssimazione controllerai 3-4 slave nel caso peggiore
0
voti
Va bene, allora meglio questa soluzione!
Quando tu dici che devono conoscersi (pairing) intendi che devono già essere stati abbinati , no ?
perché leggendo il manuale, vedo che si possono salvare degli indirizzi (non ho capito se uno solo o più di uno) per connettersi agli slave.
Se non si potesse salvarne più di uno, dovrei ogni volta inviare l'indirizzo della scheda a cui connettersi , no ?
Quando tu dici che devono conoscersi (pairing) intendi che devono già essere stati abbinati , no ?
perché leggendo il manuale, vedo che si possono salvare degli indirizzi (non ho capito se uno solo o più di uno) per connettersi agli slave.
Se non si potesse salvarne più di uno, dovrei ogni volta inviare l'indirizzo della scheda a cui connettersi , no ?
Visita il mio sito : http://www.raffotech.altervista.org
0
voti
non avresti comunque problemi - che il master sia uno o meno
gli slave conosceranno il loro master - se il master "dimenticasse" qualcosa ci pensa il PIC/arm
l'indirizzo a cui connetterti devi saperlo comunque non importa se hai fatto pairing o no, se non lo sai lanci un enquire* e tutti gli slave in zona ti rispondono con l'indirizzo, loro ti conoscono già
* puoi anche salvarti i risultati su flash o fare l'enquire ogni volta che il master viene spento e riacceso
gli slave conosceranno il loro master - se il master "dimenticasse" qualcosa ci pensa il PIC/arm
l'indirizzo a cui connetterti devi saperlo comunque non importa se hai fatto pairing o no, se non lo sai lanci un enquire* e tutti gli slave in zona ti rispondono con l'indirizzo, loro ti conoscono già
* puoi anche salvarti i risultati su flash o fare l'enquire ogni volta che il master viene spento e riacceso
0
voti
Per il momento utilizzo un solo master (con l'ARM) e tutti gli altri slave vorrei utilizzarli senza PIC o altro, per ora mi basterebbe anche usare le GPIO dei modulini BT.
Comunque si, hai ragione, non userei quasi mai più moduli contemporaneamente.
Però ecco, ogni volta dovrei dire al MASTER l'indirizzo a cui connettersi, no ?
Quindi ad esempio CAMERA DA LETTO la devo abbinare ad un preciso indirizzo XXXXX che corrisponderà ad un modulino BT.
Facendo quindi CONNECT(CAMERA DA LETTO) mi si connetterebbe a quel modulino.
L'abbinamento di CAMERA DA LETTO -> XXXXX è salvato sull'ARM quindi non ci dovrebbero essere problemi
Comunque si, hai ragione, non userei quasi mai più moduli contemporaneamente.
Però ecco, ogni volta dovrei dire al MASTER l'indirizzo a cui connettersi, no ?
Quindi ad esempio CAMERA DA LETTO la devo abbinare ad un preciso indirizzo XXXXX che corrisponderà ad un modulino BT.
Facendo quindi CONNECT(CAMERA DA LETTO) mi si connetterebbe a quel modulino.
L'abbinamento di CAMERA DA LETTO -> XXXXX è salvato sull'ARM quindi non ci dovrebbero essere problemi
Visita il mio sito : http://www.raffotech.altervista.org
Chi c’è in linea
Visitano il forum: Nessuno e 56 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)



