gepard

Ciao, tra i tanti progetti che inizio e ciclicamente interrompo e riprendo (e non riesco mai a portare a conclusione) ce n'è uno in cui mi sono arenato a causa di palese mancanza di competenze tecniche e per il quale ho iniziato questo thread di appello / richiesta soccorso / chiamata alle armi agli esperti di progettazione elettronica specializzati in radiofrequenza presenti nei Cantieri Riuniti Base Atlantica - Betasom. L'idea di partenza è quella di realizzare un sistema radiocomando trasmittente+ricevente in grado di sintonizzarsi su tutte le frequenze per il radio modellismo a livello mondiale, con minimi adattamenti plug & play, eventualmente solo software, per adattarlo alla banda di frequenza di utilizzo a scelta tra una delle seguenti: 0: 13.560 MHz 1: 26.815-27.995 MHz 2: 29.720-30.350 MHz 3: 34.945-36.600 MHz 4: 40.510-41.200 MHz 5: 49.830-50.980 MHz 6: 53.100-54.550 MHz 7: 70.140 MHz 8: 72.010 MHz 9: 75.410 MHz A: 433.250 MHz B: 434.025 MHz C: 439.700 MHz D: 458.500 MHz E: 459.500 MHz F: 2.4 GHz Qualche mese fa ho trovato un SoC (efr32mg12 series 1 SoCs) con radio transceiver 110-960 MHz (FSK,ASK,...) e 2.4 GHz (BTLE,...) di silabs con CPU Cortex ARM M4 (ho poi scoperto che il noto mobilificio svedese li usa per la linea Tradfri di lampade e pulsanti wireless). Ho ipotizzato che aggiungendo un mixer up/down converter e un PA/LNA bidirezionale, questa famiglia di chip potrebbe essere utilizzata per questo progetto, come ho abbozzato negli schemi elettrici allegati. La trasmittente (schema elettrico RCTX_ERF32MG12.pdf) utilizzerebbe il chip con più GPIO mentre la ricevente (schema elettrico RCRX_ERF32MG12.pdf) utilizzerebbe il chip con meno GPIO. Il progetto è su github (con licenza opensource GPL 3.0) e sviluppato con kicad. Ora, dal punto di vista elettronico non so proseguire e non so nemmeno se quello che ho abbozzato negli schemi elettrici sia fattibile. Per questo motivo chiedo aiuto agli esperti di Betasom e ringrazio vivamente qualsiasi volontario interessato a collaborare nello sviluppo di questo progetto. P.S. gli appassionati di modellismo sottomarino negli USA sono a corto di sistemi rx/tx sulla banda dei 72 MHz e pagherebbero qualsiasi cifra pur di procurarsene per i loro modelli.

Bello! Quanto viene grande ?

Questo viso non mi è nuovo... Classe Archimede!

Ho utilizzato il termine "accelerazione" nel senso più generico possibile, in fondo gli scostamenti dalla verticale vengono percepiti come variazioni rispetto al campo gravitazionale terrestre che non è altro che una accelerazione. Beh, dai, fra poco tempo la TMS sarà a buon mercato e a larga diffusione anche nel settore gaming quindi si potranno simulare tutte le sollecitazioni meccaniche perepite dal cervello senza ausili e attuatori meccanici, una vera e propria VR Full Immersion.

Premetto che gli unici 4 sommergibili (Toti, Provana, Sauro e Pampanito) sui quali ho messo piede sono musealizzati e quindi ben stabili e stabilmente orizzontali, quindi potrei dire una castroneria... Penso che i somergibilisti imbarcati abbiano dalla loro parte le sensazioni delle varie accelerazioni (oltre alle scoppolate del Dir), che il battello subisce in seguito ai comandi impartiti, che forniscono loro un utilissimo feedback fisico, contemporaneamente a quello visivo/elettronico dato dai display. Quindi... @Ocean's One, mi sa che ti tocca montare tutto l'ambaradan su una piattaforma basculante movimentata da martinetti idraulici (oppure una manina meccanica per le scoppolate), altrimenti la simulazione sarà veramente ostica per chi ci si cimenterà

Eh eh, devo dire che hai azzeccato in pieno a dare a me il compito di inserire insidie e guasti , come softwareista, quale sono, per me l'aggiunta di bachi è normale routine Gli ordini del computer non sono vocali ? Al posto di usare il text to speech si potrebbero campionare registrandoli direttamente dalle voci dei Totiani in carne ed ossa !!!

