Jump to content

Recommended Posts

Apro questo nuovo topic per introdurvi ad un progetto che abbiamo iniziato a sviluppare unitamente a @Valter1966 e @pivan e al quale ci piacerebbe coinvolgere altri AFOL di ItLUG e non solo. Penso ad esempio a persone come @alf, @fonderiadigitale, @bricksnspace ma sono sicuro che tra noi ci sono molti altri che potrebbero essere interessati ad avere una parte attiva nel progetto, ognuno con le proprie competenze, idee ed esperienze.

Scopo del progetto è quello di colmare una lacuna di LEGO in tema di 'automazione/programmazione' di un diorama/circuito ferroviario.

Nonostante il neonato Powered Up abbia introdotto il protocollo Bluetooth (che elimina una parte dei problemi del precedente sistema IR), non è in grado di soddisfare le esigenze di noi AFOL che vogliamo rendere più dinamici i nostri circuiti ferroviari.

Sia chiaro: il nostro progetto non è certo una novità nel panorama AFOL. Sono stati moltissimi coloro che negli anni si sono ingegnati nell'automatizzare i diorami, soprattutto grazie alla facilità di programmazione offerta dalle ben note schede Arduino, ma ancora prima con gli RCX/NXT.

La caratteristica principale del nostro progetto è la comunicazione Wireless tra i singoli elementi del sistema, rendendo più semplice implementare l'automazione anche su circuiti di grandi dimensioni senza la necessità di dover passare metri e metri di cavi per collegare sensori ed attuatori alla 'Control Unit' (capire meglio più avanti cos'è...)

A questa caratteristica, si aggiunge lo sviluppo di componenti elettronici specifici, a basso impatto visivo, integrabili con i normali elementi LEGO.

Ovviamente, per quanto cercheremo di sviluppare una cosa molto semplice da realizzare sul piano pratico (documentando passo per passo), non potrà comunque essere paragonato alla semplicità di accendere due dispositivi e fare il pairing tra loro (come il Powered Up, per intenderci...).
Del resto, o ci si accontenta di usare un telecomando per fare andare un treno avanti/indietro regolandone la velocità, oppure ci si ingegna un pochino più del necessario per avere 2, 3 o 4 treni che circolano su un tracciato articolato, effettuando fermate programmate, azionando le barriere dei passaggi a livello primo del loro transito o attivando scambi per modificare il tracciato da percorrere.

Questo nuovo topic nasce come prosecuzione di un discorso già avviato tempo fa e che vi invito a leggere come "background" informativo sui concetti relativi ad un automatismo ferroviario in ambito LEGO, benchè alcuni passaggi sono superati (soprattutto nella parte harware).

ITS è fondamentalmente composto da sensori, attuatori e da una Control Unit.
Sensori e attuatori parleranno con la Control Unit usando il protocollo MQTT per mezzo di un Broker MQTT (un sofware che agisce da centro di smistamento messaggio).
Il protocollo MQTT è un protocollo di comunicazione molto diffuso in ambito IoT (Internet of Things).

(Nota: non fatevi 'impressionare' da sigle/acronimi. È molto, molto più semplice di quanto vi possa apparire in una prima lettura.)

Questo vuol dire che la Control Unit può essere realizzata i modi diversi ed integrarsi a sistemi già esistenti tipo ArduTrain (nel caso l'ideatore Luca Bellan decidesse di evolvere il suo sistema di controllo ferroviario implementando l'MQTT) anziché utilizzare componenti di terze tipo SBrick, EV3, NXT.

Ricordate: lo scopo del progetto ITS è quello di sviluppare un sistema flessibile e facile da implementare, che offra un po' di dinamismo ad un diorama ferroviario LEGO, permettendo di espandersi con facilità verso "nuove frontiere".

Come hardware di base per la Control Unit ci baseremo sulla scheda Raspberry 3B+ per il suo basso costo, le sue dimensioni, le sue caratteristiche (ecc. ecc.) tra cui il WiFi integrato (con la possibilità di funzionare da Access Point) e il Bluetooth (per parlare direttamente con i nuovi treni LEGO Powered UP, SBrick, Smartphone).

