Success..?

[MrVibrating]

..just cuz i ain't giff-bombed this page into a crawl yet, here's an updated version geared more towards what the rig's intended to measure:


200 Hz = fast, but poor MoI lock


..remember, it only looks like it's over-balancing..

..in reality, it's perfectly balanced whenever the green light's on! It's only able to accelerate when braking - and then, most of that acceleration is momentum being dumped from the weight axes - plus a fleeting moment of over-balance, but only while that red light's on..

Key points to note:

• input work by the motors is constant

This is because inertia is speed-invaraint - a 1 kg-m² inertia is always 1 kg-m², regardless of its current RPM. So motor work evolves linearly with respect to time - doubling the amount of momentum being generated only requires a doubling of input work / energy.

Thus the input workload is relative to - and resides within - the rotating reference frame.


• KE values of those braking counter-momenta are increasing with respect to RPM - the step heights are getting progressively taller, the more momentum is accumulated this way


This is because KE is only meaningful as relative to the external, 'ground' reference frame - and it squares with velocity!


Thus input and output workloads are in alternative FoR's, and their energies - the energy cost, and value of the motor workloads - scale differently with regards to velocity and time.


So the intention was to investigate whether this inherently-OU interaction could be decoupled from the GPE cost of sustaining the effective N3 violation in the first place - such as by varying the axial-to-orbital MoI ratio, spin-up and braking speeds etc., to look for any cracks in the wallpaper..


..because gravity is a time-constant rate of change of momentum, whereas the amount of counter-momentum we might sink to it per unit time may perchance be amenable to some degree of manipulation, which this series of measurements should be able to ascertain..

But only if we can get it to spit out reliable control runs first! Just a stable margin of error would be something - happy to drop down to three zeros displayed.. ATM tho it's near-zero here then 9 J there... forget about a signal above noise; the 'signal' is the noise...

We'll get there eventually..

[MrVibrating]

Apparently clear positive result:


1000 Hz, 1 i-s/f, 1e6 FFB, sprung timing, 10 rad/s TRS and 3 turns:

acts = 465.9005546

sols = 5.31172899

total in = 471.21228359

KE rise = 497.589826

EPE = 0.131973

total out = 497.721799

diff = +26.50951541 J



Now exactly the same sim, only with TRS set to zero (ie. unhindered OB):

acts = 472.4172035

sols = 1.058194521

total in = 473.475398021

KE rise = 473.914965

EPE = 0.004616

total out = 473.919581

diff = +0.444182979 J



Finally; same sim, OB-only (TRS=0), no sprung timing:

acts = 477.9850634

sols = 0.645346677

total in = 478.630410077

KE rise = 478.739561

EPE = 0.004434

total out = 478.743995

diff = +0.113584923 J


..so allowing for the 0.44 J baseline anomaly, we're still 26 J free and clear.

This result will be reproducible using that last sim posted - Google how to do spreadsheet integration ('area under curve sum'), export the meter data and crunch it in any spreadsheet.. it's silly wasting bandwidth posting sheets anyone who cares can make themselves from the sim and given settings..

Again, the assumption re. subtracting the known error is that it's accumulating on a per-frame basis for any given combination of sim frequency and FFB multiplier; hence by keeping those unchanged between runs, the same level of uncertainty applies to all three examples.

If that assumption's valid... we got ourselves a free energy warp drive doomsday machine and last one to build's a cissy.


Trying to eliminate the solenoids error is obviously another rabbit hole in its own right, increasing as it does with sim frequency - better MoI control code would help - however in this last example they're no longer gaining, but costing energy.. the PE discount is primarily in the actuators..


..and because of this, you'd think the gain should finally be trackable via those CF PE meters.. ie. if the interaction's working as intended, then the s&b cycles are causing a rotKE gain that's being harvested in the form of output CF PE, subsidising the GPE workloads..

Will try to check for this next..

[MrVibrating]

..Also, just noticed - i'd fallen out of the habit of taking the brake integral... lol

• the brake integral, from that first run with TRS = 10, is -357.1508204 J!

Oops! Minor detail...

Remember, the 'brake' merely applies negative torque - so the KE loss isn't necessarily dissipated, and could be driving a generator... would be nuts to convert it into frictional heating then back into useful energy of course, unless heat was the desired form of output for a given application..

