That fixed it!!
Nick & Andy - thank you both so much for looking into it. Without your help,
there is no way I would have fixed this… and without Nick’s code I couldn’t
have built it in the first place.
- Luke
> On Nov 4, 2014, at 8:28 PM, Nick Foster wrote:
>
> Red face over here.
>
> The
This is awesome! I just pulled master and I am recompiling it right now. Thanks
you both so much for the help.
I clearly still have some tuning work to do either way, but it would be great
to get move up to 3.7. I will let you know if this clears it up. I have my
fingers crossed that it will.
Red face over here.
There was a bug in correlate_access_code_tag -- which only gr-smartnet and
gr-ais use, so far as I know. The fix was pulled into master a couple of
days ago. This could explain the discrepancy you're seeing in the preamble
mark.
Pull latest GR master, build, and see if it fixe
Thanks Andy! Good catch - I made the changes you suggested. I was just doing a
simple back of the envelope calculation to come up with channel size. It does
look like cleans things up and adding the waterfall graphs does make it easier
to see. Unfortunately, it does seem to change the decoding.
On Mon, 2014-11-03 at 12:01 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
>6. Re: Works with GR 3.6, breaks with 3.7 (Luke Berndt)
>
> On the off chance that someone has some free time to look into this, I
> have built the Smartnet trunk control channel in GRC. I have also made
> a capture o
On 10/18/2014 05:57 PM, Luke Berndt wrote:
> The Band Edge FLL works great for me too, on 3.6. Does anyone know if
> there were changes to it or surrounding blocks in 3.7 that would make it
> stop working?
None of the DSP was changed, if it worked before it should(TM) still
work. The reason we say
ndy Walls"
> wrote:
> On Fri, 2014-10-17 at 12:00 -0400,
> discuss-gnuradio-requ...@gnu.org
> wrote:
>
> > Message: 33
> > Date: Fri, 17 Oct 2014 07:37:25 -0700
> > From: John Malsbury
> > To:
quot; wrote:
>
>> On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
>> wrote:
>>
>> > Message: 33
>> > Date: Fri, 17 Oct 2014 07:37:25 -0700
>> > From: John Malsbury
>> > To: Luke Berndt
>> > Cc: "Discuss-
Message: 33
>> > Date: Fri, 17 Oct 2014 07:37:25 -0700
>> > From: John Malsbury
>> > To: Luke Berndt
>> > Cc: "Discuss-gnuradio@gnu.org List"
>> > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
>> > Message-ID:
>&g
18, 2014 6:41 AM, "Andy Walls" wrote:
> On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
>
> > Message: 33
> > Date: Fri, 17 Oct 2014 07:37:25 -0700
> > From: John Malsbury
> > To: Luke Berndt
> > Cc: "Discuss-g
On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 33
> Date: Fri, 17 Oct 2014 07:37:25 -0700
> From: John Malsbury
> To: Luke Berndt
> Cc: "Discuss-gnuradio@gnu.org List"
> Subject: Re: [Discuss-gnuradio] Works with GR 3.6,
The good news is. the GFSK block doesn't do anything specific to Gaussian
FSK. So I guess tha tall works out =)
You're outputs might be more illustrative if you rebuild it in from the
blocks actually inside the GFSK demod block:
quad demod > clock recovery -> slicer
On Fri, Oct 17, 2014 at 12:
It actually looks like the control channel for Motorola SmartNet is FSK: "On
the control (data) channel the base station transmits 84 bits frames at
3600 bit/s with direct frequency modulation of the carrier using Frequency
Shift Keying (FSK). "
I will at least see if I can get something that look
Also, my understanding for the PLL blocks were that they were ideal for
"strong carrier" signals like AM. When I say strong carrier i mean a
signal that has an obvious carrier which isn't "hidden" under modulation..
Anyway, the GMSK block might be a good place to start.
-John
On Fri, Oct 17, 20
It doesn't have frequency correction - I can probably follow up with some
ideas on how to implement that part. But the GMSK demod might do OK for
you initially. It doesn't do anything intelligent to deal with the data
shaping - its just a non-coherent slicer.
If you want to design in GRC but kee
Thanks for looking into it! To be honest, I am not really good at RF. I
based my code off the python code in gr-smartnet. The fsk-demod python file
is here:
https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py
It is quite possible that it just happened to work because of a
On 10/17/2014 08:28 AM, John Malsbury wrote:
> Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect
> understanding of that block is that it was more ideal for PAM with
> common RRC.
For the record: It might work coincidentally because of the rolloff-y
shape of GMSK, but it's de
John,
I use the BE FLL for auto-doppler correction in the rare case where I am
not actively correcting for doppler. But, the correction is *really*
slow. I'm probably not using it correctly, but it works OK in that rare
case when it's all I've got.
Very Respectfully,
Dan CaJacob
On Fri, Oct 1
Luke,
I researched this for a bit (OK, maybe it was more like staring
blankly)... unfortunately on a windows machine w/out git. Nothing stands
out at the momentt. I'll give it another try tomorrow! =)
Also, I've never used the PLL blocks for freq demod before. Can you set
something up with a g
I just tried doing a complete PyBombs reinstall and that didn't seem the help.
I checked and simple GRC files run fine. I can also see the signal where I
expect it to be in GQRX, so I think my tuning parameters are correct.
Are there some other things I should try?
Sent from my iPhone
> On O
20 matches
Mail list logo
