frsky s-bus

[romoloman]

[QUOTE=flyhight;4043492personalmente 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...
[/QUOTE]

In altri settori:
Anche la Toyota era sicura che la sua centralina di controllo dell'acceleratore funzionasse senza problemi... Peccato che abbia fatto dei morti... E si sta parlando comunque di Toyota...
Toyota's killer firmware: Bad design and its consequences | EDN

I guasti spesso capitano in modo imprevisto/diverso rispetto alla progettazione, soprattutto quando su un bus si vanno ad attaccare periferiche sviluppate da reparti diversi dello stesso produttore o peggio ancora da produttori diversi,
ESC di un produttore e servi di un altro.

Comunque siamo abbondantemente OT.
Non si sta parlando di SBUS2 e neanche delle riceventi Futaba...

[flyhight]

Originalmente inviato da romoloman

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 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...

Ma scusa, sono stato gentile con te e ti inasprisci? Chi ha detto che la reverse engineering sia una pratica non consentita o inutile, visto che è una scienza anche a me ben nota? Forse mi sono spigato male, il solito mio amico al campo ha una RX FrSky s.bus, ha attaccato il suo bel flight controller all'uscita s.bus e mi son chiesto: ma i caratteri di stampa s.bus non mi sembrano quelli dei miei ricevitori Futaba; non è che hanno fatto reverse engineering di un protocollo tutto sommato semplice (non c'è cifratura dei dati) violando qualche ipotetico diritto di utilizzo del protocollo? Chiedo, non affermo...

[romoloman]

Originalmente inviato da flyhight

Ma scusa, sono stato gentile con te e ti inasprisci? Chi ha detto che la reverse engineering sia una pratica non consentita o inutile, visto che è una scienza anche a me ben nota? Forse mi sono spigato male, il solito mio amico al campo ha una RX FrSky s.bus, ha attaccato il suo bel flight controller all'uscita s.bus e mi son chiesto: ma i caratteri di stampa s.bus non mi sembrano quelli dei miei ricevitori Futaba; non è che hanno fatto reverse engineering di un protocollo tutto sommato semplice (non c'è cifratura dei dati) violando qualche ipotetico diritto di utilizzo del protocollo? Chiedo, non affermo...

Non mi sembra di essermi inasprito, comunque diritti non ne esistono se non sul logo...
Motivo per cui FrSky non può copiare il logo Futaba, ma può tranquilllamente reingegnerizzare il protocollo.

[klamath]

Originalmente inviato da flyhight

Ma scusa, sono stato gentile con te e ti inasprisci? Chi ha detto che la reverse engineering sia una pratica non consentita o inutile, visto che è una scienza anche a me ben nota? Forse mi sono spigato male, il solito mio amico al campo ha una RX FrSky s.bus, ha attaccato il suo bel flight controller all'uscita s.bus e mi son chiesto: ma i caratteri di stampa s.bus non mi sembrano quelli dei miei ricevitori Futaba; non è che hanno fatto reverse engineering di un protocollo tutto sommato semplice (non c'è cifratura dei dati) violando qualche ipotetico diritto di utilizzo del protocollo? Chiedo, non affermo...

non conosci Romolo, non si inasprisce mai, anzi a volte mi chiedo come faccia, ma se si inasprisce te ne accorgi...si eleva a 20000000000 Volts e skrachhhhh

[flyhight]

Originalmente inviato da romoloman

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

Perdonami, non voglio farti elevare i Volts: Sunmicrosystem, ora del gruppo Oracle ma poco importa, ha inventato un bus chiamato SBus (nome sofferente di cloni in quanto si riferisce al generico termine "serial bus", ossia sistema di trasmissione seriale); quello Futaba si chiama S.Bus, che potrebbe anche in qualche modo discendere dal primo detto, ma dubito che, una volta ad oggi fatto suo in qualche modo che esula dal nostro discorso, non abbia diritti, se intendo per sistema S.Bus quello appunto per servi Futaba, sensori telemetrici Robbe o Futaba (Robbe è evidente che è in chiara collaborazione e produce da sempre prodotti per Futaba secondo certe specifiche, vedi le radio serie FX)... il dubbio sullo specifico marchio "S.Bus" Futaba (non su marchi Futaba, Fasst ecc., che ovviamente hanno copyrights) mi sorge ancora di più, non credo di essere fuori tema, anche se stiamo discorrendo di un dubbionon tecnico ma più commerciale/copyrights, stiamo parlando di S.Bus figlio di nessuno, quello insomma Futaba tanto per intenderci... Mi informerò meglio...

