Classifica

Ho deciso di cambiare nome a PU Trains, trasformandolo in ATS SmartApp dato che, via via, l'App sta diventando una sorta di mini sistema ATS ed ho già pensato anche a come integrarlo, in un prossimo futuro, con il "fratello maggiore". Ad oggi, ATS SmartApp può controllare fino a 4 Smart Hub PU e fino a 8 device connessi alle rispettive porte. Può funzionare in modalità manuale, controllando l'output di motori e luci, oppure in modalità "sequencer" ovvero eseguendo una lista di comandi che prevedono anche la lettura dello stato di uno o più sensori Boost (distanza/colore) al fine di determinare le azioni da intraprendere. Al momento non abbiamo molte informazioni al riguardo, ma sappiamo che il nuovo set STEAM Spike (che usa la stessa "architettura" Powered Up) prevede l'espansione del sistema mediante sensori personalizzati. In un prossimo futuro, quindi, hardware e firmware dello Smart Hub ci consentiranno di integrare sensori magnetici, di tocco e, non di meno RFID. Torniamo ora alla descrizione della funzionalità di ATS Smart Hub. Al momento, la funzionalità manuale di controllo dei motori prevede che il motore (non importa di quale tipo) sia connesso alla *Porta A* dello Smart Hub e che il sensore o la luce LED siano connessi alla *Porta B*. Nella modalità Sequencer invece ci sarà la massima versatilità di configurazione, nel senso che sarà possibile utilizzare qualsiasi porta/device. Ad esempio, si potrà configurare uno Smart Hub con due sensori di colore/distanza, che agisce semplicemente da "rilevatore di passaggio/posizione" e, parallelamente, configurare un altro Smart Hub con 2 distinti motori che (ad esempio) agiscono su un passaggio a livello e uno scambio, o su due scambi. Gli altri due Smart Hub potranno invece comandare motore+luci di due distinti treni. La novità del sequencer è l'introduzione del comando SENS[hub] (dove 'hub' è il numero dell'hub al quale è connesso il sensore) che blocca l'esecuzione della sequenza fintanto che non viene rilevato un ostacolo. È configurato per rilevare un ostacolo a 3-4 cm. Ovviamente tenete a mente che la velocità di "rilevamento" non è particolarmente alta quindi, a secondo che utilizziate il sensore a bordo treno, o lungo il tracciato ferroviario, dovete realizzare un opportuno "ostacolo". Nella prossima release, troverete anche SCOL[hub][color] ovvero la possibilità di attendere il rilevamento di un determinato colore. Vi faccio un esempio "pratico" di cosa si può fare con il sequencer... Prendete due treni, ognuno dotato di un Hub con motore sulla Porta A e sensore di distanza sulla Porta B. Per semplificare la spiegazione, assumiamo che i treni siano posizionati su due tracciati ferroviari indipendenti. Il sensore è montato perpendicolarmente rispetto alla direzione di marcia del treno. Lateralmente ad entrambi i tracciati c'è un "ostacolo" costituito da un muretto di brick alto abbastanza per entrare nel raggio di azione del sensore. Usiamo questa sequenza: GF190 WAIT2 SENS1 STOP1 GF290 WAIT2 SENS2 STOP2 GF190: Avvia il motore collegato alla Porta A dell'Hub 1, al 90% di velocità. WAIT2: Aspetta due secondi prima di eseguire il successivo comando SENS1: Aspetta che il sensore (collegato alla Porta B dell'Hub 1) sia "attivato" da un ostacolo. STOP1: Ferma il motore dell'Hub 1 GF275: Avvia il motore collegato alla Porta A dell'Hub 2, al 75% di velocità. WAIT2: Aspetta due secondi prima di eseguire il successivo comando SENS2: Aspetta che il sensore (collegato alla Porta B dell'Hub 2) sia "attivato" da un ostacolo. STOP2: Ferma il motore dell'Hub 2 Se questa sequenza viene eseguita in loop (altra novità di questa versione dell'App: una sequenza può essere eseguita una sola volta, oppure in loop) avremo il risultato che il primo treno parte e percorre il circuito fino al punto di stop. A quel punto si ferma, e parte il secondo treno che, a sua volta, percorre il circuito fino al suo punto di stop. Dopodiché si ferma, e riparte il primo treno. Se ci riflettete bene, ci sono svariate configurazioni che possono essere combinate tra loro al fine di ottenere un movimento più dinamico dei treni anziché il solito treno che circola all'infinito senza sosta. Gli unici veri limiti con i quali potremmo avere a che fare sono: - La durata delle batterie - La lunghezza dei cavi dei motori/sensori - Il numero di dispositivi BLE (Bluetooth Low Energy) collegabili allo smartphone Android che funzionerà da "Centrale di controllo". Infatti, come ho già detto in un post precedente, alcuni smartphone, non sono in grado di connettersi a più di 3 dispositivi BLE. Il mio Huawei P20 Lite è uno di questi, mentre il Samsung di mia moglie (pagato meno della metà del mio P20) ne supporta tranquillamente 4 (e forse anche 1 o 2 in più). Cosa manca, oggi, ad ATS SmartApp e che implemeterò nei prossimi giorni? - Identificazione della versione del firmware; - Visualizzazione dello stato delle batterie, con eventuali avvisi in caso di scarsa energia e l'interruzione della sequenza di comandi (se attiva); - Modifica del nome dello Smart Hub (così come si può fare dall'App ufficiale LEGO); - Lo spegnimento istantaneo di tutti gli Smart Hub connessi; - L'accoppiamento di due motori identici sullo stesso Smart Hub (per funzionare come fossero un solo motore con doppia potenza) con la possibilità di settare le direzioni per singolo motore; - L'accoppiamento di due Smart Hub, come fossero un solo Smart Hub (utile per pilotare treni con due motori posizionati nella motrice di testa e di coda); - L'esecuzione di suoni (sullo smartphone) in base a determinati eventi; - Il controllo remoto dell'App da un altro smartphone (per controllare più App parallele su grandi diorami). - Loop e flussi condizionali personalizzati nello script editor del sequencer. Vi ricordo che ATS SmartApp è utile anche al di fuori dell'ambito "ferroviario", ovvero in qualsiasi MOC dove avete bisogno di una gestione più complessa del semplice "motore che gira continuamente". La versione aggiornata potete scaricarla dal link presente nel primo messaggio di questa discussione

Ieri pomeriggio ho speso un'oretta per sperimentare qualcosa con un collegamento seriale. Prima di mettermi al lavoro, ho scambiato qualche messaggio con Joege Pereira: già in passato aveva provato a "sniffare" la comunicazione seriale tra il Boost Move Hub e il sensore di distanza WeDo 2.0, oltre che con il motore esterno del Boost. Sfortunatamente, com'era del resto prevedibile, senza la documentazione del protocollo wired è praticamente impossibile riuscire a scambiare dati via seriale. Speravo almeno di riuscire a scrivere qualche byte dall'Hub alla seriale utilizzando il comando WriteDirect, ma non c'è stato verso Però, almeno una cosa son riuscita a "portarla a casa"... ovvero essere in grado di intercettare un contatto aperto/chiuso e quindi avere la base per realizzare un sensore di tocco/switch magnetico (che poi è proprio il primo tipo di sensore che avevo in mente di realizzare). Il tutto si basa sui messaggi di notifica che lo Smart Hub invia sul canale Bluetooth quando un dispositivo viene connesso/rimosso dalle porte dell'Hub. Questa feature è interessante perché permette al sistema PU di adattarsi "dinamicamente" ai dispositivi che vengono collegati/disconnessi anche mentre l'Hub è accesso e di notificare questi cambiamenti ad una eventuale App o comunque ad un altro dispositivo smart (in futuro, se LEGO prosegue lo sviluppo in tal senso, sarà possibile avere reti di Hub interconnessi). Ma come faccio a simulare il collegamento/disconnessione di un dispositivo e far scatenare i relativi messaggi? La risposta è molto banale: basta collegare tra di loro i pin 3 (gnd) e 5 (rx) del cavetto PU interponendo una resistenza (io ne ho utilizzata una da 220 ohm). Se questo collegamento dura più di 400/500ms, lo Smart Hub genera l'evento "Dispositivo connesso". Quando il collegamento viene interrotto, viene generato il messaggio "dispositivo disconnesso". Tenete conto che entrambi i messaggi contengono delle informazioni utili: hanno un byte che identifica qual'è la porta interessata dalla connessione/disconnessione e, soprattutto, il messaggio di "dispositivo connesso" include un byte che identifica il tipo di dispositivo... e il tipo di dispositivo viene modificato proprio grazie al valore della resistenza interposta tra i due pin. È sufficiente intercettare e gestire questi due messaggi per implementare un sensore On/Off. Sicuramente non è la miglior soluzione possibile, ma finché LEGO non rilascerà la documentazione (e la rilascerà, senza dubbio...) non si può fare molto altro. Appena ho risolto il problema del "timing" della chiusura del contatto (devo fare un piccolo circuitino che a fronte di un micro contatto generi un impulso più lungo) entrerò nel dettaglio con lo schema e video di questo workaround. P.S. Ovviamente ho provato a chiedere a LEGO se fosse stato possibile avere qualche informazione in più/piccola anticipazione sul protocollo wired. La risposta era scontata... ma ci ho comunque provato

Questo ragazzo è un mostro... Un vero maestro in questo specifico tema.

Ciao a tutti, questo e' il mio attuale circuito GBC, quello che esporrei a Borgobricks (in caso la mia iscrizione venga accettata). I moduli sono tutti basati su idee arcinote ma sono tutti (ri)progettati da me (non ho seguito istruzioni insomma). Alcuni sono piu' affidabili di altri ma in generale il circuito gira abbastanza pulito senza troppi interventi Purtroppo non ho i pezzi e soprattutto il tempo per fare i moduli con colori coordinati, per cui sono tutti rainbow ma vabbe' Spero di riuscire a fare altri due moduli, uno e' già in lavorazione, poi mi piacerebbe fare un modulo con EV3, magari un contatore di palline. Che ve ne pare? PS scusate il casino del tavolo da lavoro