Re: [Discuss-gnuradio] Clock rate change on x300

2019-10-11 Thread Martin Braun
A bit late here, but the X300 can now (at least on master) also do all the other clock rates in between 184.32 and 200 Msps. On Tue, Aug 6, 2019 at 11:56 AM Derek Kozel wrote: > Hi Paul, > > What rate do you want to adjust it to and for what purpose? The X300 > supports a master clock rate of

Re: [Discuss-gnuradio] Clock rate change on x300

2019-08-07 Thread Derek Kozel
g Technician IV >> paul.mitch...@testllc.com >> 256.716.9056 (Work) >> 256.289.3581 (Cell) >> >> From: Marcus Müller >> Sent: Wednesday, August 7, 2019 9:27 AM >> To: Mitchell, Paul; Derek Kozel; discuss-gnuradio@gnu.org >> Cc: usrp-users >> Sub

Re: [Discuss-gnuradio] Clock rate change on x300

2019-08-07 Thread Marcus Müller
mitch...@testllc.com > 256.716.9056 (Work) > 256.289.3581 (Cell) > > From: Marcus Müller > Sent: Wednesday, August 7, 2019 9:27 AM > To: Mitchell, Paul; Derek Kozel; discuss-gnuradio@gnu.org > Cc: usrp-users > Subject: Re: [Discuss-gnuradio] Clock rate change on x300 > > D

Re: [Discuss-gnuradio] Clock rate change on x300

2019-08-07 Thread Mitchell, Paul
.@testllc.com > 256.716.9056 (Work) > 256.289.3581 (Cell) > > From: Derek Kozel > Sent: Tuesday, August 6, 2019 1:56 PM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Clock rate change on x300 > > Hi Paul, > > What rate do you want to adjust it to and f

Re: [Discuss-gnuradio] Clock rate change on x300

2019-08-07 Thread Marcus Müller
ll) > > From: Derek Kozel > Sent: Tuesday, August 6, 2019 1:56 PM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Clock rate change on x300 > > Hi Paul, > > What rate do you want to adjust it to and for what purpose? The X300 > supports a master

Re: [Discuss-gnuradio] Clock rate change on x300

2019-08-07 Thread Mitchell, Paul
...@testllc.com<mailto:paul.mitch...@testllc.com> 256.716.9056 (Work) 256.289.3581 (Cell) From: Derek Kozel<mailto:de...@bitstovolts.com> Sent: Tuesday, August 6, 2019 1:56 PM To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Clock r

Re: [Discuss-gnuradio] Clock rate change on x300

2019-08-06 Thread Derek Kozel
Hi Paul, What rate do you want to adjust it to and for what purpose? The X300 supports a master clock rate of 200 MS/s and 184.32 MS/s. The built in DSP can convert to an integer divisor sample rate of one of those two. Adding support for another rate would require either a lot of software work

[Discuss-gnuradio] Clock rate change on x300

2019-08-06 Thread Mitchell, Paul
I need to adjust the clock rate on a USRP x300. Is there a simple way to do this or do I need to use Vivado to access the FPGA image somehow? I am using Linux for everything. Paul Mitchell Engineering Technician IV paul.mitch...@testllc.com 256.716.9056 (Work) 256.289.3581 (Cell)

Re: [Discuss-gnuradio] Clock recovery without change of phase

2017-06-22 Thread Marcus Müller
Hi George, isn't the job of a clock recovery actually to *change* the phase of your signal so that its original clocking is recovered? I'm a bit confused; could you maybe elaborate on what you want to do (what for/why/what specific output are you looking for)? Are you maybe looking for the clock

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

2017-06-15 Thread Andy Walls
Hi Phil: > Date: Thu, 15 Jun 2017 12:57:54 + > From: Phil Frost: > I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK > where the pulses are a raised cosine (impulse, not frequency domain) twice > the symbol duration[2], no error correction, at 31.25 baud. The

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

2017-06-15 Thread GhostOp14
I had messed with psk31 a while back. There's a gnuradio module to decode and some example GRC's to send and receive that I had used here: https://github.com/tkuester/gr-psk31 that may help you out. The flowgraphs in the examples directory already have all the blocks set up to receive. On

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

2017-06-15 Thread Phil Frost
Do you mean the equalization would be performed with another linear filter? matched filter -> equalizing filter -> clock recovery -> [...] Wouldn't that be equivalent of convolving the input responses of the two cascaded FIRs, with the net result being an unmatched filter? Existing

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

