[Discuss-gnuradio] USRP News -- April 18th, 2006
USRP News -- April 18, 2006 In this Issue - New Daughterboard Announcement - New Daughterboard Naming and Contest - TVRX Status - Inventory Status - American Express New Daughterboard Announcement We are pleased to announce the availability of the Daughterboard Which Would Have Been Called Flex900, or the DBWWHBC-Flex900. For the reasons why it will not actually be called the Flex900, please see the next section of this announcement. The DBWWHBC-Flex900 is a transceiver very similar to the DBFKA-Flex2400 (Daughterboard Formerly Known As Flex2400). It is a transceiver covering the 800-1000 MHz range which includes the 902-928 MHZ ISM band, cell phones, and several other interesting bands. The transmit power is adjustable up to well over 20 dBm (100 mW). It includes an ISM-band filter for reducing interference which can be enabled by removing one capacitor. For operation outside of the ISM band, simply leave the capacitor in place. The DBWWHBC-Flex900 costs $250, and will begin shipping next Wednesday. You can order it from the standard web ordering page, http://www.ettus.com/custom.html New Daughterboard Naming and Contest While we have never claimed to own the word Flex, we have recently received a Cease and Desist letter from a company which believes it does own it. FlexRadio Systems, a maker of HF and VHF SDR equipment for amateur radio, has requested that we completely discontinue the use of the word Flex. Not wishing to fight this, we have decided to comply. In order to choose a new name for the Flex-series of daughterboards, we have decided to have a naming contest. To enter, please send your suggestions to [EMAIL PROTECTED] with the subject Contest. On April 30th, we will choose the best entry, and from then on, the boards will be known by the new name. The winner will receive one free Flex-series (oops, said it again...) daughterboard of their choice. All decisions are final. Just to clarify the naming system, we have created this handy chart: Old NameInterim Name Final Name == Flex400 DBFKA-Flex400 ? 400 Flex900 DBWWHBC-Flex900? 900 Flex2400DBFKA-Flex2400 ? 2400 Best of luck to all entrants! == TVRX Status == We have been able to locate a source of the tuner modules used in the TVRX boards. This will allow us to continue to provide TVRX boards for the forseeable future. == Inventory Status == As of April 18th, all items are in stock except for the USRP motherboard. We expect to have USRP motherboards back in stock in early May. We are sorry for any inconvenience this may cause. == American Express == By popular demand, we are now able to accept American Express credit cards from the same web order page. Simply enter the card info in the fields provided. == Thank you, Matt Ettus President, Ettus Research LLC +1 (650) 814-8943 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] selective build of FPGA
i wish to build just one rx_hb and one tx.present usrp_std.vh has 2rx 1tx or 4rxwhat do i need to do to...do i need to modify usrp_std.vh or are the dependancies are deep rooted..thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Generating chrip signals
Hi At the moment I would like to see if I can generate a chirp signal. Looking through what gnuradio blocks are available, I assumed I could use the gr_fxpt_nco block to do something like this. I was wondering firstly if it would be possible, and secondly, how this block works and behaves when it's running. Regards Lance New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] swig error in compile, gr-atsc stuff
On Tue, 2006-04-18 at 17:00 -0400, Charles Swiger wrote:
Gang - Wonder if any of the block writing wizards could take a gander
at this and spot why the blocks compile, but error out on the - I don't
even know what you call it - the swig file?
atsc.cc:2178: error: `atsc_ds_to_softds_sptr' was not declared in this
scope OH NO
atsc.cc:2179: error: expected `,' or `;' before '{' token
Found it -
* Boston, MA 02111-1307, USA.
*/
#ifndef INCLUDED_ATSC_RS_ENCODER_H
#define INCLUDED_ATSC_RS_ENCODER_H -- D'oh!!!
#include gr_sync_block.h
#include atsc_types.h
class atsc_ds_to_softds;
typedef boost::shared_ptratsc_ds_to_softds atsc_ds_to_softds_sptr;
ALL compiles ok now ;))
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Generating chrip signals
On Wed, Apr 19, 2006 at 03:44:27AM -0700, seph 004 wrote: Hi At the moment I would like to see if I can generate a chirp signal. Looking through what gnuradio blocks are available, I assumed I could use the gr_fxpt_nco block to do something like this. I was wondering firstly if it would be possible, and secondly, how this block works and behaves when it's running. Regards Lance gr_fxpt_nco doesn't derive from gr_block. It's a low level primitive used within blocks. However, you could generate a chirp by feeding gr.frequency_modulator_fc (basically a VCO) a periodic ramp. You could generate a periodic ramp using gr.vector_source_f(foo, True) where foo was a python sequence that defines the ramp. You could of course also build a new block that derives from gr_sync_block. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc receiver error rate: 5.19e-05
I thought this was pretty good for last night's recording of Boston Legal: end of file, exiting 661 errors out of 12727848 mpeg packets. 12727187 good packets. Error rate = 5.19e-05 That's for a 450Kw xmtr 10 miles away receiving with a scanner antenna. What works so far is: recording an hour long program in 3 20-minute segments, making about 80Gb per segment. Then running gnuradio-0.9 on 3 cpu's (with fake mc4020's on another 3 cpu's) and by about 10AM the next day they're done. Then concatenate the 3 transport streams into 1 8Gb file, and running hdtv2dvd on it for 2 hours, and out pops one hour long 720x480 ntsc high quality dvd, all from thin air. Tonight's target video: Bones. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc receiver error rate: 5.19e-05
As a side note, if you want to keep the program in HD you can burn the MPEG program on a standard red-laser DVD and play them with this DVD player: http://pro.jvc.com/prof/attributes/press_res.jsp?model_id=MDL101546feature_id=08 You'll have to burn it as a DL disc, but 8 MB would fit. You can also encode it to WMV-HD or DiVX-HD to make the program much smaller. This is all kind of stop-gap until we get HD-DVD and/or Blu-Ray. But it is sweet to play HD content off a DVD. On Wed, 19 Apr 2006, Charles Swiger wrote: I thought this was pretty good for last night's recording of Boston Legal: end of file, exiting 661 errors out of 12727848 mpeg packets. 12727187 good packets. Error rate = 5.19e-05 That's for a 450Kw xmtr 10 miles away receiving with a scanner antenna. What works so far is: recording an hour long program in 3 20-minute segments, making about 80Gb per segment. Then running gnuradio-0.9 on 3 cpu's (with fake mc4020's on another 3 cpu's) and by about 10AM the next day they're done. Then concatenate the 3 transport streams into 1 8Gb file, and running hdtv2dvd on it for 2 hours, and out pops one hour long 720x480 ntsc high quality dvd, all from thin air. Tonight's target video: Bones. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc receiver error rate: 5.19e-05
On Wed, Apr 19, 2006 at 01:18:26PM -0400, Charles Swiger wrote: I thought this was pretty good for last night's recording of Boston Legal: end of file, exiting 661 errors out of 12727848 mpeg packets. 12727187 good packets. Error rate = 5.19e-05 That's for a 450Kw xmtr 10 miles away receiving with a scanner antenna. What works so far is: recording an hour long program in 3 20-minute segments, making about 80Gb per segment. Then running gnuradio-0.9 on 3 cpu's (with fake mc4020's on another 3 cpu's) and by about 10AM the next day they're done. Then concatenate the 3 transport streams into 1 8Gb file, and running hdtv2dvd on it for 2 hours, and out pops one hour long 720x480 ntsc high quality dvd, all from thin air. Tonight's target video: Bones. --Chuck Cool. It's too bad you have to downsample to 720x480 from 1920x1080 or whatever it was you started with. Maybe you need to install MythTV? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] work function - how it fits in the big picture
I'm stuck on how to loop over the data in calling a primitive
that does 12 segments at a time. What is it that calls the
work function and what sets the value of noutput_items?
If I completely ignore noutput_items and shovel in the code
from 0.9 :
for (int i = 0; i atsci_trellis_encoder::NCODERS; i +=
atsci_trellis_encoder::NCODERS){
d_trellis_encoder.encode(out[i], in[i]);
it compiles and runs but every NCODERS blocks there a bunch
of missing or corrupted data.
Anything else, like
for (int i = 0; i noutput_items; i +=
atsci_trellis_encoder::NCODERS){
d_trellis_encoder.encode(out[i], in[i]);
just segfaults ;) I think it needs to relate noutput_items
to NCODERS somehow that I don't understand.
Or, what code in gnuradio-core might shed some light on the
plumbing?
--Chuck
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] work function - how it fits in the big picture
Chuck - A variety of comments; someone please correct me if my
understanding is not correct. - MLD
1) The work() method is used by the gr_sync_block class as a
subcall from general_work(). The latter (general_work()) is
called by the scheduler (quoted from a previous email from Eric; see
gr_single_threaded_scheduler::main_loop() for the actual
scheduler code which does all the 'work' ... ha ha):
+
Part of the setup is in Python, the runtime part is in C++.
gnuradio-core/src/python/gnuradio/gr:
basic_flow_graph.py
flow_graph.py
scheduler.py
gnuradio-core/src/lib/runtime:
gr_single_threaded_scheduler.{h,cc} # the runtime scheduler
you'll also want to look at
gr_block.{h,cc} and gr_block_detail.{h,cc}
+
2) The scheduler calls each block's forecast() method repeatedly
starting with a large buffer size (e.g. 2^16) and dropping down by
powers of 2 nearest the block's output_multiple. The end result is
that each block's general_work() method is provided with a correct
output_multiple multiple of number of output items to create (i.e.
if the o_m is 10, then noutput_items = 10*X, where X is any non-
negative integer). The number is clearly dependent on the number of
input_items available for processing, as well as the forecast()
to create a reasonable number of output items given those input items
(really vice versa, but it's one way of looking at things).
3) The forecast() method is important (as per 2 above); make sure
it returns an accurate number of input items required for the
provided number of output items.
4) The return value for work() or general_work() is the number of
output items actually created, but no more than the input
noutput_items. Remember, these are -items- as defined by the
output_io_signature, not necessarily Bytes or whatever.
5) Instead of looping over atsci_trellis_encoder::NCODERS or the
number of output items, you should use the size of the input_items or
output_items (depending on how your computation works;e.g.
output_items.size()). These may or not be the same depending on
how your io_signatures are set. Looking at the code from 0.9,
maybe something like:
for (int i = 0; i output_items.size(); i++) {
d_trellis_encoder.encode (out[i], in[i]);
But what you do really depends on how the rest of the block is
configured.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] work function - how it fits in the big picture
On Wed, 2006-04-19 at 16:54 -0400, Michael Dickens wrote: Chuck - A variety of comments; someone please correct me if my understanding is not correct. - MLD 4) The return value for work() or general_work() is the number of output items actually created, but no more than the input noutput_items. Remember, these are -items- as defined by the output_io_signature, not necessarily Bytes or whatever. Ah [lightbulbs flash] - I'm blindly returning noutput_items but only processing NCODERS items, explains the missing data. This'll take a while. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: selective build of FPGA
found how to do it...just wanted to veryfy..created one more fileusrp_std_config_1rxhb_1tx.vh on the line of other files uncommented `define TX_SINGLE and`define RX_SINGLE..so this now includes 1 TX and 1 RX halfband On 4/19/06, amit malani [EMAIL PROTECTED] wrote: i wish to build just one rx_hb and one tx.present usrp_std.vh has 2rx 1tx or 4rxwhat do i need to do to...do i need to modify usrp_std.vh or are the dependancies are deep rooted.. thanks -- Amit MalaniMaster of Science (Information Networking)Carnegie Mellon Universitymobile: 001 516 209 1358 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] work function - how it fits in the big picture
On Wed, Apr 19, 2006 at 05:50:38PM -0400, Charles Swiger wrote: On Wed, 2006-04-19 at 16:54 -0400, Michael Dickens wrote: Chuck - A variety of comments; someone please correct me if my understanding is not correct. - MLD 4) The return value for work() or general_work() is the number of output items actually created, but no more than the input noutput_items. Remember, these are -items- as defined by the output_io_signature, not necessarily Bytes or whatever. Ah [lightbulbs flash] - I'm blindly returning noutput_items but only processing NCODERS items, explains the missing data. This'll take a while. --Chuck Chuck, To make the new code match the behavior of GrAtscTrellisEncoder (which is what I think you're up to) you'll need to derive from gr_sync_block and add this to your constructor: set_output_multiple(atsci_trellis_encoder::NCODERS); If you're explicitly calling set_history, remove that. I'd try it with the standard forecast method first. If that doesn't work you may have to modify it such that it returns NCODERS + the regular answer. Normally we'd just call set_history(atsci_trellis_encoder::NCODERS), but that would have the side-effect of the first 12-segments we saw being binary zero, which means it wouldn't have the pipeline info fields initalized properly. Hope this helps. The code is a bit odd because it must maintain the 12-segment alignment, even in the face of errors upstream (which I don't think can happen). I also suggest adding the paranoid check that's at the bottom of GrAtscTrellisEncoder if you haven't already. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: selective build of FPGA
On Wed, Apr 19, 2006 at 06:30:03PM -0400, amit malani wrote: found how to do it... just wanted to veryfy.. created one more file usrp_std_config_1rxhb_1tx.vh on the line of other files uncommented `define TX_SINGLE and `define RX_SINGLE.. so this now includes 1 TX and 1 RX halfband On 4/19/06, amit malani [EMAIL PROTECTED] wrote: i wish to build just one rx_hb and one tx. present usrp_std.vh has 2rx 1tx or 4rx what do i need to do to... do i need to modify usrp_std.vh or are the dependancies are deep rooted.. thanks Amit, you're on the right path. However, I don't think that the existing tx code honors the defines defined as f(TX_SINGLE), so there may still be a bit of work to do. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC changes
The ATSC has published revisions of several key standards--including A/52, the Digital Audio Compression Standard (AC-3); A/53, the Digital Television Standard; and A/110, the Synchronization Standard for Distributed Transmission. New versions of all three documents were approved by the ATSC membership this summer and are now available on the ATSC Web site. http://www.tvtechnology.com/features/atsc/f_jerry_whitaker.shtml ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Embedded PCs for GNU Radio
This company has some interesting embedded Pentium-M machines -- fanless, 10W, USB 2.0 http://www.advantech.com/ Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
