My Motors got me to Tap into Radiant Energy

[JohnStone]

@Cornboy: Wow. Black Beauty coming to life.

I'd like to give you remote assistance at building process for your pulsers. We will do it here publicly in order to give others a tutorial as well.
Give me some days in order to elaborate steps and advice.
It is very helpful you own an ocilloscope and generator. You should own a solder pump for board repair.

Outlok to the procedure:

• You assemble one single borad with first subcircuit only -> post a pic
• I will add conntections to the pic.
• You test it and report results
• assemble all other borads with first subcircuit
• test them

Proceed with next subcircuits like above.


HINT: There was some confusion regarding R1, R2 and gate resitors.

JS

[Cornboy 555]

JS boards.

Hello everyone, just a couple of pics of John Stone Pulser boards that Sampojo, organised.

Thanks Joe.

[IMG][/IMG]

[IMG][/IMG]

Regards Cornboy.

[Ufopolitics]

Hello Gerry

@UFOPolitics, John Stone, Dana, Hitby13KW

I am baffled by the use of the word frequency as it is being used in the forum. First in the use as it pertains to motor frequency as if this is a fixed number, which it is not. The motor frequency changes as the rpm changes. It is my understanding that frequency is expressed as hertz or one cycle per second. I take this to mean in the case of our electric motor one revolution per second = a frequency of one hertz. There may be multiple events happening in that cycle but they all occur within that cycle. So frequency is an easy calculation at given rpm, rpm/60. So calculating the total time period in milliseconds is just as easy since there are one thousand milliseconds in a second the formula would be 1000/frequency. So this would be a sliding scale with frequency getting larger as rpm getting higher and the total time period would be getting smaller as rpm increase.
At what rpm is a motor with a time period of 22 milliseconds turning. 1000/22*60 = 2727.2728. Dana has made the statement that his motor is most comfortable at a frequency, I believe he said 35. So what is the rpm here 35*60=2100. Now it is obvious to me from the data that I have seen that it is possible to have a difference in the program frequency and the actual motor's frequency.
Correct me if I am wrong or misunderstanding what I consider to be a very basic concept. But wouldn't the motor be most comfortable with a frequency that matched the rpm. This is how I designed the RadiantMotorControl. I know that the program frequency has to be matched to the frequency of the motor. It is not possible to know the frequency of the motor without a tachometer. In the current method of the rmc no one is using it with a tachometer and so there is no way to control the motor without it. Furthermore it is impossible to know whether there is a mismatch between the intended frequency of the program and the actual frequency of the motor without a tachometer reading. This could be a simple handheld tachometer. The fact that a motor is revving up is a sign of a mismatch between the intended frequency of the program and the actual frequency of the motor . Simply putting a scope on the leads of the motor will tell you the frequency that the program is operating at. It will not tell you the frequency that the motor is operating at. This can only be done by taking a tach reading and dividing rpm by 60.
The target time period of the rmc at this time is 16 milliseconds. How does this work out to the intended frequency and intended operating rpm. 1000/16 = a frequency of 62.5 *60 = 3750 for target rpm.
We have people making many speculative guesses as to what is causing the revving. My best guess which I would have tested immediately, is that there is a mismatch between the programs frequency and the rpm of the motor. It is possible for the program to be overpowering or providing too little power to the motor. BTW this program is not currently the type of program that you can take out of the box and type in your processor name and the number of brush pairs and expect it to work flawlessly. It is a test platform to test the different modes at different voltages and different duty cycles to find a match between the setup you are testing and the design of the program. That is what I mean when I say establish a baseline. It may be that the rpms are too low and that the motor is trying to get up to the frequency that the program is operating at and failing to do so because it is not getting enough voltage to power the coils. It could also be that the coils in the motor are receiving too much voltage and the motor is overshooting the mark and then coming back down to the programs operating frequency. And then again it could be something else entirely. I am not sure if hitby13kw noticed this revving in his motor or if it was isolated to Dana's motor.
I would appreciate any comments or corrections if I am in error in my understanding of frequency as it applies to these motors.

Cheers

Garry

Hello Gerry,

Primarily, I would tell you that all your Definitions/Understandings are correct. Is just, that there is a bit more to this...

When we step into the Fields of Motors Driving/Controllers we must realize Two Main Sides to this...generally speaking.

