Re: [Discuss-gnuradio] Dead USRP box?
G'day Bob, this is exactly what happened to my USRP board. The board seems operational except it won't communicate. I've ordered the FX2 chip from DigiKey as I believe it to be faulty. Digikey actually managed to sent me the wrong part, a RAM chip, inside an otherwise correctly labled package. The hopefully correct part is on its way, so it shouldn't be long until we know if it fixed the problem. It just begs the question, what causes this chip to fail? As described by Bob, it was left off for several month and failed on subsequent power up. Seasons Greetings, cheerio Berndt On Sunday 21 December 2008 12:48:40 Bob Cameron wrote: > Hi All > > I purchased a USRP some time ago, had it working and then left it for a > while. > > I suspect that the USB port has been zapped. > > Question. Is it safe to assume that there should be some kind of response > in /var/log/messages on connection of the USB cable? > > I have tried the usual switching of ports and cables, pulling > daughterboards, the LED is blinking and the 24MHz oscillator can be heard > on the nearby HF radio. > > I can no doubt tackle the debugging by looking up the chip specs. Any > start point ideas would be welcome though. > > Cheers Bob VK2YQA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dead USRP box?
Hi All I purchased a USRP some time ago, had it working and then left it for a while. I suspect that the USB port has been zapped. Question. Is it safe to assume that there should be some kind of response in /var/log/messages on connection of the USB cable? I have tried the usual switching of ports and cables, pulling daughterboards, the LED is blinking and the 24MHz oscillator can be heard on the nearby HF radio. I can no doubt tackle the debugging by looking up the chip specs. Any start point ideas would be welcome though. Cheers Bob VK2YQA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC and OS X 10.5.6
The check for the gtk module is failing, however, a second check for the gtk version is also failing, I need to fix this so its test is run conditionally upon gtk actually existing. Anway -> > checking for Python Cheetah templates... no > checking for Python GTK wrappers... no > checking for Python XML wrappers... no this means that the import of these modules has failed. Python cannot find them... Perhaps your python path is not set up properly. Consult the relevant mac os guides. Maybe someone familiar with mac os will chime in... -Josh Einar Thorsrud wrote: Hi all. I am trying to install Gnu Radio with OS X Leopard, following the instructions on: https://radioware.nd.edu/documentation/install-guides/mac-os-x , and several others for inspiration. Most components seem to configure without a problem, but when using ./configure --enable-grc , a problem occurs, and the errors are: checking for xdg-mime... false checking for Python version 2.5... yes checking for Python Cheetah templates... no checking for Python GTK wrappers... no checking for Python XML wrappers... no checking for GTK version >= 2.10.0... Traceback (most recent call last): File "", line 1, in ImportError: No module named gtk ./configure: line 46951: test: =: unary operator expected no configure: error: Component grc has errors; stopping. I have installed the latest gtk2 using port, and all other recomended packages. Is there any other trics that I am missing? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC and OS X 10.5.6
Hi all. I am trying to install Gnu Radio with OS X Leopard, following the instructions on: https://radioware.nd.edu/documentation/install-guides/mac-os-x , and several others for inspiration. Most components seem to configure without a problem, but when using ./configure --enable-grc , a problem occurs, and the errors are: checking for xdg-mime... false checking for Python version 2.5... yes checking for Python Cheetah templates... no checking for Python GTK wrappers... no checking for Python XML wrappers... no checking for GTK version >= 2.10.0... Traceback (most recent call last): File "", line 1, in ImportError: No module named gtk ./configure: line 46951: test: =: unary operator expected no configure: error: Component grc has errors; stopping. I have installed the latest gtk2 using port, and all other recomended packages. Is there any other trics that I am missing? -- Einar Thorsrud Singsakerbakken 2B-26 N-7030 Trondheim +47 958 77 206 eina...@stud.ntnu.no ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Carrier Deactivation for OFDM Transceiver
Hi fellas, I am actually trying to change the ofdm module in the gnuradio library in order to add some carrier deactivation capability to it. As a matter of fact I need to feed carrier deactivation data dynamically as an array of zeros and ones from spectrum sensing module to the ofdm block right before the ifft module in order to obstrcut data for some of the carriers. Should I create a new gnuradio block and put it before ifft module for this? or there may be some other less painful ways to do this. I appreciate any of you help and I was wondering if anyone has already impelemented such a system and some code is publicly available. Cheers, Rahman Doost ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Fwd: [Discuss-gnuradio] Big bugs out of nowhere...
On Sat, Dec 20, 2008 at 06:38:45PM -0300, Igor Almeida wrote:
>
> Hi Johnathan,
>
> Thank you for the insight. I was indeed NOT a user of the usrp group
> to which udev was configuring the block device.
> The thing is, we have an LDAP-configured network here, and we use it
> to fetch a number of configs, including groups, passwords and whatnot.
>
> Bottom line, there were two 'usrp' groups: one from /etc/group, with
> no members; and the other was from LDAP, with myself as member.
>
> So I removed the usrp group from /etc/group{,-}, and it no longer
> exists acording to 'getent group|grep usrp', but now udev seems to be
> confused as it changes the permissions correctly, but the group
> association is not performed:
> /dev/bus/usb/007:
> total 0
> crw-rw-r-- 1 root root 189, 768 2008-12-19 06:38 001
> crw-rw 1 root root 189, 769 2008-12-19 09:50 002
>
> Notice the crw-rw block, which showed up when I plugged the usb cable.
>
> So if udev cannot be aware of the usrp group fetched from LDAP, the
> whole LDAP-centralizing-access-permissions scheme goes down, because I
> will have to manually create and maintain/synchronize the usrp group
> in every machine on the lab.
Have you looked at any of the system log files? Usually /var/log/*
They'll probably tell you what's going on.
There may also be a way to increase the level of debug output from udev.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Fwd: [Discuss-gnuradio] Big bugs out of nowhere...
Oops, sorry for this. I thought I sent the e-mail to the list but just
noticed only Johnathan got it.
I am posting it again hoping that someone can help.
-- Forwarded message --
From: Igor Almeida
Date: Fri, Dec 19, 2008 at 10:04 AM
Subject: Re: [Discuss-gnuradio] Big bugs out of nowhere...
To: Johnathan Corgan
Hi Johnathan,
Thank you for the insight. I was indeed NOT a user of the usrp group
to which udev was configuring the block device.
The thing is, we have an LDAP-configured network here, and we use it
to fetch a number of configs, including groups, passwords and whatnot.
Bottom line, there were two 'usrp' groups: one from /etc/group, with
no members; and the other was from LDAP, with myself as member.
So I removed the usrp group from /etc/group{,-}, and it no longer
exists acording to 'getent group|grep usrp', but now udev seems to be
confused as it changes the permissions correctly, but the group
association is not performed:
/dev/bus/usb/007:
total 0
crw-rw-r-- 1 root root 189, 768 2008-12-19 06:38 001
crw-rw 1 root root 189, 769 2008-12-19 09:50 002
Notice the crw-rw block, which showed up when I plugged the usb cable.
So if udev cannot be aware of the usrp group fetched from LDAP, the
whole LDAP-centralizing-access-permissions scheme goes down, because I
will have to manually create and maintain/synchronize the usrp group
in every machine on the lab.
On Wed, Dec 17, 2008 at 5:34 PM, Johnathan Corgan
wrote:
> On Wed, Dec 17, 2008 at 6:56 AM, Igor Almeida wrote:
>
>> File "/usr/local/gnuradio/lib/python2.5/site-packages/gnuradio/usrp.py",
>> line 79, in _look_for_usrp
>>raise RuntimeError, "Unable to find USRP #%d" % (which,)
>> RuntimeError: Unable to find USRP #0
>
> Can you use the 'groups' command to verify the user running the script
> really is a member of group 'usrp'? Also, you may need to log the
> user out and back in for the group membership to become effective.
>
> -Johnathan
>
--
Igor Almeida
--
Igor Almeida
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Mblock library API update
In the latest trunk (r10144), the C++ header files for the mblock library have been moved into their own subdirectory. For those people using the mblock library, in your source code you will need to change the #include statements as follows: #include ...becomes #include You will need to do this for all mb_* header files you use. The changes have already been made to the USRP in-band mblocks. It is recommended that you do a 'make uninstall' before 'svn update', then re-install after re-compiling the updated trunk. Otherwise, you may be left with both the old and the new copies of the files. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [zfs-discuss] panic()
El Dec 20, 2008, a las 12:56 PM, Richard McClellan escribió: On Dec 20, 2008, at 08:35 , Christian Kendi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Noel, this was my laptop HD. As this occurs i was writing in Word, therefore no sleep or remove. Don't laptops spin down/sleep hard drives if they're inactive? If you stop for a long moment and think while you're writing, it may be long enough (especially if on battery) for the OS to do something to the drive that ZFS doesn't like. I'm pretty sure it didn't spin down as i was doing intensive drive work. I was just switching to the Word app while compiling in background. I wasnt on battery either. Anyways, just to let you know what i've done. The hardware failiure is possible, but will this happen every time on a non-disasterous hardware failure ? It was nothing dramatic, as the SMART of the HD is fine this time. What would happen if i get continous read/write errors due to damaged sectors. How will ZFS react on this? If ZFS encounters read errors (comparing checksums from different copies of the same block when reading or doing a scrub) it will flag the drive, but it won't take it offline. But... your laptop probably only has the one drive, so unless you set the ZFS copies property > 1 you won't know there's a problem. thought so. I was just curious in regards to this panic(), what would happen once there are faulty sectors and the read/write may get async. As you said this could have happend because of a spin down/sleep. Once you have bad sectors the HD automatically stop's and restarts its reading/writing activity i.e. try to recover. Would the system continue to function or would it panic? Are there any tests for this bahaviour? Rich Greets, Chris. > > > looks like you've either ripped out a drive prematurely, your drive > went to sleep, or your drive had a hardware failure. At any rate, ZFS > can't find it to write to it so panic ensues since they were > ansynchronous writes we've already returned success on and this would > make disk state inconsistent. > > In Snow Leopard we are thinking of changing this so that we will > actually freeze the pipleline if this occurs and be alerted you've > lost data. > > Noel On Dec 19, 2008, at 2:28 PM, Christian Kendi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > im just off to report a kernel panic. The website wont send me an > activation mail, so i just do it here. > > Thu Dec 18 15:28:26 2008 > panic(cpu 0 caller 0x00C08D21): "ZFS: I/O failure (write on > off 0: zio 0x4a2eab0 [L0 ZFS plain file] 1800L/1800P > DVA[0]=<0:144b278800:1800> fletcher2 uncompressed LE contiguous > birth=26685 fill=1 > cksum=758849a10b2fd5b6:4bfc8c90062499f1:c0fc06747bfaa98b: > 1cf76936dedc736d): error " "5"@/Volumes/pixie_dust/home/ndellofano/ > zfs-work/zfs-119/zfs_kext/zfs/zio.c:918 > Backtrace (CPU 0), Frame : Return Address (4 potential args on stack) > 0x38893e38 : 0x12b4f3 (0x45b13c 0x38893e6c 0x1335e4 0x0) > 0x38893e88 : 0xc08d21 (0xc786b0 0xc786a4 0xc74400 0xca5670) > 0x38893f08 : 0xc053fb (0x4a2eab0 0x16f5 0x38893f28 0xc4c18a) > 0x38893f48 : 0xc644a6 (0x4a2eab0 0x47f8800 0x271356 0xc8d5f4) > 0x38893fc8 : 0x1a017c (0x481c500 0x0 0x1a30b5 0xd2036b0) > Backtrace terminated-invalid frame pointer 0 > Kernel loadable modules in backtrace (with dependencies): > com.apple.filesystems.zfs(8.0)@0xbf1000->0xcbcfff > > BSD process name corresponding to current thread: kernel_task > > Mac OS version: > 9G55 > > Kernel version: > Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; > root:xnu-1228.9.59~1/RELEASE_I386 > System model name: MacBook1,1 (Mac-F4208CC8) > > Regards, > Chris. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFJTB/1p+9ff145KVIRAkJnAJ9DDhnUj9s7K0HBz28G/lkU9CkhEQCfQCfP > UbNbwThBjfpx4N389JqfcD4= > =/qFD > -END PGP SIGNATURE- > ___ > zfs-discuss mailing list > zfs-discuss at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/zfs-discuss -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJTR7Dp+9ff145KVIRApysAJ9I9U1oKnpWR6wh4EOFeu1tBWt74wCdH5rL 4sE/J26J/tK1m8BacbA7czg= =lMRB -END PGP SIGNATURE- ___ zfs-discuss mailing list zfs-disc...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/zfs-discuss PGP.sig Description: Mensaje firmado digitalmente ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
