Kingfish
100 MW
It has been a long time since our last comprehensive summation; therefore let us review what was discussed in brief, and the changes/directions that have manifest as a result.
MPS
Voltage Limit is set to 150V, though the design plan allows for 100V through component loading options.
FET
There has been a tremendous and informative conversation in the past weeks.
Changes to Feature Specification:
These changes are pending. Unless there are concrete reasons to do otherwise I will update the specs by EOD next Monday 11/22.
MPS:
Conversations are too fluid and embryonic for definitive conclusions; no changes.
Actions:
The achievable tasks that we can do with what we know right now are as follows…
MPS:
Develop Prototype Circuit and BOM. Once this has been completed and vetted we should move to Prototype design and layout, consider any pending showstoppers, and then move to limited production for stuffing and evaluation. Call it: "MPS Version 1.00 – ALPHA." :wink:
FET:
We are close to a consensus. We could and should adopt the dedicated motor controller per wheel with a master unit orchestrating the entire show. This would forward a forked development path of 6- and 12-FET boards specifically tailored to meet the lesser and greater needs of all interested factions, including the Off-Board support. It is a lot to bite off and doubles the challenge; though considering the overall epic objectives at stake we’re simply adding one more lap to the 4-lap race. To that end…
Using TO-247/264 onboard, develop a high-level circuit design to submit to the team developing the MCU, and resolve the significant details between (FET) Boards #2 & #3. In addition, we should adopt a different naming convention than #2 & #3; maybe FET Driver & Daughter would be more fitting, yes?
MCU:
I think we are still too fluid in this arena. More discussion is warranted. Consider though…
Now is the time to start putting this together. Let’s divvy this up into functional blocks: MPS, FET to FET, MCU to FETs, and Reserved for future.
Plush Features:
User Experience and Interface should be fleshed out as we move forward, learn, and understand what the hardware will do; we have a good map though we won’t know the topology precisely until we cross that bridge. We’ll continue to accept input. We need to support other developed hardware such as the CA and the BMS et al; conversely - we don’t need to be distracted with the business of re-engineering those wheels.
Questions?
Much appreciated, KF
MPS
Voltage Limit is set to 150V, though the design plan allows for 100V through component loading options.
FET
There has been a tremendous and informative conversation in the past weeks.
- 6- and 12-FET versions discussed; which has priority?
- Drop TO-220 support
- Embrace TO-247
- Provision for Off-Board FETs
- PCB Plating up to 3 or 4 ounces
- Insulated Substrates
- Bus Bars
- FET candidates Categorized:
- 75V: IRFP4368PBF up to 195A, TO-247
- 100V: IRFP4468PBF up to 195A, TO-247
- 150V: XFK360N15T2 up to 360A, TO-264
- Defer Amp demands exceeding spec to Off-Board support.
- Candidates for Off-Board considered:
- MMIX1T550N055T2: 55V, 550A, Square Package
- MMIX1F520N075T2, 75V, 500A, Square Package
- FET Board Architecture examined:
- If 12-FET designed, layout to be two parallel rows of 6 FETs
- Sandwiching configurations: Brief
- Lots of discussion on the concepts at large; generally there are two camps:
- One MCU that does it all up to 2WD
- Central CPU driving dedicated wheel controllers in a 1:1 relationship. This is the leading contender.
- AVR is most often mentioned followed by PIC and ARM.
- Which is better: 8-bit architecture or greater?
Changes to Feature Specification:
These changes are pending. Unless there are concrete reasons to do otherwise I will update the specs by EOD next Monday 11/22.
MPS:
- Maximum voltage = 150V (should be locked)
- Maximum Current: Onboard = 150A; Support greater range Off-Board (should be locked)
- Lock remaining features for Version 1.
- Add Board #2 & #3 derivatives from the Sandwiching configurations discussion but do not lock until we have consensus.
- Add Driver circuitry to spec to support Board #2 option but do not lock.
Conversations are too fluid and embryonic for definitive conclusions; no changes.
Actions:
The achievable tasks that we can do with what we know right now are as follows…
MPS:
Develop Prototype Circuit and BOM. Once this has been completed and vetted we should move to Prototype design and layout, consider any pending showstoppers, and then move to limited production for stuffing and evaluation. Call it: "MPS Version 1.00 – ALPHA." :wink:
FET:
We are close to a consensus. We could and should adopt the dedicated motor controller per wheel with a master unit orchestrating the entire show. This would forward a forked development path of 6- and 12-FET boards specifically tailored to meet the lesser and greater needs of all interested factions, including the Off-Board support. It is a lot to bite off and doubles the challenge; though considering the overall epic objectives at stake we’re simply adding one more lap to the 4-lap race. To that end…
Using TO-247/264 onboard, develop a high-level circuit design to submit to the team developing the MCU, and resolve the significant details between (FET) Boards #2 & #3. In addition, we should adopt a different naming convention than #2 & #3; maybe FET Driver & Daughter would be more fitting, yes?
MCU:
I think we are still too fluid in this arena. More discussion is warranted. Consider though…
- The Tools of Development should be easily obtainable (low cost).
- The programming language is not difficult to master and does not require licensing fees or limitations of use, such as the development of Consumer Interface for parameter modification through whatever device we elect.
- The Device Feature set maps closely to the MCU specification without significant additional hardware support.
- The Device Feature set is not overloaded with or duplicates that of common functionalities with other devices e.g. GPS or Mobile Phone.
Now is the time to start putting this together. Let’s divvy this up into functional blocks: MPS, FET to FET, MCU to FETs, and Reserved for future.
Plush Features:
User Experience and Interface should be fleshed out as we move forward, learn, and understand what the hardware will do; we have a good map though we won’t know the topology precisely until we cross that bridge. We’ll continue to accept input. We need to support other developed hardware such as the CA and the BMS et al; conversely - we don’t need to be distracted with the business of re-engineering those wheels.
Questions?
Much appreciated, KF