To understand this a bit better...Let's start by naming our Controllers "The Server"...and our Motors..."The Client"...Language utilized in Robotics Network Communications...where Server originates the Commands...and Client executes them. (the only difference is that in Robotics, the Client could be a Servo Motor...or a Joint, which is a combination of Servos...etc...and then it could become pretty complicated in terms of number of commands plus 3D Sensors, etc)

Now, here in our set up...we are just trying to achieve a simple series of commands for our Client to execute/maintain basically a Linear Speed/Torque response under different circumstances, depending on Generator Head demand.

In all cases...there always need to be a "Cushion"...a gap, a small delay, between Server/Client...and that is designed like that, in order not to generate "Traffic Congestion" in the Network Protocols...since we will be incorporating Sensors for the Operation to be performing in "Top Shape"...Sensors will be constantly sending a read out...that program/processor will compare and elaborate a "Resolve/Solution command" based on Software Codes...that "resolve signal" will travel towards Client for execution.

It is known that Electronics processing/sending signaling is "Ultra Fast"...based on our State of the Art technology...and our Machines, or any other, including Symmetrical...will carry on an "Intrinsic delay" for execution...realizing Electrodynamics need to charge a Coil...produce the required Magnetic Field...then develop enough force to rotate a Mass of wires/steel...so it could never be compared to the speed of a FET...which converts a signal to its Gate to produce -not a mechanical switching- but a chemical instant reaction that will close Drain to Source...while nothing is moving inside that FET...no inertia, no acceleration, no gravitational forces plus much more...

Therefore, we will be very wrong, if we expect that Server-Client Network Protocols must be done "instantly"...or "iso facto"...because it will NEVER Happen in Real Life...I mean, machines will rotate...but the back and forth electronic command origination at super speeds by Server...will never allow our Machines to catch up...at "executing stage"

Then we need to allow that Gap when designing all our "Server" structures, including-of course, and mainly- our codes.

The "Game" here is that Controller signals will always be Ahead of our Machines, like the saying..."Catch me If You can"......However...it is VERY Important here to NEVER allow Signals Flow/Networking to get "too far out", leaving our Machine and Sensors in a "Lost State"...So...if required, at times...our flow would need to stop...waiting for Client execution...and so on.

In the beginning on this set up with the Monsters/Arduino/Imperial...I recommended to add/duplicate the Monsters LED's to each corresponding Motor Gate...so we could "see" better the signal flow rotation...as the pulsing sound of our machines executing them...being able to compare at low pulsing IF this delay/gap is taking place and verifying that when accelerating SLOWLY, our Motor will interpret/execute them "in time"...then Go back to Low speed...etc,etc...This is a process to "adjust" our codes, sensors and Machine Networking...without reaching higher accelerations/speed required of 3600/3800.

And for those familiar with Gas Engines in Vehicles...could apply this same concepts...

Let's go to a brand new vehicle...and we will find lots of PCM's (Processor Control Modules) installed all over the engine bay and under the dashboard...this PCM's are also "Programmable Read-Out and Execute Modules" Diagnostics could be done through either an On Board Module...or a complex one in the Car Dealer or Repair Shop...But going into Functions...they all are attached to Sensors...like Crank Shaft Positioning Sensors...Temperature, Liquids Pressure Sensors...etc,etc.

In modern technology...our accelerator pedal is no longer attached to a "Mechanical Cable"...and to a rod with a return spring in a Carburetor Throttle Butterfly like in old days...nope!
Nowadays...accelerator is connected to either a hall sensor...or a potentiometer "Sending Unit"...that sends the signal to a Main processor...where it starts a series of events...or what we are calling here...a Networking of Signals Flow...back and forth...Then, we have the Old Farting Dinosaur......The Gas Engine...trying to keep up with the fast electronic flow...

But going to the point...and even in the latest "State of the Art" technology in Vehicles...we will "feel" always a delay...between our acceleration mode and our cars to start developing our requirements to gain or decrease power/speed.

Even in the "Good Old Days"...we needed to adjust the two screws mixture flow (Air-Fuel) at Carburetor...because our Gas Engines would choke/stall, if too much fuel was dispensed in a very short time...or if the opposite would be taking place...Engine "Starvation"...lack of enough fuel...and too much air..."too lean mixture"...could cause big time farting through their A** Holes, sorry...I meant their "Exhaust System"...

