Shop our Airplanes Products Drone Products Sales
Thread Tools
Jul 08, 2015, 04:03 PM
Registered User
Discussion

DIY Futaba Telemetry receiver ? Any contributors out there ?


Edit 15 JUL 2015:
At the time of creating this thread I had no idea how much Futaba messed up their protocols and made things complicated. Only the god knows why they have FASST (7ch / 8ch / 10ch / MULTI), FASST+telemetry, FASSTest, FHSS, S-FHSS, T-FHSS Air Systems and T-FHSS Surface Systems which are not compatible between each other or only partly.
Originally I wanted to create "Robbe Futaba Telemetry Box" compatible device which works with FASST+telemetry.
Realizing that there is s only one R6308SBT receiver from Robbe which have FASST+Telemetry, I abandoned the whole idea.
This receiver is available only in EU, FASST+Telemetry is obviously a dead for Futaba and above that Robbe Modellsport GmbH & Co declared insolvency few months ago.


Few weeks ago I was sniffing the web when I found out that Futaba telemetry box is not only super expensive but also based on a regular receiver with a different firmware. Since I have one telemetry receiver R6308SBT I got an idea to get some details regarding futaba telemetry protocol.

Before you continue reading, let me please warn you that I don't have enough time to crack the protocol alone and don't ask me to do so, I was rather thinking about some community project (involving Circuit Maker ) ...

I happened to have TFR-4B receiver which could possibly do all the fun. It contains RF chip, MCU (both well documented) and a special stream-decoding chip. First orange clones had Altera CPLD or small FPGA (not sure at the moment) but cutting the costs down forced the Chinese to replace it with an ASIC.
The good thing is that the ASIC acts as the SPI master and all data are not difficult to understand. At least for the standard FASST protocol.

The MCU is STM8L151K6 which on the beginning configures the RF chip for the reception and then just converts data from SPI to PPM.
If the community is lucky, it might have to be enough just to change the RF chip configuration to set channels to telemetry ones and decode the data stream. Of course it means custom FW. The MCU also have bootloader with USART which could enable a testing in community without any special tools.

The target would be TFR-4B receiver without HW modifications turned into FASSTest telemetry receiver with serial output. The board than shall be used with aruduinos or whatever master systems.

It is not going to be cheaper, there is no profit, only hard work .
So.. anyone bored ?
Last edited by warhawk.cz; Jul 15, 2015 at 01:21 AM.
Sign up now
to remove ads between posts
Jul 08, 2015, 08:15 PM
Registered User
DIY Futaba Telemetry receiver ? i think nobody do this
you say " you don't have enough time to crack the protocol alone and don't ask me to do so '' . Everyone here also same you
Jul 09, 2015, 02:18 AM
Registered User
Quote:
Originally Posted by Jame David
DIY Futaba Telemetry receiver ? i think nobody do this
you say " you don't have enough time to crack the protocol alone and don't ask me to do so '' . Everyone here also same you
I meant to say that I would appreciate some buddies on this possible project. I do electronics (embedded systems) for living but RF is a black magic for me

Well, if nobody were interested I would rather let this project sleep. I am not in need of telemetry.
Jul 09, 2015, 06:04 AM
Bart
I think that the data shout look almost the same as what is put in on the telemetry receiver side

here a nice blog with a lot of in formation

http://sbustelemetrysensors.blogspot...rt-sensor.html
Last edited by dirtyballs; Mar 18, 2017 at 09:23 AM.
Jul 09, 2015, 06:19 AM
Registered User
Time for Simon Chambers to enter the stage
Jul 09, 2015, 07:16 AM
Bart
He won't I think. He diapered at a point in time and I never seen him again.
Li Wang went on, I used the information to make a multisensor.
Castle Creations live data to Futaba Telemetry.

I am busy with a complete different project
Oculus Rift ( Razor OSVR ) for FPV.
https://www.rcgroups.com/forums/show....php?t=2375314

so I have not a lot of time.
Last edited by dirtyballs; Mar 18, 2017 at 09:23 AM.
Jul 09, 2015, 09:01 AM
Registered User
Quote:
Originally Posted by renatoa
Time for Simon Chambers to enter the stage
Honestly, I have been thinking about him
Jul 09, 2015, 09:13 AM
Registered User
Quote:
Originally Posted by dirtyballs
I think that the data shout look almost the same as what is put in on the telemetry receiver side

here a nice blog with a lot of in formation

http://sbustelemetrysensors.blogspot...rt-sensor.html

Bart,
The biggest struggle for me is absence of deeper FASST / FASSTest RF knowledge.

Manual for the telemetry receiver says that telemetry data are being transmitted immediately when the receiver is turned on. It means there must be a selection of telemetry channels. Once I / we get this information it should be able to use BusPirate or custom FW to change the RF chip settings. I expect the stream decoding will be same.
Jul 09, 2015, 09:46 AM
Bart
on the SBUS2, it is already a sequence, And I think futuba sends always all telemetry slots, even if there is no data. Why do I think that, the SBUS has a fixed sequence of these telemetry slots on the 100kbit serial bus and a sensor may take any of these slots, as long as it is not overlapping with another sensor.

