[ Update at the end ]
You bought a brand new FRSky with 8 channel and a promise of a helpful PPM Sum output.
Be warned that you cannot use this with 8 channels. Only 6 channels could be used with some risks (only 5 for real safety). [Note #1 at the end] It's really disappointing.
Yes. FRSky's CPPM signal has a BIG problem: It has a period of only 18 milliseconds. What does that means? Here we go:
A PPM Sum signal usually has a period of 20ms. As each channel uses up to 2ms so you need 16ms to fully accommodate the data from 8 channels (8 * 2 = 16ms).
Now comes an important element: the Sync Pulse. It needs to be wider than all other ones to indicate the start of a new PPM train. Any 8 channels system based on a 20ms has room for a 4ms pulse (16 + 4 = 20ms). Even with all the channels at 100% a system like that still gives you a perfect sync pulse.
That's the BIG problem with FRSKy CPPM. If you start using some switches and knobs you are pretty much risking to lose the sync on your autopilot. Because the sync pulse is squeezed until having the same size of any channel.
I hope they can fix that with a firmware update sooner, because I believe it's not acceptable.
Until that, you cannot use it on your autopilot without risks. [Note #1 below]
[ NOTE #1 ]
This is far away from the ideal, but there is a cheat to eliminate the risks when using just 6 channels by suppressing CH7 and CH8 from CPPM.
At least on a ER9X or ERSky9X radios there is this way:
By changing your model's setup to use a Proto PPM 6CH it will not output CH7 and CH8.
(The frame space (300uSec) though is just ignored. I did not see any changes.)
I've verified on Oscope. It works!!! The CPPM was outputed from RX without CH7 and CH8.
Is still a shame and disappointing using just 6 from 8 channels. But that seems to eliminate the risk.
[ NOTE #2 ]
Jani, from jDrones took this issue to FRSky's GM/CEO and got a response from them. They are now baking a solution to release a new firmware. Probably the new CPPM frame period would be 27ms (the next available number dictated by the hardware's clock division).
[ UPDATE ]
Yesterday (28th September) Jani came up with a beta firmware from FRSky. It does output CPPM frames at 27ms. So far we have some positive feedback from DIYDrones dev team's tests. I'll not update this post anymore. A new post instead will show some results followed by a mini updating tutorial for those CPPM capable receivers. Stay tuned! ;)
[ UPDATE ]
This post shows how to fix it.
--Sandro
Comments
Yes, and this only would affect people who update their firmware. This will NOT become the default firmware on new hardware, and nobody is going to put a gun to anybody's head to update. If you want to use 8 wires, or continue to use CPPM on 18ms frame width, you are free to do so.
You are correct in that we have uncovered a case where the signal from the Rx can have a fault, and the PPM encoder does not signal for a failsafe. It just hangs on the last known good value. Maybe that should be fixed.
Jelle has a very good point however. The knowledge that we have a fixed 18ms period is actually a very strong data point. We can do a lot with that. I hadn't even thought of that yet. I think that's a back-up to the soft-sync idea that would make it pretty fault proof. I wasn't super happy with the idea of carrying on for a long period of time with the soft-sync. But the 18ms thing is good backup.
nice, ning ate my on the spot patch :(
change line 105 to read:
if((Pulse_Width>5000)||(PPM_Counter==8)) //Verify or guess this is the sync pulse
Untested code, use at your own risk.
Was that worth 12 pages of discussion?
That's good Sandro. They are only dropping frames for CPPM, then.
@Ellison: You said: "Using the FrSky update will potentially have an adverse affect on not only CPPM users, but also people using the channels separately from the receiver."
This is not true. That was the first thing I've tested on oscope after updating my receiver (D8R-XP). We are talking about receivers that has a jumper to enabling CPPM on CH1 and RSSI on CH2. If you don't set the jumper, so the frame still has a 18ms framing output.
Hmm, the main loop is still running at 100hz, from what I can see, and the radio is still being read on every iteration as well as stabilization code. So basically, the faster we can process in coming frames from the better our realtime response is. Ultimately accepting the 27ms radio frame, results in a drop of response. It's not really a question of whether a human being can respond at that rate. We move the stick from point A to point B, the machine samples all the points in between. The sample rate determines how finely we can control the craft.
You're right that the craft is, theoretically autonomous, but the granularity of that is limited. With GPS, it's probably in the 1M range, of 10hz, at best. Until we get better, close quarters flying is going be by RC transmitter.
What I'm trying to point out to the community, since this is open source, and we all own the code whether we are part of the development team or not, are the following:
I have presented my points, and as I'm not currently in a position to take on this coding project, I will just leave it at that.
@PX4, the picture is much broader than that one scope trace! We have already established it is a corner case, so it is safe to assume it will not occur at startup. That is when you acquire your sync pulse and start your counting to whatever number of channels you get offered. Two sync pulses will tell you that number and the refresh frequency.
The point I was trying to make is that you have a lot more knowledge about the signal you are offered besides that >4ms sync. You know the total frame length is fixed, you know what the last frame was, so you have a very good predictor what the values in the next frame will be and thus when the next pulse in the train will occur. This is not an analog receiver with a counter-IC anymore, you have a (very small) computer available, use those uC capabilities to be more forgiving in the input you accept!
As for complexity: nah, not really much more logic. You need to remember the number of channels and add a 'ninth-channel' or soft-sync function that calls the same stuff the >4ms routine is calling. For extra safety you could add a check that adds all channel values + sync and see if that matches the initial value.
@Ellison. In the first place, this is not our problem. FRSKY is who has a problem with their short CPPM period.
That affects not only our system but it does affect any other system that needs a trusty PPM signal using their lower cost hardware. They came up with a non-standard solution. But, at this time it's solving the main problem at a minimal and meaningless cost of adding extra 7ms.
Are you really telling that 10ms is sufficient? So we are all crazy here. We have 18ms. So, at your affirmation we do have much more than the necessary.
Ellison, the difference between 37Hz and the 55Hz we were getting with the 18ms frame width is completely meaningless. It *might* have been meaningful if this was a high performance, fully manually controlled aircraft, but it's not. The microcontroller does the flying, we just give it directions. And giving those directions at 37Hz is more than enough. We could probably drop to 10Hz without having a real problem.
The human brain can't even sense, process, and respond to inputs at anything like 10Hz. The only real benefit to the higher frame rate is the lag time at the turning points of the control inputs. ie: driving an RC Touring car at 60mph on a track 5 feet wide, the lag time can become significant, as it requires the operator to predict the lag time, and input the command at a predetermined point before you actually want it to turn.
A touring car doing 60mph is doing 26 m/s. Or 2.6 cm per ms. With a frame width of 18ms, it will travel 46.8 cm per frame, or 18". So you have 18" variability to a step-function turn input, depending on if you catch the nearest frame, or have to wait for the next. That makes a big difference when trying to do a 90° turn on a track 5 feet wide!
This is why people in the RC world are concerned about frame rates. Changing to a 27ms frame would mean 28" of variability! Dropping to 9ms would drop the variability to 9"! A huge advantage in controllability in top level racing.
But we are not controlling touring cars, or doing pyro flips 2 feet off the ground. We are controlling UAV's.
37Hz is fine.
Besides which, you must have missed the point about having a hardware restriction. For whatever reason, the hardware can only do the framewidth in multiples of 9ms. 9, 18, 27, 36...
18 isn't working, obviously can't do 9, 27 is plenty.
Why would we get all worked up about 55 vs. 37Hz input updates, when the motor controllers are only updating at 50Hz anyway.
I'm also not a huge fan of forging off on some new PPM reading scheme that is fraught with danger. The 4ms sync pulse works. It has worked for a long time. If you want to develop something new, better faster, great. I'll be onboard *after* you've proved it out. I'm sort of getting tired of chasing problems, so will minimize the risks when I can.
At this point however, given the choice, I like the 37Hz thing.
@PX4: I think the suggestion is that there still is the sync pulse, but once you have sync'd you can tranisition to a pulse counting technique. i.e.. you time the 400us pulse and know the next is a the channel, and you do that for a count of nine. If the ninth pulse is >4ms you 'hard-sync' as you really do know it was a sync pulse if <4ms, it's a soft sync. If less 2ms (since we have an 18ms frame window) the world has gone wrong.
Obviously, the challenge here is, is the complexity worth it for this edge case, or as others have suggested, maybe falling back to failsafe when the sync pulse is lost
@PX4, as we we're discussing before this "solution" from FrSky. We are in a fault state, when all controls maxed out has caused the CPPM frame to squeeze out the the SYNC pulse. The point is that we need to add code to handle signal faults. Our software should take some kind of failsafe, if we are getting insane input. This will eliminate the need to accept the Frsky experimental firmware to increase the frame size to 27ms. There is no need for it.
-
8
-
9
-
10
-
11
-
12
of 21 Next