Resuming here...and sorry for a long post!...We need to incorporate a delay function...between our controllers and our Machines ...and "Tuning Up" this "Scenario" could take a bit of working/testing time...and we need You here Gerry...as we also need our Great Machine Testing and excellent Builders here...But, I tell You, once we tune up, at low speed gain/acceleration/deceleration responses...then Guys...we could "step on" our machines and we will obtain superb results...then, it would be just like to keep a "Cruise Control" ...set up at 3600 RPM's...no matter if we go Up Hill...or down the road...


Warm Regards


Ufopolitics

[Cornboy 555]

Cards Anyone?

Hey Sampojo, boards have arrived, so much for paying extra for tracking!

They look and feel excellent, thanks very much. will post pics when i have camera back.

Can't wait to populate one and try it, i have a bench function generator, and a scope now, perhaps if the winding is driving me insane, i'll swap for a while.

Thanks Friend, Cornboy.

[iankoglin]

@UFOPolitics, John Stone, Dana, Hitby13KW

I am baffled by the use of the word frequency as it is being used in the forum. First in the use as it pertains to motor frequency as if this is a fixed number, which it is not. The motor frequency changes as the rpm changes. It is my understanding that frequency is expressed as hertz or one cycle per second. I take this to mean in the case of our electric motor one revolution per second = a frequency of one hertz. There may be multiple events happening in that cycle but they all occur within that cycle. So frequency is an easy calculation at given rpm, rpm/60. So calculating the total time period in milliseconds is just as easy since there are one thousand milliseconds in a second the formula would be 1000/frequency. So this would be a sliding scale with frequency getting larger as rpm getting higher and the total time period would be getting smaller as rpm increase.
At what rpm is a motor with a time period of 22 milliseconds turning. 1000/22*60 = 2727.2728. Dana has made the statement that his motor is most comfortable at a frequency, I believe he said 35. So what is the rpm here 35*60=2100. Now it is obvious to me from the data that I have seen that it is possible to have a difference in the program frequency and the actual motor's frequency.
Correct me if I am wrong or misunderstanding what I consider to be a very basic concept. But wouldn't the motor be most comfortable with a frequency that matched the rpm. This is how I designed the RadiantMotorControl. I know that the program frequency has to be matched to the frequency of the motor. It is not possible to know the frequency of the motor without a tachometer. In the current method of the rmc no one is using it with a tachometer and so there is no way to control the motor without it. Furthermore it is impossible to know whether there is a mismatch between the intended frequency of the program and the actual frequency of the motor without a tachometer reading. This could be a simple handheld tachometer. The fact that a motor is revving up is a sign of a mismatch between the intended frequency of the program and the actual frequency of the motor . Simply putting a scope on the leads of the motor will tell you the frequency that the program is operating at. It will not tell you the frequency that the motor is operating at. This can only be done by taking a tach reading and dividing rpm by 60.
The target time period of the rmc at this time is 16 milliseconds. How does this work out to the intended frequency and intended operating rpm. 1000/16 = a frequency of 62.5 *60 = 3750 for target rpm.
We have people making many speculative guesses as to what is causing the revving. My best guess which I would have tested immediately, is that there is a mismatch between the programs frequency and the rpm of the motor. It is possible for the program to be overpowering or providing too little power to the motor. BTW this program is not currently the type of program that you can take out of the box and type in your processor name and the number of brush pairs and expect it to work flawlessly. It is a test platform to test the different modes at different voltages and different duty cycles to find a match between the setup you are testing and the design of the program. That is what I mean when I say establish a baseline. It may be that the rpms are too low and that the motor is trying to get up to the frequency that the program is operating at and failing to do so because it is not getting enough voltage to power the coils. It could also be that the coils in the motor are receiving too much voltage and the motor is overshooting the mark and then coming back down to the programs operating frequency. And then again it could be something else entirely. I am not sure if hitby13kw noticed this revving in his motor or if it was isolated to Dana's motor.
I would appreciate any comments or corrections if I am in error in my understanding of frequency as it applies to these motors.

Cheers

Garry

