Not simple BLDC controller It RUNS! :)

texaspyro said:
Lebowski said:
An example when this happens: when you've come to a stop at a traffic light....

Stop? Trafic light? Yeah, like that's gonna happen... :twisted:

Pyro, thanks for this post. It was on the screen as I laced a wheel yesterday, and I looked up and laughed almost every other spoke, (and am still laughing). :lol: I do usually avoid stopping except at each end of most rides, although sometimes I stop to yell at someone who cuts me off getting into a parking lot.....

But, you have to remember that Lebowski has to deal with much tougher law enforcement than we in northamerica, so he ALWAYS complies with ALL laws, rules, and regulations. :wink:

You probably do stop to charge or change your batteries at least, right? On those rare occasions, it is nice to be able to get going again, without pedaling?

Bob
 
oldswamm said:
But, you have to remember that Lebowski has to deal with much tougher law enforcement than we in northamerica, so he ALWAYS complies with ALL laws, rules, and regulations. :wink:

Yesterday with the car I had to go through a police roadblock where police were carrying MP5's :shock: I think they were looking
for a bankrobber or something.... Felt very Afganistan for a moment.

Yesterday got the ADC's working and also managed to control a '41100', a digital potentiometer for gain-control. Plan: the 30F will
ask you to spin the motor. It will then do automatic gain control on the back-emf voltage to measure the waveforms. After
this I plan to run a cross-correlation algorithm to determine the phase-relationships between the back-emf and the hall sensors.

Still thinking about how to make the waveform for the controller output. I want to use the back-emf waveform for this but I think
the measurement of the waveforms will not be too accurate. I can either filter it or determine the phase / amplitudes for the
first 9 (or so) fundamentals (only odd ones of course)...
 
oldswamm said:
You probably do stop to charge or change your batteries at least, right? On those rare occasions, it is nice to be able to get going again, without pedaling?

Nope, I've gone plug-in and have a 20 mile extension cord... :roll:

Actually, I have a pair of Weinmann concave rims on my meat powered bike. They have WELL over 60,000 miles on them (installed them around 1978). They look brand new, no detectable wear. The only reason I've ever changed brake pads is because the rubber turned to glass.
 
captured back-EMF waveforms in relation to hall sensors...

Screenshot.jpg

the 0 to 127 on the x-axis corresponds to 0-359 degrees (or the 0-1 of the staircase plot / sawtooth plot of a few days ago).
Memory use for this is 768 bytes of RAM.

think I will extend the program a bit so it captures around 3 versions of each waveform and calculate the average. Then I need
a routine to calculate a sine / cosine wave array (in assembly :D know already how to do this) and compute all the cross correlations
to arrive at one number that indicates the phase relationship with the halls. So much work for just 3 numbers :? :D
 
Lebowski said:
captured back-EMF waveforms in relation to hall sensors...
Am i missing something or is my iphone not showing the whole pic ? I cant see the hall capture??
 
Managed to get the DSP going :D and to write a routine for computing a sine/cosine wave and computing cross correlations.

fundamental.jpg

Some simplified theory about cross correlation... Calculating a cross correlation comes down to trying to find a patern
in an unknown signal. Here our unknown signal is the sampled back-EMF of the motor (white line in top graph). The red
signal in the top graph is the perfect sinewave we're trying to 'find' in the back-EMF signal.

The white signal is multiplied with the red signal and the whole bunch is integrated to end up with one single number.
Then the red signal is shifted to the right by 1 unit (360/128 degrees) and the multiplication/integration
is repeated to yield a second number. This is repeated 128 times until we've shifted the red signal over all the positions.

The 128 numbers we calculated in this way are then plotted in the bottom graph. Our unknown and known signals match
the best when the calculated number is maximum, in the bottom graph this is around 29 on the x-axis meaning we have
to shift our red signal (of the top plot) 29 positions to the right to get the best match with the white signal (the back-EMF).

In motor terms: the peak of the back-EMF of motor phase A is (29/128)*360 = 82 degrees after the rising edge of hall sensor 1.

