I am using Beaglebone not Beaglebone Black.
I just tried to output a PWM and I expected potential frequencies of some megaherz on such a fast device.
I found out that 100HZ is the exact maximum I can set through sysfs.
I started digging online for examples and they did not mention a limit but they also did not show an value faster than 100HZ.
Example:
root#beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 10000000 > period_ns
root#beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 1000000 > period_ns
-sh: echo: write error: Invalid argument
root#beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 200 > period_freq
-sh: echo: write error: Invalid argument
root#beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 101 > period_freq
-sh: echo: write error: Invalid argument
root#beaglebone:/sys/class/pwm/ehrpwm.0:0# echo 100 > period_freq
root#beaglebone:/sys/class/pwm/ehrpwm.0:0#
Any 10cent AVR can do a faster PWM than that.
Is there some trick I missed?
Do I really have to create a custom PWM by manuallz toggling GPIO if I want a faster frequency than 100 HZ ?!
I actually found the solution just shortly after opening my question.
I will post it here as I think this might actually cause more than just me to wonder :)
The PWM frequency is of course not limited like that on a 1GHZ device, the kernel driver is just not working in the same way one would expect.
If you enter a duty_percent value (like 1 percent) then the driver seems to just calculate the duty_ns value out of it and forget about percent afterward.
A normal user would think he is in "percent mode" but actually the percentage file is just bound to a wrapper to help.
The same counts for the frequency!
If you now change the frequency to a higher value then then the kernel checks if the duty_ns cycle period fits into the new total period_ns!
It ignores that you actually set a percentage!
So of course you can not have an on-period which is larger than the whole period, so it fails.
Long text short summary:
Always set duty_cycle to zero BEFORE you set the frequency if the previous value will not fit into the new period, this avoids frustration.
Related
How do I set the block-size parameter when running grep using GNU parallel on a single machine with multiple cores, based on the "large_file" filesize, "small_file" filesize and machine I'm using to get the fastest performance possible (or please correct me if there is something else that im missing here)? What are the performance issues/speed bottlenecks I'll run into when setting it too high or too low? I understand what block-size does, in that it blocks out the large_file in chunks, and sends those chunks to each job, but I'm still missing the potential for how and why that would impact speed of execution.
The command in question:
parallel --pipepart --block 100M --jobs 10 -a large_file.csv grep -f small_file.csv
where large_file.csv has in it:
123456 1
234567 2
345667 22
and
where small_file.csv has in it:
1$
2$
and so on...
Thank you!
parallel --pipepart --block -1 --jobs 10 -a large_file.csv grep -f small_file.csv
--block -1 will split large_file.csv into one block per jobslot (here 10 chunks). The splitting will be done on the fly, so it will not be read into RAM to do the splitting.
Splitting into n evenly sized blocks (where n = number of jobs to run in parallel) often makes sense if the time spent per line is roughly the same. If it varies a lot (say, some lines take 100 times longer to process than others), then it may make more sense to chop into more bits. E.g. --block -10 will split into 10 times as many blocks as --block -1.
The optimal value can seldom be guessed in advance, because it may also depend on how fast your disk is. So try different values and identify where the bottleneck is. It is typically one of disk I/O, CPU, RAM, command startup time.
I'm trying to interpret the results of perf-stat run on a program. I know that it was run with -r 30 and -x. From https://perf.wiki.kernel.org/index.php/Tutorial is says that if run with -r the stddev will be reported but I'm not sure which of these columns that is and I'm having trouble finding information on the output when run with -x. One example of the output I've recieved is this
19987,,cache-references,0.49%,562360,100.00
256,,cache-misses,10.65%,562360,100.00
541747,,branches,0.07%,562360,100.00
7098,,branch-misses,0.78%,562360,100.00
60,,page-faults,0.43%,560411,100.00
0.560244,,cpu-clock,0.28%,560411,100.00
0.560412,,task-clock,0.28%,560411,100.00
My guess is that the % column is the standard deviation as a percentage of the first column but I'm not sure.
My question in summary is what do the columns represent? Which column is the standard deviation?
You are very close. Here are some blanks filled in.
Arithmetic mean of the measured values.
The unit if known. E.g. on my system it shows 'msec' for 'cpu-clock'.
Event name
Standard deviation scaled to 100% = mean
Time during which counting this event was actually running
Fraction of enabled time during which this event was actually running (in %)
The last two are relevant for multiplexing: If there are more counters selected than can be recorded concurrently, the denoted percentage will drop below 100.
On my system (Linux 5.0.5, not sure since when this is available), there is also a shadow stat for some metrics which compute a derived metric. For example the cpu-clock will compute CPUs utilized or branch-misses computes the fraction of all branches that are missed.
Shadow stat value
Shadow stat description
Note that this format changes with some other options. For example if you display the metrics with a more fine granular grouping (e.g. per cpu), information about these groups will be prepended in additional columns.
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:
Almost a month ago I started working on a digital communications project
which involves GNUradio.
And I am severely struggling to get past some errors or mismatches I am
encountering in GNUradio.
I am desperately in need of some expert help.
I made a DQPSK modulator and demodulator using just GNURADIO companion.(screenshots provided)
Gave a vector source with bits 0,1,0,1 and repeat on, on the input of
PSK modulator.
I also used an error rate block to calculate bit error rate.
(Vector source is on ref of error rate block and DQPSK demodulator output is on input).
I have connected wx gui scope to error rate block and constellation sink to PSK modulator.
Now almost everything that is appearing on the scopes is completely
wrong.
The bit error rate is 0.5, provided that I have added no noise (which is
max considering that we will recover 50 percent bits correctly just by
chance).
The scope connected at the PSK modulator output shows four constellation points
Even though I am transmitting only one symbol i.e (0,1).
What am I doing wrong?
Can someone please be kind enough to go through the screenshot and tell
me the mistake(s).
As Timothée Cocault said in his answer to your mail on the gnuradio-discuss#gnu.org mailing list:
Hi Haaris,
The documentation of the PSK Mod says : "The input is a byte stream
(unsigned char), treated as a series of packed symbols. Symbols are
grouped from MSB to LSB." You should add an "Unpacked to Packed block"
with 2 bits per chunk and MSB endianness before. Likewise, you should
add a "Pack K bits" block with K=2 after the PSK Demod.
Also, your assumption that you should have one point in the
constellation sink is wrong. You're using DQPSK so the (0, 1) symbol
will add 90 degrees to the phase, and you will cycle through the 4
points of your constellation.
And last, keep in mind that each block has a delay, and you can't
compare the input and output bits directly. Try to use a "Scope plot"
with 2 inputs, and add a delay block before the input bits to
synchronise the two.
Timothée.