Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
Inlined responses:
Quoting yyzhuang <[EMAIL PROTECTED]>:
Hello,
Hi,
In the BBN 802.11 package, I see the scripts for receiver, and some lines of
code for packet handling as well.
==
def rx_callback(ok, payload):
size = struct.calcsize("@qHBB");
packet_data = payload[size:];
hdr = struct.unpack("@qHbB", payload[0:size]);
if len(packet_data) > 16:
data_hdr = struct.unpack("@BB", packet_data[10:16])
What does the struct.unpack do? Is it for formatting the packet for display?
Pretty much -- though it does more than that as well.
http://docs.python.org/lib/module-struct.html
struct.unpack() is also used by the mainline gnuradio code (see
gnuradio-examples/python/(digital|ofdm)/benchmark_* for instance).
coz when I tried to do this: print "payload: %s" % payload, what got
displayed on the screen is like this:
payload:
That's because the 'payload' string isn't ascii- or unicode-formatted;
it's raw binary data packed into a string because that's how python
handles things that would be stored in a c struct.
If you unpack it with an appropriate format string, you can display
the actual data received. (something close to but less ugly than
struct.unpack('!' + `len(payload)` + 'B',payload)
depending on what you want to see.)
And what exactly the "time" is? As I see in the script, is it in ticks?
means the time instance, or the inter-arrival time?
I'll defer to someone who's familiar with the BBN code.
--Mason
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What's wrong with this constellation?
Howdy list, My partner and I have been working on getting a QAM demodulator working on the gnuradio; the current patch, with lots of debugging spew still present, is located at http://www.cae.wisc.edu/~masond/gr-qam-patch-rev7.diff . The current problem: When the constellation 'locks', it looks like the following: http://www.cae.wisc.edu/~masond/figure3.png (for qam16) http://www.cae.wisc.edu/~masond/figure4.png http://www.cae.wisc.edu/~masond/figure4.png (for qam8) The red Xes are the true constellation points, and the black dots are the output of the receiver. The amplitude of the receiver output seems to spray out pretty widely from the constellation point intended. Any ideas what could be causing this amplitude distortion? I've tried increasing the number of stages in the feedforward AGC to 40 or 60 (as many as my receiver can bear without underruns) and it doesn't seem to impact it. The amplitude noise is present with a variety of mus and costas alphas (the ones used in those figures were alpha~.015 and gain-mu~.05-.075). I've also tried with several different --tx-amplitudes to see if it was a matter of some clipping or other artifact to no luck. I know that for digital radio purposes the constellation doesn't have to be perfect, but rather 'good enough', so I would be inclined to let this go except for point 2: --The receiver frequently cycle-slips, with the longest string of un-slipped packets somewhere in the 2000 range on our USRPs. I think that this is being hurt by the amplitude noise pushing received points into neighboring constellation points and causing the receiver to correct for that. I'm running out of ideas (I've tried only using the corner points as the patch does, using all points with weighting based on distance, weighting only the costas loop portion, weighting only the m&m timing portion...) and could use some suggestions or obvious things I may have overlooked. --Mason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
Quoting "Y. Zhuang" <[EMAIL PROTECTED]>: Thanks very much for help. So "@qHBB" and "@qHbB" actually mean the format that we should unpack this string, right? What is the differences between "@qHBB" and "@qHbB" then? and "@BB"? Thank you Yes. Basically, to summarize the python doc I linked, if you have binary data stored in a string you want to decode, each character in the python format string corresponds to one or more of the bytes in it (with the exception of the @ at the beginning. @ tells the byte order and alignment to use -- the system default in this case). Then q would be a long long, H an unsigned short, and B being an unsigned char. Also, @BB can be written as @6B, and you can construct the formatting strings dynamically if needed (if transmitting a variable length packet). The difference between qHbB and qHBB is that the lowercase b in the middle is signed and the capital B is unsigned. (i.e. is the number stored in two's-complement.) Of course, what that means for the code is up to the coder. --Mason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_rx.py
Quoting Swapna Raj <[EMAIL PROTECTED]>: Hello all, i'm trying to send and receive data using benchmark_tx.py and benchmark_rx.py When i run benchmark_rx.py the rx_callback is not being executed. None og the print statements in the rx_callback is getting being printed. I get the warning failed to enable realtime scheduling. I'm already running both tx and rx in verbose(-v) . That warning isn't critical, and you should be able to receive packets anyway. Run again with --log, and look at the outputted .dat files (either in octave with the instructions on the gnuradio website or using the provided gr_plot_const.py and friends) to see if they look remotely close to what you expect. (compare and contrast with the output of benchmark_loopback.py --log). If nothing is being printed that's usually (for me, at least) a sign that the link between the two radios isn't good enough for anything to make it through. What are the full command lines you're using for each (tx and rx)? --Mason ___ 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
Quoting Johnathan Corgan <[EMAIL PROTECTED]>: We are looking for testers, to measure the difference in performance between the non-GL and GL versions, and in particular, the performance of the GL versions when using a non-accelerated host-based GL implementation like Mesa (without DRI). In particular, the waterfall implementation is a vast improvement over the existing one. Try usrp_fft.py -W to view. Thus far it's a great improvement in apparent response time and update speed. It "feels" faster. (Let me know how you want this quantified and I'll certainly try to do that.) One thing I've noticed, though it may just be this machine: If I resize usrp_fft.py too much, the GUI stops responding to user input, though the data display keeps running. (This is using rev 9293, on Ubuntu Gutsy.) usrp_oscope.py is apparently immune. That said, it's an amazing improvement on the current scope/spectrum analyzer. Thanks, Josh! Indeed, thanks a ton, Josh! --Mason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
