Ulrika, The rx_handler thing is if its implemented to create a seperate stream of timestamps in python (i.e gr-usrp2) rather than C++ - I ran into the problem due to not fully understanding the code/checking base classes before I modified it, it shouldnt be an issue with pure C++ or if you dont bother incrementing the timestamp for each sample in a packet.
I think they are the same size, but contain x samples. I'd ignore that bit I was confusing myself I think :) Its been ages since I double checked stuff with wireshark/print statements though so i might be wrong on whether they can vary. Cheers, Tim 2010/2/19 Ulrika Uppman <ulrika.upp...@foi.se> > Tim, > thanks for your reply. > > I thought the packets always had the same size (specified by > U2_MAX_SAMPLES), or am I wrong here? I also do get the very same timestamp > diff when running rx_streaming_samples with N= 400, 4000, 6000, 60000 etc. > > I don't quite follow you on what will happen when calling the handler > multiple times? I print the timestamps in usrp2_impl handle_data_packet > which I thought would be run every time (once) a new ethernet packet arrives > which isn't a control packet? > > (And yes the timestamps are treated as uint32's.) > > Regards, > /Ulrika > > ------------------------------ > *From:* Tim Pearce [mailto:timothy.pea...@gmail.com] > *Sent:* Thursday, February 18, 2010 9:35 PM > *To:* Ulrika Uppman > *Cc:* Discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] Timestamp value > > Ulrika, > > I agree with how you think the timestamps are generated -- it seems to work > for me that way anyway! > > I did it with a custom source block that added the counter*decimation rate > after the first sample, the trap I fell into there is that (particuarly at > lower decimation rates) rx_*_handler() can be called multiple times per > instance of it. > > Are the timestamps being treated as UINT32's? > > 400 samples is quite low, I think the packets are usually bigger than that > (I might be wrong, its been a while since I looked into that). > > Cheers, > > Tim > > On Thu, Feb 18, 2010 at 4:10 PM, Ulrika Uppman <ulrika.upp...@foi.se>wrote: > >> Hi, >> I wonder how the timestamps are being generated for each ethernet-packet >> sent from the USRP2 to the host? My initial idea about how it works was that >> timestamps are generated at 100MHz (same as the samples) and then the >> timestamp associated with the first sample in an ethernet data packet will >> be put in the metadata which could then be unpacked in the host. I then >> would assume that the next packet after the first one will have a timestamp >> value that is proportional to the number of samples per packet times the >> decimation rate. However I get timestamp values that increase much much more >> for each received packet, so I wonder if my idea of how timestamps are >> generated is wrong? >> >> I run the stable 3.2 version of gnuradio on Ubuntu 9.04 and I have an >> USRP2 with the RFX2400. (I also was going to try the gnuradio trunk but I >> got problems with building, see my other post "Error on make from git >> development trunk"). I tried both an old version of the fpga bin-file and >> one that I just recently downloaded (but both gave the same result). >> >> I put some printouts in usrp2_impl.cc in the handle_data_packet function >> and the output when I run rx_streaming_samples then looks like this: >> ./rx_streaming_samples -f 2457e6 -d 16 -N 400 -v >> >> ................................................................................... >> Daughterboard configuration: >> baseband_freq=2456250000.000000 >> ddc_freq=-750000.000000 >> residual_freq=-0.016764 >> inverted=no >> >> USRP2 using decimation rate of 16 >> Receiving 400 samples >> >> ts_in = 1435221596, ts_last = 0, diff = 1435221596 >> ts_in = 2560802396, ts_last = 1435221596, diff = 1125580800 >> ts_in = 3367616092, ts_last = 2560802396, diff = 806813696 >> ts_in = 4174429788, ts_last = 3367616092, diff = 806813696 >> ts_in = 686341724, ts_last = 4174429788, diff = 806879232 >> ts_in = 1493155420, ts_last = 686341724, diff = 806813696 >> ts_in = 2283192156, ts_last = 1493155420, diff = 790036736 >> ts_in = 3090005852, ts_last = 2283192156, diff = 806813696 >> ts_in = 3896819548, ts_last = 3090005852, diff = 806813696 >> ts_in = 408731484, ts_last = 3896819548, diff = 806879232 >> >> Copy handler called 2 times. >> Copy handler called with 2968 bytes. >> >> Elapsed time was 0.000 seconds. >> Packet rate was 100000 pkts/sec. >> Approximate throughput was 148.40 MB/sec. >> Total instances of overruns was 0. >> Total missing frames was 0. >> >> ................................................................................... >> >> ts_in is the timestamp found in the metadata of the packet just received, >> ts_last is the one from previous packet and diff is just the difference them >> between. Since there seems to be no missing frames I'm guessing the big >> value of diff can't be related to lost packets? >> If I try different decimation rates, I see no obvious relation between the >> difference in value between two timestamps... >> >> Do anyone know why the difference in timestamp value between received >> packets is so big? What am I missing here? >> >> Thanks, >> /Ulrika >> >> _______________________________________________ >> 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
