Yet another Single Channel Encoder

Button pushers
Post Reply
Mike_K
Posts: 241
Joined: 16 Feb 2018, 06:35

Re: Yet another Single Channel Encoder

Post by Mike_K » 14 May 2019, 07:36

Hi Martin

Thanks for the advice. I did some tests with OpenSCAD last night and I can generate STL files with errors by just touching two parts together, not overlapping them as you suggested. The errors disappear once things overlap. Interestingly I checked the STL files for the enclosure base and body online that I had already printed OK and found they all had errors as well.

I then started a test print last night of a small piece of the lid, that had completed this morning and yes things are a lot better, but still not perfect. So I've re-checked what the smallest x/y resolution my printer can do and I'm probably expecting too much from it. So now I need to go through the complete .scad file and ensure everything overlaps and then get it commercially printed, probably by a different process to our FDM.

-------------------------

Frank

Thanks for the offer, but I hope you don't mind if I decline for the moment., The OS Pixie MK2 case has been my personal challenge for the last year or two and I really want to complete it on my own, I'll happily take advice, but I would like to finish it without outside help if possible. I now understand why I'm generating STL errors, I just need to go through the complete .scad file and make sure everything overlaps then try again. But I will definitely share the .scad and STL files once it's complete.

MaxZ
Posts: 130
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: Yet another Single Channel Encoder

Post by MaxZ » 18 May 2019, 15:38

Hi all,

Today, I have successfully flown the Tomboy on S/C! Two flights, both on the umbilical cord with my propo Tx. The start of the first flight was still on propo, the second on S/C from the start. Propo interventions were minimal.
I am still struggling with the throttle blips though, especially on landing. I misjudged the second landing and managed to put it down in the only water filled ditch from the ones surrounding the field. Well, mostly in the reeds with just the nose touching water. No further damage occurred, so a dry out will see it flying again. :D :D

Cheers,
Max.

User avatar
Wayne_H
Posts: 280
Joined: 17 Feb 2018, 05:26
Location: Temora, NSW. Australia
Contact:

Re: Yet another Single Channel Encoder

Post by Wayne_H » 19 May 2019, 01:01

Well done Max ;)
Cheers,

Wayne
Once a Retrobate, always a Retrobate............ :roll:

MaxZ
Posts: 130
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: Yet another Single Channel Encoder

Post by MaxZ » 25 May 2019, 10:13

Hi Mike,

Don't know if you have read about my problems with the Flysky RF module ( viewtopic.php?f=62&t=695), but I have a hunch that the 4 channel format of the ppm stream is the culprit. Preliminary testing with a 6 ch source has shown some improvement, so I have modified your sketch to a 6 channel output. Can you please check and confirm that the changes below are all that is required, and I have not overlooked anything?
Schermafbeelding 2019-05-25 om 09.40.10.png
Schermafbeelding 2019-05-25 om 09.42.47.png
(the vertical line after the "6" is the cursor position)

Cheers,
Max.

Edit: Something must be wrong, Phil's pulse analyser shows a single pulse and a frame rate of about 25 ms.
Edit2: I found an error in line 658, "i < 4" should remain as it was. I'll test it again later, I am going out to fly something now :D
Edit3: error corrected, but result does not change, still a single pulse (about 670 us) and 25 ms frame rate.
Last edited by MaxZ on 25 May 2019, 15:05, edited 2 times in total.

MaxZ
Posts: 130
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: Yet another Single Channel Encoder

Post by MaxZ » 25 May 2019, 14:39

Phil_G wrote:
25 May 2019, 12:59
Hopefully not with botched code Max!
No,no, I flew my mini-Mustang with a regular Turnigy/Flysky i6 tranny.
Phil_G wrote:
25 May 2019, 12:59
the RM002 is absolutely fine on 4 channels and I would expect the RM003 to be the same...
I hear what you say, but it's got to be something. No harm in seeing what a 6 channel does to it. Your Pulse Analyser is doing overtime.....what would I do without it :D :D

Cheers,
Max.

Mike_K
Posts: 241
Joined: 16 Feb 2018, 06:35

