On Fri, 2016-03-25 at 22:14 +, Landsman, Arik wrote:
> Hi Andy,
>
> I gave it a few more touches since we last spoke, but to no avail...
> Costas still flips sporadically on a simulated channel.
>
> Generally the corr_est block would show a large spike in |corr|^2 on
> the very first packet
On Fri, 2016-03-25 at 11:07 -0600, Tom Golden wrote:
> AX.25 data is NRZI encoded (so inverse bits and then NRZ). I hand
> calculated the HDLC frame start byte and first few address bytes so
> the corr_est only triggers at the start of the packet.
I've added NRZI decoding and encoding and adjus
Hi Andy,
I gave it a few more touches since we last spoke, but to no avail... Costas
still flips sporadically on a simulated channel.
Generally the corr_est block would show a large spike in |corr|^2 on the very
first packet I send (>1600), but on all subsequent loops (same packet) the
value
Yes. It is indeed the way to go about things. Works much more smoothly and
quite a bit faster as well. Thanks.
On Fri, Mar 25, 2016 at 11:26 AM, Kevin Reid wrote:
> On Mar 25, 2016, at 7:53, M. Ranganathan wrote:
>
> > Kevin,
> >
> > Thanks for the answer. My setup is a little more complicated
AX.25 data is NRZI encoded (so inverse bits and then NRZ). I hand
calculated the HDLC frame start byte and first few address bytes so the
corr_est only triggers at the start of the packet. Seems to trigger but I
had to lower the threshold down to .390.
I have a separate program I'm using to chec
Hi fellows,
I am currently experimenting with gnuradio and rtl-sdr osmosdr etc.
When I start germgsm_livemon respectively grgsm_scanner the scripts break with a
Runtime Error
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 3537,
in primitive_msg_connect
return _ru
On Fri, 2016-03-25 at 12:22 -0400, Andy Walls wrote:
> On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> FWIW, I couldn't get the attached flowgraph (which looks to correlate to
> the HDLC flag) to crash. I was probably just lucky.
I forgot to mention, in the flowgra
On Fri, 2016-03-25 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> I do have that fix in place. I added the tag_debug for time_est. I'm
> not
> sure which value causes the error, but I see:
>
> thread[thread-per-block[17]: ]:
> mmse_fir_interpolator_cc: imu out of bounds.
>
>
> ---
Jacob,
This is a gr-uhd issue (not UHD) if it is what I think it is, so the uhd
version is probably immaterial. Which gnu radio version are you running?
M
On 25 Mar 2016 07:53, "Jacob Gilbert" wrote:
> I have tried it two ways:
>
> 1) calling stop() wait() on the top_block
> 2) having a block r
Hi Martin,
Thanks for your comments. As mentioned in proposal core deliverable is a
user friendly GUI that allow users to perform operations mentioned in
section 4 of the proposal. Please see following link for the GUI:
http://imgur.com/57VXo5T
Its definitely not final/complete. I'll target pyqt
On Mar 25, 2016, at 7:53, M. Ranganathan wrote:
> Kevin,
>
> Thanks for the answer. My setup is a little more complicated than that. The
> sensor reads its configuration from the server. The server could reconfigure
> the sensor between restarts.
>
> I did try stopping the task graph and rest
I do have that fix in place. I added the tag_debug for time_est. I'm not
sure which value causes the error, but I see:
--
Tag Debug: corr_est
Input Stream: 00
Offset: 37840 Source: corr_est_cc0 Key: time_est Value: 0.3
Kevin,
Thanks for the answer. My setup is a little more complicated than that. The
sensor reads its configuration from the server. The server could
reconfigure the sensor between restarts.
I did try stopping the task graph and restarting but the problem is
unresolved. I tried ulocking but I get t
I have tried it two ways:
1) calling stop() wait() on the top_block
2) having a block return WORK_DONE to the scheduler to stop the flowgraph
Both ways result in segfaults. I'll try calling stop() on the USRP block
directly. I am currently running the 3.9.2 release but will update when I
get a ch
Hi,
I have tried to get better performance(throughput & error rate) in OFDM
packet transceiver.
I tested TxRx experiments in variety environments (modulation, frequency,
bandwidth, fft_length, occupied_carriers, gain level, packet size and etc.)
As a result, I got a poor performance and I found
15 matches
Mail list logo