L'hardware utilizzato per far girare la Control Unit non è in realtà così importante: in alternativa potrà essere utilizzato un qualsiasi PC portatile, purché ci sia un Access Point WiFi che faccia da "infrastruttura di rete".

I software che useremo per questo progetto sono tutti Open Source e sono comunque sostituibili con altri simili, dato che si basano su protocolli e standard a loro volta aperti e largamente diffusi. Insomma: niente di proprietario/chiuso.
Anche laddove scriveremo il nostro firmware specifico per l'harware sul quale svilupperemo i sensori/attuatori, il codice sarà comunque messo a disposizione di tutti anche perché, con il contributo di altri AFOL-Maker, potrà essere sicuramente migliorato/evoluto.

Sensori ed attuatori, come già detto, dialogheranno con il protocollo MQTT su infrastruttura WiFI.
Il cuore di questi dispositivi sarà il chip ESP8266 della EspressIf, diventato oramai molto diffuso, soprattutto nell'ambito della domotica.

Il primo dispositivo che abbiamo avviato alla prototipizzazione è il sensore di prossimità che avrà il compito di rilevare il passaggio del treno davanti ai Check Point comunicandone tale passaggio alla Control Unit. Sarà quest'ultima, sulla base delle impostazioni impartite per lo specifico tracciato, ad inviare i comandi verso gli altri dispositivi che agiranno sui passaggi a livello, sugli scambi e sul motore del treno.

Come primo attuatore, invece, partiremo dal controller del motore PF (hardware+software) e, parallelamente da quello per l'HUB Powered Up (software).
Da quanto ho potuto vedere documentandomi sulla Rete, non sarà  troppo difficile integrarsi anche con i dispositivi SBrick, BuWizz e PFx Brick. Avendo sotto mano un SBrick (grazie @ZioTitanok ) proverò inizialmente ad interfacciarmi con questo primo componente di terze parti, ma solo dopo aver sviluppato un prototipo del nostro attuatore (ad un costo nettamente inferiore rispetto ai vari "intelligent brick" già disponibili sul mercato).

Sensori ed attuatori, da soli, non servono sostanzialmente a nulla se in mezzo a loro non c'è un 'cervello' ovvero il centro di controllo, quello che finora ho nominato com 'Control Unit', nell'ecosistema ITS - ItLUG Train System.

La parte software che rappresenterà la C.U. potrà essere realizzata con qualsiasi linguaggio/piattaforma che sia in grado di interfacciarsi con un broker MQTT (praticamente tutti).

Per semplicità e flessibilità, noi useremo Node Red (basato su Node.js, ovvero JavaScript), un ambiente di sviluppo visuale che ci permetterà di creare dei 'flussi' di messaggi, disegnando (nel vero senso della parola) la logica di controllo per i nostri circuiti ferroviari e potendola adattare 'all'istante', senza troppe complicazioni e con una rappresentazione chiara.

Per farvi comprendere meglio, vi farò un esempio pratico, usando come base un circuito molto semplice:
CircuitoTreno.png

Su questo circuito sono posizionati 4 check point che identificano l'approssimarsi a dei punti 'nevralgici' del circuito.
1) La stazione/punto di partenza/punto di stop
2) e 3) Passaggi a livello
4) Scambio

