Help! HVT not sending 2048 EU packets?

  • So I took on my first big high voltage transfer project and I'm a bit confused. I'm using a MFE channeling into a redstone-powered HVT, then over about 150 tiles of 4x insulated iron cable into an unpowered HVT, split into two unpowered MVTs via very short (<10 tiles) lengths of 4xiron cable, which are each adjacent to an unpowered LVT, then into a bank of 16 furnaces via more short (<5 tile) copper wires. I've double checked that the facing of the 3 dots on all transformers is toward the higher voltage. Even using a generous distance of 200 blocks I assumed the energy cost to furnace a stack of something would be about 22,000 EUs since the energy loss for 20k would be (200 * .8) / 2048 or about 8%. It ended up working just fine but taking over 60k EU. From this forum and the wiki I was under the impression that a HVT could only output packets of 2048EU, but this is what I saw with the voltage meter while a couple of the furnaces were operating:


    http://i.imgur.com/wWbI4.jpg


    http://i.imgur.com/OeKkO.jpg



    The machine toward the back connecting with the gold cable is the MFE and although I didn't get a screenshot I'm 100% sure that the 3 dots on the HVT are facing toward the iron cable. I've checked over the entire setup again and again. Even if there were a problem on the receiving end, is there any reason at all that it would be sending what looks like tiny packets of 36 and 39 EU at a time? I tried this also with a MVT in between the MFE and HVT at the beginning, but same result.


    Thanks in advance. I know it has to be something stupid that I'm missing but I'm out of ideas.

  • Work on that MVTF portion. You're loosing ~10% of your transferred power in that section alone!


    Next order of business; put bloody storage devices at the other end of that HVTF link! Even a batbox would soak up the extra energy transferred.

  • The transformer itself buffers the packet for at least 1 tick, the new version will make sure to only request a packet if it fits into that buffer completely.


    Yes /that/ behavior explains all of my earlier observations and also why storage (which can take the extra burst) would work-around the problem.