Pierre's 170W in 1600W out Looped Very impressive Build continued & moderated

[TinselKoala]

polarity of the test aparatus magnets doesn't really matter...  at 5:45, he's putting a magnet back on.  he first matches it to the other magnet (they breifly attach) so he puts the magnets back on with opposing poles.  (  S-N  ... N-S ) on the other side.  I guess that's why he has such a problem putting it back on... in the 2:30 range, as soon as he takes it off, the rotating part tries to rotate, trying to bring the south to meet the N that's off now...




That video does have the wipe; someone said 'charges to 25V in 30 seconds' but there's no knowing because between 10-25.1V is cut. ( at 3:28)(yes, charaging starts at 2:58 so... 30 seconds of film time; but it only goes up to (4.5-10.4) (6V in 30 seconds, so would be another 3 minutes (more because the rate slows) )


----
The LEDs never show a skip....
I guess at 1RPS (60RPM) it's really   1000/36  or 27ms per click ... every 250ms seems to be a lull; but 250 isn't really a harmonic... so I'm not sure why there's a lull...

Yet look at Pierre's original Arduino sketch, and count the number of "delay()" statements between turning a pin HIGH and turning that same pin LOW, for each pin.

I think this is the point T-1000 is making in his post above where he lists some of the lines from the sketch. Count the delay(x) statements between turning a pin HIGH and then turning it LOW.  The pins do not all get the same total "delay" or ON time.

[partzman]

http://overunity.com/login/
polarity of the test aparatus magnets doesn't really matter...  at 5:45, he's putting a magnet back on.  he first matches it to the other magnet (they breifly attach) so he puts the magnets back on with opposing poles.  (  S-N  ... N-S ) on the other side.  I guess that's why he has such a problem putting it back on... in the 2:30 range, as soon as he takes it off, the rotating part tries to rotate, trying to bring the south to meet the N that's off now...




That video does have the wipe; someone said 'charges to 25V in 30 seconds' but there's no knowing because between 10-25.1V is cut. ( at 3:28)(yes, charaging starts at 2:58 so... 30 seconds of film time; but it only goes up to (4.5-10.4) (6V in 30 seconds, so would be another 3 minutes (more because the rate slows) )

Actually, what I said was quote-

"Well, I see that the videos are once again removed so I can't refer to the first video when Pierre shows the charging of the supercaps from 4.64v to 10.4v over a ~32 second period."

Regards,
Pm

----
The LEDs never show a skip....
I guess at 1RPS (60RPM) it's really   1000/36  or 27ms per click ... every 250ms seems to be a lull; but 250 isn't really a harmonic... so I'm not sure why there's a lull...

[d3x0r]

Yet look at Pierre's original Arduino sketch, and count the number of "delay()" statements between turning a pin HIGH and turning that same pin LOW, for each pin.

I think this is the point T-1000 is making in his post above where he lists some of the lines from the sketch. Count the delay(x) statements between turning a pin HIGH and then turning it LOW.  The pins do not all get the same total "delay" or ON time.

Ya; ... 30fps is 33.33ms(or less, is it 24fps video) ... and cycle delay is something like 27... so
Audio channel does actually have better data...
I'm kinda rusty on isolating clicks (there's lots of pop and click removers, not many amplifiers... which I guess is remove them, then subtract the result from the input... kinda like work.
Spectra analysis doesn't give good time resolution; but would think a pop would be a wide-spread high FFT. 


(turned sideways to not overflow message width)


but 'low' is off.  it's not reverse. 
'high' is on.  and the opposite coil also (in reverse)
so his coils are running in parallel.


Edit: Replaced image with just 1 second, so more than 1 pixel per millisecond... 250 millisecond spans.
I noticed in the other video with the cycle counter that the pitch had changed... I wonder if this is running to 50Hz instead of 60?

[TinselKoala]

Nicely done! You can clearly see the long interval followed by a short interval, happening every 12 "clicks".

So is this deliberately done, or is it an easily made mistake in the original Arduino sketch (which was clearly written
by someone with very little Arduino or c++ experience)?

If it is deliberate, what is the rationale behind this "stutter" in the smooth sequential "rotation" of the superimposing fields?

If it's a mistake, I think several "corrected" versions of the Arduino code have already been posted.

But is LUC now using the Propeller board, which I think uses a version of BASIC? Does Luc's program also have this little stutter?

[pmgr]

Funny that the image shows that he wants to solve the problem with 4 poles instead of 6.  In order for him to do this he would have to replace each coil to a 9 pole bridge instead of his 6.  Always look at the pattern.  For a 4 pole to work correctly, you would need to trigger 9 coils in series with a bridge gap of 9. Do you see his pattern?   This means we might have problems doing our setup with the same bridged poles as the 36 pole.  It should be 5 to match his same configuration.  [size=78%]I beginning to realize why the overlap in coil windings will be a problem.  I can see how his new configuration will work better!

I also believe we could do this method of pulsing on a toriod completely solid state. 

I was also able to place the priming sequence of coils to visualize the arrangement.  My original post had a wrong pin number, 14 should have been 13.  The reason for this PIN change is because all odd relays are on the outside and even relays are on the inside.  See image.  I still don't understand why he is priming the entire stator prior to sequence.  Maybe this image will help others.   

Jerdee

Jerdee,


Regarding the hold sequence, I don't believe there is one (at least not on purpose). It is not part of the original sketch Pierre provided. The facts that some pins are high initially, is most likely because the Arduino enters the bootloader first which will probably have some pins set to high to communicate with outside world or on board peripherals.


Pin 1 is a TX0 output pin (serial port).
Pin 13 is a PWM pin
Pin 20 and 21 are SCA and SCL pins which are I2C pins


PmgR