Adding channels to the Bayang protocol?

Yeah, that way or a similar one would be nice from the point of view of a user. No idea if it's doable though.
A way like this would mean that PIDs could be stored in model config, so there would be an easy way to tune the quad for diffrent sorts of props or even diffrent main frames!

There's something to think about, maybe you don't want the PID's sent on bind, if you are running say 2 or 3 different quads with this board, and you only use one model ini file for all of them (which I do). But, I like the way this discussion is heading, and I am just one person, who can find a way to adapt. The possibilities are many, and there are many possible ways to achieve them.

but copying the model file to a new one and change only the necessary things (PIDs in our Case) that would not be a big deal, would it?

Edit: Or maybe Deeviation lets us select between a few PID sets - for toggleing between and see what the difference is - in the future. Who knows

For sure, yes. It will be interesting to see what is adopted. I have good faith in the extensive experience of the guys in here.

xxx wrote: It's hard to believe so little protocols use telemetry, with the 2.4 transceiver chips in use now it's only a matter of implementing the software. Even the cheap toy tx's that have a buzzer would only need a software change to make it beep on battery low.

Ok, this is mostly politics, not technical, so you may want to skip it. But it's a favorite rant of mine.

Your assumption about "only implementing the software" isn't right. Well, ok, it is, but you're missing the real issue. The vast majority of protocols are on the NRF, mostly for one reason - they are cheap. If you look at the protocols page in the supported models section, you'll notice that almost all the protocols use the NRF. The other three chips have three or four (depending on how you count DSM[2X] and the two FrSky protocols) protocols compared to ~20 for the NRF. The NRF protocols are all from companies whose sales strategy is to use low price to sell as many units as possible (one of the signs off a toy-grade product) rather than form a long-term relationship with the customer by sharing parts like transmitters between models. The latter means the company tends to push one or two protocols for all their models, whereas the former means they use whatever parts & software is cheapest on every design iteration, so you get multiple protocols from one company, sometimes on "the same" model!

In order for telemetry to be useful in an aerial RC context (as opposed to robotics or Internet of Toilets type things), you need an LNA in the controller. Otherwise, you only get telemetry for a fraction of the range of your aircraft. Those add to the cost, so won't show up in most toy-grade protocols. Given the importance of power management on an aircraft, you also need a PA on the aircraft and software to control it, again adding to the cost. I note that turning on telemetry on a Walkera Micro CP (temp & battery voltage) or a Estes Proto X (battery voltage) cuts the flight time by roughly 2/3rds on both aircraft. Of course, you also need something to do with it - meaning a display of some kind. A warning buzzer might be do, but only if it's not already in use. Again, adding to the cost.

I will note that some of the rc power boats now have what you're asking for - an LED or buzzer to indicate lower power on the boat. But they normally operate at park flyer ranges or shorter, so the LNA & PA issues aren't there, so it really is "only software". AFAIK, the only boat protocols we've added to deviation are the JoySway yacht protocols (though at least one power boat uses them). Those don't have a motor and typically come with even less capable transmitters than the toy-grade quads.

Which brings up another issue - possibly some of the protocols do have a telemetry option in the proprietary format, but until we have an example reverse engineered, it won't show up in deviation! So maybe some of them do, but we haven't got it yet.

I agree with your assessment, although I find it hard to believe a pa that uses 200mA would substantially reduce flight time. (I do believe you)

I guess I knew why they don't do it, it's just that, to me, spending time once to improve something at the design part of a product beats copying an substandard design a million times.

But of course, I do not expect this of any profit driven entities.

SirDomsen wrote: but copying the model file to a new one and change only the necessary things (PIDs in our Case) that would not be a big deal, would it?

Edit: Or maybe Deviation lets us select between a few PID sets - for toggleing between and see what the difference is - in the future. Who knows

Deviation does support comments in model files. So you could have a few sets of numbers in comments and just comment/uncomment lines to choose different ones. Unfortunately, one of the few things not supported on the user interface is reading or editing comments.

Right, so it'll,require som changing of the GUI. But as PhracturedBlue mentioned, there is a need of doing something new, so afaik Deviation 5.0 is on its way! Perhaps the possible need in this project here can ifluence the possibly new GUI design a little

Deviation 5.0 is going to be a stable version of current state, no new development.

victzh wrote: Deviation 5.0 is going to be a stable version of current state, no new development.

The new version creates a solid base for advancement. It doesn't have to slow it down.