G'day Garry
I see and understand and agree to exactly what you are saying.
I have noticed over the years while dabbling into these things that there is basically frequency and voltage that governs the speed of a motor and that no matter which one is changed if left alone the motor will either speed up or slow down to whatever it needs to match the parameters it is comfortable with.
In saying this I can use as an example The UFO's "Happy motor circuit" this circuit is to run the switching on and off of a bifilar coil or rather 2 separate coils, both wound the same way and one on top of the other separated by reversed fast switching diodes to harvest the radiant energy using a 36v battery as source to energise these coils. And then controlling the Duty cycle of the switching by means of an oscillator that uses a pot to alter the duty cycle.
As I seem to understand now is that the faster the switching and the shorter duty cycle the Off time ? being longer allows more radiant energy to accumulate and this means more voltage (if you charge a battery no matter what voltage you charge it with it will always start charging 1v then 2v in a linear increase of voltage until they are equal) This is proved to me by the way I have been able to run a standard Chinese 250w 9amp motor 2750RPM motor up to 105volts 10,000revs drawing only about 2amps.
I notice that whatever position the pot is either increase or decrease it takes some time for the motor to stabilise that is to run at the same frequency/speed that the motor is comfortable with for that voltage and this switching may or may not be the same frequency that the motor runs as I am sure that the segments of the commutator receive more than one pulse while actively connected.

So my observation is that the frequency/speed of the motor controller needs to be stabilized to what ever the revs of the motor is required and this is done either by Frequency of the switching of the driver or the amount of volts applied. And when the speed is stabilized so is the voltage.


Kindest Regards

Kogs Just thing aloud or allowed which is it?

[Cornboy 555]

It Hertz.

That's a great explanation DANA, it sure helps me, i have a standard motor controller, for a 18 kw, short circuit motor, and i think it runs at 35 khz.

It strains your brain, when you look at linear feed to one of our rotors, it is an excellent mechanical switch.

My MAG3 for instance, when fed linear would switch at 1.8 khz, at 3000 RPM!, if my calculations are right.

I sympathise with you Garry, frequency with these motors, can be a little confusing.

Later down the track, i would like to try 1 hard pulse from our monsters, PER commutator segment, timed from hall sensor on shaft, with adj Duty.


Warm Regards Cornboy.

[prochiro]

Garry
You just asked the million dollar question. The following are my observations. Every motor has a frequency range that it runs best at. Once found, leave frequency alone as that range can be as small as 2 to 5 Hertz from top to bottom. The frequency that a motor runs best at is still different from setup to setup as it depends if you are using one long pulse or many pulses in pulse as well as a composite of everything else in that system. It probably is a tuning range dependent upon every other part of that system including mechanical. Can you run a motor with frequency, well we know you can. But the point here is that if you have a setup with both variable frequency and duty cycle, once you set it set up, you are going to end up using one or the other as rpm control, not both. One or the other must remain stable to produce reliable results. In what I thing most have found, changing duty cycle only is the best method as even with the store bought pulser, that is how they work. Now rpm is a result of one setup only and the voltage applied with that duty cycle change. Use a different motor setup with the same arduino and code and voltage and you will get different RPM. Maybe close but certainly not something you use to set an exact variable in a program. That is why we use PID. RPM is a variable result from top to bottom but will remain stable within the same system setup.
With solid pulses, the Imperial seems to like a slow frequency which is why UFO and Machine are having fun with the solenoids. You see there joyful motor running with extremely low frequency. Other motors, seem to run best around the 490 hertz that we were using. I think that if we could have code that recorded a number in hertz that we could initially tune to and then thereafter NOT do anything to alter that frequency again no matter what, you have your program. The big issue here is again if you lock in a frequency and then enter any additional delay at all between the pulses, you are not at the correct frequency now. My Imperial has a frequency running range of 30 to 32. How much code will keep it in that range is to be determined I guess. It may turn out that the Imperial likes the 490 Hertz as long as we use your many pulse in pulse system and in fact it works well on mine. But frequency is not stable at all times. Hope this helps some and others will also help soon.
Dana

[GChilders]

Frequency and freqency mismatches

@UFOPolitics, John Stone, Dana, Hitby13KW

