Hi, can u help me?
I want to know which are the step and the file to recompile after a changing
in .cc code....After add the printf code in .cc what have u done?
I have to modify a .cc code to use this modification in a py script as a new
method....but i don't get on with the job....
Thanks,
Domenico
zzw.1012 wrote:
>
> Hi, Thomas
> thanks for your help ! you are right!
> I add printf code in the function of usrp_basic.cc like this:
> int usrp_basic_tx::write(const void *buf, int len, bool *underrun)
> {
> ...
> printf ("len = %d\n", len);
> if (len < 0 || (len % 512) != 0)
> {
> fprintf(stderr, "usrp_basic_tx::write: invalid length= %d\n", len);
> }
> }
> then I run the example of benchmark_tx.py :
> ./benchmark_tx.py -f 2500M -s 1500 -M 0.001
> it really send 194560 bytes = 190k for the default case using 4 samples
> per symbol and it send 380k with -M 0.002.
> but , I still have some question. first , after making packet with 1520
> bytes, then whether is it going on gmsk(default) modulation? I think the
> 1520-bytes packet changes to 190kbytes occur in the process of gmsk. Is it
> right? how to calculate the number from 1520 to 194560?
> second, in the process of sending packet, the printf information as
> follow:
> (./benchmark_tx.py -f 2500M -s 1500 -M 0.001)
> len = 16384
> len = 15872
> len = 16384
> len = 16384
> len = 16384
> len = 15872
> len = 16384
> len = 512
> len = 16384
> len = 16384
> len = 16384
> len = 16384
> len = 14848
> Is there have some discipline in sending data? I find it seems unorderly.
>
> thank you again
>
> best wishes
>
>
>>
>> On Sun, May 9, 2010 at 11:28 PM, zzw.1012 <zzw.1...@163.com> wrote:
>> > Hi,
>> > I'm studying benchmark_tx.py now. I find that the packet size is
>> not
>> > right (at least I'd like to think so) in the process of making packet,
>> which
>> > can be seen in pkt.py and packet_utils.py. In the packet consist of 2
>> bytes
>> > packed_preamble, 8 bytes packed_access_code, 4 bytes header, 4 bytes
>> > outband_crc with default 1500 bytes size, padding bytes and
>> endbyte"\x55" .
>> > I use default gmsk modulatiom. So, the packet have 2 + 8 + 4 + 1504 + 1
>> + 1
>> > = 1520bytes.
>> > However, in the function of _npadding_bytes(pkt_bytes_len,
>> > samples_per_symbol, bits_per_symbol) , there have such description:
>> > "generate sufficient padding such that each packet ultimately ends up
>> being
>> > a multiple of 512 bytes when sent across the USB, we send 4-byte
>> samples
>> > across the USB (16-bit I and 16-bit Q), thus we want to pad so that
>> after
>> > modulation the resulting packet is a multiple of 128 samples". Also ,
>> in the
>> > function "int usrp_basic_tx::write(const void *buf, int len, bool
>> > *underrun)"in the usrp_basic.cc, there have similar code like "if (len
>> < 0
>> > || (len % 512) != 0){fprintf(stderr, "usrp_basic_tx::write: invalid
>> length
>> > = %d\n", len}".
>> > they both tell me that the data across the USB must be a multiple
>> of 512
>> > bytes .but in the example of benchmark_tx.py, the packet size is 1520
>> > bytes. what's wrong ?
>>
>> 1520 bytes only refers to the packet size. The transmitted sample
>> stream at the physical layer includes a number of other factors
>> including conversion to bits, samples per symbol, and sample size. So
>> for the default case, a 1520 byte packet using 4 samples per symbol
>> yields 48640 samples or 194560 bytes, which is a multiple of 512.
>>
>> Thomas
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://old.nabble.com/PACKET-FORMAT-%22error%22-tp28507552p28547711.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