So anyways, apologies, i am awful at this:


1000 Hz, 1 i-s/f, 1e6 FFB, sprung timing, 10 rad/s TRS and 3 turns:

• acts = 465.9005546

• sols = 5.31172899

• total in = 471.21228359

• KE rise = 497.589826

• EPE = 0.131973

• brakes = 357.1508204

• total out = 854.8726194

• diff = +383.66033581 J

• 854.8726194 / 471.21228359 = 1.81x unity


So PE-to-KE efficiency gains 26 J, but net of KE plus heat means we've actually gained hundreds of Joules..

But anyways, does this finally correlate with some kind of signal on the CF plots?

TBC..

[MrVibrating]

..again, just to reign in expectations, there's a likely error margin of 0.44 J there, so it might only be 854.4 J, rather then 854.8 J.






0.4 J was a big deal, yesterday..

[MrVibrating]

Rotor 1 CF P*t = -78.97858585

Rotor 2 CF P*t = 79.49167891

Rotor 3 CF P*t = -13.43347046

Rotor 4 CF P*t = 13.92785698

Net CF work = 1.00747958 J


So a minimum of work was done against CF force - presumably in line with the three zeros or so of MoI lock achieved at the 1 kHz sim frequency - but i'm not seeing the 26 J of rotKE coming through here..?

Do i need to add / subtract these CF workloads from the GPE inputs or something? Not too sure what to make of the CF data thus far..

[Fletcher]

If there is a NET Work done against Cf's i.e. the counter accelerations Netted to more than the CF accelerations v^2/r on average, then does that not mean that the masses which were 'ideally' separation distance controlled (maintained) by your formula to maintain constant MoI, slightly out of phase at times resulting in the classical ice-skater Net effect of pulling her arms in a little and giving the ice skater more RKE ?

Ignore me if I'm off base here. Just mumbling to myself.

[MrVibrating]

No, that's pretty much my interpretation too - the sim frequency was only 1 kHz, with 1e6 FFB, which was only enough to lock the MoI to three decimals... however it was three decimals high, not low, implying the gap between masses had narrowed very slightly, a net work against CF of ~1 J, and accounting for 1 J of the 26 J KE rise..


At least i think that's what it means...


The logic is that the solenoids error is increasing with sim frequency, hence we're better off - getting better data - by taking fewer 'vertical slices' of the curve integrals... whereas having more should in principle shave zeros off the result, here it's also introducing more uncertainty, so fewer zeros to a result are actually probably more accurate.


Again, the basic assumption is that it's OK to subtract the 'baseline' error (no s&b cycles) from the live run (with s&b's); in which case the net of heat plus KE is hundreds of Joules OU..

IIRC, the efficiency figure it's arrived at is consistent with what we've been seeing earlier in the thread, of around 181%..

So i'm thinking this really could be it..


If we can get better / cleaner MoI control, such that accuracy really does improve with frequency, or else, do away with it entirely, that would boost confidence.. i still think it's probably incidental to the gain mech; what should really matter is simply sinking counter-momenta to gravity while accumulating the results; this velocity divergence between internal (PE) vs external (KE) FoR's...

Back after work..

[MrVibrating]

Realised why the KE gain's not immediately visible in the CF plots (it's actually pretty simple and obvious):

• if the KE gain was the result of a single stroke, then you'd expect to see such a 1:1 correlation; however the gain's accumulating over many reciprocating radial translations of each weight...

So the KE gain probably is transferring through CF force (how else could it be subsidising the input GPE?) but as it's happening during each braking phase, we don't see all 26 J as negative CF work in the final integral sum.. which, incidentally, would presumably be 'zero' if the MoI was fully locked..


Too late and knackered to do anything with it tonight..

471 Joules in, for 854 Joules out, with an uncertainty of +/- 0.4 Joules.. seems a pretty good signal to noise ratio, for now.. Contrary to my earlier thinking that lower spin-up speeds were better, it seems higher ones are equally efficient - it's consistent across the board, by the looks of things, so the power density's fairly arbitrary.. you'll basically get out 181% of whatever goes in, so spin-up speeds of 100 rad/s or whatever are on the table, if we want kilojoules out..


