Rickys High Power Flexable motor controller

[texaspyro]

I have designed and built lots of systems where failures cost BIG bucks or damage things that you just don't want damaged (like people). Getting a robust set of protections implemented is well worth the effort. Getting them to work in such a way that they don't interfere with normal operation can be a real pain.

You need to look at EVERY single component and decide what happens if it opens/shorts/drifts/gets eaten by elves/gets crapped on by gremlins and how to detect and minimize the damage when (not if) that happens. The same with the code. Every comparison and branch is evil incarnate, just waiting to make your day miserable. Never forget that they are all out to get you.

My capacitive discharge spot welder has a rediculous amount of code and hardware (well over 50%) dedicated to fault monitoring and protection. The idea was to make it so no single point of failure could kill the caps or blow the FETs. Not easy to do considering it tosses around 20,000 amp pulses without breaking a sweat. Well worth the effort, though. It has only fried once (during a test while a protection feature was disabled... can you say Chernobyl?).

My high power (300+ watt) LED dimmer/driver has a similar protection philosophy. It can protect against low or high battery voltage, thermal overload, temperature sensor failure, fan failure, etc. So far it has not killed any LEDs or batteries... either of which is a $50-$200 boo-boo. Not too shabby considering the whole thing fits in 1K of compiled code. Again half of that is protection related.

 

[Ricky_nz]

If the sensorless FOC loses sync or has some other problem (phase unplugged, wrong motor values, etc) what will the controller do? Nothing worse than a controller getting confused and then putting 1000A through a spinning motor. It would be nice if after a problem the motor gently coasts to a stop.

I haven't thought about it too much but at medium and high speed it shouldn't losse sync as thee will be a fairly strong backemf.
At low speed / starting things get more interesting. I still need to choose the low speed startup method but in general the protection will turn off all transistors on serious protection events.

I will be simulating the control algorithms before implementing them so I should have a fair idea before I get them on the bike.

The current control loop will stay working so letting go of the throttle completely results in 0 current in the motor. Excessive current in the motor is also prevented ( HW current limit for too long) will turn off all transistors.
Some thought as to how this interacts with regen and sync loss will need to occur.

I have tested a hard short between 2 phases and the controller kept the currents under control .

I should be able to come up with some form of sync loss detection as well.

It should be possible to detect an open circuit phase wire if the sensed phases show the same current or if one shows zero and the other current. Basically unbalanced currents.

My early tests with minimal protection and fixed frequency resulted in the motor loosing sync if I increased the frequency too fast for the rotor to adapt to the change. In this case the rotor stopped and vibrated. With the additional protections either over current or bus voltage too high result in transistors off which allows the motor to stop in the nicer manor. If these don't catch it the rotor received the current demanded by the throttle input to releasing the throttle resolves the issue. I haven't seen hardware over current unless doing silly things at high average current to begin with.

 

[Ricky_nz]

I have designed and built lots of systems where failures cost BIG bucks or damage things that you just don't want damaged (like people). Getting a robust set of protections implemented is well worth the effort. Getting them to work in such a way that they don't interfere with normal operation can be a real pain.

Yep having people involved really puts a strong focus on safety.

One of the products we develop at work is power conditioning equipment and the rule there is never damage the load where the load is worth many millions.

Kind of glad I don't work in the aerospace industry, the paperwork involved with documenting the protection of their multiply redundant systems must be a nightmare.

You need to look at EVERY single component and decide what happens if it opens/shorts/drifts/gets eaten by elves/gets crapped on by gremlins and how to detect and minimize the damage when (not if) that happens. The same with the code. Every comparison and branch is evil incarnate, just waiting to make your day miserable. Never forget that they are all out to get you.

I know of customers pulling random plugs in a machine not knowing what they were for just trying to test their modbus monitoring connection so the totally unexpected can happen when people are involved :lol:.

