Just to be clear, I’m not actually going to code the android app, I can help with the encoding information, but java and android are a couple of steps in a different direction from my programming, and I don’t really think I can spend the time to learn it for a 1 off application
Yeah, i gathered that from comments on rcg. You’ve done quite enough for us as is and we are very appreciative of all your work! Not sure if I’ll get very far with it but I’ll certainly try!
Well I’ve just learned ovet on the rcg thread that when using a toy tx - trims do not work in silverware at all as actual trims … but the buttons can be used as aux channel switches. So I will make another edit to my toy tx channel mapping to account for this option. That gets racemode off of the headfree button with that annoying beeping. I’ll report back after testing. Maybe @FelineFlyer can help me test once updated to confirm. And as a result of the feature request from @usererror … I can seperate arming and idleup/airmode as two seperate features. They could be set to the same switch so that it functions like current nfe firmware, arming could be set to always on so behavior is more like a toy, airmode could be toggled on and off… I just never considered seperating the two because I’ve always used those two features together on one switch. What do you guys think? Seperate arming and airmode features, or leave them as one linked feature? @Ian444 - any guidance?
I don’t use airmode myself (throttle down is motors off), but have been researching a little bit recently due to the dedicated silverware FC coming into existence, where people coming from BF might need an airmode or idle-up switch.
Historically there was an airmode, it was in H8 blue firmware until about maybe 3 weeks ago. Here is a quote from silverxxx from May 2017 about it:
Airmode as referred to in this firmware / thread is just a throttle management function. Normally, silverware cuts motors below 10% throttle, as there is no arm / disarm. Airmode keeps them running, and it can be done via throttle modification in the tx.
In other firmwares Airmode also increases / decreases throttle as required. This 2 functions are available separately here, as Mix_lower_throttle / mix_increase_throttle.
I asked silverxxx recently if “airmode” as in idle-up could be added to the B03 firmware for the BF guys who might want that feature in the dedicated silverware FC and this was the answer:
I think with the arm function , the main problem is, silverware can react quite extremely even at minimal throttle. I’ve been thinking about a solution, but I’m not sure, maybe a ramp-up after takeoff.
I know bf quads are quite mild when armed, and I think most people would expect something like that, and they’ll get a nasty surprise.
But I’m not against an arm switch if I can make it better, maybe even now, software or tx side makes little difference to me.
Do you think it’s ok like an idle up now? ( but software side ) Or is there some issue due to the above reason?
I tested the “airmode” in the older H8 blue firmware and it seems fine, and works (for me) as expected. I think it is much the same as your idle-up switch. I didn’t follow up as demand for the feature in that thread was low.
As far as I can see, if the NFE arm/idleup/airmode all work on one switch with no unpleasant side effects, I would run it that way. I can’t really see the point in having 2 switches to be set before takeoff. I think in BF some (or many) people use 2 switches as the BF airmode makes it difficult to land IIRC, or they switch airmode on only after liftoff, I’m not sure tbh.
Using idle up in combination with mix increase is basically the silverware version of betaflight airmode yes. And silver is right … in both cases there can be a rather aggressive reaction on the ground with it active. In bf… the safety for taking off (I think) is that once armed and activated … the idle up portion is on right away but the mix increase throttle portion doesn’t become active until the first time the throttle stick passes some minimum set value. It’s kind of an insignificant difference for little brushed quads but it could make pre takeoff on ground behavior erratic in a powerful brushless setup. In both firmwares … a timely disarm is needed to avoid bouncing on landing. Maybe I should code the throttle safety thing next. Oh and even if I split the features (arm and idle up)…they could both be assigned to the same switch. That is the way we do it in betaflight. I don’t really want to work over tge entire presentation to mimic betaflight … but it isn’t quite intuitive to most the difference between bf airmode, idle up, mix increase.
Sounds like the best and safest way to go at this stage. The minimum set value might need to be adjustable to account for different kv motors/quad weights. Otherwise a timer from throttle first raised, not sure. Maybe @silver13 has some ideas up his sleeve?
I don’t use this feature, so not really sure how to deal with it. For brushed it’s probably fine as an idle up.
For landing, maybe a detector could be used, the gyro data spikes very badly when the quad lands. Probably not the safest since it only has to fail once, it could probably be used for something though
Yes landing with betaflight airmode on, with a powerful brushless quad, can be sketchy. Standard procedure is a carefully timed disarm just as you touch down. I think that part has become common knowledge among betaflight users. It’s the takeoff event where betaflight puts the safety feature. If airmode is active on arming … then it’s only idle up without mix increase until throttle passes a set point. That way it doesn’t start bouncing on the ground as soon as you arm. I’ll put that on my to do list next.
My toy launcher connection (jjrc h67)
But there is no way to control it
I believe there was also this issue in Airmode with I term building up resulting in the quad suddenly shooting to the moon lol
Hi, just had to read through the whole thread, nice developmental stuff going on here
Something that I noticed while I was trying your fork:
- Selecting the boards the way you did it is nice, but I guess it’s not complete. H8mini_blue and Bwhoop boards use HW I2C on Gyro with the setting fast2 on Silver’s repo, not sure if it was inteded to use software I2C on all boards. (makes tuining more consistend though). Also the pushpull is E011 related only.
- A personal wish: Dual PIDs. It might make tuning faster plus I think it’s very useful to compare 2 settings. Perhaps maybe make the whole tune switchable including filters (not sure how the coding amount would be)
- Perhaps implement SilverAG’s switchable telemetry that can display PIDs in Devo
- Speaking of channels, one should include the remaining 2 of all 12 Bayang channels (I guess that’s more Silver’s Part :P)
Just thinking out loud, watch it as a few Ideas that can be discussed
@SirDomsen - hey man… THANK YOU for such awesome feedback and for checking out the fork!! Let’s go over some specific responses to your points… cause they are quite important!
Everything you noticed as a result of selecting the board type was actually intentional. @Ian444 informed me that the h8mini blue has a single pull up resistor on on i2c (like the e011) so selecting that option to correct should put us on track to use software i2c fast. Was that decision incorrect? As for the bwhoop, I was also under the impression that since it had the correct i2c pull-ups that it was supposed to run software i2c fast. I believe that is what silver has in his main repository. Myself I only have e011 boards so I rely on you guys for tge right settings on the other 2, but I used to fly hardware i2c fast 2 on e011 and found soft i2c fast a good bit better once the pull up resistor thing got fixed.
Dual pids could be a pretry cool advanced feature. I will daydream about that till the correct implementation strikes me! I don’t imagine it would be too hard.
I absolutely plan to merge in all of SilverAG’s work. It is awesome! ! Just need free time to do so.
Yeah I’ll leave 4 up to silver then merge that in also!!
To be honest, I always thought HW I2C would run best, but only assumed and set but never tested it eventually …
If soft I2C fast runs better, just leave as is, makes tuning easier as the boards are consistent then.
might give it a shot on my virating boss quad, perhaps that’s the problem
That’s exactly what I though too. I tried asking over on rcg but never really felt like I got a clear answer on it and the push seemed to be towards using soft i2c. In theory using hardware to alleviate that load from the mcu seems to make intuitive sense … but I am admittedly out of my area of expertise with such a question. Lol I’m a materials engineer. I can tell you more than you ever wanted to know about what these chips are made of… but what works best - I’m clueless and left to highly subjective testing to try to decide.
Hi, (USE_MULTI) aux channels seem a bit mixed up for me - CHAN_5 in config.h = CHAN_6 in OpenTX transmitter with multiprotocol module. CHAN_8 is at CH8 like it should and I am not sure about the other channels.
Here’s a cross-reference, might help. It should be correct, but unverified as I don’t have a multiprotocol unit to test with.
There are so many multiprotocol modules now that we may be dealing with more than one mapping. My mapping matches the picture above for multi. What module are you using @silenec?
I noticed the differences in I2C too, when setting up for my first board which was a H8 mini blue. In the github firmwares, by default, the E011 and B-03 use software i2c and only the H8 mini blue uses hardware i2c.
The B-03 has 2 pullups yet runs software i2c as default. E011 and H8 blue have only one pullup. The softi2c_pushpull_clk option is also in B-03 and H8 mini blue code (but not set as default).
I must admit, when I set up the first H8 blue board I ran hardware i2c after thinking about it. All subsequent boards I tested this NFE firmware on used copies of that first one, so all have hardware i2c running. I will start trying the software_i2c and softi2c_pushpull_clk and see if I can find anything. I am noticing though with these different filters I can relax the PID’s a bit compared to before. I think but am not sure that this is an indication of less delay in the filters?
Just for info, it looks like in drv_ic2.c that the code defaults to USE_SOFTWARE_I2C if none of these are set in hardware.h:
In my fork, all boards are set to software i2c fast and selecting the e011or h8blue will enable that push pull chk to compensate for the missing pullup. I’m certainly curious to any feedback from side by side testing if I should change it.