Need to decide what to do next..

[MrVibrating]

..i know - how about another try at destroying some energy?

If we can consolidate more rotational KE from reactionless accelerations than the corresponding GPE cost of sinking the counter-momenta, by exactly the same token we should also be able to consolidate less...


This will be your basic 'non-dissipative loss' time. This singular phenomenon has the near-magical ability to make the most ardent pathoskeptic invoke free heat from nowhere in the attempt to explain it away.. i won't bore yet again elaborating Steorn's variation using Sv, but this is going to be exactly the same thing, only, using gravity instead of magnetic force.

In exactly the same way though - if it works - the interaction will lose mechanical energy that hasn't simply been dissipated to heat, but has instead performed an asymmetric amount of work against gravity, in relation to the rotational KE gained by perfectly cancelling the OB torque..

This should be a simple matter of prolonging the spin-up phases; if we want to maintain perfect torque cancellation then we can't change the torque value, and likewise if we want to maintain smaller weight MoI's to increase their KE value relative to the OB axis then we can't increase their MoI's either.. which just leaves spin-up speeds..

With longer spin-up periods (ie. higher target relative speeds), the system will be performing multiple GPE cycles per s&b cycle... and all the while the weights are being spun up, they're also being raised and then lowered, yet without obtaining any acceleration, or, thus KE, from their descents.. so we're paying for the lifts, but not getting any work out of their 'falls' (not technically 'falling' at all, really).

Results b4 bed..

[MrVibrating]

OK the anim's a little time-compressed but you get the idea:


The sim runs much smoother (attached)

Five spin'n'brake cycles of 100 rad/s:

(ignore the EPE meter; the spring's entirely absent here, the attached sim adds a new switch to the meter to detect when the spring's disabled to stop it doing this; i should also prolly expose the spring constant at some point too, not worth redoing the anim now tho)


acts = 14763.06327

sols = 7768.225097

motors = 24993.23572

brakes = -22230.98124

total in = 25293.542847

ke rise = 18316.999

diff = -6976.543847 J


"Wooo! where'd the energy go?"

..so, this implies efficiency can't be "181% across the board" since it's evidently a function of the time spent accelerating and braking at some benefit, vs lifting and dropping weights at a dead loss..

IOW, there must be a 'unity threshold' spin-up speed, where we'd generate precisely the same amount of rotKE we would've got from allowing the system to overbalance unhindered... i wonder what speed that is?


Is the efficiency curve linear, or non-linear WRT spin-up speeds?

What spin-up speed has the optimum efficiency?


Also, i note that the 'torque' calc for the OB axis appears to be failing - it's using N2 ('torque' is being taken as the MoI * rad/s² of the OB axis), which appears to be vibrating, presumably in response to the actuator / solenoid frame steps, and this resonance is throwing off that calc; you can see on the "Wheel Speed" meter that it's not actually accelerating anywhere when the motors are on.. but not important - haven't used it for anything yet.. was just to fill a gap, really..



So, plotting the efficiency of a dozen-odd different spin-up speeds is gonna take a good while, and i currently only have time for one or two sims a night ATM - is there some way to work out the optimum speed on first principles, i wonder?

Also, 1 rad/s is a large unit of velocity for scanning a range in stepwise fashion - mebe better to start using RPM for input speeds instead..

You can see though how this is a kind of time differential asymmetry; we're sacrificing (foregoing the output of) GPE we're lifting at one time rate of change, whilst consolidating KE from the s&b cycles at a different rate.. if faster, then we gain energy over time; if slower then we lose it.

Since the "T*a of OB axis" meter appears to be of dubious use, maybe i could replace it with a meter logging this time differential between rate of GPE in/out vs rate of rotKE netted from the s&b cycles? I wonder how you might formulate that..


The enclosed sim also updates the torque constant - previously tuned when the system contained nearo-zero masses; correcting that left the applied torque a little short, but as i've left the s&b cycles out of it the last week i'd forgotten to tweak the balance..

[MrVibrating]

..isn't the trend pretty much what i thought back on the first page - that shorter spin-ups consolidate more KE in less time, so efficiency IS a function of spin-up speeds..?