The algorithm seems very elaborate, why not look for the peak in the back-emf signal and be done with it ? The clou is that
this cross correlation algorithm also works for very crappy signals. If for some reason the 30F only manages to sample about
half of the back-EMF signal (so we have lot's of 'holes' in our data, maybe due to a very fast spinning motor) the cross
correlation algorithm will still work reliably. I tried it with only 20 valid samples in the back-emf waveform (so 108 missing
measurements) and it still yields the same result (a shift of 82 degrees).

In the same way we can try to match a faster red signal with the back-EMF signal to see the harmonics.

third.jpg

This is for a 3-rd order harmonics (the red signal is 3 times as fast as the back-emf one). Apparently the match is the
best when we shift the red curve (9/128)*360 = 25 degrees. The peak is around 0.7 (while that of the original was 62.
This is also the ratio of the amplitudes.

So, if we want to 'reconstruct' the back-EMF waveform we need a sinewave shifted over 82 degrees and a three times
as fast sinewave shifted over (3 times) 25 degrees with an amplitude (0.7/62)=0.011 times that of the main sinewave.
This allows the reconstruction of the back-EMF waveform EVEN WHEN WE ONLY HAVE A CRAPPY ORIGINAL MEASUREMENT !

for fun I also tried to match the fifth and second order:



the amplitude of the fifth order harmonic is even smaller than the 3rd

second.jpg

the second order is even smaller which makes sense as the back-emf is supposed to be symmetrical...

P.S. and remember, all this nonsence is programmed in assembly :D there is no 'intelligence' on the PC side, all graphs
here are directly plotted data coming over rs232 from the 30 F. The finished controller will be able to do all the calibration,
computations, back-EMF reconstruction etc etc shown here without needing a PC....
 
Well, this is a one time calculation only necessary for calibration. During calibration you give
the motor a good yank to get is spinning, then the 30F will determine all hall positions w.r.t. each
other and determine all back-EMF signals w.r.t. the hall signals.

This last bit is what the cross correlations are about. The 82 degrees from my previous post will be
stored in EEPROM and be used when the 30F is working as a motor controller. The 82 degrees is
every specific for my motor (and only for one phase wire of my motor), your motor will have a
different 'offset' between hall sensors and back EMF. The other two phases for my motor are
at 197 and 321 degrees... not completely 120 degrees apart but close enough (for a homemade
axial flux motor :D )

If we figure out all phase and amplitude relations during calibration and store these in EEPROM
we can use this to re-contruct the back-emf waveform and using this as the driving waveform
during motor controller operation.So in effect we will then 'feed' the motor with it's own waveform.
 
Very cool great work lebokski!

Are you sure you can just free spin it or should it be held at a steady rpm? Can this be used to determin the phase shift caused by inductance vs rpm?
 
WOW, you guys are putting incredible stuff on the horizon. I need to get on the stick preparing a bike that will do justice for the controller(s) you develop. Please let me know if I can help in either a financial or materials contribution sense, because other than as a beta tester I don't have the skill set to contribute technically.
 
oldswamm said:
Ditto from me too, Lebowski. :D

I've been working on add on circuitry for commercial controllers and slow (hub) motors, which will have auto sensored/sensorless switching, as well as auto hall sensor learning.
Other functions I intend to implement are serial to/from the controller units, handlebar unit, lighting controller, BMS, and any other functions (such as a brake interface).
The handlebar unit will include the basic CA functions, the ability to 'reprogram' the controller units, and inputs for more controls than almost anyone could want. I'm also working on interfacing to LED arrays such as in 'moving' signs (bright green, red, or orange 2-1/2" characters) as an alternative to the standard LCD interface.
A board in the hub for an interface for the halls as well as 3 thermistors, 2 in the windings, a fan control, and 6 tach inputs for fans. (edit: using the 3 hall wires as a 3bit parallel interface, and 12v on the red wire)
I want the ability to control 2WD and 3way (intelligently :wink: . )
Lighting control , including turn signals.
Thermal current limiting (temp sensors on the mosfets too).
I would also LIKE to implement skid/spin control (what I got interested in controller design for :shock: !), eventually including electronic brake control, integrating regen and electric brakes. Would include AFB (anti flip braking :) ), and a wheelie eliminator (selectable). I think I would need use hall sensors on the suspensions. Can't see a G sensor (tilt/tip) working (at least not easily).
edit: Forgot about timing, which will partially compensate for processing the halls through 2 processors, as well as poorly timed halls. :)
Bob

Great features Bob. Would AFB be a wheelie riding enabler, or are you talking about anti front flipping? Also, sensors on the suspension would seem extremely hard for it to distinguish between bumpy road conditions and bike lifting issues.
 
OK So I got all the things in to try to whip this up (if I can get it to work on bread board) But where do I want to get sockets for the header pins? I just got a bunch of stips of pins from digikey but I hate using them to much money and way to much for shipping!
 
