Rosemary Ainslie circuit demonstration on Saturday March 12th 2011

[poynt99]

hi Rosemary

if 4 out of the 5 MOSFETs are merely providing (rather unconventional) feed back to Q1 gate, how many are actually needed to achieve the same effective results (eg. as March 12)?  does it still work with, say: 4? ..3? ..2? ..1?

also, does any other particular number of 'feedback' MOSFETs appear to give a better result than 4 of them?

thanks
np


http://docsfreelunch.blogspot.com

In my simulation, going from 4 mosfets down to 1 mosfet in pseudo-parallel with Q1, the Fo changes from ~1.3MHz to ~1.8MHz, and the P-P voltages increase about 25% or so. This make sense to me.

I'm currently looking for my spare IRFPG50, but so far I can't find it. I am pretty sure I bought 2 when I was putting together GL's PCB to test the previous version of this project. If I can find it, I might try the two in psuedo-parallel and see if I can get the oscillation.

.99

[poynt99]

Further to the changes mentioned above, the net MEAN CSR voltage goes from ~-35mV to ~-55mV.

This of course would seem to indicate more current going back to the source battery with one mosfet compared to 4 mosfets in psuedo-parallel with Q1.

.99

[poynt99]

Briefly once again looking at the CSR placement, we see from the IR datasheet for the IRFPG50, that they are placing the CSR outside the Vgs loop. This avoids the possibility of the Gate drive interfering with the current measurement.

It also eliminates the appearance of the CSR voltage on the Gate drive, which can modulate it and cause instability. This is usually only a concern if the CSR resistor value is relatively high, or it exhibits significant inductance, or if the Source current is relatively high.

.99

[neptune]

@poynt99 .You seem to have missed my earlier question . Does the result of your simulation lead you to believe that the Rosemary Ainsle Circuit is overunity . In other words , that it provides heat output whilst recharging the battery .If you are busy , a yes or no will suffice .

[Rosemary Ainslie]

the gist of 'evolvable' hardware is simple enough. the configuration bits that program the wiring and circuitry of the fpga become the 'chromosomes' of the individuals to undergo the trial of survival of the fittest. the chip is configured, then set to do some task (like applying various settings at the gate, or something else), and its performance is measured. then the bit streams representing the best-performing configurations are mated together, mutations are added, and new individuals are tested, measured, and either discarded or mated. eventually, a configuration should emerge that’s very good at accomplishing a specific task, albeit might take thousands of generations to appear.

the beauty of it is, that you can use the fpga's as blank evolutionary 'slates' and let evolution fiddle around with the fine details. ie: you can create without any preconceptions built in. so, it’s not told anything about what is 'good' and what is 'bad' or how it achieves the behavior. evolution just plays around making changes, and if the changes produce an improvement, then fine. it doesn’t matter whether it’s changing the circuit design or using just about any weird, subtle bit of physics (note: this doesn't work on the simulation fpgas, only hardware fpgas) that might be going on. the only thing that matters to evolution is the overall behavior. this means you can explore all kinds of ways of building things that are completely beyond the scope of conventional methods. allow evolution to write all the design rules.

i hope that helps elucidate, i can be rather terse at times and expect people to 'see' what i see. it's a character flaw.

Hi Wilby.  This sounds really interesting.  I'm afraid I'm absolutely not equal to this.  But if you or anyone else is - then I think we'd all be riveted.  How fascinating.  Sort of allowing chance to determine an optimised design.  I see now why you refer to it as 'evolving'.  How extraordinary.  Let us know if you can rally the right expertise.

Kindest regards,
Rosie