Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[Thalass]

Originally Posted by e*clipse

Ok, file sent.

Ok, now this brings up another issue, kind of an "open source" issue, if you will.
I know this has been dealt with very well by the folks involved with Ubuntu.

How do we do this so Paul can keep blazing ahead with the sensorless and PI parts of the code, without having problems if someone adds a "blinky light" routine?

Should certain parts be "frozen"? Which parts?

- E*clipse

Is the code on github or something similar? With something like that you can roll back to earlier versions. Someone can take the code, mess with it, and then submit it for inclusion in the main codebase. The new code can be checked before being merged into the main branch. (I'm sure y'all know this). It's flexible yet still under control of the main group. (or Paul)

[MPaulHolmes]

By "frozen" on the startup, I really meant "I don't give a crap what happens there because I never mess with that part. haha (laughing intentionally in quotes)" So, feel free to adjust that to include delays for things that are needed so no extra delays are there. I just remember a few years back with the DC controller that when there wasn't at least 0.2 sec or so before A/D measurements happened, the microcontroller started up at probably 1.8v, and was doing A/D conversions WAY before it reached 5v. LOL. My poor beta tester said it felt like the discovered "zero current point" was NOT the zero current point. In fact it was off by 80 amps, which made the car feel like it was taking off by being hit with a small sledge hammer, and I always remembered that lesson.

There is no concern about confusing the throttle or resolver input in the code. YOu have to take a very deliberate step of saying "next time, you will have resolver!", or "next time you will have throttle". I think measuring throttle outside the A/D makes perfect sense. You are absolutely right that it is NOT time critical. Oh no! I just measured throttle position 0.0001 seconds ago, and that is WAY different from now. we are all going to die. hahaha. Awesome idea!!

This may bring up an opportunity - again, just thinking aloud - would it be possible to have certain inputs changable in hardware via jumpers to account for different set-ups?

Yes that is certainly possible! I prefer that option to upgrading the micro. I have been using a through-hole micro, but there are very nice dsPICs where the code would not need to be changed (or almost not at all), and you could do 8 simultaneous A/D conversions instead of 4. The problem is they are TQFP-80, and a fully DIY kit then goes out the window. With my finances, it's not going to happen to have a surface mount board, and have a bunch of boards pick and placed. I can hand-solder down to 0.5mm pitch, but it's not very fun. I think fully DIY needs through-hole, from what I've come to know about people and all the emails I get.

If just that part was soldered, then there's a risk of it getting messed up in shipping, since it should be added after the capacitors. So, if you commit to adding the caps AND the chip, each board has maybe 30 minutes of labor attached.

[MPaulHolmes]

I just started with github, but haven't tried out the fancier features. I think that's a good idea.

[Thalass]

Originally Posted by e*clipse

This may bring up an opportunity - again, just thinking aloud - would it be possible to have certain inputs changable in hardware via jumpers to account for different set-ups? For example, my demo board uses two different sets of uart pins depending on which jumpers are chosen. If jumpers aren't reliable, it seems possible to have different 0 ohm solder in place jumpers, or something.

- E*clipse

Rather than use jumpers, or solder, you could use a DIP switch package like this. Just an option.

[thingstodo]

Originally Posted by Thalass

Rather than use jumpers, or solder, you could use a DIP switch package like this. Just an option.

To summarize the random thoughts below - I could live with DIP switches if they are only looked at during startup, and if there is a way to tell in software what the readings were for the DIP switches during that last startup.

Random stuff to support above statement:

I went through the data sheet briefly. I don't have the mechanical experience to tell whether '10 to 55 Hz, 1.5-mm double amplitude' is good or bad. I expect that vibrations in a car will be both lower than 10 Hz and higher than 55 Hz ... but I don't actually KNOW.

I have dealt with DIP switches for 25 years on hobby stuff and industrial equipment - Rockwell PLCS, Modicon PLCs, various VFDs. They are GREAT to document what option is selected. As a user interface, they are pretty good ... when they are new and reliable.