2017-06-15 Thread Federico 'Larroca' La Rocca
Hi, Nice problem you got there. In any case, have you considered performing matched filtering (thus maximizing SNR), outputting more than one sample per symbol (in fact, without decimation at all), then equalize (so that the signal looks as if it was sent and received with a squared-root Nyquist

[Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

2017-06-15 Thread Phil Frost
I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK where the pulses are a raised cosine (impulse, not frequency domain) twice the symbol duration[2], no error correction, at 31.25 baud. The transmitted signal has no ISI, but after matched filtering it does: [image:

Re: [Discuss-gnuradio] Clock recovery without change of phase

2017-06-14 Thread Federico 'Larroca' La Rocca
Hi, I'm not sure if I understood correctly your question, but clock recovery (such as MM or Polyphase clock sync) takes the incoming signal and by default outputs a sample every $T_s$ seconds (symbol time) but at the point where the eye is widest (and thus it interpolates as needed). Once it

[Discuss-gnuradio] Clock recovery without change of phase

2017-06-14 Thread George Vardakis
Hi all, I need to perform clock recovery on a signal without constantly changing its phase. I think that the clock recovery block in Gnuradio does exactly that in order to maximize the energy of the signal. Is there any other way that does not tamper with the signal phase? Thanks!

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-31 Thread Marcus Müller
Hi Tom, why do/I/ have to advertise the PFB approach? Arguing against Mueller Müller feels strange. Anyway: Mueller Müller in the classical, real valued approach [1, eq (49), p. 524] in its core is eqn. (49) page 524 with $z_k$ being the timing estimate ,$x_k$ being the input samples, and

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-31 Thread Marcus Müller
Hi Klauss, is it new ? Not really, no. It's been around since ca April 2012. If there's no Polyphase Clock Sync: What version of GNU Radio are you using? Best regards, Marcus PS: I always recommend not using ruby-forum but directly signing up to the mailing list:

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-31 Thread Klauss Wolfeinstein
Wow ! Thank you all for your reply. Very interesting ! Tom, I didn't find the pfb_clock_recovery block in my GNU Radio Companion, is it new ? Best regards. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-31 Thread Klauss Wolfeinstein
Hi Marcus, A it's the Polyphase Clock Sync, I didn't think about it ... :-D Thank you for the advice, I will use the mailing list next time. Best regards. Klauss. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Francisco Albani
From Matlab MM documentation [1]: [...] Typically, the input signal is the output of a receive filter that is matched to the transmitting pulse shape. [...] Assuming the MM Gnuradio implementation has the same hypothesis on the input signal (anybody can confirm this?), I deduced this block is

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Tom Rondeau
On Thu, Jul 30, 2015 at 3:03 PM, Iluta V iluta2...@gmail.com wrote: Hi, Tom, Could you be more specific where exactly it is not the right algorithm? We'd appreciate that and would correct that in own work as well, if Security Research Assessment made a mistake here. I will be looking

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Martin Braun
Klaus, the manual page for this block has a paper reference in it: http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details M On 30.07.2015 10:16, Klauss Wolfeinstein wrote: Hello, I would like to find a proper documentation on MM algorithm block (paper

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Daniel Camara
Hi Klauss, You could also take a look at https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/, it helped me quite a bit! Best regards... Daniel On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com wrote: Klaus, the manual page for this block

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Tom Rondeau
Another point to keep in mind is that the MM block isn't great in fading environments. It's really suboptimal in general. Look at the pfb_clock_recovery block, instead. Tom On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com wrote: Hi Klauss, You could also take a look at

[Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Klauss Wolfeinstein
Hello, I would like to find a proper documentation on MM algorithm block (paper for example). Any ideas ? Thank you. Regards. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Iluta V
Thanks for your explanation! That's worth while looking into! On Fri, Jul 31, 2015 at 1:17 AM, Francisco Albani francisco.alb...@gmail.com wrote: From Matlab MM documentation [1]: [...] Typically, the input signal is the output of a receive filter that is matched to the transmitting pulse

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Tom Rondeau
On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com wrote: Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of Using GNU Radio Companion for Security Research and Assessment) deals with Clock Recovery MM, I attached the paper, have a look at: 6.Section 6.Counting

Re: [Discuss-gnuradio] Clock Recovery MM documentation

2015-07-30 Thread Iluta V
Hi, Tom, Could you be more specific where exactly it is not the right algorithm? We'd appreciate that and would correct that in own work as well, if Security Research Assessment made a mistake here. I will be looking forward to your response, Iluta On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau

Re: [Discuss-gnuradio] Clock Recovery MM

2014-09-09 Thread Tom Rondeau
On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org wrote: Hi all, looking at the clock recovery MM code, I wonder if d_omega_relative_limit is a relative or absolute deviation from d_omega. Here it looks like absolute

Re: [Discuss-gnuradio] Clock Recovery MM

2014-09-09 Thread Bastian Bloessl
On 09 Sep 2014, at 15:42, Tom Rondeau t...@trondeau.com wrote: On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org wrote: Hi all, looking at the clock recovery MM code, I wonder if d_omega_relative_limit is a relative or absolute deviation from d_omega. Here it looks

[Discuss-gnuradio] Clock Recovery MM

2014-09-08 Thread Bastian Bloessl
Hi all, looking at the clock recovery MM code, I wonder if d_omega_relative_limit is a relative or absolute deviation from d_omega. Here it looks like absolute https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107 Here it is relative

Re: [Discuss-gnuradio] Clock synchronization B210

2014-08-29 Thread Martin Braun
On 08/29/2014 12:02 AM, Sharath Ananth wrote: Hello all, I am using the B210 without an external 10MHz clock and without a GPSDO mounted. As expected I see a frequency and sampling time error on the captured samples. Once this sampling time error is estimated, I would like to remove this

[Discuss-gnuradio] Clock synchronization B210

2014-08-28 Thread Sharath Ananth
Hello all, I am using the B210 without an external 10MHz clock and without a GPSDO mounted. As expected I see a frequency and sampling time error on the captured samples. Once this sampling time error is estimated, I would like to remove this in hardware by changing the sampling clock by a

[Discuss-gnuradio] Clock block slow in position satellite calculation

2014-06-10 Thread caruiz.ext
Hello, I have this flowgraph in GNURadio: http://i1281.photobucket.com/albums/a515/Carlos_Alberto_Ruiz_Naranjo/esque_zpsd89166da.png - Green: calculates the signal delay of a satellite. - Yellow: a clock with a second precision. If I run the clock separately I can see in the WX GUI Number

Re: [Discuss-gnuradio] Clock block slow in position satellite calculation

2014-06-10 Thread Marcus Müller
Hi! You shouldn't use so many throttles in one flow graph; throttle limits the number of samples going through in a given time, and as soon as the upstream blocks have filled their output buffer, they will be limited in throughput, too. So I guess this is the effect of throttles blocking each

Re: [Discuss-gnuradio] Clock block slow in position satellite calculation

2014-06-10 Thread caruiz.ext
Hi! RetardoSat: 1.Come three samples (method work) - X: X position of receiver. - Y: Y position of receiver. - Z: Z position of receiver. - ClK: seconds. 2. With Kepler paremeters calculates the satellite position, the distance between the

[Discuss-gnuradio] Clock recovery in HRPT receiver

2014-04-07 Thread Pablo Fernández Alonso
Hi, I am checking the HRPT receiver available in gr-noaa repository and I don't understand the parameters of the Clock Recovery block with the information available about the HRPT format. I roughly know how that block works, but Ineedmore information. Thank you in advance. Pablo Fernandez.

Re: [Discuss-gnuradio] Clock recovery in HRPT receiver

2014-04-07 Thread Tom Rondeau
On Mon, Apr 7, 2014 at 9:41 AM, Pablo Fernández Alonso pfernandezalons...@gmail.com wrote: Hi, I am checking the HRPT receiver available in gr-noaa repository and I don't understand the parameters of the Clock Recovery block with the information available about the HRPT format. I roughly

[Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Jay Prakash
how can we set the time of usrp by sending it message. I know there are function to (usrp.set_time_now()) do this from from top block variable but can this be done by sending message at usrp port . We can give internal reference signal of 10MHz but is there also a way to give pps signal

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread John Malsbury
The GPSDO can provide an internal 10 MHz/1 PPS signal. I'm not sure if that's what you meant or not: https://www.ettus.com/product/details/GPSDO-KIT AFIAK, you cannot set the time of a USRP with a message. You may be able to use the XML_RPC block in gr-extras to call the function if it is

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Jay Prakash
thanks for the clarification so i checked the new grextras wiki it has uhd_control block i guess that can be used for this job. Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Adeel Anwar
so i checked the new grextras wiki it has uhd_control block i guess that can be used for this job. uhd_control block supports only a subset of usrp-functions (exposed through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT currently it doesn't support set_time_now()

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Jay Prakash
so do we have any other block to do that. I did'nt find XML_RPC block in the new gr-extras Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/ http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top On Sun, Jun

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread John Malsbury
XML_RPC block in the new gr-extras XML_RPC would have been subject to the same limitations. It could only call set_time_next_pps if set_time_next_pps was in the uhd_sink/source blocks. Maybe you can update them to include the function. Let me ask a more fundamental questions - why do you want

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Jay Prakash
I think i can use set_command_time (which i guess set the next time of transmission/command?). how can i make the usrp send its time when configured for synchronization? Jay Prakash Senior Undergraduate Electronics Engineering IIT (BHU) VARANASI +91-9559475258 http://about.me/jay.prakash/

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread John Malsbury
how can i make the usrp send its time when configured for synchronization? I might be misunderstanding the question, but here's an answer. The USRP source outputs stream tags on the first sample when streaming. The three tags are 1) rx_time 2) rx_rate 3) frequency. Using (1) and (2), you

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Jay Prakash
I went through the stream tagging pdf. The tags from source has time,freq and rate. I am interested in insuring that transmitter sets a particular frequency of transmission ie Tx_Next_freq and time at which the transmitter starts sending data packets at an instance. The set_command_time as you

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Josh Blum
On 06/16/2013 02:13 PM, Adeel Anwar wrote: so i checked the new grextras wiki it has uhd_control block i guess that can be used for this job. uhd_control block supports only a subset of usrp-functions (exposed through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT currently it

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Josh Blum
On 06/16/2013 10:44 PM, Josh Blum wrote: On 06/16/2013 02:13 PM, Adeel Anwar wrote: so i checked the new grextras wiki it has uhd_control block i guess that can be used for this job. uhd_control block supports only a subset of usrp-functions (exposed through gr-uhd) e.g.

Re: [Discuss-gnuradio] clock synchronization by message passing

2013-06-16 Thread Adeel Anwar
Josh, I didnt add every possible setting. But I am happy to add more on request! I'm gathering that someone would like to make a configuration and control block that could perform the synchronization tasks w/ a GPSDO or some external clock and time source. I think it will also be very useful to

[Discuss-gnuradio] Clock Sync Problems + Timestamp question

2009-10-20 Thread Tim Pearce
Hi, I've been trying to get two USRP2's with their clocks both synced to a 10MHz reference (for now the same reference from the back of some test equipment) - to do this I'm using the following code: in_pipe1=usrp2.source_32fc('eth0') in_pipe2=usrp2.source_32fc('eth2')

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

2009-10-20 Thread Matt Ettus
Tim Pearce wrote: Hi, I've been trying to get two USRP2's with their clocks both synced to a 10MHz reference (for now the same reference from the back of some test equipment) - to do this I'm using the following code: in_pipe1=usrp2.source_32fc('eth0')

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

2009-10-20 Thread Douglas Geiger
On Tue, Oct 20, 2009 at 12:20 PM, Tim Pearce timothy.pea...@gmail.com wrote: I'm also trying to attach the timestamp data do each sample -- as far as I can tell this is sent to give the sample timestamp for the first sample in each ethernet frame (then incremented by 1 for each subsequent

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

2009-10-20 Thread Tim Pearce
There is no frequency which can be received by both the BasicRX and the DBSRX. What frequency are you putting in? What frequency are you telling the USRP2s to tune to? Matt Hi, Sorry I probably confused things by mentioning the BasicRX DBSRX is the only receiver we have 2 of at the

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

2009-10-20 Thread Matt Ettus
Tim Pearce wrote: There is no frequency which can be received by both the BasicRX and the DBSRX. What frequency are you putting in? What frequency are you telling the USRP2s to tune to? Matt Hi, Sorry I probably confused things by mentioning the BasicRX DBSRX is the

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

2009-10-20 Thread Tim Pearce
Ah! The 10MHz was coming out the back of the siggen so would have been locked to the same reference. Thanks for your help Doug/Matt -- next time I'll stop and think through my test setup! Cheers, Tim On Tue, Oct 20, 2009 at 6:16 PM, Matt Ettus m...@ettus.com wrote: Tim Pearce wrote:

[Discuss-gnuradio] Clock input level

2007-10-04 Thread Juha Vierinen
Hi, What is the voltage level for the USRP external clock? Is 1V peak to peak ok? I am planning to drive the board using a high accuracy reference clock. juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org

[Discuss-gnuradio] clock

2007-07-19 Thread Zhuocheng Yang
Hello: Does anyone know the clock speed of master_clk, serial_clk and tx_clk? Which one is fastest and which one is slowest? Leo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock Recovery

2007-04-03 Thread pilla
Hi, I'm an Italian student and I'm searching for documents concerning Mueller Muller clock recovery method used from gnuradio. Thanks a lot This message was sent using IMP, the Internet Messaging Program.