[romoloman]

Originalmente inviato da flyhight

Perdonami, non voglio farti elevare i Volts: Sunmicrosystem, ora del gruppo Oracle ma poco importa, ha inventato un bus chiamato SBus (nome sofferente di cloni in quanto si riferisce al generico termine "serial bus", ossia sistema di trasmissione seriale); quello Futaba si chiama S.Bus, che potrebbe anche in qualche modo discendere dal primo detto, ma dubito che, una volta ad oggi fatto suo in qualche modo che esula dal nostro discorso, non abbia diritti, se intendo per sistema S.Bus quello appunto per servi Futaba, sensori telemetrici Robbe o Futaba (Robbe è evidente che è in chiara collaborazione e produce da sempre prodotti per Futaba secondo certe specifiche, vedi le radio serie FX)... il dubbio sullo specifico marchio "S.Bus" Futaba (non su marchi Futaba, Fasst ecc., che ovviamente hanno copyrights) mi sorge ancora di più, non credo di essere fuori tema, anche se stiamo discorrendo di un dubbionon tecnico ma più commerciale/copyrights, stiamo parlando di S.Bus figlio di nessuno, quello insomma Futaba tanto per intenderci... Mi informerò meglio...

SBUS
S.BUS
S-BUS
S_BUS

commercialmente sono 4 marchi differenti, se non lo fossero S.BUS non sarebbe utilizzabile in quanto TM di sun microsystem/oracle.

Poi ti ripeto un conto è il marchio un conto è il protocollo..
Sta di fatto che non mi pare che futaba abbia mai fatto causa a nessuno..

[MicheTN]

Avrei una domanda a proposito del protocollo S-BUS:
sto allestendo un modello con dieci canali, 4 in fusoliera e 6 nelle ali (3 per semiala). Utilizzo una centralina (giofly 10 canali) per alimentare il tutto. La ricevente è una X8R.
Vorrei montare un s-bus decoder frsky in ogni semiala, in modo da semplificare i cablaggi e ridurre i rischi di interferenza.
I miei dubbi:
- posso semplicemente sdoppiare passivamente (con una Y) l'uscita s-bus della X8R o è necessario un qualche tipo di hub?
- posso far passare il segnale s-bus in centralina o conviene prima convertire in pwm e poi passare questo in centralina (quindi utilizzando un solo decoder posizionato in fusoliera)?

[romoloman]

Originalmente inviato da MicheTN

Avrei una domanda a proposito del protocollo S-BUS:
sto allestendo un modello con dieci canali, 4 in fusoliera e 6 nelle ali (3 per semiala). Utilizzo una centralina (giofly 10 canali) per alimentare il tutto. La ricevente è una X8R.
Vorrei montare un s-bus decoder frsky in ogni semiala, in modo da semplificare i cablaggi e ridurre i rischi di interferenza.
I miei dubbi:
- posso semplicemente sdoppiare passivamente (con una Y) l'uscita s-bus della X8R o è necessario un qualche tipo di hub?
- posso far passare il segnale s-bus in centralina o conviene prima convertire in pwm e poi passare questo in centralina (quindi utilizzando un solo decoder posizionato in fusoliera)?

La Y va bene, verifica comunque la sezione dei cavi della Y
Personalmente porterei in ala anche un alimentazione aggiuntiva o mi accerterei che il cavo SBUS abbia una discreta sezione, detto questo puoi portare in ala il decoder Sbus e basta

[MicheTN]

Ti ringrazio molto per la risposta.
Un mio dubbio riguardava anche la possibilità di far passare in centralina l'sbus, vista la presenza di filtri attivi. In alternativa potrei prevedere dalla ricevente il solo polo del segnale dell'uscita sbus e poi affiancarci un'alimentazione dalla centralina. Le masse essendo tutte in comune non dovrebbero creare problemi...

[gisante]

Mi riaggancio a questo vecchio post per tentare di togliermi una curiosità... Ho una Taranis ed un ricevitore X8R che, tra le altre, mette a disposizione un serial bus. Tenendo conto la disponibilità di dispositivi a microcontrollore anche fortemente integrati (cito Arduino giusto per esempio), mi è balenata l'idea di poter leggere il bus FrSky per poter controllare uno di questi dispositivi. La domanda vera è: il protocollo è pubblicamente disponibile o l'unica strada sarebbe l'ingegneria inversa?

Grazie.