Go Down

Topic: Interfacing to Radio Conrol Receiver (Read 502 times) previous topic - next topic

rtdgreg

I have been collecting PWM signals from the Radio Control receiver of an Ikonnik KA-6 six channel proportional system.  All was well.  Standard servo control outputs are 1msec ± 500µsec.  I discovered that leading edge of channel 2 coincides with trailing edge of channel 1, leading edge of channel 3 coincides with trailing edge of channel 2, etc.  So I could feed channels 1, 3 and 5 into a 74HC4002 2*4NOR gate, and the output of that to ICP1.  That gave me a time stamp for each state change on ICP1, with an interrupt to collect this at leisure, and at least 500µsec to do it.  I could measure pulses accurate to 500nsec with a 16MHz Arduino, which was just about perfect.

I have just bought another KA-6 receiver, and it doesn't seem to behave the same.  Although the new one looks the same as previous one, the leading edge of all servo drive signals seem to occur at the same moment, so I am faced with a struggle to time stamp the pulse edges.

I realise I can use something like a multi way <and or invert> logic gate, but wonder if anyone on the forum has come across this.  I would rather simply buy another receiver that behaves like the first, but I rather think it's an undocumented feature.

Do any of you know if it's now normal, or at least, common for the radio receiver to send all servo drive pulses at the same time, not sequentially?

Robin2

I have just bought another KA-6 receiver, and it doesn't seem to behave the same.  Although the new one looks the same as previous one, the leading edge of all servo drive signals seem to occur at the same moment, so I am faced with a struggle to time stamp the pulse edges.
What are you trying to do?  Describe the project so we understand the context of your questions.

If you feed each receiver channel to a different Arduino pin can't you deal with each of them separately?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

rtdgreg

#2
Jan 15, 2018, 02:10 am Last Edit: Jan 15, 2018, 09:34 pm by rtdgreg
As I understand it, the Arduino has just one capture interrupt.  The current count is staticised at the moment of a pulse edge.  That's accurate to 0.5µsec.  Pretty good.  Sorry, earlier I said pulse duration is 1msec ±500µsec.  It's actually 1.5msec ±500µsec.

If I hang receiver outputs onto separate Arduino inputs, then the timestamp I staticise is not the moment of the edge, but that time plus interrupt latency.  Whilst execution time from commencement of interrupt servicing routine to capturing its time may be deterministic, time from the edge that stimulates the interrupt to commencement of the servicing routine is not.  If all leading edges happen at nearly the same instant, the servicing may well be sequential.  Basically, it comes down to accumulation of errors.  The more of them that happen at the same moment, the more delay is introduced between pulse edge & reading the time.

Maybe I was lucky with my first receiver.  Since the pulses stacked end to end, I could accurately stamp the time of each edge from a hardware counter, and leave the interrupt servicing routine to collect those time readings.

I don't see how I can measure six different pulse lengths to an accuracy of 0.5µsec if I feed the radio outputs to separate Arduino input pins.  ICP1 is unique and special in that counter is captured for the moment of the pulse edge.  This can be read at leisure, comparatively.

I think the point I was trying to make is that two apparently identical receivers behave quite differently.  With the former bahaviour I can measure many pulses very accurately.  With the new behaviour, I can't.  I don't know if most receivers put out all the pulses at the same time, or if most send them out in an orderly sequence.  I would value the benefit of other forum members' experience.  A trouble is that this feature does not appear as part of a receiver specification.  I am trying to avoid random purchase in hopes of getting a sequential flavour receiver.

But, Robin2 - if I have misunderstood your message about delivering the pulses to separate Arduino pins, and I can capture the time for both ends of all channels to a reasonable accuracy (as opposed to resolution), then I would welcome your thoughts.  It has occurred to me that I could effectively sit in a tight loop with interrupts disabled once the leading edge is detected, and stay in that state until all pulses have completed, but I really think I would struggle to get anywhere near my 0.5 or even 1µsec accuracy.  These pulses repeat about every 19msec, so, I just might be able to get away with hogging the processor for 2msec every 19msec.  But it does go against the grain to block interrupts for that long.

