Encoder woes?
- Flynn
- Posts: 72
- Joined: 17 Feb 2018, 14:48
Encoder woes?
Hi all, I'm trying to bind a 4CH-FS2A micro Rx to a Flysky AFHDS 2A RM module in my 'Phil's encoder' equipped Futaba Gold and it isn't having any of it! I should perhaps mention I am not 100% sure the Tx module is good but I have come across another anomaly that has me stumped. The data stream coming from the encoder does not appear to be stable and I can't find out why. With the RF module removed and my scope attached to PPM and ground at the module connector I get this -
Edit, I hope you don't mind but I have put the video onto YouTube - Mike
Edit, I hope you don't mind but I have put the video onto YouTube - Mike
You only ever need two tools....WD40 and duct tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
-
- Posts: 748
- Joined: 16 Feb 2018, 14:11
- Location: Warwickshire
Re: Encoder woes?
Looks like you've not set the 'hold off' on your scope trigger. Set the hold off to be longer than the maximum servo pulse,
but shorter than the sync pulse. A setting of about 3 ms should be ideal. You'll find hold off in your scope's trigger menu - usually you have to use a manual trigger mode - hold off isn't usually available in auto trigger mode.
but shorter than the sync pulse. A setting of about 3 ms should be ideal. You'll find hold off in your scope's trigger menu - usually you have to use a manual trigger mode - hold off isn't usually available in auto trigger mode.
- Phil_G
- Posts: 629
- Joined: 15 Feb 2018, 23:32
- Contact:
Re: Encoder woes?
H Flynn, what are you using for your trigger? for a stable ppm display you need to trigger based on frame timing.
The video shows what you'd expect when its not synchronised to the frame, with the scope triggering on whatever
channel pulse happens to come next. My Siglent has a trigger-on-interval which when set to 3ms is great for ppm, rock solid.
For demo purposes I usually code in a pulsed trigger output on every sync pause, but of course its just
a waste of an I/O in a working encoder.
The video shows what you'd expect when its not synchronised to the frame, with the scope triggering on whatever
channel pulse happens to come next. My Siglent has a trigger-on-interval which when set to 3ms is great for ppm, rock solid.
For demo purposes I usually code in a pulsed trigger output on every sync pause, but of course its just
a waste of an I/O in a working encoder.
- Flynn
- Posts: 72
- Joined: 17 Feb 2018, 14:48
Re: Encoder woes?
Spot on Martin although my scope jumps from 1ms to 11 ms and the jitters stop at 11ms, except when I move to full throttle, then it needs 31ms to settle down. Phil's explanation made a lot of sense too.... triggering on whatever pulse came next, I was thinking it would only be triggered on the sync pulse because of a brain fart. I seem to be getting more of those recently!
Anyhow... now the encoder has been fully vindicated (we never really had any doubts did we!) I have a new Tx module on order
Thanks again.
You only ever need two tools....WD40 and duct tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
- Phil_G
- Posts: 629
- Joined: 15 Feb 2018, 23:32
- Contact:
Re: Encoder woes?
Thats fine but just be aware that 31ms will miss alternate frames
Doesnt matter as long as you're aware
I just had a thought, some Flysky modules need a standing-high-pulsing-low PPM stream (what we used to call negative-going PPM until the Kraft people showed us Kraft PPM pulsing below battery level!)
If that is the problem, a simple one-transistor inverter would solve that one.
Doesnt matter as long as you're aware
I just had a thought, some Flysky modules need a standing-high-pulsing-low PPM stream (what we used to call negative-going PPM until the Kraft people showed us Kraft PPM pulsing below battery level!)
If that is the problem, a simple one-transistor inverter would solve that one.
- Mike_K
- Posts: 686
- Joined: 16 Feb 2018, 06:35
- Location: Hertfordshire
Re: Encoder woes?
Or use a cheap USB logic analyser, you can get them for under £10 from AliExpress.
https://redirect.viglink.com/?format=go ... 4itemAdapt
The USB logic analysers have the USB-ID of Salea, so the Salea software can be used (I assume they are not genuine Salea products, but rip-offs), but can use the open-source PulseView software that is at least the equal of the Salea software,
https://learn.sparkfun.com/tutorials...less%20machine.
The advantage of a logic analyser over a scope is that they are 8 channels, 24MHz and can record many seconds of data (minutes even) if you have a fast enough USB port on your PC. It can decode many protocols such as serial, SPI and I2C, so can go far further than just ppm/cppm including s-bus. The only downside is they are 5V max input, so use a scope first to check the signal doesn't go negative and the pulses are not above 5V.
Obviously there is still a place for a scopes, scopes can display analog signals as well as logic levels and may be needed for any analog signal or to look at things like rise times on digital signals. But at these costs having both is a good investment.
https://redirect.viglink.com/?format=go ... 4itemAdapt
The USB logic analysers have the USB-ID of Salea, so the Salea software can be used (I assume they are not genuine Salea products, but rip-offs), but can use the open-source PulseView software that is at least the equal of the Salea software,
https://learn.sparkfun.com/tutorials...less%20machine.
The advantage of a logic analyser over a scope is that they are 8 channels, 24MHz and can record many seconds of data (minutes even) if you have a fast enough USB port on your PC. It can decode many protocols such as serial, SPI and I2C, so can go far further than just ppm/cppm including s-bus. The only downside is they are 5V max input, so use a scope first to check the signal doesn't go negative and the pulses are not above 5V.
Obviously there is still a place for a scopes, scopes can display analog signals as well as logic levels and may be needed for any analog signal or to look at things like rise times on digital signals. But at these costs having both is a good investment.
-
- Posts: 332
- Joined: 31 Jan 2019, 11:48
- Location: Boskoop, Netherlands
Re: Encoder woes?
- Flynn
- Posts: 72
- Joined: 17 Feb 2018, 14:48
Re: Encoder woes?
Thanks for that thought Phil and that link Max. That's fixed it. following F2B's suggestion about altering the ppm frame format to give negative going pulses (and re-calibrating the sticks) it all works now.
Now, of course, if I fit a different module I will have to re-flash the nano back to positive pulses.... be nice to have a jumper on a spare IO to facilitate the change.
You only ever need two tools....WD40 and duct tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
- Phil_G
- Posts: 629
- Joined: 15 Feb 2018, 23:32
- Contact:
Re: Encoder woes?
On the 7ch + S/C mix encoder its one line:
Code: Select all
#define onState 1 //set polarity of the pulses: 1 is positive, 0 is negative
- Flynn
- Posts: 72
- Joined: 17 Feb 2018, 14:48
Re: Encoder woes?
OK. I guess I must be using an older version and this is something you added later because that #define doesn't exist in the sketch I'm using ....or do you mean if I add that line to the existing unmodified sketch it will invert the ppm pulse train? This is the post from F2B that seemingly fixed the issue for me -Phil_G wrote: ↑05 May 2024, 00:23 On the 7ch + S/C mix encoder its one line:
Code: Select all
#define onState 1 //set polarity of the pulses: 1 is positive, 0 is negative
```
Then I changed this line:
//send ppm frame, last channel holds sync value
for (int ch=0; ch<7; ch++) {digitalWrite(ppm, HIGH); delayMicroseconds(ppmPulse); digitalWrite(ppm, LOW); delayMicroseconds(channel[ch]);}
into:
for (int ch=0; ch<7; ch++) {digitalWrite(ppm, LOW); delayMicroseconds(ppmPulse); digitalWrite(ppm, HIGH); delayMicroseconds(channel[ch]);}
and all sprang to life....
```
What a great piece if software by the way...
You only ever need two tools....WD40 and duct tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.
If it doesn't move when it should use the WD40 and if it moves and it shouldn't use the tape.