[Discuss-gnuradio] So long, and thanks for the fish
Hi everyone, its time for me to say goodbye. I started working in the embedded area a few month ago, and have lost track of gnuradio efforts since. Maybe I will be back one day, as SDRs and signal processing in general are still one of my favourite topics. Good luck to everyone, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory allocation woes
This is just an educated guess, so anyone, please correct me if I am wrong: GR tries to hide the fact that even for a ringbuffer, memory space is always linear. Now lets assume you try to do an fft with overlap, with an fft size as large as your buffer. The first time, you memory area might be at the beginning of the buffer. The next time, it is shifted somewhat into the buffer, therefor the last part of your buffer is actually at the beginning of the buffer. To get a linear (with monotonically increasing adresses) buffer, the physical memory pages backing your buffer are mapped into virtual memory space twice, where the second mapping directly follows the first. Physical memory usage is equal to buffer size, whereas virtual memory space uses twice as much memory. So for current applications on todays computer it is really easy to run out of virtual memory space. If your demands are really so high, why aren't you using a 64bit machine. On top of the larger memory space, you get more registers and guranteed existence of SSE (only an issue, if you use prebuilt packages). The last time I used GR, it worked fine on 64bit. Stefan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Altera Quartus II for linux free web edition finally available
On Wednesday 11 November 2009 19:47:26 Martin DvH wrote: With the release of Quartus II 9.1 on 2 november 2009 Altera has finally decided to make a free Linux Web edition available. One down, one to go (Nokia Firmware Updater). Great News! Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB latency problem
On Sunday 20 September 2009 22:45:08 Newman, Timothy wrote: It totally depends on where you implement the latency sensitive components. I believe the best USB can do is a minimum of 100us, and that probably the theoretical minimum. If you need 80-120 us latency, you will definitely need to move the latency sensitive components to the FPGA. The best you can do with USB is 150-200us, if you use really small USB transfers (~16bytes), and 250-400 if you use the default block size of 512 bytes. For small transfers, latency is dominated by IRQ coalescing - there is just one interrupt per microframe, resulting in a variable delay of 0-125us [1]. For larger transfers, the time needed for filling a USB packet (128 samples/sample_rate) and transferring it ( (55+512byte) /60MByte/s) contributes to latency significantly. Reducing the packet size to 128 bytes hardly influences the achievable USB transfer rate (~40MB/s, [2]), but lowers the theoretical latency signicantly, although it will cause higher processing overhead on the host. As far as I know, there is no possibility to disable irq coalescing. Stefan [1] see Intel EHCI specification [2] USB 2.0 spec, Table 5-10 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RTOS and GNU Radio
On Thursday 13 August 2009 20:09:55 Jane Chen wrote: Hi all, Eric, thank you for your reply. I ran the tunnel.py with the username useSDR in group usrp and added @usrp - rtprio 50 in the /etc/security/limits.conf. gr.enable_realtime_scheduling() is in the orignial tunnel.py file. However, I keep get an error as following: File tunnel_original.py, line 78, in open_tun_interface tun = os.open(tun_device_filename, os.O_RDWR) OSError: [Errno 13] Permission denied: '/dev/net/tun' This error is unrelated to the first one. You dont have permission to create a tun device. Recommended proceeding: 1. install tunctl 2. sudo chmod 666 /dev/net/tun 3. sudo tunctl -u useSDR -n steps 2 and 3 have to be repeated after restarting the computer. This way, you dont have to run tunnel.py as root. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading from USRP
On Sunday 12 July 2009 08:09:24 Timur Alperovich wrote: Hey guys, I've been trying to read from the USRP by simply doing u-read(buf, 512, overrun). I used the usrp_inband_usb_packet class to extract the payload size and the payload from each USB packet received. As I understand, the USB packets contain pairs of I and Q for each (I didn't change the format from the default). I was expecting the payload size then to be a multiple of 4, since it is 2 shorts. I frequently see payload sizes such as 7, 13, etc. What is going on here? Are there examples of getting the data from a dbsrx using this method and processing it? I found the test_standard_rx example, but it doesn't do any processing and just reads. If you want to use the inband code, of course you have to use the inband firmware as well. Most probably, you use the standard firmware, and the payload size you see is a normal sample. USB packets produced by the standard firmware always contain 512 bytes/128 complex samples (as long as you stick to standard sample resolution of 16 bit per component). The inband firmware will produce packets containing 504 bytes of payload (126 samples), and it will accept shorter packets. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP with USB/IP
On Saturday 06 June 2009 00:23:54 Alberto Trentadue wrote: On Fri, 2009-06-05 at 12:14 -0700, Firas Abbas wrote: Hi, --- On Fri, 6/5/09, Patrick Strasser patrick. stras...@tugraz.at wrote: Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. Patrick From the web site the transfer rate of these boxes is 10/100Mb/s. So theoretically it should transfer a maximum of 12.5MByte/sec which is far below the required 32Mbyte/sec of USRP1. Hello Firas. Just for my understanding: The 32Mbyte/s requirement is for a full speed - 4 channel USRP operation. But if we suppose a simpler application, e.g. 1 TX/RX channel only, wouldn't this fit in the USB/IP? This still on the decimation/interpolation rate. Each complex sample is 4 byte. Theoretically 100MBit Ethernet could sustain 3 MSample/s, so the decimation rate has to be 22 or higher (most probably substantially higher, as there is some overhead by the TCP(UDP?)/IP headers, but 32 (2MSample) should be fine). As Ethernet is full duplex, this is the number of samples/s that can be sustained per direction, in constrast to USB, where the bandwidth is shared. This will for sure add some latency, you will have to figure this out by yourself. Bottom Line: 1TX/1RX, 2 MSample/s, complex samples should be possible. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 firmware
On Wednesday 06 May 2009 18:35:36 Dominik Auras wrote: Do you have, maybe, an idea why TX bandwidth is limited? Interestingly enough, 32.7 Mb/s is the limit on my computer and my notebook. Of course, I made the tx loop on the host as short as possible, set SCHED_FIFO and rtprio to 49, and played with fusb_nblock/size etc. Are you transmitting random data, or a stream of zeros? In the latter case (IIRC), every 6 zeros will have a single 1 added to aid clock recovery, limiting net bandwidth to 6/7 (which is about 42MByte). Try transmitting random data, a stream of ones should be fine to. For detail have a look at the USB spec. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing gnuradio on Opensuse
On Thursday 30 April 2009 17:04:53 garretaj wrote: sorted it now. There are no .so files in lib64, only .a files - recreated the symbolic links and all was merry. This is somewhat contradictory to what you wrote first - did the symbolic links exist in the first place, and were they pointing to the right file? What is the result of rpm -qif /usr/lib64/libgsl.so and rpm -qif /usr/lib64/libgsl.a ? [...] You my now run the make command to build these components. I get the following error message: g++: /usr/lib64/libgsl.so: No such file or directory g++: /usr/lib64/libgslcblas.so: No such file or directory make[5]: *** [libgnuradio-core.la] Error 1 I have located the files in question, and they're in the right directories, with the right permissions Can anyone shed any light?? Many thanks Andrew Garrett -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wx openGL sinks and segmentation faults
Hi, I have noticed that I always get a segmentation fault if I use the openGL versions of the sinks. This seems to be dependent on the graphics chipset, I have two computers both with Intel G965. The segfault can be avoided with LIBGL_ALWAYS_INDIRECT=1, eg, $ LIBGL_ALWAYS_INDIRECT=1 usrp_oscope.py Although this slows things down a little bit, it should still be faster than pure software rendering. I would be interested in reports from other people, especially which chipsets/drivers segfault and which dont. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High CPU load when sending waveform from file to USRP2
On Friday 03 April 2009 18:00:03 Jakob Meineke wrote: When I do not enable realtime scheduling in the script the CPU load seems to increase even more and the signal is never nice. The sampling rate is 10e8/4, where 4 is the interpolation set in siggen.py. Using an interpolation of 8 seems to alleviate the problem but I need the bandwidth. I installed the realtime kernel which did not change a thing. so you try to read a 25MS/s signal from disk? Assuming you use complex floats, this is 8*25MB/s = 200MB/s. Even using complex short is 100MB/s. Most probably your CPU is not working, but waiting - you can use top to see whats going on (us: user process, sy: kernel workload, wa: waiting) Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sora
On Wednesday 25 March 2009 23:53:47 Johnathan Corgan wrote: 2009/3/25 Newell Jensen pillar2...@gmail.com: Yeah, let me know what you guys think about this if anyone wants to make a comment. Just a *very* brief glance at it showed at least one mistake in their comments about GNU Radio; I'll give it a more thorough read when I get a chance. Johnathan The most interesting part is IMHO the hardware. The comments on GNU Radio are misinformed (they are not able to differentiate between USRP and GNU Radio ...), and using SIMD for software radio, well, I think I have seen that before somewhere else ... ;-) Nevertheless, they have achieved quite something when implementing 802.11 on the host ... Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gardner's Algo Block for Symbol Timing
On Tuesday 24 March 2009 20:58:39 Sajjad Sarwar wrote: Hi, I am doing my final year UG project of implementing a packet radio in SDR. I want to use Garner's algo for symbol timing recovery but i couldn't find any block of it in gnuradio. Is there any such block? if not, then what's the solution? cz I am not good at writing own signal processing block and I am short of time too. There is an implementation for MuellersMüllers (MM/MM) symbol timing recovery algorithm. You can find it either in the mpsk_receiver_cc block (in combination with costas carrier synchronization), or as a standalone block Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Octave script for plotting CIC+HBF transfer functions
Hi, as the Matlab script created by Firas needs the Filter toolbox, I have created an equivalent script for Octave. Two differences: It uses only 'freqz' for the computation of the transfer functions For the baseband, also the images due to aliasing is plotted I think, the second point gives some valuable information. Part of the first sidelobe of the CIC filter falls into the passband of the HBF, so it is quite strong (only ~50dB attenuation). The new plot strengthens this. Plots and script is available here: http://www.kawo1.rwth-aachen.de/~lurchi/gnuradio/ Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Input Calibration / CIC Filter Response
On Thursday 19 March 2009 22:43:56 Erich Stuntebeck wrote: Hi, I'm trying to calibrate the USRP so I can get true dBm readings out of it. I'm using an LFRX card with 16 decimation and a center frequency of 2 MHz so I can look at the range from DC - 4 MHz. I hooked up a signal generator and swept it through the DC - 4 MHz range at 100 kHz intervals and generated the plot here: http://ice.cc.gt.atl.ga.us/usrp_adc_response.jpg The signal generator produced a -36 dBm signal for each frequency, and the y-axis of this plot is the output of the USRP's ADC in dB. (20 * log10 of the appropriate FFT bin for the frequency of interest, using an 8192 point FFT). My question is what is causing the particular shape of this response. I'm guessing it has to do with the CIC filter, but I can't seem to reconcile my output with the plots from this post on the CIC filter's response: I think there are two parts - dampening at 0 and 4 MHz: This is most probably the typical CIC shape, [sin(x)/x]^4 (four CIC stages) - 500kHz Ripple: this is most probably an artifact due to how you generate the response. There might be a small frequency offset between the USRP and your signal generator. The USRP oscillator is specified to be 64MHz +/- x ppm (parts per million, x either 20 or 50 depending on USRP revision). If you take the power just from a single bin, you may use the wrong bin. One possibility would be to take several bins around the correct bin and sum up the powers of these bins. Actually, you dont need the fft at all, you can just calculate the power of the incoming signal in the time domain. A somewhat related question: which firmware are you using - with or without halfband filter? Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The effect of FUSB_BLOCK_SIZE and FUSB_NBLOCKS
On Wednesday 04 March 2009 05:40:36 Yong J. Chang wrote: Hi all, Now I'm working on measuring Round Trip Time ( FPGA(RXFIFO)-USB-PC-USB-FPGA(TXFIFO) ). Since I'm using 128kbps bitrate and 10 samples per symbol, sample rate is 1.28Msps. And I do not give any options about FUSB_BLOCK_SIZE and FUSB_NBLOCKS. So they might be 0. In this case, the result is following: 0 means default. Excerpt from fusb_linux.cc: --- static const int MAX_BLOCK_SIZE = fusb_sysconfig::max_block_size(); static const int DEFAULT_BLOCK_SIZE = MAX_BLOCK_SIZE; static const int DEFAULT_BUFFER_SIZE = 4 * (1L 20); if (d_block_size == 0) d_block_size = DEFAULT_BLOCK_SIZE; if (d_nblocks == 0) d_nblocks = std::max (1, DEFAULT_BUFFER_SIZE / d_block_size); --- max_block_size() is 16kB Minimum RTT : 1.96ms Maximum RTT : 5.12ms As Thomas Schmid's paper, this result is so reasonable. However, if I use FUSB_BLOCK_SIZE=2048 and FUSB_NBLOCKS=8 such like paper mentioned, it starts to be messed up. RTT becomes larger and variation is also broaden. Also it gives me lots of overrun message. I have no problem running with a block size of 512, but it is important to run with SCHED_FIFO (you have to be root or need appropriate settings in /etc/security/limits.conf, this has been discussed a few days ago on this ML). What is the effect of these two parameters? As I know, in USB bulk transfer mode the USB packet size is fixed as 512 bytes. So these two parameters will determine the packet size transfered between Linux kernel and user space. It does not affect physical USB transaction. Am I correct? If yes, why does it make overrun error? As you can see above, with default values the in-kernel buffer is much larger (from my experiments it is mostly irrelevant how large the URBs -- USB request block, the size you set with FUSB_BLOCK_SIZE -- are, the total buffer size is much more critical). The size of the URB determines how often you get notified from the kernel. Another factor is the number of interrupts generated by the USB host controller, this is limited to one interrupt per microframe (125us). Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Details on USB buffer
On Friday 27 February 2009 01:05:52 Tony wrote: The USRP C++ example program uses this code to move USRP USB data into a buffer: urx-read(buf, bufsize, overrun); If this line is called many times in a short period of time will the buffer have some of the data leftover from previous read(s)? Can I assume that the OS will not return the buffer until the next n bytes have been received? Tony The read is a blocking read. The return value is the number of bytes actually read, which will always be the same as bufsize or an error value (0). Samples may be thrown away in the USRP itself this is called an overrun, in this case the corresponding variable will be set to true. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/frees
On Tuesday 24 February 2009 16:03:05 Marcus D. Leech wrote: Have you tested receive performance, and is it improved? Hm, if you are going for high bandwidth, you should set the blocksize quite high (eg 4096). I am targetting low latency, so I go for the smallest possible blocksize (512). If you are receiving with 32MB/s, the new code saves about 75e6 instructions per second at a blocksize of 512, so for 4096 this should be about 9e6. For a current generation cpu, this should be about 1% of its throughput, on the other hand, the mallocs are most probably very unfriendly to branch prediction and cache access, so savings may be higher. If I find some time, I will run oprofile to get some numbers ... Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fixed FPGA inband firmware
Hi,
attached is a somewhat larger patch for the FPGA firmware.
The patch changes the following:
- stable timestamp, timestamp is latched on the last sample that goes into the
packet, so in case no overrun happens, timestamp goes up reliably 126 times
decimation rate.
- channel buffer is emptied when an overrun happens, avoids multiple overruns
in short succession
- tx timestamp wrap around, range is divided into 2^31 past and 2^31 future
timestamps.
- dropped flag is set
- overrun flag is set
- tag is set to the tag of the last sent package
- rssi value is transmitted in a logarithmic representation
- waiting on fifos is shortened based on the fact that these get filled and
emptied at a fixed rate. If the reader is faster than the writer, than the
fifo should reach zero level when the reader finishes.
The patches have successfully been tested with 1tx1rx on usrp rev4. Loopback
works, overrun and underrun reporting works, drops are reported as well.
Regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
=== modified file 'usrp/fpga/inband_lib/chan_fifo_reader.v'
--- usrp/fpga/inband_lib/chan_fifo_reader.v 2008-04-30 02:52:31 +
+++ usrp/fpga/inband_lib/chan_fifo_reader.v 2009-02-24 21:01:19 +
@@ -1,7 +1,7 @@
module chan_fifo_reader
(reset, tx_clock, tx_strobe, timestamp_clock, samples_format,
fifodata, pkt_waiting, rdreq, skip, tx_q, tx_i,
-underrun, tx_empty, debug, rssi, threshhold, rssi_wait) ;
+underrun, tx_empty, debug, rssi, threshhold, rssi_wait, drop, tagline) ;
input wire reset ;
input wire tx_clock ;
@@ -19,6 +19,8 @@
input wire [31:0] rssi;
input wire [31:0] threshhold;
input wire [31:0] rssi_wait;
+ output reg drop;
+ output reg[3:0] tagline;
output wire [14:0] debug;
assign debug = {7'd0, rdreq, skip, reader_state, pkt_waiting, tx_strobe, tx_clock};
@@ -37,6 +39,7 @@
// Header format
`define PAYLOAD 8:2
+ `define TAG 12:9
`define ENDOFBURST 27
`define STARTOFBURST 28
`define RSSI_FLAG26
@@ -52,6 +55,8 @@
reg trash;
reg rssi_flag;
reg [31:0] time_wait;
+ reg [32:0] time_to_wait;
+ reg[3:0] tag_save;
always @(posedge tx_clock)
begin
@@ -68,6 +73,8 @@
trash = 0;
rssi_flag = 0;
time_wait = 0;
+ time_to_wait = 0;
+ drop = 0;
end
else
begin
@@ -86,10 +93,10 @@
begin
reader_state = HEADER;
rdreq = 1;
- underrun = 0;
end
+
if (burst == 1 pkt_waiting == 0)
- underrun = 1;
+ underrun = ~underrun;
if (tx_strobe == 1)
tx_empty = 1 ;
end
@@ -102,10 +109,7 @@
rssi_flag = fifodata[`RSSI_FLAG]fifodata[`STARTOFBURST];
//Check Start/End burst flag
- if (fifodata[`STARTOFBURST] == 1
-fifodata[`ENDOFBURST] == 1)
- burst = 0;
- else if (fifodata[`STARTOFBURST] == 1)
+ if (fifodata[`STARTOFBURST] == 1 fifodata[`ENDOFBURST] == 0)
burst = 1;
else if (fifodata[`ENDOFBURST] == 1)
burst = 0;
@@ -115,19 +119,27 @@
skip = 1;
reader_state = IDLE;
rdreq = 0;
+ burst = 0;
end
else
begin
payload_len = fifodata[`PAYLOAD] ;
+ tag_save = fifodata[`TAG];
read_len = 0;
rdreq = 1;
- reader_state = TIMESTAMP;
+ if( fifodata[`STARTOFBURST] == 0)
+ begin
+ reader_state = WAIT;
+ timestamp = 32'h;
+ end else
+ reader_state = TIMESTAMP;
end
end
TIMESTAMP:
begin
timestamp = fifodata;
+ time_to_wait = ({1'b1, fifodata} - {1'b0, timestamp_clock});
reader_state = WAIT;
if (tx_strobe == 1)
tx_empty = 1 ;
@@ -137,32 +149,31 @@
// Decide if we wait, send or discard samples
WAIT:
begin
+
[Discuss-gnuradio] New implementation for fusb_linux without allocs/frees
Hi,
attached is a new version for fusb_linux.cc.
The current implementation uses three std::list lists for free, pending and
completed urbs, so submitting a single urb causes three allocs and three frees
(pushing and popping of the list).
The new implementation uses a circular list for the urbs, where each urb is
marked as free, pending or completed. As the total number of allocated urbs is
constant, no allocs or frees are needed.
Benchmark:
usrp/host/apps/test_usrp_standard_tx -B 512 -N 64 -M 128
old code needs ~990e6 instructions, new code 690e6 instructions. The call to
usrp_basic_tx::write goes down from 380e6 to 80e6 (so almost down to a fifth
...), the remaining instructions is the pattern fill for the sample buffer.
Regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
/* -*- c++ -*- */
/*
* Copyright 2003 Free Software Foundation, Inc.
*
* This file is part of GNU Radio
*
* GNU Radio is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3, or (at your option)
* any later version.
*
* GNU Radio is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with GNU Radio; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street,
* Boston, MA 02110-1301, USA.
*/
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include fusb_linux_2.h
#include usb.h // libusb header
#include stdexcept
#ifdef HAVE_LINUX_COMPILER_H
#include linux/compiler.h
#endif
#include linux/usbdevice_fs.h // interface to kernel portion of user mode usb driver
#include sys/ioctl.h
#include assert.h
#include string.h
#include algorithm
#include errno.h
#include string.h
#include iostream
#define MINIMIZE_TX_BUFFERING 1 // must be defined to 0 or 1
static const int MAX_BLOCK_SIZE = fusb_sysconfig::max_block_size(); // hard limit
static const int DEFAULT_BLOCK_SIZE = MAX_BLOCK_SIZE;
static const int DEFAULT_BUFFER_SIZE = 4 * (1L 20);// 4 MB / endpoint
enum urb_state_t { FREE, PENDING, COMPLETED };
struct _urb_private_data {
fusb_ephandle_linux* handle;
enum urb_state_t state;
// int count readers;
};
// Totally evil and fragile extraction of file descriptor from
// guts of libusb. They don't install usbi.h, which is what we'd need
// to do this nicely.
//
// FIXME if everything breaks someday in the future, look here...
static int
fd_from_usb_dev_handle (usb_dev_handle *udh)
{
return *((int *) udh);
}
inline static void
urb_set_ephandle (usbdevfs_urb *urb, fusb_ephandle_linux *handle)
{
((_urb_private_data*)(urb-usercontext))-handle = handle;
}
inline static fusb_ephandle_linux *
urb_get_ephandle (usbdevfs_urb *urb)
{
return ((_urb_private_data*)(urb-usercontext))-handle;
}
//
// USB request block (urb) allocation
//
static usbdevfs_urb *
alloc_urb (fusb_ephandle_linux *self, int buffer_length, int endpoint,
bool input_p, unsigned char *write_buffer)
{
usbdevfs_urb *urb = new usbdevfs_urb;
memset (urb, 0, sizeof (*urb));
urb-buffer_length = buffer_length;
// We allocate dedicated memory only for input buffers.
// For output buffers we reuse the same buffer (the kernel
// copies the data at submital time)
if (input_p)
urb-buffer = new unsigned char [buffer_length];
else
urb-buffer = write_buffer;
// init common values
urb-type = USBDEVFS_URB_TYPE_BULK;
urb-endpoint = (endpoint 0x7f) | (input_p ? 0x80 : 0);
// USBDEVFS_URB_QUEUE_BULK goes away in linux 2.5, but is needed if
// we are using a 2.4 usb-uhci host controller driver. This is
// unlikely since we're almost always going to be plugged into a
// high speed host controller (ehci)
#if 0 defined (USBDEVFS_URB_QUEUE_BULK)
urb-flags = USBDEVFS_URB_QUEUE_BULK;
#endif
urb-signr = 0;
urb-usercontext = new _urb_private_data;
((_urb_private_data*)urb-usercontext)-state=FREE;
urb_set_ephandle (urb, self);
return urb;
}
static void
free_urb (usbdevfs_urb *urb)
{
// if this was an input urb, free the buffer
if (urb-endpoint 0x80)
delete [] ((unsigned char *) urb-buffer);
delete (_urb_private_data*)(urb-usercontext);
delete urb;
}
//
// device handle
//
fusb_devhandle_linux::fusb_devhandle_linux (usb_dev_handle *udh)
: fusb_devhandle (udh)
{
// that's all
}
Re: [Discuss-gnuradio] Re: is there a sdcc option for configure
On Wednesday 04 February 2009 21:05:49 feldmaus wrote: Eric Blossom eb at comsec.com writes: Why don't you just install it using whatever package manager your system uses? apt-get or yum or whatever... There are dependency Problems with the sdcc Package under Suse. I hope the developer of this package read this. You may also hope some gold nugget falls directly in front of your feet. Which is as likely ... There are 2 packages, the sdcc-common and the sdcc-devel which are the same.One is older and the other is newer but mostly not available. Some repository from suse supports a new sdcc package but need the sdcc-common, which is not supported by any repository from suse. And there are some older sdcc packages which depends on the older package sdcc-devel. The older package do problems by the dependency. I hope a Developer of this package had read this. Regards Markus As my crystal ball is in repair at the moment, I only may make an educated guess ... In the whole opensuse buildservice is no package called sdcc-common, although there is a broken package in home:illuusio, which depends on sdcc- common. You can find the packagers contact information either in the package changelog, or following the link to the OBS on software.opensuse.org/search . Meanwhile, you can just use sdcc 2.7.0 from the OBS hamradio project, which works. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: checking for boost = 1.35... no
On Saturday 31 January 2009 15:20:58 feldmaus wrote: I installed the Package gcc-c++ and solve this Problem, but no i am getting this: checking whether the boost::thread includes are available... yes configure: error: Could not link against libboost_thread! I am using the boost packages of the standard openSUSE 11.1 repository, so in general, it should work. These are the packages I have installed from boost (according to zypper se -i boost): S | Name | Summary | Type --++-+ i | boost-devel| Development package for Boost C++ | package i | boost-license | Boost License | package i | libboost_date_time1_36_0 | Boost::Date.Time Runtime libraries | package i | libboost_filesystem1_36_0 | Boost::Filesystem Runtime Libraries | package i | libboost_graph1_36_0 | Boost::Graph Runtime Libraries | package i | libboost_iostreams1_36_0 | Boost::IOStreams Runtime Libraries | package i | libboost_math1_36_0| Boost::Math Runtime Libraries | package i | libboost_mpi1_36_0 | Boost::MPI Runtime libraries| package i | libboost_program_options1_36_0 | Boost::ProgramOptions Runtime libraries | package i | libboost_python1_36_0 | Boost::Python Runtime Libraries | package i | libboost_regex1_36_0 | The Boost::Regex runtime library| package i | libboost_serialization1_36_0 | Boost::Serialization Runtime Libraries | package i | libboost_signals1_36_0 | Boost::Signals Runtime Libraries| package i | libboost_system1_36_0 | Boost::System Runtime Libraries | package i | libboost_test1_36_0| Boost::Test Runtime Libraries | package i | libboost_thread1_36_0 | Boost::Thread Runtime Libraries | package i | libboost_wave1_36_0| Boost::Wave Runtime Libraries | package Have you installed libboost_thread1_36_0 (shoud be a dependency of boost-devel, anyway, so most probably, yes). To get some more info from configure, have a look into config.log, search for boost::thread. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Small cleanups for inband code
One more: This time, some changes for the uniform vectors (uv) of pmt. Rationale: std::vector always initializes memory. First, for the uvs, uninitialized may be fine for many cases, otherwise, initialization should be requested explicitly. Second, even for scalar types, initialization is expensive, as memset is only used for byte sized types, otherwise a for loop is used (even when setting to 0). This patch introduces a small helper class which substitutes std::vector for the uniform vectors. This patch has no influence on ABI/API. It saves about 20% of cycles for test_usrp_inband_tx. (Savings for *_rx are much smaller, as it only uses uv_u8, not uv_s16, but still significant) Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Small cleanups for inband code
On Wednesday 28 January 2009 21:40:35 Stefan Bruens wrote:
sorry, forgot to attach something ...
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
=== added file 'pmt/src/lib/simplevector.hpp'
--- pmt/src/lib/simplevector.hpp 1970-01-01 00:00:00 +
+++ pmt/src/lib/simplevector.hpp 2009-01-28 18:37:52 +
@@ -0,0 +1,68 @@
+#ifndef __SIMPLE_VECTOR__
+#define __SIMPLE_VECTOR__
+
+#include string.h
+#include complex
+
+template typename T
+class simplevector
+{
+public:
+ simplevector() : start(0), end(0) {};
+ simplevector(const size_t size) { start = new T[size]; end=start+size; }
+ simplevector(const size_t size, const T fill);
+ ~simplevector() { delete[] start; }
+
+ size_t size() const { return end-start; }
+ T at(const size_t k) const;
+ T operator[](const size_t k) const { return *(start+k); }
+
+protected:
+ T* start;
+ T* end;
+};
+
+template
+inline simplevectorstd::complexdouble ::simplevector(const size_t size, const std::complexdouble fill)
+{
+ start = new std::complexdouble[size];
+ end=start+size;
+ for(size_t i = 0; i size; ++i) start[i] = fill;
+}
+
+template
+inline simplevectorstd::complexfloat ::simplevector(const size_t size, const std::complexfloat fill)
+{
+ start = new std::complexfloat[size];
+ end=start+size;
+ for(size_t i = 0; i size; ++i) start[i] = fill;
+}
+
+template
+inline simplevectorchar::simplevector(const size_t size, const char fill)
+{
+ start = new char[size];
+ end=start+size;
+ memset(start, fill, size*sizeof(char));
+}
+
+template typename T
+simplevectorT::simplevector(const size_t size, const T fill)
+{
+ start = new T[size];
+ end=start+size;
+ if(fill == 0) { memset(start, 0, size*sizeof(T));}
+ else {
+ for(size_t i = 0; i size; ++i) start[i] = fill;
+ }
+}
+
+template typename T
+T
+simplevectorT::at(const size_t k) const
+{
+ assert(start+k end);
+ return *(start+k);
+}
+
+#endif // __SIMPLE_VECTOR__
=== modified file 'pmt/src/lib/unv_template.cc.t'
--- pmt/src/lib/unv_template.cc.t 2008-06-26 17:17:15 +
+++ pmt/src/lib/unv_template.cc.t 2009-01-28 18:37:52 +
@@ -9,12 +9,13 @@
}
+p...@tag@vector::p...@tag@vector(size_t k)
+ : d_v(k)
+{ }
+
p...@tag@vector::p...@tag@vector(size_t k, @TYPE@ fill)
- : d_v(k)
-{
- for (size_t i = 0; i k; i++)
-d_v[i] = fill;
-}
+ : d_v(k, fill)
+{ }
p...@tag@vector::p...@tag@vector(size_t k, const @TYPE@ *data)
: d_v(k)
=== modified file 'pmt/src/lib/unv_template.h.t'
--- pmt/src/lib/unv_template.h.t 2008-06-26 17:17:15 +
+++ pmt/src/lib/unv_template.h.t 2009-01-28 18:37:52 +
@@ -5,9 +5,11 @@
class p...@tag@vector : public pmt_uniform_vector
{
- std::vector @TYPE@ d_v;
+ // std::vector @TYPE@ d_v;
+ simplevector @TYPE@ d_v;
public:
+ p...@tag@vector(size_t k);
p...@tag@vector(size_t k, @TYPE@ fill);
p...@tag@vector(size_t k, const @TYPE@ *data);
// ~p...@tag@vector();
=== modified file 'pmt/src/lib/generate_unv.py'
--- pmt/src/lib/generate_unv.py 2007-07-21 02:44:38 +
+++ pmt/src/lib/generate_unv.py 2009-01-28 20:58:05 +
@@ -80,6 +80,11 @@
+h_includes =
+#include simplevector.hpp
+
+
+
qa_includes =
#include qa_pmt_unv.h
#include cppunit/TestAssert.h
@@ -128,6 +133,7 @@
output_filename = 'pmt_unv_int.h'
output = open(output_filename, 'w')
output.write(header)
+output.write(h_includes)
output.write(guard_head(output_filename))
for tag, typ in unv_types:
d = { 'TAG' : tag, 'TYPE' : typ }
signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Small cleanups for inband code
Hi again,
some more improvements, this time for the tx part only. This patch saves about
10% CPU for the test_usrp_inband_tx example.
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
=== modified file 'usrp/host/lib/inband/symbols_usrp_rx_cs.h'
--- usrp/host/lib/inband/symbols_usrp_rx_cs.h 2007-09-05 00:43:43 +
+++ usrp/host/lib/inband/symbols_usrp_rx_cs.h 2009-01-26 01:54:15 +
@@ -25,6 +25,7 @@
// Outgoing
static pmt_t s_cmd_usrp_rx_start_reading = pmt_intern(cmd-usrp-rx-start-reading);
+static pmt_t s_cmd_usrp_rx_handle = pmt_intern(cmd-usrp-rx-handle);
// Incoming
static pmt_t s_response_usrp_rx_read = pmt_intern(response-usrp-rx-read);
=== modified file 'usrp/host/lib/inband/symbols_usrp_tx_cs.h'
--- usrp/host/lib/inband/symbols_usrp_tx_cs.h 2007-09-05 00:43:43 +
+++ usrp/host/lib/inband/symbols_usrp_tx_cs.h 2009-01-26 01:54:15 +
@@ -25,6 +25,7 @@
// Outgoing
static pmt_t s_cmd_usrp_tx_write = pmt_intern(cmd-usrp-tx-write);
+static pmt_t s_cmd_usrp_tx_handle = pmt_intern(cmd-usrp-tx-handle);
// Incoming
static pmt_t s_response_usrp_tx_write = pmt_intern(response-usrp-tx-write);
=== modified file 'usrp/host/lib/inband/usrp_rx.cc'
--- usrp/host/lib/inband/usrp_rx.cc 2009-01-12 21:31:44 +
+++ usrp/host/lib/inband/usrp_rx.cc 2009-01-26 01:54:15 +
@@ -93,6 +93,8 @@
if(pmt_eqv(event, s_cmd_usrp_rx_start_reading))
read_and_respond(data);
+if(pmt_eqv(event, s_cmd_usrp_rx_handle))
+ d_urx = boost::any_castusrp_standard_rx_sptr(pmt_any_ref(data));
}
}
@@ -115,13 +117,12 @@
unsigned int n_read;
unsigned int pkt_size = sizeof(transport_pkt);
- pmt_t invocation_handle = pmt_nth(0, data);
-
- // Need the handle to the RX port to send responses, this is passed
- // by the USRP interface m-block
- pmt_t handle = pmt_nth(1, data);
- d_urx =
-boost::any_castusrp_standard_rx_sptr(pmt_any_ref(handle));
+ if(!d_urx) {
+ std::cerr [usrp_rx] USRP RX Handle not set, shutting down\n;
+ d_cs-send(s_response_usrp_rx_read,
+ pmt_list3(PMT_NIL, PMT_F, PMT_NIL));
+ return;
+ }
if(verbose)
std::cout [usrp_rx] Waiting for packets..\n;
=== modified file 'usrp/host/lib/inband/usrp_tx.cc'
--- usrp/host/lib/inband/usrp_tx.cc 2009-01-26 01:06:02 +
+++ usrp/host/lib/inband/usrp_tx.cc 2009-01-26 01:54:15 +
@@ -83,6 +83,8 @@
if(pmt_eqv(event, s_cmd_usrp_tx_write))
write(data);
+if(pmt_eqv(event, s_cmd_usrp_tx_handle))
+ d_utx = boost::any_castusrp_standard_tx_sptr(pmt_any_ref(data));
}
}
@@ -100,7 +102,13 @@
pmt_t invocation_handle = pmt_nth(0, data);
pmt_t channel = pmt_nth(1, data);
pmt_t v_packets = pmt_nth(2, data);
- d_utx = boost::any_castusrp_standard_tx_sptr(pmt_any_ref(pmt_nth(3, data)));
+
+ if(!d_utx) {
+ std::cerr [usrp_tx] USRP TX Handle not set, shutting down\n;
+ d_cs-send(s_response_usrp_tx_write,
+ pmt_list3(PMT_NIL, PMT_F, PMT_NIL));
+ return;
+ }
size_t n_bytes;
bool underrun; // this will need to go, as it is taken care of in the packet headers
@@ -114,7 +122,7 @@
if (ret == (int) n_bytes) {
if (verbose)
- std::cout [usrp_server] Write of n_bytes successful\n;
+ std::cout [usrp_tx] Write of n_bytes successful\n;
// need to respond with the channel so the USRP server knows who to forward the result of
// the write to by looking up the owner of the channel
d_cs-send(s_response_usrp_tx_write,
@@ -122,7 +130,7 @@
}
else {
if (verbose)
- std::cout [usrp_server] Error writing n_bytes bytes to USB bus\n;
+ std::cout [usrp_tx] Error writing n_bytes bytes to USB bus\n;
d_cs-send(s_response_usrp_tx_write,
pmt_list3(invocation_handle, PMT_F, channel));
}
=== modified file 'usrp/host/lib/inband/usrp_usb_interface.cc'
--- usrp/host/lib/inband/usrp_usb_interface.cc 2009-01-26 01:06:02 +
+++ usrp/host/lib/inband/usrp_usb_interface.cc 2009-01-26 01:54:15 +
@@ -412,6 +412,11 @@
// d_utx-_write_oe(1, 0x, 0x);
// d_urx-_write_oe(1, 0x, 0x);
+ pmt_t tx_handle = pmt_make_any(d_utx);
+ pmt_t rx_handle = pmt_make_any(d_urx);
+ d_tx_cs-send(s_cmd_usrp_tx_handle, tx_handle);
+ d_rx_cs-send(s_cmd_usrp_rx_handle, rx_handle);
+
d_cs-send(s_response_usrp_open, pmt_list2(invocation_handle, PMT_T));
}
@@ -426,17 +431,7 @@
void
usrp_usb_interface::handle_cmd_write(pmt_t data)
{
- pmt_t invocation_handle = pmt_nth(0, data);
- pmt_t channel = pmt_nth(1, data);
- pmt_t pkts = pmt_nth(2, data);
-
- pmt_t tx_handle = pmt_make_any(d_utx);
-
- d_tx_cs-send(s_cmd_usrp_tx_write,
-pmt_list4(invocation_handle,
- channel,
- pkts,
- tx_handle));
+ d_tx_cs-send(s_cmd_usrp_tx_write, data);
}
/*!
@@ -455,9 +450,7 @@
if(!d_fake_usrp)
Re: [Discuss-gnuradio] full daughterboard support added to in-band code in-band update
On Friday 16 January 2009 19:52:47 George Nychis wrote: Hi all, Thanks to Eric, Jonathan, Tom, and whoever else worked on the C++ daughterboard code, we now have full daughterboard support for the in-band project. I only have BasicTX/RX and RFX2400 which I tested. If anyone wants to test others I would greatly appreciate it. I have made modifications to usrp_usb_interface in usrp/host/lib/inband for the support, which are now checked in to the trunk. You can specify a center frequency by adding an rf-freq element in the usrp_dict dictionary in any of the applications, for example to use 2.45G: pmt_dict_set(usrp_dict, pmt_intern(rf-freq), pmt_from_long(2450e6)); Hm, MAX_LONG= (2^31)-1 = 2147 483 648 2450e6 = 2450 000 000 MAX_LONG Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird WX scope problem
On Monday 22 September 2008 04:38:49 Josh Blum wrote:
http://gnuradio.org/trac/changeset/9637
Yeah, looks fine ...
Just a small nitpick, in fftsink_gl.py, there is still this line:
--
class _fft_sink_base(gr.hier_block2, common.prop_setter):
...
def __init__(
...
fft_rate=gr.prefs().get_long('wxgui', 'fft_rate',
fft_window.DEFAULT_FRAME_RATE),
---
Although this should have no effect, it might be misleading for anyone looking
at the code.
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird WX scope problem
On Saturday 20 September 2008 23:22:20 Matt Ettus wrote: This is usually caused by your system not being able to keep up.Try lowering the fft_rate. The code from trunk does not use the fft_rate from the config file (opengl version of scope sink). Sent a patch to patch-gnuradio on thursday. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Patch 2/3: usrp specific patches
Am Tuesday 16 September 2008 18:56:27 schrieb Eric Blossom: On Tue, Sep 16, 2008 at 05:35:49PM +0200, Stefan Brüns wrote: On Tuesday 16 September 2008 14:24:49 Stefan Brüns wrote: Making usrp_basic abstract and some of the functions pure virtual caught some faults - newer call a virtual method in the base constructor and hope it calls the method of the derived class. Stefan, A call through a virtual in the base constructor will not resolve to the derived class, it calls the base class. (The derived class has not yet been initialized, since we're still in the constructor of the base.) Yes, I know that, and I exactly meant to say that. The comment was actually meant for the third patch, where the constructors where calling the wrong methods. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Not able to set TX freq from c++ (branch trondeau/dbs) - solved (part 1)
Found the bug, at least the first:
db_flexrf.cc:
---
flexrf_base_tx::flexrf_base_tx(usrp_basic *usrp, int which, int _power_on)
: flexrf_base(usrp, which, _power_on)
{
/*
@param usrp: instance of usrp.sink_c
@param which: 0 or 1 corresponding to side TX_A or TX_B respectively.
*/
d_usrp = (usrp_basic_tx*)usrp;
d_tx = true;
int d_spi_enable; // -- shadows class member!
if(which == 0) {
d_spi_enable = SPI_ENABLE_TX_A;
}
else {
d_spi_enable = SPI_ENABLE_TX_B;
}
--
At least, the board is able to tune to the right frequency, and I was able to
send a few times.
Unfortunately, after running a few other (python) examples, it stopped
working, so I think, the python code modifies some registers and the c++ code
is not able to set this registers to working values.
Disconnecting power from the USRPs did not help - any hints?
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope displays in trunk
On Monday 18 August 2008 18:04:23 Johnathan Corgan wrote: On Mon, Aug 18, 2008 at 4:57 AM, Firas A. [EMAIL PROTECTED] wrote: 2) I think screen refresh (drawing times) is too high (on my system) that leads to flickering. You can lower the frame rate from the default of 30 by adding the following line(s) to your config.conf: [wxgui] fft_rate=15 (...or whatever frame rate you want) This will work with either the old or the new sinks. Unfortunately, this is not the case - waterfallsink_gl.py uses DEFAULT_FRAME_RATE, which is set waterfall_window.py to the fixed value of 30. There is another problem with the frame rate, if it is decreased often enough, old_framerate*0.75 will yield 0, and this leads to various problems. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make Check Failures under FC9 on Intel
On Tuesday 01 July 2008 23:06:57 Don Ward wrote: I ran into this today with gcc 4.3.1 on Debian (testing). Line 101 of qa_gr_fxpt_nco.cc new_nco.sincos ((gr_complex*)new_block, SIN_COS_BLOCK_SIZE); only fills the first 1696 members of new_block (though SIN_COS_BLOCK_SIZE = 10). Adding printf statements to new_nco.sincos or compiling qa_gr_fxpt_nco.cc with -O1 makes the problem go away. openSUSE affected as well. Bug report for gcc with simplified test case can be found here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37067 Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