When they begin to wear, they are NOT so good. They cause intermittent problems (options changing) so you need to look at them only on start-up, for example. And as they wear, they may look like they are CLOSED but are a tiny fraction of an inch away from closed and appear as OPEN to the controller. It helps a lot if there is a way to log what DIP options are selected - so you can tell WHY the thing appears to go crazy once in a while.

My 2 cents, for what it's worth.

[thingstodo]

Originally Posted by e*clipse

This may bring up an opportunity - again, just thinking aloud - would it be possible to have certain inputs changable in hardware via jumpers to account for different set-ups? For example, my demo board uses two different sets of uart pins depending on which jumpers are chosen. If jumpers aren't reliable, it seems possible to have different 0 ohm solder in place jumpers, or something.

If there will be jumpers, is this an opportunity to buffer the inputs with an analog mux?

This is likely a bit more complex part than is needed, but it has a minimum quantity of 1
MAX14661ETI+ Maxim Integrated | Mouser

If the voltage goes out of range, the magic smoke is released from the Mux instead of the dsPIC.

[Thalass]

Originally Posted by thingstodo

To summarize the random thoughts below - I could live with DIP switches if they are only looked at during startup, and if there is a way to tell in software what the readings were for the DIP switches during that last startup.

Random stuff to support above statement:

I went through the data sheet briefly. I don't have the mechanical experience to tell whether '10 to 55 Hz, 1.5-mm double amplitude' is good or bad. I expect that vibrations in a car will be both lower than 10 Hz and higher than 55 Hz ... but I don't actually KNOW.

I have dealt with DIP switches for 25 years on hobby stuff and industrial equipment - Rockwell PLCS, Modicon PLCs, various VFDs. They are GREAT to document what option is selected. As a user interface, they are pretty good ... when they are new and reliable.

When they begin to wear, they are NOT so good. They cause intermittent problems (options changing) so you need to look at them only on start-up, for example. And as they wear, they may look like they are CLOSED but are a tiny fraction of an inch away from closed and appear as OPEN to the controller. It helps a lot if there is a way to log what DIP options are selected - so you can tell WHY the thing appears to go crazy once in a while.

My 2 cents, for what it's worth.

That's fair. I've only ever seen them in that kind of role: Options for startup code to check. Mostly in aircraft secondary equipment (PA systems, etc).

[dave koller]

Not to Brain Fog anyone but I have used rotary BCD (takes four inputs) for years to select options on various embedded microprocessors - some are over 30 years and working still....

Oh I am following along and enjoying your projects!

[e*clipse]

Originally Posted by dave koller

Not to Brain Fog anyone but I have used rotary BCD (takes four inputs) for years to select options on various embedded microprocessors - some are over 30 years and working still....

Oh I am following along and enjoying your projects!

I like the idea of BCD switches - they're a very compact option.

I would agree w/ thingstodo that using switches would be better than jumpers, and in any case should just be for startup/configuration options.

When you consider the vibration/ thermal cycling / etc. that automotive stuff goes through there's a lot of potential for intermittent problems in the future. It's a serious issue for the OE's - I just heard about someone's VW Touareg that acts like it's posessed because of intermittent connections on it's 3 CAN-bus circuits. I also personally dealt with an intermittent connection problem on a 1997 Toyota 4runner that would cause a fairly high level "check engine" OBDII code. This was a simple little analog temperature sensor on the transmission, but it won't pass emmisions without a clear OBDII output.

If the "intended market" for these controllers is DIY folks who will solder everything themselves, then it seems some "solder in" jumpers would work fine, and be reliable in the long run. The odds of an individual changing feedback methods or other major set-up decisions is low, and they can deal with changing the jumper if they do that.

- E*clipse

[MPaulHolmes]

Maybe there could be a separate microcontroller that does all the non time critical stuff that sends the info to the time critical micro? non super-time critical could compute A/D's of throttle, brake A/D pressure switch thing, temperature A/D, DC voltage monitor, UART communication with outside, etc... All stuff that doesn't HAVE to be right this 0.0001 sec. It could even drive an optional 4th half bridge for the boost option. Then the other micro could do current 1, current 2, encoder or resolver, and that's it. boom. FOC with the focus of a ninja. haha. It would have to receive messages but that could be done quickly and reliably.