I have connected and external MCP3208 to my raspi PICO since my application requires atleast 8 reading simultaneously I use MCP3208. The problem is that the reading jumps not in the ranges of+/- 10 but 100s.I have to read maximum of 1V. The reference voltage is connected to the 3.3V. Also on measuring the input voltage at ADC it was constant. For example I measured a 0.189V at one of the channel but the ADC reading give values between 120 and 300.
Related
I'm trying to learn how the SPI protocol works, and I'm working on a basic project using the STM32F407G-Discovery board.
This board has a built-in accelerometer (LIS3DSH), and it uses the SPI protocol. In the user manual, it states the following:
The LIS3DSH has ±2g/±4g/±6g/±8g/±16g dynamically selectable full-scale
and it is capable of measuring acceleration with an output data rate
of 3.125 Hz to 1.6 kHz.
This accelerometer is using SPI1, which is connected to APB2. I'm using STM32CubeMX to generate the initialization code (including the clock configuration), and it looks like the APB2 peripheral clock has a default value of 84 Mhz.
Does this mean that I need to configure the APB2 peripheral clock to have such a value that it falls between the range of 3.125 Hz and 1.6 kHz? I can't imagine this is true because I can't get the value low enough
in STM32CubeMX since it throws an error if I go too low.
I'm also accounting for the baud rate control SPI register, which allows you to go as low as f-PCLK/256.
In other words, I'm a bit stuck on which clock frequency to use and which baud rate control to use.
I'm still learning embedded programming, and so my terminology might be incorrect.
the two are not related. the max SPI clock rate is 10Mhz (page 14). The out rate of 3.125Hz to 1.6Khz is how fast the chip does an acceleration conversion. At 3.125Hz, a new conversion result is ready every 320ms, and at 1.6Khz, they are available every 625us. There is a trade off between conversion rates, power consumption and accuracy. The data sheet leaves a lot of holes, I would suggest reading the MMA7660 data sheet to get a better understanding of how these types of chips work and then revert back to your datasheet for implementation details.
You could use the SPI clock frequency with up to 10MHz to get data from this chip.
(So a prescaler of 16 and the full rate (84MHz) APB2 clock would be ok)
The SPI clock determines how fast the data is transferred from the chip to the controller not how fast the chip generated new results.
To always get the newest data you could use the IRQ lines from the chip or use an timer to trigger the transmission corresponding to sampling rate.
I have two USRP N210s connected together as a receiver and transmitter and I'm trying to send multi tone signals across the channel. However, I am finding extra frequency spikes mirrored about the centre frequency for when I send a signal with more than 2 tones.
I am using a low pass filter at the output with a cutoff frequency of 200kHz and the signal I am sending is constrained to 0-200kHz. I have an out of tree module that creates the multi tone signals that are evenly distributed within this bandwidth.
As I increase the number of tones the reflected frequency components become more and more prominent to the point at which I can barely correlate the input and output signals.
This is what the transmitted multi tone signals looks like
And here is the flowchart at the receiver end
The center frequency of the USRP source (receiver) is given by
uhd.tune_request(center_freq, rf_freq=(center_freq + lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL)
which evaluates to 2.48GHz for which is the baseband frequency for the transmitting USRP
It may be something to do with the down conversion in the USRP or when GNURadio is actually sampling from the receiver with respect to this process.
Removing the LPF and connecting the FFT sink to the USRP source doesn't fix anything. The extra frequency spikes are still there (assuming the number of tones > 2)
You're not specifying how you transmit your tones into the RX port of your USRP, but the most likely thing to have happened here is that you didn't use sufficient attenuation between TX and RX – and you're saturating the RX amplifier chain (hopefully not damaging it).
By saturating, you drive them into nonlinear operation, which would lead to a broadband intermodulation.
I am trying to transfer data over USB. These are packets of at most 64 bytes which get sent at a frequency of 4KHz. This gives a bit rate of about 2Mb/s.
The software task that picks up this data runs at 2.5 KHz.
Ideally we never want packets to get there slower than 2.5 KHz (so 2 KHz isn't very good).
Is anyone aware of any generic limits on what USB can achieve?
We are running on a main board which has a 1.33 GHz running QNX and a daughter board which is a TWR K60F120M tower system running MQX.
Apart from the details of the system, is USB supposed to be used in this kind of data transfers, i.e., high frequency and short packet sizes?
Many Thanks for your help
MG
USB, even at its slowest spec (1.1), can transfer data at up to 12MB/sec, provided you use the proper transfer mode. USB will process 1000 "frames" per second. The frames contain control and data information, and various portions of each frame are used for various purposes, and thus the total information content is "multiplexed" amongst these competing requirements.
Low speed devices will use just a few bytes in a frame to send or receive their data. Examples are modems, mice, keyboards, etc. The so-called Full Speed devices (in USB 1.1) can achieve up to 12 MB/sec by using isochronous mode transfers, meaning they get carved out a nice big chunk of each frame, and can send that much data (a fixed size) each time a frame comes along. This is the mode audio devices use to stream the relatively data-intensive music to USB speakers, for example.
If you are able to do a little bit of local buffering, you may be able to use isochronous mode to get your 64 bytes of data sent at 1 KHz, but with 2 or 3 periods (at 2.5KHz) worth of data in the USB frame transfer. You'd want to reserve 64 x 3 = 192 bytes of data (plus maybe a few extra bytes for control info, such as how many chunks are present: 2 or 3?). Then, as the USB frames come by, you'd put your 2 chunks or 3 chunks of data onto the wire, and the receiving end would then get that data, albeit in a more bursty way than just smoothly at a precise 2.5KHz rate. However, this way of transferring the data would more than keep up, even with USB 1.1, and still only use a fraction of the total available USB bandwidth.
The problem, as I see it, is whether your system design can tolerate a data delivery rate that is "bursty"... in other words, instead of getting 64 bytes at a rate of 2.5KHz, you'll be getting (on average) 160 bytes at a 1 KHz rate. You'll actually get something like this:
So, I think with USB that will be the best you can do -- get a somewhat bursty delivery of either 2 or 3 of your device's data packet per 1 mSec USB frame rep rate.
I am not an expert in USB, but I have done some work with it, including debugging a device-to-host tunneling protocol which used USB "interrupts", so I have seen this kind of implementation on other systems, to solve the problem of matching the USB frame rate to the device's data rate.
I'm doing a USB device is to control stepper motors. I've done this before using a parallel port. because these ports do not exist in current motherboards, I decided to implement a USB communication between my device and the PC (host).
To achieve My objective, I endowed the freescale microcontroller the device with that has a USB module 12Mbps.
My USB device must receive 4 bytes (one for each motor driver) at a given time, because every byte is a step that should move the engine.
In the PC (Host) an application of user processes a text file with information and make the trajectory coordinates sending bytes at a certain rate for each motor (time is trivial to achieve the acceleration and speed of the motors) .
Using the parallel port was an easy the task because each byte is sent sequentially to a time determined by the user app.
doing a little research about full speed USB protocol understood that the frame is sent every 1ms.
then you can send 4 byte or many more every 1ms but I can not manage time like I did with the parallel port.
My microcontroller can send up to 64 bytes per frame (Based on transfer papers type Control, Bulk, Int, Iso ..).
question 1:
I want to know in what way I can send 4-byte packets faster than every 1 ms?
question 2:
What type of transfer can advise me for these type of devices?
Thanks.
Like Ricardo said, USB-serial will suffice.
As for the type of transfer, try implementing a CDC stack and use your SCI receiver to listen for PC commands. That will give you a receive buffer which will meet your needs.
Initialize your SCI (baud, etc)
Enable receiver and interrupt
On data receive, move it to your 4-byte command buffer
Clear receive buffer, wait for more
When you have all 4 bytes, fire off the steppers! Four bytes should take µs.
Check with Freescale to see if your processor is supported.
http://cache.freescale.com/files/microcontrollers/doc/support_info/USB_STACK_RELEASE_NOTES_V4.1.1.pdf?fpsp=1
There might even be some sample code to get you started.
-Cheers
I am achieving the same goal (driving/control CNC machines) like this:
the USB device is just synchronous I/O parallel port. Using continuous bulk transfer one pipe as input and one as output. This way I was able to achieve synchronous 64bit parallel communication with ~70KHz sample rate. It uses traffic around (i)4.27+(o)4.27 MBit/s that is limit for mine MCU and code. Bigger speeds cause jitter on the output due to USB events interrupts.
How to do it (on MCU side)
I have 2 FIFO's one for ingoing and one for outgoing data. I have timer interrupt occurring with sample rate frequency. In it I read the inputs and feed it to the first FIFO and read data from the other FIFO and send it to the outputs.
On top of that the USB task is called (inside the same interrupt) checking FIFO for sending to and incoming data from USB handling the transfer itself
I choose ATMEL AT32UC3A chips for this task. After a long and pain full research I decided these MCU's because they have enough memory for both FIFO's and program so no need for additional IC. It has FPGA package which can be used (BGA is not an option). It has HS USB (most USB MCU's have only FS like yours). It runs at 66MHz. It supports many interesting features (did interesting projects with it in the past) and of coarse I have experience with ATMEL MCU's from past
So if you want to achieve something similar then
start with bulk transfer (PC -> USB -> MCU -> output)
add FIFO if needed
do not know the sample rate you need. The old LPT's could handle from 80-196KHz depend on the manufactor. The modern ones are much much slower (which is silly and sad).
measure the critical sample rate
you need oscilloscope or very good hearing for this. The output data must be synchronous so no holes in it, no jitter, etc...
if any of these are present you have to lower the sample rate. Mine setup could handle even 1MHz sample rate but the USB jitter was present (sometimes USB event froze the sending for longer that one sample...) so I achieve only 70KHz of stable output.
if needed also inputs then add them
but only if the output is working as it should. Do not forget to lower the sample rate after this too ... Use separate bulk pipes and FIFOs for input and output.
I don't have much knowledge about microcontrollers. In my project, I need to shift the sine wave. Here, I want to know, if I feed pure sine at port A pin 2. Then, will i get the shifted version of pure sine wave at port B pin 2 . will the following instruction work?
Inialise port A as input and port B as output
call delay
portb=porta
we can generate sine wave using DAC in microcontroller. But, as it is not perfect, it wont meet required conditions.
First of all the input needs to be to an ADC, and the output needs to be from a DAC (or a PWM with appropriate output filtering). It is not clear from your question that the pins you have chosen are appropriate for that.
If you are generating the sine from the DAC, why would you apply it to an input only to output it again? If you need two sine waves shifted in phase, why not simply generate calculated outputs from two DAC or PWM? Either way you need two analogue outputs, but that way you do not need any input. A PWM will need greater analogue filtering than a DAC and is likely to support lower bandwidth, but most microcontroller have more PWMs than DACs.
You cannot simply call a delay than copy port a to port b, that would be simply be a copy of a to b after a delay. You need to take samples from A and place then in a FIFO buffer, then apply the output of the FIFO to B. The length of the FIFO determines the delay.
A microcontroller is not an analogue device, you cannot put in an analogue signal on just any old pin and and transfer that signal to another pin. Most pins are digital GPIO, they except just two states representing 0 or 1. No matter what voltage you apply, it will be interpreted as either high or low.
Rather you will have to use an ADC input, sample at sufficiently high frequency, delay the samples through a FIFO, then apply the delayed samples to a DAC. Reconstruction of a "pure" sine wave from the quantized DAC output requires analogue filtering circuitry. With a filter cut-off lower than half the sampling rate you will recover a reasonably good representation of the original signal (which can be any signal with components below half the sampling frequency - it need not be a sine wave). If you do use a more complex signal, you will need to analogue filter the input to remove components above half the sampling rate to avoid aliasing.
It might be possible to do all that on one chip using a Cypress PSoC, since these are hybrid chips with reconfigurable analogue elements as well as a microcontroller.