TPU - General Discussion

[EMdevices]

Ok Guys,Ã,  here's some MATH for youÃ, 

Notice I calculate the Voltage and Current induced in a vibrating wire per unit length (1 meter) Ã, 

I assume a vibration displacement of 1 mm in either direction (or amplitude of 1mm)Ã, 

This is only half the fun, the other is to calculate the amount of vibration produced given a certain driving Voltage.


@ BEP
The problem with the different modes is solved when applying the FEEDBACK.Ã,   That's when we use a FREQUENCY SELECTIVE network to feedback the right frequency.

EM

P.S.  Marco,  good job, sounds interesting.  We'll help you buddy!!!  I know the feeling.

[acerzw]

TPU heat is not a problem. We can make many TPUs then connect to the load via an automatic switch. The switch controller will select the coolest TPU among them to the load.

Exactly what I was thinking before. If for instance we HAD to live with the HEAT 'problem', we could easily use this technique as a sure fire method to avoid the HEAT issue, disregarding what you could use that HEAT energy for....

So, say a TPU could run for 1 hour and then it would get too hot, then you had to let it cool for 30 minutes for it to return to normal temp, you could just use two TPUs, run one for 1 hour, then switch to the other TPU which will run for another hour, and once that second TPU is ready to 'cool off', the first TPU would have already been cool for 30 minutes, so it would be very easy to switch back again. If it was the case that the cooling time was longer than the running time, you could just use 3 TPUs, which would easily solve that timing problem.

In regard to using the HEAT, that are A LOT of ways to USE the HEAT energy that is coming off a TPU, thereby cooling it enough to run forever.

Either way it's done, the HEAT 'issue' isn't really one...

It was an issue for SM because he was only considering the TPU in and of itself, without heat transmuting additions or multiples TPUs, he was only considering any single TPU device, in and of itself, so FOR SM, and his mindset of looking at the TPU like so, the heat 'issue' is an issue...

@tao

This is probably one of the most insane ideas that I have ever come across on this site! The main appeal of the TPU is its small portable size and simplicity, the above is a practical solution to the problem of heat but totally negates the point of the TPU, imagine carrying four TPU's around!

You might as well use a mechanical OU device instead which would be much safer than a TPU which can catastrophically fail without any notice due to external influences. Remember the exploding TV, a TPU even with a decent control circuit can fail unpredictably in such a manner without any warning!

[EMdevices]

Or you could include a cooling FAN and run CONTINUOUSÃ,  on one TPUÃ,    

The heat can also be minimized by minimizing the eddy losses, by lamination, but if design parameters don't permit, cooling is the alternative.

[TheNOP]

What if eddy current is not a lost but is a needed part in the process ?

[tao]

TPU heat is not a problem. We can make many TPUs then connect to the load via an automatic switch. The switch controller will select the coolest TPU among them to the load.

Exactly what I was thinking before. If for instance we HAD to live with the HEAT 'problem', we could easily use this technique as a sure fire method to avoid the HEAT issue, disregarding what you could use that HEAT energy for....

So, say a TPU could run for 1 hour and then it would get too hot, then you had to let it cool for 30 minutes for it to return to normal temp, you could just use two TPUs, run one for 1 hour, then switch to the other TPU which will run for another hour, and once that second TPU is ready to 'cool off', the first TPU would have already been cool for 30 minutes, so it would be very easy to switch back again. If it was the case that the cooling time was longer than the running time, you could just use 3 TPUs, which would easily solve that timing problem.

In regard to using the HEAT, that are A LOT of ways to USE the HEAT energy that is coming off a TPU, thereby cooling it enough to run forever.

Either way it's done, the HEAT 'issue' isn't really one...

It was an issue for SM because he was only considering the TPU in and of itself, without heat transmuting additions or multiples TPUs, he was only considering any single TPU device, in and of itself, so FOR SM, and his mindset of looking at the TPU like so, the heat 'issue' is an issue...

@tao

This is probably one of the most insane ideas that I have ever come across on this site! The main appeal of the TPU is its small portable size and simplicity, the above is a practical solution to the problem of heat but totally negates the point of the TPU, imagine carrying four TPU's around!

You might as well use a mechanical OU device instead which would be much safer than a TPU which can catastrophically fail without any notice due to external influences. Remember the exploding TV, a TPU even with a decent control circuit can fail unpredictably in such a manner without any warning!

The most insane ideas, ey? Who said anything about carrying it around? I didn't...

Mine was a SIMPLE example as to how you could solve the HEATING problem of the TPUs in the MOST OBVIOUS WAY, nothing more nothing less.

And, since his 6" TPU weighed only 1 pound, having 2 or 3 TPUs would only make that at around 2 to 3 pounds.

SM said that the HEAT issue was a real problem, so, if he resorted to water cooling, you can damn well bet he tried air cooling with a fan and such. SM insinuated that the HEAT issue was a sort of byproduct of the conversion process, and that eddy currents were in effect also related to the conversion process. Since this is the case, the HEATing problem is almost INTERNAL to the actual conversion elements, and hence hard to COOL. So, my SIMPLE and OBVIOUS example of using 2 or more TPUs, WOULD 100% solve the TPU heating problem a la SM's own words and admissions about how he dealt with the heating problems and how and why they occur.

So, to call my idea insane, is in itself insane, because my SOLUTION is OBVIOUS, and is 100% workable as a SOLUTION...