5.01 will follow. And it will be amazing -- because of that solid base, and because of what is brewing now.

Many thanks to all the wonderful minds involved!

Richard96816 wrote: The new version creates a solid base for advancement. It doesn't have to slow it down.

Just the opposite, actually. The lack of a new release has slowed down current work a bit. 5.0.1 is liable to be mostly bug fixes after the broader exposure from 5.0.0. The version after that should be at least 5.1, if not 6.0, depending on what happens. For instance, if the (now dated) new toggle code goes in, then it should rally be 6.0, as the model files won't be backwards compatible.

How best to proceed towards a flexible/extendible protocol?

Someone makes a draft, taking into account all the limitations of realistic radio link

1, lack of PA on receivers, so unreliable telemetry/acknowledgement,
2. necessity to reliably pass channel values, so important channels should be repeated more often and values should be idempodent - no toggles, values passed explicitly,

Also, there should be some requirements. E,g, channel values are 4096-step (12-bit), passed every 7ms, 6 main values - AETRGP. Telemetry format is unclear to me, I can't add anything. Should they be floats? What precision if integers - is 12-bit value enough?
There should be some extension mechanism - number of channels and packet type should be passed in each packet.

I'm not an RC expert, I don't know what's needed from domain point of view. Is above (pseudo-) requirements reasonable? You tell me, or formulate your own and I will tell you what's feasible from the radio link point of view.

I don't think anybody does floats in a telemetry protocol. To use them directly, you'd want to use IEEE floats, and that's overkill. If you're going to use a custom format, you are back to manipulating ints anyway and trading away bits of precision to get extra range. Most valued in the protocols use a 16 bit value, which means you can count to for instance 64 volts in millivolt increments. There are also tricks you can pull to combine values, liked having one value count amp-hours and another count milliamp-hours beyond the last full amp-hour.

I've about decided to do the telemetry test page rewrite before starting on the alerts changes. I'll have a better feel for what kind of values go into telemetry afterwards.

Ok, for channels, I think 10 bits and higher would be fine, so 12 bits are ok. That is for the 4 main channels. Also a 8 bit with on/off channels(flip, etc) if there are any left

Channel order should be roll, pitch , yaw , throttle, so I can do a for loop...

Then the pid channels, I was thinking 8 bit *5 values. You were saying a different frame sent alternatively with the main one. I guess send it every 16 packets or something, it's not expected to change very often.

The telemetry , well, I only need to send 2* 8 bits with 2 voltages and a byte with flags ( battery low flag).

The quad loop time is 1mS so the telemetry will have a 1mS jitter. I guess a packet rate of 5mS or so?

Actually , I was thinking, what if you were to send the pids at bind, and check in the tx if they have been changed, and only start sending them if they have been?

xxx wrote: Channel order should be roll, pitch , yaw , throttle, so I can do a for loop...

Maybe I'm missing a joke, but channel order shouldn't change your ability to do a loop. Stick layout might, but that's independent of the channel order in the protocol.

I'd recommend AETR, as that's the most common order. Or at least it is among the hobby-grade protocols; I have no idea what the toy companies are doing. That's aileron (roll), elevator (pitch), throttle and rudder (yaw).

not that kind of loop, I mean a "for" loop (c++). it would only save 10 bytes or so...

Let me float this again.

For passing parameters to the quad at bind, we put one line in the transmitter's model.ini file for each one:
Or maybe:The transmitter would normalize and compress the list and send it to the quad at each bind. The second form might make selectable lists of parameter sets possible (OPT1, OPT2.)

I know space is tight on both ends. But this could make some very nice things possible.

If Deviation could allow editing of this list in the field that would be the icing on the cake.

Thanks.

It would also be nice for the quad to have a unique id or serial number to share with the transmitter at bind.

Then things like Hobbs (hours flown) could be handled for multiple quads automatically. Individualized settings could be handled too.


Edit: STM32 processors apparently have factory programmed unique ids. Not sure about other processor families.
techoverflow.net/blog/2015/02/03/reading...ique-device-id-in-c/

In the interests of moving things along, perhaps we should choose an existing protocol and add a couple of the most desired features. As a test-bed.

That would seem to be a lot quicker than starting from scratch. And hopefully make the eventual scratch build easier.

Since the intent is to provide silverxxx's open flight controller firmware with more functionality. A quicker implementation seems appropriate.

Thoughts and/or offers of coding efforts most appreciated.

Thanks.