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

[pmgr]

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?

Pierre's code has 24 times delay(x) in it. Your total scan is about 250ms for this, so his x value is about 10ms. This means his relays stay on four 3*delay(x)=30ms, then off for 210ms. Frequency is around 4Hz (250ms).

PmgR

[d3x0r]

Pierre's code has 24 times delay(x) in it. Your total scan is about 250ms for this, so his x value is about 10ms. This means his relays stay on four 3*delay(x)=30ms, then off for 210ms.


PmgR

total scan is 1second - or 4 250ms sections.  Previously it was like 3 seconds (before edit)


yes; but that only results in 12 on events.  (and 12 off)



There is a short spike between most peeks which is probably the release. 
There is a bit of chatter too... it's not a sharp snap...(but that's what relays do)


but the engage is typically louder than the release.


(that is the same as(it didn't change during that video) frequency used to run the microwave and drill; although it was only shortly after turning on, there was a lull in the background )music.)


---


I do think the long space before blue lines(250ms) (image was rotated clockwise, from time left to right to time top to bottom) Uhmm ya the space is 2 Off's followed by 2 quick On's.In the Working live demonstration; I do not think that is a bug, but that there is a time of no lights on that the video does not show. (but original code and audio do)
Having the ability to instantanously remove the magnet from a generator is unique to this scheme.


I also think it could be optimized to just cycle the poles over the collecting coil  (that in 6 poles the sides don't actually play that much role). (less power for coils that don't do much)
like only use (1-10) and (16-25) 1-12 and (16-27 or 18-29) and ignore the other 2 ....
(plus a span of 5 covers 1-17/ or a span of 4 on 30 coil cover up to 14   ...  a full half cycle walking through 12 coils (24 delays))

--------
This is more on the theory of this though; A magnet approaching a coil increases current in the coil... I guess a drive coil 'approaches' by having its current increase...  nevermind.

[d3x0r]

So... 4 poles... One would imagine N-S-N-S going around?  that makes opposite coils opposing polarity... and if it's N-S-S-N then it's really only 2 poles....
(N-S-N-S) but the mating flux is going to be from bottom to side and side to top; not trough the pickup coil...
Although there was that generator (probably years ago now) that was replaced rotor with permanent magents wound in coils?  that was 4 pole....
And flux-gate generators can be 4 pole... but the pickup coil is on the edge between magnets, not in the center.

[TinselKoala]

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

The sketch from Pierre certainly doesn't include any deliberate "hold sequence" on startup. But I also don't think that it is coming from the Mega's pin states at startup. My testing here hasn't shown any pin activations other than what is specifically called for in the sketch. As I posted previously I have occasionally had problems using pins 0 and 1 (the serial rx and tx pins) but this simple sketch didn't show problems when I tested it.
Also, on the Mega all pins from 2 to 13 are PWM capable using analogWrite() statements but the sketch is exclusively using digitalWrite() and again I haven't seen any spurious pin activations on startup here either.
Pin 13 does have an internal LED connected to it on Mega, Uno and other Arduino boards though. Here's something I found on an Arduino forum:

Due to the changes made on Rev3 Uno and mega boards the on board pin13 LED is not longer directly driven by the AVR output pin but rather 'buffered' via a spare op-amp stage. This results in a floating input pin condition for the op-amp which can result in the led being on when it shouldn't be, but it's a rather random thing as the offset input value of the op-amp plays a role. The only way to be absolutly sure that the pin 13 led remains off is to do both a pinMode(13,OUTPUT) and a digitalWrite(13,LOW), best placed in your setup function

My own Mega isn't a Rev3 version though.

[r2fpl]

Rotating field:

https://www.youtube.com/watch?v=0IKX8MeVQio