Arlo1 said:
Very cool great work lebokski!

Are you sure you can just free spin it or should it be held at a steady rpm? Can this be used to determin the phase shift caused by inductance vs rpm?

Well, during the calibration phase the output stage is switched off, the idea is you just give the motor a push.
With a bicycle wheel motor this is easy. For a turnegy 80-100, you make it spin via the transmission or
with a piece of rope (like the starter chord of a lawnmower).

About the phase-shift due to inductance vs rpm, the plan is to have the controller deal with that automatically
(so automatic advance)
 
Have you guys thought about locked rotor programing. I've blown FETs twice that way. :oops: The first time I tried to power the rear wheel over a pallet (my dog's patio), with 50# of sla on the rear wheel, and at least one third throttle on a stock 22A controller, but I just took out mosfets in a modified infineon controller that I don't think should have happened. Very little throttle, better mosfets and capacitors, and almost no weight on the rear wheel (I was standing pushing on the handlebars, and have LiPo up forward). I suspect what happened was it started up, shut down, then rolled back, which may have caused an unpredictable switching sequence. Took out FETs in 2 high side and 2 low side phases.

John in CR said:
Great features Bob. Would AFB be a wheelie riding enabler, or are you talking about anti front flipping? Also, sensors on the suspension would seem extremely hard for it to distinguish between bumpy road conditions and bike lifting issues.

AFB would be braking, don't know what wheelie control would be called. I haven't given much thought to that part yet. I capitalized 'LIKE' to indicate it was for the future. :) I expect that the segway (sp?) uses g sensors, and I think there's a project somewhere for unicycles, but hi g acceleration would probably make it (even) more difficult. Would do a bunch of research before I take it that far. It would be neat to have a programmable wheelie feature. :wink:
Obviously, with the front wheel off the ground and using suspension sensors only, the processor couldn't tell the bikes attitude, but if one suspension is 'stopping' intermittently while fully extended, and the other is compressed, that wheel is just leaving the ground and either the throttle or brake could be backed off. If both leave the ground it's a jump. :lol:
I'm still waiting for some parts (got the extended temp processors for the 'in hub' unit yesterday), and am waiting for a laser printer (which is coming parcel post :( ) so I can make the PC boards.....
If I get to basic anti spin this winter I'll be doing good (if either tire accelerates faster than a table derived from maximum acceleration on dry asphalt, and/or if one tire is turning significantly faster than the other (assuming the brakes aren't on), it's spinning). :wink:
This project will take me a while... Also have to finish the controllers, mod the motors, and even build a bike up, before I can really test most features. First step will be to get a wheel to turn under control of the throttle, (through the serial link). :wink: :)
I'll start a topic in a few weeks, when I have something to show (didn't mean to hijack Arlo's thread.)
Bob
 
oldswamm said:
Have you guys thought about locked rotor programing. I've blown FETs twice that way. :oops: The first time I tried to power the rear wheel over a pallet (my dog's patio), with 50# of sla on the rear wheel, and at least one third throttle on a stock 22A controller, but I just took out mosfets in a modified infineon controller that I don't think should have happened. Very little throttle, better mosfets and capacitors, and almost no weight on the rear wheel (I was standing pushing on the handlebars, and have LiPo up forward). I suspect what happened was it started up, shut down, then rolled back, which may have caused an unpredictable switching sequence. Took out FETs in 2 high side and 2 low side phases.
With phase amp monitering you should not need to worry about locked rotor problems!
 
Probably true.
But, the current will be calculated based on the assumption that each phase only sees a 33% duty cycle, so the junction temp could rise rapidly.
Also, and I know you're not likely to write the program so it's possible, but I suspect the last infineon I blew was a shoot through caused by the motor turning backward while being driven forward. Worth giving a few moments thought when you write the code. :)
Bob
 
for automatic timing advance it's necessary to measure 2 of the 3 motor currents, from 2 you can reconstruct
the phase angle and amplitude of the current vector. Then you can build a control loop on the phase angle which
realises the automatic timing advance. A control loop on the amplitude will be the current (torgue) based
throttle... at the moment I'm busy with the TUI (Text based User Interface :D not the german travel agency)

The TUI will be a simple text based interface. The connection to the controller is over RS232, on the PC
side there is just a simple terminal program. An example of some output of the TUI (work in progresss of course):

View attachment tui.txt.zip

I made it such that it is all text-based. You can ask for graphical data, in this case the 30F will respond by
outputing a table (as can be seen in the tui.txt file). You can then select the table data and paste it in
a spreadsheet program like Excel or LibreOffice Calsc (ubuntu). Here is an example plot of the Hall sensor
data of the tui.txt file:



All graphical data is outputed in 128 lines representing 0 to 359 degrees of the motor phase. To prevent
the digital signals overlapping in the graph I gave 'm slightly different amplitudes.

In the plot you can see I did a crappy job of glueing in the hall sensors. As said before, one is glued
in backwards and apparently they're not evenly spaced either :oops:
 
oldswamm said:
Probably true.
But, the current will be calculated based on the assumption that each phase only sees a 33% duty cycle, so the junction temp could rise rapidly.
Also, and I know you're not likely to write the program so it's possible, but I suspect the last infineon I blew was a shoot through caused by the motor turning backward while being driven forward. Worth giving a few moments thought when you write the code. :)
Bob
Yup i will but you also must note the phase amp sensors will fead a Sd pin on the fet driver through a flipflop so if over current is found once the sd pin will be triggered then the fet driver will stay off for the rest of the cycle!
 
It would stay off for the rest of the PWM cycle, (normal operation right?), but to be safe with a locked rotor, it would have to stay off, or be farther limited, for the rest of the commutation cycle, wouldn't it?
 
oldswamm said:
It would stay off for the rest of the PWM cycle, (normal operation right?), but to be safe with a locked rotor, it would have to stay off, or be farther limited, for the rest of the commutation cycle, wouldn't it?
A locked rotor should be no problem the whole idea is to limit the pwm on vs off time so with a stall condition or locked rotor you do not exceed the max you want while using the sd pin for a condition like a shorted wire or overtemp condition. Rember the inductance in the motor slows the amp ramp up so as long as you program a limit for pwm on time it should be ok.
 
SO I have 15 IRFB4668pfb mosfets on order. The nice chick in future electronics canada let me get them for 4.20 ea and she is trying to get me more samples so I can do more. I told her I plan to order >100 a year in the future if they test ok. Group buy? They seem not to bad spec wise!
 
What do you guys think, are there any options I missed for tuning a controller ?
This is the output of my controller (over rs232 to a simple terminal program)
in calibration mode. The tables can be copied to a spreadsheet program to display graphs...
The lines with '----->' is where the user has to select a menu option

Code:
#######################################

 (c)opyright 2011, xzt06sd@hotmail.com 

#######################################



1) calibrate hall sensors
2) determine coil positions
3) change PWM parameters
9) store parameters in EEPROM for motor use

------> 1 

1) calibrate hall positions
2) change # of e-cycles
8) table out hall signals
9) return to main menu

# of e-cycles to be used:65535

------> 2 

new value -> 14 

1) calibrate hall positions
2) change # of e-cycles
8) table out hall signals
9) return to main menu

# of e-cycles to be used:14

------> 1 

Spin the motor then press any key to start measurement
1
2
3
4
5
6
7
8
9
10
11
12
13
14

1) calibrate hall positions
2) change # of e-cycles
8) table out hall signals
9) return to main menu

# of e-cycles to be used:14

------> 8 

hall 1, hall 2, hall 3
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	-.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	-.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540
-.500	.520	.540


1) calibrate hall positions
2) change # of e-cycles
8) table out hall signals
9) return to main menu

# of e-cycles to be used:14

------> 9 


1) calibrate hall sensors
2) determine coil positions
3) change PWM parameters
9) store parameters in EEPROM for motor use

------> 2 

1) calibrate coil positions
2) change # of back-emf samples
3) reconstruct waveforms based on extracted parameters
8) table out data arrays
9) return to main menu

# of back-emf samples to be used for coil calibration:65535

------> 2 

new value -> 850 

1) calibrate coil positions
2) change # of back-emf samples
3) reconstruct waveforms based on extracted parameters
8) table out data arrays
9) return to main menu

# of back-emf samples to be used for coil calibration:850

------> 1 

Spin the motor then press any key to start measurement

 coil position capture successfull
 data arrays now contain sampled back-emf waveforms

1) calibrate coil positions
2) change # of back-emf samples
3) reconstruct waveforms based on extracted parameters
8) table out data arrays
9) return to main menu

# of back-emf samples to be used for coil calibration:850

------> 8 

data A, data B, data C
.759	.134	-.891
.728	.189	-.909
.699	.236	-.920
.669	.283	-.927
.636	.325	-.933
.601	.366	-.939
.567	.408	-.941
.530	.447	-.941
.491	.488	-.937
.451	.524	-.933
.409	.559	-.928
.364	.593	-.921
.320	.625	-.911
.274	.658	-.898
.226	.686	-.883
.175	.715	-.869
.126	.741	-.849
.073	.765	-.831
.023	.787	-.810
-.028	.810	-.787
-.078	.829	-.760
-.125	.846	-.738
-.187	.864	-.703
-.261	.886	-.655
-.310	.896	-.624
-.356	.906	-.588
-.401	.914	-.552
-.444	.919	-.514
-.485	.922	-.476
-.526	.922	-.436
-.563	.922	-.394
-.600	.918	-.351
-.635	.913	-.308
-.666	.906	-.261
-.699	.894	-.218
-.726	.883	-.170
-.755	.869	-.125
-.776	.856	-.082
-.815	.829	-.0010
-.838	.810	.038
-.858	.788	.088
-.877	.766	.136
-.895	.741	.182
-.911	.715	.230
-.924	.687	.277
-.935	.658	.322
-.947	.625	.365
-.954	.593	.409
-.959	.559	.449
-.962	.524	.490
-.961	.488	.529
-.962	.447	.564
-.959	.407	.599
-.952	.367	.633
-.944	.327	.666
-.933	.283	.693
-.920	.239	.724
-.906	.194	.751
-.891	.145	.774
-.871	.099	.799
-.853	.051	.819
-.831	.001	.839
-.808	-.047	.858
-.778	-.107	.878
-.743	-.167	.895
-.714	-.212	.908
-.685	-.259	.917
-.654	-.305	.925
-.621	-.343	.932
-.587	-.387	.934
-.552	-.428	.935
-.514	-.468	.933
-.474	-.505	.931
-.432	-.540	.927
-.389	-.576	.920
-.346	-.610	.909
-.299	-.641	.899
-.253	-.673	.885
-.204	-.702	.870
-.155	-.729	.854
-.103	-.753	.835
-.052	-.777	.813
-.002	-.799	.792
.049	-.819	.766
.099	-.837	.741
.151	-.854	.715
.196	-.869	.684
.240	-.881	.660
.316	-.897	.608
.361	-.908	.573
.406	-.914	.537
.448	-.918	.499
.489	-.922	.460
.528	-.922	.421
.564	-.921	.378
.601	-.915	.338
.636	-.910	.295
.668	-.902	.249
.699	-.891	.204
.727	-.880	.156
.752	-.866	.108
.780	-.849	.063
.803	-.832	.013
.825	-.813	-.035
.848	-.791	-.080
.864	-.772	-.122
.887	-.740	-.186
.903	-.715	-.232
.916	-.688	-.278
.930	-.657	-.323
.940	-.626	-.367
.946	-.593	-.409
.951	-.560	-.449
.954	-.524	-.489
.954	-.486	-.528
.953	-.451	-.564
.950	-.410	-.599
.943	-.370	-.633
.934	-.328	-.665
.924	-.286	-.693
.910	-.242	-.721
.897	-.196	-.748
.882	-.149	-.772
.864	-.102	-.795
.843	-.056	-.817
.821	-.008	-.836
.799	.041	-.854
.773	.088	-.870

1) calibrate coil positions
2) change # of back-emf samples
3) reconstruct waveforms based on extracted parameters
8) table out data arrays
9) return to main menu

# of back-emf samples to be used for coil calibration:850

------> 3 

 data arrays now contain reconstructed back-emf waveforms

1) calibrate coil positions
2) change # of back-emf samples
3) reconstruct waveforms based on extracted parameters
8) table out data arrays
9) return to main menu

# of back-emf samples to be used for coil calibration:850

------> 8 

