×

Notice

The forum is in read only mode.
  1. Forum
  3. Development
  5. Protocol Development
  7. New FrSkyX protocol

New FrSkyX protocol

More
10 Mar 2017 13:10 #60087 by Wene001
Replied by Wene001 on topic New FrSkyX protocol
try to look here
www.deviationtx.com/forum/3-feedback-que...o-7e-blown-regulator
More
10 Mar 2017 16:42 #60095 by bampi2k
Replied by bampi2k on topic New FrSkyX protocol
I did something that I won't advise people to do!
I changed the hexfet with a random mosfet and it worked!
Well not exactly. I had an old PCB scavenged off the streets! I could trace that the circuit was using a ~1V - 5V logic to trigger other power electronic components.
Side-effect: The R(DS-ON) is definitely higher than the original IRLML6401. so the V-sense is off. But thats okay. I run a 2S lipo as power source.
Anyways, I shall order some of the IRLML6401 and replace. only worry MOQ is 10!

Now back to the actual topic:
With the new 3.3V Linear LDO in place, the module works perfect! Absolutely no twitching on Channel monitor. On Betaflight. its clean.

Thanks to all here for getting this sorted!
:woohoo: :woohoo: :woohoo: :woohoo: :woohoo:
More
11 Mar 2017 07:48 #60112 by sfersystem
Replied by sfersystem on topic New FrSkyX protocol
I've a question about the pigtail to sma cable, is it better to upgrade to a RG178 cable ?
High quality pigtail to sma
More
11 Mar 2017 08:55 #60117 by Fernandez
Replied by Fernandez on topic New FrSkyX protocol
myself I always use the rg178 teflon type coax. But I doubt it is very important, as the length is very short.
for RX antenna and longer coax could make difference.
More
13 Mar 2017 01:39 #60163 by petsmith
Replied by petsmith on topic New FrSkyX protocol
Is there any way to get Frsky XSR rssi value to be displayed on Betaflight OSD using Deviation? On Taranis, you can mix the rssi as a channel and send back to the receiver. Then, it can be used by Betaflight OSD. If it's not currently being supported by Deviation, maybe we add this feature.
More
13 Mar 2017 06:04 #60165 by sfersystem
Replied by sfersystem on topic New FrSkyX protocol

petsmith wrote: Is there any way to get Frsky XSR rssi value to be displayed on Betaflight OSD using Deviation? On Taranis, you can mix the rssi as a channel and send back to the receiver. Then, it can be used by Betaflight OSD. If it's not currently being supported by Deviation, maybe we add this feature.


I think i've tried some solutions, but nothing, it doesn't work for the moment with XSR.
More
13 Mar 2017 17:46 #60171 by hexfet
Replied by hexfet on topic New FrSkyX protocol
This has come up a couple times before. The "right" solution would be something like adding some telemetry items as inputs, along with a way to configure which items and possibly some scaling value. Maybe along with increasing the maximum number of channels to 16. Not something I can take on right now.

For short term a protocol option would be simple but frskyx already uses the max of 4 options.

Here's a one-liner you can add to put RSSI onto channel 12 (not the cleanest way to implement, but it's one line):
diff --git a/src/protocol/frskyx_cc2500.c b/src/protocol/frskyx_cc2500.c
index 5cfd12e..8aa8bf5 100644
--- a/src/protocol/frskyx_cc2500.c
+++ b/src/protocol/frskyx_cc2500.c
@@ -219,6 +219,8 @@ static u16 scaleForPXX(u8 chan, u8 failsafe)
     
     chan_val = chan_val * STICK_SCALE / CHAN_MAX_VALUE + 1024;
 
+    if (chan == 11 && !failsafe) chan_val = Telemetry.value[TELEM_FRSKY_RSSI];
+
     if (chan_val > 2046)   chan_val = 2046;
     else if (chan_val < 1) chan_val = 1;
More
14 Mar 2017 02:27 #60177 by petsmith
Replied by petsmith on topic New FrSkyX protocol

hexfet wrote: Here's a one-liner you can add to put RSSI onto channel 12 (not the cleanest way to implement, but it's one line):


Thanks! I'll take a look later and may try to implement something simple.
More
15 Mar 2017 03:37 #60203 by petsmith
Replied by petsmith on topic New FrSkyX protocol
With the help from Hexfet, I've added a new protocol option named RSSIChan (the max protocol options has now been increased to 5). It's off by default. When you set it to LastChan, it will use the last channel to transmit the RSSI value to the receiver. For example, if you define your model to have 12 channels, the last channel will be Channel 12. Under Betaflight/Cleanflight, you can goto the receiver tab and the last channel should display the corresponding RSSI value. The max will be around 2100 when your transmitter is next to the receiver. When you move the transmitter away, the value will decrease. The RSSI value will be useful when used with OSD. I've tested it with an XSR receiver and it's working fine. Some of the most popular devo binaries have been attached if anyone would like to test it.

Hexfet, here is the modification that I made. I don't know if you're willing to merge it. Feel free to do whatever you want.
diff --git a/src/config/model.h b/src/config/model.h
index a227ba7..3a75cde 100644
--- a/src/config/model.h
+++ b/src/config/model.h
@@ -21,7 +21,7 @@ const char *MODEL_TEMPLATE;
 #define UNKNOWN_ICON ("media/noicon" IMG_EXT)

 //This cannot be computed, and must be manually updated
