2.4ghz Futaba

[merengue]

Originalmente inviato da dtruffo

Spero anche via scatolotti vari, altrimenti la vedo dura se devi cambiare un servo sul campo !!

Beh, io penso che la funzione "reverse" e tutte le altre della TX verranno pur conservate.. in fondo è sempre la tx che genera il segnale di posizione dei servi.

[dtruffo]

Originalmente inviato da merengue

Beh, io penso che la funzione "reverse" e tutte le altre della TX verranno pur conservate.. in fondo è sempre la tx che genera il segnale di posizione dei servi.

Quelle so il meno. Il problema e' dire al servo quale 'fgunzione' deve svolgere.

Se non lo programmi non va, se gli dici che deve fare 'lelevatore, hai voglia a metterlo su un alettone, rispondera' sempre e solo al comando elevatore, sino a che non lo riprogrammi, come e' giusto che sia !

[Sergio_Pers]

Originalmente inviato da dtruffo

Vorrebbe dire includere in ogni servo la sezione RF e le antenne .... complicatino
In questo modo l'RX si assume il compito di ricevere il segnale (stadio RF , antenne, filtri etc), il resto viene passato al servo che 'capisce' come e quando agire

Capito...OK, Grazie

Sergio

[davide_moretti]

Originalmente inviato da Sergio_Pers

Grazie per la conferma che non sono ancora del tutto rincitrullito...

In altre parole, la funzione di scelta "di canale" e' trasferita dalla ricevente al servo...

Pur correndo il rischio di dire stupidaggini..
Dato che il segnale nasce dalla Tx, la Rx e' solo un "trasferitore" (lasciando perdere le funzioni di "pulire" e "stabilizzare")... perche' non trasferire questa funzione di ricezione direttamente al servo... si ha solo un filo per l'alimentazione e basta... ci penserebbe il servo a capire come e se si deve muovere..

Dove sbaglio ??..

Sergio

Per quello che ne ho capito io si tratta di un sistema di reti a due livelli.
La tx è in rete con la sola rx, la rx solo con servi.
Il fatto di avere un sistema ricevente per ogni servo, e quindi di mettere ogni singolo servo in rete con la tx sembra un po' ridondante: la rx è comunque piccola ed un bus di alimentazione lo dovresti comunque implementare, a questo punto un conduttore per i segnale è decisamente accettabile.
I servi andranno in qualche modo indirizzati, bisognerà dargli un nome od un numero che li identifichi sulla rete in cui la rx è master e i vari servi slave. Immagino verrà fatto via sw, visto che l'uso di dipswitch rihiederebbe un ingombro, che nel caso specifico, sembra innaccettabile. In caso di sostituzione del servo sarà necessario indirizzare il servo nuovo con l'indirizzo uguale a quello che andrà a sostituire.
Sono comunque considerazioni generali basate sulla mia esperienza professionale, il sistema della Futaba non lo conosco e non lo voglio, per il monento, conoscere.

Un saluto a tutti

[Sergio_Pers]

Originalmente inviato da davide_moretti

......
Per quello che ne ho capito io si tratta di un sistema di reti a due livelli.
La tx è in rete con la sola rx, la rx solo con servi.
........
Un saluto a tutti

Comunque sia mi fa pensare una cosa...
Se dalla ricevente di "dipana" un bus di trasmissione.... immagino due possibili configurazioni:
- filo ad anello (la vecchia Token Ring della IBM anni 90)
- seriale ( vecchio sistema IBM System3 .. anni 80 ).
Ogni servo dovrebbe essere dotato di una spinetta aT ( o anche una entrata e uscita ) ,per leggere se interessa il messaggio e lasciar passare gli altri, anche in caso di guasto dello stesso servo.

Quindi si innesca una necessaria "cablatura" del filo/fili, che rimane tipica di quel modello dato una diversa posizione dei servi da un modello ad un altro.

Ariquindi, salvo il vantaggio delle dimensioni della ricevente, fatto notare da Simone e che non e' secondario e tenendo presente che comunque 'sti "poveri" servi devono essere alimentati (quindi una cavo di alimentazione adeguato) i numero dei "fili" circolanti in fuso non cambia molto ( in compenso i servi aumenteranno di costo... )

Dove arisbaglio ?

Sergio

[dtruffo]

Altra analisi corretta.
Bene o male ai servi la corrente bisogna portarla, quindi al limite si potrebbe recuperare qualche grammi ei cavi di segnale.

