Hi how can I adjust the transmission times of my signals in the model. E.g. signal A is sent every 10 ms and signal B: every 20 ms, whereby the statement of signal B depends on signal A. In the 10 ms that signal b does not send, the content of signal A should be ignored.
I tried it with "Transport Delay Block" and "Sample setting" in the properties of my subsystems.
Related
I have one server with a FIFO queue, the server capacity is 1 and simulation stops at 5 minutes. I have 2 events: arrive and leave server the server.
I'm calculating the average delay in queue which is the sum of delay in queue of each costumer dividing by the number of costumers delayed.
If during simulation all my events are type "Arrive" won't my average delay be 0?
Because everyone that got in queue doesn't leave the server before the end of the simulation.
This is a very basic question. I can't simulate a PWM file, in system time, from its FPGA VI file.
Details
For a NI cRIO-9067 + LabVIEW 2016 + Windows 8 system, under FPGA Interface Mode, I have the Test VI No.1.vi NI LabVIEW file and the corresponding FPGA Desktop Execution Node block file Test VI No.1 DEN.vi as suggested in the Getting Started information [1] [2].
In both files, the Low Pulse and High Pulse Numeric Controls are filled with the 1000 value. The Loop Timer block is set as "mSec" Counter Unit and "32 Bit" Size of Internal Counter.
The compiled FPGA version of the first file executes a square wave changing each 1 second, as expected, after 7 minutes of local compilation.
Under Simulation (Simulated I/O) as Execution Mode, and for reproducing approximatedly and by trial and error the square wave timing every 1 second, I need to put the value 1750 in the Clock Ticks field, from the FPGA 40MHz Onboard Clock reference clock, shown in the block options.
I dont understand this block, and why i should not put any close divisor of 40,000,000 at the Clock Ticks field, or simply, the value 1. Basically i dont understand how to "time" these FPGA simulations.
The desktop execution node is designed for time based simulation you are definately on the right track.
What you are setting at the top is the number of cycles that are executed each time you call the node. In your case you have 1750 ticks so around 43.75us of simulated time per iteration.
To simulate in real time you need to make sure that you execute the same amount of simulated time as the simulation loop takes to run. In your case, you have no timing in your simulation loop so why 1750 works for you is because that is probably how long that loop takes to execute.
If you put a loop timer in of 1ms and set the clock ticks to 40,000 (1ms simulated time) then I think you will find that it also works.
In some cases it may be beneficial to execute faster than real time so you would just have to account for that in your maths. For example if you set the clock ticks to 40 (1us simulated time) then you can count the number of iterations and multiply by 1us to get the actual clock time.
I have a high speed clock at 10 MHz going to the processor's TIM4 input capture pin (ch.3). I would like to verify that the clock is running at 10 MHz with the processor's input capture. I coded the processor with the input capture module, and it works fine for lower frequencies (around 1 kHz or so). Once I start to climb the frequency up to the MHz range, the processor starts to miss interrupts and thus gives me an incorrect frequency. I didn't see anywhere in the datasheet that states the maximum frequency that the input capture can read. I have an external clock of 8 MHz, and a core clock of 72 MHz, so I would imagine that I can read a 10 MHz signal. Any ideas?
Take a look at the TIM_ICInitStructure.TIM_ICPrescaler options. Usually you'll have it set to TIM_ICPSC_DIV1 so that interrupts are generated on every valid transition.
Prescaler values of 1,2,4 and 8 are available that will allow you to effictively reduce the rate of interrupt generation by that factor. For example, for a 10MHz signal with a prescaler of 8 you'd expect to count a frequency of 10Mhz/8 = 1.25MHz.
This is still quite tight for a 72MHz HCLK so you'll still need to optimise your IRQ handler carefully.
Looks like you're generating an interrupt request for every rising (or falling) edge of the clock.
If that is indeed the case, then think about this for a second: with a 10 MHz input signal, you're generating an interrupt about every 7 CPU cycles. In these 7 CPU cycles, you need to budget time to save registers to RAM, run the IRQ handler function prolog, run the actual code you wrote for the interrupt handler, run the IRQ handler function epilogue, and restore the registers.
Best case, if you set compiler flags to optimize for speed and you're not doing much processing in the interrupt handler, you're looking at tens of cycles to run all these tasks. Since you only have 7 cycles to run tens of cycles' worth of processing, it's no surprise that you're missing interrupts.
You can't use an interrupt routine at that frequency. You need to feed the 10MHz in as an external trigger to the timer. Then you can use the prescaler and the timer to divide down to a suitable lower interrupt frequency.
Here is the scenario:
I'm generated a signal which is: 200ms # 2kHz 1000ms of zeros 200ms # 2kHz
and i want to calculate the time delay between them, not between the two synthetic audio part. but by playing the signal on a speaker and recording it using a microphone (adds noise)
Fs = 44100
i tried: 1. cross correlation 2. calculation the diff between two maximas of RMS window at the size of 8820 samples. (we get the maxima when the window is on the sound part.
the distance between the speaker and the mic is around 30cm. i cant get a steady result. why?
If you want to do this accurately and consistently then one method I have used in the past is to loop back one channel (e.g. the left channel) from the output to the input and then use the other (i.e. right) channel for the timing test. You can then cross correlate between the left (loopback) and right (actual audio) channels. This eliminates many potential sources of error (buffer delays, hardware latency, software issues, etc), since the left and right channels will always be "in sync" and you should be able to make measurements accurate to +/- 1 sample period (+/- 12 µs at 44.1 kHz).
I'm using Matlab 7 and have a problem in creating a monoflop which shall raise for a specific time to "1" and after that time fall to "0". How can I do this with Matlab/Simulink 7?
I don't have any other version, so I can't use the "Monostable" Block from newer versions.
Any ideas?
greets, poeschlorn
There are a couple of ways to do this, depending on whether or not you want the pulse (i.e. "monoflop") to occur at a predetermined time or in response to another signal (like a rising edge)...
Creating a pulse at a predetermined time:
If you want to create a single pulse that steps from 0 to 1 at time tOnset, then steps back to 0 after a time tDur has elapsed, you can do this using a Step block, a Transport Delay block, and a Sum block. Here is what the layout would look like:
You would set the Step time of the Step block to tOnset, the Time delay of the Transport Delay block to tDur, and then subtract the delayed signal from the original signal.
Creating a pulse in response to a rising edge:
This is will be a bit more complicated. It will require two Detect Increase blocks, a Relay block, a Transport Delay block, a Gain block, and a Sum block. Here's what the layout would look like:
Assuming your input signal is either a 1 or a 0, the first Detect Increase block will output a 1 when the input steps from 0 to 1. By setting the Switch on point to 0.5 and the Switch off point to -0.5 for the Relay block, this will create hysteresis in the Relay such that the output will persist in the "on" state (i.e. an output of 1) after the brief pulse that occurs when the rising edge is detected.
To get the Relay block to switch back into the "off" state (i.e. an output of 0) after a specified time tDur, you would set the Time delay of the Transport Delay block to tDur. The Detect Increase block in the feedback loop will output a 1 when the delayed signal steps from 0 to 1, and this output will then be scaled by setting the Gain of the Gain block to 2.
When subtracted from the input signal, this gain will ensure that the output from the Sum block can be pulled below -0.5 no matter what the positive input is (0 or 1), thus ensuring that the Switch off point of the Relay block is reached and its output is turned off when the delayed signal has a rising edge (i.e. after tDur has elapsed). One result of this is that any additional rising edges occurring in the model input after the first rising edge and during the time tDur will be ignored. Once the output from the model returns to 0, the next rising edge on the model input will trigger another pulse.