My list of protections keeps growing and I definitely need to look at the ones like CNCaddict mentioned as locking the rotor on a bike doing say 50Kph there buy locking the back wheel could be scary/dangerous.
I do not think a 80-100 would be capable of locking bikes rear wheel but some of the bigger motors might.
In reality I think the only sync issues could occur at low speed where the impact is far less but it is correct to ensure should the worst happen the controller does something sensible.

It has only fried once (during a test while a protection feature was disabled... can you say Chernobyl?).

I can imagine the mess :lol:.

I am sure a lot of people underestimate protection but like you say it is really important.
I have no desire to have to replace 12 x IRFB4368 MOSFETS so I'll do everything possible to protect them.
I have actually left the hardware current limit/trip so that it just comes in on the peaks when I command 100A RMS/phase I will push it up some more once I have everything else done.

I am sure some of the cooked modified infineon style controllers on these forums would have survived if they had real processors and protection that could have prevented operation in the bad areas.

I have got to calibrate my temperature sensor and attach it to the heatsink before I bolt the board back onto the heatsink then I will add the temperature protections. I have a second input with the same interface that can be connected to a tiny class bead NTC that can be attached to the motor windings. I have put one of these in my 300W headline motor and they are really fast responding and are tiny so they don't affect the airflow.

With good protection it should also allow more reliable operation right up to the limits.

COnsuming processor time is a problem although the trick is only putting protections that need to be in the PWM rate control loop there and then running the slightly less important ones at say 1ms or evan slower so they are fast enough but not unnecessarily wasting processor time.

 

[texaspyro]

I can imagine the mess :lol:.
...
Consuming processor time is a problem although the trick is only putting protections that need to be in the PWM rate control loop there and then running the slightly less important ones at say 1ms or evan slower so they are fast enough but not unnecessarily wasting processor time.

Actually it only fried the capacitor charging FETs. A simple, but annoying fix. The main FETs have never died. The problem had occurred when I was adding TVS diodes on the output... They were not the proper value and they shorted out. The charger section attempted to charge the short circuit. Didn't go well. I added some code that checks that the cap voltage is rising when the charger is on. It is one of those type of protections that can get in the way of normal operation. I had to tweak it quite a bit so that it did not (which probably lowered its effectiveness quite a bit).


My welder operates off a 10KHz timer interrupt. Everything happens in 100 uS steps... including a 32 bit multiply or two when firing a pulse (it calculates pulse energy in real time and can stop a pulse when the set amount of energy has been delivered). There are a few protection checks done at that rate. Every thing else is done on a time-available basis. Things like thermal monitoring can be done at a very slow rate since temperatures don't change very fast (for a microprocessor).

 

[Ricky_nz]

I added some code that checks that the cap voltage is rising when the charger is on. It is one of those type of protections that can get in the way of normal operation. I had to tweak it quite a bit so that it did not (which probably lowered its effectiveness quite a bit).

Yep trying to track a capacitor with wide tolerance like electros charging is a bit of a pain. Worse if the start point isn't always zero too.

My welder operates off a 10KHz timer interrupt. Everything happens in 100 uS steps... including a 32 bit multiply or two when firing a pulse (it calculates pulse energy in real time and can stop a pulse when the set amount of energy has been delivered).

Ok, similar times to my motor controller then, the PWM and control code is at 12KHz but that may be increased if the code doesn't bloat too much. My code has quite a few adds and multiplies in its control code and will get a few more once the sensor less is added in.
That sounds like a well controlled welder :lol:.
When I think of welding I think of a crude electrical process but these days with tab welders and some of the inverter welders there is a lot more electronics and control becoming involved.

 

[texaspyro]

That sounds like a well controlled welder :lol:.
When I think of welding I think of a crude electrical process but these days with tab welders and some of the inverter welders there is a lot more electronics and control becoming involved.

Yeah, it's a real beast. Basically a tab welder on steroids. It can weld 60 micron gold plated tungsten wire to inconel, or bond 18 gauge steel plate. Some description starts at http://endless-sphere.com/forums/viewtopic.php?f=2&t=2633&start=570#p280216

