Hi All,
I'm using the 12F683 to generate the throttle pulses for an electric brushless model plane motor. These pulses are the same as standard model servo pulses ie. 1,0 to 2,0 ms at a frame rate of 20 ms. The reason for the 20 Mhz clock is that I need a very fine control over the rpm for a feedback governor system. With the 4 Mhz clock, I can go no lower than 10 us and this relates to a resolution of 100 rpm on a scale where 1,0ms = zero rpm and 2,0ms = 10 000 rpm. The 1 us theoretically gives me a resolution of 10 rpm. This seemed to work very well, and then I picked up some glitches at certain rpm settings. Of course these "bad spots" always occur just at the rpm that I need for flying! (Murphy's law).
I thought that this was due to some problem in the esc (electronic speed controller) that is used for these brushless model motors, but after testing with a few others, the problem remained. I then tried looking at the output pulses from the PIC without connection the motor or esc. The jumps occur at the same spots. If I run a similar program with the 4 Mhz clock, these jumps do not occur, BUT of course the steps are bigger. Out of interest, I used the 20 Mhz program with steps of 10 us to simulate the 4 Mhz program, and the jumps are still there. If the jump/glitch is at say 1400 us, sometimes the pulse width will go to its maximium and then come back . Can anyone suggest what I'm doing wrong here. I have tried this with auto cycling up and down the range and also with 2 pushbuttons to go up and down. My test program is below. Thanks.
Getting 10 bits of resolution might be a tall order (i.e. 10,000rpm/10rpm). Looks like a process of elimination.
1) Was the glitch free 4 Mhz setting with the internal osc? You could gain some information by trying the 8 Mhz int osc setting for both the 10us and 1us routines (?). Try another external osc if you have one.
2) Some usual questions: Is the PIC power pins bypassed with 100nf cap? External osc traces as short as possible, and bypassed with 15-22pf caps? It wouldn't hurt to put an external pull up the MCLR pin.
3) Do you have a data sheet or manual link for the esc? Does it want to be updated a little more frequently?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Yes it was with the internal osc. I was not aware that the internal 8 Mhz osc could be used for 1 us.
2) The power pins are bypassed with a 100 nf cap. The external osc is bypassed with 22 pf caps. Mmmmm……the MCLR pin is used for reading the pulses from one of the motor wires via a fliter with a switching transistor with the collector going to pin 4 or MCLR. If there is no signal, as per when I test the board when not connected to a motor esc, then the transistor is turned on and that pin is held low. Is this a problem?
3) The esc is a standard model airplane type and the throttle pulse signal can be out of the 20 ms frame rate. When you first use these devices, some of them ask you to calibrate it by holding the throttle joystick at full power, wait for the beeps, and then bring the throttle down to low throttle. They can usually tolerate a pulse width of between 0,8 ms to 2,2 ms. When I test my unit with or without connecting it to the esc/motor, it glitches at the same spots. I noticed today, that it seems to be at around 220 us intervals.
A friend of mine has designed a similar system to mine, but uses the timer on interupt instead of the pulseout function. He has given me his program, but I just need to hook up my pc board so that I can try his software. Could my problem have something to do with interupts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K. I tried using the interrupt software with timer 1, and incremented the pulse width by 1 us every 20 ms. It too glitches in the same manner. Basically if we forget what I need this for, the question really is……..can I make a pulse width generator with this 12F683 using the 20 Mhz clock /crystal, that can increment at 1 us steps every 20 ms? I even tried stepping these increments by 10 us, to simulate the 4 Mhz program, and it glitches. Just by the way, I tried using the PIC with the 8 Mhz internal clock and when I compile the program, it says that I cannot use the chip for 1 us with a clock speed of < 20Mhz.
You said above "Getting 10 bits of resolution might be a tall order (i.e. 10,000rpm/10rpm)" I totally agree with you, and the 10 rpm resolution is theoretically possible but certainly not very practical. 50 rpm is fine, but 100 is a little on the coarse side.
I think that tomorrow I'll go back to the breadboard and fiddle some more. Now I'm a little sleepy!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The MCLR shouldn't be a problem, the thought was to have it in a known state "if" the pin was floating. Couldn't remember if 8Mhz would work with the us variable, should have known.
If looks like you have the most recent update zip? If it is convenient, can you revert back to the previous install, and try that? I always make a copy of the last working GCBasic prior to updating, then update the copy and archive the old one. The reason why I mentioned this, is I had a problem with the new 'For…..Next' routine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kent, I don't have a copy of the older files, but this is the cause of the problem. A friend of mine compiled a short test program for me using his older version and it works smoothly with zero glitching. This is a huge relief for me, because I have a box full of pc board for this project, and I can't afford to turf them out.
So what now? I did try downloading the present version on the GC Basic website again without using the update files, and this seems to have issues with many of the statements like the Osc etc. Where I can I get a version that works for the 20 Mhz small PIC's? Should I report thison the bug tracker? Thanks.
Keith R
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you got it working, and thanks for the confirmation that I'm not crazy about the new update and the For…Next loop problem. This is serious as it will BREAK previous code. The code checks for Status,C when I think it should be checking for Status,Z?
I for one, prefer the previous version, and checking for a variable that is initialized as zero is unnecessary. Sorry, but Garbage in, Garbage out. This was discussed in a recent post here.
So, go ahead and report to the bug tracker.
I still have your email from a while back, so will send along an older update zip from February of this year. Install that over a clean install of 9.3, and you should be good to go. Post back on how it went, sounds like an interesting endeavor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K. I did try what you said, and re-loaded ver 9.3 plus the update from February. Without the update, I can compile programs, but when I add the update. It will not compile anything to compile.hex. When I just use the ver 9.3 then it works but I can't config the OSC = HS. It comes up with a syntax error. If I set the chip to 20 Mhz. there is a difference but the timing is way out e.g. a 1000 us wait statement will give a pulse length of around 200 us and so on. If I use ms staements it works fine, but I need the us stuff that worked previously. Has the "HS" thing been removed from the OSC command list? I sther another way around this?
The other thing so far that does not work is a friend's program that uses a statement like this:
On Interrupt Timer1Overflow Call PulsTrain
What is wrong with this statement? This evening I'll see if I can get my friend's GC Basic folder sent to me. He says it's working fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to admit that I have not started building GCBasic from scratch for a very long time. The process has been to archive the old GCBasic folder, copy it, then apply update zip to the copied folder. If things aren't right after update, then I revert back to slightly older working version.
I can only suspect that that the problems encountered are related to a missing intermediate update or file, but which one??? The 9.3 download just by itself is not likely to work properly, without an update.
Waiting for your friends working copy seems like the way to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again Kent,
I've just sent you an e-mail as well. Whew……I've finally got the program working as it should. I cleaned out all of the GC Basic folder properly. I seem to have had some registry problems as well, so I fixed this, and cleaned up the hard drive. I then installed the latest version 9.3 plus the very latest update files, and bingo…………..it's working! I tested it with a very slow incrementing pulse width, even with for/next loops, and it's dead smooth on the scope. I believe that I can now get on with the project, so once again thanks so much for the help and advice.
Keith R
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I'm using the 12F683 to generate the throttle pulses for an electric brushless model plane motor. These pulses are the same as standard model servo pulses ie. 1,0 to 2,0 ms at a frame rate of 20 ms. The reason for the 20 Mhz clock is that I need a very fine control over the rpm for a feedback governor system. With the 4 Mhz clock, I can go no lower than 10 us and this relates to a resolution of 100 rpm on a scale where 1,0ms = zero rpm and 2,0ms = 10 000 rpm. The 1 us theoretically gives me a resolution of 10 rpm. This seemed to work very well, and then I picked up some glitches at certain rpm settings. Of course these "bad spots" always occur just at the rpm that I need for flying! (Murphy's law).
I thought that this was due to some problem in the esc (electronic speed controller) that is used for these brushless model motors, but after testing with a few others, the problem remained. I then tried looking at the output pulses from the PIC without connection the motor or esc. The jumps occur at the same spots. If I run a similar program with the 4 Mhz clock, these jumps do not occur, BUT of course the steps are bigger. Out of interest, I used the 20 Mhz program with steps of 10 us to simulate the 4 Mhz program, and the jumps are still there. If the jump/glitch is at say 1400 us, sometimes the pulse width will go to its maximium and then come back . Can anyone suggest what I'm doing wrong here. I have tried this with auto cycling up and down the range and also with 2 pushbuttons to go up and down. My test program is below. Thanks.
Keith R
#chip 12F683, 20
#config Osc = HS
#define RpmOut GPIO.1
Dir RpmOut Out
Dim RpmMin as word
Dim PW as word
RpmMin = 1000
For delay = 1 to 200 'short delay at low throttle on start-up
PulseOut RpmOut, RpmMin us
wait 20 ms
next
RpmUp:
For PW = 1000 to 2000
PulseOut RpmOut, PW us
wait 20 ms
next
For PW = 2000 to 1000
PulseOut RpmOut, PW us
wait 20 ms
next
goto RpmUp
Hi Keith,
Getting 10 bits of resolution might be a tall order (i.e. 10,000rpm/10rpm). Looks like a process of elimination.
1) Was the glitch free 4 Mhz setting with the internal osc? You could gain some information by trying the 8 Mhz int osc setting for both the 10us and 1us routines (?). Try another external osc if you have one.
2) Some usual questions: Is the PIC power pins bypassed with 100nf cap? External osc traces as short as possible, and bypassed with 15-22pf caps? It wouldn't hurt to put an external pull up the MCLR pin.
3) Do you have a data sheet or manual link for the esc? Does it want to be updated a little more frequently?
Hi Kent, Thanks for the help again.
1) Yes it was with the internal osc. I was not aware that the internal 8 Mhz osc could be used for 1 us.
2) The power pins are bypassed with a 100 nf cap. The external osc is bypassed with 22 pf caps. Mmmmm……the MCLR pin is used for reading the pulses from one of the motor wires via a fliter with a switching transistor with the collector going to pin 4 or MCLR. If there is no signal, as per when I test the board when not connected to a motor esc, then the transistor is turned on and that pin is held low. Is this a problem?
3) The esc is a standard model airplane type and the throttle pulse signal can be out of the 20 ms frame rate. When you first use these devices, some of them ask you to calibrate it by holding the throttle joystick at full power, wait for the beeps, and then bring the throttle down to low throttle. They can usually tolerate a pulse width of between 0,8 ms to 2,2 ms. When I test my unit with or without connecting it to the esc/motor, it glitches at the same spots. I noticed today, that it seems to be at around 220 us intervals.
A friend of mine has designed a similar system to mine, but uses the timer on interupt instead of the pulseout function. He has given me his program, but I just need to hook up my pc board so that I can try his software. Could my problem have something to do with interupts?
Hi Again,
O.K. I tried using the interrupt software with timer 1, and incremented the pulse width by 1 us every 20 ms. It too glitches in the same manner. Basically if we forget what I need this for, the question really is……..can I make a pulse width generator with this 12F683 using the 20 Mhz clock /crystal, that can increment at 1 us steps every 20 ms? I even tried stepping these increments by 10 us, to simulate the 4 Mhz program, and it glitches. Just by the way, I tried using the PIC with the 8 Mhz internal clock and when I compile the program, it says that I cannot use the chip for 1 us with a clock speed of < 20Mhz.
You said above "Getting 10 bits of resolution might be a tall order (i.e. 10,000rpm/10rpm)" I totally agree with you, and the 10 rpm resolution is theoretically possible but certainly not very practical. 50 rpm is fine, but 100 is a little on the coarse side.
I think that tomorrow I'll go back to the breadboard and fiddle some more. Now I'm a little sleepy!
Keith,
The MCLR shouldn't be a problem, the thought was to have it in a known state "if" the pin was floating. Couldn't remember if 8Mhz would work with the us variable, should have known.
If looks like you have the most recent update zip? If it is convenient, can you revert back to the previous install, and try that? I always make a copy of the last working GCBasic prior to updating, then update the copy and archive the old one. The reason why I mentioned this, is I had a problem with the new 'For…..Next' routine.
Hi Kent, I don't have a copy of the older files, but this is the cause of the problem. A friend of mine compiled a short test program for me using his older version and it works smoothly with zero glitching. This is a huge relief for me, because I have a box full of pc board for this project, and I can't afford to turf them out.
So what now? I did try downloading the present version on the GC Basic website again without using the update files, and this seems to have issues with many of the statements like the Osc etc. Where I can I get a version that works for the 20 Mhz small PIC's? Should I report thison the bug tracker? Thanks.
Keith R
Hi Keith,
Glad you got it working, and thanks for the confirmation that I'm not crazy about the new update and the For…Next loop problem. This is serious as it will BREAK previous code. The code checks for Status,C when I think it should be checking for Status,Z?
I for one, prefer the previous version, and checking for a variable that is initialized as zero is unnecessary. Sorry, but Garbage in, Garbage out. This was discussed in a recent post here.
So, go ahead and report to the bug tracker.
I still have your email from a while back, so will send along an older update zip from February of this year. Install that over a clean install of 9.3, and you should be good to go. Post back on how it went, sounds like an interesting endeavor.
O.K. I did try what you said, and re-loaded ver 9.3 plus the update from February. Without the update, I can compile programs, but when I add the update. It will not compile anything to compile.hex. When I just use the ver 9.3 then it works but I can't config the OSC = HS. It comes up with a syntax error. If I set the chip to 20 Mhz. there is a difference but the timing is way out e.g. a 1000 us wait statement will give a pulse length of around 200 us and so on. If I use ms staements it works fine, but I need the us stuff that worked previously. Has the "HS" thing been removed from the OSC command list? I sther another way around this?
The other thing so far that does not work is a friend's program that uses a statement like this:
On Interrupt Timer1Overflow Call PulsTrain
What is wrong with this statement? This evening I'll see if I can get my friend's GC Basic folder sent to me. He says it's working fine.
I have to admit that I have not started building GCBasic from scratch for a very long time. The process has been to archive the old GCBasic folder, copy it, then apply update zip to the copied folder. If things aren't right after update, then I revert back to slightly older working version.
I can only suspect that that the problems encountered are related to a missing intermediate update or file, but which one??? The 9.3 download just by itself is not likely to work properly, without an update.
Waiting for your friends working copy seems like the way to go.
Thanks again Kent,
I've just sent you an e-mail as well. Whew……I've finally got the program working as it should. I cleaned out all of the GC Basic folder properly. I seem to have had some registry problems as well, so I fixed this, and cleaned up the hard drive. I then installed the latest version 9.3 plus the very latest update files, and bingo…………..it's working! I tested it with a very slow incrementing pulse width, even with for/next loops, and it's dead smooth on the scope. I believe that I can now get on with the project, so once again thanks so much for the help and advice.
Keith R