I searched a lot but I didn't find a good solution. Most answers work only when the duty cycle is 50% but I am searching for a solution that works for clocks with duty cycles like 40%, etc.
SYNCHRONOUS
You will find it hard to do this with a synchronous design because the flip-flops can only switch on a clock edge.
Typical divide by 3 circuits will either:
Use positive clock edges and have a 33% output duty cycle
Use positive and negative edges and have a 50% duty cycle if the input is 50%
Unfortunately, for a general input duty cycle such as 40%, if you sketch out the location of the clock edges you will find they occur at:
0,0.4,1,1.4,2,2.4,3
but for a 40% divide by 3 you would require edges at separated by 1.2 (=0.4*3) and 1.8, but such differences are not available to you. (You only have differences such as 0.4,0.6,1.0,1.4,1.6,etc.)
ASYNCHRONOUS
The standard way to get a divide by 3 with a different duty cycle is simply to instantiate a delay locked loop or a phase locked loop circuit.
For example, if you are using an Altera FPGA look at the AltPLL megafunction which has options to set the target duty cycle, and will work across a wide range of input duty cycles.
However, note that the output duty cycle is set when you configure the PLL and will not track the input duty cycle.
Related
I was recently reading through the design of PLLs and was thinking about how these reference clocks are generated.
We know that the reference is generated from a crystal (Generally Quartz), but the oscillations produced by these crystals top out at 100MHZ, how is this reference multiplied to achieve higher frequencies (GHz)?
Is there a circuit that is used to achieve this? (I'm looking at this from an analog designer's perspective).
Clock can be easily multiplied by 2 using clock trigger at both rising and falling edges. So, clock can get multiplied by 2^n using similar logic.
Given this System, and assuming we pipelined it with the minimum number of registers:
How can I calculate the maximum throughput without even knowing the minimum number of registers needed to pipeline this?
C looks like an obvious bottleneck. The total throughput is going to be something like one result from C per clock. If C can't be internally pipelined, then its propagation delay of 25ns is going to be the bottleneck for how high you can clock the system, right?
It should be possible to pipeline the rest of it to have input for C ready that often, since the other stages have shorter propagation delays.
I'm trying to make an embedded thingy that detects the presence of a 19kHz tone from an electret microphone. I have a multistage bandpass filter/preamp hooked into the ADC of a microcontroller, and am trying to figure out the best way to digitally condition the signal in order to detect the presence of the tone.
I have implemented a Goertzel filter to look for the frequency of interest. My ADC takes 400 samples at a frequency of 4000KHz, then the micro processes the block and adds the result to a 100 point moving average. Looking at terminal output after each block, I can definitely see an overall jump in the numbers when the transmitter is turned on. However, there's a lot of noise in the power readings when the thing is turned on, and the the noise floor in the room I'm in keeps changing, too. I am not sure how to tune the thresholding level/filter out all of this noise.
I've tried a few things, but they all seem to be pretty noisy as the baseline of my signal drifts all over the place:
Preprocessing the block with Hamming/Blackman windows
Ratio of total received block power to band power in filter output
Ratio of power of band in interest (19kHz) to a band outside of,
but near band of interest (18.5kHz)
EDIT: I've done some more reading since posting this. Is calculating (2*Ew)/(N*Et) where Ew is the output from my filter and Et is the sum of the squares in my block the best way to do this test?
Any advice on how to deal with this and/or do a better method of signal extraction?
Thanks!
I'm writing an application for iphone4 and I'm taking values from the accelerometer to compute the current movement from a known initial position.
I've noticed a very strange behavior: often times when I walk holding the cellphone for a few meters and then I stop, I register a negative peak of overall velocity when the handset decelarates. How is that possible if I keep moving in the same direction?
To compute the variation in velocity I just do this:
delta_v = (acc_previous + acc_now)/2 * (1/(updating_frequency))
Say you are moving at a constant 10 m/s. Your acceleration is zero. Let's say, for the sake of simplicity, you sample every 1 second.
If you decelerate smoothly over a period of 0.1 seconds, you might get a reading of 100 m/s/s or you might not get a reading at all since the deceleration might fall between two windows. Your formula most likely will not detect any deceleration or if it does, you'll get two values of -50 m/s/s: (0 - 100) / 2 and then (-100 + 0) / 2. Either way you'll get the wrong final velocity.
Something similar could happen at almost any scale, All you need is a short period of high acceleration or deceleration that you happen to sample and your figures are screwed.
Numerical integration is hard. Naive numerical integration of a noisy signal will essentially always produce significant errors and drift (like what you're seeing). People have come up with all sorts of clever ways to deal with this problem, most of which require having some source of reference information other than the accelerometer (think of a Wii controller, which has not only an accelerometer, but also the thingy on top of the TV).
Note that any MEMS accelerometer is necessarily limited to reporting only a certain band of accelerations; if acceleration goes outside of that band, then you will absolutely get significant drift unless you have some way to compensate for it. On top of that, there is the fact that the acceleration is reported as a discrete quantity, so there is necessarily some approximation error as well as noise even if you do not go outside of the window. When you add all of those factors together, some amount of drift is inevitable.
Well if you move any object in one direction, there's a force involved which accelerates the object.
To make the object come to a halt again, the same force is needed in the exact opposite direction - or to be more precise, the vector of the acceleration event that happened before needs to be multiplied with -1. That's your negative peak.
Not strictly a programming answer, but then again, your question is not strictly a programming question :)
If it's going a thousand miles per hour, its acceleration is 0. If it's speeding, the acceleration is positive. If it's slowing down, the acceleration is negative.
You can use the absolute number of the velocity to invert any negative acceleration, if that's needed:
fabs(delta_v); // use abs for ints
I am trying to write a simple game, but I'm stuck on what I think is simple physics. I have an object that at point 0,0,0 and is travelling at say 1 unit per second. If I give an instruction, that the object must turn 15 degrees per second , for 6 seconds (so it ends up 90 degrees right of it's starting position), and accelerate at 1 unit per second for 4 seconds (so it's final speed is 5 units per second), how do I calculate it's end point?
I think I know how to answer this for an object that isn't accelerating, because it's just a circle. In the example above, I know that the circumference of the circle is 4 * distance (because it is traversing 1/4 of a circle), and from that I can calculate the radius and angles and use simple trig to solve the answer.
However, because at any given moment in time the object is travelling slightly faster than it was in the previous moment, my end result wouldn't be a circle, it would be some sort of arc. I suppose I could estimate the end point by looping through each step (say 60 steps per second), but this sounds error prone and inefficient.
Could anybody point me in the right direction?
Your notion of stepping through is exactly what you do.
Almost all games operate under what's known as a "game tick". There are actually a number of different ticks that could be going on.
"Game tick" - each game tick, a set of requests are fired, AI is re-evaluated, and overall the game state has changed.
"physics tick" - each physics tick, each physical object is subject to a state change based on its current physical state.
"graphics tick" - also known as a rendering loop, this is simply drawing the game state to the screen.
The game tick and physics tick often, but do not need to, coincide with each other. You could have a physics tick that moves objects at their current speed along their current movement vector, and also applied gravity to it if necessary (altering its speed,) while adding additional acceleration (perhaps via rocket boosters?) in a completely separate loop. With proper multi-threading care, it would fit together nicely. The more de-coupled they are, the easier it will be to swap them out with better implementations later anyway.
Simulating via a time-step is how almost all physics are done in real-time gaming. I even used to do thermal modeling for the department of defense, and that's how we did our physics modelling there too (we just got to use bigger computers :-) )
Also, this allows you to implement complex rotations in your physics engine. The less special cases you have in your physics engine, the less things will break.
What you're asking is actually a Mathematical Rate of change question. Every object that is in motion has position locations of (x,y,z). If you are able to break down the component velocity and accelerations into their individual planes, your final end point would be (x1, y1, z1) which is the respective outcome of your equations in that plane.
Hope it helps (: