Re: [USRP-users] E310 - Store last leap seconds value from GPS

[Philip Balister via USRP-users]

On 10/11/2018 10:08 AM, David Zamorano Fernández via USRP-users wrote:
> Hi all!
> 
> Each time I turn on the E310 and the GPS is synchronized I have a
> difference of 15 seconds between the GPS time and the UTC time. To have the
> appropriate leap seconds, 18, it is necessary to wait to receive the GPS
> almanac. Is it possible to save this value of leap seconds so that in later
> executions it has the correct time? Whenever I turn on the USRP, even
> though the E310 has been working for hours, I always have this problem.
> 
> Attached is a screenshot of the cgps execution in two USRPs. One has the
> correct time (leap seconds = 18) and the other has the UTC time with three
> more seconds (leap seconds = 15).

So this number is basically a constant until the next leap second? It
seems like ntpd should have a way of knowing, especially when using a
gps time source. I did some quick googling and didn't find an answer,
but it feels like this isn't a unique problem and someone else should
have a solution.

And time has always made my head hurt :)

Philip


> 
> Regards,
> David.
> 
> --
> 
> 
> [image: logo_170x100px.png] 
> 
> 
> 
> David Zamorano Fernández
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
> 
> 
> 
> Ph. (+34) 986 120 430  Ext. 3012
> dzamor...@gradiant.org   |  www.gradiant.org
> 
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales GRD
> Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03] 
>  [image: Iconos Redes Sociales GRD Firma email-04]
> 
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd:

[Marcus D. Leech via USRP-users]

On 10/11/2018 01:03 PM, Mercado, Alejandra via USRP-users wrote:


Dear USRP and GnuRadio folks,

I'm not sure whom to whom I should address this question, since I 
don't know if the problem arises in the GnuRadio code, the drivers, or 
the actual physical USRP.


I was attempting to run an extremely simple GRC graph (attached to 
this email) where the input antenna of the USRP is grounded, the 
signal is taken in with  UHD: USRP Source, then the samples' 
magnitudes are squared, then fed through a moving average (100,000 
points), and then the result is displayed on the screen in dB.


As I altered the sampling rate, I observed a very strange thing: the 
average for the noise readings were, by and large, smoothly increasing 
with the sampling rate, except at certain frequencies (specifically, 
30*2^k, k=0,1,2,3, etc). At these specific sampling rates, the noise 
level would shoot up by about 20 dB.


I'm attaching a graph of the some of the values I got, where the big 
jumps are marked by their respective sampling rates.


Can someone explain why these jumps occur? I'm guessing that when I 
adjust the samp_rate, it selects the front-end filter from a filter 
bank and combines that with decimation. Maybe at certain samp_rates 
(30*2^k, k=0,1,2,3,...) it's right at a threshold edge where the noise 
is worse. Or maybe the problem is entirely at the other end and 
GnuRadio has a bug in its assignment of samp_rate values?


Two attachments included. Comments much appreciated.

Thanks and regards,
Ale



You haven't mentioned *which* USRP you're using.  Some models have 
stricter requirements for sample-rate selection than others.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Fwd:

[Mercado, Alejandra via USRP-users]

Dear USRP and GnuRadio folks,

I'm not sure whom to whom I should address this question, since I don't
know if the problem arises in the GnuRadio code, the drivers, or the actual
physical USRP.

I was attempting to run an extremely simple GRC graph (attached to this
email) where the input antenna of the USRP is grounded, the signal is taken
in with  UHD: USRP Source, then the samples' magnitudes are squared, then
fed through a moving average (100,000 points), and then the result is
displayed on the screen in dB.

As I altered the sampling rate, I observed a very strange thing: the
average for the noise readings were, by and large, smoothly increasing with
the sampling rate, except at certain frequencies (specifically, 30*2^k,
k=0,1,2,3, etc). At these specific sampling rates, the noise level would
shoot up by about 20 dB.

I'm attaching a graph of the some of the values I got, where the big jumps
are marked by their respective sampling rates.

Can someone explain why these jumps occur? I'm guessing that when I adjust
the samp_rate, it selects the front-end filter from a filter bank and
combines that with decimation. Maybe at certain samp_rates (30*2^k,
k=0,1,2,3,...) it's right at a threshold edge where the noise is worse. Or
maybe the problem is entirely at the other end and GnuRadio has a bug in
its assignment of samp_rate values?

Two attachments included. Comments much appreciated.

Thanks and regards,
Ale


noise_level_unexpected.grc
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] weird sample values when receiving on b200

[Mitch Grabner via USRP-users]

I'm doing a loopback to check which sample a certain signal level is found.
I'm transmitting in the main thread and I create a receiver thread to look
for the rise in the input signal. Here is my receiver worker

