Originally Posted by aldaeron (Post 1514458)

After re-reading my posts I think I am not stating clearly enough to both REV and Mindsensors that you need to post appropriate, preferably independent, test data. That is what builds confidence. I believe the major reason there was widespread adoption of the last two new motor controllers was the public and independent testing done by Alpha and Beta teams. You need to replicate this level of testing if you want to get widespread adoption.


For crying out loud - post the data on your website!!



This should also be on your website. Help convince us you have a great new product. As I have noted in this thread and others, your design does look good, just send data to back it up.

Originally Posted by aldaeron (Post 1514458)

Here's the deal - you had some great looking products last year, but were unable to deliver them due to a variety of issues (our team was bummed to have had to go elsewhere).

Originally Posted by aldaeron (Post 1514458)

Great intentions do not necessarily always come through and you should be a little more aware of well-founded concerns that are raised about such key components as motor controllers. Again, providing test data will assuage many of these fears.

Originally Posted by Greg Needel (Post 1514476)

Yes, we have heard this many times this year, and I am really sorry that it happened. Last year was particularly hard for us as a new company with limited cash flow to purchase inventory. When you combine that with a game that was as perfect as you could imagine for our new products it created a shortage.

What you have said is very true, and we are listening to the concerns. As team mentors ourselves we know and understand the issues deeply as we have seen the same things.

Originally Posted by Greg Needel (Post 1514476)

Thanks for your perspective and thoughts, I really do appreciate it.

Originally Posted by philso (Post 1514331)

Mindsensors - How do the firmware changes for the SD540B (other than removing the undervoltage-lockout safety feature) change it's behaviour relative to the SD540 to account for the increase in efficiency? Has the switching frequency been changed? Have the switching edge rates been changed? ...

Originally Posted by s1900ahon (Post 1516352)

I didn't see any response from Mindsensors on this here, so I'll speculate.

There are two contributors to an efficiency loss. The IR drop due to Rds(on) is one and is the contributor most are familiar with. The other is the refresh of the boot capacitor.

To turn on the high-side MOSFETs, the Vgs must be high enough for efficient conduction, but since the source voltage is also that connected to the motor, it means that the gate voltage relative to ground is greater than the battery voltage (by more than 5V, typically). So, the high-side gate drivers use a capacitor as a source of voltage/current and that cap (the boot cap) is periodically refreshed. This means that when driving the motor at 100%, the gate driver cannot actually drive a high-side MOSFET on for 100%, it is more like 99.9%. The 0.1% is enough to refresh the boot cap.

Since the test setup uses a resistive load and RMS multimeters, the refresh will appear like further IR drop. To figure out the refresh component, a scope can be put across the resistive load and the duty cycle measured.

Some newer gate drivers (like the one announced by TI earlier this year) use an integrated charge pump and can keep a boot cap charged without requiring this loss.

So, Mindsensors *could* have updated their firmware to reduce the refresh time/duty cycle and improve efficiency.

Scott

Originally Posted by philso (Post 1516403)

Thanks for your input, Scott. It is interesting to get your perspective as a power electronics professional.

Originally Posted by s1900ahon (Post 1516419)

Ha ha.. I have to LOL on that comment. I'd hardly give myself that attribute. I'm an embedded semiconductor kind of guy (architecture/hardware/software). My experience with power electronics is due to my being employed at Luminary Micro some years ago who built microcontrollers (MCUs) for use in applications such as motor control. Specifically, you can blame me for Jaguar (he ducks as rotten tomatoes are hurled in his direction).



To be clear, I wasn't suggesting that the Cboot voltage was decaying and affecting the Vgs level on the high-side MOSFETs. Actually, the scenario I was thinking about was that the they were over refreshing and therefore incurring an un-necessary drop in efficiency.

The Cboot cap is charged up when the connected terminal (M+ or M-, there is one Cboot for each) is driven low (the low-side MOSFET is turned on). The cap charges through a diode and current limiting resistor. The Cboot charge time is therefore 3-5 RCboot times. But, the firmware in the MCU controls the timing. If you're curious, check out the Jaguar's published schematics.



Yeah, the under voltage would be the VBUS voltage reduced by a divider circuit to an ADC input, being sampled by firmware, and setting a different trip point value or updated software-based filtering to activate exceptional processing. Also a firmware change (likely).



Agreed. From a pure curiosity perspective, I'd like to see this done for all motor controllers. It would provide some insight into the real power loss (IRds(on)). It is easy to see: connect small resistive load across M+/M-, connect scope to M+ and V-(ground), set output to 100% forward, measure duty cycle and frequency on scope.

Scott

Originally Posted by s1900ahon (Post 1516419)

...employed at Luminary Micro some years ago who built microcontrollers (MCUs) for use in applications such as motor control. Specifically, you can blame me for Jaguar (he ducks as rotten tomatoes are hurled in his direction).

Originally Posted by ozrien (Post 1516453)

Yeah I'm not sure that's fair Scott, that's a bit harsh...
"The first one through the wall always gets bloody." - Moneyball (film)

Before the Jag, CANbus was totally unheard of. And because of the Jag, teams got their first glimpse at what smart motor controllers could do in FRC.

Teams also got exposed to web-based diagnostics through CTRE's 2CAN and Jags. And now the RIO has both web-based diagnostics and CANbus integrated. So I'd say it was a learning curve that benefited several aspects of the control system.

Originally Posted by ozrien (Post 1516453)

Yeah I'm not sure that's fair Scott, that's a bit harsh...
"The first one through the wall always gets bloody." - Moneyball (film)

Originally Posted by s1900ahon (Post 1516736)

True.



Glimpse for some, taste for others, a meal for very few. Rarely does improvement occur when one iteration is allowed (we made improvements to the Jaguar from Grey to Black version, but not significant enough to address the major issues). Believe it or not, we had concepts in mind for an SRX-like design back in 2012, but we couldn't convince TI to allow us to follow on. Well, it probably wound't have sold for what the SRX does had it been allowed.

Anyhow, back to the subject of the thread at hand: I need to find where I put some old power resistors...

Originally Posted by marshall (Post 1516752)

Can you explain the decision behind using RJ11 as the data connector though? I've always wondered about it. Was it just a convenient form factor? Were any other options ever discussed or considered?

Originally Posted by s1900ahon (Post 1516767)

There were other options discussed at the time. We started with different CAN standards (DB9 comes to mind, so does a 2-row square pin header). But we ended up with the 6P4C modular connector. The form factor seemed convenient, the tools could be found cheaply, the parts were available from many places, etc.

I much prefer the current solution provided by the PDP, PCM, roboRIO, etc. The connection is more reliable, no tools needed (finger), and the foot print could fit inside that of a single 6P4C connector (2x2). Mike and Omar have done a great job.