[Discuss-gnuradio] Error: Block key variable_slider not found
Hey,
I am using the 3.7.2.1
on win7 64bit on a Lenovo i5
Gnuradio was installed from pre compiled bin
When it loads it display this :
Warning (from warnings module):
File
C:\Python27\lib\site-packages\cheetah-2.4.4-py2.7.egg\Cheetah\Compiler.py,
line 1509
\nYou don't have the C version
of NameMapper installed!
UserWarning:
You don't have the C version of NameMapper installed! I'm
disabling Cheetah's useStackFrames option as it is painfully slow with the
Python version of NameMapper. You should get a copy of Cheetah with the
compiled C version of NameMapper.
Warning: Block key
blocks_ctrlport_monitor_performance not found when loading category
tree.
Warning: Block key
blocks_ctrlport_monitor_performance not found when loading category
tree.
Welcome to GNU Radio Companion 3.7.2.1
And then I open the dial_tone example to see if it's
working o.k and I get:
Loading:
C:\Python27\gnuradio\share\gnuradio\examples\audio\dial_tone.grc
Error: Block key variable_slider
not found in Platform - grc(GNU Radio Companion)
Traceback (most recent call last):
File
C:\Python27\gnuradio\bin\gnuradio-companion.py, line 70, in
module
try:
gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc', 256, 0))
GError: Icon 'gnuradio-grc' not present in theme
Error: Block key variable_slider
not found in Platform - grc(GNU Radio Companion)
Traceback (most recent call last):
File
C:\Python27\gnuradio\bin\gnuradio-companion.py, line 70, in
module
try: gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc',
256, 0))
GError: Icon 'gnuradio-grc' not present in theme
Done
Showing:
C:\Python27\gnuradio\share\gnuradio\examples\audio\dial_tone.grc
It's not working + I can't add blocks…I see them on the
side screen but when I double click them nothing happen.
Thank's,
iftah ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to best use new GR features for TDMA systems ?
Hi, I suppose airprobe handled that sort of thing for GSM reception, back in the 3.6 days. airprobe does everything inside one big block which isn't really modular at all. But disturbing is your mention of frequency hopping, since that would require some real-time performance between the software and hardware, if it requires changing the center frequency (PLL synth) of SDR source/sink hardware. I'm would assume such latency is not guaranteed even slightly. Read again ... I said I use a channelizer to split a large bandwidth into several IQ stream and then to handle hopping I just go from one stream to another, I never retune the hardware. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to best use new GR features for TDMA systems ?
Following a frequency hopper within the sampled bandwidth shouldn't be that critical. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Wayne Roberts Sent: Saturday, 21 December, 2013 06:12 To: Sylvain Munaut Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] How to best use new GR features for TDMA systems ? I suppose airprobe handled that sort of thing for GSM reception, back in the 3.6 days. But disturbing is your mention of frequency hopping, since that would require some real-time performance between the software and hardware, if it requires changing the center frequency (PLL synth) of SDR source/sink hardware. I'm would assume such latency is not guaranteed even slightly. On Thu, Dec 19, 2013 at 11:05 AM, Sylvain Munaut 246...@gmail.com wrote: Hi, So I've wanted for a while to use GR more for TDMA systems I'm working with like GSM and GMR and I'm having a bit of trouble figuring out what the best way to do that. Back when I started osmo-gmr, GR didn't have many features to deal with packets and so I rolled my own hack to go from channelized IQ stream from Gnuradio to my demodulator function that takes sliced 'windows' of IQ samples of known length and ideally I'd like to replace most of it with GR. I'll try to explain below exactly what the current code does and what it must deal with and hopefully someone familiar with all the new packet feature of GR can guide me how to implement it in GR. The input comes from GR currently. It's basically a group of channelized IQ streams that correspond to the various channels. They don't necessarely have the same sample-rate, some can be N times larger (N being an integer). All those streams are synchronized and must be kept in sync (for example it's needed for hopping, or channel assignements, ...). Once the process is started, a sync detection task is started on each channel that will try to acquire initial alignement. This essentially captures a chunk of each channel long enough and give it as a big sample array to a function that will find sync pattern for whatever protocol it's configured for. Once it finds that pattern, it will initialize a TDMA context that basically knows how to slice the input into frames. Once those initial frames boundaries are known, the main TDMA scheduler can be started for each context that was created. This scheduler basically keeps a list of active / running tasks. An example of such a task would be a BCCH task that will slice the BCCH IQ samples (purely based on the samples number and acquired alignement and the known/specified TDMA scheduling) and hand them off to the BCCH demodulator function. Each of those task can spawn new tasks, possibly on other (or dynamic) channels. So if we see an IMMEDIATE ASSIGNEMENT command in the BCCH/CCCH for example, it will create a new 'SDCCH task' for example that will go and follow this channel with it's own state ... Now of course when starting a new task (after having demodulated / processed the IQ data), it's sometime important to know where in the IQ stream that command originated and it's important that the TDMA slicer didn't take too much advance because if it did, we might miss some of the TCH frames of the newly assigned channel. In the current code, everything is done in a single thread so I'm sure that the slicer didn't avance at all while I was processing the current packet. So, how would you implement this (architecture wise I mean) with PDUs / tagged stream / ... Cheers, Sylvain ___ 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
[Discuss-gnuradio] Passing a USRP pointer
We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably re-create it given some time. I started the porting of the blocks myself and did notice that getting the pointer to a USRP object had changed. But the blocks built without error when updated appropriately. Is there anything in principle that would prevent this from working in 3.7? Or, is there a better approach to controlling the WBX GPIO based on stream tags that we should consider? I apologize for the vagueness on the actual error. I'll try to reproduce it myself in the meantime. I can probably post the code for the PTT-controlling block if that would be any help. Very Respectfully, Dan CaJacob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Services running on gnuradio.org have been upgraded
All, Tom and I have migrated all the services for gnuradio.org onto a new server. Almost everything is unchanged, except for running newer versions of all the software, including the Redmine web server software. Some exceptions: * The repository browsing service at http://gnuradio.org/cgit has now been migrated to http://gnuradio.org/gitweb, and has a different look and feel. Some configuration remains to make the interface look like the rest of gnuradio.org. * Tom and I are using a different git system for pushing to the repositories (now gitolite vs. the older gitosis), so the commit messages to commit-gnuradio will look different and are much more verbose. * We now have a CAPTCHA system in place for signing up new users, which we are still working the kinks out of. But this will allow new web accounts to be automatically upgraded to allow posting of issues and wiki edits. Aside from the above, you should not see any difference in URLs or functionality. The new Redmine has a few new bells and whistles but nothing that requires relearning the interface. Please post here if you run into any issues. Thank you. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com attachment: johnathan.vcf signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Services running on gnuradio.org have been upgraded
On Sat, Dec 21, 2013 at 8:05 PM, Johnathan Corgan johnat...@corganlabs.com wrote: All, Tom and I have migrated all the services for gnuradio.org onto a new server. Almost everything is unchanged, except for running newer versions of all the software, including the Redmine web server software. Some exceptions: * The repository browsing service at http://gnuradio.org/cgit has now been migrated to http://gnuradio.org/gitweb, and has a different look and feel. Some configuration remains to make the interface look like the rest of gnuradio.org. * Tom and I are using a different git system for pushing to the repositories (now gitolite vs. the older gitosis), so the commit messages to commit-gnuradio will look different and are much more verbose. * We now have a CAPTCHA system in place for signing up new users, which we are still working the kinks out of. But this will allow new web accounts to be automatically upgraded to allow posting of issues and wiki edits. Aside from the above, you should not see any difference in URLs or functionality. The new Redmine has a few new bells and whistles but nothing that requires relearning the interface. Please post here if you run into any issues. Thank you. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com Just a quick update. I think that we fixed the issue with user registration. Please let us know if you experience any issues. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
