Thread Tools
Jul 10, 2019, 01:54 AM
Registered User
myflydream's Avatar
Quote:
Originally Posted by slowjett
Nice to see an update! Now, how about adding RSSI to the sbus/ppm stream??
That's exactly what we want to implement.
But we haven't decided which channel we should assign with RSSI.
Any suggestions, or any standard there?
Sign up now
to remove ads between posts
Jul 10, 2019, 02:01 AM
Registered User
myflydream's Avatar
Quote:
Originally Posted by Daemon
Great, but how do you perform a firmware update on new gen Rxs?
On the old ones you'd plug in the USB while holding down the button, and it'd
show a new drive letter with nothing on it. Drop the .bin file onto that drive, and it
performed the update. With the new gen Rx, it always just shows the same drive containing
the the rx.txt config file, whether you hold the button down or not. Copying the
.bin file there has no effect. There's never been an Rx firmware update since
MFD released the new gen Rxs so this is the first time it's mattered.
As you said, the new gen RX always shows only one USB driver , ignoring you press the button or not. This is an improvement.
Because config file and FW update share the same Driver now.
Just copy the RX.bin to the driver (I know there is a rx.txt there. it is fine). Use the Windows "safe remove hardware" to unplug the USB device (RX). Otherwise, the FW may get lost.
Then unplug the USB cable, apply 5V to the RX. wait for 3 seconds the FW will be updated, and Enjoy it.
Jul 10, 2019, 03:27 AM
Registered User
Daemon's Avatar
Ok that works.
It appears that SBUS is now outputting full range, but the positions and range doesn't match what the transmitter is actually sending to the Tx module.
Taranis sends 1500uS for center position, Rx now outputs 1520uS.
Taranis sends 1000uS, Rx outputs 911uS.
Taranis sends 2000uS, Rx outputs 2128uS.
Besides the offset center point, that's ~608uS from center to each endpoint, which isn't right.

If I switch the Rx to output CPPM, then inputs match outputs precisely at 1000-1500-2000uS,
which means there must be some sort of conversion or scaling factor on the S.BUS output.
It occurs to me that Futaba's original (started 20 years ago) center point was 1520uS, but literally
no other SBUS capable Rxs use that today. It's just too confusing when all flight controllers are
expecting 1000-1500-2000.
Jul 10, 2019, 03:38 AM
Flying Zayin
Cathay Stray's Avatar

Right out of the oven


... @Daemon - try it on your Taranis. Should work with it, but how it will work with other radios remains to be seen.
So the previous version still remains an option.
Jul 10, 2019, 12:59 PM
Registered User
Daemon's Avatar
That's better. SBUS outputs appear to match CPPM outputs.

BTW, the way Futaba worked was never due to scaling on the Rx side.
Futaba transmitters themselves have their center point at 1520uS and the Rx just outputs
whatever the transmitter is sending. The Rx should always match SBUS output
to CPPM input values. 1500uS is a literal PWM pulse width measurement.