So you could optimise for better efficiency, at the expense of lower total throughput..

..or else go fast & rough with poorer returns but greater throughput per unit time..


In retrospect, i think what happened is that i lowered the MoI of the weight-rotors, which also downshifts the power ratio..

..and when i rushed into trying to replicate with 'v2', i was using a 1:1 MoI ratio, hence only got losses..

..basically threw meself a curve ball there... not very methodical..

Think tonight i'll try lowering those weight MoI's even further.. and/or raising that of the OB axis..

..then maybe try a range of spin-up speeds, if there's time..

[MrVibrating]

OK, was in too late, and too shot, to get anything done last night.. except for noticing a slight error in the 'big gain' above - i didn't just forget to take the brake integral when re-enabling the s&b cycles... there was another key integral i forgot to take, too... Duh! The motors..

Am i an idiot or what? :)

So, still need to address the signal / noise question..

..to that end, i've gone back to the quarter-turn test - one full GPE interaction - but now using constant settings for frequency, i-s/f and everything else.. so i do a full test, with s&b cycles and sprung timing, then another without s&b cycs but with sprung timing still enabled, then a final one with that disabled too.

Here's the final frame from the 'full' test:




..you can see that i've re-raised the net weight MoI to match that of the OB axis; if the s&b cycs are gaining energy at all, a 1:1 inertia ratio is mathematically the quickest route up the OU ladder, it's that simple. The previous ratio, of 8:1, would need 9 cycles just to break unity, with just an 11% per-cycle efficiency accumulator... whereas a 1:1 inertia ratio gives a full 50% p/c accumulator..

In other words, i've configured the s&b cycles to endow their 'magic' with the best possible bang-for-buck.. if they have any at all, that is..


Also, i've added a 'net GPE' meter - this just uses a hidden meter to calculate the GPE's of all gravitating bodies, and then collates them into the small display there..

..which is just as well, as it appears the GPE can vary over a test (esp. with sprung timing enabled), even tho the system starts and stops at precise angles and looks like a zero-GPE sum.

So here's the data from the 'full' test, followed by the two controls:

______________________

freq: 32765 / 1.614
spring K: 24
FFB: 8e8
brakes: -100
TRS: 0.1
turns: 0.25
sprung timing: on
______________________

acts = 36.07069573

sols = -1.648754842

motors = 1.593615824

brakes = -0.773283147

total in = 35.242273565
______________________

net GPE = -0.010106

spring EPE = 0.000001

KE rise = 36.901231

total out = 36.891126
______________________

diff = +1.648852435



as above, with s&b cycs disabled (TRS = 0):
____________________________________________

acts = 40.61005025

sols = -3.261170863

total in = 37.348879387
______________________

net GPE = -0.135939

spring EPE = 0.000493

KE rise = 40.749460

total out = 40.614014
______________________

diff = +3.265134613



as above, with sprung timing also disabled:
____________________________________________

acts = 39.98208583

sols = -3.258679515

total in = 36.723406315
______________________

net GPE = -0.005474

KE rise = 39.991096

total out = 39.985622
______________________

diff = +3.262215685




Conclusions
______________________


Definitely summink there, innit? +3.26 J from both control runs, and only half as much with s&b cycles enabled!

IOW, the s&b cycles ain't doing squat, except attenuating this persistent 'rotary solenoid' anomaly..!



next steps
______________________


I'm gonna re-do the 2nd baseline ('pure OB' only), this time varying only the sim frequency & the force feedback multiplier, to see if that +3.2 J figure changes weirdly in response, or else seems stable-ish (allowing for coarser accuracy with lower freqs)..

[MrVibrating]

Not gonna start the next round tonight - too late, plus hey i'm 3.2 J up so quitting while ahead.. (it's a WIN, damn you!).. until tomorrow anyway.

I'm glad i finally got the GPE metered up, but honestly, was taken aback by how much it can vary (it 'settles' downwards a little the instant the sim begins, even w/o sprung timing - the system was assembled with mathematical perfection, so for instance the two vertical weights 3 & 4 are initially positioned by entering "sqrt(2)" as their radii - so obviously once the system's live it's gonna settle under gravity a little, just due to the organic nature of the MoI control routine) - imperceptible drops were summing to half a joule or more, yet i've been chasing 'gains' down to 0.4 J without having GPE metered! So left it late enough, but finally eliminated another layer of potential noise..

