Re: [Discuss-gnuradio] AMSAT programming help needed
AMSAT (the Radio Amateur Satellite Corporation) is working with its partners on a Cubesat (4 inch cube satellite) to be launched in the next few months. We need experienced help programming an MPS-430 (TI Microcontroller). Is that the same as the MSP430 (see Wikipedia)? I see references to both. If you are a U.S. citizen (sorry, ITAR and out of my hands) and are interested in helping, please email me directly. Can you describe (or point to a URL for) the specific need for ITAR restrictions on this software? I looked, but found nothing on the AMSAT site. ITAR is never out of our hands. We beat these bastards on encryption, and we can beat them on satellites too. All it takes is a global, scientifically published, shared effort. There are Cubesat's being built all over the world. They don't follow US ITAR rules. The next rocket they'll launch on is in India. Clue? If you live outside the US, and you program this, AMSAT is free to use it. AMSAT is free to import code. This is a large part of how we beat the bastards. We just stopped writing crypto code in the US, or buying crypto code from US companies. We started contracting with foreigners. ITAR prohibited us from teaching them to write it, but they could learn to write it themselves, and we could pay them to import the results. (And they were free to ship the code to any other country in the world -- unlike us.) Smart people among the billions of non-US citizens figured out for themselves that they could learn to write it (whether or not we paid them). The center of crypto software development moved outside the US. Which is exactly what the ITAR rules were trying to prevent. E.g. Europeans designed a better replacement for DES, which became AES in a fair, global competition. Eventually even the thick heads among the spooks got the message, and the crypto export rules changed. The sooner we have MPS-430 Cubesat software that's built in a free country, available to any space experimenter worldwide, published under a free license, the sooner we'll all have access to space. John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio block for boolean operations
On 2/14/08, Tim Meehan [EMAIL PROTECTED] wrote: 1) gr_xor_bb, gr_and_bb, gr_or_bb, br_not_bb ... This would be the way to go. Alternatively, you could create these blocks as _ss or _ii, and work on packed data. Depending on where in your flowgraph you need this operation, this would be much faster. See: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-gpio/src/lib/gpio_and_const_ss.cc ...for an example of a block that logically ANDs a stream of short integers with a constant value. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and gnuradio errors - seems to disconnectoften
Casey Tucker wrote: I've been doing some testing with a new USRP (manufactured 12/2007). My configuration is an Intel USB interface on a P965-S motherboard. I dual-boot XP SP2 and Arch Linux. In XP I've used Cygwin and MinGW. I've tried removing all but the TVRX board (which is mainly what I'm attempting to test), and my problems persist. I've also switched to another USB cable just to be sure. What seems to be happening, is at random intervals while running the test scripts (mainly usrp_wfm_rcv.py and usrp_tv_rcv), the GUI hangs, and when I exit the GUI, I get messages as follow: uOuOuOuOuOuOread: usb_reap_async: usb_reap_async: error: A device attached to the system is not functioning. I am familiar with this message. In my case, it occurs often (with Cygwin or MinGW) when I turn on (or sometimes off) any of several devices (desk lamp, power supply, amplified speakers) in my computer room. Using a constant-voltage isolation transformer on either the USRP or desk lamp makes no difference. The desk lamp, USRP, and computer are plugged into separate surge suppressors or outlet boxes. Devices elsewhere in the house have no effect. usb_control_msg failed: error sending control message: win error: The device does not recognize the command. usb_control_msg failed: error sending control message: win error: The device does not recognize the command usrp_basic_rx: set_fpga_rx_enable failed usb_control_msg failed: error sending control message: win error: The device does not recognize the command. usb_control_msg failed: error sending control message: win error: The device does not recognize the command. usrp_basic_rx: failed to fini AD9862 RX regs I have not noticed these other messages. I've tried using two versions of usblib (0.1.10.1 and 0.1.12.1), and even tried loading different firmware. The result is always the same. It also does not matter which environment I'm using, Cygwin, MinGW, or Linux; the result is the same. The other board I've tried using is the FLEX900 -- same results with its scripts. I am using LFRX and also get similar errors under Linux. I'm left to assume that I have faulty hardware, but I'm wondering if I'm the only one who is experiencing such problems. Any ideas? Anyone? I've followed the wiki instructions exactly. My guess is that it is a hardware problem, but not necessarily in the USRP hardware. It would be interesting to see if other USB 2.0 devices that run continuosly at high data rates see similar disruptions, but I don't have any other such devices to test. -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio block for boolean operations
Johnathan, I have attached a patch to gnuradio-core/src/lib/gengen that provides gr_xor_bb, gr_xor_ii and gr_xor_ss. The patch also contains qa code dumped into gnuradio-core/src/python/gnuradio/gr If this is the format you are looking for I will quickly gen up some other boolean functions. If you don't think it is appropriate for incorporation into the code base that is OK to. I think the gengen directory should have svn:ignore set on Makefile.gen and gengen_generated.i. These both show up in the svn diff but I removed them from the patch The svn:ignore flag will need to be set for new generated c/h files i.e. gr_xor_bb.c gr_xor_bb.h ... Tim On Feb 16, 2008 8:09 AM, Johnathan Corgan [EMAIL PROTECTED] wrote: On 2/14/08, Tim Meehan [EMAIL PROTECTED] wrote: 1) gr_xor_bb, gr_and_bb, gr_or_bb, br_not_bb ... This would be the way to go. Alternatively, you could create these blocks as _ss or _ii, and work on packed data. Depending on where in your flowgraph you need this operation, this would be much faster. See: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-gpio/src/lib/gpio_and_const_ss.cc ...for an example of a block that logically ANDs a stream of short integers with a constant value. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ boolean_patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] USRP and gnuradio errors - seems to disconnectoften
I acquired another USRP with the same configuration yesterday and tested it, and I had the exact same results with it as I did with the first one. I also moved the power supply to an isolate circuit, and it had no effect. I do have powered speakers in my room, but I don't understand how they would have any effect on the stability of my USB device. I use other USB and FireWire devices in my computer with a good amount of reliability on all of them. I've also tried disconnecting these devices as well; nothing changes. BTW, I'm using gnuradio-3.0.2 on windows, and 3.1.1 on linux. From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Casey Tucker wrote: I've been doing some testing with a new USRP (manufactured 12/2007). My configuration is an Intel USB interface on a P965-S motherboard. I dual-boot XP SP2 and Arch Linux. In XP I've used Cygwin and MinGW. I've tried removing all but the TVRX board (which is mainly what I'm attempting to test), and my problems persist. I've also switched to another USB cable just to be sure. What seems to be happening, is at random intervals while running the test scripts (mainly usrp_wfm_rcv.py and usrp_tv_rcv), the GUI hangs, and when I exit the GUI, I get messages as follow: uOuOuOuOuOuOread: usb_reap_async: usb_reap_async: error: A device attached to the system is not functioning. I am familiar with this message. In my case, it occurs often (with Cygwin or MinGW) when I turn on (or sometimes off) any of several devices (desk lamp, power supply, amplified speakers) in my computer room. Using a constant-voltage isolation transformer on either the USRP or desk lamp makes no difference. The desk lamp, USRP, and computer are plugged into separate surge suppressors or outlet boxes. Devices elsewhere in the house have no effect. My guess is that it is a hardware problem, but not necessarily in the USRP hardware. It would be interesting to see if other USB 2.0 devices that run continuosly at high data rates see similar disruptions, but I don't have any other such devices to test. -- Don W. _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