It does welds by time or energy, it can do inverted DC welding, cutting, anodizing, high current power supply, and even has a battery analyzer mode built in. It's up over 12,000 lines of C code running on an Atmel ATmega 2561 with an LCD touch screen.

 

[Ricky_nz]

I have started getting ready to bring up the USB interface by getting some example code of a CDC driver for the LPC1769 compiling into my application.

I have just been fitting the few parts needed for the USB interface that I only recently got from digikey.
I made a minor mistake on my order from digikey though and got BC857 transistors ok but in SOT 523 rather than SOT 23 . It pays not to do an order in a hurry.

These SOT 523 are tiny little buggers!
View attachment SOT-523.png

Luckily they are the same pin layout and order as SOT-23 so not a problem.

I did have to account for the footprint error on the PCB that I have mentioned previously by rotating the part 120deg. The SOT-523 made good contact with the corners of 2 of the pads and needed a small bridge of solder to connect to the third.
I'll get the correct SOT-23 part next time but even with the smaller part rotated I'm sure its robust enough to use on a bike.

The CDC driver will provide a suitable test of the hardware and USB driver before I begin adding the proper interface.
I will need to adapt my earlier driver for the PC end from my prototype I used with an LPC2378 dev board to handle a few more things but it will make a good basis for the final interface. This driver for the PC is a userspace driver that runs on Libusb so should be portable to windows once I have it finalised but since Linux is a much better development environment so I'll get the majority of the development done before porting over to windows as the changes should be minor.

 

[Ricky_nz]

USB is up .

Below is an excerpt from the log of my develop machine. It shows Linux correctly identifying the example code and choosing the correct driver. Now I need to write my own embedded code that supports the endpoints I need but It will include at least a command line / serial port emulation but also probably a high speed dump facility so I can build it off the example code.
The fact that I got the log entry below confirms its all good.
I have run similar example code on my old LPC2378 dev board so I knew what to expect when it started working.

I still want to get DMA working but under interrupt is enough for now.
The DMA shouldn't be too hard based on my experience with the LPC2378.

I even got the yellow USB up LED to light up .

I had to configure the PLL1 (second PLL) for the USB clock because the main PLL needed incompatible settings to get its clock rates and could not give the required 48MHz for the USB while keeping the CPU at 120MHz.
PLL1 is a bit limited compared to PLL0 so it is more pickey about the crystal frequency used. Remember back when I had to use 12MHz crystals because that's all I had. That change is now permanent as it is impossible to get the correct USB clock using PLL1 and a 20MHz crystal whereas 12MHz works well.

Anyway its 8pm here and I haven't had anything to eat so I better go and cook somthing,

[pre]Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: new full speed USB device using ehci_hcd and address 82
Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: New USB device found, idVendor=ffff, idProduct=0005
Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: Product: USBSerial
Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: Manufacturer: LPCUSB
Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: SerialNumber: DEADC0DE
Feb 20 19:46:05 desktop kernel: usb 1-5.1.4: configuration #1 chosen from 1 choice
Feb 20 19:46:05 desktop kernel: cdc_acm 1-5.1.4:1.0: This device cannot do calls on its own. It is not a modem.
Feb 20 19:46:05 desktop kernel: cdc_acm 1-5.1.4:1.0: ttyACM0: USB ACM device
Feb 20 19:46:05 desktop kernel: usbcore: registered new interface driver cdc_acm
Feb 20 19:46:05 desktop kernel: cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Feb 20 19:46:05 desktop modem-manager: (ttyACM0) opening serial device...[/pre]

 

[texaspyro]

so I better go and cook somthing

FET flambe in a stripped gear reduction sauce... yummm....

 

[Ricky_nz]

so I better go and cook somthing

FET flambe in a stripped gear reduction sauce... yummm....

With a glass of battery acid wine maybe?
umm no thanks,
I prefer my FETs medium rare, not well done :lol:

I'll take steak, eggs and chips with a beer over FET flambe any day

 

[CNCAddict]

Ricky, you're not in Christchurch are you?!

 

[Ricky_nz]

Ricky, you're not in Christchurch are you?!

No, I'm up in Napier so far enough away that I didn't even feel it .
I've got some relatives down that way but so far it sounds like they are ok.

Heres a link to the earthquake drums for NZ (updaes every 10 mins). They have maps of the shaking etc after a new quake.
http://www.geonet.org.nz/earthquake/drums/

Heres the info from the one that did the damage
http://www.geonet.org.nz/earthquake/quakes/3468575g-shaking.html

Napier was the scene of another large destructive earthquake in the 1931 so hopefully we aren't due for one for a while.
http://www.geonet.org.nz/earthquake/historic-earthquakes/top-nz/quake-05.html

 

[kenkad]

Ricky,
I have had this questions for some time, looking at your motor controller thread. I think that others might be interested as well.

Field Oriented Control (Vector Control) and sinusoidal control seem to be similar. I wondered if they deviate because FOC does not require timing advance/retard but sinusoidal control does. Is this a correct assumption? Assuming that sinusoidal control had the timing correction feature, then their efficiencies would be the same? Does this mean that FOC is more easily implemented with Halls and sinusoidal might require optical encoding for stator to rotor positioning? It seems that for the best smooth starting, sinusoidal control with absolute optical encoding would be better than FOC. Can you comment from your experience and understanding on these questions?

Had you considered the Toshiba ARM Cortex M3 (or similar devices) rather than doing your own? If you did, why did you want to do your own? Does sinusoidal control require less processor resources to implement, i.e., does not require DSP capability?

Thank you for answering these questions. I have not seen them addressed before and if they have been, I apologize in advance for asking again.
Kenkad

 

[Ricky_nz]

Hi Kenkad,

Field Oriented Control (Vector Control) and sinusoidal control seem to be similar. I wondered if they deviate because FOC does not require timing advance/retard but sinusoidal control does. Is this a correct assumption? Assuming that sinusoidal control had the timing correction feature, then their efficiencies would be the same? Does this mean that FOC is more easily implemented with Halls and sinusoidal might require optical encoding for stator to rotor positioning? It seems that for the best smooth starting, sinusoidal control with absolute optical encoding would be better than FOC. Can you comment from your experience and understanding on these questions?

- Sinewave is the type of modulation or waveform output to the motor

- FOC / vector control is a method of controlling/generating that modulation pattern.

There is another method called V/Hz which uses a mapping of voltage on the motor to frequency fed to the motor that can generate sinewave. With V/Hz the motor self synchronises to the supplied waveform requiring no sensors but it has limitations.
There is probably other control schemes that use sinewave output and sensors in some ways but doing this and not being FOC would mean that adjusting the sensor timing might work. I imagine these methods would be like the ones used for the squarewave drive.

