frsky s-bus

[minulino]

confesso che sono ignorante , ma come funziona l's-bus di sky e di cosa abbiamo bisogno per farlo funzionare?

[romoloman]

Originalmente inviato da minulino

confesso che sono ignorante , ma come funziona l's-bus di sky e di cosa abbiamo bisogno per farlo funzionare?

Qui la documentazione su S-BUS
Futaba® S.Bus System

Per farlo funzionare non hai bisogno di nulla, il segnale S-BUS esce dalla ricevente, e poi ad esempio può essere usato in una centralina flybarless, in una scheda per multicottero, oppure con servi sbus.

[mauro cap]

scusa, ma non mi è chiaro :

posso sostituire una ricevente classica con una s-bus ?
Ha bisogno di qualche programmazione o è già pronta all'uso ?
Necessita del decoder o può lavorare anche senza ?

(Nelle istruzioni si parla di programmatore, decoder, ecc. .... )
Grazie in anticipo dei chiarimenti.

[romoloman]

Originalmente inviato da mauro cap

scusa, ma non mi è chiaro :

posso sostituire una ricevente classica con una s-bus ?
Ha bisogno di qualche programmazione o è già pronta all'uso ?
Necessita del decoder o può lavorare anche senza ?

(Nelle istruzioni si parla di programmatore, decoder, ecc. .... )
Grazie in anticipo dei chiarimenti.

Esistono due casi:
1) le periferiche connesse alla ricevente sono SBUS (servi/flight controller/esc)
2) le periferiche sono standard (servi e esc attaccati attualmente alla ricevente convenzionale)

nel caso 1 non serve nulla, solo i programmatori delle varie periferiche perchè devi in pratica dire ad ogni singolo servo a che canale deve rispondere, (difficilmente se uno non ha un sistema tipo futaba si trova nella condizione 1)

nel caso 2 per attaccare dei servi standard all'SBUS si usano dei convertitori (decoder), che consentono di attaccare fino a 4 servi. Questi convertitori vanno programmati per dire alle uscite quali canali servono.
Non si programma la ricevente, ma si programmano le periferiche che si attaccano alla ricevente.

[italo.driussi]

Su tre fili passano il positivo il negativo e il segnale di tutti i servi con la codifica dell' indirizzo.

In un servo sb devi programmare a che indirizzo/canale rispondere e legge sul bus solo i dati che lo interessano.

Esistono anche convertitori da sb a servi standard che vanno programmati per un determinato indirizzo.

In un ipotetica ala con alettone, flap, carrello retrattile e aereofreno al posto di 4 spinette ne colleghi solo una per tutti 4 i servi

[flyhight]

Originalmente inviato da mauro cap

scusa, ma non mi è chiaro :

posso sostituire una ricevente classica con una s-bus ?
Ha bisogno di qualche programmazione o è già pronta all'uso ?
Necessita del decoder o può lavorare anche senza ?

(Nelle istruzioni si parla di programmatore, decoder, ecc. .... )
Grazie in anticipo dei chiarimenti.

Dunque il discorso è un po' intricato, ma semplice;
In generale puoi sostituire una ricevente classica con una s.bus sempre rimanendo sulla stessa marca della radio, oppure con una ricevente s.bus dichiaratamente compatibile;
Parlando in particolare di FrSky, essa ha prodotto anche riceventi che mandano fuori il segnale compatibile col protocollo Futaba s.bus, da una delle uscite del ricevitore stesso; ciò significa che se tu hai una radio FrSky e un ricevitore FrSky con uscita s.bus, puoi usarlo o con servi normali (PWM analogici o digitali); oppure puoi collegare dei servi Futaba s.bus (programmabili), oppure, caso più frequente, collegare il ricevitore subito ad una centralina di controllo es. di un quadricottero con un solo data cable in genere incluso nell'acquisto della centralina, e poi dalla centralina collegare i 4 o più regolatori del quadricottero o dell'elicottero; ricordo che Futaba, in concomitanza dell'implementazione della telemetria, ha introdotto il nuovo protocollo s.bus 2 (sui nuovi ricevitori sono presenti entrambe le uscite per i rispettivi segnali, il precedente s.bus ed il nuovo s.bus 2), utilizzabile per sensori e servi Futaba s.bus 2, e non adottato, per quanto ne sappia da ditte terze che producono centraline di controllo es. di quadricotteri, che sono rimaste appunto al protocollo s.bus;

Non ha bisogno di programmazione;