void receive_worker(
  uhd::usrp::multi_usrp::sptr usrp,
  std::vector > rx_buff,
  uhd::rx_streamer::sptr rx_stream,
  size_t total_num_rx_samps,
  double time_to_receive,
  std::queue* edge_queue,
  bool* stop_receive
){
  io_mutex.lock();
  std::cout << boost::format("Receive thread started!") << std::endl;
  io_mutex.unlock();

  //set buffers same for all channels (if more than 1)
  std::vector *>
rx_buffs(rx_stream->get_num_channels(), _buff.front());

  //setup streaming
  uhd::stream_cmd_t stream_cmd((total_num_rx_samps == 0)?
uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
  );

  io_mutex.lock();
  // if we are looking for a finite set of samples
  if (total_num_rx_samps > 0){
std::cout << boost::format(
"Begin streaming in for %u samples starting at %0.9f device time"
) % total_num_rx_samps % time_to_receive << std::endl;
  }
  else{
std::cout << boost::format(
"Begin streaming in continuous samples starting at %0.9f device
time"
) % time_to_receive << std::endl;
  }
  io_mutex.unlock();

  //set up the RX command
  stream_cmd.num_samps = total_num_rx_samps;
  stream_cmd.stream_now = false;
  stream_cmd.time_spec = uhd::time_spec_t(time_to_receive);
  rx_stream->issue_stream_cmd(stream_cmd);

  //meta-data will be filled in by recv()
  uhd::rx_metadata_t rx_md;

  double rx_timeout = time_to_receive + 0.1;
  size_t num_acc_samps = 0;
  /* - Main While Loop --- */
  while(not *stop_receive and (num_acc_samps < total_num_rx_samps or
total_num_rx_samps == 0)){
//rece  ive a single full otw packet
size_t num_rx_samps = rx_stream->recv(
  rx_buffs, rx_buff.size(), rx_md, rx_timeout, true
);
rx_timeout = 0.1f; //small timeout for subsequent recv

//error handling
if (rx_md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
  io_mutex.lock();
  std::cout << boost::format(
"Receiver Error %s ... Shutting down!"
  ) % rx_md.strerror() << std::endl;
  io_mutex.unlock();
  //set stop receive signal
  *stop_receive = true;
}

//look for a single rising edge
edge_offset_calc(rx_buff, num_acc_samps, edge_queue);


//keep track of absolute sample number
num_acc_samps += num_rx_samps;

//if we were streaming continuously, send a stop command
if (*stop_receive and total_num_rx_samps == 0){
  // Shut down receiver
  std::cout << boost::format("Sending stop command...") << std::endl;
  stream_cmd.stream_mode =
uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
  rx_stream->issue_stream_cmd(stream_cmd);
}
  }//RX while

  boost::this_thread::sleep(boost::posix_time::seconds(0.2)); //wait

  io_mutex.lock();
  std::cout << boost::format("Receive thread ended!") << std::endl;
  io_mutex.unlock();
}

I create the rx thread with:

//edge queue
  std::queue edge_queue;
  bool stop_receive = false;

  //start the thread
  boost::thread_group transmit_thread;
  transmit_thread.create_thread(
boost::bind(
  _worker, usrp, rx_buff, rx_stream, total_num_rx_samps,
  time_to_receive, _queue, _receive
)
  );

the edge calc function simply iterates through the vector and pushes the
sample location of the rise in signal level (2-norm of the complex float)
to the queue. When debugging I sometimes get this kind of output after
starting up the device

Setting device timestamp to 0...
Transmitting 50 samples at 0.2 device time
Receive thread started!
Begin streaming in for 40 samples starting at 0.19000 device time
Transmit burst success!
max is 0.358725
Edge found on sample 200164 packet offset of 164
max is 2.0942e+34
Edge found on sample 242000 packet offset of 2000
max is 2.0942e+34
Edge found on sample 244000 packet offset of 2000
max is 2.0943e+34
Edge found on sample 254000 packet offset of 2000
max is inf
Edge found on sample 262000 packet offset of 2000
max is inf
Edge found on sample 264000 packet offset of 2000
max is 2.09449e+34
Edge found on sample 272000 packet offset of 2000
max is 2.09449e+34
Edge found on sample 274000 packet offset of 2000
Receive thread ended!

My spp is forced to 2000 using the stream args. and This is on UHD 3.010.03.

thanks for the help.

On Wed, Oct 10, 2018 at 5:07 PM Michael Dickens 
wrote:

> Hi Mitch - Can you provide your code for us to review, to get an idea of
> what you're doing that's causing this issue for you? Without specific
> code, debugging is a little difficult ... And, no, I haven't seen this
> issue to the best of my knowledge / understanding of what it might be.
> Cheers! - MLD
>
> On Wed, Oct 10, 2018, at 4:03 PM, Mitch Grabner via USRP-users wrote:
>
> Hello,
>
> I find that sometimes when I initialize a b200 and 

[USRP-users] source and run rfnoc on boot on E310

[Jason Matusiak via USRP-users]

I have a problem that I thought I solved a year or two back, but I can't seem 
to find it in my notes anywhere.
 
I have a GR app that I want to run on boot on an E310, I know how to do that 
for straight GR.  The problem is that it is an RFNoC GR app, so I need to 
source the cross-compiled tools in my home directory.  I can't seem to get that 
to work and I think it is because when it gets sourced automatically the 
process doesn't have the new environment.  I got it to kind of work once, but 
it wouldn't kick off until I logged in first (which is a non-starter).
 
Any ideas where to throw a script to make this happen?
 
Thanks.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com