Futaba FASST?

[Geert]

Bonjour XFO,

I'm not sure I understand the first part of your message?
I understand you did some experiments with a jamming device and 100mW video transmitters to see if the Spectrum/Futaba radios can "survive" this kind of interference?

As to the number of available channels for auxiliary functions like controlling a camera:
The Armo has built-in capability to stabilize the camera pitch and roll, if you want to control the reference position you need 2 channels.
If you want to directly control additional functions for a camera or other payload (like zoom, light or whatever), you can hook them up directly to the receiver.

For the moment I use an R617FS receiver with a special adapter (7 channels), but I ordered the R6108SB serial bus receiver (Robbe says it should be available in the second half of March; according to my information Avio & Tiger in France will also have it).
This receiver looks exactly like the R6008HS (and costs the same), but it has a serial output (NOT the same as PPM). As soon as I have it, I will try to decode the serial protocol they use, and depending on this protocol, Hans may be able to support it directly like the Spectrum, otherwise an adapter may be needed).
The receiver supports up to 16 proportional + 2 switching channels, but the Armo only supports up to 12 channels.
For channels 1-8 there are still "normal" servo connections on the RX, if you want to use channels 9-18 you will need their S-bus servos (individually programmable, but probably 100 euro each ), or use one or more adapters for normal servos. They will sell a programmable adapter that decodes the s-bus protocol and accepts 4 normal servos. You can freely choose which channels these 4 servos use.

If I can decode the protocol, it should be fairly simple to make such an adapter myself.
In the ideal case (if the mysterious S-bus protocol allows it) it will be possible to connect the Armo directly to the S-Bus (without any adapter), and connect an adapter to the same S-bus to directly control servos or other stuff with all the remaining channels

Let's hope Futaba has not decided to encrypt their data to the servos...

A+,
geert

[Dukedolphin]

if we want to command a video/camera (start/stop, photo, zoom+/zoom-, rotation y, rotation 4D, light, and other, 12 channel are just enough)
we haven't enough output on the arm-o board

zoom is not very clever on fly pictures.
But anyway you can control 10 Channels nick,roll, yaw, throttle, gps-heigth,vrate,cam nick, aux 2-4.
If you need more you can build a small µC that reads the debugdata from RC11 and RC12 and generate a servo signal or what ever.
Best regards
Boris

[Geert]

Hello again,

I haven't had much time for the Kopter over the last few weeks, but I did get the Robbe/Futaba s-bus receiver.
Some experimenting yesterday revealed the following:

• In "normal" mode, the receiver sends a burst of data every 14 ms. I haven't tried High speed mode yet, but I assume that the data would be sent every 7 ms, just like their other receivers.
• A burst of data takes just under 3 ms, and contains 25 bytes at a baudrate of 100000 (not 115200).
• The format is 8N1, but it's inverted.
• The first byte is always the same (maybe an ID for the transmitter type).
• The next bytes contain servo position data only (no channel number), 11 bits per channel, LSB first.
• The data overlaps from one byte to the next (channel 1 uses the 2nd byte and the first 3 bits of byte 3, channel 2 uses the remaining 5 bits plus the first 6 bits of byte 4 and so on.)

I have only been able to test it with my own 10-channel transmitter so far; the data for channels 11 and up all show a value of 1. When I get back to Belgium I will try it with a friend's 12 and 14 channel transmitter.

So, there is no channel number transmitted, it's just 11 sequential bits per channel (sent in bytes, 8N1). I guess each servo knows from its "address" where its 11 bits are in the stream?

@Hans:
Will it be possible for the Armo to support this protocol (100 kbps, channel data not cleanly contained in separate bytes)? Or will an adapted be needed to convert it to the more standard 115200 bps and 2 bytes per channel?

edit: here is a screenshot that hopefully clarifies things a bit:

The 2 highlighted areas are channels 1 and 2 (bytes 2, 3 and 4 in view). You can see how channel data does not respect byte boundaries. Channel 1 has a decimal value of 523 here, and channel 2 is 1525.


brgds,
geert

[ufo-hans]

Will it be possible for the Armo to support this protocol (100 kbps, channel data not cleanly contained in separate bytes)? Or will an adapted be needed to convert it to the more standard 115200 bps and 2 bytes per channel?

the "8+3" bits per channel should not be a problem, as long as the single bytes are cleanly separated by start/stop bits. the inversion of the signal could be solved by inverting the signal electronically.

100kbps should be possible by tuning the baud-rate generation registers of the ARMs UART. i have not looked at the datasheet yet, how precise the wanted baudrate can be matched.

regards, hans.

[Geert]

the "8+3" bits per channel should not be a problem, as long as the single bytes are cleanly separated by start/stop bits. the inversion of the signal could be solved by inverting the signal electronically.

Electronic inversion is probably a good idea, that way the level can also be converted to ARM-friendly 3,3v.
The bytes are nicely separated, 1 start and 1 stop bit, no parity.
The only "strange" thing in the protocol is that there is nothing to separate one channel from the next, just have to count the bits.
Channel 1 = 8+3 bits
Channel 2 = 5+6 bits
Channel 3 = 2+8+1 bits
Channel 4 = 7+4 bits
...

I'll do some more tests tonight to see if a signal loss / failsafe activation is flagged.

geert

[sebseb7]

Hi,

The data format is: 1 start bit , 8 data bits , 1 parity bit, 2 stop bits , repeat.

in each burst are 24 bytes. the first byte is always: 11110000, the next 22 bytes contain 16 channels (11 bits each channel), 0 - 2048, 1024 is center.

the last byte contains 4 flags (and 4 other unknown flags): flag1: digital channel 1 , flag2: digital channel 2 , flag3: lost frame, flag4: failsafe active.

I successfully decoded this using pin change interrupts and a timer in an atmega. I didn't try the Uart, because I don't have one left.

/sebastian

[Geert]

Sebastian,

Thanks for the info.
I haven't had time the last few weeks to do more analyzing, so your explanation is greatly appreciated!

I will check again, but as reported in a previous post, I have 25 bytes in a burst, and from what I can see on the analyzer readout there is 1 start bit, 8 data bits, no parity, 1 stop bit. The signal is also inverted (a logic high means 0).
The first byte is always 15, then 22 bytes for 16 channels with 11-bit resolution (LSB first). I hadn't figured out the remaining bytes yet. It looks like the last byte is always 0.
I have never reachedvalues of 0 or 2047, but I haven't tried different settings in my transmitter yet.

In a few hours' time I'm meeting some very clever people, I will take the stuff with me, maybe they can have a look at it too.

As for the UART, it is my understanding that this is preferable for the Armo, because it is hardware-buffered.

brgds,
geert

[sebseb7]

I also see 15 as first byte. maybe I also have a 25th byte, but ignored it.

To reach 0 and 2047 I had to set the radio to the absolute maximum limits.

But what I find very strange is that you don't see a parity bit, which I have 100% for sure.

Can you send me the full data output the you see?

I decode it with an attiny4313 and convert it either to PPM or to a 57600bps serial protocol my quadrokopter can understand.
For just converting it to PPM a attiny24 would be sufficient.

/sebastian

[Geert]

You are right, there is an even parity bit. I didn't notice before because the analyzer software decodes the data just fine without parity bit.
There is definitely a 25th byte, but it is always 0 in my setup.

You are also right about the packet loss and failsafe flags.
The packet loss flag is obviously set as soon as a frame is lost, and the failsafe flag is set after exactly 1 second of continuous packet loss. While in the packet loss state (before failsafe activates), it keeps on sending out identical frames.
Recovery from failsafe is immediate: as soon as a valid frame arrives, the servo data is updated. I also confirmed this with a servo connected.