Robin2

But, Robin2 - if I have misunderstood your message about delivering the pulses to separate Arduino pins, and I can capture the time for both ends of all channels to a reasonable accuracy (as opposed to resolution), then I would welcome your thoughts.
You still have not told us what is the purpose of all this - without that background it is very difficult to make sensible suggestions. You know a whole lot more than the stuff you have shared with us.


I have been assuming that each receiver channel would go to a separate pin and you would use pinChange interrupts to catch the times of the changes.

If, as you say, all the pulses start at the same instant then you only need to capture that once.

What is the maximum acceptable error (in microsecs) in the measurement of the width of a pulse?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

rtdgreg

#4
Jan 15, 2018, 01:02 pm Last Edit: Jan 15, 2018, 01:08 pm by rtdgreg
Thanks Robin2 for your contribution to the discussion.  Let me answer your last question first.  I guess the answer is 2µsec.  The pulse is between 1000 & 2000µsec resolved to 4µsec, so measurement resolution should be at least twice as good as that.  Given that the pulse has two ends, that means accurate to 1µsec at each end.

Going back to your first sentence - "what is the purpose of all this?" - I am struggling to expand on what I have said already.  I'm sure it's a diversion to go into the "business logic" of how that information is used after it's gathered, but basically radio control gear is telemetering six off eight bit values at a repeat rate of 50 samples per second.

Either I have not understood the pinChange interrupt, or you have not understood what I have been writing about interrupt latency.  I would really like to shake that out.  I have been using Arduino Uno, Nano and Pro / Pro Mini.  They all have Atmega 328 processor.  That has one 16 bit counter, and only one external pin to transfer current value to a holding register.  Please correct me if I'm wrong.  I haven't played with Mega, and don't have one to hand, but it may have more.

Actually, if I did say they all start at the same time that was a mistake. The problem is that they all start at close to the same time and can finish close to the same time.  That may mean that they can start or finish at the same time, but it doesn't mean that they do necessarily start or finish at the same time.

Isn't it true that if I use pinChange interrupt, I can only get a time stamp using some code of the interrupt servicing routine that's stimulated by the pinChange event?  The time relates to when the interrupt servicing routine executes, not the state change on the pin.  The variability of elapsed time between the two is the issue.

From observation on my oscilloscope, if I "OR" the receiver outputs the result brackets all individual channel pulses.  Pulse length is variable, but not greater than 2.4msec and it should not be less than 1msec, because any contributing pulse shouldn't either.  These pulses come along about every 19msec.  I could use an "and or invert" eg 74HC4086 gates to measure, say channel 1 at first cycle, channel 2 on the next, etc.  I would then get around my 6 channels in 6 * 19 = 114msec - so I'm telemetering updates at about 9Hz.  Alternatively, I could commit a separate Arduino to each channel & get them to talk to each other, or I could do something in between. Two Arduinos could get around the cycle in 57msec, 3 could in 38msec.

My disappointment is that the old receiver delivered a nice train of pulses that I could easily and accurately measure to about 500nsec.  I'm pretty sure that pre 2.4GHz transmitters sent a train of PWM pulses, and their receivers did the same.  My first 2.4GHz receiver delivered this train.  My next receiver, which looks identical, doesn't.  Ideally, if it's still common practice to deliver individual channel outputs from the receiver sequentially, I just want to get another receiver which does that and scrap this "orphan" receiver.

Robin2

Going back to your first sentence - "what is the purpose of all this?" - I am struggling to expand on what I have said already.  I'm sure it's a diversion to go into the "business logic" of how that information is used after it's gathered, but basically radio control gear is telemetering six off eight bit values at a repeat rate of 50 samples per second.
It seems a waste of my time trying to assist when you are not prepared to describe you project. Nobody captures receiver pulses measured to +/- 2µsecs just for fun.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

rtdgreg

