@subcritacal71
I think that is already in use in sort of state of the art BMS management.
Thinking out of the box is good
That's no problem. In my ES there would be 4 buckets of water, and I can virtually split them by attaching post-it notes to each; I would label 2 buckets "H", and the other 2 "K"... what if you could take a battery, virtually split it in two using the controller (say an ES-H and ES-K). This would be a dynamic allocation of the cells. For example 2MJ for ES-H and 2 MJ for ES-K (SOC).
I can move one of the "K" buckets under the incoming pipe when harvesting from the MGU-KCharge the ES-K from the K (2 MJ limit)
That's ok too. There are no limits on moving the buckets around in the ES, and I can change the labels to read whatever I wantand then under certain conditions, re-allocate the battery cells instead of transferring energy, either partially or fully (a sort of ES <> ES transfer but by way of re-allocation). I don't see a limit on ES to ES transfers.
I need a bit of help on this bit. I think I understand what you mean; you're referring back to the original topic of transferring energy via intermediate componentsThis would minimize losses and time incurred by cycling the H (for the K -> H -> ES route), for example. This would ensure that on tracks where the K can send its full 2 MJ of energy from the K straight to the battery, and then reused wherever they desire (either the H or the K). It could also be used the other way, H charges its 2MJ to ES-H, reallocates it to the ES-K, do this twice a lap, therefore 4MJ delivered to the K with minimal losses.
After I wrote the above I was having a look at a very interesting paper regarding dynamic allocation of battery cells. (http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf) and came to the same thought as you did (bolded and italic'd above). If you are not allocating all of the cells at once then you could 'cool' the unused ones.Dr. Acula wrote: ↑31 Jul 2018, 17:52This wouldn't make much sense.subcritical71 wrote: ↑31 Jul 2018, 17:07I just had a random thought. I don't know how battery construction works or how two virtual batteries might work. But, what if you could take a battery, virtually split it in two using the controller (say an ES-H and ES-K). This would be a dynamic allocation of the cells. For example 2MJ for ES-H and 2 MJ for ES-K (SOC). Charge the ES-K from the K (2 MJ limit) and then under certain conditions, re-allocate the battery cells instead of transferring energy, either partially or fully (a sort of ES <> ES transfer but by way of re-allocation). I don't see a limit on ES to ES transfers. This would minimize losses and time incurred by cycling the H (for the K -> H -> ES route), for example. This would ensure that on tracks where the K can send its full 2 MJ of energy from the K straight to the battery, and then reused wherever they desire (either the H or the K). It could also be used the other way, H charges its 2MJ to ES-H, reallocates it to the ES-K, do this twice a lap, therefore 4MJ delivered to the K with minimal losses.Red Rock Mutley wrote: ↑30 Jul 2018, 16:28The flow diagram would look something like this
http://s50.photobucket.com/user/3874619 ... u.png.html
What do you think? Has this been covered already? I'm sure there are other strategies that could be used that I haven't thought of.
The ES is made up of a multitude of individual cells anyway. With the voltage the MG-Units working in F1 it must be atleast several hundred, because every individual Cell will only give you a voltage of about 3.7 Volt. So you have to manage the whole Pack anyway and technically it doesn't make much difference for the energy managment software if you have one big pile of cells or two smaller piles.
One intresting aspect is the thermal managment though. If one pile alone is able to deliver the necessary voltage the MG-units need, you gain time to cool the other down which means you can get away with a smaller and lighter cooling system for the ES.
And not all need to be allocated. There could be spare cells in case of failures and over-temperature conditions. I was using two cells (buckets) as an example but in real life it would be hundreds, maybe thousands of buckets). The paper I read after writing the above talks about dynamically allocating cells to deliver the optimized voltage for whatever operation you are performing at the time. For example, charging and discharging rates based on the consumer or producer. They used 5 and 10 second monitoring, but I could imagine that could be increased for finer control.Red Rock Mutley wrote: ↑31 Jul 2018, 20:11That's ok too. There are no limits on moving the buckets around in the ES, and I can change the labels to read whatever I wantsubcritical71 wrote: ↑31 Jul 2018, 17:07and then under certain conditions, re-allocate the battery cells instead of transferring energy, either partially or fully (a sort of ES <> ES transfer but by way of re-allocation). I don't see a limit on ES to ES transfers.
subcritical71 wrote: ↑31 Jul 2018, 17:07This would minimize losses and time incurred by cycling the H (for the K -> H -> ES route), for example. This would ensure that on tracks where the K can send its full 2 MJ of energy from the K straight to the battery, and then reused wherever they desire (either the H or the K). It could also be used the other way, H charges its 2MJ to ES-H, reallocates it to the ES-K, do this twice a lap, therefore 4MJ delivered to the K with minimal losses.
Maybe a better way of explaining it is from the MGU-H side. You could use the MGU-H to charge the ES-H battery until fully charged. We'll assume the ES-K was fully charged. After the MGU-K deploys those 2 MJ from the ES-K the ES-H now becomes the ES-K, therefore there are 2 MJ more the MGU-K can use. While the MGU-K is consuming the 2 MJ that originally started in the ES-H, the MGU-H is now charging the empty ES-H (which used to be the ES-K)... wow, there is no way your going to follow what is going on in this head of mine! This switching and optimization of the number of cells 'connected' can put the respective batteries at their peak efficiencies(?)Red Rock Mutley wrote: ↑31 Jul 2018, 20:11I need a bit of help on this bit. I think I understand what you mean; you're referring back to the original topic of transferring energy via intermediate components
If I understand you correctly, you're scheme uses the pipe between the ES and the MGU-K to transfer water to and from the ES in the conventional way. Unfortunately that's the pipe where the bottle neck is. It's limited to a maximum of 4 buckets of water out of the ES per lap, and maximum of 2 buckets in
This is already solved with the switching of the MGU-H between harvest and generating like Honda use, isn't it?Red Rock Mutley wrote: ↑31 Jul 2018, 20:11The point with the MGU-H is it's connected to both the ES and the MGU-K by separate pipes, and crucially those separate pipes have no limits; as much water can through those pipes as you like. So, to exceed the 4/2 buckets of water per lap limits, there needs to be a way of connecting the MGU-H pipes together and then you can flow as much water as you like between the ES and the MGU-K
subcritical71 wrote: ↑31 Jul 2018, 21:13
You could use the MGU-H to charge the ES-H battery until fully charged
That's a good point, batteries are fundamentally a chemical process, they deliver more energy when warm and conversely, accept more energy when cold (when the internal resistance is lower). There's a mismatch in efficiency between charge and discharge. I can see there's a potential gain by segmenting the battery, allocating one half to charge and the other to discharge. Actively cool the charge segment, while letting the discharge segment heat up. Then swap the segments
I can’t know whether all the manufacturers use the “extra” routes.Red Rock Mutley wrote: ↑07 Aug 2018, 14:51Do we think all the engine manufacturers are using extra harvest & extra deployment?
We know from the Christmas 2017 magazine interview that Honda are at least performing the extra harvest. Skip forward a couple of design and qualification cycles and that's pretty much around the time the Ferrari engine showed signs of extra deployment. Presumably Renault now know the trick via their association with McLaren. That leaves Mercedes. I can't remember, was it them who estimated Ferrari needed 4.5MJ deployment to match their speed profile
While I’m here, I need to credit muramasa. It took ages of scrolling back through the Honda engine thread to find the source so I’ll post the link here viewtopic.php?f=4&t=18874&start=13440#p749725
Those MGU deployment graphs make fascinating reading, particularly the MGU-K trace tending towards the throttle trace. Don't know why it hadn't dawned on me before, but I've always read "full deployment" to read "using all available battery power" as opposed to "operating the MGU-K at full power all the time"
Yes, presumably it is track specific, although I don't know with Silverstone, there's a lot of part-throttle time. Looking at the published figures it's conceivable they exceed 2MJ MGU-K harvest
How much of that 11s is heavy enough to allow 120kW harvest from the rear wheels?Red Rock Mutley wrote: ↑08 Aug 2018, 13:24Brembo give a brake time of 11.5s per lap. So that's 11.5s x 120W = 1.38 MJ under braking
With every lap, brakes are used 8 times, but in 3 of the bends drivers rely on their brakes for less than 7 tenths of a second.
All told, the braking system is used for 11 and a half seconds in each lap, amounting to 14% of the entire duration of the race.
Even maximum deceleration is affected by the reduced need to slam on the brakes: the average value per lap is 3.6 g due to turn 10 and the curve right after, since deceleration does not even get to 3 g for either of these bends.
All this means that only a moderate amount of energy is dissipated in braking compared to other tracks: 103 kWh, half as much as the Budapest track and Singapore.
www.brembo.com/en/company/news/formula ... bo-brakes