I was testing voltage because electrical potential means there has to be power in the system. In a closed system, if some of the original enrgy were to be lost, and not replaced, the overall potential should lower, right? So when i tested it, it did not increase nor decrease, even when i added wires.
A Player's Guide to Redpower 2 Blutricity
- Thread starter Omicron
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
And, ratchet, im not testing energy usage; im testing for energy loss, so using it isnt really the best way to go unless you know all of the other constants in the equation, which, i dont. If you know how much a batbox holds and how many J per cobble, then go for it.
Erm, two things there Quantumwolf...
1.) We do know how much a battery box holds and how many joules a smelting operation takes, it's written in the guide
2.) All of this is irrelevant in this test because you simply want to test for energy loss. If the directly attached furnace smelts more pieces of cobble than the furnace attached by cable, you have energy loss. If they both smelt the same number of cobble, you don't.
But, I think I know where your confusion comes from. You are expecting that when you input a finite amount of energy into the cables and measure it, that it would decrease slowly over time because of energy loss. This does not happen, however, because there is not actually any energy flowing through the cable.
What you measure when you read out the voltage in the cable is how much energy it stores. Each cable has a small energy storage ability, called self-capacitance, and if that is filled to for example 80%, you will be seeing a potential of 80 V. In this way, the cable acts like a tiny battery. And this internal energy will remain where it is, until you connect a consumer. It is not flowing anywhere. The cable can sit there for a hundred years, and it will still be at 80 V. Just like a filled battery box does not get less filled over time.
What I mean with energy loss, on the other hand, is that you get out less on side B than you input on side A. It's a distance based loss, not time based, and it only happens when energy is actually flowing from A to B.
1.) We do know how much a battery box holds and how many joules a smelting operation takes, it's written in the guide
2.) All of this is irrelevant in this test because you simply want to test for energy loss. If the directly attached furnace smelts more pieces of cobble than the furnace attached by cable, you have energy loss. If they both smelt the same number of cobble, you don't.
But, I think I know where your confusion comes from. You are expecting that when you input a finite amount of energy into the cables and measure it, that it would decrease slowly over time because of energy loss. This does not happen, however, because there is not actually any energy flowing through the cable.
What you measure when you read out the voltage in the cable is how much energy it stores. Each cable has a small energy storage ability, called self-capacitance, and if that is filled to for example 80%, you will be seeing a potential of 80 V. In this way, the cable acts like a tiny battery. And this internal energy will remain where it is, until you connect a consumer. It is not flowing anywhere. The cable can sit there for a hundred years, and it will still be at 80 V. Just like a filled battery box does not get less filled over time.
What I mean with energy loss, on the other hand, is that you get out less on side B than you input on side A. It's a distance based loss, not time based, and it only happens when energy is actually flowing from A to B.
For a situation where you are not transferring energy, yes.
When you are transferring energy, you need to "pay a price" everytime you cross from one conductor section to the next, in order to overcome electrical resistance. That energy paid is permanently lost.
Maybe it'll help you if you compare it with a different, easier to understand energy system. Let's talk about Industrialcraft EU. If you have copper cable and send a packet over it, every five steps of copper cable you lose 1 EU. Blutricity is very similar, except that you are counting in Joule, not EU. And instead of losing a big amount every five steps, you lose a small amount every step.
The mistake you made was trying to measure in a situation where no energy flow was happening. In IC2 terms, you had a batbox and some copper cable, but no machine connected to it. All the EUs would remain in the battery box, and you conclude that copper cable has no energy loss. Which is quite obviously not the case, as you would see as soon as you hook up a machine (or another batbox) and make the EUs actually move.
Of course, IC2's cables do not store any energy themselves, whereas blue alloy wire does. However, the stored energy is completely irrelevant for loss considerations. You can ignore it.
When you are transferring energy, you need to "pay a price" everytime you cross from one conductor section to the next, in order to overcome electrical resistance. That energy paid is permanently lost.
Maybe it'll help you if you compare it with a different, easier to understand energy system. Let's talk about Industrialcraft EU. If you have copper cable and send a packet over it, every five steps of copper cable you lose 1 EU. Blutricity is very similar, except that you are counting in Joule, not EU. And instead of losing a big amount every five steps, you lose a small amount every step.
The mistake you made was trying to measure in a situation where no energy flow was happening. In IC2 terms, you had a batbox and some copper cable, but no machine connected to it. All the EUs would remain in the battery box, and you conclude that copper cable has no energy loss. Which is quite obviously not the case, as you would see as soon as you hook up a machine (or another batbox) and make the EUs actually move.
Of course, IC2's cables do not store any energy themselves, whereas blue alloy wire does. However, the stored energy is completely irrelevant for loss considerations. You can ignore it.
Which makes me love IC even more. Course, I did wish it came with these types of measurements. But for simplistic sake, I guess some sacrifices had to be made...
If I didn't think the IC2 team was so scared of altering their ENet, I'd try to convince them to move toward this model of energy distribution. But then again, I think the reason why people prefer EU over Blutricitic quantification is, indeed, because it is simple. Still, this is a really nice guide, and I am glad Eloraam designed it in such a way to appropriately describe how electricity works in a realistic physics-type application...
ok, so i think i've figured it out.
I was wrong.
So the set up for the most recent test i ran was this...
bat box at 100%, an empty furnace, and wires placed after the box was charged. This was done for all trials
trial 1 had 0 wires and resulted in 3.5 unsmelted
trial 2 had 1 wire and resulted in 3.75 unsmelted
trial 3 had 5 wires and resulted in 6 unsmelted
trial 4 had 10 wires and resulted in 7.25 unsmelted
so...
when you find the difference between the control and any one of them, then try to scale it to match other trials, it doesnt match up.
so, there is energy loss, but i didnt calculate how much. per wire. I'd assume it's a really annoying log equation so i'm not even gunna bother.
I was wrong.
So the set up for the most recent test i ran was this...
bat box at 100%, an empty furnace, and wires placed after the box was charged. This was done for all trials
trial 1 had 0 wires and resulted in 3.5 unsmelted
trial 2 had 1 wire and resulted in 3.75 unsmelted
trial 3 had 5 wires and resulted in 6 unsmelted
trial 4 had 10 wires and resulted in 7.25 unsmelted
so...
when you find the difference between the control and any one of them, then try to scale it to match other trials, it doesnt match up.
so, there is energy loss, but i didnt calculate how much. per wire. I'd assume it's a really annoying log equation so i'm not even gunna bother.
The equation is called Ohm's Law, and it's much simpler than you think: Resistance = Potential Difference / Current
In other words, R = dV / A. You can easily solve it for any of the three variables so long as you have the two others. And because the resistance R describes an entire length of cable, that means it can be written as the conductor's specific resistivity ρ (that's a greek rho) times the length L of the conductor in blocks: ρ * L = dV / A.
An example of applying that equation can be found in my guide under 17.), and under 23.) I list the values for ρ for all blulectric conductors.
I've been poking around the windmill stuff a bit. I'm still trying working through the blocking bits but thought I post up a couple of points I have noticed. I'll double check all of this once I'm done.
Max wind speed (normal weather) is 1.3 although this is multiplied by 10000 for the purpose of calculating power generation.
Height does affect wind speed. The multiplier is SqRoot(Height)/16 giving a number between 0 and 1 with reducing returns the higher you go.
If you generate a flat world the height multiplier is *not* applied which could explain some of the confusion.
Hell worlds have a constant wind speed of 0.5.
Max power gen (normal weather)
Vertical: 4680
Horizontal: 2470
Thunder multiplies power output by 4.
Rain generally increases wind speed but not always. Modified speed is 0.5 + (speed*0.5). If wind speed is very high (>1) rain will actually reduce wind speed.
Like I said, I'm still working through it all so I may have misinterpreted some of this. I'll correct things as I go.
Max wind speed (normal weather) is 1.3 although this is multiplied by 10000 for the purpose of calculating power generation.
Height does affect wind speed. The multiplier is SqRoot(Height)/16 giving a number between 0 and 1 with reducing returns the higher you go.
If you generate a flat world the height multiplier is *not* applied which could explain some of the confusion.
Hell worlds have a constant wind speed of 0.5.
Max power gen (normal weather)
Vertical: 4680
Horizontal: 2470
Thunder multiplies power output by 4.
Rain generally increases wind speed but not always. Modified speed is 0.5 + (speed*0.5). If wind speed is very high (>1) rain will actually reduce wind speed.
Like I said, I'm still working through it all so I may have misinterpreted some of this. I'll correct things as I go.
Neat information, thanks! Kind of a nasty trap to fall in that height does not modify wind speed in flat words.
Looking at that formula, output would be 50% at sea level (y=64), 75% at y=144, and 100% at y=256.
With thunderstorms being a x4 multiplier, does that mean you could theoretically see up to 10 kW out of a vertical windmill?
Also, is this the same "wind system" that IC2 uses, or is this specifically Redpower's method?
Looking at that formula, output would be 50% at sea level (y=64), 75% at y=144, and 100% at y=256.
With thunderstorms being a x4 multiplier, does that mean you could theoretically see up to 10 kW out of a vertical windmill?
Also, is this the same "wind system" that IC2 uses, or is this specifically Redpower's method?
Yup, that's right. Also means windmills at ground level in the twilight forest are not so good...
I'm getting 18720 for the vertical at max height in thunder. You either get the thunder or rain modifier, never both.
Different wind system. To my untrained eye it looks like Perlin noise with world time as the position and a fixed seed. Which is weird because it would mean wind speed would be the same at a given point in world time for every world.
I'm finding it quite difficult to follow Eloraam's code in places if I'm honest but if you want anything else in particular I could have a poke around.
Well, I recently ninja-updated the numbers for self-capacitance a bit after finding a new testing method that I think should work better than what I had before. Do you think it might be possible to find this in the code and confirm whether I measured accurately?
Also, the biggest mystery for me so far is still the blulectric engine, and how it decides how much power to consume and output. I have this setup with 36 battery boxes powering one of them, and it still won't draw more than 9 kW (meaning 9 MJ/t generated) when hooked up to a REC that requests 100 MJ/t. According to Eloraam it should self-adjust to the requested amount, up to 30 or 32 MJ/t; but it isn't. I've no clue how to test this thing properly.
Also, the biggest mystery for me so far is still the blulectric engine, and how it decides how much power to consume and output. I have this setup with 36 battery boxes powering one of them, and it still won't draw more than 9 kW (meaning 9 MJ/t generated) when hooked up to a REC that requests 100 MJ/t. According to Eloraam it should self-adjust to the requested amount, up to 30 or 32 MJ/t; but it isn't. I've no clue how to test this thing properly.
Can someone estimate how many solar panels and battery boxes? For night storage for a frame boring machine that have 40 frames and breakers for the "head" and a 3 by 7 platform with two motors, about 8 more frames and wires attached to them, 5 battery boxes with an automated battery box for recharging the one. I'll have this thing go at about 4 seconds per cycle so around how many solar panels and battery boxes will I need to make sure this thing will run day/night? Good thing these solar doesn't care about rainy days like the IC2 ones.
I'll have a look and see what I can find.
I've had a look at the Blulectric engine. As appears to be the common thing with redpower, it's more complicated than you'd think. It doesn't appear to be a straight conversion. Believe it or not that flywheel you see on the engine is modeled with energy being drawn to bring it up to speed. The power generated appears to be based on the speed of the flywheel. Outputting MJ slows the flywheel down. I'll have to trace things through to see where the limits are.
Well, a frame motor needs 10 J per block moved per action. "Blocks moved" includes frames, and blocks that are being moved by frames. Things like red alloy wires count as blocks - basically, anything that occupies at least a part of a block space.
So what you need to do is count every frame and every non-frame object (except for covers and panels installed into frames, those don't count) moved by a motor, multiply that by 10, and multiply that by the number of actions you predict the motor to take during a night phase. If it's an extending/retracting arm it'll be more complicated, of course, because the number of frames moved will be different each time. Do this for every motor on your frame machine, and add up the numbers into a grand total.
That grand total is how much joule your frame machine will probably consume during a night phase. A battery box holds 300,000 J. Thus you can easily calculate how many battery boxes you need.
Then, looking at power generation: each solar panel will charge a battery box with around 180 W. Watt equals joule per second, so 180 J/s. You have sunlight for a minimum of 600 seconds per Minecraft day; it might be closer to 660, but let's calculate with 600 for safety. 180 * 600 = 108,000; meaning that three solar panels will easily recharge one battery box over the course of a Minecraft day, with a healthy safety margin factored in. It might be as little as 2.5 panels in practical application.
So by taking the number of battery boxes you need for a night times 3, you get how many solar panels you need to always recharge them before sundown. But! Your frame machine also consumes power during the day. Probably the same amount it needed during the night. So you must place double the amount of solar panels in order to both feed the continuing power draw and recharge the buffer storage at the same time.
Oh dear. Apparently Eloraam's a fan of "why simple when it can be complicated"
Yea but hey I can upgrade the thing to 4x bigger then! I just need to run this guy for a good sleep's worth and I'll have the redstones and brass materials to make it that size. That means I should also get an iriduim ore in just a couple of hours with that size of bore too.