#6
Jan 15, 2018, 04:52 pm Last Edit: Jan 15, 2018, 05:06 pm by rtdgreg
That's the nature of standard servo interface specification.  It's a repeating PWM pulse, 0% is indicated by a 1msec pulse duration.  100% is indicated by a 2msec duration pulse, and it's linear between those limits.  2µsec error represents 0.2% of full scale error in transmission of a measurement.  If I'm down at 10% full scale, that becomes 2% of the measurement.

I would welcome your thoughts on a what is a reasonable level of repeatability of the reading in response to a constant signal of, say half scale - 500µsec.

What repeatability would you expect using pinChange?  I have said the issue is interrupt latency.  If I am wrong, can you put me right?  You asked me what I wanted.  I believe I have answered that and justified my answer.  What repeatability would you expect from a pinChange solution?  I'm not sure where pinChange interrupt sits in priority order, but I think you have to allow for aggregate execution of all higher priority hardware interrupts between the physical state change that triggers the pinChange interrupt and capture of the its timestamp.  Please tell me if I'm wrong.

Clearly, I have been able to achieve significantly better than my target 2µsec accuracy with old receivers.  Clearly, I can continue to achieve that with a multiplicity of Arduinos. 

You have suggested an alternative strategy.  That's great.  I haven't tried it, but I would welcome your thoughts on the likely trade off.  How much accuracy do I lose, if any, by using pinChange?  I believe the answer depends on execution time for the sum of all higher priority interrupt servicing routines plus the longest lower level interrupt servicing routine.  That's the measure of the worst case extra delay.  Do you agree?

Maybe I could exclude outliers somehow, but then I need to think about design of an algorithm to do that.

Did you look at the picture showing the contrast between old style and new style timelines?  I think you understood that without the picture, but it might help some.  I have attached it again in case you didn't & want to.

http://forum.arduino.cc/index.php?action=dlattach;topic=522652.0;attach=241303

Robin2

Please re-read Reply #5

if you don't wish to explain your project then, with a bit of luck another contributor will come along to answer your questions.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

rtdgreg

Thank you Robin2 for your interest in and contributions to this thread.

May I remind our readers that I was not asking for help to solve a programming problem.  Referring back to my original post, my question was:- "Do any of you know if it's now normal, or at least, common for the radio receiver to send all servo drive pulses at the same time, not sequentially?"

I was hoping to tap into the experience of readers who know about radio control model receivers.

I think it's a pity that the thread sank to repeats of "if you don't wish to explain your project".  I really thought I had done that, and that was hard enough.  If you're aiming to put a man on the moon & you want a nut and bolt, how far do you explain your project to the nut & bolt expert?

Robin2

my question was:- "Do any of you know if it's now normal, or at least, common for the radio receiver to send all servo drive pulses at the same time, not sequentially?"
If all one wants to do is control a model airplane or a model boat with an RC system then this is a completely irrelevant question.

Consequently I think it was reasonable for me to assume you have other plans.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

rtdgreg

Indeed.  You just connect the radio receiver to servos & electronic speed controllers.  You can buy them off the shelf.  Nothing to do with Arduinos.  Your assumption is correct, but I don't see the relevance.

The bought in item is a mass produced radio receiver.  I want to collect the outputs from such a receiver into one or more Arduinos.  I discovered that the receiver I have sends PWM pulses concurrently, whereas earlier ones sent sequentially.  I wondered if anybody else is aware of this.  I don't know that anybody on this forum is.

I find it a bit curious that there's nobody saying "Yes, receivers are all like that nowadays" or "That's unusual.  The ones I have send their pulses sequentially".

Nevertheless, I think I have answered all the questions that you have asked me, but you have not answered any of the questions that I asked you, and nobody else on the forum has provided answers to any of those questions either.


Robin2

I find it a bit curious that there's nobody saying "Yes, receivers are all like that nowadays" or "That's unusual.  The ones I have send their pulses sequentially".
Perhaps you need to ask on a Forum that specializes in RC equipment. This Forum specializes in Arduinos.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up