Grazie a tutti anche se con notevole ritardo... tra una cosa e l'altra solo oggi sono riuscito a trovare il tempo per leggere il forum...

Riguardo ai contatti on/off per le leve dei controlli dei timoni, una soluzione affidabile ed economica potrebbe essere quella di utilizzare dei contatti reed (pagina WikiPedia). All'interno del puntale rosso delle leve, da realizzare in materiale amagnetico (ad esempio in plastica o legno), si inserisce un piccolo magnete mentre i contati reed si incollano al disotto del quadrante, anche questo da realizzare in materiale amagnetico o al più in materiale paramegnetico (alluminio), in corrispondenza dei fine corsa su/giù o destra/sinistra delle leve. I contatti reed possono essere a due terminali tipo: - normalmente aperti (NA) - chiudono il circuito in presenza del campo magnetico - normalmente chiusi (NC) - aprono il circuito in presenza del campo magnetico O a tre terminali: un terminale comune, un terminale per il contatto NA e un terminale per il contatto NC. Opterei per quest'ultima tipologia, si potrà scegliere poi al momento del cablaggio se utilizzare la connessione NA o quella NC. A differenza dei sensori ottici non richiedono alimentazione esterna. A differenza degli switche meccanici non richiedono una connessione fisica/meccanica con le leve, oltre ad essere notevolmente più robusti.

Queste leve assomigliano parecchio alle chiavi a cricchetto tipo questa:

Purtroppo in questo non saprei proprio come aiutarti, ad intuito potrei ipotizzare che pedaliere e leve dei simulatori di volo sono quelle che più si avvicinano dal punto di vista delle funzioni, ho fatto una rapida ricerca (pedaliera simulatore volo) e qualcosa salta fuori, però bisogna che prima si definiscano bene le specifiche mecaniche / elettriche / estetiche / ergonomiche e poi si fa una ricerca più mirata e quindi si valuta se in alternativa valga la pena autocostruirle in toto o cannibalizz-adattare qualcosa di commerciale. Una domanda per soddisfare la mia curosità: i manometri sono solo scenografici e statici oppure indicheranno realmente lo stato di parametri definiti dalla simulazione ? Ribadisco i miei complimenti per l'opera !!!

Prometto che questo sarà il mio ultimo post di carattere sistemistico / informatico. Configurando come access point WiFi il PC di controllo del TOTI 1:1 gli si possono poi collegare in rete wireless tutti i dispositivi remoti che si vogliono, che siano essi dei PC con lo schermo per il pubblico (questa funzione potrà essere svolta anche da una smart TV con wifi e server miracast compatibile, il PC TOTI 1:1 le invierebbe direttamente le immagini...), dei PC o anche degli smartphones / tablet che fungano da console remote di configurazione e gestione degli scenari di simulazione e qualsiasi altra idea / necessità che verrà in mente in seguito. Alla fine sarà solo una questione di implementazione del software. Vorrei comunque ribadire il mio suggerimento di utilizzare come unità di controllo del TOTI 1:1 una Raspberry Pi 4: Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz 2GB, 4GB or 8GB LPDDR4-3200 SDRAM (depending on model) 2.4 GHz and 5.0 GHz IEEE 802.11ac wireless WiFi, Bluetooth 5.0, BLE Gigabit Ethernet 2 USB 3.0 ports; 2 USB 2.0 ports. Raspberry Pi standard 40 pin GPIO header 2 × micro-HDMI ports (video 4k) 2-lane MIPI DSI display port 2-lane MIPI CSI camera port (connettore per sensore videocamera) 4-pole stereo audio and composite video port H.265 (4kp60 decode), H264 (1080p60 decode, 1080p30 encode) OpenGL ES 3.0 graphics Micro-SD card slot for loading operating system and data storage 5V DC via USB-C connector (minimum 3A*) 5V DC via GPIO header (minimum 3A*) Power over Ethernet (PoE) enabled (requires separate PoE HAT) Operating temperature: 0 – 50 degrees C ambient C'è potenza di calcolo da vendere (molta, ma molta, di più di quella che servirà), linee di I/O digitali (GPIO) a iosa e configurabili a piacere, possibilità di connettività che levati e un costo che è una piccola frazione di quello di un PC industriale che non si avvicina nemmeno lontanamente alle dotazioni hardware della Raspberry. Inoltre ci sono tonnellate di documentazione e forum per sfruttarla al meglio e nella maniera più semplice possibile con una delle tante distribuzioni Linux in circolazione a meno che non si voglia tristemente e miserrimamente usare Windows... beh, sarebbe un vero peccato...

