I am using N210 USRP to have a RF spectrum around 2.4GHz range.
I have programmed two TelosB nodes and they are using RadioCoundLed to send and Receive signals
I have set the TelosB nodes at highest power level following the datasheet
I also made them fixed at a channel(26) around 2.48Ghz
I can see the Telosb nodes communication and the LEDS are blinking.
Now I should observe this in USRP RF spectrum. However I am observing nothing in Scope Sink. I have fixed the center freq in the 2.48 Ghz range.
Set the RX gain - 0
Sampling rate is 2M
Is it possible to even to observe it?
I guess I solved the problem. I was using the wrong daughter board. Now I am using the SBX board that can support 2.5Ghz range.
Related
I'm implementing a hashing algorithm in Verilog using Vivado 2019.2.1. Everything (including synthesis and implementation) worked quite well but I noticed recently that the results of the behavioral simulation (correct hash digest) differs from the post-synthesis/-implementation functional and timing simulation, i.e. I receive three different values for the same circuit design/code.
My base configuration contained a testbench using the default `timescale 1ns / 1ps and a #1 delay for toggling the clock register. I further constrained the clock to a frequency of 10 MHz using an xdc file. During synthesis, no errors (or even warnings, except some "parameter XYZ is used before its declaration") are shown and no non-blocking and blocking assignments are mixed inside my code. Nevertheless, I noticed that the post-* simulation (no matter if functional or timing) needs more clock cycles (e.g. 58 instead of 50 until the value of a specific register was toggled) for achieving the same state of the circuit. My design is entirely synchronous and driven by one clock.
This brought me to the Timing Report and I noticed that 10 input and 10 output delays are not constrained. In addition, the Design Timing Summary shows a worst negative slack for setup that is very close to the time of one clock cycle. I tried some combinations of input and output delays following the Vivado documentation and tutorial videos but I'm not sure how to find out which values are suitable. The total slack (TNS, THS and TPWS) is zero.
Furthermore, I tried to reduce the clock frequency because the propagation delay of some signals that control logic in the FSM (= top) module might be too large. The strange thing that happened then is that the simulation never reached the $finish; in my testbench and nothing except the clock register changed its value in the waveform. In the behavioral simulation everything works as expected but this doesn't seem to be influenced by constraints or even timing. Monitoring the o_round_done wire (determined by an LFSR in a separate submodule) in my testbench, I noticed that for the behavioral simulation the value of this wire changes with the clock whereas for the post-* simulations the value is changed with a small delay:
Behavioral Simulation
clock cycles: 481, round_done: 0
clock cycles: 482, round_done: 1
clock cycles: 483, round_done: 0
total of 1866 clock cycles
Post-Implementation Functional Simulation
clock cycles: 482, round_done: 0
clock cycles: 482, round_done: 1
clock cycles: 483, round_done: 1
clock cycles: 483, round_done: 0
total of 1914 clock cycles
Post-Implementation Timing Simulation
WARNING: "C:\Xilinx\Vivado\2019.2\data/verilog/src/unisims/BUFG.v" Line 57: Timing violation in scope /tb/fsm/i_clk_IBUF_BUFG_inst/TChk57_10300 at time 997845 ps $period (posedge I,(0:0:0),notifier)
WARNING: "C:\Xilinx\Vivado\2019.2\data/verilog/src/unisims/BUFG.v" Line 56: Timing violation in scope /tb/fsm/i_clk_IBUF_BUFG_inst/TChk56_10299 at time 998845 ps $period (negedge I,(0:0:0),notifier)
simulation never stops (probably because round_done is never 1)
Do you know what I'm doing wrong here? I'm wondering why the circuit is not behaving correctly at very low clock frequencies (e.g. 500 kHz) as, to my knowledge, this will provide enough time for each signal to "travel" to the correct destination.
Another thing I noticed is that one wire that is assigned to a register in a submodule is 8'bXX in the behavioral simulation until the connected register is "filled" but in the post-* simulations it is 8'b00 from the beginning. Any idea here?
Moreover, what is actually defining the clock frequency for the simulations? The values in the testbench (timescale and delay #) or the constraint in the xdc file?
I found an explanation for the question why the post-* simulations are behaving differently compared to the behavioral simulation w.r.t. clock cycles etc. in the Xilinx Vivado Design Suite User Guide for Logic Simulation (UG900).
What causes the "latency" before the actual computation of the design can start is called Global Set and Reset (GSR) and takes 100ns:
The glbl.vfile declares the global GSR and GTS signals and automatically pulses GSR for 100ns. (p. 217)
Consequently, I solved the issue by letting the test bench wait for the control logic (= finite-state machine) to be ready, i.e. changing to the state after RESET.
I'm using ADC pin in ESP32 WROOM to determine the voltage reading from them (GPIO34, GPIO35, GPIO36, GPIO39) but the reading is not accurate aka non-linear.
What I have done is:
I take the actual reading using a multimeter and compare to what the ESP32 reads on those pins by using a potentiometer by varying the voltage on that pin (from 0.1V -> 3.3V based on the ADC reading)
I put those numbers into an excel sheet to plot the error in the following columns :
ADC_READING_VOLTAGE | MULTIMETER_READING | ERROR (MULTIMETER_READING - ADC_READING_VOLTAGE)
Then I get a trendline equation from the error plot and add the error margin to the ADC_READING_VOLTAGE so that I could actually get the real value of the reading (MULTIMETER_READING)
voltage_reading = analogRead(adc_pin)/4095 *3.3V // to get the actual reading
The method that I've tried though gives a slightly better result, but still not good enough (the reading is still off by +- 0.2V)
Has anyone deal with this before? Any suggestions are welcomed.
I'll need your header files to give you a clear solution.
I also came across this issue when I used the WiFi.h everything seems to work fine without WiFi.h, for some reason the ESP32 analog pins(13,12,14,4..) are HIGH while using WiFi.h that's why when you connect the sensors to these pins the value returned is 4095 which is the highest value, I got around this by changing the pins to pin 32, 34, 35, 36 & 39.
I figured it out by plotting 3 piecewise equation to solve the problem on excel, reduced the error margin around +-0.02V (although region >3.1V around +-0.05V).
I would like to generate a frequency with the resolution of 0.1Hz from the range of 0.0 up til 1000.0 Hz ( Example such as 23.1 Hz, 100.5 Hz and 999.7 Hz) I have found that using AD9833 we can generate the signal as what I was required, but the notes are a bit confusing to me.
The specification can be obtained HERE .
Need your kind assist to if we can make the Arduino code.. lets say, to generate a signal of 123.4 Hz via Serial monitor from Arduino and it displayed as it is in the oscilloscope?
Thank you.
Looking at the notes, it appears that programming this chip will be non-trivial. If you don't require frequencies all the way down to 0 Hz, this job can be done much more easily with a standard Windows sound card. (Sound cards are AC-coupled, so won't go below a few Hz.) For one example, my Daqarta software can generate frequencies (with any waveform you want) at a resolution better than 0.001 Hz. The maximum frequency will be a bit less than half the sound card's sample rate... typically 20 kHz at the default 48000 Hz sample rate.
You don't have to buy Daqarta to get this capability; the Generator function will continue to work after the trial period... free, forever.
UPDATE: You don't mention what sort of waveforms you need, but note that if you can use square waves you may be able to do the whole job with the Arduino alone. The idea is to set up a timer to produce interrupts at some desired sample rate. On each interrupt you add a step value to an accumulator, and send the MSB of the accumulator to an output pin. You control the output frequency by changing the step value. This is essentially a 1-bit version of the phase accumulator approach used by the AD9833 (and by the Daqarta Generator). The frequency resolution is controlled by the sample rate and the size of the accumulator. You can easily get much better than 0.1 Hz resolution.
Best regards,
I was working on this project : http://elm-chan.org/works/sd8p/report.html
and I failed in every possible way from the start. Now that the .Hex files have been uploaded, and the fuses written, when I plugged the SD card in, nothing happened. Nothing at all. Directly asking for a solution might be impossible here as I have no idea what went wrong. So instead I tested the speaker's positive connection with the arduino serial plotter, and I found some interesting results. The output gave some cool irregular pattern of waves,similar to what I would expect from a sound output. But there was no sound, and I suspect that it was because of the output size being too small.(60/1023 is around 0.06 volts, 200/1023 is around 0.2 volts and the bigger output at 500++ levels out, so it shouldn't produce a sound.)
So now I would like to ask whether I can change the fuses of the .hex file(or the hex file itself, but its big.) to produce a larger output. I have not much understanding in hex files or even AVR devices, so any hep at all would be useful.
Thanks in advance.
the graphs
Please let me know if any other information is needed.
Your voltage output on a GPIO pin is limited to your supply voltage, so no you probably can't fix your problem by changing the software or the fuse bits. Depending on your current supply voltage, you might be able to crank that higher, which would increase your voltage output of the PWM, but the supply voltage can only go so high without damaging the chip.
That being said, you need to disconnect the amp and speaker from the AVR and probe the output pin of the PWM and make sure that it is actually producing a signal on that pin. The plots that you posted with that amplitude look like they are nothing but random electrical noise to me.
I am doing a project on self balancing quadcopter with Autonomous control. I am using Arduino Mega 2560 and MPU6050. I have obtained the roll and pitch angles from MPU6050 without the help of DMP and applied complex filter to omit the noise due to vibration.
Also configured and able to run the BLDC motors with Flysky Transmitter and receiver with the help of Arduino interrupts. Now for balancing I am focusing on only one axis (i.e. roll). I have also constructed a balancing stand for the free movement of roll axis by the motor.
For the controlling part, I am implementing PID algorithm. I tried using only the kp value so that, somehow I can balance and then move on to ki and kd term. But unfortunately, for Kp itself, the quadcopter is undergoing aggressive oscillation and is not settling at all.
Some of my queries are:
Whether a single PID loop is enough, or we have to add another?
What type of tuning method I can implement, to find the kp, ki, kd other than trial and error?
I programmed my ESC for 1000 to 2000 microseconds. My PID input angles will be within the range +/- 180. Whether I can directly set the PID output limits for range -1000 to 1000 or -180 to 180 or any other value?
The code can read from the URL https://github.com/antonkewin/quadcopter/blob/master/quadpid.ino
Since its not provided, I am assuming that:
The Loop time is atleast 4ms. (The less the better)
The sensor noise is been reduced to an acceptable level.
MPU-6050 needs gyro+accel data to be combined to get angles in degrees.
If the above points are not taken care of, it will Not balance itself.
Initially, you can get away without tuning kI. So let's focus on kP and kD:
Keep increasing Kp till it starts oscillate fast. Keep the Kp value half of that.
With kP set, start experimenting kD values, as it will try to dampen the overshoots of kP.
Fiddle around these two values, tune it for perfection.
Note, the more accurate your gyro data is, the higher you can set your kP to.