[SOLVED] I found out the servo is discontinued. I think it has flaws in its design. I can't explain why it sort of works (only one direction) from the USB thing and does not from the expansion board, but I got 2 different newer winch servos and they work great in both directions from Onion and my USB thing, so it has to be a faulty servo. I have a feeling it had a 1 to 3 turn limit before breaking a cog if it driven past that, then once the cog is broken the pot doesn't return the right values and its all screwed up. Anyway the expansion board seems pretty bullet proof for noise and EMI EMF, I man handled it pretty good.

@ccs-hello Thanks ccs-hello. I drive it with the polulu USB servo thing and works fine. I've used batteries to drive the thing. You can't get much cleaner than that. I'm pretty sure its not noise or power issues. This is really old tech (servos and drivers) this stuff works in some of the worst environments like in an RC airplane.

I just got a new 2+ and same relocate error. Has this been solved? Is there a fix? WTF? this is a year later, you would think they test these things before shipping. I also got a onion 2 at the same time. It was tested because the pins were bent from de-insertion. The pins were straight on the 2+. Not saying they didn't, but sure looks like its not tested. I Always order at least 2 of everything when I'm developing. Can't say how much time it has saved me but its huge.

@Andrew-Moore Oximoron thanks for helping and I totally understand what your saying. I might not have stated this properly but regular servos seem to work fine. I haven't looked at the expansion schematic at all, but I've done plenty of power designs and optocoupled i/o and other forms of decoupling. I think the microchip designed for controlling the pwm has decoupling, it should be enough. I don't think I need to look there yet. You right the grounds are probably connected but I really don't think its its back emf. The regular servos can chatter like crap and I can even crank them to cause back emf. It doesn't crash. Its only when I try this sail winch servo.

Just to make sure, I have a USB device from Polulu that controls servos from the desktop and I only works with an external; supply. It runs the servo continuously in one direction when I set it to approx. 1500 us pulse width at 20ms period. at below 500 us pulse width it stops rotating. Above 2500 us it maxes out at full speed. Its a little different than normal servos but still within the ability of the board. So I replicate those pulse widths using pwm-exp -p <port> 1.5 20(almost irrelevant). This will cause a 1500 us pulse width on the <port> , and works fine for regular servos, but crashes completely when sent to the 360 servo. BTW servo model is GWS S125 1T/2BB

I checked the levels on the pwm voltage lines, and it corresponds with my external power when plugged in, and Omega power when I don't plug in. Omega's supply is about 4.6vdc and I give it 4.99 externally.

Has anyone used a one of these things or even a hacked regular servo to spin 360 with the onion?

Thanks Again

@Oximoron I think that's done on the expansion board. Like I said I have used external power to the expansion instead of from the Omegas power supply. The documentation says they are isolated so I am assuming so.

Hi any help appreciated. I have been trying to use a sail winch servo that can spin 360 degree. I have also tried regular servos. The problem happens when I send a PWM signal using the web console app. The device crashes the dock and the onion based on certain values. Is this normal. I use external power supply but same results either way. I know I can send the servo past its edge and it will chatter, but thats not when it crashes. Once it crashes it will reset consistently until you unplug the servo. Then the device resets but the port on the PWM board no longer works. You have to then reset the whole board. So it sounds like the chip on the expansion crashes but doesn't get reset. So does anyone else see the same thing or is it just my expansion board.

Has anyone used a sail winch servo or hacked a regular servo to spin 360. If so can I see you code?

A few ideas from using the PWM console...
Servos just need a pulse width of somewhere between 900 to 1500 ms I think. Instead of using delay, duty cycle and frequency it would be much better to just enter the pulse width in ms. I know its so you can use it to dim leds and other stuff but the board is designed for RC type servos and 95% of us will be plugging in regular servos and just want to enter the width to figure out the exact numbers for each servo. Also in the PWM console you have to click outside of the boxes to make the page send the value to the device. Its a pain in the butt when the device starts chattering like its mad at you because of a typo.

Thanks Andrew

@ziger-zigs said in PWM flicker between pwm duty changes:

fast-gpio pwm

WOW over a year and no replys. I think its because fast-gpio pwm is software based and the cpu is interrupting its attempts to provide a clean signal

@Pavel-Metrokhin OK Thanks I never saw that tutorial. I think the problem is many versions of tutorials in different places, but this is good thanks.'

@Pavel-Metrokhin

Pavel FYI I followed the instructions for 'cross-compile C Programs' and I used the source repo exactly and the instructions did not say to wget the Makefile and it was not preselected in the .config so I still got the same errors with the ugpio headers when I tried to run the example at the end of those instructions. If you read the "more complex..." section from the link in your post above that I copied below, its says it will all be done if I used that source but I still had to creat the dir, wget the files, select it in .config and then make again. I wouldn't have been able to do that unless I found this post and the example compile would never have worked. Not sure if I did something wrong or its just been missed but thanks for this post, you might want to check the repo for the lib.

"...A Small but Important Note
We keep mentioning that the program will use the ugpio library. In order for this to be possible, the library must first be compiled by LEDE build system.

If you’re using our omega2-source Docker image or building based on our source GitHub repo, you’re all good as it’s selected for compilation by default.

If not, you’ll have to run make menuconfig in the build system to select the libugpio package to be compiled and then compile it by running make.
..."

@Maximilian-Gerhardt Perfect I actually ordered a few from digikey. Thanks Maxi.