Servopos, longer duration?
- Thread starter RobertN
- Start date
Andrew Cowan
Senior Member
You could try using PWM, or slow down the clock.
I need to generate 20 Hz, 0 to 40% duty cycle from a 90 Hz input at the equivalent variable duty cycle. Slowing to 1MHz does not change the duty cycle. Schemes for using pulsout are too resource limiting and PWM is too fast for the 20Hz target rate. A 20 Hz 40% max. servo - servopos may handle the the output. Need to run pulsin and pulsout concurrently, or something equivalent. Any ideas?
OK so this is a completely new take on the requirements.
Originally the request was to generate the slow pulse train.
Now the request appears to be to convert a slow pulse train to an even slower pulse train.
Is this correct?
If so there are completely different options available.
Which bit varies - the input pulse train, the output pulse train, or both?
Originally the request was to generate the slow pulse train.
Now the request appears to be to convert a slow pulse train to an even slower pulse train.
Is this correct?
If so there are completely different options available.
Which bit varies - the input pulse train, the output pulse train, or both?
BeanieBots
Moderator
I've not checked any numbers to see if this possible but here's a thought.
Use a simple RC to convert the incomming PWM into an averaged DC voltage.
Measure it with ReadADC and use that to control the PICAXE pwmout.
Change the PICAXE clock speed to get the desired PWMout frequency.
Use a simple RC to convert the incomming PWM into an averaged DC voltage.
Measure it with ReadADC and use that to control the PICAXE pwmout.
Change the PICAXE clock speed to get the desired PWMout frequency.
hippy
Ex-Staff (retired)
Assuming it's a fixed frequency input and output and you are setting output duty to input duty you have two separate processes; determining a duty from the incoming signal and generating an output signal at the right duty cycle.
For the first PULSIN should do the job and as the input frequency is near five times the rate of output frequency that PULSIN can only catch alternative pulse times will not be a problem.
For the second, setting the internal TIMER1 to give a 20Hz rate and triggering a PULSOUT to vary the duty should work.
Because the 20Hz duty is only 0% to 40% you will have 12ms after the PULSOUT. As the 90Hz is 11ms so it's not possible to guarantee a PULSIN would complete in that time without causing a missed 20Hz cycle. If the input stream were significantly higher frequency that would have worked.
Te solution is to split the separate prcesses, either using hardware as BeanieBots suggest or using two PICAXE's and have the first communicate with the second. Using serial has a problem with SERIN after the PULSOUT having similar issues as a PULSIN after PULSOUT.
Using a high-speed interface with 'always ready' data solves that problem. Using two 20M's and the outputs of one can feed to the inputs of the other, data is always ready whenever the 20Hz generator needs it, and it can be doubly read to avoid reads while the data may be changing ...
For the first PULSIN should do the job and as the input frequency is near five times the rate of output frequency that PULSIN can only catch alternative pulse times will not be a problem.
For the second, setting the internal TIMER1 to give a 20Hz rate and triggering a PULSOUT to vary the duty should work.
Because the 20Hz duty is only 0% to 40% you will have 12ms after the PULSOUT. As the 90Hz is 11ms so it's not possible to guarantee a PULSIN would complete in that time without causing a missed 20Hz cycle. If the input stream were significantly higher frequency that would have worked.
Te solution is to split the separate prcesses, either using hardware as BeanieBots suggest or using two PICAXE's and have the first communicate with the second. Using serial has a problem with SERIN after the PULSOUT having similar issues as a PULSIN after PULSOUT.
Using a high-speed interface with 'always ready' data solves that problem. Using two 20M's and the outputs of one can feed to the inputs of the other, data is always ready whenever the 20Hz generator needs it, and it can be doubly read to avoid reads while the data may be changing ...
Code:
[b]' 90Hz reader[/b]
Do
PuslIn pin,0,w0
Gosub DetermineDutyInB2
pins = b2
Loop
Code:
[b]' 20Hz generator[/b]
Do
b2 = pins
Gosub DeterminePulsePeriodInW0
Gosub WaitFor20HzSync
PulsOut pin,w0
Loophippy
Ex-Staff (retired)
20M's are very handy for this having 8 ins on left and 8 outs on the right so it's possible to easily chain as many as are wanted on strip-board and vero-board. Two 20M's next to each other isn't much more complicated than a single one, although I've just noticed the pin order is reversed on each side ! If time isn't important that can be resolved in software.
Two 18X's can be connected using the outputs as inputs giving an 8-bit link but the receiver then only has the Serial Out line as output and wiring is a little more complicated.
Two 18X's can be connected using the outputs as inputs giving an 8-bit link but the receiver then only has the Serial Out line as output and wiring is a little more complicated.
BeanieBots
Moderator
Mpep, yes we know that but no servos are being used here. The servo command is being explored as a possible solution to a PWM generation solution.
Was really hoping th M08 could do this application, the software ease and flexability is very appealing. In this case there seems to be a wall right down the middle of the pulsin, pulsout, PWM, and servo. Will have to reconsider analog or digital support for the M08, or go with all analog or digital. Anyone know a good way to convert a variable duty cycle from one frequency (repetition rate) to another?
hippy
Ex-Staff (retired)
Anyone know a good way to convert a variable duty cycle from one frequency (repetition rate) to another?
For the particular frequencies, on a single 08M; no. If you are prepared to use two 20M's then see post #7.
You could probably do it with three 08M's, the one in the middle ensuring that the generator always has data sent va serial whenever it asks for it on completing a PULSOUT cycle but that's more complicated and more costly than two 08M's.
For the particular frequencies, on a single 08M; no. If you are prepared to use two 20M's then see post #7.
You could probably do it with three 08M's, the one in the middle ensuring that the generator always has data sent va serial whenever it asks for it on completing a PULSOUT cycle but that's more complicated and more costly than two 08M's.
BeanieBots
Moderator
I still think post 6 is the easiest option but assumes the 08M clock can be adjusted to give the desired repetition rate.
hippy
Ex-Staff (retired)
You're right, #6 gets a single 08M solution.
Getting the 20ms repeat rate is just a matter of setting TIMER1 to overflow at the right rate, checking the flag then PULSOUT for whatever time the READADC indicates. There shouldn't be too much jitter in that. Alternatively an external 50Hz source could be used to generate an interrupt - mains or maybe the TIMER1 overflow can generate the interrupt ( can't recall if that works on the 08M, it does on an 18X ).
Wouldn't using SERVO achieve that ? Take the servo out back in as an interrupt.
Getting the 20ms repeat rate is just a matter of setting TIMER1 to overflow at the right rate, checking the flag then PULSOUT for whatever time the READADC indicates. There shouldn't be too much jitter in that. Alternatively an external 50Hz source could be used to generate an interrupt - mains or maybe the TIMER1 overflow can generate the interrupt ( can't recall if that works on the 08M, it does on an 18X ).
Wouldn't using SERVO achieve that ? Take the servo out back in as an interrupt.
Looks like #6 would work, low pass the input pulses into an ADC input to measure input duty cycle. There could be some jitter or beating from input filter ripple as there is no synchronization between PWM input signal and ADC read. The input filter should have a short time constant to maximize system response. Some jitter is acceptable.
Maths would determine 20 Hz. output pulse high and low time. To maintain a 20 Hz. output signal, a dummy pulsout could be used for an appropriate output low time. Compensation for processor time would have to be incorporated into the maths.
Another approch would be to do succesive 2 pulsins, one for high pulse time and the other for low. These pulsins would be separated by one input PWM cycle, since the end of the high pulsin is the same falling edge as start of the low pulsin. The 08M processing time does not allow a low pulsin to start from the same edge as the high pulsin it just completed. As a result it will wait for the falling edge in the second input cycle. Maths would determine the pulsout high time and dummy pulsout low time for the proper duty cycle and cycle rate, like above. This would give one input measurement per output cycle with no jitter as long as timing is not messed up due to sudden changes in input duty cycle. Synchronization would occur since pulsin would wait for the rising edge of the input pulse. Have to try this to see how it works. Comments and suggestions appreciated.
Maths would determine 20 Hz. output pulse high and low time. To maintain a 20 Hz. output signal, a dummy pulsout could be used for an appropriate output low time. Compensation for processor time would have to be incorporated into the maths.
Another approch would be to do succesive 2 pulsins, one for high pulse time and the other for low. These pulsins would be separated by one input PWM cycle, since the end of the high pulsin is the same falling edge as start of the low pulsin. The 08M processing time does not allow a low pulsin to start from the same edge as the high pulsin it just completed. As a result it will wait for the falling edge in the second input cycle. Maths would determine the pulsout high time and dummy pulsout low time for the proper duty cycle and cycle rate, like above. This would give one input measurement per output cycle with no jitter as long as timing is not messed up due to sudden changes in input duty cycle. Synchronization would occur since pulsin would wait for the rising edge of the input pulse. Have to try this to see how it works. Comments and suggestions appreciated.
BeanieBots
Moderator
I'd simply go for using PWMout and an adjusted clock to get the right frquency. No 'faffing about' with pulsins and pulsouts. And why bother trying to syncronise anything. There's no point.
To reduce ripple on the input PWM->Voltage conversion without losing response, simply go to a higher order filter. I'd be surprised if 2nd order didn't yeald better than 10 bit (no point going better) but 3rd order would only be a few more components.
The joy of PWM->V into high Z is that you can use Nth order filtering without having to use any active components.
To reduce ripple on the input PWM->Voltage conversion without losing response, simply go to a higher order filter. I'd be surprised if 2nd order didn't yeald better than 10 bit (no point going better) but 3rd order would only be a few more components.
The joy of PWM->V into high Z is that you can use Nth order filtering without having to use any active components.
I agree there is no reason to sycronize, and a good passive filter would minimize ripple. A passive filter would have an output span of 2 volts (40% of 5v). This would be adequate even with 8 bit a/d.
Adjusting the clock to get 20 Hz PWM would make the 08M a real slug.
Will have to try both the 'faffing about' approch and r/c - ADC to see how they work. May be interesting to get TIMER1 to work.
Adjusting the clock to get 20 Hz PWM would make the 08M a real slug.
Will have to try both the 'faffing about' approch and r/c - ADC to see how they work. May be interesting to get TIMER1 to work.
Next step up
I have enjoyed working with the 08M. The software has been easy to use and real plus. Unfortunately the hardware and software limits have prevented a straight foreward digital only solution to this project. No straight forward way to do concurrent pulse in and out. As a result I would like to explore a more advanced software and hardware solution that hopefully would not be too big of a learning process. Could anyone recommend a developement system that is a step above PicAxe?
I have enjoyed working with the 08M. The software has been easy to use and real plus. Unfortunately the hardware and software limits have prevented a straight foreward digital only solution to this project. No straight forward way to do concurrent pulse in and out. As a result I would like to explore a more advanced software and hardware solution that hopefully would not be too big of a learning process. Could anyone recommend a developement system that is a step above PicAxe?
hippy
Ex-Staff (retired)
Could anyone recommend a developement system that is a step above PicAxe?
A bigger PICAXE, more bigger PICAXE's ?
I think the more advanced solution without the learning curve is the tough nut to crack. There are plenty of powerful processors out there where you can get right down to the nitty-gritty and control and do things with sub-microsecond accuracy but then there's the making it do it and investing in new tools and costs to achieve that.
Maybe a brief run through of what you have, what worked and - importantly from your current perspective - what's not working or proving hard to achieve and what your limitations are on possible solutions, and maybe people here can come up with the brain-wave to get you over the final hurdle ?
I've often found that the best problem solver is someone who just listens ( or in this case reads ). While explaining the problems, the dilemmas, paradoxes and what not of why the thing won't work the solution pops into my head and what should have been blindingly obvious becomes crystal clear. You never know, before even finishing the post you might discover the ellusive solution !
A bigger PICAXE, more bigger PICAXE's ?
I think the more advanced solution without the learning curve is the tough nut to crack. There are plenty of powerful processors out there where you can get right down to the nitty-gritty and control and do things with sub-microsecond accuracy but then there's the making it do it and investing in new tools and costs to achieve that.
Maybe a brief run through of what you have, what worked and - importantly from your current perspective - what's not working or proving hard to achieve and what your limitations are on possible solutions, and maybe people here can come up with the brain-wave to get you over the final hurdle ?
I've often found that the best problem solver is someone who just listens ( or in this case reads ). While explaining the problems, the dilemmas, paradoxes and what not of why the thing won't work the solution pops into my head and what should have been blindingly obvious becomes crystal clear. You never know, before even finishing the post you might discover the ellusive solution !
Ellusive solution
Hippy, your reply is appreciated. Here is a little reading.
Initially doing pulse width frequency conversion with pulsin and pulsout commands looked like it would be a snap with just the commands I needed. Unfortunately those commands are exclusive of each other and with other commands. After considering a handful of approaches (see previous posts), it looks like the suggestion to use a second order passive filter pulse width to voltage conversion is a simple viable option. There is a minimum of external components, but some concern about the lag - ripple trade off. For faster response I worked up a pulse width to voltage sample and hold circuit, clocked by the input pulses. This circuit required a fair number of components, and has unresolved reset issues if no input pulses are present.
Also considered using ADC to monitor an external 20Hz. saw tooth ramp - time base for the input and output pulses. It looked like it required some convoluted programming, had poor resolution for short pulses, and could have missed pulses due to processing time. It galls me to think digital I/O's require an analog interface.
It appears multiple 08M's could have communication issues, especially in conjunction with pulse commands. Other approaches have been discussed here, and generally have had one issue or another.
With most any input scheme, the ~ 20Hz. output pulse looks like it should be made from 2 output pulse commands. One for mark and the other for space, with the sum of their time = ~1/20 sec. This doesn't leave much time to do anything else, like A/D and maths, without being part of a mark or space time.
An accessible counter(s) sure would be nice, but then again that's kind-of what pulse commands are except one command hogs the timer. If there were a way to run 2 pulse commands concurrently, this project would be done, even if time resolution was reduced. How about a small PicAxe with more counters and/or pulsin and pulsout sharing a counter. This might help others with pulse - pwm command issues.
Again, it is perturbing to think that a project with 2 pwm inputs, some maths, and one slow pwm output would require analog circuitry or more than a 8 pin micro.
At some point, all this casting about leads to looking for something more suitable. Avoiding the resulting undesirable learning curve is an issue.
I was delighted to find and work with PicAxe, continue to be a fan of PicAxe, and I have recommended it to a couple friends. It can readily do other projects I have in mind, so it will be the first choice. If it would just do this darn pulse width conversion thing.
Hippy, your reply is appreciated. Here is a little reading.
Initially doing pulse width frequency conversion with pulsin and pulsout commands looked like it would be a snap with just the commands I needed. Unfortunately those commands are exclusive of each other and with other commands. After considering a handful of approaches (see previous posts), it looks like the suggestion to use a second order passive filter pulse width to voltage conversion is a simple viable option. There is a minimum of external components, but some concern about the lag - ripple trade off. For faster response I worked up a pulse width to voltage sample and hold circuit, clocked by the input pulses. This circuit required a fair number of components, and has unresolved reset issues if no input pulses are present.
Also considered using ADC to monitor an external 20Hz. saw tooth ramp - time base for the input and output pulses. It looked like it required some convoluted programming, had poor resolution for short pulses, and could have missed pulses due to processing time. It galls me to think digital I/O's require an analog interface.
It appears multiple 08M's could have communication issues, especially in conjunction with pulse commands. Other approaches have been discussed here, and generally have had one issue or another.
With most any input scheme, the ~ 20Hz. output pulse looks like it should be made from 2 output pulse commands. One for mark and the other for space, with the sum of their time = ~1/20 sec. This doesn't leave much time to do anything else, like A/D and maths, without being part of a mark or space time.
An accessible counter(s) sure would be nice, but then again that's kind-of what pulse commands are except one command hogs the timer. If there were a way to run 2 pulse commands concurrently, this project would be done, even if time resolution was reduced. How about a small PicAxe with more counters and/or pulsin and pulsout sharing a counter. This might help others with pulse - pwm command issues.
Again, it is perturbing to think that a project with 2 pwm inputs, some maths, and one slow pwm output would require analog circuitry or more than a 8 pin micro.
At some point, all this casting about leads to looking for something more suitable. Avoiding the resulting undesirable learning curve is an issue.
I was delighted to find and work with PicAxe, continue to be a fan of PicAxe, and I have recommended it to a couple friends. It can readily do other projects I have in mind, so it will be the first choice. If it would just do this darn pulse width conversion thing.