What transmitter do you use? Mine is a T10CG, I wonder if that first byte (15) could be an ID for the transmitter or receiver type...
How do you know that the 2 least significant bits in byte 24 are for channel 17 and 18? It seems logical, but I thought there were no 18-channel Futaba transmitters yet?

All in all, I think it looks promising, that packet loss bit could even be used as a real-time indication of radio link reliability, could be very intersting as a debug value for use in an OSD for example.

Hans may be able to implement the S-bus protocol directly in the Armo, otherwise a translation to the Spektrum protocol will be needed, at 115200 baud if I'm not mistaken...

geert

[sebseb7]

You are right, there is an even parity bit. I didn't notice before because the analyzer software decodes the data just fine without parity bit.
There is definitely a 25th byte, but it is always 0 in my setup.

most probably I have this byte too, I didn't check exactly.

What transmitter do you use? Mine is a T10CG, I wonder if that first byte (15) could be an ID for the transmitter or receiver type...

I have t8fg and the first byte is 15 as well. Maybe it has some meaning, like protocol version or something like that.

How do you know that the 2 least significant bits in byte 24 are for channel 17 and 18? It seems logical, but I thought there were no 18-channel Futaba transmitters yet?

In addition to the 8 proportional channels the t8fg has two additional digital channels, than can be either -100 or +100, when I assign switches to those two channels I can see those two bits switching. All newer radios (t12 & t14) have those two additional channels. (the 14ch receiver also has two additional digital channels). In those radios and on the receiver those channels are always called "DG1" and "DG2".

All in all, I think it looks promising, that packet loss bit could even be used as a real-time indication of radio link reliability, could be very interesting as a debug value for use in an OSD for example.

jup, I already use this flag to generate a voltage, that feeds into the RSSI input of my OSD. I begin with 5V, and as soon as packet drop begins I decrease this voltage. If the bit is set 90% of the time, the voltage would be 0.5V.

Hans may be able to implement the S-bus protocol directly in the Armo, otherwise a translation to the Spektrum protocol will be needed, at 115200 baud if I'm not mistaken...

Thats exactly my goal, but first I will do a sbus to ppm converter. I already designed a small PCB (that would even fit right into the receiver) with an atmega328p on it to do all this. Next thing will be spectrum (same pcb). Can you tell me where I can find precise information (other than source code) about the spectrum protocol?

/sebastian

[Geert]

I have t8fg and the first byte is 15 as well. Maybe it has some meaning, like protocol version or something like that.

Ok, so definitely not TX ID. Looks like it's of no immediate interest to us anyway...

In addition to the 8 proportional channels the t8fg has two additional digital channels, than can be either -100 or +100, when I assign switches to those two channels I can see those two bits switching.

Hmm, very interesting. My T10CG is a bit older than your T8, but more recent than the T12.
My T10 also has only 8 proportional channels, 9 and 10 can only be assigned to switches, but they do NOT affect the bits in byte 24.
They switch channels 9 and 10 between values of 144 and 1904; I have found no way to adjust the endpoints for these channels in the TX menu, so I can't use them for anything else than switching something on or off, but in the protocol they are treated as proportional channels anyway...
On the sticks, 100% throw corresponds to values from 364 to 1684, 1024 middle.
140% corresponds to 66-1982. I can't reach 0 or 2047 on mine.

Strange that there are these differences between similar transmitters...
A friend has a T12, as soon as I see him I will analyze what that one does.

Can you tell me where I can find precise information (other than source code) about the spectrum protocol?

There is a large comment section explaining the Spectrum protocol about halfway down this source code: http://svn.mikrokopter.de/filedetails.p ... Spectrum.c
And Hans posted this earlier in this thread:

the 11-bit protocol ist nearly identical...
CODE: SELECT ALL
// DX7 and DSM9 format:
// Bits: F 0  C3 C2 C1 C0  D9 D8 D7 D6 D5 D4 D3 D2 D1 D0
// DSM12 format:
// Bits: F C3 C2 C1 C0 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

