Hi,
For anyone interested into digging into this, here are some recordings
of the mic RF signal during talks at GRCon 15
http://people.osmocom.org/~tnt/grcon/mic-f5.030000e%2b08-s2.000000e%2b06-t20150826090018.cfile
http://people.osmocom.org/~tnt/grcon/mic-f5.030000e%2b08-s2.000000e%2b06-t20150826090030.cfile
(Hehe, I bet you didn't expect that when you clicked on that email title :p)
Microphone system is from Shure, their ULXD line of products (
http://www.shure.com/americas/products/wireless-systems/ulxd-systems )
FCC filing for the microphone that was used: https://fcc.io/DD4ULXD1G50
Modulation is 8-PSK and symbol rate is 156250 sym/s
Cheers,
Sylvain
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Saturday, August 29, 2015
[Discuss-gnuradio] Installing OOT Module on Mac
Hello,
I'm using GNURadio 3.7.8 installed from MacPorts on a MacBook Air.
I have tried to create a custom module on my MacBook Air using gr_modtool.
I was able to write, compile and build the code.
After this I edited the XML file for accessing on gnuradio-companion.
But the block didn't show up on gnuradio-companion.
so I have set the following in .bash_profile
export GRC_BLOCKS_PATH="<required folder>"
and I was able to see the newly generated block.
But when I run the flowgraph I get the following error.
ImportError: No module named <module name>
In linux there is sudo ldconfig command, but the command doesn't exist on Mac
So after
"sudo make install"
Is there anything else to do for mac?
Thanks
Vamsi and Rich
Re: [Discuss-gnuradio] What factor determines input_item size (ninput_items)?
Dear, Marcus
Sorry for telling it. It is just my mistake.The Gist codes that I've referred on the previous post were wrong.
I've forgot editting codes related with the second input stream (input_items[1] and ninput_items[1]) after I removed the second input stream from a block.
So, `ninput = min(ninput_items[0], ninput_items[1])` was doing some undefined behavior.
And my own machine reads garbage value of ninput_items[1] as 32767,
so the equation is simplified to `ninput = ninput_items[0]`.
But the machine that the school gave me reads garbage value as something smaller than 240, 480, etc...,
so the `to_consume` will be zero according to my state machine.
After fixing the codes, I can get the same and correct behaviors and results on both machines.
In short, it has nothing to do with spec. of a machine.
It's just all my fault.
Regards,
Jeon.
2015-08-29 2:34 GMT+09:00 Marcus Müller <marcus.mueller@ettus.com>:
Hi Jeon,
What factor determines input_item size (ninput_items)?
these are two things: the input item size is the size of a single item, and ninput_items is the amount of items that your (general_)work call sees.
You are referring to the second thing:
Consider this flow graph:
A -> B -> C
A is the upstream block (e.g. USRP source), B is your block, and C is a downstream block (e.g. Vector sink).
ninput_items is determined by how many samples are available. Your block B has no influence on it; whenever the upstream block A finishes doing its (general_)work, GNU Radio updates the number of items available in the buffer between A and B. It then asks B whether it wants to work on this amount of input samples.
I see your forecast method, and it seems to do the right thing: If your block is in the SYNC state, to output anything, it needs 480 items. If there's no 480 input items, GNU Radio won't call your general_work, usually. You should try printing ninput_items, to see if that's correct.
Now, your block has two input streams. If they are somehow related, timing and buffer sizes might actually lead to a deadlock situation. Can you give us an overview over the whole flowgraph?
Best regards,
Marcus
On 28.08.2015 19:00, Jeon wrote:
I am testing my OOT module in various condition of different machines.A certain block implementing a state machine requires a certain number of items or more.
Thus, I've stated it in forecast():
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp
In general work(), the block determines how many items it should be consume:
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp
With these codes, it works find with my own machinie.
Ubuntu 14.04, 2 CPUs and 4 GB RAM allocated virtual machine. The host has i7-3770 and 16 GB RAM.
But it fails on machine that my school gave to me for educational and research purposes. I can't tell you the exact spec. of the machine, but it apparently has a poor CPU and a lower memory space.
Do these difference on machines' specs affect on ninput_items? I think they have a certain relation to each other... since GNU Radio scheduler allocates available memory over all blocks...? If so, can it be resolved if I manually set a larger memory/buffer size to GNU Radio? (If my memory is correct, I remember there's a configuration file to do it...)
Regards,
Jeon.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Friday, August 28, 2015
Re: [Discuss-gnuradio] FSK receiver
Hi Hoang,
Yes it's a problem with your design. You have 2 Msps feeding into an audio sink that probably goes up to 48 ksps. You need to change your sample rate from 2 Msps to a rate your sound card supports. I would target one of the default rates you can select from the audio sink. You can use polyphase arbitrary resampler block with the proper resampling ratio 2M/48k entered leaving the taps blank and the other parameters to default.On Fri, Aug 28, 2015 at 2:19 PM, Hoang Nguyen Tran <hoangnt09@gmail.com> wrote:
Dear all,
I have just built a FSK receiver aim to receive Cubesat data with FSK modulation with 9600 baud rate, below is my flow graph.I have just tested it with usb dongle RTL-SDR, however when I'm using audio sink, I received OOOOO (overrun I think) continuously .
Does it have anything wrong with my set up ?
samplerate 2Mcut off freq 9600transition 4800
I really appriciate for any comment on my FSK receiver flowgraph, I am a newbie :)
Thank you and best regard,Hoang
--
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FSK receiver
Dear all,
I have just built a FSK receiver aim to receive Cubesat data with FSK modulation with 9600 baud rate, below is my flow graph.
I have just built a FSK receiver aim to receive Cubesat data with FSK modulation with 9600 baud rate, below is my flow graph.
I have just tested it with usb dongle RTL-SDR, however when I'm using audio sink, I received OOOOO (overrun I think) continuously .
Does it have anything wrong with my set up ?
samplerate 2M
Does it have anything wrong with my set up ?
samplerate 2M
cut off freq 9600
transition 4800
I really appriciate for any comment on my FSK receiver flowgraph, I am a newbie :)
I really appriciate for any comment on my FSK receiver flowgraph, I am a newbie :)
Thank you and best regard,
Hoang
--
Re: [Discuss-gnuradio] What factor determines input_item size (ninput_items)?
Hi Jeon,
these are two things: the input item size is the size of a single item, and ninput_items is the amount of items that your (general_)work call sees.
You are referring to the second thing:
Consider this flow graph:
A -> B -> C
A is the upstream block (e.g. USRP source), B is your block, and C is a downstream block (e.g. Vector sink).
ninput_items is determined by how many samples are available. Your block B has no influence on it; whenever the upstream block A finishes doing its (general_)work, GNU Radio updates the number of items available in the buffer between A and B. It then asks B whether it wants to work on this amount of input samples.
I see your forecast method, and it seems to do the right thing: If your block is in the SYNC state, to output anything, it needs 480 items. If there's no 480 input items, GNU Radio won't call your general_work, usually. You should try printing ninput_items, to see if that's correct.
Now, your block has two input streams. If they are somehow related, timing and buffer sizes might actually lead to a deadlock situation. Can you give us an overview over the whole flowgraph?
Best regards,
Marcus
What factor determines input_item size (ninput_items)?
these are two things: the input item size is the size of a single item, and ninput_items is the amount of items that your (general_)work call sees.
You are referring to the second thing:
Consider this flow graph:
A -> B -> C
A is the upstream block (e.g. USRP source), B is your block, and C is a downstream block (e.g. Vector sink).
ninput_items is determined by how many samples are available. Your block B has no influence on it; whenever the upstream block A finishes doing its (general_)work, GNU Radio updates the number of items available in the buffer between A and B. It then asks B whether it wants to work on this amount of input samples.
I see your forecast method, and it seems to do the right thing: If your block is in the SYNC state, to output anything, it needs 480 items. If there's no 480 input items, GNU Radio won't call your general_work, usually. You should try printing ninput_items, to see if that's correct.
Now, your block has two input streams. If they are somehow related, timing and buffer sizes might actually lead to a deadlock situation. Can you give us an overview over the whole flowgraph?
Best regards,
Marcus
On 28.08.2015 19:00, Jeon wrote:
I am testing my OOT module in various condition of different machines.A certain block implementing a state machine requires a certain number of items or more.
Thus, I've stated it in forecast():
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp
In general work(), the block determines how many items it should be consume:
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp
With these codes, it works find with my own machinie.
Ubuntu 14.04, 2 CPUs and 4 GB RAM allocated virtual machine. The host has i7-3770 and 16 GB RAM.
But it fails on machine that my school gave to me for educational and research purposes. I can't tell you the exact spec. of the machine, but it apparently has a poor CPU and a lower memory space.
Do these difference on machines' specs affect on ninput_items? I think they have a certain relation to each other... since GNU Radio scheduler allocates available memory over all blocks...? If so, can it be resolved if I manually set a larger memory/buffer size to GNU Radio? (If my memory is correct, I remember there's a configuration file to do it...)
Regards,
Jeon.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What factor determines input_item size (ninput_items)?
I am testing my OOT module in various condition of different machines.
A certain block implementing a state machine requires a certain number of items or more.Thus, I've stated it in forecast():
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp
In general work(), the block determines how many items it should be consume:
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp
https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp
With these codes, it works find with my own machinie.
Ubuntu 14.04, 2 CPUs and 4 GB RAM allocated virtual machine. The host has i7-3770 and 16 GB RAM.
But it fails on machine that my school gave to me for educational and research purposes. I can't tell you the exact spec. of the machine, but it apparently has a poor CPU and a lower memory space.
Do these difference on machines' specs affect on ninput_items? I think they have a certain relation to each other... since GNU Radio scheduler allocates available memory over all blocks...? If so, can it be resolved if I manually set a larger memory/buffer size to GNU Radio? (If my memory is correct, I remember there's a configuration file to do it...)
Regards,
Jeon.
Subscribe to:
Posts (Atom)