Now if someone at MyFlyDream wants to get really ambitious they can figure
out how to make the otherwise useless serial input port on the Tx accept SBUS input
(it's just inverted serial prototol anyway) which any OpenTx transmitter can
output now, and we'd have digital packets end to end and significantly lower
end to end latency when using > 8 channels.
Jul 11, 2019, 03:49 AM
Registered User
myflydream's Avatar
Quote:
Originally Posted by Daemon
That's better. SBUS outputs appear to match CPPM outputs.

BTW, the way Futaba worked was never due to scaling on the Rx side.
Futaba transmitters themselves have their center point at 1520uS and the Rx just outputs
whatever the transmitter is sending. The Rx should always match SBUS output
to CPPM input values. 1500uS is a literal PWM pulse width measurement.

Now if someone at MyFlyDream wants to get really ambitious they can figure
out how to make the otherwise useless serial input port on the Tx accept SBUS input
(it's just inverted serial prototol anyway) which any OpenTx transmitter can
output now, and we'd have digital packets end to end and significantly lower
end to end latency when using > 8 channels.
Something similar already implemented.
Now this SBUS-EXT board is a standard component of MFDLink package.
It accepts S-Bus input and encodes/sends data to the 3-pin EXT port of MFDLink-TX.
It also can decode your sbus signal into 16 channels PWM signal
Jul 11, 2019, 09:16 AM
-NEFPV-
Quote:
Originally Posted by myflydream
That's exactly what we want to implement.
But we haven't decided which channel we should assign with RSSI.
Any suggestions, or any standard there?
I usually assign it to ch8. But perhaps an option in the TXT file? I'm really excited to see some interest in product development here!!
Jul 11, 2019, 11:11 AM
Registered User
Daemon's Avatar
Quote:
Originally Posted by myflydream
Something similar already implemented.
Now this SBUS-EXT board is a standard component of MFDLink package.
It accepts S-Bus input and encodes/sends data to the 3-pin EXT port of MFDLink-TX.
It also can decode your sbus signal into 16 channels PWM signal
That's cool. How do I buy one? I don't see it listed on your website.


As for RSSI on a channel, I'd also suggest making it configurable via the rx.txt file with
the option to not have it assigned.
I don't want it eating a 1-8 channel unless I tell it to. Sometimes I need all 8.
Jul 12, 2019, 10:49 AM
Registered User
Quote:
Originally Posted by Daemon

As for RSSI on a channel, I'd also suggest making it configurable via the rx.txt file with
the option to not have it assigned.
I don't want it eating a 1-8 channel unless I tell it to. Sometimes I need all 8.

This solution is universal - looks to be good for everyone.
Jul 12, 2019, 11:10 AM
Registered User
Quote:
Originally Posted by myflydream
Something similar already implemented.
Now this SBUS-EXT board is a standard component of MFDLink package.

It accepts S-Bus input and encodes/sends data to the 3-pin EXT port of MFDLink-TX.

Connecting 16ch s.bus output to TX this way will allow sending how many channels?
Jul 12, 2019, 11:24 AM
Registered User
Daemon's Avatar
Should allow sending 16 channels. SBUS protocol natively supports exactly 16 proportional
11bit (2048 steps) channels in every packet, plus 2 non-proportional 1 bit (although many
implementations don't handle the latter), plus 1 bit for failsafe and 1 bit for "frame lost".
Most implementations only populate and use the 16 bit proportional + failsafe bit.

At its native speed (100Kbs 8E2), it takes only 3ms to transmit an SBUS packet containing
all 16 channels + 4 bits, versus the roughly 45ms to do the same with CPPM,
so there's potentially a huge performance advantage. Taranis's minimum frame length
for for SBUS output is only 6ms (defaults to 7ms) so still way better than PPM.
I don't know how fast this converter is, or how fast RLink/MFDLink Tx will accept
and transmit packets. Hopefully it can keep up.

mfd, how can we buy the SBUS-EXT board?
Last edited by Daemon; Jul 12, 2019 at 11:41 AM.
Jul 12, 2019, 06:34 PM
Registered User
I tried following the steps in the Rlink manual to update the firmware:
1. Hold button while plugging in USB
2. Copy new firmware .bin file to Rx
3. Unplug from USB, replug it back in.

Nothing happens. Am I doing something wrong?

EDIT: I needed to rename the file RX(3).bin to RX.bin, and apply power over 5V (not USB). Now it provides a range of 960-2075us!
Last edited by Zangetsu57; Jul 12, 2019 at 06:41 PM.
Jul 13, 2019, 12:52 AM
iNav Fanatic
Quote:
Originally Posted by slowjett
I usually assign it to ch8. But perhaps an option in the TXT file? I'm really excited to see some interest in product development here!!
I'd prefer this as well. It would be worth moving the max channels to 12 or 16 to accommodate. I would not use it on ch 1-8. Maybe default to CH16? This would probably allow you to configure ch16 as RSSI on your FC w/o having to use or configure for more than the standard 8 since it's just RX side.

-Shawn
Jul 14, 2019, 10:41 PM
-NEFPV-
Quote:
Originally Posted by Daemon
As for RSSI on a channel, I'd also suggest making it configurable via the rx.txt file with
the option to not have it assigned.
I don't want it eating a 1-8 channel unless I tell it to. Sometimes I need all 8.
It should be entirely possible for RSSI to be injected into a channel that is still used. Thats how iNAV/Betaflght works. You can have RSSI injected into any channel but still have full use of the channel for RC.
Jul 14, 2019, 10:57 PM
Registered User
Daemon's Avatar
I don't see any way that's possible. iNav documentation says to use a spare channel and
they give ch9 as an example.


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Sold 433MHz LRS MFDLink (RLink) TX/RX diversity Aries321 Aircraft - General - Radio Equipment (FS/W) 1 Feb 04, 2016 07:36 PM
Sold MyFlyDream MFDLink 433Mhz LRS (RLink) Aries321 FPV Equipment (FS/W) 0 Dec 18, 2015 09:31 PM
Sold Rlink 16 channel UHF LRS with diversity newbielife5 FPV Equipment (FS/W) 1 Oct 05, 2015 09:09 AM
Sold Rlink 16 channel LRS with diversity newbielife5 Aircraft - General - Radio Equipment (FS/W) 0 Oct 04, 2015 04:48 PM