I'm currently using MPLABX to code Pic16f877a, I use Proteus as a simulator, I have to identify what type of waveform I get at the analog input, my frequency is not fixed but I can store it. I wanted to use a full bridge rectifier so I get an input of 0-5V.
I was thinking I could check how much time it needs to get from 0 to 1V, from 1V to 2V, etc. for the square wave it would always be ~+5V.
I don't know if there's a better way of if this is even possible. I attach a piece of code that stores the frequency. MPLABX
Related
Note: Since the most logical cause of malfunction is that my component is faulty I have ordered a few more. Will test on them and let you know the result.
I am expanding an existing driver for the PCF8591 Analog to Digital converter, here's the Pcf8591 class in github.
Reading analog inputs works fine, but I have a strange problem when trying to write the output.
To test the driver I have a potentiometer connected to input channel 2, then I write that value to the analog output and then connect the analog output to the input 3.
The analog value only changes from 20 to around 75 for a value write from 0 to 255. I don't know if I am missing something or maybe my component is defective.
I am doing it the way it is specified by the spec sheet and also in the same way I've seen some drivers for Arduino doing it.
This is how I am writing the analog value:
byte[] data = {0x40, // Control code for writing analog value
(byte) (value)}; // Analog value
mI2cDevice.write(data, 2);
I'll appreciate if someone else with this component can try and see if writing the analog value works for them.
In theory the analog output goes from AGND to VREF and I am assuming the board I have have them linked to GND and VCC. I am using this board:
I'm pretty new to using GNURadio and I'm having trouble recovering the data from a signal that I've saved into a file. The signal is a carrier frequency of 56KHz with a frequency shift key of +/- 200hz at 600 baud.
So far, I've been able to demodulate the signal that looks similar to the signal I get from the source:
I'm trying to get this into a repeating string of 1s and 0s (the whole telegram is 38 bytes long and it continuously repeats). I've tried to use a clock recovery block in order to have only one byte per sample, but I'm not having much luck. Using the M&M clock recovery block, the whole telegram sometimes comes out correct, but it is not consistent. I've tried to adjust the omega and Mu values, but it doesn't seem to help that much. I've also tried using the Polyphase Clock sync, but I keep getting a runtime error of 'please specify a filter'. Is this asking me to add a tap? what tap would i use?
So I guess my overall question would be: What's the best way to get the telegram out of the demodulated fsk signal?
Again, pretty new at this so please let me know if I've missed something crucial. GNU flow graph below:
You're recovering the bit timing, but you're not recovering the byte boundaries – that needs to happen "one level higher", eg. by a well-known packet format with a defined preamble that you can look for.
I'm trying to demodulate a signal using GNU Radio Companion. The signal is FSK (Frequency-shift keying), with mark and space frequencies at 1200 and 2200 Hz, respectively.
The data in the signal text data generated by a device called GeoStamp Audio. The device generates audio of GPS data fed into it in real time, and it can also decode that audio. I have the decoded text version of the audio for reference.
I have set up a flow graph in GNU Radio (see below), and it runs without error, but with all the variations I've tried, I still can't get the data.
The output of the flow graph should be binary (1s and 0s) that I can later convert to normal text, right?
Is it correct to feed in a wav audio file the way I am?
How can I recover the data from the demodulated signal -- am I missing something in my flow graph?
This is a FFT plot of the wav audio file before demodulation:
This is the result of the scope sink after demodulation (maybe looks promising?):
UPDATE (August 2, 2016): I'm still working on this problem (occasionally), and unfortunately still cannot retrieve the data. The result is a promising-looking string of 1's and 0's, but nothing intelligible.
If anyone has suggestions for figuring out the settings on the Polyphase Clock Sync or Clock Recovery MM blocks, or the gain on the Quad Demod block, I would greatly appreciate it.
Here is one version of an updated flow graph based on Marcus's answer (also trying other versions with polyphase clock recovery):
However, I'm still unable to recover data that makes any sense. The result is a long string of 1's and 0's, but not the right ones. I've tried tweaking nearly all the settings in all the blocks. I thought maybe the clock recovery was off, but I've tried a wide range of values with no improvement.
So, at first sight, my approach here would look something like:
What happens here is that we take the input, shift it in frequency domain so that mark and space are at +-500 Hz, and then use quadrature demod.
"Logically", we can then just make a "sign decision". I'll share the configuration of the Xlating FIR here:
Notice that the signal is first shifted so that the center frequency (middle between 2200 and 1200 Hz) ends up at 0Hz, and then filtered by a low pass (gain = 1.0, Stopband starts at 1 kHz, Passband ends at 1 kHz - 400 Hz = 600 Hz). At this point, the actual bandwidth that's still present in the signal is much lower than the sample rate, so you might also just downsample without losses (set decimation to something higher, e.g. 16), but for the sake of analysis, we won't do that.
The time sink should now show better values. Have a look at the edges; they are probably not extremely steep. For clock sync I'd hence recommend to just go and try the polyphase clock recovery instead of Müller & Mueller; chosing about any "somewhat round" pulse shape could work.
For fun and giggles, I clicked together a quick demo demod (GRC here):
which shows:
I'm pretty much a noob when it comes to this kind of thing, so if you guys could either help me or direct me to a place to learn what I need to know, I would greatly appreciate it.
Basically my problem is that I am using the libpruio library to continuously sample analog values from the board. 2 things are going wrong here.
The first is that whenever the BB is sampling the voltages, the voltage of the wire that is hooked up to the AIN pin goes up. I've observed this through hooking up an oscilloscope to the same wire the pin is sampling. What I see is that whenever the BB starts sampling, the entire signal (just a sound wave from an amplified mic) is shifted up .8-.9 volts. This is also reflected in the values that I get from the BB, which are around 30,000 (when they should be 0). Hooking the pin up to ground gets me 0, which is correct, and hooking it up to 1.8 volts gets me something like 65520, which is also correct. So maybe it has something to do with the signal being weak?
The second issue is that even though I am receiving values at a rate of like 500khz-900khz, the actual rate seems to be around 11khz. What I mean by this is I only get a new value every 88us, and the rest of the values I get are stay the same as the new value until the next 88us passes, when I get a new value. These times correspond to the voltage shift up, which I mentioned in the previous paragraph. So actually what I see on the oscilloscope is that whenever I sample with the BB, there is a saw wave, with the frequency at the 11khz I was mentioning earlier.
In conclusion, whenever the BB samples, it first increases the voltage at the pin by .9volts, takes a sample of that voltage, and the voltage dies down for the next 88us, all the while the BB spits back the sample it took at the beginning of the period. I do not want this. I want it to not affect the voltage significantly, and take new samples every time the code runs.
As for the code I'm using, it's basically a slightly modified version of the IO_Input example in the libpruio library, with the values being stored in an array for later use instead of being printed immediately.
If you guys need any more information, I will gladly post it here, but for now I'm wondering if it is something super obvious that I'm missing.
Hooking the pin up to ground gets me 0, which is correct, and hooking
it up to 1.8 volts gets me something like 65520, which is also
correct. So maybe it has something to do with the signal being weak?
The BBB and libpruio seem to work OK. Check your wiring.
Regarding the sampling rate, the io_input example uses IO mode. If you need accurate timing for the samples use MM mode or RB mode.
Your target isn't very clear, so I cannot give detailed advices. (Some code also would help to understand what you're trying to do.)
BR
I am using http://shakithweblog.blogspot.kr/2012/12/getting-sobel-filter-application.html for zynq processor.
I am using his filter design in the PL part and running the hdmi test.
I am inputting this file
and my filtered output is coming like this:
I am trying to display 1920 * 1080 pixels.
Now lets assume its difficult for you see exactly my design/ or download the design and check it or even you are not familiar with the zynq board and all but is it possible to make some guess that why the filter output could be like this? and what can I try to make it correct. I need some suggestions.