I am baffled by the use of the word frequency as it is being used in the forum. First in the use as it pertains to motor frequency as if this is a fixed number, which it is not. The motor frequency changes as the rpm changes. It is my understanding that frequency is expressed as hertz or one cycle per second. I take this to mean in the case of our electric motor one revolution per second = a frequency of one hertz. There may be multiple events happening in that cycle but they all occur within that cycle. So frequency is an easy calculation at given rpm, rpm/60. So calculating the total time period in milliseconds is just as easy since there are one thousand milliseconds in a second the formula would be 1000/frequency. So this would be a sliding scale with frequency getting larger as rpm getting higher and the total time period would be getting smaller as rpm increase.
At what rpm is a motor with a time period of 22 milliseconds turning. 1000/22*60 = 2727.2728. Dana has made the statement that his motor is most comfortable at a frequency, I believe he said 35. So what is the rpm here 35*60=2100. Now it is obvious to me from the data that I have seen that it is possible to have a difference in the program frequency and the actual motor's frequency.
Correct me if I am wrong or misunderstanding what I consider to be a very basic concept. But wouldn't the motor be most comfortable with a frequency that matched the rpm. This is how I designed the RadiantMotorControl. I know that the program frequency has to be matched to the frequency of the motor. It is not possible to know the frequency of the motor without a tachometer. In the current method of the rmc no one is using it with a tachometer and so there is no way to control the motor without it. Furthermore it is impossible to know whether there is a mismatch between the intended frequency of the program and the actual frequency of the motor without a tachometer reading. This could be a simple handheld tachometer. The fact that a motor is revving up is a sign of a mismatch between the intended frequency of the program and the actual frequency of the motor . Simply putting a scope on the leads of the motor will tell you the frequency that the program is operating at. It will not tell you the frequency that the motor is operating at. This can only be done by taking a tach reading and dividing rpm by 60.
The target time period of the rmc at this time is 16 milliseconds. How does this work out to the intended frequency and intended operating rpm. 1000/16 = a frequency of 62.5 *60 = 3750 for target rpm.
We have people making many speculative guesses as to what is causing the revving. My best guess which I would have tested immediately, is that there is a mismatch between the programs frequency and the rpm of the motor. It is possible for the program to be overpowering or providing too little power to the motor. BTW this program is not currently the type of program that you can take out of the box and type in your processor name and the number of brush pairs and expect it to work flawlessly. It is a test platform to test the different modes at different voltages and different duty cycles to find a match between the setup you are testing and the design of the program. That is what I mean when I say establish a baseline. It may be that the rpms are too low and that the motor is trying to get up to the frequency that the program is operating at and failing to do so because it is not getting enough voltage to power the coils. It could also be that the coils in the motor are receiving too much voltage and the motor is overshooting the mark and then coming back down to the programs operating frequency. And then again it could be something else entirely. I am not sure if hitby13kw noticed this revving in his motor or if it was isolated to Dana's motor.
I would appreciate any comments or corrections if I am in error in my understanding of frequency as it applies to these motors.

Cheers

Garry

[machinealive]

Hitby, I always thought that you should not connect batteries up, that have different ratings, like you plan to. I thought that was dangerous. what if you get spikes, enough for 12 v, but bigger then 6 v can absorb. I don't know, but I want to keep you safe, dude.

[Hitby13kw]

Thanks Hitby, it will be interesting.
Regards Cornboy.

@Imperial Team,
After my discussion with Cornboy it occurred to me that we can still run on batteries and have 6 volt steps if we add golf cart batteries to the mix, so after many hours of moving things around we have added to our power source.
It now consists of 4 x 12V @ 1400CCA + 2 x 12V @ 950CCA + 6 x 6V @ 500CCA so we can switch in any amount from 6 to 108VDC in 6V steps
(smallest interconnecting cable used is 6 AWG, most are 1/0 ~ (can you say ark weld)) and of course my variable DC supply that can deliver 0 to 120VDC @ 0 to 27Amps.




Research continues,

Hitby13kw

[JohnStone]

Hi friends,
pondering on advantage of short pulses I tried to get the picture in terms of power dissipated in coil resistance (loss) and power charged into the coil producing flux.
I can not calculate that but I can simulate that and got amazing results.

I simulated two cases along a coil 100mA and 5 Ohm:
1. 12V -> pulse ended at 1A / 11ms
2. 36V -> pulse endet at 1A as well / 3ms



Now what do you guess is the advantageous case?
First of all let's look at power in coil resistance:

As expected in both cases we have losses of 5W peak.
A: Now let's take the 11ms pulse as reference and assume a duty cycle of 50% -> period of 22ms. If we assume the power increase to be linear we get 5W/2 of continuous power loss while pulsing and again divided by 2 because of 50% duty cycle in this gate = 1.25W.

