[Discuss-gnuradio] Beagle board update
I have some NEON code in the fff dotproduct routine, the qa code passes: [EMAIL PROTECTED]:/home/balister/oe/tmp/work/armv7a-angstrom-linux-gnueabi/gnuradio-3.1.3+svnr9809-r4.1/trunk/gnuradio-core/src/tests# ./test_filter . [generic] [cortex_a8] . [generic] [cortex_a8] . [generic] . [generic] . [generic] . [generic] .>>> gr_fir_fff: using cortex_a8 .. OK (9 tests) [EMAIL PROTECTED]:/home/balister/oe/tmp/work/armv7a-angstrom-linux-gnueabi/gnuradio-3.1.3+svnr9809-r4.1/trunk/gnuradio-core/src/tests# ./benchmark_dotprod_fff generic: taps: 256 input: 4e+07 cpu: 968.586 taps/sec: 1.057e+07 cortex_a8: taps: 256 input: 4e+07 cpu: 45.703taps/sec: 2.241e+08 Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] installation problem
> > Since they only have swig 1.3.29 installed, I installed myself 1.3.36 on > my space (at least as a temporary solution). > > Now when I run "configure" in gnuradio it does not recognize the new > swig, but the old one... > In addition, after "configure" is run, when I do "which swig" I get the > old version not the one I installed and similarly "swig -version" gives > me the old one (ie, the one originally installed in the system). > > Did you uninstall the older version with make uninstall? -- Umair ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Catching mouse clicks in fft_sink
For the gl fft sink, try to bind it to the self.spectrum.win.plotter plotter is a gl canvas -Josh Steve Glass wrote: Hi, I've been using the following to catch mouse clicks in the original fft_sink: self.spectrum.win.Bind(wx.EVT_LEFT_DOWN, self.spectrum_on_left_click) to invoke the following method: def spectrum_on_left_click(self, event): x, y = self.spectrum.win.GetXY(event) self.SetStatusText(str(x)) but since I've switched to using the new fftsink2 class no clicks get caught by this method. I've tried using the eventmanager too but no joy with that approach either. Is this simply my code or are others having problems getting mouse click events in fftsink2? Regards Stevie -- The highest human happiness is not the exploitation of the present but the preparation of the future. ___ 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
[Discuss-gnuradio] Catching mouse clicks in fft_sink
Hi, I've been using the following to catch mouse clicks in the original fft_sink: self.spectrum.win.Bind(wx.EVT_LEFT_DOWN, self.spectrum_on_left_click) to invoke the following method: def spectrum_on_left_click(self, event): x, y = self.spectrum.win.GetXY(event) self.SetStatusText(str(x)) but since I've switched to using the new fftsink2 class no clicks get caught by this method. I've tried using the eventmanager too but no joy with that approach either. Is this simply my code or are others having problems getting mouse click events in fftsink2? Regards Stevie -- The highest human happiness is not the exploitation of the present but the preparation of the future. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
On Thu, Oct 23, 2008 at 05:52:18PM -0400, Ed Criscuolo wrote: > Eric Blossom wrote: >> On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > > >>> At this point, I think I'll embed all the packet reading AND >>> hdlc processing into a single source block with no flow >>> inputs. This way the block can check for packets on the TUN >>> device, read them, bitstuff and hdlc frame them, and put them >>> into an internal ring buffer. Then it would return as many bits >>> as requested, or flags if the ring buffer was empty. >> >> OK. The only problem that I can see with this is that the scheduler >> will run this block whenever there is space available in the >> downstream buffer. If your data rate is low (100's of b/s) we could >> be adding a serious amount of latency to the system. If this is a >> deep space probe, no problem :-) otherwise we may need to cookup some >> way to limit the amount of buffer used between the blocks. The >> default is ~32KB. If the data rate is relatively high, the 32KB of >> buffering may not be an issue. >> > > It's not deep space, just LEO (Low Earth Orbit), so speed-of-light > latency is only on the order of 5 - 30 mS. > > This flow will be feeding the uplink, which runs at 9600 bits/sec. > Not that low, but not very high either. OK > My initial plan, was to have the block output an unpacked stream > of bits, one per byte. Now, if I'm understanding you correctly, > the scheduler will request as much as 32KB of output from this > hdlc source block at one time. At one bit/byte, and 9600 bits/sec, > that amounts to just over 3 seconds worth of data. If my ring > buffer just happens to be empty, this means I'm going to insert > 3 seconds worth of flags into the stream at once, even if I have > a packet come along in the next millisecond. This would cause > me to fall behind, never to catch up. The overall effect would > be to reduce my effective data rate to something less than 9600. > Seems like I should be checking for newly arrived packets after > sending each flag, not just once per invocation of the work method. > But this sounds like a lot of extra processing overhead. Is it > possible for a block to return less than the number of outputs > requested? (I think the answer is yes for a block, no for a sync > block). You can return less. In any event, the scheduler will call you again if there's still room in the output buffer. > Would that be a better way to limit the amount of data output at once? I think the right answer is to come up with a way to limit the total buffer space you see. My suggestion is to not worry about it right now, get the rest of it working, then we can fix this problem. It shouldn't be a big deal. (I just spent a couple of minutes looking at it. It won't be hard to limit the buffer space seen. We just need to come up with a reasonable API for it.) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
Eric Blossom wrote: On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > At this point, I think I'll embed all the packet reading AND hdlc processing into a single source block with no flow inputs. This way the block can check for packets on the TUN device, read them, bitstuff and hdlc frame them, and put them into an internal ring buffer. Then it would return as many bits as requested, or flags if the ring buffer was empty. OK. The only problem that I can see with this is that the scheduler will run this block whenever there is space available in the downstream buffer. If your data rate is low (100's of b/s) we could be adding a serious amount of latency to the system. If this is a deep space probe, no problem :-) otherwise we may need to cookup some way to limit the amount of buffer used between the blocks. The default is ~32KB. If the data rate is relatively high, the 32KB of buffering may not be an issue. It's not deep space, just LEO (Low Earth Orbit), so speed-of-light latency is only on the order of 5 - 30 mS. This flow will be feeding the uplink, which runs at 9600 bits/sec. Not that low, but not very high either. My initial plan, was to have the block output an unpacked stream of bits, one per byte. Now, if I'm understanding you correctly, the scheduler will request as much as 32KB of output from this hdlc source block at one time. At one bit/byte, and 9600 bits/sec, that amounts to just over 3 seconds worth of data. If my ring buffer just happens to be empty, this means I'm going to insert 3 seconds worth of flags into the stream at once, even if I have a packet come along in the next millisecond. This would cause me to fall behind, never to catch up. The overall effect would be to reduce my effective data rate to something less than 9600. Seems like I should be checking for newly arrived packets after sending each flag, not just once per invocation of the work method. But this sounds like a lot of extra processing overhead. Is it possible for a block to return less than the number of outputs requested? (I think the answer is yes for a block, no for a sync block). Would that be a better way to limit the amount of data output at once? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > Eric Blossom wrote: >> >> Ed, >> >> The problem is that you need to know when the output is about to >> underrun, and only then insert flags. >> >> Is there any external reference clock or other way to tell when the >> external stream needs data? In general, GR has no tie to an external >> timebase, except indirectly through sinks or sources that consume data >> at a fixed rate (e.g., USRP, audio card, etc). If there is some way >> to tell when the external world is ready for more data, we can solve >> this problem. > > The data stream needs to be at a fixed rate. I was planning to add > a throttle block to insure this. You definitely don't want to use a throttle block for this purpose. It's only reason for existence is so that file driven GUI test code doesn't suck down all the CPU available. >> Is the USRP the final sink for the modulated bits? >> > > Yes, after it's upsampled and modulated, the USRP is the final sink. Good. > I realize that this should pace things, but I figured the throttle > block would be a good idea in that it would allow me to test > without a USRP hooked up, just a spectrum display. I strongly suggest not using the throttle block. Definitely don't use it if the USRP is in the graph. There should be only a single clock in the system. > At this point, I think I'll embed all the packet reading AND > hdlc processing into a single source block with no flow > inputs. This way the block can check for packets on the TUN > device, read them, bitstuff and hdlc frame them, and put them > into an internal ring buffer. Then it would return as many bits > as requested, or flags if the ring buffer was empty. OK. The only problem that I can see with this is that the scheduler will run this block whenever there is space available in the downstream buffer. If your data rate is low (100's of b/s) we could be adding a serious amount of latency to the system. If this is a deep space probe, no problem :-) otherwise we may need to cookup some way to limit the amount of buffer used between the blocks. The default is ~32KB. If the data rate is relatively high, the 32KB of buffering may not be an issue. > I'm assuming that the scheduler would keep asking for enough bits > from this source block to keep the flow going at the throttled rate. > (assuming I have enough CPU power to keep up). Yes. > Does this approach sound like it will work? Yes. Let us know how it works out! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] installation problem
On Thu, Oct 23, 2008 at 10:31:19AM -0400, Achilleas Anastasopoulos wrote: > Hi, > > I am trying to install gnuradio on a Linux system for which I am not the > owner (university-wide computing at U of Michigan). > Since they only have swig 1.3.29 installed, I installed myself 1.3.36 on > my space (at least as a temporary solution). I also added the path to > the new swig in my path variable and > verified that > >> which swig > /afs/engin.umich.edu/u/a/n/anastas/mylocal/bin/swig > > and > >> swig -version > SWIG Version 1.3.36 > > Fine so far. Be sure your PATH is set correctly. > Now when I run "configure" in gnuradio it does not recognize the new > swig, but the old one... > In addition, after "configure" is run, when I do "which swig" I get the > old version not the one I installed and similarly "swig -version" gives > me the old one (ie, the one originally installed in the system). I suspect you were doing this in a different window then when you first typed 'which swig' Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get wireless carrier signal in GNU Radio
Hi Zhenghao, Thank you for your valuable reply. I appreciate it. As per your supplied information, I will start looking for CSMA code in tunnel.py, though if you can send me your code, it will be quite helpful too. I hope that using tunnel.py code and help from you I will be able to get the carrier sense capability for my application. Thanks -Sachin Zenny Zhang wrote: > > Sachin, > > I don't know if this is helpful, just sharing my experience. > > 1. You may want to check tunnel.py, in which there is a CSMA scheme -- > Eric told me this a couple of weeks ago. > 2. It is possible to do some carrier sensing by ourself. You can just > read the signal from the USRP and compare the signal strength level > with a threshold. Of course a filter is needed. I tried this last week > and it is working, although the threshold may need some tuning. If you > need I can send you the code written in python. > > Zhenghao > > On Wed, Oct 22, 2008 at 6:19 PM, Shirve <[EMAIL PROTECTED]> wrote: >> >> Hi, >> As per the current status of GNU Radio, I got to know that there is no >> MAC >> (CSMA) implementation. Therefore I am not sure if I can get the signal >> from >> signal processing blocks of GNU Radio about the carrier sensed by USRP >> receiver. >> >> Please help me in this regard. >> >> Till now I am able to locate the message queue mechanism to get the >> received >> packets from the other USRP transmitter, which is in gr_msg_que.cc in >> runtime library of GNUradio-core. But this mechanism just indicates the >> received packets (correct or corrupted), while the signal sensing (packet >> start) starts much earlier than the complete packet reception. >> >> Is it possible to get the information about the wireless carrier signal >> in >> the vicinity of USRP receiver from the current GNU Radio framework? I am >> using GNU Radio 3.1.1 version. >> >> Your help will greatly help me in my goal. Thanks in advance and >> expecting >> your kind reply. >> >> - Sachin >> -- >> View this message in context: >> http://www.nabble.com/how-to-get-wireless-carrier-signal-in-GNU-Radio-tp20120856p20120856.html >> Sent from the GnuRadio mailing list archive at Nabble.com. >> >> >> >> ___ >> 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 > > -- View this message in context: http://www.nabble.com/how-to-get-wireless-carrier-signal-in-GNU-Radio-tp20120856p20139200.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast method for HDLC transmit block
Eric Blossom wrote: Ed, The problem is that you need to know when the output is about to underrun, and only then insert flags. Is there any external reference clock or other way to tell when the external stream needs data? In general, GR has no tie to an external timebase, except indirectly through sinks or sources that consume data at a fixed rate (e.g., USRP, audio card, etc). If there is some way to tell when the external world is ready for more data, we can solve this problem. The data stream needs to be at a fixed rate. I was planning to add a throttle block to insure this. Is the USRP the final sink for the modulated bits? Yes, after it's upsampled and modulated, the USRP is the final sink. I realize that this should pace things, but I figured the throttle block would be a good idea in that it would allow me to test without a USRP hooked up, just a spectrum display. At this point, I think I'll embed all the packet reading AND hdlc processing into a single source block with no flow inputs. This way the block can check for packets on the TUN device, read them, bitstuff and hdlc frame them, and put them into an internal ring buffer. Then it would return as many bits as requested, or flags if the ring buffer was empty. I'm assuming that the scheduler would keep asking for enough bits from this source block to keep the flow going at the throttled rate. (assuming I have enough CPU power to keep up). Does this approach sound like it will work? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRp clock sync
Hello, Can I get the clock signal from the usrp? I know that I can get it via hardware, but, it's possible to do this via software? For example, if I create a counter, wich just increment a number on a USRP clock rise or fall. It's possible to do this on GNUradio? Thank you all, -- __ Ronaldo A. Viera Nunez Acadêmico/Engenharia Elétrica Universidade Federal de Santa Maria Santa Maria - RS - Brasil Email: [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 External Clock
Mamoru Yamamoto wrote: Would you please inform us what spec. 10MHz and 1PPS signals are needed? What waveform are they? The Reference input can take a square or sine wave input, it is DC-blocked and is terminated in 50 ohms. The input should be less than 3V pk-pk. The PPS input is not DC blocked. It is AC terminated in 50 ohms, DC terminated in 1K. The digital signal you put in should be between 0 and 5 V. It should never go below 0V and never above 6V. What phase relation do you expect between 10MHz and 1PPS? The PPS signal should be synchronous to the 10 MHz reference. It doesn't actually have to be a PPS signal, it can be any digital signal, but you would need to figure out how to deal with it in the FPGA. It is helpful if you could show us examples of the matching GPS clock/receiver models, too. Nearly any GPS frequency reference should work. Everything from http://jackson-labs.com would suffice. Tell them I sent you :) May I just miss finding the information from the wiki? I will put it there. Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Last few packets dropped
Hi all When I ran benchmark_ofdm_tx.py, I noticed that the last few packets (5-20, depends on the packet size and modulation) always got dropped. The spectrum analyzer shows nothing transmitted. Using --discontinuous helps to reduce the # of dropped packets, but the 2-3 packets of the last run still got last. Similar case when I run tunnel.py under the example ofdm folder. When I ping another machine, spectrum analyzer shows no transmission at all although the laptop screen shows "Tx: len(payload)=42". I searched the mailing list and found similar discussion two years ago about the dropped packets problem but no solusion there. Has anybody successfully got tunnel.py working? My OS is Ubuntu 7.04 and I checked the gnuradio several days ago. I use USRP1 and RFX2400. Thanks! Best regards, Zheng Zeng [EMAIL PROTECTED] 2008-10-23 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] US Spectrum Allocation Details
isaacgerg wrote: > I am looking for a detailed spectrum allocation guide for the US. Im not > talking the default "US Frequency Allocations Chart." but something more > like a book or guide. Does such a thing exist? That data is scattered all over the place at the moment, and we've had to spend a large amount of time digesting and marking it up. We'll post our code and tidy XML representations of the data soon. Generally speaking, the sources you would have to dig through to get the full details of US spectrum allocations are: 1) The FCC regulations, 47 CFR, contain band allocations, power restrictions, etc.: http://www.access.gpo.gov/cgi-bin/cfrassemble.cgi?title=200447 2) Additional information on federal band allocations can be found in the NTIA Redbook: http://www.ntia.doc.gov/osmhome/redbook/redbook.html 3) Most allocations to non-Federal organizations are in the FCC Universal Licensing System. You can download the entire contents of this database as delimited text files, but they're an amazingly awful mess and require substantial pre-processing. http://wireless.fcc.gov/uls/index.htm?job=transaction&page=weekly 4) AM, FM, and TV broadcast stations are in the FCC CDBS, which is not nearly as bad as ULS: http://www.fcc.gov/mb/databases/cdbs/ 5) Shortwave broadcast stations are on the FCC HF Broadcasting site: http://www.fcc.gov/ib/sand/neg/hf_web/seasons.html 6) Federal allocations are listed in the NTIA Government Master File. This is a classified database, but we managed to get half of the GMF records in a FOIA request last summer, and we'll be requesting an updated and expanded version. 7) Some additional information is available in the FCC IBFS, COALS, and Equipment Authorization databases, and in various DISA JSC databases. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Signal processing and GPU
--- Martin DvH <[EMAIL PROTECTED]> wrote: > > All that said. I do have a complete WFM receiver > which is running > completely on the GPU. > (using FIR and/or FFT filters, quadrature_demod, > fm-deemph) > > At the moment it is not running faster then on the > CPU, mainly because > of the call overhead. (too little work items done > per call) > And the extra copying done to emulate circular > buffers. > Do share with us which video card you are using and roughly how much slower is the GPU WFM ? Regards, Hew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installation problem
Hi, I am trying to install gnuradio on a Linux system for which I am not the owner (university-wide computing at U of Michigan). Since they only have swig 1.3.29 installed, I installed myself 1.3.36 on my space (at least as a temporary solution). I also added the path to the new swig in my path variable and verified that which swig /afs/engin.umich.edu/u/a/n/anastas/mylocal/bin/swig and swig -version SWIG Version 1.3.36 Fine so far. Now when I run "configure" in gnuradio it does not recognize the new swig, but the old one... In addition, after "configure" is run, when I do "which swig" I get the old version not the one I installed and similarly "swig -version" gives me the old one (ie, the one originally installed in the system). I could circumvent this problem by changing the configure script by adding $SWIG = right before the part of the code that checks for the swig version. Now "configure" works fine. However i would like to know what I am doing wrong in the first place. Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] US Spectrum Allocation Details
Hi, I am looking for a detailed spectrum allocation guide for the US. Im not talking the default "US Frequency Allocations Chart." but something more like a book or guide. Does such a thing exist? Thanks in advance, Isaac -- View this message in context: http://www.nabble.com/US-Spectrum-Allocation-Details-tp20129833p20129833.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [Install gnuradio_r7596]
Hello, several months ago I've installed gnuradio version 3.1.2, but now I want to use the ofdm module, so I followed this "how to install" https://www.cgran.org/wiki/SPAN80211b#HowToInstall, but I have had some problems. I do the bootstrap, and it seems to run ok. Then I do the configure (./configure --with-boost=/opt/boost_1_36_0 >& configure.log &), and It seems the make doesn't find the make in the directory /gnuradio_r7596/python. Looking in this directory there is no a Makefile, and looking in to the trace, It doen't seem that it was generated. Another thing, when i do de configure, at the end say: "The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-osx gr-audio-windows grc These components will not be built. " My operative system is Ubuntu 7. Thanks -- View this message in context: http://www.nabble.com/-Install-gnuradio_r7596--tp20128799p20128799.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Transmission power and GUI
Hi, I am using RFX2400+USRP+SUSI, and I have two questions: 1) I am extending my main class from gr.top_block and I have noticed that all application examples which implement GUI are using stdgui.gui_flow_graph. I have tried stdgui.but in my application that cant be used because I have to run parallel/multiple flowgraphs but I want to implement GUI as well. Can some one guide me how can integerate GUI with such an application using gr.top_block, it would be better if one could refer me to some example code. 2) After reading many posts on this forum I have got an idea how the transmission power is controlled and implemented but still I am unable to get exact figure in dB. I mean I read that the transmission power is set by: --- u.set_pga(0/1, gain)By doing this we set the maximum balue of gain, but it is not setting the amplitude of transmitted signal (i.e. transmission power) or in other words it simply set what can be the maximum transmission power (maximum limit allowed). But the actual transmission power is set by the following: gr.multiply_const_cc(AMPLITUDE)..and the maximum AMPLITUDE is ~32000 It means that maximum AMPLITUDE i.e ~32000 can only be set if first we have set gain by set_pga() to maximum allowed value. ---Please let me know if above concept is correct. Now I want to know what is the exact (or almost) transmission power in dB corresponding to different values of AMPLITUDE, e.g. what for the following: AMPLITUDE = 32000.. ?? dB AMPLITUDE = 26000.. ?? dB AMPLITUDE = 2.. ?? dB AMPLITUDE = 16000.. ?? dB AMPLITUDE = 1.. ?? dB and is there any standard formulea which I can use to exactly calculate the dB value corresponding any AMPLITUDE value? Thanks in advance Kaleem Ahmad -- View this message in context: http://www.nabble.com/Transmission-power-and-GUI-tp20127597p20127597.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A Verilog question or two
On Thursday 16 October 2008 01:00:19 Jason Uher wrote: > 2008/10/14 Daniel O'Connor <[EMAIL PROTECTED]>: > > On Wednesday 15 October 2008 01:15:48 Sebastiaan Heunis wrote: > >> always @(posedge clk) > >> begin > >> tap1 <= #1 input; > >> tap2 <= #1 tap1; > >> tap3 <= #1 tap2; > >> end > >> > >> the #1 ensures that tap1 gets updated before tap2? > > > > According to what I have read with about synthesis tools the delays will > > be ignored totally. > > > > I see a lot of it though, so I don't know if it's superstition or the > > manual lies. > > I think the delays are just for simulation. In synthesis the > assignments take a real amount of time to complete (because it's > hardware). If you are dependent on that delay, you need to signify > that in simulation, otherwise the assignment would occur at the same > simulation timestep as everything else and you could be using new data > instead of old. Most likely synthesis ignores them, but they are > needed for the simulation (I'm not 100% sure, I usually remove all > such delays before synthesis testing). Hmm.. I think it's more likely to be superstition for broken simulators then.. A book I have (Kilts - Advanced FPGA design) states that "Delays are always ignored by synthesis tools, and this type of modeling can easily create mismatches between simulation and synthesis." (page 167). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C 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
