- Login or Register
No account yet? Sign up
Honda F1 project leader Yusuke Hasegawa has outlined a number of reasons why Honda has been struggling so badly in the beginning of the 2017 Formula One season. He confirmed that lots of problems were not discovered while running on the dynamo meter.
Wazari wrote:McLaren Honda will not be taking any 2015 ICE or PU's to Barcelona, only new 2016 PU's.
Oh sorry, I didn't see the above article when I posted this originally.
The teams already have their own "what if" analytical and predictive PU software. On the actual implementation of the software though, Arai admitted that the way the PU was mapped was a big weakness at the start of the 2015 season. They duly sorted it out, but of course software is not the real differentiator here. The good old hardware and how you use the software to manage it is the limitation. If you don't have the hardware and application knowledge, all the best software can't help and vice versa. See Mercedes customer teams; same software, different programming, different PU performance. And as for hardware side, I think if you ran and tuned the Honda PU on the Mercerdes programs you won't get much more out of it than what the Honda tuners got on their programs.Postmoe wrote:I'm thinking about the software they need to develop the car holistically, not the ECU.taperoo2k wrote:I believe teams can run their own code on the ECU but it has to be FIA approved and is restricted so a team can't develop software that controls traction as an example. Everything else is to do with the ECU is locked down. McLaren do have expertise in software, so that's not really an issue for them. No idea if Honda do the PU maps themselves or get help from McLaren via data mining the data collected during races.Del Boy wrote:
I may be wrong in my interpretation, but I thought software has to FIA approved and be used in the standard FIA designated (supplied by McLaren electronics) ECU.
2016 technical regulations 8.2.1 Control electronics
They cannot use an excel sheet, they need some kind o ERP-like tool to manage the different layers of information from the different teams, only for the engine.
If combustion is key to harvesting, they need to manage several equilibriums. The way I see it, they need a solid sofware only for tuning the engine for a specific GP, with what if scenarios, analytics, etc. I mean... if not, they would need to gather info from the ICE guys, then the MGU guys, then the fuel guys... nightmarish.
Technically, there is nothing avoiding you to put middleware to link the ECU system to this development tool, as long as you don't touch the code.
Yes, but I'm not talking so much about mapping. This would be the most basic layer and that is easy to develop, since it's only an evolution from the classical approach. I'm thinking more about organizational software dedicated to the development of the car, specially for the engine part. It's more about workflows, coordination on the go and so on. And that is extremely important, because those engines are way more complex than in the V8 era.PlatinumZealot wrote:The teams already have their own "what if" analytical and predictive PU software. On the actual implementation of the software though, Arai admitted that the way the PU was mapped was a big weakness at the start of the 2015 season. They duly sorted it out, but of course software is not the real differentiator here. The good old hardware and how you use the software to manage it is the limitation. If you don't have the hardware and application knowledge, all the best software can't help and vice versa. See Mercedes customer teams; same software, different programming, different PU performance. And as for hardware side, I think if you ran and tuned the Honda PU on the Mercerdes programs you won't get much more out of it than what the Honda tuners got on their programs.Postmoe wrote:I'm thinking about the software they need to develop the car holistically, not the ECU.taperoo2k wrote:
I believe teams can run their own code on the ECU but it has to be FIA approved and is restricted so a team can't develop software that controls traction as an example. Everything else is to do with the ECU is locked down. McLaren do have expertise in software, so that's not really an issue for them. No idea if Honda do the PU maps themselves or get help from McLaren via data mining the data collected during races.
They cannot use an excel sheet, they need some kind o ERP-like tool to manage the different layers of information from the different teams, only for the engine.
If combustion is key to harvesting, they need to manage several equilibriums. The way I see it, they need a solid sofware only for tuning the engine for a specific GP, with what if scenarios, analytics, etc. I mean... if not, they would need to gather info from the ICE guys, then the MGU guys, then the fuel guys... nightmarish.
Technically, there is nothing avoiding you to put middleware to link the ECU system to this development tool, as long as you don't touch the code.
Why do you believe it's impossible? There has to be an inverter and it would be between both motor/generators and the battery.godlameroso wrote:The problem may be electronic hardware related. It's much more efficient to send high voltage than high current, and that may be a limiting factor. The batteries are probably limited to about 5-600 volts, and that's not really the issue. The issue is being able to send high voltage to the MGU-K from the H at the 1,000 volt limit while maintaining 5-600 volts at the battery would be very very difficult, probably impossible. The increase in efficiency would be tremendous because you can lower resistance by increasing voltage and reducing current.
There is little to be gained by running higher voltages when the efficiencies are already close to 100%. The losses avoided by increasing the voltage are mostly I squared R (resistive heating) losses.godlameroso wrote:Sure the cabling is not leaking much but I'm talking about the controllers, non of them are even capable of handling 700 volts let alone 1,000.
Only if they are running an AC motor in the MGU's - if it's all DC then you dont need and inverter (merely voltage regulation).Del Boy wrote: Why do you believe it's impossible? There has to be an inverter and it would be between both motor/generators and the battery.
They are. All the photos show 3 (heavy gauge) cables to each MGU.djos wrote:Only if they are running an AC motor in the MGU'sDel Boy wrote: Why do you believe it's impossible? There has to be an inverter and it would be between both motor/generators and the battery.
Cheers, I wasnt sure.gruntguru wrote: They are. All the photos show 3 (heavy gauge) cables to each MGU.
BTW "Brushless DC" is also actually an AC motor.
For sure but in this case the 3rd cable will be a 2nd phase, not earth as in your home AC wiring (Active, Neutral & Earth).gruntguru wrote:Sure, but a good indication - especially if all three are the same gauge. Check the Andy Cowell video if you haven't already. (I added a link to the post above.)