data A, data B, data C
.743	.154	-.923
.715	.205	-.937
.686	.255	-.948
.656	.303	-.958
.623	.349	-.964
.589	.394	-.968
.554	.437	-.969
.516	.478	-.968
.477	.518	-.964
.436	.556	-.958
.393	.592	-.949
.350	.627	-.939
.305	.661	-.928
.259	.693	-.914
.211	.724	-.899
.163	.753	-.883
.114	.781	-.864
.063	.806	-.843
.012	.831	-.820
-.040	.853	-.794
-.093	.874	-.765
-.146	.893	-.734
-.199	.910	-.701
-.251	.925	-.666
-.302	.938	-.628
-.352	.949	-.590
-.399	.958	-.550
-.444	.964	-.509
-.486	.968	-.468
-.526	.969	-.426
-.563	.968	-.383
-.598	.964	-.340
-.631	.957	-.295
-.663	.948	-.249
-.692	.937	-.202
-.721	.924	-.153
-.749	.909	-.103
-.775	.892	-.052
-.800	.874	-.000
-.824	.854	.051
-.846	.831	.102
-.866	.807	.154
-.885	.782	.204
-.901	.754	.253
-.915	.724	.301
-.926	.693	.347
-.935	.660	.392
-.942	.625	.436
-.947	.589	.477
-.950	.552	.518
-.950	.513	.556
-.949	.474	.594
-.945	.433	.629
-.940	.390	.663
-.932	.347	.695
-.921	.302	.725
-.909	.255	.754
-.894	.207	.780
-.878	.158	.805
-.859	.107	.829
-.839	.055	.851
-.817	.003	.871
-.794	-.049	.890
-.769	-.102	.907
-.743	-.154	.923
-.715	-.205	.937
-.686	-.255	.948
-.656	-.303	.957
-.624	-.349	.964
-.589	-.394	.968
-.554	-.437	.969
-.516	-.478	.968
-.477	-.518	.964
-.436	-.556	.958
-.394	-.593	.949
-.350	-.628	.939
-.305	-.661	.927
-.259	-.693	.914
-.212	-.724	.899
-.163	-.753	.882
-.114	-.781	.864
-.063	-.806	.843
-.012	-.831	.820
.040	-.853	.794
.093	-.874	.765
.146	-.893	.734
.199	-.910	.701
.251	-.925	.665
.302	-.938	.628
.352	-.949	.590
.399	-.958	.550
.444	-.964	.509
.486	-.968	.468
.526	-.969	.426
.563	-.968	.383
.598	-.964	.340
.631	-.957	.295
.662	-.948	.249
.692	-.937	.201
.721	-.924	.153
.748	-.909	.103
.775	-.893	.052
.800	-.874	.000
.824	-.854	-.051
.846	-.832	-.103
.866	-.808	-.154
.885	-.782	-.204
.901	-.754	-.253
.915	-.725	-.301
.926	-.693	-.348
.935	-.660	-.392
.942	-.626	-.436
.947	-.590	-.478
.950	-.552	-.518
.950	-.514	-.557
.949	-.474	-.594
.945	-.433	-.629
.939	-.391	-.663
.931	-.347	-.695
.921	-.302	-.725
.909	-.256	-.754
.894	-.208	-.780
.878	-.158	-.805
.859	-.107	-.829
.839	-.055	-.851
.817	-.003	-.871
.794	.049	-.890
.769	.101	-.907

1) calibrate coil positions
2) change # of back-emf samples
3) reconstruct waveforms based on extracted parameters
8) table out data arrays
9) return to main menu

# of back-emf samples to be used for coil calibration:850

------> 9 


1) calibrate hall sensors
2) determine coil positions
3) change PWM parameters
9) store parameters in EEPROM for motor use

------> 3 

1) change PWM frequency
2) change PWM deadtime
3) change dutycycle PWM test signal
8) test PWM signals
9) return to main menu

PWM frequency: 0kHz
deadtime: 8499ns
dutycycle testsignal: 50%

------> 1 

new value -> 50 

1) change PWM frequency
2) change PWM deadtime
3) change dutycycle PWM test signal
8) test PWM signals
9) return to main menu

PWM frequency: 50kHz
deadtime: 8499ns
dutycycle testsignal: 10922%

------> 2 

new value -> 300 

1) change PWM frequency
2) change PWM deadtime
3) change dutycycle PWM test signal
8) test PWM signals
9) return to main menu

PWM frequency: 50kHz
deadtime: 299ns
dutycycle testsignal: 10922%

------> 9 


1) calibrate hall sensors
2) determine coil positions
3) change PWM parameters
9) store parameters in EEPROM for motor use

------> 9 

 Data stored in EEPROM for motor use


1) calibrate hall sensors
2) determine coil positions
3) change PWM parameters
9) store parameters in EEPROM for motor use

------>
 
Are you sure its not simpler to have a software (java maybe) to do that? Looks like a few hours of coding to write a software to do this.
Anyway i believe its not the right time to bother about UI. Its time to burn some fets! :)
 
Back
Top