I can easily make a module that spits out always the same telemetry data, that has to be atached to a SBUS2 receiver. So that it is easy to find that data on the receiver side of the telemetry data.
Last edited by dirtyballs; Mar 18, 2017 at 09:23 AM.
Jul 09, 2015, 02:41 PM
Registered User
Do you know if the receiver transmits data back even though there is no sensor connected ? e.g. a receiver voltage ? However the only one telemetry rx is hidden deep in my glider but I will ask my friend and bring it to work. I will check the channels with small antenna and spectrum analyzer.
In meanwhile I will try to get more information about FASST. Do you guys have some useful links here to the forum or somewhere else ? I must say I am still not smart regarding 7ch, 8ch, 10ch, Multi-ch mode etc...
Last edited by warhawk.cz; Jul 09, 2015 at 04:32 PM.
Jul 09, 2015, 04:22 PM
Bart
always, the 7008 has two sensor, RX Voltage and external voltage, so it always needs to send telemetry data
Last edited by dirtyballs; Mar 18, 2017 at 09:23 AM.
Jul 10, 2015, 03:20 AM
Registered User
Quote:
Originally Posted by dirtyballs
always, the 7008 has two sensor, RX Voltage and external voltage, so it always needs to send telemetry data

Bart,
What about R6308SBT I have ? It should be same, right ? I will find out I guess

that robbe/futaba thing is also nightmare.
Jul 13, 2015, 07:46 AM
Registered User
R6308SBT is a FASST receiver that works with futaba telemetry box only, beware !

Yes, indeed, Futaba no more deserve any kudos from the past...
- the only company having 4 (four) non-interoperable protocols, all live
- the only company producing a radio working with a single receiver and no other choices
- the only company producing a telemetry receiver for non telemetry radios, which can't be used for their own top of the line telemetry radios...

Everything done with the clear goal to layer the customer mass in herds according to company vision about how customers must consume RC the Futaba way: trash your whole previous system and buy everything new when you change to next level. Just because we say so, and we can... and the sheeps are happy to follow.
Jul 13, 2015, 10:06 AM
Registered User
Quote:
Originally Posted by renatoa
R6308SBT is a FASST receiver that works with futaba telemetry box only, beware !

Yes, indeed, Futaba no more deserve any kudos from the past...
- the only company having 4 (four) non-interoperable protocols, all live
- the only company producing a radio working with a single receiver and no other choices
- the only company producing a telemetry receiver for non telemetry radios, which can't be used for their own top of the line telemetry radios...

Everything done with the clear goal to layer the customer mass in herds according to company vision about how customers must consume RC the Futaba way: trash your whole previous system and buy everything new when you change to next level. Just because we say so, and we can... and the sheeps are happy to follow.
Yes, that is sick and I agree with you. I am not happy with Futaba business plan either but I happened to have 12z and couple FASST receivers which I am happy with. Previously I had a different 2.4GHz system and it cost me two planes. (no flame here please).

So, as far as I understood:

Futaba protocols:

FASST - can be 7ch/8ch/10ch (proportional) and MULTI channel (12 proportional +2 digital).

7ch mode shall be used with higher priority because of lower latency.
8ch/10ch mode is extended version of original 7ch as a result of old radios support (9Z, 9C, 10C).
Futaba then realized that for more channels they need to change protocol a lot and introduced MULTI. User should switch to MULTI mode only when demands more channels. Latency is somehow higher than 7ch.

Telemetry: The telemetry function was obviously glued besides the standard protocol. It uses separate RF channels and does not interfere with FASST at all. Can be received only by external box.

FASSTest - At some certain point Futaba realized that they should catch the train and have a protocol with native telemetry. At this time there are 14SG and 18 MZ which are able to receive telemetry directly to radio. This works only with R700x receivers. This way they have two telemetry options (FASST+telemetry and FASSTest) which are not compatible between each other.

Since the universe is not simple system, there are also two additional systems on budget which don't use special futaba ASICs. Nobody knows what is a difference between them....

FHSS
S-FHSS


What do I miss ? Is it right ? Please correct me if I am wrong.
Jul 13, 2015, 11:26 AM
Registered User
Protocol change for Futaba became a must when in early '10s ETSI revealed the requirements of future V1.8, and the must for LBT. So appeared FASSTest.
Even on a market with zero request or interest for telemetry, a company must switch to transceiver style circuitry in order to implement LBT.

You forgot T-FHSS, which is a S-FHSS with a twist for telemetry, in order to calm down the voice of the masses requesting cheap telemetry without the costs of the 14/18 radios.
Is the best example of Futaba hypocrisy revealed in action, because they previously claimed that S-FHSS is not telemetry capable because the hardware limits this, even the hardware of S-FHSS is LBT capable and same hardware is used by Hitec, Frsky and Graupner, go figure...
One year later they issued T-FHSS which is same hardware, but different software !
And of course not interoperable, a top of the line 14/18 is not able to drive a T-FHSS receiver !!!


Quick Reply
Message:

Thread Tools