Deve lavorare senza decoder, i quali esistono per 2 casi opposti: primo caso, io ho una radio di qualsivoglia marca, ed il suo ricevitore compatibile, ma non ha uscita s.bus; ora voglio connetterci dei servi s.bus per poterli programmare o gestire su un modello risparmiando sui cablaggi, o per connettere questo ricevitore ad una centralina di controllo s.bus: allora esistono decoder che in ingresso hanno fino ad una decina di connessioni DAL tuo ricevitore, ed in uscita un solo data cable in cui ho il segnale s.bus.
Caso opposto; ho una radio qualsivoglia con ricevitore compatibile che ha anche uscita s.bus, (o esistono ricevitori che hanno solo uscita s.bus), e voglio sfruttare questa uscita, ma ho dei servi normali non s.bus, o una centralina di controllo priva di ingresso s.bus; ci sono decoder che prendono in ingresso il segnale s.bus e danno in uscita tre segnali normali PWM; questi secondi decoder vanno programmati mediante una ulteriore interfaccia per PC, o programmatore dedicato; notare che il caso di centralina di controllo es. di quadricotteri non s.bus e ricevitore s.bus, ma che ha anche uscite normali, caso più normale, si risolve più semplicemente usando le altre uscite normali del ricevitore (a meno del caso particolarissimo che il ricevitore abbia SOLO uscita s.bus) con tanti cavetti, in generi anche questi inclusi con l'acquisto della centralina, quanti sono i canali necessari, è assurdo utilizzare l'uscita s.bus per poi doverla ricodificare in PWM, quando già avevo il PWM dal ricevitore; caso invece più utile per l'utilizzo di questo secondo tipo di decoder è l'utilizzo misto (utilizzato personalmente su un aereo con servi misti e regolatore per motore elettrico non s.bus, tanto più che regolatori s.bus non esistono a quanto ne sappia); cioè sfrutti sia le uscite normali che quella s.bus, poi dove serve il segnale normale PWM decodifichi il segnale s.bus con uno o 2 decoder da tre uscite ognuno, secondo quanti servi e regolatori non s.bus hai (nel mio caso 5);
aggiungo che a quanto ne sappia non esistono decoder s.bus 2 ne del primo tipo, ne del secondo.

Credo che il discorso teorico è incomprensibile; per capire dovremmo metterci a tavolino con tutti i dispositivi e creare una esigenza reale, altrimenti le combinazioni possibili per l'utilizzo del protocollo s.bus possono essere veramente tante...

[romoloman]

Originalmente inviato da flyhight

Dunque il discorso è un po' intricato, ma semplice;
In generale puoi sostituire una ricevente classica con una s.bus sempre rimanendo sulla stessa marca della radio, oppure con una ricevente s.bus dichiaratamente compatibile;
Parlando in particolare di FrSky, essa ha prodotto anche riceventi che mandano fuori il segnale compatibile col protocollo Futaba s.bus, da una delle uscite del ricevitore stesso; ciò significa che se tu hai una radio FrSky e un ricevitore FrSky con uscita s.bus, puoi usarlo o con servi normali (PWM analogici o digitali); oppure puoi collegare dei servi Futaba s.bus (programmabili), oppure, caso più frequente, collegare il ricevitore subito ad una centralina di controllo es. di un quadricottero con un solo data cable in genere incluso nell'acquisto della centralina, e poi dalla centralina collegare i 4 o più regolatori del quadricottero o dell'elicottero; ricordo che Futaba, in concomitanza dell'implementazione della telemetria, ha introdotto il nuovo protocollo s.bus 2 (sui nuovi ricevitori sono presenti entrambe le uscite per i rispettivi segnali, il precedente s.bus ed il nuovo s.bus 2), utilizzabile per sensori e servi Futaba s.bus 2, e non adottato, per quanto ne sappia da ditte terze che producono centraline di controllo es. di quadricotteri, che sono rimaste appunto al protocollo s.bus;

Build telemetry Sensors for Futaba SBUS2 and a Data Logger

non esattamente... anche del sbus2 è stato fatto il reverse enginering.
tuttavia altri produttori hanno preferito separare i bus dei sensori da quelli di comando, la ragione è semplice, un corto su un bus dei sensori non manda in crash il bus di comando.
Le periferiche SBUS infatti da un punto di vista strettamente elettronico sono sempre ad alta impedenza rispetto al filo del segnale, non possono pertanto modificarne lo stato.
Le periferiche SBUS2 invece quando "parlano" sono a bassa impedenza visto che devono loro comandare il bus.
Se per errore una periferica manda in corto il cavo del segnale verso massa o lo tiene a livello logico alto, le altre periferiche non comunicano più.