FOC works best with a position encoder or sensorless. It should be possible to use halls and PLLs but the errors reduce performance. The more accuratly it knows the rotor position the better the torque control is.
Sensorless operation by calculating the rotor position will give a accurate rotor position once working correctly.
FOC allows more control of the motor torque ensuring the maximum available torque. It does this by keeping the current at 90deg to the rotor. In FOC a second current can be introduced in phase with the rotor to perform field weakening to achieve a similar effect to changing the timing. However field weakening has drawbacks as not all motors benefit from it or some motors require very large amounts of current to achieve additional speed and at the same time they lose torque because a significant amount of that current is now not at 90deg to the rotor position ( motor can only handle so much current and if you put it all in phase with the rotor to field weaken then you can't put any into the 90deg part to generate torque.

Another issue with field weakening is at full speed in the field weakened region if the controller was to trip you would get sudden uncontrolled regen through the controllers FETS diodes as without field weakening the motor reverts to its nominal KV causing the backemf to be much higher than the battery voltage when running at speeds above the motors nominal speed.

So yes FOC uses more processor than a crude V/Hz controller but you gain performance. The sensorless part will probably more than double the processor requirement.

The controller power losses should be similar no matter which control algorithm is used for the same output modulation (eg sinnewave) but the power out and response of the motor to changes in operating conditions and throttle would be very different.

Had you considered the Toshiba ARM Cortex M3 (or similar devices) rather than doing your own? If you did, why did you want to do your own? Does sinusoidal control require less processor resources to implement, i.e., does not require DSP capability?
Kenkad

I decided that the LPC1769 cortex M3 processor was suitable based on speed and the peripherals it has ( Hardware motor control PWM on chip) but I also decided that its ADC although ok is not fast enough sampling for what I wanted to do so I chose an external ADC which can sample the current in two phases simultaneously so errors are reduced significantly.
I also added some comparators feeding interrupts and the hardware trip of the PWM module in the processor to allow reliable fault protection mechanisums. Accurate current sampling is important for sensorless operation.

Trying to get the performance for full sensorless FOC requires the right hardware and some efficient coding but does not require a DSP as the benefit is not worth it from what I have seen. Driving RC motors with sensorless FOC is processor intensive because of the high electrical RPMs used. DSPs are good at running over large multitap filters but no so god at other things. A general purpose processor covers everything required for the motor control and also works well for things like communications that can become inefficient on some DSP's. TI have processors with a DSP and an ARM for just this reason.


I also have some other uses for this processor board that are not motor controllers in mind but they don't add any cost to the board if the parts are not fitted.
Part of the project is also a learning exrcise as I work with power electronics but not motor drives.

Hopefully I haven't missed anything.

 

[grindz145]

Thanks for the explanation Ricky! I want all the gory details Have I mentioned this project is amazing? 8)

 

[Ricky_nz]

Thanks for the explanation Ricky! I want all the gory details Have I mentioned this project is amazing? 8)

Hopefully I got it correct :lol:.
Always tricky deciding how to explain some of this stuff, I'm an engineer, not a technical writer :lol:.

I hooked up the USB console interface yesterday.
Since my code is written in C++ using object orientated design it was quite easy to create two independent consoles with their own line editor and hook them up to the same command line parser to handle the commands. All I had to do was write a thin wrapper around the usb put/get char functions to create a class derived from my console base class and then create two objects of the command line class with different console/line editor objects. It sounds worse than what it was but the result is below,

Two independent working command line interfaces
- The one on the left is over USB
- The one on the right is out the debug serial port through an FTDI TTL - Serial lead.

The currents reported on the USB one are bogus at the moment. Small bug in the filter. the temperature and throtle values are wrong as the hardware is not connected yet.
View attachment twin_console_small.png

These two interfaces operate independently and adding them added very little to the flash memory usage but having the two of them needs approx 200bytes more RAM for buffering etc.

Now I need to setup my GUI configuration tool to talk to the USB interface. I had been holding off getting it to work on the serial interface until I decided how to handle the USB but since the interface is now essentially the same for most things I can make a start on that. Being able to set parameters from a gui on the pc is going to be really handy, saving a lot of time in testing.

 

[grandmasterE]

You've progressed it this far at an incredible rate. Keep up the incredible work!

E

 

[Ricky_nz]

You've progressed it this far at an incredible rate. Keep up the incredible work!

Yep, I'm still working on it ,
Forgot to put an update up last week

I have got RMS calculation of the phase currents for display / test purposes working .

I have tested and debugged the DC Bus ripple detection / trip and it seems to be working well.
To test it I intentionally created a situation where the power supply was under powered and connected through wimpy clip leads.
I then slowly increased the phase current and watched the threshold get closer to my trip point and finally when it crossed the threshold all transistors were turned off so it worked as expected . The filters need to be setup in a way that prevents false triggers. I'm not sure how this protection will interact with the batteries internal impedance but the filters are configurable so when I try it on the bike I will know. It should be possible to setup ok as its only to protect the capacitors against excessive high frequency ripple and not DC sag.