B: Second case with short pulse because of 3 fold voltage but 1 A peak as well. Remember: motor speed requires every 22ms period but we have a duty cycle of 7.33%. Let's calculate: 5W /2 while pulse active and regarding 7.33% dutiy we get: 0.175 Watt.
Result: Factor 7.14 less power dissipation

That's fine but let's look at power pumped in the coil:

Remember: Condition at switch off triggers the magic: the more the better. In both cases the flux conforms to 1A - no difference, same advantage.
We pump in both cases same energy into the coil. But because of short pulse the energy flow (power) needs to be higher.

Discussion:
1. Short pulses with same cut off current decrease the losses in the coil resistance considerably.
2.Conversely if we pump the coil to same losses we can get much more current into teh coil and that corresponds to much more flux than before.
3. Items above might be essential if we intend to pump the flux up in the nonlinear magnetic area. It is told that there we get untold advantages by magnetic resonance.
4. It is told that radiant increases nonlinearly with flux increase - i.e. doubled flux = squared radiant. That is another reason for reducing losses in coils by short pulses.

Please excuse spelling errors and possibly less clear explanation. It is late night here but I am so excited and I did not dare to wait posting these facts.
Please look through and report possible errors. We need to confirm my finding.
And please to not rush now to short pulses in your setups. Time will come to experience it. But it is important to have those facts in mind in order to digest them.

JS

[JohnStone]

.... I see in the end we will have two possible systems. One with a computer that runs a control panel or one that uses two arduino's with the controls in the first and that has a keyboard attached.....

We need to think in consecutive steps:
1. First task is to get Arduino running with what he is supposed to do. It is far more convenient to command an test by PC immediately than adding an additional obstacle like second one or local display.
2. If we have a known functioning Arduino we can add whatever HMI (Human Machine Interface) we decide for. Bluetooth to PC or Iphone possible as well if you like. BTW: Unfortunately USB keyboard is supported by Arduino due only.

@ALL: Please be patient. Garry does a superiour job and his preference for PC I/F speeds up the whole process. This procedure does not exclude other HMIs at all.

Some of us make up their mind regarding data aquisition. Please regard there are different applications we intend to have and uncontrolled mix up is not helpful.
A: Motor control: pulse outputs, rpm sensor.
B: Motor protection: temp, current, rpm. Please regard theses values do not need to be very precise and can be setup in usual mode.
C: Data aqusition for proof of concept: current, voltage, torque along power calculation and finding sweet spots. In this case we need high precision. Any disturbance from setup prevents precision and repeatability. Therefore we need to take some additional precaustions. It is no question of big money but some very very moderate increase of expense along smart building.

There are some heads in the forum stressing their brain on how to perform next steps. Please believe it: we are still centered on road! But we do not jump shortcuts because we do not want to go any track twice.

Current step is to get stetups pulsed at different places in the world with similar behaviour. There are some pulsers still not running well and Arduino needs to get some steps of education.
- First comparable functional test: pulsing at one gate with 12V / 24V / 36V and take rpm and amps.
- Same with n poles.
With these readings we can discuss if setups behave like requested.
JS

[Ufopolitics]

Yes John...

@UFO:
Summing up what I understood in order to check correctness:

1. One qualification check should be to drive the motor via one single gate and it should run idling at max. duty (25% for 4 gate design, 16,66 for 6 gate design). Preferred less duty than max.
Questions:

• Should the motor arrive in this test requested speed i.e. 3600rpm?
• Any hint regarding voltage or ratio voltage/current?

2. Every setup requires a certain minimum voltage / current in order to start the magic:
- We need an area (angle) where we (a) feed a gate actively and another area (angle) where we (b) harvest HER gift.
- It is preferred to decrease charging area (angle) and increase harversting area (angle)
- Harvesting energy depends on amount of magnetic energy being interupted in a sudden from hot current. Magentic energy being linearly related to hot current applied and number of turns and somehow design of coil (bifilar...).
- Overall magnetic energy in the motor is being built up at startup and maintained while running.
- Harvesting depends on maximum current reached at every pulse just before interruption. It can be build up slowly by low voltage (high duty required) or fast by higher voltage (lower duty required).

3. Suggestion for test. (please comment or confirm)
All builders shall take data from test below:
- Set up your preferred voltge (1.....4 batteries)
- Take data with one single gate energized and with all gates energized

