My error, typo I meant GMSK!!
Sent from my iPad
> On May 3, 2016, at 9:31 PM, Kevin McQuiggin wrote:
>
> Hi Henry:
>
> The narrowest channels are 600 bps MPSK, although in Inmarsat parlance they
> call it "A-BPSK". There are 1200, 4800, 10200 bps channels as well, plus
> faster ones I have
Hi Henry:
The narrowest channels are 600 bps MPSK, although in Inmarsat parlance they
call it "A-BPSK". There are 1200, 4800, 10200 bps channels as well, plus
faster ones I have not really considered yet.
The spec document describes it all.
I find the signal to be quite strong, perhaps check
The initial GRC errors are known and for now occur on all the builds.
The QT/GTK error is interesting. Unfortunately, I'm still building blind
for these older systems, in a month I'll have good direct access. I will
try to work it regardless.
Thanks for the feedback!
On Wed, May 4, 2016 at
So the control channels are the narrow ones? I’m guessing the really wide ones
are the traffic. (On a side note, I’m kind of surprised that people [you and
killmore231] can get Inmarsat with a patch. I just barely see the signals with
9A4QAV’s helix and an SDRplay. However, Iridium comes in like
Hi Henry:
I have an Inmarsat demodulator working for the lower speed control channels. I
am writing a program to decode the traffic, but this is not a trivial task.
Think on the order of 1000 lines of C. It is "almost" working, I am hoping for
valid output in the next week or so, depending o
> On Tue, May 3, 2016 at 4:26 PM, Richard Bell
> wrote:
>
>> I like the new style, it feels fresh and modern.
>>
>
I'm glad you like it!
> I've noticed that depending on the link you click, you may end up on a
>> page in the old style. For example, clicking the development link does
>> this. Wi
The development link is intended for keeping developer focused content
which is highly dynamic. It will always go to a wiki. It won't always be
redmine, but I'll leave that as a teaser so you listen to the monthly dev
calls ;-)
-Nathan
On Tue, May 3, 2016 at 7:26 PM, Richard Bell
wrote:
> I lik
Makes sense, and will do! Thanks.
On Tue, May 3, 2016 at 6:41 PM, Derek Kozel wrote:
> That's what I put the standard deviation in for. Your photos are showing
> ~1 degree of deviation which certainly points to the system being
> synchronized. The flowgraph is crude though and can definitely be
That's what I put the standard deviation in for. Your photos are showing ~1
degree of deviation which certainly points to the system being
synchronized. The flowgraph is crude though and can definitely be improved
so don't pay too close attention to the exact number of the deviation. If
you do make
Hi Derek,
Thanks. Wrt the degrees versus dB, wouldn't it be more useful to test that
the phase error (not the offset) is only changing over time by less than
some threshold? It's already known that the offset is around 60 degrees,
but the question is how much it varies *from* 60 degrees over time,
I had partial success with these binaries:
1) GRC starts with the following warnings which I am not sure if they are
important:
---
setting gnuradio environment
** (python.exe:2060): WARNING **: Trying to register gtype
'GMountMountFlags' as
enum when in fact it is of type 'GFla
Just for clarity. That's a phase error in degrees not dB. :) And yes,
there's expected to be an offset. The correct behaviour is that the phase
offset is stable for a given frequency (assuming no other changes in the
system) and that tuning away and back or restarting should produce the same
phase
Nice. Will def check this out.
On May 3, 2016 5:05 PM, "Geof Nieboer" wrote:
> All,
>
> An updated set of windows binaries and build scripts have been posted.
> Quick summary:
> 1- Added gqrx to package
> 2- Patched 2 x issues which would cause the generic version to crash on
> non-AVX systems (o
"There is still a lot of content work to do as we migrate away from Redmine
(you may notice that many of the links on the website take you to
Redmine-hosted content, at the moment)"
:)
I imagine part of the challenge will be keeping the various sections of the
website which are written wiki style
On 05/03/2016 07:26 PM, Richard Bell wrote:
I like the new style, it feels fresh and modern.
I've noticed that depending on the link you click, you may end up on a
page in the old style. For example, clicking the development link does
this. Will the entire website eventually get the makeover?
I like the new style, it feels fresh and modern.
I've noticed that depending on the link you click, you may end up on a page
in the old style. For example, clicking the development link does this.
Will the entire website eventually get the makeover?
Rich
On Tue, May 3, 2016 at 1:44 PM, Ben Hilbu
On 05/03/2016 04:25 PM, John Shields wrote:
Thanks Marcus,
I have moved the N200 over to another cable to
see if the situation improves but I think that the best solution is to
move the Ubuntu box into the shack rather than move house/shack closer :)
Lazy :) :)
All,
An updated set of windows binaries and build scripts have been posted.
Quick summary:
1- Added gqrx to package
2- Patched 2 x issues which would cause the generic version to crash on
non-AVX systems (one in volk, one in FFTW)
3- Added gr-newmod to package
Plus a number of improvements to mak
Hi all -
I am happy to share that primary development on the user-facing GNU Radio
website has been wrapped up! You can check out the new site in action at
gnuradio.org.
There is still a lot of content work to do as we migrate away from Redmine
(you may notice that many of the links on the websit
[The answers to both 1) and 2) are yes.]
That's great. Thank you.
[Stay tuned.]
What does that mean? Do you have more info?
_
From: Ian Buckley [mailto:i...@ionconcepts.com]
Sent: Tuesday, May 03, 2016 4:37 PM
To: Marcus D. Leech
Cc: Henry Barton; Discuss-gnuradio; discuss-gnura
Here's a good starting point for you:
http://www.uhf-satcom.com/lband/
The answers to both 1) and 2) are yes. Stay tuned.
On Tue, May 3, 2016 at 12:56 PM, wrote:
> I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT
> THINGS" knob in Gnu Radio. The answer to that would be a re
Thanks Marcus,
The cable is cat-5e and the length is 52 meters
(give or take).
Based on your calculations, it seems that I am
setting myself for high likelihood of a dropped packet if I were to run
for 4 or 5 days continuously.
I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT
THINGS" knob in Gnu Radio. The answer to that would be a resounding NO.
If the question is, instead:
(1) Is the Gnu Radio development environment suitable for
*developing* signal-processing chains to decode INMARSAT
(2
What you're going to need to do is provide the *simplest* flow-graph
that demonstrates the issue, rather than requiring the community to
debug your entire end-to-end setup.
Also a diagram of your setup showing the RF and 1PPS and 10MHz paths.
On 2016-05-03 15:39, khalid.el-darymli wrote:
> Tha
http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrpl
ay_lband-1024x573.png
I didn't see the widest signal (bright yellow) from this picture on
sigidwiki.com. Does anyone know what it is? If so, can it be decoded by
GNUradio? Thanks.
Thanks again Marcus. I really appreciate your help.
I am setting Ref Clock / PPS to external, etc. I get the syncing to work
properly around a year ago. Since then, we made various changes and I think
one or more change may be causing the issue. Among the changes are: buy
N200 units with a new rev
Thanks, this is a false alarm. It must have been an issue with downloading
on Chrome for Windows on the machine I was using. I just verified that the
file's SHA256 checksum matches the expected checksum on a Ubuntu system:
$ wget
http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf
The native BER of 1000BASE-T is better than 1.0e-11 or so.
Which means you'd expect a bad bit roughly every half-hour at 2msps
(64Mbit/sec), the bad-bit probabilities get worse as you make the cable
longer.
On 2016-05-03 12:59, John Shields wrote:
> On 03/05/16 15:01, mle...@ripnet.com wrote:
Everyone,
a couple of notes on PyBOMBS: First, GSoC participant Ravi Sharan will
be part of PyBOMBS development over the next weeks (see his announcement
and blog). Expect some cool features coming! If you want to see what
else we've planned, check out the issue tracker on github.
But, right now,
This has me thinking that this is a PHY-layer issue.
How long are your Ethernet runs, and are you using Cat5e cabling?
On 2016-05-03 12:59, John Shields wrote:
> On 03/05/16 15:01, mle...@ripnet.com wrote:
>
> It's possible that we're dealing with a memory leak somewhere. Could you
> watch
On Tue, May 3, 2016 at 11:53 AM, Sean Nowlan wrote:
> Sorry, email confusion with IEEE email forwarding. Resending to hit
> discuss-gnuradio list.
>
> Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
> Jethro. This version incorporated the bugfix, so it could theoretically
On Tue, May 3, 2016 at 10:51 AM, Sean Nowlan wrote:
> I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here
> [1] is corrupted, or at least the download keeps failing in the same way.
>
> The SHA256 checksums do not match:
> Posted
> [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2
You may have a broken pip. Does 'pip list' work for you on the command line?
M
On 05/02/2016 08:50 PM, Shahnaz Shirazi wrote:
> Just an update.
>
> I found the Pybomb source cod got updated to try it one more time
> All step went through without error except the installation.
> I got bellow erro
On 03/05/16 15:01, mle...@ripnet.com wrote:
It's possible that we're dealing with a memory leak somewhere. Could
you watch the memory consumption of simple_ra over time?
Also, could you just run something like uhd_fft with the same sample
rate for long periods to see if it gets the same 'D'
Dear Khalid,
the RS232 connection, as you've noticed, is necessary for detection.
Without being detected, the GPSDO can still supply a PPS (and 10 MHz
clock) over the coax connectors – however, I'm not even sure they will
discipline those correctly when not initialized via RS232 by UHD.
Why would
The only way the USRP knows that there's a GPSDO present is if the
serial data from the GSPDO is validated. If it doesn't see that data,
it concludes that there's no (internal) GPSDO present.
There is no concept of "external GPSDO" -- only that *something* is
providing 10MHz and 1PPS externally.
Hi Yan,
the output buffer size has nothing to do with this. The FFT will give
you a 512-element vector of complex numbers. You can for example use the
matrix multiplication block to select the right elements from those vectors.
However:
Really, go for the newer blocks I described in the bottom pa
I am out of the office until 09/05/2016.
Back on Monday 9 May. Sporadic email access during this period.
Note: This is an automated response to your message "Discuss-gnuradio
Digest, Vol 162, Issue 1" sent on 03/05/2016 17:41:15.
This is the only notification you will receive while this perso
Thanks Marcus.
OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS
232 cable. I am able to do so after enabling echoing on RS 232 from the
GPSDO. Would that be a problem? Do I need to completely disable the RS 232
echoing, even while the RS 232 cable is completely unplugged?
Sorry, email confusion with IEEE email forwarding. Resending to hit
discuss-gnuradio list.
Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
Jethro. This version incorporated the bugfix, so it could theoretically be
enabled in meta-sdr's gnuradio build.
On Tue, May 3, 2016 a
Hi Marcus,
Thanks a lot, following your suggestion:
· I add a 512-FFT on the receiver side, but how can I only pick the
first 200 subcarriers? I set the max output buffer of FFT as 200, but I don't
think it works. How can I deal with it?
· After FFT in receiver side, I connect
ORC is still in VOLK, but it doesn't give you much.
On Tue, May 3, 2016 at 11:32 AM, Philip Balister
wrote:
> On 05/03/2016 10:47 AM, Sean Nowlan wrote:
> > According to the wiki [1], ORC support was disabled on armhf due to a
> bug,
> > which has apparently since been resolved [2]. Was ORC supp
On 05/03/2016 10:47 AM, Sean Nowlan wrote:
> According to the wiki [1], ORC support was disabled on armhf due to a bug,
> which has apparently since been resolved [2]. Was ORC support added back
> for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
> page just out of date?
>
>
It's possible that we're dealing with a memory leak somewhere. Could
you watch the memory consumption of simple_ra over time?
Also, could you just run something like uhd_fft with the same sample
rate for long periods to see if it gets the same 'D' treatment?
On 2016-05-03 04:32, John Shields w
I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here
[1] is corrupted, or at least the download keeps failing in the same way.
The SHA256 checksums do not match:
Posted [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a
Actual: d99df0557e8766d02036f583cca6fb
The PPS input is conditioned with a:
http://www.ti.com/product/SN74AUP1T57/description
Looks to me like it should work just fine.
On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
> Hi,
>
> I'll appreciate any help on the following. According to the link below [1],
> the PPS vol
According to the wiki [1], ORC support was disabled on armhf due to a bug,
which has apparently since been resolved [2]. Was ORC support added back
for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
page just out of date?
Thanks,
Sean
[1] http://gnuradio.org/redmine/projects
Hi,
I'll appreciate any help on the following. According to the link below [1],
the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
[1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
I am getting a PPS signal through fan-outs from an external Firefly-1A
GPSDO. I measure
Dear Yan,
> If I want to change the SNR, can I add a Noise Source to the USRP
> Source to change it?
Well, sure, but then you have two sources of noise: the noise inferred
via reception of the signal with additive noise, and the added noise
source power.
It's a change, but it's pretty hard to qua
Hi Marcus,
Thank you for kind reply. Actually I want to calculate the sum-Signal to
sum-Noise ratio, as you have referred Parseval to calculate it.
· But the problem is I don't know how to estimate the noise power of
the receive signal.
· If I want to change the SNR, can I add
Hi John,
agreeed,
we need to shorten this thread :)
Hence: replies below!
Best regards,
Marcus
>> They are certainly not the greatest NICs in the world when it comes to
>> CPU efficiency, but I'm not aware of any specific prolems. Can you
>> actually just try with the atheros interface? That w
Thanks Marcus,
Have put answers in-line.
Kind Regards,
John
On 03/05/16 08:20, Marcus Müller wrote:
On 03.05.2016 09:52, John Shields wrote:
On 03/05/16 02:58, Marcus D. Leech wrote:
On 05/02/2016 10:40 PM, John Shields wrote:
the system runs a
On 03.05.2016 09:52, John Shields wrote:
> On 03/05/16 02:58, Marcus D. Leech wrote:
>> On 05/02/2016 10:40 PM, John Shields wrote:
>>>
>>> the system runs along happily for several maybe even up to 20 odd
>>> hours but, as below, I start to see one or more Ds. In one run of 23
>>> hours, I had 10
On 03/05/16 02:58, Marcus D. Leech wrote:
On 05/02/2016 10:40 PM, John Shields wrote:
Hi,
I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP
N200 with SBXv3. I have been using the aptly-named and highly useful
Simple_ra though I believe this is orthogonal to the issues I am
On 03/05/16 02:58, Marcus D. Leech wrote:
On 05/02/2016 10:40 PM, John Shields wrote:
Hi,
I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP
N200 with SBXv3. I have been using the aptly-named and highly useful
Simple_ra though I believe this is orthogonal to the issues I am
55 matches
Mail list logo