In un mondo perfetto SBUS2 è superiore, in un mondo dove le cose possono rompersi, beh introduce possibilità di errori.

[mauro cap]

ok tutto chiaro: per ora mi limiterò ad una classica ricevente. Poi vedremo!
Grazie a tutti

[flyhight]

Originalmente inviato da romoloman

Build telemetry Sensors for Futaba SBUS2 and a Data Logger

non esattamente... anche del sbus2 è stato fatto il reverse enginering.
tuttavia altri produttori hanno preferito separare i bus dei sensori da quelli di comando, la ragione è semplice, un corto su un bus dei sensori non manda in crash il bus di comando.
Le periferiche SBUS infatti da un punto di vista strettamente elettronico sono sempre ad alta impedenza rispetto al filo del segnale, non possono pertanto modificarne lo stato.
Le periferiche SBUS2 invece quando "parlano" sono a bassa impedenza visto che devono loro comandare il bus.
Se per errore una periferica manda in corto il cavo del segnale verso massa o lo tiene a livello logico alto, le altre periferiche non comunicano più.

In un mondo perfetto SBUS2 è superiore, in un mondo dove le cose possono rompersi, beh introduce possibilità di errori.

Si, il motivo per cui alcuni scelgono di usare s.bus per dispositivi che ricevono solo, e s.bus 2 per telemetria, sicuramente è di sicurezza come dici tu; personalmente penso che se Futaba ha, ormai da un anno abbondante mi sembra, prodotto servi s.bus 2 è perché è sicura di farli funzionare bene sullo stesso segnale dei sensori; poi, esprimo concetti personali, visto che abbiamo una psicologia oltre che la fredda intelligenza, penso che se Futaba sarà conservativa e non rivoluzionaria, continuerà a produrre RX che hanno sia s.bus che s.bus 2, altrimenti in futuro potrebbe anche soppiantare s.bus in favore del solo s.bus 2, difficilmente, ma ripeto, sono considerazioni passionali e inutili... Grazie comunque del link all'articolo...

PS: anche del s.bus 2 hanno fatto reverse engineering, significa che lo hanno fatto dell's.bus, e che lo abbiano fatto spero non significhi che le ditte che fanno RX s.bus non abbiano i diritti del protocollo proprietario, seppur semplice e sempre che ci siano dei diritti... Cioè non vorrai dirmi che hanno visto cosa esce e fatto ricevitori che buttano fuori quanto misurato senza consultare Futaba, marchiato s.bus, senza che Futaba approvi il corretto funzionamento coi suoi magari servocomandi?

[romoloman]

Originalmente inviato da flyhight

PS: anche del s.bus 2 hanno fatto reverse engineering, significa che lo hanno fatto dell's.bus, e che lo abbiano fatto spero non significhi che le ditte che fanno RX s.bus non abbiano i diritti del protocollo proprietario, seppur semplice e sempre che ci siano dei diritti... Cioè non vorrai dirmi che hanno visto cosa esce e fatto ricevitori che buttano fuori quanto misurato senza consultare Futaba, marchiato s.bus, senza che Futaba approvi il corretto funzionamento coi suoi magari servocomandi?

Sia la Comunità Europea che gli Stati Uniti consentono il reverse enginering a norma di legge a scopo di interoperabilità. Quanto al reverse enginering del protocollo: nessuno ha consultato futaba che io ne sappia, il protocollo è talmente semplice che non ce ne è stato bisogno.

Magari futaba potrebbe non garantire (stupidamente) i suoi servi S-BUS con riceventi non sue, ma da un punto di vista legale fortunatamente il reverse enginering non solo esiste ma anche è consentito.

Inoltre neanche il nome ha copyright perchè SBUS è un marchio della SUN microsystem (ora Oracle)

Tu sapessi di quanta robe più cruciale per l'esistenza umana è stato fatto reverse enginering a causa della mancanza o perdita della documentazione originaria ti preoccuperesti meno di sapere che la stessa cosa è stata fatta per dei servocomandi RC

Per fare un'elenco nel solo settore informatico:
BIOS dei PC senza i quali non sarebbero esistiti PC compatibili
Filesystem di rete di microsoft senza il cui reverse enginering non esisterebbero gran parte dei NAS
Format binario dei documenti office, e di altre software house ora chiuse,
Senza il reverse enginering la leggibilità dei documenti sarebbe ristretta ad un software proprietario, praticamente togliendoti la proprietà dei tuoi dati.

Se poi parliamo del corpo umano e della medicina, senza reverse enginering non esisterebbero una marea di medicine...