-#define NUM_PROTO_OPTS 4
+#define NUM_PROTO_OPTS 5
 #define VIRT_NAME_LEN 10

 struct Model {
diff --git a/src/protocol/frskyx_cc2500.c b/src/protocol/frskyx_cc2500.c
index 5cfd12e..b02ae73 100644
--- a/src/protocol/frskyx_cc2500.c
+++ b/src/protocol/frskyx_cc2500.c
@@ -42,6 +42,7 @@ static const char * const frskyx_opts[] = {
   _tr_noop("AD2GAIN"),  "0", "2000", "655361", NULL,       // big step 10, little step 1
   _tr_noop("Freq-Fine"),  "-127", "127", NULL,
   _tr_noop("Format"),  "FCC", "EU", NULL,
+  _tr_noop("RSSIChan"),  "None", "LastChan", NULL,
   NULL
 };
 enum {
@@ -49,6 +50,7 @@ enum {
     PROTO_OPTS_AD2GAIN,
     PROTO_OPTS_FREQFINE,
     PROTO_OPTS_FORMAT,
+    PROTO_OPTS_RSSICHAN,
     LAST_PROTO_OPT,
 };
 ctassert(LAST_PROTO_OPT <= NUM_PROTO_OPTS, too_many_protocol_opts);
@@ -217,7 +219,10 @@ static u16 scaleForPXX(u8 chan, u8 failsafe)
     else
         chan_val = Channels[chan];

-    chan_val = chan_val * STICK_SCALE / CHAN_MAX_VALUE + 1024;
+    if (Model.proto_opts[PROTO_OPTS_RSSICHAN] && (chan == Model.num_channels - 1) && !failsafe)
+        chan_val = Telemetry.value[TELEM_FRSKY_RSSI] * 21;      // Max RSSI value seems to be 99, scale it to around 2000
+    else
+        chan_val = chan_val * STICK_SCALE / CHAN_MAX_VALUE + 1024;

     if (chan_val > 2046)   chan_val = 2046;
     else if (chan_val < 1) chan_val = 1;
Attachments:
More
15 Mar 2017 06:07 #60206 by sfersystem
Replied by sfersystem on topic New FrSkyX protocol
Oh thank you very much, will try with DEVO10 and come back soon.
More
15 Mar 2017 09:48 #60209 by FDR
Replied by FDR on topic New FrSkyX protocol
What I don't understand here, shouldn't it be a receiver feature?
In general I like the idea of using the telemetry values as inputs. But sending them back?!
More
15 Mar 2017 10:31 #60211 by petsmith
Replied by petsmith on topic New FrSkyX protocol

FDR wrote: What I don't understand here, shouldn't it be a receiver feature?
In general I like the idea of using the telemetry values as inputs. But sending them back?!


I totally agreed! This should have been a feature on the receiver. Unfortunately, the popular XSR & X4R-SB receivers can't send RSSI to the FC via a RC channel. Only the newest Frksy receivers XM & XM+ support this feature. Unless we rewrite the receiver firmware, there isn't much we can do on the receiver side. The OpenTX firmware also provide the ability to send back the RSSI telemetry value to the receiver via a dedicated RC channel. I'm just borrowing the idea and brought it to the devo, so that we can have the RSSI value available for the FC.
More
15 Mar 2017 11:10 - 15 Mar 2017 11:12 #60212 by FDR
Replied by FDR on topic New FrSkyX protocol
Actually I would be more happy if we could use the RSSI telemetry value to control the TX power, so that could be automatic...

EDIT: Of course the range still would be limited, and you would like to see that on your FPV screen...
Last edit: 15 Mar 2017 11:12 by FDR.
More
15 Mar 2017 11:33 #60213 by sfersystem
Replied by sfersystem on topic New FrSkyX protocol
Just awesome, Thanks a lot, works very well for me.
More
15 Mar 2017 12:21 #60214 by petsmith
Replied by petsmith on topic New FrSkyX protocol

sfersystem wrote: Just awesome, Thanks a lot, works very well for me.


Glad to hear it works well. Thanks for taking the time to test.
More
15 Mar 2017 15:17 #60219 by hexfet
Replied by hexfet on topic New FrSkyX protocol
The code looks fine and I encourage you to make a pull request. We'll see what everyone thinks about increasing the protocol option limit. I'll approve it :)
More
16 Mar 2017 07:07 #60235 by petsmith
Replied by petsmith on topic New FrSkyX protocol
PR done.
More
18 Mar 2017 18:44 #60340 by magic_marty
Replied by magic_marty on topic New FrSkyX protocol
Having a problem getting my 12s with 4n1 module to bind with a Frsky 802 rx has anybody got this rx working with deviation? I know my module is working cause i was able to bind to 2 other frsky receivers...Any help greatly appreciated ..
More
18 Mar 2017 19:04 #60344 by magic_marty
Replied by magic_marty on topic New FrSkyX protocol
Says bind in D8 mode is that the Frskyx on the tx or just the frsky protocol?
More
18 Mar 2017 19:05 - 18 Mar 2017 19:13 #60345 by aMax
Replied by aMax on topic New FrSkyX protocol
There is no Frsky 802...
Do you mean the DIY receiver FD802 or F802? They are different to handle.

Edit: Deviation " frsky" is D8. ..."frskyx" is D16.
Devo7e, TaranisQ X7, R9M , 4in1 MM, Futaba FC18plusV3.2 & DFT/FLD-02
Last edit: 18 Mar 2017 19:13 by aMax. Reason: added "no"
  1. Forum
  3. Development
  5. Protocol Development
  7. New FrSkyX protocol
Time to create page: 0.524 seconds
Powered by Kunena Forum
Force desktop display