I also tuned the spring constant to try to end on an EPE minima - since any PE stored in the spring means that the GPE timing is lagging rotation - as intended, but means ending on a potentially-significant GPE drop. IOW, minimal EPE means minimal GPE change between starting and ending conditions

Apologies for not following up with the solenoid F*d integrals, however we already know the net solenoid P*t gain is equal to the difference between the two F*d integrals.. basically that gain's arising because the two solenoid workloads are not equal and opposite.

For some reason.



To be determined..

[Fletcher]

Sometimes you loose a little GPE at sim run start because of elasticity effectively.

Let's say you place objects set to collide in your sim, but don't run it. And let's say elasticity is 0.5 and one object is above another on a common slot for instance. When the sim is run the top most object will "settle' against the lower loosing some GPE from initial conditions. It will 'settle' more with lesser elasticity factor.

fwiw.

[MrVibrating]

The previous tests were made at over 20 kHz, so here i've halved the frequency:


freq: 10 kHz
is-/f: 1
FFB: 2e8
turns: 0.25
no s&b cycs
no sprung timing


acts net P*t = 39.96921469

sols net P*t = -5.092553725

sol1 P*t = -14.62399066

sol2 P*t = 9.531436939

total in = 34.876660965
__

KE rise = 39.987528

net GPE = -0.011112

total out = 39.976416
__

diff = +5.099755035 J



In terms of potential error sources i'm still stumped, however if it's real, then the increase in gain could be correlated to a slight increase in MoI, caused by having to reduce the feedback multiplier in line with the lower sim frequency.

The feedback strength determines how rigidly the MoI is locked - too low and it starts to widen up as CF forces build, pulling each pair further apart..

Hence the results seem consistent with the gain representing real work done by centrifugal force pulling weights 1 & 2 apart - more being done at this lower frequency, due to looser MoI control.

Next up i'll try a max frequency run, thus with maximum force-feedback strength and minimal MoI drift; so a 'consistent' result from this would see the gain no greater than the 3.2 J we got from the 20 kHz run yesterday, and possibly somewhat less..


One point that would seem apparent at this stage however is that if it is real, then we're seeing greater gains from worse MoI control; thus we may conclude that the constant-MoI condition is indeed incidental to the gain mechanism - it's making the right moves, somehow.. just not for the intended reasons.. IOW, we can begin to think seriously about abandoning constant-MoI control entirely, and start investigating the truly optimal MoI variations to exploit whatever the potential here..

Also have to say that if real, the mechanism seems totally off my radar, just at a general conceptual level: KE gains as a function of anomalous acceleration of the FoR are piss-easy to understand - you just add whatever the velocity of the FoR to that of the internal accelerations and voila; you've transposed your workload right up the 'V²' multiplier in the KE equation. So long as the effective N3 break was free, or at least, cheaper than the gain, it's a pretty straightforward case of 1 + 1 = 3..

But here we appear to have something quite different - in a nutshell, if i'm understanding correctly, we're extracting more work from the CF-PE associated with the KE output of a GPE, than we're inputting in work done against CF force over that same GPE output stroke.

Neither the net MoI, nor that of either individual weight pair, is changing during this GPE output.

Yet the distances between each weight in a pair is varying cyclically, by a known amount, equal to r*sqrt(2), and it is from this radial displacement that the CF input and output work is being done.


Could we simplify the gain condition down to just two weights, sliding radially but in orthogonal orientation? Thus their net MoI would still remain locked as in the current rig, and they'd still be taking turns to cause over-balance... so might we expect to see the gain replicated in the outbound vs inbound CF workload difference?

The 'v2' attempt went off a bit half-cocked (who, me?) but maybe we're starting to get a bit more of an informed picture of what 'v3' might be designed to test for..

But for now, let's see if the max-freq result matches expectations..

Back in a bit..


ETA: oops here's a screenie (since i'm referring to newly-added integrals):




..just putting more metrics on the gain.

We should also be able to correlate the gain to the CF integrals at this point, so need to check this again and try to finally match 'em all up..

Sim also attached.