Drogue Chute controller for Jeti radios
06-29-2019, 06:23 AM
#1
Drogue Chute controller for Jeti radios
Hi Jeti users and Parachute Fans,
Since meeting earlier in the season at First in Flight, Gary (viper1gj) and I have been collaborating on a drogue chute controller for Jeti radios. Gary is building an F-105 where a parachute is important for the maximum scale effect on landings.
We were discussing what to do since Dan Gill's Details for Scale Autochute, generally seen as the "Cadillac" solution for this problem, is no longer available. Gary thought that it should be possible to emulate most of the relevant functions with logic controls on the Jeti and I think he's right, but it struck me as something that would be a bit complicated to do, and especially hard to understand and maintain.
I've done a lot of work with lua scripts on the DS-24 and I find it to be a really well-designed and well-engineered programming environment. In fact Gary and I first got connected here on RCU when he asked about my speed announce lua script that announces speed more or less frequently based on how much the speed of the aircraft is changing. I've also done a fuel announcer that computes time to "bingo fuel", and a live GPS display that puts the google maps image of the field on the display and overlays in real time the aircraft position. I have also experimented with an autothrottle to maintain airspeed by measuring the pitot speed and controlling the throttle (which works surprisingly well).
So it seemed logical to me to try a lua script for the parachute control problem.
I now have a first cut at the lua chute controller done that Gary and I have been iterating and refining. It looks at throttle, flaps, brakes and landing gear channel state .. and also counts pulses from a hall sensor (we got ours from AeroPanda) to measure wheel rotation. There is an arming switch you can assign and then when all the channel conditions are satisfied, it will deploy the chute.
The lua program works by creating three "virtual channels" C01, C02 and C02. C01 is for an optional parachute door release, C02 is for the chute deploy mechanism (e.g. an air cylinder to push the parachute out) and C03 is the control to jettison the chute from the aircraft. The lua program controls these three channels, and you use the function and servo assignment screens in the TX in the usual way to connect these channels to servos. It also has a sub-menu for ground use to load and test the deployment. There is a simple sequencer built in to allow a delay from door opening (or door lock release) to chute deployment.
We are still working on the hall sensor implementation, and interested in getting some more insight into how best to implement that. Should it count pulses, thereby measuring the ground run (e.g. 20 feet? 50 feet?) .. should it measure speed (e.g. don't deploy till below 60 mph .. should it do a WOW (weight on wheels) measurement requiring WOW be continuous for 2 seconds? 5 seconds? .. you get the idea .. we could implement each of these and have the user select a preference. All measurements are from the same sort of hall sensor and magnet... the Hall sensor just plugs into an RX channel that is set to be an input and then acts like a telemetry sensor (standard Jeti setup).
We are interested to see if anyone else out there wants to collaborate on the project, and especially would like insight from folks who have a lot of experience using braking parachutes. We are happy to supply anyone the current version of the program to play with and are happy to take comments, suggestions and advice.
As a former fan of Dan and D4S .. should the company come back I'd personally love to mod the lua program to work with their hardware and adapt their excellent autochute system to the Jeti radio.
Dave
Since meeting earlier in the season at First in Flight, Gary (viper1gj) and I have been collaborating on a drogue chute controller for Jeti radios. Gary is building an F-105 where a parachute is important for the maximum scale effect on landings.
We were discussing what to do since Dan Gill's Details for Scale Autochute, generally seen as the "Cadillac" solution for this problem, is no longer available. Gary thought that it should be possible to emulate most of the relevant functions with logic controls on the Jeti and I think he's right, but it struck me as something that would be a bit complicated to do, and especially hard to understand and maintain.
I've done a lot of work with lua scripts on the DS-24 and I find it to be a really well-designed and well-engineered programming environment. In fact Gary and I first got connected here on RCU when he asked about my speed announce lua script that announces speed more or less frequently based on how much the speed of the aircraft is changing. I've also done a fuel announcer that computes time to "bingo fuel", and a live GPS display that puts the google maps image of the field on the display and overlays in real time the aircraft position. I have also experimented with an autothrottle to maintain airspeed by measuring the pitot speed and controlling the throttle (which works surprisingly well).
So it seemed logical to me to try a lua script for the parachute control problem.
I now have a first cut at the lua chute controller done that Gary and I have been iterating and refining. It looks at throttle, flaps, brakes and landing gear channel state .. and also counts pulses from a hall sensor (we got ours from AeroPanda) to measure wheel rotation. There is an arming switch you can assign and then when all the channel conditions are satisfied, it will deploy the chute.
The lua program works by creating three "virtual channels" C01, C02 and C02. C01 is for an optional parachute door release, C02 is for the chute deploy mechanism (e.g. an air cylinder to push the parachute out) and C03 is the control to jettison the chute from the aircraft. The lua program controls these three channels, and you use the function and servo assignment screens in the TX in the usual way to connect these channels to servos. It also has a sub-menu for ground use to load and test the deployment. There is a simple sequencer built in to allow a delay from door opening (or door lock release) to chute deployment.
We are still working on the hall sensor implementation, and interested in getting some more insight into how best to implement that. Should it count pulses, thereby measuring the ground run (e.g. 20 feet? 50 feet?) .. should it measure speed (e.g. don't deploy till below 60 mph .. should it do a WOW (weight on wheels) measurement requiring WOW be continuous for 2 seconds? 5 seconds? .. you get the idea .. we could implement each of these and have the user select a preference. All measurements are from the same sort of hall sensor and magnet... the Hall sensor just plugs into an RX channel that is set to be an input and then acts like a telemetry sensor (standard Jeti setup).
We are interested to see if anyone else out there wants to collaborate on the project, and especially would like insight from folks who have a lot of experience using braking parachutes. We are happy to supply anyone the current version of the program to play with and are happy to take comments, suggestions and advice.
As a former fan of Dan and D4S .. should the company come back I'd personally love to mod the lua program to work with their hardware and adapt their excellent autochute system to the Jeti radio.
Dave
06-29-2019, 09:08 AM
#2
Dave,
I've been running a drag chute on my DerJet Hunter for the last 3+ years. My own design install as its not part of the kit, using a D4S scale chute.
I have the chute control on a 3 position switch on my Jeti (Closed/ Deploy/ Release).
Just a few flights after I installed the chute, I inadvertently deployed the chute when on finals at about 10-15ft AGL after I moved my finger to the switch after going to idle, in preparation for deploying the chute on touchdown. The result was a significantly damaged model, severe enough that I ordered as new one in case I couldn't repair it, but repair it I did and it continues to fly reliably. I now have over 120 flights on it.
Thinking about the inadvertent deployment, apart from using wheel brake logic, all the other usual candidates (idle, landing flap, gear down) were met. It just turned out to be a very light switch that was easy to select. I though about a WOW micro-switch, but in the end opted to make my own locking 3-position switch (I got the switch from e-bay) and soldered onto a Jeti switch board.
I struggle with the concept of using Jeti telemetry and LUA to count wheel rotation pulses. At 50mph and assuming a nominal 5" wheel diameter, that results in 56 pulses per second, or one every 18msec. A smaller wheel would be even faster. I doubt hthat the Jeti TM update rate could support that pulse rate for transmitter processing of the pulses into a model speed. I think the only way you could do that would be to use a dedicated pulse counter processor on the model (Arduino??) and send a simple logic signal to the Jeti.
Other issues I see with multiple interlocks are lack of flexibility - what about needing to deploy the chute on an aborted take-off with take-off (but not landing flap) selected. I had to do that recently. I also like to deploy the chute in the flare, just before touchdown, and a WOW or wheel rotation interlock would prevent that.
I have just settled on the locking switch option. I do occasionally end up jettisoning the chute rather than deploying it as I miss the center switch position and go directly to the 3rd position. I'm thinking about adding in some 'AND' logic with another switch to initiate the jettison function Partial wheel braking may be a good option for that second jettison interlock signal.
Good luck and I hope you can make it work.
Paul
I've been running a drag chute on my DerJet Hunter for the last 3+ years. My own design install as its not part of the kit, using a D4S scale chute.
I have the chute control on a 3 position switch on my Jeti (Closed/ Deploy/ Release).
Just a few flights after I installed the chute, I inadvertently deployed the chute when on finals at about 10-15ft AGL after I moved my finger to the switch after going to idle, in preparation for deploying the chute on touchdown. The result was a significantly damaged model, severe enough that I ordered as new one in case I couldn't repair it, but repair it I did and it continues to fly reliably. I now have over 120 flights on it.
Thinking about the inadvertent deployment, apart from using wheel brake logic, all the other usual candidates (idle, landing flap, gear down) were met. It just turned out to be a very light switch that was easy to select. I though about a WOW micro-switch, but in the end opted to make my own locking 3-position switch (I got the switch from e-bay) and soldered onto a Jeti switch board.
I struggle with the concept of using Jeti telemetry and LUA to count wheel rotation pulses. At 50mph and assuming a nominal 5" wheel diameter, that results in 56 pulses per second, or one every 18msec. A smaller wheel would be even faster. I doubt hthat the Jeti TM update rate could support that pulse rate for transmitter processing of the pulses into a model speed. I think the only way you could do that would be to use a dedicated pulse counter processor on the model (Arduino??) and send a simple logic signal to the Jeti.
Other issues I see with multiple interlocks are lack of flexibility - what about needing to deploy the chute on an aborted take-off with take-off (but not landing flap) selected. I had to do that recently. I also like to deploy the chute in the flare, just before touchdown, and a WOW or wheel rotation interlock would prevent that.
I have just settled on the locking switch option. I do occasionally end up jettisoning the chute rather than deploying it as I miss the center switch position and go directly to the 3rd position. I'm thinking about adding in some 'AND' logic with another switch to initiate the jettison function Partial wheel braking may be a good option for that second jettison interlock signal.
Good luck and I hope you can make it work.
Paul
06-29-2019, 09:34 AM
#3
Thanks Paul. Beautiful pictures, the chute looks really sharp. Thanks for taking the time to write such a thoughtful post.
You are quite correct on the timing, I did not want to get into the weeds with my initial post but I've done the calculations too, and I have also extensively measured the callback loop time on the lua apps, and the telemetry refresh rate. The lua callbacks are anywhere between 30-50 per second depending on the load from other apps etc. So 20-30 msec approx. And, as you state not only is the pulse rate too fast, the pulses are narrow since the Hall sensor only responds when the magnet is passing .. once per rev or twice depending on 1 or 2 magnets. So the sensor has to be augmented by a divide by N chip .. serveral one chip CMOS or 74LS examples exist that I have on the bench. A divide by 8 or 16 not only makes the narrow pulses into a square wave but of course it slows down the repeat rate at the expense of resolution. Gets you into the 200-300 msec range which is manageable for lua and just in the ballpark from a telemetry refresh point of view. Taking N to 32 would make it easy, I'm working on finding the best resolution/timing tradeoff. Bench testing shows that the divider, which is one chip soldered inline with the wire and covered by heatshrink (looks like the old signal inverters or active Y connectors) should be good. This is the only potential technical showstopper. And yes, if you really had to you could put a small uP onboard .. You could use something even simpler than an Arduino .. many choices. I like the little esp8266 since has a lua runtime :-)
Dan had an advantage there since he had a closer-to-the-metal solution, so I suspect he did raw pulse counts/timings. I also experimented with the Jeti Hall RPM sensor as a perhaps overkill but prepackaged solution but whatever Hall sensor they use is VERY persnickety about spacing to the magnet which would probably be bad when stuck to the landing gear.
On attraction of WOW is that the sensor can be used "raw".
Interesting comments about "non-conventional" deployments on RTO or just above touchdown. Agreed that the Autochute philosophy does not work there. I am impressed if you have/had the presence of mind and appropriate muscle memory to actuate the chute on a rejected takeoff!
I have one locking two-position switch on my DS-24 that I intended to use for the RF switch, but that turned out not to be very attractive since the US versions draws 40ma so you have to remember to unplug it at the end of the flying day. The european/native one is much lower (uA) draw but not sold here because they did not FCC qualify it. So now I use that switch for the Autothrottle since you would not want to accidentally bump that either :-)
Dave
You are quite correct on the timing, I did not want to get into the weeds with my initial post but I've done the calculations too, and I have also extensively measured the callback loop time on the lua apps, and the telemetry refresh rate. The lua callbacks are anywhere between 30-50 per second depending on the load from other apps etc. So 20-30 msec approx. And, as you state not only is the pulse rate too fast, the pulses are narrow since the Hall sensor only responds when the magnet is passing .. once per rev or twice depending on 1 or 2 magnets. So the sensor has to be augmented by a divide by N chip .. serveral one chip CMOS or 74LS examples exist that I have on the bench. A divide by 8 or 16 not only makes the narrow pulses into a square wave but of course it slows down the repeat rate at the expense of resolution. Gets you into the 200-300 msec range which is manageable for lua and just in the ballpark from a telemetry refresh point of view. Taking N to 32 would make it easy, I'm working on finding the best resolution/timing tradeoff. Bench testing shows that the divider, which is one chip soldered inline with the wire and covered by heatshrink (looks like the old signal inverters or active Y connectors) should be good. This is the only potential technical showstopper. And yes, if you really had to you could put a small uP onboard .. You could use something even simpler than an Arduino .. many choices. I like the little esp8266 since has a lua runtime :-)
Dan had an advantage there since he had a closer-to-the-metal solution, so I suspect he did raw pulse counts/timings. I also experimented with the Jeti Hall RPM sensor as a perhaps overkill but prepackaged solution but whatever Hall sensor they use is VERY persnickety about spacing to the magnet which would probably be bad when stuck to the landing gear.
On attraction of WOW is that the sensor can be used "raw".
Interesting comments about "non-conventional" deployments on RTO or just above touchdown. Agreed that the Autochute philosophy does not work there. I am impressed if you have/had the presence of mind and appropriate muscle memory to actuate the chute on a rejected takeoff!
I have one locking two-position switch on my DS-24 that I intended to use for the RF switch, but that turned out not to be very attractive since the US versions draws 40ma so you have to remember to unplug it at the end of the flying day. The european/native one is much lower (uA) draw but not sold here because they did not FCC qualify it. So now I use that switch for the Autothrottle since you would not want to accidentally bump that either :-)
Dave
06-29-2019, 10:42 AM
#5
Dave,
Sounds like you have some serious thought invested in this - your electronic skills are well beyond my level.
I have 3 locking switches on my DS-16 and DS-24. Two Jeti 2-position locking switches (one for the RF switch and one for the turbine run/ kill switch) plus a self-built 3-position locking switch for the chute deploy.
If you build your own 3-position switch you need to use a Jeti 3-position switch for the donor board as each switch type has a specific resistor on it to allow the TX to auto-configure the switch.
I will probably use the 3-position locking switch on my next project as the engine start select switch (Left/ Both/ Right) as it will be a twin, but luckily no chute.
I love the remote RF switch, and I have no problem manually disconnecting the batteries at the end of the day.
Paul
Sounds like you have some serious thought invested in this - your electronic skills are well beyond my level.
I have 3 locking switches on my DS-16 and DS-24. Two Jeti 2-position locking switches (one for the RF switch and one for the turbine run/ kill switch) plus a self-built 3-position locking switch for the chute deploy.
If you build your own 3-position switch you need to use a Jeti 3-position switch for the donor board as each switch type has a specific resistor on it to allow the TX to auto-configure the switch.
I will probably use the 3-position locking switch on my next project as the engine start select switch (Left/ Both/ Right) as it will be a twin, but luckily no chute.
I love the remote RF switch, and I have no problem manually disconnecting the batteries at the end of the day.
Paul
06-29-2019, 12:19 PM
#6
Thanks for the info on the Jeti switches. I had wondered how they sensed 3 vs 2 posn switches.
We'll see how it works in practice. The telemetry update rate (which as you know is not user controlled and rather opaque especially if you have a lot of telemetry sensors...) is the wildcard .. the lua loop is much faster than it needs to be for this app (e.g. almost 10x the telemetry update rate) .. its min speed is set by stuff contained in the TX like screen drawing.
I am too much of a dingaling to remember to unplug so I use the magnetic switch instead...
Dave
We'll see how it works in practice. The telemetry update rate (which as you know is not user controlled and rather opaque especially if you have a lot of telemetry sensors...) is the wildcard .. the lua loop is much faster than it needs to be for this app (e.g. almost 10x the telemetry update rate) .. its min speed is set by stuff contained in the TX like screen drawing.
I am too much of a dingaling to remember to unplug so I use the magnetic switch instead...
Dave
06-29-2019, 06:14 PM
#10
My Feedback: (20)
Hi Guys, I the other half of the chute collaboration with Dave. My half is the used fighter pilot with over G'd single brain cell that just wanted to mash the button and have a cool chute pop out the back of the F-105. My friend Frank, who flies a Saab Draken, who has been using the D4S system for several years introduced me to the idea that it was a little more than mashing the button.
As Dave stated my first idea was to use Jeti logic switches to make some safety interlocks to prevent accidental deployment in flight. Of course I would have to figure out how a logic switch would work first, which at present I have no idea. I discussed this with Dave after we met at FIF in May and he said it would be very easy to do with a Lua program. I said what's a Lua? And my education began. Lua, Arduino, CMOS, 74LS, esp8266,... way over my pay grade but WOW, did Dave produce a really cool auto chute program. He got me smart enough to install and run a Lua program on the DS-24 and I have been beta testing each of his revisions. It is really slick program by a talented programmer, and with the exception of the hall sensor does not rely on telemetry data, just switch positions on the radio.
My questions are about how important and useful certain thing are since I have never used a chute before.
Is it important to have the chute available at half flaps for crosswind landings or aborted takeoff? Or just for full flaps?
Do you want it to deploy at touch down or after wheel spin up or being on the ground a certain time?
What about a bounce?
We need to taxi back with flaps up with out dropping the chute. No self respecting fighter pilot would taxi back with flaps down or speed brakes open. So Dave has programmed a really neat jettison consent switch.
Do we really need a wheel sensor or weight on wheels sensor or maybe just auto deploy when brakes are applied.
What do you guys think?
Anybody using a chute before please chime in here for the novice.
Many thanks Dave for helping me with this project for the F-105. I plan to get back to the 105 project in late summer after completing the Havoc project I on now.
Thanks,
Gary
As Dave stated my first idea was to use Jeti logic switches to make some safety interlocks to prevent accidental deployment in flight. Of course I would have to figure out how a logic switch would work first, which at present I have no idea. I discussed this with Dave after we met at FIF in May and he said it would be very easy to do with a Lua program. I said what's a Lua? And my education began. Lua, Arduino, CMOS, 74LS, esp8266,... way over my pay grade but WOW, did Dave produce a really cool auto chute program. He got me smart enough to install and run a Lua program on the DS-24 and I have been beta testing each of his revisions. It is really slick program by a talented programmer, and with the exception of the hall sensor does not rely on telemetry data, just switch positions on the radio.
My questions are about how important and useful certain thing are since I have never used a chute before.
Is it important to have the chute available at half flaps for crosswind landings or aborted takeoff? Or just for full flaps?
Do you want it to deploy at touch down or after wheel spin up or being on the ground a certain time?
What about a bounce?
We need to taxi back with flaps up with out dropping the chute. No self respecting fighter pilot would taxi back with flaps down or speed brakes open. So Dave has programmed a really neat jettison consent switch.
Do we really need a wheel sensor or weight on wheels sensor or maybe just auto deploy when brakes are applied.
What do you guys think?
Anybody using a chute before please chime in here for the novice.
Many thanks Dave for helping me with this project for the F-105. I plan to get back to the 105 project in late summer after completing the Havoc project I on now.
Thanks,
Gary
06-30-2019, 05:26 AM
#11
My Feedback: (21)
It would be easy to add a simple timing circuit that would require a specific amount on the “ground “ time before triggering, thereby eliminating the bounce issue.. I can see a situation where a bounce could trigger the chute as well from a wheel spin up circuit.
Bob Neal
Bob Neal
06-30-2019, 06:15 AM
#12
Gary,
From what I've seen with my chute on the Hunter I think a lot of this complexity is not needed.
As I mentioned previously, I have just a simple 3-position locking switch at position SB (top left) of my Jeti transmitter. All I do is, once I go to idle just before the flare I move by hand to the chute switch, as I no longer need to use the left stick. I can then deploy the cute when I want (I try for in the flare, just before touchdown).
In a decent crosswind I do not use the chute as it will tend to weathercock the model nose into wind.
If you deploy the chute just before touchdown, it kills all tendency to bounce - the model just sticks.
I am unable to taxi with the chute deployed - the model just sits there with the chute catching the jet efflux and unable to move. Keep that up for long at high power and you will burn off the chute. If there is some wind I can occasionally manage to turn around before I stop and that then allows the chute to fly clear of the exhaust allowing me to taxi back with it still attached. Once it inflates in the exhaust stream you have to jettison it.
The only improvement I am considering is either separating the jettison from the deploy switch or having a second jettison consent switch, as I occasionally miss the center detent and go right to the jettison position and dump the chute on the runway.
Paul
From what I've seen with my chute on the Hunter I think a lot of this complexity is not needed.
As I mentioned previously, I have just a simple 3-position locking switch at position SB (top left) of my Jeti transmitter. All I do is, once I go to idle just before the flare I move by hand to the chute switch, as I no longer need to use the left stick. I can then deploy the cute when I want (I try for in the flare, just before touchdown).
In a decent crosswind I do not use the chute as it will tend to weathercock the model nose into wind.
If you deploy the chute just before touchdown, it kills all tendency to bounce - the model just sticks.
I am unable to taxi with the chute deployed - the model just sits there with the chute catching the jet efflux and unable to move. Keep that up for long at high power and you will burn off the chute. If there is some wind I can occasionally manage to turn around before I stop and that then allows the chute to fly clear of the exhaust allowing me to taxi back with it still attached. Once it inflates in the exhaust stream you have to jettison it.
The only improvement I am considering is either separating the jettison from the deploy switch or having a second jettison consent switch, as I occasionally miss the center detent and go right to the jettison position and dump the chute on the runway.
Paul
06-30-2019, 06:16 AM
#13
My Feedback: (3)
Awesome little project!
To keep it simple and not require telemetry input that could go wacky, why not:
- chute arming switch ON (any two way switch)
AND
- half OR full flaps selected (don’t really have to have this if not desired)
AND
- gear down
AND
- Brakes applied (for X seconds or greater than Y % brake applied)
THEN
Deploy Chute.
JS
To keep it simple and not require telemetry input that could go wacky, why not:
- chute arming switch ON (any two way switch)
AND
- half OR full flaps selected (don’t really have to have this if not desired)
AND
- gear down
AND
- Brakes applied (for X seconds or greater than Y % brake applied)
THEN
Deploy Chute.
JS
06-30-2019, 08:04 AM
#14
Jamie,
That is where Gary started the conversation .. using "logic mixes" to do all but the wheel spin function. And of course you can do that, just as you described.
Doing it this way puts all the complexity on the end user to master all the mixing, and essentially every end user has to do their own programming. Folks who love programming their radios will see it as simple, folks who don't .. not so much. So a lua script with a few setup screens basically does the same thing in lua code, but lets an end user set it up visually and very easily since the structure of the problem is embodied in the lua program. In the end, same result. Control positions only, no wheel spin, no telemetry. Our lua script can work that way .. just don't assign a sensor.
Paul has an even simpler proposition .. and any engineer will tell you that simpler is better .. just use the three-position guarded switch. Tradeoff is simplicty vs safety interlocks. Einstein said "as simple as possible but no simpler" .. Bill Lear of Learjet fame said "it you don't put it in the plane, you never have to fix it" (or something like that). Paul also notes that the safety interlocks may prohibit two important or interesting use cases .. rejected takeoff and deploy in the flare.
Dan's autochute was a separate dedicated piece of hardware, additional safety interlocks based on wheel spin. Again, the "Cadillac" back in the day and sadly no longer available.
So really, there is a range of tradeoffs depending on personal preferences. For his F-105 Gary will be able to choose any of these options, perhaps with wheel spin measurement, whetever he decides is best for him.
Honestly since this is my hobby (where an economist would say we do it purely for fun and value our time at $0) and I love tinkering with programs and electronics I took it as a challenge to see if we could use the native Jeti ecosystem and re-create Dan's functionality. Is the Jeti system powerful enough and flexible enough to replace a somewhat sophisticated custom hardware device with stock Jeti parts and some lua. And it turns out you can!
Read more if interested...
I spent the morning spinning a fake jet wheel on my milling machine and using an individual hall sensor with a divide by 16 chip .. and also using the Jeti MRPM hall sensor. As Paul pointed out in his first post, to get wheel spin
to work with telemetry you have to deal with about a 200-300 ms latency in telemetry delivery to the TX and a 20-30 ms loop time in lua. For this problem the telemetry latency is the more critical item.
Using a "bare" hall sensor requires a divide by 16 counter (just one 25 cent chip that you can hide in the servo cable). So instead of sensing one revolution of the wheel (which spins at about 6000RPM in a typical jet landing!) which is too fast, you sense once for each 16 revolutions .. so resolution is 16 ft vs 1 ft (a typical jet wheel travels about a foot per revolution .. pi times d). The divide by 16 is to slow down the signal enough to reliably get it thru the telemetry system to the lua program in the TX. Essentially, you trade speed for resolution. It is workable for our situation.
Using the Jeti Hall RPM sensor is a more elegant solution since they do all the fast sensing and counting and just provide an RPM number. I had originally thought the Hall sensor that comes with the MRPM was too fussy about spacing from the magnet to the sensor. That was my issue .. turns out it is fine and can sense well even with a 1/8" gap. This deals very nicely with the wheel spin speed problem, and uses only out of the box components as I originally hoped, and removes telemetry latency from the critical path.
Then Paul raised the very interesting use cases of a rejected takeoff where you want the braking from the chute, or the ability to deploy in the flare, which I have to admit is irresistably cool... The Jeti world has other tricks up its sleeve for this.
As I am sure we all know there are gyroscopic sensors in the TX box and there is also voice actuation. I've played with both of these. I've done a fuel state announcement with a quick flip of the TX in the up direction (this is quite useful .. and not disruptive to flying). I've also played with the voice reco. You can enable it to listen with a pushbutton, or with a salutation (like "Hey Google.." or "Alexa..."). I set mine to "Hey Jeti". Then I did a simple lua program to allow the smoke system to be turned on and off with voice: "Hey Jeti .. smoke on!" and "Hey Jeti.. smoke off!". Worked just fine. Maybe a little too cute.
But suppose you set up voice and tx flip up to do an immediate chute deploy .. actuate either way .. you could still require gear down and low throttle for safety .. and override all other interlocks. Then on the rejected takeoff, chop the throttle, flip the TX up or say "Hey Jeti .. DEPLOY!". For the deploy in the flare .. when 6" off the ground say "Hey Jeti .. DEPLOY".
I know ... going the wrong direction in complexity .. but .. using only standard Jeti programming and a lua script and only off the shelf Jeti sensors. Cool.
Dave
That is where Gary started the conversation .. using "logic mixes" to do all but the wheel spin function. And of course you can do that, just as you described.
Doing it this way puts all the complexity on the end user to master all the mixing, and essentially every end user has to do their own programming. Folks who love programming their radios will see it as simple, folks who don't .. not so much. So a lua script with a few setup screens basically does the same thing in lua code, but lets an end user set it up visually and very easily since the structure of the problem is embodied in the lua program. In the end, same result. Control positions only, no wheel spin, no telemetry. Our lua script can work that way .. just don't assign a sensor.
Paul has an even simpler proposition .. and any engineer will tell you that simpler is better .. just use the three-position guarded switch. Tradeoff is simplicty vs safety interlocks. Einstein said "as simple as possible but no simpler" .. Bill Lear of Learjet fame said "it you don't put it in the plane, you never have to fix it" (or something like that). Paul also notes that the safety interlocks may prohibit two important or interesting use cases .. rejected takeoff and deploy in the flare.
Dan's autochute was a separate dedicated piece of hardware, additional safety interlocks based on wheel spin. Again, the "Cadillac" back in the day and sadly no longer available.
So really, there is a range of tradeoffs depending on personal preferences. For his F-105 Gary will be able to choose any of these options, perhaps with wheel spin measurement, whetever he decides is best for him.
Honestly since this is my hobby (where an economist would say we do it purely for fun and value our time at $0) and I love tinkering with programs and electronics I took it as a challenge to see if we could use the native Jeti ecosystem and re-create Dan's functionality. Is the Jeti system powerful enough and flexible enough to replace a somewhat sophisticated custom hardware device with stock Jeti parts and some lua. And it turns out you can!
Read more if interested...
I spent the morning spinning a fake jet wheel on my milling machine and using an individual hall sensor with a divide by 16 chip .. and also using the Jeti MRPM hall sensor. As Paul pointed out in his first post, to get wheel spin
to work with telemetry you have to deal with about a 200-300 ms latency in telemetry delivery to the TX and a 20-30 ms loop time in lua. For this problem the telemetry latency is the more critical item.
Using a "bare" hall sensor requires a divide by 16 counter (just one 25 cent chip that you can hide in the servo cable). So instead of sensing one revolution of the wheel (which spins at about 6000RPM in a typical jet landing!) which is too fast, you sense once for each 16 revolutions .. so resolution is 16 ft vs 1 ft (a typical jet wheel travels about a foot per revolution .. pi times d). The divide by 16 is to slow down the signal enough to reliably get it thru the telemetry system to the lua program in the TX. Essentially, you trade speed for resolution. It is workable for our situation.
Using the Jeti Hall RPM sensor is a more elegant solution since they do all the fast sensing and counting and just provide an RPM number. I had originally thought the Hall sensor that comes with the MRPM was too fussy about spacing from the magnet to the sensor. That was my issue .. turns out it is fine and can sense well even with a 1/8" gap. This deals very nicely with the wheel spin speed problem, and uses only out of the box components as I originally hoped, and removes telemetry latency from the critical path.
Then Paul raised the very interesting use cases of a rejected takeoff where you want the braking from the chute, or the ability to deploy in the flare, which I have to admit is irresistably cool... The Jeti world has other tricks up its sleeve for this.
As I am sure we all know there are gyroscopic sensors in the TX box and there is also voice actuation. I've played with both of these. I've done a fuel state announcement with a quick flip of the TX in the up direction (this is quite useful .. and not disruptive to flying). I've also played with the voice reco. You can enable it to listen with a pushbutton, or with a salutation (like "Hey Google.." or "Alexa..."). I set mine to "Hey Jeti". Then I did a simple lua program to allow the smoke system to be turned on and off with voice: "Hey Jeti .. smoke on!" and "Hey Jeti.. smoke off!". Worked just fine. Maybe a little too cute.
But suppose you set up voice and tx flip up to do an immediate chute deploy .. actuate either way .. you could still require gear down and low throttle for safety .. and override all other interlocks. Then on the rejected takeoff, chop the throttle, flip the TX up or say "Hey Jeti .. DEPLOY!". For the deploy in the flare .. when 6" off the ground say "Hey Jeti .. DEPLOY".
I know ... going the wrong direction in complexity .. but .. using only standard Jeti programming and a lua script and only off the shelf Jeti sensors. Cool.
Dave
Last edited by ww2birds; 06-30-2019 at 08:21 AM.
06-30-2019, 10:40 AM
#15
My Feedback: (20)
Hi Dave,
This is good news with the Jeti Mrpm sensor. As we first discussed I thought we could just input the wheel diameter and the program could compute MPH. Then you could select deployment at < or > some selected speed similar to what the D4S system did. As you said the fancy stuff is in the program and it allows the user to use some or all of the interlocks as they feel the need. I like the idea of being able to select the options or turn stuff on and off with the visual menu options in your Lua program. I have my radio and servos here at Myrtle Beach so I can give the new revision a test run this week before I get back home.
We need to talk about your voice controlled smoke on/off program. That sounds really cool. Playing with fun stuff is part of my hobby like yours, except I'm not smart enough to program it. I would love to try it out with the Havoc.
Also I was thinking of using the Havoc as a drag chute test bed by making a removable chute pod that would fit on the bottom between the ventral fins. This way we could test the chute program using a proven airframe that would have no trouble "dragging" it around.
Gary
This is good news with the Jeti Mrpm sensor. As we first discussed I thought we could just input the wheel diameter and the program could compute MPH. Then you could select deployment at < or > some selected speed similar to what the D4S system did. As you said the fancy stuff is in the program and it allows the user to use some or all of the interlocks as they feel the need. I like the idea of being able to select the options or turn stuff on and off with the visual menu options in your Lua program. I have my radio and servos here at Myrtle Beach so I can give the new revision a test run this week before I get back home.
We need to talk about your voice controlled smoke on/off program. That sounds really cool. Playing with fun stuff is part of my hobby like yours, except I'm not smart enough to program it. I would love to try it out with the Havoc.
Also I was thinking of using the Havoc as a drag chute test bed by making a removable chute pod that would fit on the bottom between the ventral fins. This way we could test the chute program using a proven airframe that would have no trouble "dragging" it around.
Gary
06-30-2019, 06:10 PM
#16
My Feedback: (3)
Dave, Gary and I chatted about the project today. You’re a wizard and I’m glad that you are working on this project even if my jet does not have a chute. So much to learn from a guy with your talents that could be applied to other applications. Thanks for your contributions and willingness to share with all of us. Looking forward to seeing the evolution of this LUA project! JS
Last edited by jsnipes; 06-30-2019 at 06:34 PM.
06-30-2019, 06:30 PM
#17
Hi Jamie,
You guys are too kind .. I am not a professional programmer .. far from it .. but I do love a challenge and an interesting problem to work on :-)
Some of the guys who do lua scripts for RC companies (e.g. Daniel who works with Sandor) are truly talented .. I really admire and learn a lot from their work.
Gary, (and anyone else interested)
I am resurrecting the voice-controlled smoke program .. it was one of my first Jeti lua scripts and I can do a lot better now with the experience I have. I did wonder how it would do at a noisy flight line vs in a quiet local environment .. perhaps it would need a headset mic like the ones we use with cell phones .. but perhaps not. I've had good success with it but just at the local field. Plus smoke is not really a life or death sort of function and I have a physical switch to turn it off no matter what.
Dave
You guys are too kind .. I am not a professional programmer .. far from it .. but I do love a challenge and an interesting problem to work on :-)
Some of the guys who do lua scripts for RC companies (e.g. Daniel who works with Sandor) are truly talented .. I really admire and learn a lot from their work.
Gary, (and anyone else interested)
I am resurrecting the voice-controlled smoke program .. it was one of my first Jeti lua scripts and I can do a lot better now with the experience I have. I did wonder how it would do at a noisy flight line vs in a quiet local environment .. perhaps it would need a headset mic like the ones we use with cell phones .. but perhaps not. I've had good success with it but just at the local field. Plus smoke is not really a life or death sort of function and I have a physical switch to turn it off no matter what.
Dave
07-01-2019, 04:32 AM
#18
Edgar,
Here you go. These are the ones I got.
https://www.ebay.com/itm/NEW-C-K-710...item4d7deaf700
Paul
Here you go. These are the ones I got.
https://www.ebay.com/itm/NEW-C-K-710...item4d7deaf700
Paul
07-01-2019, 07:24 AM
#21
If I recall correctly, de-soldering the original Jeti witch from the circuit board was simple, aided by a solder-sucker.
Remember to use a 3-position Jeti switch for the donor board. The first one I did I used a 2-position switch and I couldn't work out why the Tx would only show a 2-position switch when on Auto - over-riding it to manually configure the switch worked fine. There is a resistor on the board that is used to enable the correct switch auto-configuration.
I think I had to trim down the pins on the new switch to fit the holes in the circuit board - a pair of side-cutters worked well and I managed to insert all 6 pins into the board. Be careful not to get the board too hot or you will damage the board and the printed tracks. I scrapped one in the process.
You do have to thin down the lock nut as the threaded portion of the new switch does seem a little shorter. I rubbed the lock-nut on some sandpaper to get it to the point that the threads would engage.
Once done it works well. I wish Jeti would provide this as one of their standard switch options.
Paul
07-01-2019, 07:47 PM
#22
My Feedback: (2)
Lua Scripts
I would like to try your lua script for smoke and drag chute if you care to share. I am not a programer but have a good friend who is good with lua and should be able to adapt your script to other radios. Direct email: [email protected]
07-02-2019, 04:00 PM
#23
My Feedback: (13)
I did something similar for my F-4 chutes. I set up logic switches that look for gear down AND throttle below X% AND a chute-arming switch (three position switch that up is chute dearmed, and no brakes, middle is chute armed, down is chute armed and a tiny bit of wheel brakes on(crosswind use)) AND a pushbutton on my throttle stick deploys the chute. I taxi out, arm the chute, takeoff and aomet8mes dearm the chute, sometimes don’t. Then in pattern once gear are down I arm the chute and either select brakes on or no depending on factors and then punch the button once I’m on the ground (throttle idle) and out comes the chute!
the ultimate safety of course is a fuseable link in the chute itself that will fail if deployed too fast
Last edited by ozief16; 07-02-2019 at 04:02 PM.
07-02-2019, 04:44 PM
#24
My Feedback: (20)
That's pretty much where we are now with Dave's program. He sent me the latest version and it seems to work great on the bench with servos connected. Next step is to incorporate the Mrpm sensor data into the program for wheel spin on the ground. The short pole in the tent is me and shop time to build up the working system to install and test. Hopefully by end of summer.
Gary
Gary
07-04-2019, 08:58 PM
#25
My Feedback: (51)
Hello guys.
i may he able to custom develop a real time based, small size low weight controller for drag chutes. i have done many types of controllers for RC jets and this is something cool and different and I'd love to play with it.
do you guys have the required logic for sensing / deployment finalized?
i may he able to custom develop a real time based, small size low weight controller for drag chutes. i have done many types of controllers for RC jets and this is something cool and different and I'd love to play with it.
do you guys have the required logic for sensing / deployment finalized?