VCU Hardware Decision
Self-Developed VCU
Big Flex
Potentially reducing almost 1kg of weight
Compact Packaging
Customize I/O as needed
Only here for the sake of completeness. Too many drawbacks to realistically consider
High Risk
Huge amount of surplus effort
Way less computing power
Way less complex algorithms possible
Workflow will become much more difficult
Debugging becomes way more difficult
Communication might become unstable
Realistically takes more than one season to establish
Speedgoat Unit
Smaller Packaging Volume
Lighter VCU Box
A lot of weight and volume benefits next season because we won't need to provide backup for Baseline anymore.
Wider temperature range: -40°C to 85°C
We can use Speedgoat Unit for testing in the future even if I fail.
I will still have time to implement new features.
Less computing power (1.6 GHz instead of 2 GHz)
Less time to get to know the current model
CAN FD support on MCM creates extra effort for MCM freelancer and müCM freelancer
Packaging will probably still remain similar if we consider using the backup option.
For backwards compatibility we still need 4x CAN lines und similar packaging space.
Speedgoat Baseline
Low Risk
Possibility to iron out most bugs
More debugging features could be implemented
Data logging could be optimized
Dashboard could be optimized
CAN FD and AMS/CB ethernet connections can be tested on the baseline if we order the corresponding I/O module.
Missed opportunity for Year-over-Year progress
Weight and Packaging
This years VCU model can always be built & loaded within minutes as a backup plan.
We have the mythen Baseline lying around in the shelf.
Options to reduce 2 CAN lines
AMS over Ethernet
Integrating an Ethernet port on the HVPCB isn't that much work. Can be done this season for testing.
We have Know-How on Ethernet implementation from Inverter connection. So I'm assuming AMS to VCU connection
The implementation of CAN FD can still be prepared/tested and then tackled next season.
If we dimension the VCU packaging for the mythen we always have the possibility to swap out the Unit for a Baseline
The need for a separate CAN line with lower baudrate becomes superfluous.
Not certain if CAN load can be balanced
Cable harness weight might not decrease. 2 Can lines less and 1 more ethernet cable.
Medium Risk
Pins left for ethernet connection? Might need another connector on battery box.
Highly dependent on battery module and ET
AMS will integrate an ethernet port for us to test, but it's unlikely that we will use it
There's an existing bug in UDP transmission for inverter temp sensors which has to be fixed in order to not affect the AMS connection
CAN FD
Will suffice to balance the entire CAN load, without having to connect the AMS via Ethernet
The switch to CAN FD would bring bitrate increases up to 8-fold and open up more possibilites in the future.
Hybrid networks should be possible with CAN devices so a step-by-step transition to CAN FD sensors etc. is possible.
Need a new microcontroller and transceiver on MCMs
Model I/O needs to be adapted for CAN FD
CAN communication is tried and tested
CAN-ETH Gateway
Get a third CAN bus by using a CAN-ETH gateway at the ethernet port of the Unit.
Might be possible to package CAN broadcasted messages as UDP packets at Gateway, receive through ethernet port and unpack in VCU model
Might be possible with little data overhead and small speed sacrifices.
Added weight negates the benefits of switching to Unit
Medium Risk
Ideas
Sync GNSS sensor with VCU and GPS using PTP over ethernet.
Logging with a detachable storage medium.
Config files to enable changing parameters without rebuilding the model.
"Smart" Startup Modes for smoother testing and faster workflow at the dynamics.
Improve Telemetry for easier debugging of the car during testing.
Requires
Note
Map 1
500 % 400 % 300 % 200 % 150 % 120 % 100 % 80 % 50 % 20 %