Re: [Discuss-gnuradio] re playing file_source?
On Wed, Jul 27, 2011 at 11:36 AM, Minhoo Kim wrote: > > is there a way to replay gr.file_source? > by replay, I mean controlled replay, not the repeat that's already an option > within the function. > I can't use the repeat, because I need the file to play once (and just > once), change the frequency of the daughterboard, then play the file just > once, and so on. > So while the daughterboard is retuning, I need the file to stop playing, and > I need to make sure the board is retuned before the file starts playing so > no information is lost. > > Any help would be great. > > Thanks a lot. Take a look at the documentation for that function: http://gnuradio.org/doc/doxygen/index.html There is a "seek" method that you can use. To reset the source to the beginning of the file, you can use seek(0, SEEK_SET). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Plotting Data Received by USRP
On Wed, Jul 27, 2011 at 3:29 PM, valentac wrote: > > Ok, I wasn't aware of those difference between the vector source and the > message source. So if I put my data in a message source, can I connect this > directly to qtgui.time_sink_f? I'd think I'd have to do some other > formatting here. > > Let me explain a bit more...after receiving the payload from the message > sink following the receiver path in benchmark_rx, I have some data. I'd like > to plot this data on a time graph and update it after every packet is > received. I guess fundamentally my question is, what type of source do I > need to do this. It appears that a message source is the wrong length to > connect to the time_sink_f. As I said, you'll have to look more at some of the examples that use the message sources and sinks to understand how to handle this. You'll eventually set up a second flow graph with a message source and graphical sink. Your receiver flow graph will then send the messages from itself to the message source. How this is actually implemented is "left as an exercise to the reader." Tom > Tom Rondeau wrote: >> >> >> Josh suggested the use of message source/sink, not the vector source/sinks >> that you are currently using. Two different things. The vector source and >> sink are meant more for testing and debugging while the message source and >> sink are designed to handle exactly your situation in a running program. >> >> Look through the benchmark_rx code we have. The framer at the end of the >> receive chain is a message sink, actually, and we get the messages in a >> callback function in the Python world. You would have to set up a message >> source to listen for the messages and process them farther from there. >> >> Tom >> >> >> > > -- > View this message in context: > http://old.nabble.com/Plotting-Data-Received-by-USRP-tp32126980p32150867.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
On Wed, Jul 27, 2011 at 4:16 PM, Thomas Tsou wrote: > On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer > wrote: > > Hi all, > > I'm running a duplex system on the USRP1; using UHD drivers (about 1 > month > > old). For the sample rates, I have 640KHz to the USRP and 1MHz from the > > USRP. The turn around time for a simple amplitude detected signal is > approx > > 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by > > observing the nitems_written() method for the block that produces samples > > for the sync. > > I'm running UHD and gnuradio with real time threading enabled and giving > the > > gnuradio app a nice of -20. Since this happens before any math occurs, I > > assume the kernel is lagging on this. Could switching to a modified > kernel > > with realtime improvement patches help? > > The short answer is that using the RT patch series won't perform any > magic and bring across the board reductions in measured latencies. The > longer answer is, of course, more complicated. If you want > straightforward solutions, try removing other peripherals from the USB > bus and disabling all power management (preferably from the kernel). > The latter can be particularly sinister when it comes to tracking down > latency bugs. > > Once upon a time, I wrote a kernel module to handle a hard interrupt > off of a parallel port and trigger responses from within kernel space > (out another pin) and userspace (submitting transfers to libusrp). An > external scope was was used for timing measurement. Response times > were on average in the single and 10's of microseconds respectively, > but differed drastically based on many factors. The main ones were CPU > load, power management, and other devices on the USB bus. > > When it comes to RT patches, you need to consider that the objective > is typically containing maximum latencies and not necessarily minimal > or average times. In certain cases, average latencies using RT code > may be even be higher than the mainline version. > > When I ran the tests, differences between mainline (somewhere around > 2.6.31) and RT series kernels were initially limited, but became > apparent when running at near 100% CPU load. In contrived cases, the > maximum latency on the normal kernel could increase without bound, > which would be more limited on the RT kernel. > > To sum it up, RT changes to the kernel will have an effect, but it > probably won't be immediately obvious. I would start from more obvious > areas - for example by seeing what power management is up to. > > Thomas > Thanks for the detailed reply Thomas! I'll give the power management changes (from the kernel and from BIOS) a shot, then will try the ubuntu linux-rt kernel from their ubuntu studio repo. Are there any particular power options to change on the Kernel? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer wrote: > Hi all, > I'm running a duplex system on the USRP1; using UHD drivers (about 1 month > old). For the sample rates, I have 640KHz to the USRP and 1MHz from the > USRP. The turn around time for a simple amplitude detected signal is approx > 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by > observing the nitems_written() method for the block that produces samples > for the sync. > I'm running UHD and gnuradio with real time threading enabled and giving the > gnuradio app a nice of -20. Since this happens before any math occurs, I > assume the kernel is lagging on this. Could switching to a modified kernel > with realtime improvement patches help? The short answer is that using the RT patch series won't perform any magic and bring across the board reductions in measured latencies. The longer answer is, of course, more complicated. If you want straightforward solutions, try removing other peripherals from the USB bus and disabling all power management (preferably from the kernel). The latter can be particularly sinister when it comes to tracking down latency bugs. Once upon a time, I wrote a kernel module to handle a hard interrupt off of a parallel port and trigger responses from within kernel space (out another pin) and userspace (submitting transfers to libusrp). An external scope was was used for timing measurement. Response times were on average in the single and 10's of microseconds respectively, but differed drastically based on many factors. The main ones were CPU load, power management, and other devices on the USB bus. When it comes to RT patches, you need to consider that the objective is typically containing maximum latencies and not necessarily minimal or average times. In certain cases, average latencies using RT code may be even be higher than the mainline version. When I ran the tests, differences between mainline (somewhere around 2.6.31) and RT series kernels were initially limited, but became apparent when running at near 100% CPU load. In contrived cases, the maximum latency on the normal kernel could increase without bound, which would be more limited on the RT kernel. To sum it up, RT changes to the kernel will have an effect, but it probably won't be immediately obvious. I would start from more obvious areas - for example by seeing what power management is up to. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IEEE 802.15.4 on USRP N210
Hi Marius, Thanks for the quick reply. First of all I get a communication now. When I set the sample rate to 4M then it works. Any idea why? Could it have something to do with the 2M data rate? But shouldn't it then work with every sample rate > 4M, which it doesn't? See more info below. > I don't really understand what you're trying to archive, but here's a > stack for 802.15.4: > http://wiesel.ece.utah.edu/redmine/projects/gr-ieee802-15-4/wiki The first step to my goal was to get a communication going between USRP N210 devices and regular wireless sensor nodes, such as TelosB, etc. I have seen the stack you mentioned, but it is pretty similar to the UCLA stack with some extra features. Here, as well as with the UCLA stack some modifications are needed to make them work with N210s and the UHD driver. > How did you change the frequencies? If you change the center-frequency > on a FFT your USRP2 <-> PC communication breaks down? What is the > decimation? Sorry for that, probably I wasn't clear here. The frequency change had nothing to do with the FFT. The FFT I just did to see whether I actually get something from my sensor nodes and what might be the reason why I can receive from another N210, but not from a sensor node. The frequency change is done in the python script directly, i.e., in the setup of the USRP device. The original code has 2,475 GHz as its center frequency (which is channel 25 in the 802.15.4). When I have two N210s with that frequency, they do communicate. When I change the frequency to another channel (by changing the center frequency on both devices), they do not communicate any longer. > To demodulate you need at least 2 * the frequency of the channel. So > in case of 802.15.4 something like 5 MS/s should be sufficient. I thought the same. As soon as it should be over 2* it should be good. Thus the test with a rather high sampling rate. Strange is that two N210s can communicate with a 1M sample rate as long as both devices have the same sample rate. Now the combination sensor node - N210 works only with 4M. Any idea what might be the reason. > I actually finished a project on 802.15.4 and used USRP2s with the > WIESEL stack to analyze a real-time sensor network. I'll commit some > stuff quite soon (this week). E. g. a complete demod and mod path in > GRC. Most stuff is in German though. :) Let me know when you have some code or report work done on that. The language should not be an issue :) Regards, Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IEEE 802.15.4 on USRP N210
Hi Sebastian! I don't really understand what you're trying to archive, but here's a stack for 802.15.4: http://wiesel.ece.utah.edu/redmine/projects/gr-ieee802-15-4/wiki > I am trying to communicate between gnuradio (USRP) and 802.15.4 sensor > nodes, as it has been done before (see Thomas Schmid @ UCLA). Because > the hardware has evolved since then, I am using USRP N210s as the > interface to the computer. The N210s are equipped with XCVR2450 Works fine here. The XCVR is a much better choice than the RFX, because it has TX gain. > Problem 1: When changing the center frequency on both Tx and Rx, > communication does not work any longer. Even a 5 MHz shift does the > deal. How did you change the frequencies? If you change the center-frequency on a FFT your USRP2 <-> PC communication breaks down? What is the decimation? > Problem 2: Packets send from a sensor node are not received. Do you send a full 802.15.4 MAC sublayer? The stack you mentioned uses a Packet Sink that drops packets on certain conditions. I changed that recently for my efforts. > I have the feeling > that > the node signal is only processed occasionally. In that case try attaching the GDB and log (verbose define statement at the C code). Actually if GNU Radio drops vectors it outputs an "S" indicating an overflow. > I played a bit around with sample rates. To demodulate you need at least 2 * the frequency of the channel. So in case of 802.15.4 something like 5 MS/s should be sufficient. > I hope someone might have an idea or a tip what else I could check out. I actually finished a project on 802.15.4 and used USRP2s with the WIESEL stack to analyze a real-time sensor network. I'll commit some stuff quite soon (this week). E. g. a complete demod and mod path in GRC. Most stuff is in German though. :) Best, Marius ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms
Hi all, I'm running a duplex system on the USRP1; using UHD drivers (about 1 month old). For the sample rates, I have 640KHz to the USRP and 1MHz from the USRP. The turn around time for a simple amplitude detected signal is approx 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by observing the nitems_written() method for the block that produces samples for the sync. I'm running UHD and gnuradio with real time threading enabled and giving the gnuradio app a nice of -20. Since this happens before any math occurs, I assume the kernel is lagging on this. Could switching to a modified kernel with realtime improvement patches help? Thanks, Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase correction
On 27/07/2011 3:03 PM, Matt Ettus wrote: You don't need to do fractional interpolation. Just phase rotation (complex multiply). Matt Brrrzzzt! Yup.. Doh! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Plotting Data Received by USRP
Ok, I wasn't aware of those difference between the vector source and the message source. So if I put my data in a message source, can I connect this directly to qtgui.time_sink_f? I'd think I'd have to do some other formatting here. Let me explain a bit more...after receiving the payload from the message sink following the receiver path in benchmark_rx, I have some data. I'd like to plot this data on a time graph and update it after every packet is received. I guess fundamentally my question is, what type of source do I need to do this. It appears that a message source is the wrong length to connect to the time_sink_f. Tom Rondeau wrote: > > > Josh suggested the use of message source/sink, not the vector source/sinks > that you are currently using. Two different things. The vector source and > sink are meant more for testing and debugging while the message source and > sink are designed to handle exactly your situation in a running program. > > Look through the benchmark_rx code we have. The framer at the end of the > receive chain is a message sink, actually, and we get the messages in a > callback function in the Python world. You would have to set up a message > source to listen for the messages and process them farther from there. > > Tom > > > -- View this message in context: http://old.nabble.com/Plotting-Data-Received-by-USRP-tp32126980p32150867.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase correction
On 07/27/2011 07:58 AM, Marcus D. Leech wrote: > I'm looking into updating some of my interferometer code to work with > newer hardware, like DBS_RX2, which will have unpredictable > phase offsets between LOs. > > I played with the fractional interpolator a little while ago, to use for > phase-correcting one half of the interferometer. Is there a better > method to use? > You don't need to do fractional interpolation. Just phase rotation (complex multiply). Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Announcement: New Hardware Platform solutions are available for use with GNURADIO
Dear all, Greetings from Agile Solutions...! New Hardware Platform solutions are available for use with GNURADIO. Please checkout our new solutions for exploring new posibilities with PC based SDR at www.agile-sdr-solutions.com Regards Team, Agile Solutions ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] re playing file_source?
is there a way to replay gr.file_source? by replay, I mean controlled replay, not the repeat that's already an option within the function. I can't use the repeat, because I need the file to play once (and just once), change the frequency of the daughterboard, then play the file just once, and so on. So while the daughterboard is retuning, I need the file to stop playing, and I need to make sure the board is retuned before the file starts playing so no information is lost. Any help would be great. Thanks a lot. -- View this message in context: http://old.nabble.com/replaying-file_source--tp32149011p32149011.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Phase correction
I'm looking into updating some of my interferometer code to work with newer hardware, like DBS_RX2, which will have unpredictable phase offsets between LOs. I played with the fractional interpolator a little while ago, to use for phase-correcting one half of the interferometer. Is there a better method to use? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi, I think you need to change the the O-QPSK modulator, it's in src/lib/ucla_qpsk_modulator_cc. Currently, for each chip, it expects 2MChips/s and produces 4 complex samples that specify the shape of the pulse (half a sine wave up for chip "1" and down for chip "0" or -1): *out++ = gr_complex(0.0, 0.0); *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678); *out++ = gr_complex(iphase, qphase); *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678); If you add more samples per pulse by interpolating in-between (say 8), you halve the bandwidth while using the same chipping sequence, using only 2 samples doubles it (when you use a fixed sampling rate). So if you want to increase the bandwidth, you should first adjust the default sampling rate/decimation of the ZigBee code as defined in the python script when initiating the USRP source, from 4MSamples (decim 16) to a higher value, and adjust the modulation block accordingly (e.g., decim 8 -> use 8 samples/chip), so that you still have several samples per chip even on larger bandwidths (to generate smooth pulses). The changes are then straight-forward, you just specify different cases/if clauses and produce a different number of samples for each symbol (i.e., for a sequence of 32 chips), depending on the bandwidth you want. The larger problem may be how to get the "schedule" information from python to the C code so that it's synchronized with the sampling stream, I don't have much experience on how you can achieve this in GNU Radio. I think there is a way to attach meta-data to a stream of samples ... Another approach is in-band signaling (interleaving special tags into the stream of samples that change settings in the blocks and are filtered out in the end), but I think it's more of a hack than sound design. Matthias Am 27.07.2011 um 15:22 schrieb bjoe...@ee.ethz.ch: > Hi, > > Thanks a lot for your reply! > > This is exactly what I was looking for! > Would you by any chance have an idea in what C level files I could manipulate > the interpolation? > > best regards and thank you, > Bjorn > > Zitat von "Matthias Wilhelm" : > >> Hi, >> >> i think this would be hard on the python level, you would need to notify the >> python code after each symbol to make adjustments, which will lead to >> latency between symbols ... >> >> (As I understand you want to keep the chipping sequences, but change the >> sampling rate used for each symbol. You can have the same effect by changing >> the interpolation between samples, keeping the rate constant, and >> oversampling small bandwidths. ) >> For this, I would suggest that you add a "per packet schedule" that >> specifies the bandwidth of each symbol, and hack the C code to follow the >> schedule, changing the interpolation between chips for each symbol. >> Something like send_802_15_4_pkt (packet, "1,2,8,2,4,1"), meaning 1MChips/s >> for the first symbol, 2MChips/s (the default) for the second, then >> 8MChips/s, etc. The benefit is that you can go on working on the packet >> level in python. >> On the C side, you would need to run the flow graph at 16MSamples (to get 2 >> samples per chip @ 8MChips/s, basically fast enough to support the largest >> bandwidth you want), and decide for each symbol the necessary interpolation >> to generate the specified bandwidth (e.g., 16 samples/chip @1MChips/s). >> >> Regards, >> Matthias >> >> >> Am 27.07.2011 um 13:31 schrieb bjoe...@ee.ethz.ch: >> >>> Hi, >>> >>> I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and >>> I need to >>> change the Bandwidth of the used wireless channel on a per symbol basis. >>> >>> I managed to change it on a per packet basis, which can be done on the >>> python level >>> (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same >>> thing, but on a >>> per symbol basis, which (up to my knowledge) is not possible from the >>> python level... >>> >>> Does anyone have an idea how I could do that? (Changing the Bitrate of the >>> USRP after >>> each symbol (e.g. after sending 32 modulated bits (actually chips))) >>> >>> I would be very happy for any help or suggestions! >>> Thanks a lot! >>> >>> best regards, >>> Bjorn >>> >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi, Thanks a lot for your reply! This is exactly what I was looking for! Would you by any chance have an idea in what C level files I could manipulate the interpolation? best regards and thank you, Bjorn Zitat von "Matthias Wilhelm" : Hi, i think this would be hard on the python level, you would need to notify the python code after each symbol to make adjustments, which will lead to latency between symbols ... (As I understand you want to keep the chipping sequences, but change the sampling rate used for each symbol. You can have the same effect by changing the interpolation between samples, keeping the rate constant, and oversampling small bandwidths. ) For this, I would suggest that you add a "per packet schedule" that specifies the bandwidth of each symbol, and hack the C code to follow the schedule, changing the interpolation between chips for each symbol. Something like send_802_15_4_pkt (packet, "1,2,8,2,4,1"), meaning 1MChips/s for the first symbol, 2MChips/s (the default) for the second, then 8MChips/s, etc. The benefit is that you can go on working on the packet level in python. On the C side, you would need to run the flow graph at 16MSamples (to get 2 samples per chip @ 8MChips/s, basically fast enough to support the largest bandwidth you want), and decide for each symbol the necessary interpolation to generate the specified bandwidth (e.g., 16 samples/chip @1MChips/s). Regards, Matthias Am 27.07.2011 um 13:31 schrieb bjoe...@ee.ethz.ch: Hi, I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I need to change the Bandwidth of the used wireless channel on a per symbol basis. I managed to change it on a per packet basis, which can be done on the python level (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same thing, but on a per symbol basis, which (up to my knowledge) is not possible from the python level... Does anyone have an idea how I could do that? (Changing the Bitrate of the USRP after each symbol (e.g. after sending 32 modulated bits (actually chips))) I would be very happy for any help or suggestions! Thanks a lot! best regards, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi, i think this would be hard on the python level, you would need to notify the python code after each symbol to make adjustments, which will lead to latency between symbols ... (As I understand you want to keep the chipping sequences, but change the sampling rate used for each symbol. You can have the same effect by changing the interpolation between samples, keeping the rate constant, and oversampling small bandwidths. ) For this, I would suggest that you add a "per packet schedule" that specifies the bandwidth of each symbol, and hack the C code to follow the schedule, changing the interpolation between chips for each symbol. Something like send_802_15_4_pkt (packet, "1,2,8,2,4,1"), meaning 1MChips/s for the first symbol, 2MChips/s (the default) for the second, then 8MChips/s, etc. The benefit is that you can go on working on the packet level in python. On the C side, you would need to run the flow graph at 16MSamples (to get 2 samples per chip @ 8MChips/s, basically fast enough to support the largest bandwidth you want), and decide for each symbol the necessary interpolation to generate the specified bandwidth (e.g., 16 samples/chip @1MChips/s). Regards, Matthias Am 27.07.2011 um 13:31 schrieb bjoe...@ee.ethz.ch: > Hi, > > I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I > need to > change the Bandwidth of the used wireless channel on a per symbol basis. > > I managed to change it on a per packet basis, which can be done on the python > level > (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same > thing, but on a > per symbol basis, which (up to my knowledge) is not possible from the python > level... > > Does anyone have an idea how I could do that? (Changing the Bitrate of the > USRP after > each symbol (e.g. after sending 32 modulated bits (actually chips))) > > I would be very happy for any help or suggestions! > Thanks a lot! > > best regards, > Bjorn > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bandwidth switching per symbol
Hi, I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I need to change the Bandwidth of the used wireless channel on a per symbol basis. I managed to change it on a per packet basis, which can be done on the python level (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same thing, but on a per symbol basis, which (up to my knowledge) is not possible from the python level... Does anyone have an idea how I could do that? (Changing the Bitrate of the USRP after each symbol (e.g. after sending 32 modulated bits (actually chips))) I would be very happy for any help or suggestions! Thanks a lot! best regards, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bandwidth switching per symbol
Hi, I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I need to change the Bandwidth of the used wireless channel on a per symbol basis. I managed to change it on a per packet basis, which can be done on the python level (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same thing, but on a per symbol basis, which (up to my knowledge) is not possible from the python level... Does anyone have an idea how I could do that? (Changing the Bitrate of the USRP after each symbol (e.g. after sending 32 modulated bits (actually chips))) I would be very happy for any help or suggestions! Thanks a lot! best regards, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] E100 UHD Update Issue
On 07/27/2011 12:58 AM, Almohanad Fayez wrote: I'm working with the Rootfs which has DSPLink support ... also I'm bitbaking some custom packages ... can I propagate your updates through OE so I can maintain my current workflow? thanks Josh Not quite yet. I have the modified kernel recipes locally, but haven't pushed them yet. I was hoping to push the kernel change at the same time I update the uhd build, but I suppose I can push the kernel early. Philip al fayez -Original Message- From: Josh Blum To: usrp-users Sent: Wed, Jul 27, 2011 12:45 am Subject: Re: [USRP-users] E100 UHD Update Issue On 07/26/2011 09:43 PM, Almohanad Fayez wrote: I tried to update the UHD on my E100 and I broke something ... here's what I did 1- I followed the UHD download and build instructions for a native UHD compilation on http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-update-the-FPGA-firmware 2- I made sure to "opkg remove --force-depends" all previous UHD packages 3- I downloaded the latest FPGA images "UHD-images-003.002.000.tar.gz" from http://www.ettus.com/downloads/uhd_releases/master_images/ 4- I untared and moved the contents of UHD-images-003.002.000/share/uhd/images to "/usr/local/share/uhd/images/" 5- Ran uhd_find_devices and it worked 6- Ran uhd_usrp_probe and it failed with the following: linux; GNU C++ version 4.5.3 20110223 (prerelease); Boost_104500; UHD_003.002.000-c0764b4 -- Opening device node /dev/usrp_e0... Error: RuntimeError: Expected module compatibility number 0x2, but got 0x1: The module build is not compatible with the host code build. Ahh working perfectly, use these kernel images i put with with the latest fpga images. A new rootfs and all that biz will be posted in a few days http://www.ettus.com/downloads/uhd_releases/master_images/e100_kernel_images/ I understand that this means that the UHD build and FPGA image are incompatible I'm just not sure where the discrepency came from I even deleted the entire contents of the images folder and it still gave me the same error message which i thought is weird since there weren't any FPGA images to begin with ... since I deleted them all. thanks in advance, al fayez ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP for two way ranging
Thank you all. Perphas my idea was not explained very well. The basic assumption is that i can calculate time since i can count samples. If i receive an echo starting from RX sample nr. 12000 and another echo starting from sample nr. 13230, then i can say that the time between two echo is 1230*Ts. The problem was how to time-correlate between the rx stream and the tx stream from USRP. Let’s assume (for clarity) that USRP1 has 64Ms/s ADC and 64 Ms/s DAC. Before starting acquisition&transmission, i pre-fill the tx buffer of the USRP with some dummy samples (preventing underflows) and set rx_sample_counter = 0; tx_sample_counter=1000 (dummy samples). At t=0 i start acquisition&transmission. After Ts, the first incoming sample is sampled and the first rx sample is transmitted. So, i detect an echo starting from sample nr.12000 and i prepare a reply. I prepare the samples for transmission, looking tx_sample_counter and with a simple subtraction i can calculate the time elapsed between the acquisition of sample nr.12000 and the departure of the first sample associated to the reply. It can’t work? From: Kunal Kandekar Sent: Wednesday, July 27, 2011 4:27 AM To: Colby Boyer Cc: Mattia Rizzi ; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP for two way ranging Also, take a look at this brief related discussion from a few weeks ago: http://lists.gnu.org/archive/html/discuss-gnuradio/2011-06/msg00103.html Kunal On Tue, Jul 26, 2011 at 8:49 PM, Colby Boyer wrote: You would need a very very accurate real time guarantee on how long it would take to process/detect an echo, and then to respond to it. To my knowledge the GNURadio framework cannot make that guarantee, in general. I would not try to depend on getting an accurate time for signal processing delay and Linux delay. Look at the UHD driver and see if you can be creative with the driver calls. That is your best bet, honestly. With UHD you can schedule clock accurate transmit bursts and receive bursts. --Colby On Tue, Jul 26, 2011 at 5:33 PM, Mattia Rizzi wrote: The two device are not clock syncronized. My end goal is clock syncroniztation & ranging. The true problem is if it’s possible to compute the time difference between an incoming sample and a outgoing sample from USRP. This is critical since i have to compute the time elapsed (due to calculation & delays from Linux) between the received echo and the outgoing reply. I suggested a method to do this task, can it work? Thanks From: Colby Boyer Sent: Wednesday, July 27, 2011 2:17 AM To: Mattia Rizzi Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP for two way ranging This might be possible to do if both devices have access to the same and very accurate clock, e.g. GPS. What is your end goal? On Tue, Jul 26, 2011 at 3:59 PM, Mattia Rizzi wrote: Hello. I need to implent a two way ranging. A device send an “echo”, a second device discover the “echo” and send a reply, then the first device can calculate the distance. For a correct distance evalutation, the second device must calculate the time elapsed between the discover of the first echo and the reply response. Let’s assume that the second device is a SDR with gnu radio & USRP1 device. The problem is: how to time-correlate the streaming sample received from the USRP and the streaming sample transmitted to the usrp. If i pre-fill the usrp transmit buffer with dummy data (preventing underflows) before starting acquisition&transmission, then i can correlate the two streams, right? (Yes, with the hypothesis that i don’t miss data from usb). Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
