Jeti DS-24
06-21-2018, 11:23 AM
#952
gives you :
1. security (overspeed)
2 . Cruise control
3. Constant Propspeed perfect for towing sorta same as the cruise control..
anway i am sure we can do all this , but does not have our first priority..
maybe if more people write kingtech they will do it..
anyway we do have looked into this , and its possible to make our own hall sensor in combination with the CTU.
and have all the goodies that come with one..
06-21-2018, 11:25 AM
#953
Last edited by causeitflies; 06-21-2018 at 11:27 AM. Reason: sandor beat me
06-25-2018, 06:44 AM
#959
I think this worth to share. A Brazilian friend turned off his 2.4 link while flying his jet. He wanted to have a sense of what would be like flying on 900 mhz. According to him not much differente other than fly the plane with more expo.
Flight video:
Log show video:
Flight video:
Log show video:
06-29-2018, 07:03 AM
#963
Just thought I'd mention a behavior I noticed recently. I have been using an MBAR in most of my jets and have it setup as a gear fali-safe, to automatically drop the landing gear if pressure goes below a certain level. This has always worked fine but I recently noticed that if I press the ""Clear" button on the display to reset my flight timer, it cause my landing gear to cycle up then down. Traced it back to the Clear button not simply clearing the timer but ALL telemetry input, and as a result the telemetry control fails. Played with various combinations and all reasonable settings of rht default state for the telemetry control when it loses telemetry but no joy. As a result I' eliminated the fail-safe in favor of a simply alarm on low gear pressure. For most this may not be a problem but since I have my timer start when I advance the throttle stick, I always press stop and clear to reset it before takeoff so it was causing issues for me. If someone has solved this problem I'd love to hear how...
06-29-2018, 08:07 AM
#964
With some good advice from the gang here on the thread I've been trying to work out a good method to migrate a few large jets from Futaba S-bus to Jeti, previously using Futaba 7003 receivers, Powerbox iGyro, and Emcotec/Robbe DPSI 2018 system. My goals were to retain the 2018 for battery redundancy and S-bus servo driving (it is very convenient for that, and has a great wiring/connector system), and to get the full benefit of all the Jeti RF link redundancy and telemetry.
The 2018 does support use of two Jeti EXbus receivers, so that is a good start. But the iGyro does not, so I am switching over to the Cortex Pro, which handles EXBus properly (e.g. serial in/out), and also supports setup/tuning with Device Explorer.
Thus, I am using two Jeti REX receivers, EXbus output. These feed the Cortex Pro. So the Cortex is handling the selection of the 2.4GHz receivers. The conundrum was how to properly incorporate the 900MHz backup link. I know from experience that the 2018 switches back and forth between the two RXs as the signal quality changes. From the logs, I see it going back and forth as the RX signal quality bounces around in the 90% range, perhaps switching 4-5 times during the flight. This is different from what the Jeti CBs do, where I understand that they "hang on" to the primary until it really gets bad, then switches to the backup. Makes perfect sense if the primary is 2.4 and the backup is 900. But putting the 2.4 link into RX1 and the 900 into RX2 on the 2018 does not seem like a good solution.
So I decided that a nice way to handle this is to incorporate a CB200 into the system between the Cortex Pro and the 2018.
So then the setup is: Two REX RXs plugged into the Cortex Pro. Cortex EXbus out to the RX1 port on the CB200, and the 900MHz receiver outputting EXBus to the RX2 port on the CB200. Then, I set Ext2 and Ext3 on the CB200 to EXBus out ... these ports feed RX1 and RX2 on the 2018 receiver inputs. I am handling failsafe in the CB200, so it's off in the RXs and off in the 2018.
With all the new firmware updates, and hooked up as noted above in this thread by Sandor, I "see" the REX receivers, the CB200 and the Cortex Pro on device explore. My Xicoy Flight computer, set to Jeti mode for its telemetry output, goes into the Ext1 port of the CB200 and provides all the turbine parameters, pitot-static airspeed, g-forces etc. I noted with some surprise that the 2018 was also supplying its telemetry via the EXbus even before I plugged in the "Jeti telemetry dongle" that Emcotec supplies (which plugs into one of the Spek satellite connectors).
So far things are working very well. And, as a bonus, I can now use all 24 channels since I can assign pins on the CB200 to channels not originally usable in a 2018-only solution.
I would welcome any comments from those much more knowledgeable, in terms of any traps or "gotchas" or any thoughts on the reliability of the approach or how to improve it.
One potential weak point I've noted is that I only have one wire from the Cortex EXBus output to the CB200 RX1 .. since the CB200 RX2 is fed by the 900MHz backup. And of course the Cortex pin 4 to a servo output on the CB200 I presume to back up on power only.
Dave
The 2018 does support use of two Jeti EXbus receivers, so that is a good start. But the iGyro does not, so I am switching over to the Cortex Pro, which handles EXBus properly (e.g. serial in/out), and also supports setup/tuning with Device Explorer.
Thus, I am using two Jeti REX receivers, EXbus output. These feed the Cortex Pro. So the Cortex is handling the selection of the 2.4GHz receivers. The conundrum was how to properly incorporate the 900MHz backup link. I know from experience that the 2018 switches back and forth between the two RXs as the signal quality changes. From the logs, I see it going back and forth as the RX signal quality bounces around in the 90% range, perhaps switching 4-5 times during the flight. This is different from what the Jeti CBs do, where I understand that they "hang on" to the primary until it really gets bad, then switches to the backup. Makes perfect sense if the primary is 2.4 and the backup is 900. But putting the 2.4 link into RX1 and the 900 into RX2 on the 2018 does not seem like a good solution.
So I decided that a nice way to handle this is to incorporate a CB200 into the system between the Cortex Pro and the 2018.
So then the setup is: Two REX RXs plugged into the Cortex Pro. Cortex EXbus out to the RX1 port on the CB200, and the 900MHz receiver outputting EXBus to the RX2 port on the CB200. Then, I set Ext2 and Ext3 on the CB200 to EXBus out ... these ports feed RX1 and RX2 on the 2018 receiver inputs. I am handling failsafe in the CB200, so it's off in the RXs and off in the 2018.
With all the new firmware updates, and hooked up as noted above in this thread by Sandor, I "see" the REX receivers, the CB200 and the Cortex Pro on device explore. My Xicoy Flight computer, set to Jeti mode for its telemetry output, goes into the Ext1 port of the CB200 and provides all the turbine parameters, pitot-static airspeed, g-forces etc. I noted with some surprise that the 2018 was also supplying its telemetry via the EXbus even before I plugged in the "Jeti telemetry dongle" that Emcotec supplies (which plugs into one of the Spek satellite connectors).
So far things are working very well. And, as a bonus, I can now use all 24 channels since I can assign pins on the CB200 to channels not originally usable in a 2018-only solution.
I would welcome any comments from those much more knowledgeable, in terms of any traps or "gotchas" or any thoughts on the reliability of the approach or how to improve it.
One potential weak point I've noted is that I only have one wire from the Cortex EXBus output to the CB200 RX1 .. since the CB200 RX2 is fed by the 900MHz backup. And of course the Cortex pin 4 to a servo output on the CB200 I presume to back up on power only.
Dave
06-29-2018, 10:14 AM
#965
Join Date: Dec 2011
Location: Geneva, IL
Posts: 14
Likes: 0
Received 0 Likes
on
0 Posts
Just thought I'd mention a behavior I noticed recently. I have been using an MBAR in most of my jets and have it setup as a gear fali-safe, to automatically drop the landing gear if pressure goes below a certain level. This has always worked fine but I recently noticed that if I press the ""Clear" button on the display to reset my flight timer, it cause my landing gear to cycle up then down. Traced it back to the Clear button not simply clearing the timer but ALL telemetry input, and as a result the telemetry control fails. Played with various combinations and all reasonable settings of rht default state for the telemetry control when it loses telemetry but no joy. As a result I' eliminated the fail-safe in favor of a simply alarm on low gear pressure. For most this may not be a problem but since I have my timer start when I advance the throttle stick, I always press stop and clear to reset it before takeoff so it was causing issues for me. If someone has solved this problem I'd love to hear how...
06-29-2018, 10:34 AM
#966
My Feedback: (3)
Just thought I'd mention a behavior I noticed recently. I have been using an MBAR in most of my jets and have it setup as a gear fali-safe, to automatically drop the landing gear if pressure goes below a certain level. This has always worked fine but I recently noticed that if I press the ""Clear" button on the display to reset my flight timer, it cause my landing gear to cycle up then down. Traced it back to the Clear button not simply clearing the timer but ALL telemetry input, and as a result the telemetry control fails. Played with various combinations and all reasonable settings of rht default state for the telemetry control when it loses telemetry but no joy. As a result I' eliminated the fail-safe in favor of a simply alarm on low gear pressure. For most this may not be a problem but since I have my timer start when I advance the throttle stick, I always press stop and clear to reset it before takeoff so it was causing issues for me. If someone has solved this problem I'd love to hear how...
06-29-2018, 11:29 AM
#967
With some good advice from the gang here on the thread I've been trying to work out a good method to migrate a few large jets from Futaba S-bus to Jeti, previously using Futaba 7003 receivers, Powerbox iGyro, and Emcotec/Robbe DPSI 2018 system. My goals were to retain the 2018 for battery redundancy and S-bus servo driving (it is very convenient for that, and has a great wiring/connector system), and to get the full benefit of all the Jeti RF link redundancy and telemetry.
The 2018 does support use of two Jeti EXbus receivers, so that is a good start. But the iGyro does not, so I am switching over to the Cortex Pro, which handles EXBus properly (e.g. serial in/out), and also supports setup/tuning with Device Explorer.
Thus, I am using two Jeti REX receivers, EXbus output. These feed the Cortex Pro. So the Cortex is handling the selection of the 2.4GHz receivers. The conundrum was how to properly incorporate the 900MHz backup link. I know from experience that the 2018 switches back and forth between the two RXs as the signal quality changes. From the logs, I see it going back and forth as the RX signal quality bounces around in the 90% range, perhaps switching 4-5 times during the flight. This is different from what the Jeti CBs do, where I understand that they "hang on" to the primary until it really gets bad, then switches to the backup. Makes perfect sense if the primary is 2.4 and the backup is 900. But putting the 2.4 link into RX1 and the 900 into RX2 on the 2018 does not seem like a good solution.
So I decided that a nice way to handle this is to incorporate a CB200 into the system between the Cortex Pro and the 2018.
So then the setup is: Two REX RXs plugged into the Cortex Pro. Cortex EXbus out to the RX1 port on the CB200, and the 900MHz receiver outputting EXBus to the RX2 port on the CB200. Then, I set Ext2 and Ext3 on the CB200 to EXBus out ... these ports feed RX1 and RX2 on the 2018 receiver inputs. I am handling failsafe in the CB200, so it's off in the RXs and off in the 2018.
With all the new firmware updates, and hooked up as noted above in this thread by Sandor, I "see" the REX receivers, the CB200 and the Cortex Pro on device explore. My Xicoy Flight computer, set to Jeti mode for its telemetry output, goes into the Ext1 port of the CB200 and provides all the turbine parameters, pitot-static airspeed, g-forces etc. I noted with some surprise that the 2018 was also supplying its telemetry via the EXbus even before I plugged in the "Jeti telemetry dongle" that Emcotec supplies (which plugs into one of the Spek satellite connectors).
So far things are working very well. And, as a bonus, I can now use all 24 channels since I can assign pins on the CB200 to channels not originally usable in a 2018-only solution.
I would welcome any comments from those much more knowledgeable, in terms of any traps or "gotchas" or any thoughts on the reliability of the approach or how to improve it.
One potential weak point I've noted is that I only have one wire from the Cortex EXBus output to the CB200 RX1 .. since the CB200 RX2 is fed by the 900MHz backup. And of course the Cortex pin 4 to a servo output on the CB200 I presume to back up on power only.
Dave
The 2018 does support use of two Jeti EXbus receivers, so that is a good start. But the iGyro does not, so I am switching over to the Cortex Pro, which handles EXBus properly (e.g. serial in/out), and also supports setup/tuning with Device Explorer.
Thus, I am using two Jeti REX receivers, EXbus output. These feed the Cortex Pro. So the Cortex is handling the selection of the 2.4GHz receivers. The conundrum was how to properly incorporate the 900MHz backup link. I know from experience that the 2018 switches back and forth between the two RXs as the signal quality changes. From the logs, I see it going back and forth as the RX signal quality bounces around in the 90% range, perhaps switching 4-5 times during the flight. This is different from what the Jeti CBs do, where I understand that they "hang on" to the primary until it really gets bad, then switches to the backup. Makes perfect sense if the primary is 2.4 and the backup is 900. But putting the 2.4 link into RX1 and the 900 into RX2 on the 2018 does not seem like a good solution.
So I decided that a nice way to handle this is to incorporate a CB200 into the system between the Cortex Pro and the 2018.
So then the setup is: Two REX RXs plugged into the Cortex Pro. Cortex EXbus out to the RX1 port on the CB200, and the 900MHz receiver outputting EXBus to the RX2 port on the CB200. Then, I set Ext2 and Ext3 on the CB200 to EXBus out ... these ports feed RX1 and RX2 on the 2018 receiver inputs. I am handling failsafe in the CB200, so it's off in the RXs and off in the 2018.
With all the new firmware updates, and hooked up as noted above in this thread by Sandor, I "see" the REX receivers, the CB200 and the Cortex Pro on device explore. My Xicoy Flight computer, set to Jeti mode for its telemetry output, goes into the Ext1 port of the CB200 and provides all the turbine parameters, pitot-static airspeed, g-forces etc. I noted with some surprise that the 2018 was also supplying its telemetry via the EXbus even before I plugged in the "Jeti telemetry dongle" that Emcotec supplies (which plugs into one of the Spek satellite connectors).
So far things are working very well. And, as a bonus, I can now use all 24 channels since I can assign pins on the CB200 to channels not originally usable in a 2018-only solution.
I would welcome any comments from those much more knowledgeable, in terms of any traps or "gotchas" or any thoughts on the reliability of the approach or how to improve it.
One potential weak point I've noted is that I only have one wire from the Cortex EXBus output to the CB200 RX1 .. since the CB200 RX2 is fed by the 900MHz backup. And of course the Cortex pin 4 to a servo output on the CB200 I presume to back up on power only.
Dave
06-29-2018, 12:03 PM
#968
Thanks, those are fair criticisms of the approach. I started with exactly the approach you suggested but, apparently, the current RXs don't have the ability to take a PPM-connected satellite and "compute" an EXbus output. It may be the case that the assist RXs can do that now (I recall a post from ZB along those lines) and I understand that there may be a firmware update coming that will allow all the REX family to do that. But I hooked it up that way and it does not work unless you make the system all PPM which does not help me at all.
If this is wrong, I would love to know...
I realize that wanting to keep SBus and therefore the 2018 is driving some complexity into the solution.
I thought about replacing the 2018 with a CB400, then making a "bootleg" SBus setup with some Slinky's or CB100s as in the Esprit video ... to get the "one plug" sbus experience on the wings. Perhaps that will end up being a better approach.
Oh, and I'd love to see a fix for your "CLR"/gear issue too!!
Dave
If this is wrong, I would love to know...
I realize that wanting to keep SBus and therefore the 2018 is driving some complexity into the solution.
I thought about replacing the 2018 with a CB400, then making a "bootleg" SBus setup with some Slinky's or CB100s as in the Esprit video ... to get the "one plug" sbus experience on the wings. Perhaps that will end up being a better approach.
Oh, and I'd love to see a fix for your "CLR"/gear issue too!!
Dave
06-29-2018, 06:13 PM
#971
My Feedback: (1)
Join Date: Nov 2003
Location: Caracas, VENEZUELA
Posts: 551
Likes: 0
Received 0 Likes
on
0 Posts
Just thought I'd mention a behavior I noticed recently. I have been using an MBAR in most of my jets and have it setup as a gear fali-safe, to automatically drop the landing gear if pressure goes below a certain level. This has always worked fine but I recently noticed that if I press the ""Clear" button on the display to reset my flight timer, it cause my landing gear to cycle up then down. Traced it back to the Clear button not simply clearing the timer but ALL telemetry input, and as a result the telemetry control fails. Played with various combinations and all reasonable settings of rht default state for the telemetry control when it loses telemetry but no joy. As a result I' eliminated the fail-safe in favor of a simply alarm on low gear pressure. For most this may not be a problem but since I have my timer start when I advance the throttle stick, I always press stop and clear to reset it before takeoff so it was causing issues for me. If someone has solved this problem I'd love to hear how...
As far as I know, there is no way to avoid the "clear" command from momentaneously interrupting all telemetry input. Nonetheless there are a couple of ways to avoid that issue affecting your normal gear operation.
Method 1:
a) Gear is operated by a Logical switch (say L1 ). Gear is Down when L1 is in 'X", and Up when it's in "V".
b) Assign switch SB as your gear switch: "X" if gear is down, and "V" if gear is up.
c) Define a telemetry control (say Mx1): closed ( "V" ) when air pressure is > than your failsafe pressure.
d) Define L1 as: SE AND Mx1
e) L1 is in the "gear up" position ("V") when: SB is "V", AND, Mx1 is "V". In other words, gear is up if the switch is SE is Up "and" the pressure is greater than 60#. Otherwise L1 will be "X" ( gear down).
With this configuration, the "clear" command will only cycle the gear if you "clear" while the gear is in the retracted position and the air pressure is above the failsafe press.
Method 2:
a) similar
b) similar
c) Make Mx1: closed when air pressure is "< " than failsafe pressure (instead of >)
d) similar
e) "Reverse" Mx1 in L1 edit menu. So, gear is Up if switch SE is in the Up position, and the air pressure is "not" less than the failsafe pressure.
With this method, the "clear" command will only cycle if you "clear" while the switch gear is in the Up position and the pressure is below the failsafe pressure (very unlikely situation).
Jack
06-29-2018, 06:29 PM
#972
Join Date: Dec 2011
Location: Geneva, IL
Posts: 14
Likes: 0
Received 0 Likes
on
0 Posts
Just thought I'd mention a behavior I noticed recently. I have been using an MBAR in most of my jets and have it setup as a gear fali-safe, to automatically drop the landing gear if pressure goes below a certain level. This has always worked fine but I recently noticed that if I press the ""Clear" button on the display to reset my flight timer, it cause my landing gear to cycle up then down. Traced it back to the Clear button not simply clearing the timer but ALL telemetry input, and as a result the telemetry control fails. Played with various combinations and all reasonable settings of rht default state for the telemetry control when it loses telemetry but no joy. As a result I' eliminated the fail-safe in favor of a simply alarm on low gear pressure. For most this may not be a problem but since I have my timer start when I advance the throttle stick, I always press stop and clear to reset it before takeoff so it was causing issues for me. If someone has solved this problem I'd love to hear how...
06-29-2018, 06:31 PM
#973
(1) Output (pin 6) from the Cortex Pro to the 2018
REX 900 to the second input of the 2018
All EX Bus
06-29-2018, 06:37 PM
#974
Thanks, those are fair criticisms of the approach. I started with exactly the approach you suggested but, apparently, the current RXs don't have the ability to take a PPM-connected satellite and "compute" an EXbus output. It may be the case that the assist RXs can do that now (I recall a post from ZB along those lines) and I understand that there may be a firmware update coming that will allow all the REX family to do that. But I hooked it up that way and it does not work unless you make the system all PPM which does not help me at all.
If this is wrong, I would love to know...
I realize that wanting to keep SBus and therefore the 2018 is driving some complexity into the solution.
I thought about replacing the 2018 with a CB400, then making a "bootleg" SBus setup with some Slinky's or CB100s as in the Esprit video ... to get the "one plug" sbus experience on the wings. Perhaps that will end up being a better approach.
Oh, and I'd love to see a fix for your "CLR"/gear issue too!!
Dave
If this is wrong, I would love to know...
I realize that wanting to keep SBus and therefore the 2018 is driving some complexity into the solution.
I thought about replacing the 2018 with a CB400, then making a "bootleg" SBus setup with some Slinky's or CB100s as in the Esprit video ... to get the "one plug" sbus experience on the wings. Perhaps that will end up being a better approach.
Oh, and I'd love to see a fix for your "CLR"/gear issue too!!
Dave
I'm not sure if the Regular non REX receivers work correctly in this regard or not and I don't have any central boxes anymore to test against but I wouldn't be surprised if they don't carry serial PPM through to EX Bus either.
You could simply replace one of the REX receivers with a REX Assist with stabilization turned off. You could also skip the Cortex Pro (don't hate me Danny) and use a Rex Assist with a PPM connected R900 and connect it to the 2018 via Ex Bus.. Then if you really wanted a secondary 2.4Ghz receiver, simply connect it directly to the 2018. The secondary 2.4Hhz won't be stabilized but it the Assist dies or becomes disconnected for some reason it may save the airplane. Just some thoughts.
06-29-2018, 06:46 PM
#975
Would that really be a good solution ? Since I believe the 2018 looks at the secondary receiver on a nearly frame by frame basis and since the R900 isn't even really active (updates about 1/10 rate) until the transmitter detect the 2.4Ghz link has failed, any time the 2.4Ghz drops a frame it may use very out of date data from the R900, possibly resulting in glitchy controls if the frame is dropped during rapid servo movements. Not sure what the likelihood of this happening is but I think Jeti specifically makes use of it's receivers in a way that favors the "hot standby" style 900Mhz receiver which isn't really active until the 2.4Ghz link fails which matches up very nicely to the way Jeti uses Rx2 of the central box..