• When idling: check max. rpm at full duty cycle (25% for 4 gate design ....)
• When idling: chack max. rpm at have duty cycle (12.5% for 4 gate design...)
• Let's discuss data obtained

Hint: Most processes in nature are nonlinear. It is estimated that this applies to harvesting radiant as well. Hence it might be very convenient to apply (later on) short high voltge pulses in order to drive magnetic effects in nonlinear area while feeding minute hot energy at input. (Given the state at very switch off time is essential).
With this in mind I feel it to be very importent to find an initial test procedure like suggested above in order to have a solid and common foundation for further elicitations.
JS

Hello John,

Ok, all we need to know/find out/investigate is:

IF One Gate Pulse will Turn our Rotors at the MAX allowed Quad Pulsers.
And yes, that Single Pulse to One Gate, should turn Motor strong enough and, yes, reaching the 3600 or above.

What we are trying to do by Quad Pulsing, is to AMPLIFY our existing force created by that single pulse...by repeating The SAME SIGNAL pulses, Sequentially, at strategically located points of our Machines...related to Stators and Brushes...

And it seems to me that we are getting motor to turn...but ONLY when assisted by ALL Pulses together...and that IS NOT what we are looking for.

Hope you guys understand what I mean above.

Voltage and Current?...I have reached over 4000 RPM's with 36 Volts with just Two Gates...and I really do not see why we need to go to such high voltages...So I think we could use from 36 to 48 Volts... maybe 72 MAX...but non sense is to go at 90 or above...and current should not exceed 20 Amps.


Yes, related to Short Pulses High Voltages...it is what Tesla mentioned back in the 1800"s...


Kind regards John, hoping everything is well with family.


Ufopolitics

[prochiro]

Hello All
PS
If we are talking of importance of wire length and size as well as rise time and fall time, why do you think that throwing off the pulses a few milliseconds is OK, as these changes are nonlinear. I see in the end we will have two possible systems. One with a computer that runs a control panel or one that uses two arduino's with the controls in the first and that has a keyboard attached.
Dana

[prochiro]

There seems to be a lot of confusion here. It is apparent to me that it is in part related to the two ways that we are using to define duty cycle. First off, a glass can only be 100% full. When we talk of 255 duty cycle that is not the duty cycle, it is 100%. The common 255 comes in in the sensors range and was started that way to give better definition to the 0 to 100% or off and on. Ok, so the computer uses this as a method but if the human uses this in his mind he must do this every time, (255/100)=duty cycle. We need to show in any output or input the 0 to 100% that our minds relate to and let the computer do the math. This is simple and takes computer no time at all.

Now the confusion about 25% duty and such. This is dependent upon how many pins are going off as to what it really is. If you only are causing one pin to fire you will have 0 to 100% duty possible. If you art using two pins you will use ) to 50 an 50*2=100%. If you are using four pins as in the quadpulser with Imperial, each pin delivers 25% of 100%, or 25*4=100%. Now if you are running the Imperial with one pin say on P1 for example that is one pin going off and the duty range on that setup is 0 to 100% as per the above explanation. You can not take a Quad setup in the arduino where all four pins are going off, put only on pin to P1 and get it to run. That is what Machine was doing. That method will delever only 25 percent at max divided by 4 in time slots or (duty cycle of 6). Imperial should not be expected to run with duty of 6 and it will not. The program used must be set to number of pins ether in the code or by control panel to do this pulsing rite.
If you want to see on your scope and motor the changes in pulsing, all you deed to do is take the duopulser program and after the two pins are sent high the low, add "delay( what ever delay you want to test)". If you test this with the scope you will see immediately the alteration of duty cycle. If you use a motor, as our ears are not that sensitive and only a large change will be noted to slow motor enough to hear, you will need to add more time to hear it that way but will be way out of correct duty cycle. My suggestion is to mot use a motor at all for this but only a scope as it does not get confused as our ears do. Delays in the Millisecond range can be seen as bad. Delays in the microsecond range can be seen as altered duty cycle and or frequency. Not good. You do not need to have a motor going or even a monster pulser to test this. Just put leads int arduino and attach scope. Easy. We are not playing darts here where we get points for being close, That Imperial is extremely responsive to every small event and as UFO has described above, that one small change has repercussions in both time and space that follows.
Dana