Self-Powered Electronic Board

[pierinter]

Eccomi di nuovo qui!

Ho fatto progressi, sono riuscito a far andare la scheda e nel frattempo mi sono letto parecchia documentazione.
Più che altro per ora sul Bluetooth , per capire come funziona e come inviare i pacchetti. Non ancora molto sugli ARM ma piano piano lo farò.

Comunque , ho necessità di fare circa 200 misurazioni al secondo (da un accelerometro digitale ADXL345), e fin qui non dovrebbero esserci problemi.

Quello che vorrei chiedervi è se qualcuno di voi ha mai esplorato il protocollo bluetooth. Nel senso , con una misurazione ogni 5ms , faccio in tempo a mandare la misura prima della successiva ?

Non trovo queste specifiche , cioè quanto tempo impiego per trasmettere tot dati.

Attualmente vedo che le specifiche BLE prevedono un datasize per ogni pacchetto di max 20 byte.
Quello che non capisco è ogni quanto posso inviare i pacchetti, e quanto i pacchetti ci impiegano ad arrivare a destinazione.

Aggiornamento :

- Minimo Connection_Interval from BLE Specs : 7.5 ms
- Minimo Connection_Interval from iOS Specs : 20 ms (Assumo questo come limite minimo)
- Max 6 pacchetti ogni connection interval
- Max 20 byte ogni pacchetto
- Misure a 10 bit

Stando a queste specifiche , con ogni pacchetto riesco a mandare 20*8 = 160 bit , cioè 16 misure.
Ne faccio 200 al secondo , quindi una ogni 5 ms.
Se setto il minimo connection interval a 20 ms , posso mandare mandare un pacchetto ogni 3.3 ms.

Il problema che non capisco è : Mandando un pacchetto ogni 3.3 ms , hanno abbastanza tempo per arrivare ?

[boiler]

Un paio di cose che devi considerare:
- ti basta un asse? se vuoi la misurazione su tre assi sono tre valori da 10 bit, quindi 30 bit per misurazione
- hai visto che l'accelerometro consuma 140 uA al datarate da te richiesto? Ce la fai a fornirglieli?
- cosa succede se un pacchetto viene perso durante la trasmissione? Non è il caso di aggiungere un numero di serie al pacchetto prima di inviarlo?
- cosa succede se il pacchetto arriva a destinazione ma ha un bit sbagliato (o due, o sei, o tutti)? Puoi accettarlo o dobbiamo aggiungere una checksum?

Riguardo alla tua ultima domanda, non capisco cosa intendi. Chi o cosa non dovrebbe avere tempo?

Boiler

[pierinter]

- ti basta un asse?

Yep , devo fare misurazioni solo su un asse

- hai visto che l'accelerometro consuma 140 uA al datarate da te richiesto? Ce la fai a fornirglieli?

Ho visto , non è pochissimo ma ho assunto che siano più o meno i consumi standard essendo un 'low power'. Non ho fatto ricerche molto approfondite su questo poiché non è proprio il nocciolo del progetto. Per ora quello su cui mi voglio concentrare è la parte di controllo e trasmissione. Il sensore da utilizzare penso sia abbastanza facilmente cambiabile senza troppe preoccupazioni. Nel senso che se un domani saltare fuori un accelerometro che consuma nettamente meno , potrei agevolmente usare quello. Per il momento volevo usare questo perché è quello che attualmente ho. Se comunque hai qualche buon modulo da propormi che conosci, volentieri, grazie mille :)

- cosa succede se un pacchetto viene perso durante la trasmissione? Non è il caso di aggiungere un numero di serie al pacchetto prima di inviarlo?
- cosa succede se il pacchetto arriva a destinazione ma ha un bit sbagliato (o due, o sei, o tutti)? Puoi accettarlo o dobbiamo aggiungere una checksum?

Appunto, questo è quello che stavo cercando di capire.
Per quanto riguarda la perdita del pacchetto , il protocollo BLE prevede diverse modalità di comunicazione , tra cui : notify e indication . Entrambe notificano allo slave l'update di un valore ( da capire con che frequenza massima ) , la differenza è che l'indication prevede un acknowledge , mentre il notify no. Chiaramente usare il ' notify' permette un throughtput più elevato.
Con i dati dovrei poi fare una trasformata per visualizzare lo spettro delle vibrazioni , e perdere un pacchetto vorrebbe dire perdere praticamente 16 misurazioni. Il che forse è troppo.
Immagino che inviare un ackowledge ogni volta sia però troppo dispendioso , quindi forse (se non è già incluso nel pacchetto BT) si potrebbe inviare un timestamp , e verificare la corretta tempistica dei pacchetti lato ricevitore.

Per quanto riguarda l'errata trasmissione di qualche bit , beh , questo è un problema, si.
Riceverei misure totalmente sballate.
Immagino però che nel protocollo BT sia già compresa una sorta di error checksum o comunque un controllo sugli errori.

Per quanto riguarda la mia ultima domanda , mi sono espresso male. Intendevo dire : se mando i pacchetti in maniera temporalmente troppo ravvicinata , potrebbe succedere che il pacchetto B arrivi prima del precedente pacchetto A.
Però in realtà questo non dovrebbe essere un problema perché immagino che il protocollo sappia già riordinare i pacchetti. - Quindi probabilmente si , nel pacchetto ci sarà un timestamp da qualche parte -

[boiler]

Non conosco il protocollo, per questo ti ho messo delle pulci nelle orecchie. A te di decidere se sono dei problemi reali o meno.

Per la sequenza di arrivo dei pacchetti non mi farei troppi problemi: in 3.3 ms la radiazione elettromagnetica (assumiamo di essere nel vuoto per comodità) percorre 1000 km. Il BT mi risulta avere una portata leggermente minore

Seriamente: il problema esiste solo se hai diverse strade per la propagazione del pacchetto dalla sorgente alla destinazione e se queste strade hanno latenze diverse (è per esempio il caso in una rete TCP/IP con diversi routers).

Boiler