Credo che l'idea di Futaba non sia tanto nell'alleggerire il cablaggio, quanto nell'eliminare il segnale PWM che attualmente mandiamo ai servi, arrivando sino ad esse son un'informazione digitale, quindi piu' precisa e meno soggetta ad eventuali disturbi esterni.

L'impressione e' comunque quella di un'operazione prettamente commerciale, per forzare l'utilizzo del loro servi e quindi creare un legame indissolubile che parte dal TX, passa dal modulo TX (addirittura nazionalizzato), va alla RX (che deve essere compatibile a TX e relativo modulo per finire ai servi che devono a loro volta essere in grado di dialogare con tutta la catena.

Questo permetterebbe sicuramente di recuperare un mercato che volenti o nolenti si sono persi, ovvero quello dei servocomandi.

In questo modo uniscono l'utile al dilettevole... Se vuoi un sistema innovativo, sicuro, preciso etc... e entri nella 'sprirale' acquisti tutto da un unico produttore...

Bisognera' capire, a fronte di questa limitazione, quali potranno essere i vantaggi pratici nell'adozione di un sistema del genere.

Sicuramente si potra' ottenere quello che oggi si fa con centraline di terze parti (vedi Eagle Tree o Weatronic) che permettono di leggere gli assorbimenti di ogni singolo servo, loggare il loro movimento etc. Il problema sara' capire se questa utilita' sara' piu' o meno a buon mercato.

Oggi acquisto una eagle tree e la sposto su piu' modelli, facendo un'investimento una sola volta, domani forse dovro' investire meno per ogni singolo servo, ma dovro' farlo anche se tali funzioni non mi interessano.

A mio modo di vedere sara' un sistema che entrera' sul mercato, sara' acquistato da molti per mera curiosita' (e da pochissimi per effettiva necessita'), e pian piano sara' 'spinto' per ottenere il risultato di mercato sopra descritto.

Per quanto riguarda le dimensioni, il ridurre il numero di connettori a bordo di una ricevente potrebbe essere molto interessante, ma gia' oggi sarebbe sufficiente (per un modello ripo F3K) portare gli attuali 12 contatti (4 servi per 3 poli) a 6 (2 alimentazioni in comune e 4 segnali), riducendo del 50% la larghezza di una rx.

[davide_moretti]

Originalmente inviato da dtruffo

......

Credo che l'idea di Futaba non sia tanto nell'alleggerire il cablaggio, quanto nell'eliminare il segnale PWM che attualmente mandiamo ai servi, arrivando sino ad esse son un'informazione digitale, quindi piu' precisa e meno soggetta ad eventuali disturbi esterni.

.....

Probabilmente è così come dici tu.

Forse l'idea è quella di digitalizzare l'informazione (comando) che deve passare da rx ai servi. In linea di massima impacchettando l'informazione una apposita stringa il servo può verificarne l'integrità e agire di conseguenza in caso d'errore (disturbo).
Se invece l'informazione tra rx e servo viaggia con un segnale, il servo credo non abbia nessuna possibilità di discriminare un comando da un disturbo.
Questo sulla carta poi talvolta i bus danno tanti di quei grattacapi da rimpiangere il cablaggio tradizionale.

Ciao

[gmo78]

Originalmente inviato da dtruffo

[...]

Per quanto riguarda le dimensioni, il ridurre il numero di connettori a bordo di una ricevente potrebbe essere molto interessante, ma gia' oggi sarebbe sufficiente (per un modello ripo F3K) portare gli attuali 12 contatti (4 servi per 3 poli) a 6 (2 alimentazioni in comune e 4 segnali), riducendo del 50% la larghezza di una rx.

Non sono daccordo, questo incrementerebbe molto i rischi nel caso di un falso contatto di uno dei pin

[Sergio_Pers]

Originalmente inviato da gmo78

Non sono daccordo, questo incrementerebbe molto i rischi nel caso di un falso contatto di uno dei pin

Dai... non togliere la miglior causa che puo' autorizzare a dire "INTERFERENZA"
.

Sergio

[merengue]

Tutto ciò per ridurre le dimensioni per l'F3K?? Non credo, troppo banale e riduttivo. In fondo le rx piccole ci sono già, e per diminuire le dimensioni basta usare componentistica specifica (vedi rx AR6300 e similia).
A parte il blocco del cliente sulla marca, non vedo altri motivi dell'esistenza dell'S-bus