I kept the test for the above two features short as I have not reattached the controller to the heat-sink yet as I still want to fit a couple of parts but then again the FETs don't get too hot with short bursts of up to 50A RMS / phase with no heatsink :lol:
Since I'm using my small bench supply again for the ripple testing thats about as much as I can suck out of it with the motor running at a reasonable frequency.

Getting the ripple protection going is good because in doing so I had to get my first order filter block working and that block will see more use shortly.

I have been working on my GUI tool, started adding the parameter read/write code but have decided I need to write a small command queueing mechanism to handle multiple commands from the GUI at once which I started writing yesterday but run out of time to finish (Sleep is such a waste of time but unfortunately so necessary).

I think I might need to get the shielded version of the inductor I used for the Vaux converter to stop some RFI I have noticed on my amateur radio equipment although it could be that I just need to put the motor controller in a shielded box. I also have extra aerials in the form of USB,serial and JTAG cables hanging off the board at the moment that probably don't help the situation.

 

[Ricky_nz]

Just bringing up the throttle and brake inputs,
Time to work around the small design flaw.

On my 12 FET power board these inputs are connected to the micros ADC inputs rather than the external ADC inputs. There is a subtle difference in that the micros ADC inputs are 3.3V whereas the external ADC inputs are 5V.
All ADC inputs are clamped and protected to he correct voltages on the micro board. I must have forgotten which ADC was being used when I did the schematic .

I would put a simple voltage divider on the PCB as a simple mod if it were not for the fact that the throttle line is on an internal layer making adding a series resistor impossible .

In fact I think I will fit pull down resistors on both lines on the PCB and size them as suitable for a voltage divider. Tthen its just a matter of a series resistor for throttles or brakes with 5V outputs. Quite a simple mod that allows use of the existing PCB layout since I have found nothing else wrong with it yet.

Now for the value of the resistors:
a) Must be high enough to not cause issues when used with 5K pot throttles
b) Must not be so high as to make it noise sensitive.

That leaves me with resistors in say the low 100Ks.
The divide ratio doesn't need to be perfect, just good enough to get the whole range of the throttle into the ADC input range. I'm not worried about losing resolution as the ADC is 12 bit. It might make sense to just arrange for the input signal to be divided down slightly more than necessary. From the software side it doesn't mater much as each input has a gain and offset calibration parameter.

Ok so preferring to use more standard resistors I will use 100K for both the pull down and the series resistor.
This approximately halves the input voltage giving me about 2.5V for 5V input. This is fine as at 2.5V in the ADC has 2014 counts which I'm sure is still adequate throttle resolution!
The external resistor can be changed if necessary.
I believe this is also high enough impedance that a 5K pot throttle should not be a problem.

Turned out a very easy modification. The ground pad is next to both the throttle and brake inputs so it was an easy job to solder the two 100K 0805 resistors on.
Looks like I did the same thing I did on the control board. checked througherly the really important stuff and missed a minor error on the side. .



I need to write the throttle interface software to check for "High pedal" type faults on startup etc. I should probably put a small software filter on the input as the ADC is sampled at 12KHz which is way more than necessary for throttle use so a filter will help reduce the affects of noise. I will also leave hooks in the code to make it easy to add throttle response mapping when I get there.


Edit:
Just confirmed that the ADC blkock is correctly reading this input.
The 12 buits of ADC are left justified into a 16 bit word.

These values are for a cheep e-crazyman hall throttle.
RAW adc at min throttle = 9232
RAW adc at max throttle = 43280
back to 12 bit values for comparison
min 577
max 2705
ie 2706 - 577 = 2128 values of throttle which I would assume is adequate .

As a side note I had no problem getting a reliable crimp of the throttle wires to the molex mini-fit pins using nothing more than a pair of bent needle nose pliers. The wire will definitely not pull free. Its just a bit slow to do by hand

 