Re: Yet another Single Channel Encoder

Post by Mike_K » 25 May 2019, 20:51

Hi Max

I'm away from home this weekend and only have my phone, so it isn't so easy to look through Arduino sketches. I didn't have a copy of the sketch, so I've downloaded it from this forum. One thing I noticed in your code alterations is you hadn't increased the variable array size, it now need to be:

67. volatile unsigned int outputValue[7]; //define array size to number of channels + 1 (for the sync pulse)

Try that and see if it fixes it.

Mike

MaxZ
Posts: 130
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: Yet another Single Channel Encoder

Post by MaxZ » 26 May 2019, 09:56

Hi Mike,

Pretty basic stuff, I should have found that, duh.. :oops: The code now generates a nice 6 channel ppm stream.

Thanks, cheers,
Max.

User avatar
F2B
Posts: 76
Joined: 16 Feb 2018, 11:23
Location: 20 m NE of Amsterdam

Re: Yet another Single Channel Encoder

Post by F2B » 02 Jun 2019, 08:45

Hi all,

Max and I got together yesterday at our first 'vintage radio assist' meeting in 2019.
We tried Max' module in my JR X-388S tranny and the whole thing instantaneously sprang to life...
All worked with good range.
We both suspect the culprit is in the format and this FlySky really needs a 9ch. input.
I think Max Will try that next and I expect him to report here when done do.

Bruno
F2B or not to be....

MaxZ
Posts: 130
Joined: 31 Jan 2019, 11:48
Location: Boskoop, Netherlands

Re: Yet another Single Channel Encoder

Post by MaxZ » 02 Jun 2019, 11:06

Hi all,

Yes, and at that same VRA meeting I have had my first experience with flying solo (i.e. no backup) on S/C. I flew my Tomboy, with Multiplex M-Link module and -receiver as a replacement for the problematic FlySky module. The flight was a mixed succes, initially all went well, then suddenly the plane rose higher and higher. Since conditions for thermal activity were ideal, judging by the many flyaways at the FF competition which was held at the same time, and my experience on a previous flight with a different plane, at first I thought I had hit the big one. But then it dawned on me that I must have inadvertently switched on the motor, and a blip on the button while carefully listening to the pips emerging from the Tx confirmed that such was indeed the case. From then on I was struggling to control the flight, which eventually led to a landing between the trees, luckily without serious damage.

On hindsight, I think I must have not pushed the button long enough for small right rudder corrections, which were then seen as input for throttle changes. I must add that the rudder response was rather fierce, despite earlier trials to assess the correct travel settings, so I tend to let go of the button too soon.
I have been searching the code to see where the discriminating timing between throttle and rudder inputs is set, but have not found it. Mike, can you help me?

On the module subject, I would be surprised if the 9-ch version is the solution for my module problems, but I want to try it anyway. I have prepared a 9-channel version by adding a total of 5 neutral (1.5 ms) pulses. I have put them in the "outputValues()" routine, where the other value setting takes place, but I wonder if it is worthwhile to put those in the setup to avoid longer processing times.
To be continued...

Cheers,
Max.
Last edited by MaxZ on 02 Jun 2019, 11:44, edited 2 times in total.

User avatar
Phil_G
Posts: 295
Joined: 15 Feb 2018, 23:32
Contact:

Re: Yet another Single Channel Encoder

Post by Phil_G » 02 Jun 2019, 11:29

Hi Max, back in the day it was essential to practise with the cadence of an escapement, initially you would get many wrong commands but you adapt to the rhythm eventually and mis-keys become less frequent.
Please take this suggestion as a positive thing, I only want to help, not criticise. I think Mikes encoder was probably doing exactly as you told it, quick blips are quick blips whether intended or not.
The crux is that I know that a lot of time & effort goes into emulating an escapement as accurately as possible, and to me altering the code would be the wrong approach. Competent S/C flying takes practise and distorting an accurate emulation would (I feel) negate all of Mikes efforts. What with the elevator corrections on throttle changes I feel we're losing the simplicity of S/C and its recreation. Just my 2p Image
Cheers
Phil

Post Reply