Beh, se gli espansori di I/O hanno una interfaccia i2c o rs485 richiedono cavi con solo 4 fili: +V, GND e due fili per il segnale seriale. Per semplificare le connessioni ed utilizzare componenti commerciali affidabili si possono connettere i vari moduli tramite cavi ethernet CAT5 o CAT6 schermati, internamente hanno 8 fili in 4 coppie intrecciate più una schermatura da collegare a massa. I cavi ethernet possono trasportare sia il segnale (ad esempio 4 canali seriali) sia l'alimentazione (ad esempio nello standard POE l'alimentazione può arrivare fino a 48V e 15W di potenza e il POE+ può trasportare fino a 30W di potenza). Il PC del simulatore lo metterei in uno scatolotto (black box) a se stante da piazzare nei pressi del modulo del TV per via del limite di lunghezza del cavo HDMI. Questa black box avrà i seguenti connettori: - la presa di ingresso alimentazione a 220V (con fusibile, salvavita messa a terra, schermatura anti RNBC-EMP etc. ?) - la presa di uscita a 220V (bypass dalla presa di ingresso, con fusibile?) per alimentare lo schermo TV - il connettore HDMI (audio+video) per lo schermo TV - 3 prese RJ45 (classiche ethernet) per stabilire le connessioni (dati seriali o I/O + alimentazione) verso gli altri moduli. La black box conterrà al suo interno: - il PC di controllo del TOTI 1:1 - l'alimentatore per il suddetto PC e per gli altri moduli - una schedina di supporto (hub) per i connettori RJ45 che sarà collegata con 2 pin (linea i2c o rs485) + GND al PC e i +V dall'alimentatore. - un dongle USB WiFi (se non già previsto dal PC) Il PC per il pubblico può essere connesso al simulatore tramite Wi-Fi e piazzato dove si vuole.

Per controllare il tutto ci vedo bene una Raspberry Pi la quale può pilotare anche il piccolo display da 55 pollici e interfacciarsi con l'esterno via cavo ethernet o via WiFi. Si sceglie una distribuzione Linux minimale e customizzabile e lo sviluppo del software avverrebbe direttamente on board senza utilizzo di tools specifici e/o proprietari. Poca spesa massima resa. Per quanto riguarda i relè a stato solido, si potrebbero usare dei chip shift registers controllati via I2C e sviluppati per il pilotaggio dei display a matrice di LED, ogni output può gestire ben più di 200 mA, alcuni di questi chip possono pilotare anche tutte e 48 le linee di output richieste. Anche per gli ingressi analogici ci sono dei chip che fanno ciò che occorre (tipo il MCP3008: https://www.adafruit.com/product/856) Per gli ingressi optoisolati c'è da cercare o da autocostruire... è davvero necessario che siano optoisolati ? Se si opta per gli ingressi non optoisolati si può valutare l'uso di chip come il MCP23017 (https://www.raspberrypi-spy.co.uk/2013/07/how-to-use-a-mcp23017-i2c-port-expander-with-the-raspberry-pi-part-1/), se dovesse friggersi il danno sarebbe di pochi euro, gli optoisolatori in proporzione sono molto più costosi. Comunque, se hai una bozza di schema elettrico degli I/O si può fare una valutazione più approfondita della lista della spesa.

Che meraviglia, complimenti ! Già mi immagino quando procedereai alla realizzazione del medellino riporducente la zona dei silos di lancio di un Akula / Typhoon

La votazione l'ho persa anche io, però devo ammettere che la newsletter di fine Novembre l'ho ricevuta e, dato il largo anticipo, ho fatto affidamento sul fatto che nei giorni della votazione avrei visto apparire sul forum il relativo thread. Ora non so se è stata colpa mia che non ho notato il thread oppure nella vista dei thread non lettti, relativi al mio account, non è apparso e quindi è stata colpa mia che ho proprio dimenticato le date.