[CamLight]

Great work!
Looking forward to hearing more as testing continues!

 

[Ricky_nz]

The biggest problem is finding time to work on it when I'm in the mood to do so :lol:
I have now got some software reading the throttle from the ADC driver and doing some filtering.

Planned work for this week:
I think I'll fit the NTC for the heatsink temperature next and the parts to support it. I better write the software to convert the NTC reading to degrees C as well. At the same time I'll add the parts for the motor NTC input and get the software for that going also.

After that I'll add the two transistors for the logic output lines and then the board can be bolted back onto the heat-sink and I can start pushing the current up. 95A RMS/phase is good but it can do better :lol: .
I'm trying to avoid having to bolt and unbolt the PCB/FETS from the heatsink as removing and reinstalling 16 bolts gets boring quickly.

Maybe I should see if I can add the tiny glass bead NTC to my motor without pulling the whole thing apart. Might come in handy when I start pushing the current up. I wonder if there is enough room to thread a couple of thin wires through with the phase wires if I just remove the end plate of the 80-100 (skirt bearing version). I could then through the end with the exposed windings glue the sensor to the windings. I believe at least one bearing isn't perfect but I don't want to bother removing the shaft just yet as this is my spare/test motor, I have a newer one that I will use on the bike.

 

[texaspyro]

Converting thermistor/NTC readings to temperature can be a real pain. It requires lots of calibration, etc. Platinum RTD sensors or IC temp sensors (like the LM34/LM35) are a lot easier to work with. I use the degrees F sensors since they give a higher resolution per count than celsius sensors.

And rememeber that with the TO92 case sensors, most of the heat input to the die is via the leads. In my LED driver, I attach leave the leads long and attach the sensor to the LED with home made thermal epoxy. I have used epoxy filled with aluminum oxide, but have switched to silicon carbide or diamond dust since they have much better thermal conductivity. 1 micron diamond dust can be had for $1/gram. It is the best thermal conductor in the world. 1500 grit silicon carbide is less than $10/pound. Aluminum oxide is under $5/pound.

 

[Ricky_nz]

Yes those TO92 sensors are good probably a better option for the heatsink temperature.
I used the NTC for the motor due to its size and only 2 leads. Was just going to use a NTC for the heatsink because once the code is written it isn't a major issue and I already had a few devices handy.
The board only has 2 pins for the heat sink sensor but there is +5V nearby so no problem to connect one of those LM 34/35 devices if needed. The device is on leads anyway as there is no other way to get it near the center of the heatsink. I will need to keep an eye out for noise though.

I have written the shell of the temperature sensor code so it can be configured for either temperature sensor type with a parameter so shouldn't give too many issues. I'm not looking for super accuracy, just how close to melt down things are. Just need to add the maths part now.

Good to know about home made thermal epoxy. Probably a good way to attach to the motor windings. The last NTC I added to a motor was epoxied by its leads and a small amount of thermal compound between its glass bead and the end wind so not ideal but it worked.

 

[texaspyro]

PT100/PT1000, etc platinum RTDs interface is a lot like thermistors, but they have a nice linear response. For the short leads of an ebike a two wire connection should be fine. They can be had for a couple bucks each for 0.2% accurate ones. Only issue is the cheap/easy to find ones tend to be mounted in a 5x30mm tube.

 

[Ricky_nz]

I'm a bit annoyed today....

Was planning on ordering a few parts from digikey today but as of 4:30am some twat (putting it very politely) tried to use my credit card number on 3 or 4 overseas websites all declined (between $90 and $520 ) but the bank fraud detection immediately locked down my card. It will be 3 - 5 days to I get a new one Grrrrr!!! so basically due to weekends that probably puts the parts I wanted back a week based on typical delivery times from digikey

At least there is other things to work on so not a major issue but always annoying when something interrupts your plan of attack.