Protocol Stacks

FDR wrote: Looks like it was a flat battery...

I've flown my CB100 and Genius CP with the new fw!
BTW looks like the gyro gain is sent on channel 7. I thought it is the 5th, but the rx led doesn't light, which is the case of too low gyro gain, and it flew horrible that way...

Is your CP Deviation based or WK2801?
We should start thinking about setting up a repository where folks can upload model configs

My Genius CP is a DEVO compatible one, so it supposed to work, but it's not easy to configure a CP to be able to fly with deviation.
There is not enough help which channel does what...

...and the most problematic thing is that it is still not reliable. There is a lot of settings to set, and sometimes (mostly on the first attempt) they just disappear. For example one such bug I could reproduce (that I've reported that on bitbucket) is when pressing the OK on the channel page: it clears all the mixer settings.

One more request:
Could you implement the fixed id stuff for the devo protocol, because I used to use it with the original fw, and now I had to clear it to try deviation.

BTW I don't like Walkera's arroach of fixed id: if you have binded you model, you can switch models and it stays binded whether it is with different fixed id or without fixed id at all...
I use fixed id to make sure I won't use it with wrong setup, but their way it can happen...

FDR wrote: One more request:
Could you implement the fixed id stuff for the devo protocol, because I used to use it with the original fw, and now I had to clear it to try deviation.

Untested, but it should be fixed now

BTW I don't like Walkera's arroach of fixed id: if you have binded you model, you can switch models and it stays binded whether it is with different fixed id or without fixed id at all...
I use fixed id to make sure I won't use it with wrong setup, but their way it can happen...

That is odd. The fixed-id is part of each packet sent, so I would consider it a bug in either the Tx or the Rx if switching models doesn't result in losing the connection.

PhracturedBlue wrote:

FDR wrote: BTW I don't like Walkera's arroach of fixed id: if you have binded you model, you can switch models and it stays binded whether it is with different fixed id or without fixed id at all...
I use fixed id to make sure I won't use it with wrong setup, but their way it can happen...

That is odd. The fixed-id is part of each packet sent, so I would consider it a bug in either the Tx or the Rx if switching models doesn't result in losing the connection.

While I don't like it that way, I don't think it is a bug, but rather intentional.
Probably they choosed it because they think it is still better to fly with wrong settings, than fall out of sky for sure... (At least if some fool switches models while flying!)

I would rather inhibit switching models while one is flying. We could watch some channel output (for example the throttle) to determine this, but there are cases, when it wouldn't be enough, for example for gliders, which don't use throttle...
This is probably the same check, that would needed on turning on...
Later, we can use telemetry to find out if a model is even bound...

When someone switches models, while an rx has already bound, we should rebound it. The problem is you cannot rebound the rx when it has already bound. It has to be restarted... EDIT: Hasn't it? ...or can we make it loose that bind, and then bind it again with other ID?
But leaving it bound and fly it with wrong settings by mistake is dangerous, and I would call it a bad design decision!

FDR wrote: When someone switches models, while an rx has already bound, we should rebound it. The problem is you cannot rebound the rx when it has already bound. It has to be restarted... EDIT: Hasn't it? ...or can we make it loose that bind, and then bind it again with other ID?
But leaving it bound and fly it with wrong settings by mistake is dangerous, and I would call it a bad design decision!

I don't know if we have any control over it. We'll have to do some experimentation to see what happens. One thing we could do would be to change the channel assignments when the model is changed (this may already happen actually, though there is no way of knowing if you'll get the same channels or not. Usually the channel allocation should be somewhat random though

PhracturedBlue wrote: One thing we could do would be to change the channel assignments when the model is changed (this may already happen actually, though there is no way of knowing if you'll get the same channels or not. Usually the channel allocation should be somewhat random though

Yep, but it doesn't help with the already bound rx. It will stay bound and listen to the previous channels and id...

I don't know where it belongs to, but I have one more problem with the stick calibration besides the one I have reported on bitbucket:
I cannot calibrate the stick to reach -100%..+100% range reliably.
If I move the sticks around the whole rectangle they can move in while calibrating, then I get some 97%..98%.
But my Genius CP spins up the rotors even at -99% throttle!!
If I move the stick only up/down and left/right while calibrating, then the range is better: 99%..100%, but then sometimes the stick can move beyond the calibrated 100%, which causes the reported bug (where the stick input should be limited).

FDR wrote:

PhracturedBlue wrote: One thing we could do would be to change the channel assignments when the model is changed (this may already happen actually, though there is no way of knowing if you'll get the same channels or not. Usually the channel allocation should be somewhat random though

Yep, but it doesn't help with the already bound rx. It will stay bound and listen to the previous channels and id...

??? What happens when you turn off your tx? My ladybird switches to a flashing light. I would expect the same behavior if we switched fixedid, but certainly if we switched channels.

If you rotors spin up at -99% throttle, it is likely the servo calibration is wrong on the Devo protocol.

On the stick calibration, I can back off the max/min values so you can hit 100%

PhracturedBlue wrote: ??? What happens when you turn off your tx? My ladybird switches to a flashing light. I would expect the same behavior if we switched fixedid, but certainly if we switched channels.

It's just the sign that it has lost signal, but not the binding. If the signal comes back, it would work again.
It's hard to test, but possible: set the power to minimum, and after binding take the tx far away, or shield it in some box until the rx looses signal, then take the rx back near. If it's find it again (led is still) and reacts, then it didn't loose the binding...

(I can't check this at the moment, because I'm at work...)

PhracturedBlue wrote: If you rotors spin up at -99% throttle, it is likely the servo calibration is wrong on the Devo protocol.

On the stick calibration, I can back off the max/min values so you can hit 100%

I don't know. It spins up very slowly, but it does (at least at -98% for sure). Genius is a very sensitive one, probably because of the coreless motors...

I think it would be better to set the stick range a tiny bit narrower, than the calibration shows, but limit it to the max valid range...

FDR wrote: I think it would be better to set the stick range a tiny bit narrower, than the calibration shows, but limit it to the max valid range...

Yes I agree, but I want to find the out-of-range bug 1st. Just because the input value is out of range should not make the channels go crazy.

I have changed the gyro to use "fixed", but there are interesting stuff remained in those mixers...

As I thought the input page is all right, but on the channels page the throttle pitch is jumping if I press the throttle stick down...

FDR wrote: I have changed the gyro to use "fixed", but there are interesting stuff remained in those mixers...

As I thought the input page is all right, but on the channels page the throttle is jumping if I press the throttle stick down...

I don't fully understand, however I did find a couple of other issues with the Fixed curve handling with regards to loading/saving which I've fixed.
Can you explain what the thrtottle value shows on the input page before and after the issue, and which channel you are looking at?

I created an overshoot on the throttle, and I see channel 6 jump in unexpected ways when I move it, so that is probably the same bug you filed, but may not be the same as the issue you are describing.

Yep, that's it!
The channel six, i.e. the pitch is jumping from -50% to +50%.
The -50%..+50% range is defined as a 3 point curve (-50,0,50), with the throttle stick as the source...

EDIT: Sorry I mistyped my message, should be:

FDR wrote: As I thought the input page is all right, but on the channels page the throttle pitch is jumping if I press the throttle stick down...

One strange thing: if I want to make ch4 (=RUD) a complex mixer, the rudder channel dissapears. It doesn't shown on the mixer list as the source, and doesn't work either...

Another one: with the devo protocol I had to reverse the aileron and the rudder channel for the Genius CP, however with the original fw all the channels are normal...

EDIT: Here is the model data, in which I try to make the rudder complex...

FDR wrote: Another one: with the devo protocol I had to reverse the aileron and the rudder channel for the Genius CP, however with the original fw all the channels are normal...

Is this true on the CB100 too?
I checked the WK2801, Devo and Flysky, and in all cases Up and Right move the servos counter-clockwise.
So they are consistent.I then checked the Devo7 Tx with my Devo12Rx and noticed that rudder and aileron should move the servos clockwise when the stick is moved right. That corresponds to what you are seeing, so I reversed the Rudder and Ailerons. Hopefully that will help.

I verified that in the Devo protocol, the servo throw is correct for +/- 100% so if you still don't have enough throw for your GeniusCP that would be quite odd.

I implemented support for changing the Tx Power. Range is the full range of the module which is ~100uW to ~150mW
That is one additional step on each side. I hacked up the bitmap to add the extra levels, but the images really need to be fixed to have more bars instead
I haven't actually tried running in 150mW mode. That is really pushing the PA hard, and may sacrifice the SNR.