So, the way I understand it (someone please correct me if it's wrong):

• 16-byte data frames every 11 ms, baudrate 115200.
• The frames alternate: frame 1 contains channels 1-7, frame 2 contains 8-12
• The first 2 bytes of each frame contain unknown information, then comes the channel data, 2 bytes per channel, MSB first:
  
  • First bit identifies frame 1 or 2
  • Next 4 bits are the channel number
  • 11 bits for servo position
• The last 4 bytes of the second frame are unused (11111111)

geert

[Pitlem]

Hallo Gert,

So, the way I understand it (someone please correct me if it's wrong):

* 16-byte data frames every 11 ms, baudrate 115200.
* The frames alternate: frame 1 contains channels 1-7, frame 2 contains 8-12
* The first 2 bytes of each frame contain unknown information, then comes the channel data, 2 bytes per channel, MSB first:
o First bit identifies frame 1 or 2
o Next 4 bits are the channel number
o 11 bits for servo position
* The last 4 bytes of the second frame are unused (11111111)

I think so too. Do you know the absolute values of servo position?

brgds,
Pit

[Geert]

Do you know the absolute values of servo position?

For the Spectrum? No, I don't, but I guess Hans could probably help you out there...

geert

[S3NS3]

Gibts eigentlich schon was neues zu FASST?!
Ich würd mir gern ne Futaba FF10 kaufen, primär für den Armo, alle 10 Kanäle zu nutzen wäre natürlich nett

Sorry, das ganze hier ist mir ne Stufe zu hoch daher hab ich es innerhalb ner Stunde nur "grob" überlesen

Mir wäre wegen den anderen Koptern eine PPM Lösung allerdings am liebsten!

[sebseb7]

also wenns jemanden was nützt: ich hab nen sbus->ppm konverter gebaut.

[el-dentiste]

also wenns jemanden was nützt: ich hab nen sbus->ppm konverter gebaut.

HI
Heisst das du kannst normale 35mhz empfänger (oder auch 2.4ghig) an der armo Platine betreiben ??
Was kostet der den ??

[sebseb7]

ne, dazu brauchst du den neuen Sbus Empfänger

[S3NS3]

Ja das hört sich sehr interessant an mit deinem SBUS->PPM Konverter
Wieviele Kanäle kann er denn und hast du es am Armo in betrieb? Passt alles?
Und: Könnte man den ggf käuflich bei dir erwerben?!

Ich bin noch dabei zu lesen und mich schlau zu machen. Das Thema ist ganz nett komplex, denkt man vorher garnicht...

Also der TTRecEnc soll schonmal bei 8 Servokanälen am standard FASST Empfänger funzen. Habe nur später irgendwo gelesen das der keinen Empfangsausfall erkennt?! Weis das jemand?
Ich möchte jedenfalls am Kameraarmo nicht sparen und auf jeden Fall einen Diversity Empfänger mit voller Reichweite nutzen.

Bei der FF10 wäre je nach Angebot der

R6008HS
Oder der
R6014HS

dabei. Beide ohne SBUS. Aber ggf über einen SS-Encoder nutzbar. 8 Kanäle wären ok.

Dann hat mich ein Fliegerkollege der Helisparte und FUTABA "experte" drauf aufmerksam gemacht das es jetzt auch echte Summensignalempfänger von FUTABA gibt. Gefunden habe ich diesen hier bisher:

R6107SP

Aber was ist nun RASST... Und ob das SS kompatibel ist so das es am Armo läuft? Oder auch am TT.... weil zum nahbereichsfunfliegen reicht der da. Muss ja nicht alle meine Kopter mit so einem teuren vollwertigen FASST Teil ausrüsten.

Was sagt ihr? Gibts noch mehr Infos?

Nebenbei: Neben der FF10 finde ich die FX30 auch sehr interessant, mal schlau lesen

[ufo-hans]

also wenns jemanden was nützt: ich hab nen sbus->ppm konverter gebaut.

geil wäre jetzt natürlich noch, wenn es auch sbus -> dsm9/12 als firmware-variante geben würde! sollte eigentlich nicht wirklich ein großes problem darstellen...

lg, hans.

[sebseb7]

also wenns jemanden was nützt: ich hab nen sbus->ppm konverter gebaut.

geil wäre jetzt natürlich noch, wenn es auch sbus -> dsm9/12 als firmware-variante geben würde! sollte eigentlich nicht wirklich ein großes problem darstellen...

lg, hans.

das wäre natürlich kein Problem, aber nicht mir meiner aktuellen Hardware. Für sowas bräuchte man einen 2. UART, der atmegax8 hat aber nur einen, man müsste dann nen 644p nehmen, der ist aber auch schonwieder etwas grösser. Man kann den Sbus im Prinzip auch mit nem Software-UART über irgendeinen PIN einlesen, aber das ist halt nicht ganz so zuverlässig.

[sebseb7]

Ja das hört sich sehr interessant an mit deinem SBUS->PPM Konverter

beliebig viele Kanäle, hängt halt davon ab wieviel PPM Kanäle die Gegenseite überhaupt erkennt.

Wieviele Kanäle kann er denn und hast du es am Armo in betrieb? Passt alles?

ich hab es mit 8 Kanälen am Mikrokopter im Betrieb (der MK erkennt nur 8 PPM Kanäle)

Und: Könnte man den ggf käuflich bei dir erwerben?!

ich mach demnächst mal ne Kleinserie, würde dann so 6 Euro das Stück kosten.

Also der TTRecEnc soll schonmal bei 8 Servokanälen am standard FASST Empfänger funzen. Habe nur später irgendwo gelesen das der keinen Empfangsausfall erkennt?! Weis das jemand?

Beim ttrecenc und auch bei allen anderen PWM->PPM Encodern die ich kenne, zittern die Kanäle bei mir leicht. d.h. wenn ich mir die Stickwerte ansehe die im Kopter ankommen dann wackeln die ganz schön obwohl ich die Sticks nicht in der Hand hab, mit meinem Encoder ist alles 100% stabil.

Ja klar failsafe kann der ttrecenc auch nicht, mein Encoder kann das , da im Sbus die failsafe info mitgegen wird, man könnte sogar die Emfangsqulität auf einen der PPM Kanäle legen. Quasi ne Art RSSI, ich kann auch an die HArdware ein PIN noch machen, das dann RSSI ausgibt.

Bei der FF10 wäre je nach Angebot der

schau dir lieber die T-8fg oder die T-12 an, die ff-10 hat ne deutlich ältere Firmware, bei den neueren (T8 und T12) sind die Menüs und die Möglichkeiten deutlich besser. die T8 hat auch 10 Kanäle, davon sind aber zwei Kanäle digital, also ein oder aus. Für Licht ausreichend.

Dann hat mich ein Fliegerkollege der Helisparte und FUTABA "experte" drauf aufmerksam gemacht das es jetzt auch echte Summensignalempfänger von FUTABA gibt. Gefunden habe ich diesen hier bisher:

die können nur 7 Kanäle und auch keine Failsafe-Werte für jeden Kanal.

Aber was ist nun RASST... Und ob das SS kompatibel ist so das es am Armo läuft? Oder auch am TT.... weil zum nahbereichsfunfliegen reicht der da. Muss ja nicht alle meine Kopter mit so einem teuren vollwertigen FASST Teil ausrüsten.

keine ahnung für was das steht, aber es ist kompatibel, aber wiegesagt eigentlich nicht optimal. auch kein diversity.

Nebenbei: Neben der FF10 finde ich die FX30 auch sehr interessant, mal schlau lesen

ja die FX-30 ist quasi ne T12 als Pultversion (man kann da an die Sticks noch kleine Schalter anbauen). die neue Fx-20 ist die Pultversion der T-8fg. die T-10 würde ich dringend abraten. (ich hatte mal eine, da kann man nicht mal den Schalter für den Lehrer-Schüler Modus frei auswählen, sondern der ist fest rechts oben, und eigentlich will man den ja links haben).

[S3NS3]

Für 6€ rum? Mehr als fair Da müsst ich auch nochmal schaun welche Empfänger SBUS haben. Glaube die mitgelieferten nicht?!
Wenn ich denn zuschlagen werde würde ich wohl auch ein paar deiner Konverter nehmen!
Failsafe bzw Empfangsausfallerkennung durch den Kopter ist auch ein absolutes MUSS, ohne geht garnicht - inakzeptabel

Wegen dem kleinen RASST SS Empfänger: Optimal in dem Sinne ist der nicht, ich weis. Aber für meine anderen Kopter die ich nur so im Nahbereich (max 50-60m) fliege würde das reichen.
Dafür schön klein und leicht und günstig. Failsafe der einzelnen Kanäle brauche ich garnicht, möcht ich auch nicht. Nur der Kopter sollte einen Empfangsausfall erkennen und sein Notprogramm starten.
Das müsste der ja können schätze ich. Einfach PPM weg, nicht das letzte weitersenden.

Bei den Funken bin ich jetzt ganz ratlos wieder.... mannomann.
Das die FF10 "veraltet" und die T8 trotz den günstigeren preises die erste wahl sein soll hatte ich auch schon gelesen gestern. Aber die sieht sowas von billig aus. Wie son Chinaspielzeugsender, also optisch gefallen mir die alle nicht sonderlich.
Das einzig optisch gute wäre das beleuchtete Display.
Vorallem mag ich eigentlich keine Handsender, würde also eh ins Pult kommen.
Und die FX20/30/40 sind auch son Ding....
FX40 ist ja für mich als Kopterflieger vollkommen übertrieben, auch der Preis, ne is klar
Die FX30 wäre was aber für das was die kann auch ganz nett teuer - UND - veraltet... die FX20 ist viel neuer bzw Topaktuell aber ne Nummer kleiner. Hat ja kaum Schalter. Sind da überhaupt mehrere Dreiwegschalter dran? Dazu kommt das angeblich die Stickmechanik wohl einfacher als bei der FX30 ausgefallen ist. Das wäre aber was das zählt. Hubi- und Flächenmischer brauch ich eher nicht in fülle.
Ich brauche viele Schalter, Dreiwegschalter, mehrere Potis, gute Sticks, 100% Empfangssicherheit und eine Reichweite von min. 1Km ohne jeglichen Ausfall (noch große Reserve). Und wenn ich schon Geld ausgebe auch ne Optik die mich anspricht

Nun weis ich wieder nicht weiter

[S3NS3]

Kleiner Nachtrag: T8FG mit R6108SB (SBUS) 380€.... hmmm da werd ich doch schwach bei dem Preis....

[S3NS3]

So bin auch schwach geworden....

Nun können wir auch zurrück zum Thema
Ich jetzt zumindest ob ich will oder nicht

Habe mir den RASST Summensignalempfänger zusätzlich mitbestellt - bin gespannt, werde berichten!

[Geert]

Hi sebseb7,

I'm very interested...

as wäre natürlich kein Problem, aber nicht mir meiner aktuellen Hardware. Für sowas bräuchte man einen 2. UART

Why? Can't you use the RXD to connect to the receiver and use the TXD from the same UART to send out the Spectrum protocol?

geert

ps. for those considering futaba: with a T-8 in combination with the R6108SB receiver you have actually 8+2 channels: 8 proportional and 2 digital. The T-10 also has only 8+2 channels, and costs much more...