Il sensore che identifica questi check point è posizionato a bordo del treno (immaginiamolo all'inizio del convoglio).
Il treno parte sempre da un punto prestabilito (la stazione) ed inizia a passare tra i vari check point... ad ogni passaggio, invia un messaggio MQTT che non fa altro che comunicare 'Sono transitato su un check point'.... Nient'altro!
A bordo del treno, ovviamente, ci sarà anche un dispositivo 'attuatore' ovvero quello che, nella pratica, agirà sul motore.

Cosa ci facciamo con i messaggi trasmessi dal treno ad ogni passaggio per un check point?

Ecco che vi presento l'interfaccia della Control Unit, basata su Node Red:

Workflow.png

Quello rappresentato nell'immagine è un Workflow di messaggi.
Ho separato il workflow in 3 aree: le prime due in alto, sono semplicissime: inviano un messaggio al treno, rispettivamente per avviare il motore e per fermarlo. L'invio del messaggio è determinato dal click sull'interfaccia grafica (il quadratino azzurrino, sul lato sx del primo box, per essere chiaro) ma può tranquillamente essere scatenato da un trigger esterno (un pulsante sullo smartphone, il caso più semplice).

Il resto, rappresenta la logica vera e propria:
Il primo box ('Sensore treno A') riceve il messaggio e lo passa a 'Conta Check Point', una funziona che non fa altro che contare in modo sequenziale il passaggio dei check point, resettando il contatore ogni volta che arriva al valore 4.
Il 'Conta Check Point' passa il messaggio (contenente il numero del check point sul quale il treno è in transito) al blocco 'Smista Check Point': questo non fa altro che, in funzione del valore, smistare il flusso verso ulteriori blocchi... ognuno di questi ha un propria sotto-logica che, fondamentalmente, determina l'azione da intraprendere: azionare l'attuatore del passaggio a livello, anzichè dello scambio... oppure intervenire sull'attuatore che controlla il treno, fermando la corsa e facendola riprendere dopo 10 secondi...

Nei prossimi giorni, entreremo nel dettaglio dei singoli componenti...

(Nota: Tutto l'ambiente software relativo al Raspberry verrà messo a disposizione come 'file immagine' da replicare sulla vostra microSD, in modo da avere tutto già pronto, senza dover conoscenere i minimi dettagli della configurazione, benché gli stessi saranno comunque messi tutti a disposizione).

Share this post


Link to post
Share on other sites

La scelta di MQTT ha diversi vantaggi: è uno standard diffusissimo, al punto che è usato anche in Google Home ed Amazon Alexa, sì, prima o poi potrete urlare "Alexa ferma il trenooooh!" prima di un devastante incidente di mattoncini; permette la diffusione di un "messaggio" a tutti i sistemi collegati anche con garanzia di consegna (comodissimo per sensori, semafori, scambi). In pratica è per dare comandi tipo: "avvisa tutti che il binario 2 della stazione è occupato", e i diretti interessati si regoleranno di conseguenza.

La scelta dell'ESP8266 riguarda dimensioni e costi, entrambi molto contenuti (è davvero arduo pensare ad un'alternativa diffusa ed economica). Per chi non la conoscesse, la definiremmo "una specie di Arduino col Wifi".

 

Share this post


Link to post
Share on other sites

Immaginavo, @alf, che te avresti colto subito i vantaggi di questa implementazione.
Uso MQTT e gli ESP8266 per altri progetti, anche se da relativamente poco tempo, e subito ho pensato che fossero idonei per semplificare al massimo il discorso dell'automazione, in unione a Node Red.

Questo, è un altro esempio di Workflow, "disegnato" velocemente...

Descrive la logica di due treni che viaggiano, contemporaneamente e nella stessa direzione, sullo stesso tracciato.
In una situazione reale, prima o poi, i due treni si avvicineranno tra di loro, per via della differenza di resa dei motori, del peso del treno, dell'efficienza delle batterie.

Partono, all'85% della loro velocità massima, a distanza di 5 secondi uno d'altro.
(il secondo treno, immaginiamolo inizialmente posizionato su un binario secondario che si innesta al circuito principale)

Lungo tutto il tracciato, a distanza di circa 50cm l'uno d'altro, sono posizionati i checkpoint (cosa sono i checkpoint, nella pratica, lo vedremo in un prossimo post).

Ogni treno conteggia i checkpoint a partire dal punto di partenza.
Il primo treno (A), gira per conto suo, senza interessarsi di altro...
Per il secondo treno (B) la logica calcola la differenza tra il conteggio dei checkpoint, facendo in modo che sia possibilmente vicino a 3 (1,5 metri di distanza). Se questa differenza diminuisce, il treno B viene rallentato... se la differenza aumenta, il treno B viene spinto più velocemente... nella pratica, i due treni viaggeranno 'all'infinito' sul circuito senza mai 'toccarsi', mantenendo tra loro una distanza ben precisa...

Insomma, anche se sono giusto delle bozze di workflow, spero sia chiaro quanto sia potente e flessibile questo sistema...

blob.png

Share this post


Link to post
Share on other sites

Purtroppo di domotica conosco niente, ma questo sistema può rivelarsi molto utile.

E poi scusate, come fate a non farvi piacere questo? 😁😁😁

f_-_controlpanel_for_whole_layout.thumb.jpg.361f5d91e46a23a7164f4ef0b5fcc49c.jpg

Presente ma come collaudatore!

Tutti questi sensori sono alimentati a batteria, giusto?

Edited by Arrow

Share this post


Link to post
Share on other sites

Ciao a tutti!

Come già detto sui social, mi aggiungo alla lista degli interessati e di quelli disposti a fare test.

Consideratemi della truppa anche se non sono un programmatore e finora mi sono dilettato soltanto con gli RCX, peraltro con discreti risultati grazie all'aiuto del mitico @Rudy

Credo sia giunto però il momento di voltare pagina, verso qualcosa che, anche se non LEGO, permetta di gestire varie funzioni in maniera affidabile ed economica.

Paolo.

 

 

 

Share this post


Link to post
Share on other sites
6 ore fa, GianCann ha scritto:

Avendo sotto mano un SBrick (grazie @ZioTitanok ) proverò inizialmente ad interfacciarmi con questo primo componente di terze parti, ma solo dopo aver sviluppato un prototipo del nostro attuatore (ad un costo nettamente inferiore rispetto ai vari "intelligent brick" già disponibili sul mercato).

Dilla tutta! Ringraziami per averti fatto scoprire Home Assistant: hai fatto il giro lungo ma alla fine sei tornato al LEGO. 😀
Seguo con interesse il progetto, pur non essendo un trenista, perché convinto che possa essere sfruttato per tante altre applicazioni LEGO.

Share this post


Link to post
Share on other sites
3 ore fa, sky7176 ha scritto:

Per lavoro già utilizzo MQTT.

In che ambito lo utilizzi, @sky7176?

Una delle cose sulle quali dobbiamo ragionare, relativamente alla sezione MQTT è la composizione dei topic.

Ad esempio, c'è bisogno di un topic per il discovery dei dispositivi (utili a verificare che tutti siano 'connessi' al broker) e poi c'è bisogno dei topic relativi a sensori ed attuatori.

Ad esempio:

ITS/Discovery/(device) search

dove 'device' può essere: Sensori/Treni/PL/Scambi, al quale i singoli dispositivi interpellati rispondono con topic contenente un payload Json contenente nome/IP/Tipo:

ITS/Info/(device) payload_json

Un meccanismo del genere, permetterebbe di cercare ed identificare tutti i dispositivi connessi al broker e per avere delle informazioni minimali per la configurazione del workfkow.

Cosa ne pensi? Ti viene in mente qualche altra idea?

Share this post


Link to post
Share on other sites

Ciao,

lo uso in ambito industria 4.0

Ho realizzato un software x il monitoraggio di macchine utensili.

X quanto riguarda i topic,direi che ci potremmo essere.

L'unica cosa è che esp32 consuma un botto.

Share this post


Link to post
Share on other sites
35 minuti fa, sky7176 ha scritto:

L'unica cosa è che esp32 consuma un botto.

Noi useremo l'ESP8266 che ha questa tabella dei "consumi":

20150112172151.jpg

L'ESP32, in effetti, consuma di più (fino a 240 mA).

Sicuramente, per gli eventi, in cui i treni girano di continuo, saranno necessarie le batterie ricaricabili oppure, come è mia intenzione fare, realizzare un "pick up" dai binari 9v.

Share this post


Link to post
Share on other sites

In un progetto che ho realizzato, un esp8266 che inviava una lettura di temp e umidità ogni 30 sec alimentato con power pack da 2000 mA funzionava x circa 2 giorni prima che il power pack si scaricasse.

Comunque la cosa mi stuzzica.

Share this post


Link to post
Share on other sites
5 ore fa, sky7176 ha scritto:

In un progetto che ho realizzato, un esp8266 che inviava una lettura di temp e umidità ogni 30 sec alimentato con power pack da 2000 mA funzionava x circa 2 giorni prima che il power pack si scaricasse.

Comunque la cosa mi stuzzica.

Andando in deep sleep?

 

8 ore fa, GianCann ha scritto:

In che ambito lo utilizzi, @sky7176?

Una delle cose sulle quali dobbiamo ragionare, relativamente alla sezione MQTT è la composizione dei topic.

Ad esempio, c'è bisogno di un topic per il discovery dei dispositivi (utili a verificare che tutti siano 'connessi' al broker) e poi c'è bisogno dei topic relativi a sensori ed attuatori.

Ad esempio:

ITS/Discovery/(device) search

dove 'device' può essere: Sensori/Treni/PL/Scambi, al quale i singoli dispositivi interpellati rispondono con topic contenente un payload Json contenente nome/IP/Tipo:

ITS/Info/(device) payload_json

Un meccanismo del genere, permetterebbe di cercare ed identificare tutti i dispositivi connessi al broker e per avere delle informazioni minimali per la configurazione del workfkow.

Cosa ne pensi? Ti viene in mente qualche altra idea?

La logica di stato di ogni device dovrebbe essere gestita da ogni client alla connessione e disconnessione. Che io sappia mosquitto (se usi quello, mqtt come protocollo non lo prevede) non lo implementa automaticamente. Sicuramente avere una rappresentazione json dello stato di ogni device quando interrogato (alias: richiesto esplicitamente  e solo per debug) potrebbe essere utile in diagnostica. Ma a quel punto sarebbe importante avere uno schema json il quanto più possibile uniforme tra i Device

 

Per la verità il broker ha una tabella di keepalive dove lo stato dei clienti viene mantenuto e in caso di disconnessione viene Attivato un meccanismo chiamato last will and testament (lwt) Che potresti usare per determinare i client Che 'spariscono'.

Personalmente preferirei avere una lista esplicita più che implicita, per cui meglio sempre fare in modo che il cliente pubblichi il suo stato nel subtopic apposta.

Share this post


Link to post
Share on other sites

Si mandando lo in deep sleep e facendolo Risvegliare ogni tot.
Il problema è che quando si sveglia deve riconnettersi alla rete, in quel momento i consumi aumentano.

Inviato dal mio SM-A500FU utilizzando Tapatalk

Share this post


Link to post
Share on other sites
5 ore fa, fonderiadigitale ha scritto:

Ma a quel punto sarebbe importante avere uno schema json il quanto più possibile uniforme tra i Device

Assolutamente d'accordo anche se, oltre a nome, tipologia, versione del FW e indirizzo IP non mi vengono in mente altri dati da comunicare. Visto il tipo di applicazione, l'indirizzamento della rete e le impostazioni del broker MQTT saranno 'mandatory', almeno in una prima release dell'intero sistema.

Ti viene in mente altro?

5 ore fa, fonderiadigitale ha scritto:

Personalmente preferirei avere una lista esplicita più che implicita, per cui meglio sempre fare in modo che il cliente pubblichi il suo stato nel subtopic apposta

Il messaggio di welcome con il Last Will & Testament lo implementeremo sicuramente, ma un comando esplicito che ci può enumerare i dispositivi connessi (per tipologia, o tutti quelli "in ascolto") ci sarà sicuramente utile.

Share this post


Link to post
Share on other sites

I miei 2 cents per gli eventuali perplessi...

La "gerarchia" dei topic MQTT non sarà tanto complicata, visto che ci sono poche categorie automatizzabili (interruttori, luci, motori, sensori). Stiamo parlando di diorami, mica della NASA...

Non fatevi spaventare dal termine "domotica": basarsi su MQTT (per esempio il mosquitto per Linux) facilita parecchie cose altrimenti complicate da realizzare (come l'invio garantito di un messaggio di status). Un singolo server MQTT (per esempio basato su una Raspberry, magari quella piccoletta) può servire tutti gli apparati che via wifi o cavetto di rete riescono a raggiungerlo, anche se di diorami ferroviari diversi.

Certo, il wifi consuma più del BLE (Bluetooth Low Energy, usato ad esempio dagli sBrick) ma anche in questo caso i vantaggi (avere parecchi sistemi contemporaneamente in rete, la notevole velocità di trasmissione dei pacchetti via wifi, il non dover costruire tutta l'infrastruttura di scambio messaggi, costi decisamente abbordabili rispetto ad alcuni anni fa, ecc., e soprattutto il fatto che si può realizzare in modo non invasivo sui diorami già esistenti) superano gli svantaggi. La tabella dei consumi sopra indicata si riferisce al caso peggiore e al funzionamento a 3,3 volts.

Il deep sleep andrà magari sperimentato più avanti, quando tutto già funziona, per vedere in quali casi produce realmente un risparmio di energia sulle batterie.

Ma non lamentatevi dei consumi se avete ingegnerizzato maluccio i vostri (esempio: immaginate i consumi di un locomotore "leggero" che traina una vettura "pesante" anziché avere il pacco batterie "in asse" verticale col gruppo motore). Anzi, cominciate a progettare un treno 8-wide col pacco batterie grosso...

Share this post


Link to post
Share on other sites

In ogni caso ai consumi del modulo si devono aggiungere i consumi dei carichi, che si dovrà decidere a che tensione alimentrarli.

Per mantenere una certa uniformità di tensioni, io rimarrei sui 9v.

Sicuramente avvantaggiati gli utilizzatori dei binari a 12v, possono "spillare" energia dai binari, per i PF altro discorso.

In ogni caso iniziamo a buttare sulla carta degli schemi di massima ed iniziamo a ragionarci su.

Io personalmente ho utilizzato come master sia un pc windows che una raspberry entrambi con Mosquitto, se usiamo red-node il passaggio tra i due ambienti hardware, al netto di uscite GPIO della raspberry, è indolore.

Giuseppe

Share this post


Link to post
Share on other sites

Intanto vi anticipo qualche foto di una parte del materiale arrivato oggi 😉

IMG_20190129_152104.jpg

IMG_20190129_152125.jpg

IMG_20190129_152135.jpg

IMG_20190129_152245.jpg

IMG_20190129_152333.jpg

Il case l'ho acquistato ieri su Amazon, pagandolo 6,5 euro
E' disponibile nei seguenti colori: rosso, blu, nero, giallo, bianco.

Le dimensioni sono 8x11 stud, altezza 3 brick

Il clutch power è ottimo... solamente sul lato inferiore, lungo il bordo, c'è meno presa (ho provato mettendo un brick 1x4 lungo il bordo).
Per il resto, è perfetto! Il colore rosso è indistinguibile da quello LEGO.

Dentro ci ho messo un Raspberry 3, modello B+

Share this post


Link to post
Share on other sites
2 ore fa, alf ha scritto:

La "gerarchia" dei topic MQTT non sarà tanto complicata, visto che ci sono poche categorie automatizzabili (interruttori, luci, motori, sensori). Stiamo parlando di diorami, mica della NASA...

Perfettamente d'accordo! Tra l'altro, proprio per questo motivo, non ci staremo in alcun modo a preoccupare di qualsiasi problematica inerente la sicurezza.

2 ore fa, alf ha scritto:

Il deep sleep andrà magari sperimentato più avanti, quando tutto già funziona, per vedere in quali casi produce realmente un risparmio di energia sulle batterie.

Il problema dei consumi (se di problema effettivamente si tratterà...) lo valuteremo in un secondo momento.
Dubito, del resto, che in questo tipo di applicazione potremo implementare le modalità sleep

1 ora fa, sky7176 ha scritto:

In ogni caso ai consumi del modulo si devono aggiungere i consumi dei carichi, che si dovrà decidere a che tensione alimentrarli.

Per mantenere una certa uniformità di tensioni, io rimarrei sui 9v.

Confermo. L'alimentazione sarà 9V

Confermo che il progetto sarà sviluppato, di base, su questo hardware:
- Raspberry 3 B+
- ESP8266 (ed altri componenti che illustrerò più avanti)

Per il software:
- Mosquitto (MQTT Broker)
- Node-Red
- Firmware specifico per ESP8266, basato sulla libreria PubSubClient, oltre a quelle specifiche per i sensori e per eventuali 'driver'

Share this post


Link to post
Share on other sites
19 ore fa, GianCann ha scritto:

Sicuramente, per gli eventi, in cui i treni girano di continuo, saranno necessarie le batterie ricaricabili oppure, come è mia intenzione fare, realizzare un "pick up" dai binari 9v.

Prendere corrente dai 9v ci piace 🤤

Se hai bisogno di un beta tester eccomi

Grande!!!

Share this post


Link to post
Share on other sites
2 ore fa, alf ha scritto:

I miei 2 cents per gli eventuali perplessi...

La "gerarchia" dei topic MQTT non sarà tanto complicata, visto che ci sono poche categorie automatizzabili (interruttori, luci, motori, sensori). Stiamo parlando di diorami, mica della NASA...

Non fatevi spaventare dal termine "domotica": basarsi su MQTT (per esempio il mosquitto per Linux) facilita parecchie cose altrimenti complicate da realizzare (come l'invio garantito di un messaggio di status). Un singolo server MQTT (per esempio basato su una Raspberry, magari quella piccoletta) può servire tutti gli apparati che via wifi o cavetto di rete riescono a raggiungerlo, anche se di diorami ferroviari diversi.

Certo, il wifi consuma più del BLE (Bluetooth Low Energy, usato ad esempio dagli sBrick) ma anche in questo caso i vantaggi (avere parecchi sistemi contemporaneamente in rete, la notevole velocità di trasmissione dei pacchetti via wifi, il non dover costruire tutta l'infrastruttura di scambio messaggi, costi decisamente abbordabili rispetto ad alcuni anni fa, ecc., e soprattutto il fatto che si può realizzare in modo non invasivo sui diorami già esistenti) superano gli svantaggi. La tabella dei consumi sopra indicata si riferisce al caso peggiore e al funzionamento a 3,3 volts.

Il deep sleep andrà magari sperimentato più avanti, quando tutto già funziona, per vedere in quali casi produce realmente un risparmio di energia sulle batterie.

Ma non lamentatevi dei consumi se avete ingegnerizzato maluccio i vostri (esempio: immaginate i consumi di un locomotore "leggero" che traina una vettura "pesante" anziché avere il pacco batterie "in asse" verticale col gruppo motore). Anzi, cominciate a progettare un treno 8-wide col pacco batterie grosso...

su un sistema live su cui passa piu di un treno non possiamo implementare il deep sleep, immagino.

ok tiro fuori una cosa su cui vorrei lavorare da parecchio tempo, e prima o poi lo faro' (tempo permettendo, quindi mai...)

Quello che sarebbe carino fare e' il pickup dai binari che carica un condensatore dal quale viene alimentato il motore e contemporaneamente (tramite un diodo per evitare il ritorno) caricare una batteria. non e' una cosa banale e va pensata bene. vorrei evitare il passthrough (ecco perche il diodo)

serve:

- alzare la corrente sul circuito da 9v a 11v o 12v

- un bridge rectifier per normalizzare la corrente presa dal circuito

- nel caso del condensatore, una batteria di supercaps (2.7 l'uno) in serie

- dato che i supercap non sono come le batterie, man mano che scaricano il voltaggio diventa 0, serve un DC/DC converter per mantenere l'andamento del treno..lineare

- un limitatore di corrente in carica sul cluster di supercaps.

 

niente di trascendentale, il piu e' fare dei test.

comunque non sono il primo ad averci pensato, per esempio questo e' un buon spunto:

 https://brickmodelrailroader.com/index.php/2017/03/20/supercapacitor-power-packs/

 

Share this post


Link to post
Share on other sites
51 minutes ago, GianCann ha scritto:

Intanto vi anticipo qualche foto di una parte del materiale arrivato oggi 😉

(...)

Il case l'ho acquistato ieri su Amazon, pagandolo 6,5 euro
E' disponibile nei seguenti colori: rosso, blue, bero, giallo, bianco.

Le dimensioni sono 8x11 stud, altezza 3 brick

Il clutch power è ottimo... solamente sul lato inferiore, lungo il bordo, c'è meno presa (ho provato mettendo un brick 1x4 lungo il bordo).
Per il resto, è perfetto! Il colore rosso è indistinguibile da quello LEGO.

Dentro ci ho messo un Raspberry 3, modello B+

metti un dissipatore su quell'IC in mezzo se sta chiuso nel case di plastica:) o tieni sotto controllo la temperatura col crescere del carico. dubito che avrai problemi comunque.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...