Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Problems using Airprobe with USRP1 (GSM Research)
2. Re: Problems using Airprobe with USRP1 (Ian Buckley)
3. Re: Problems using Airprobe with USRP1 (GSM Research)
4. Re: Problems using Airprobe with USRP1 (Markus Hofer)
5. Re: UHD driver segault (Josh Blum)
6. N200 clock ref info on application notes page (Sean Nowlan)
7. Re: UHD driver segault (Youri Westerman)
8. Re: UHD driver segault (Marcus D. Leech)
9. Re: UHD driver segault (Youri Westerman)
10. Re: UHD driver segault (Marcus D. Leech)
11. Re: UHD driver segault (Youri Westerman)
12. VRT Passthrough (Joseph Payton)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Apr 2013 12:39:37 -0400
From: GSM Research <[email protected]>
To: [email protected]
Subject: [USRP-users] Problems using Airprobe with USRP1
Message-ID:
<cakh+_5fxxlv8-anj87uvyz6kcambno3-u3fgklbxwymk7uc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
We are trying to use Airprobe to capture gsm traffic from an OpenBSC setup
using an IP.Access nanoBTS PCS 1900 as our cell tower.
For the Airprobe setup, we have a USRP1 with two FLEX900 daughter cards
(both of which have been modified to work as RFX1800 cards) attached to a
workstation on which we have installed GnuRadio. We have also downloaded
the Airprobe repository and the additional USRP drivers and programs found
on the Ettus website.
We have tested the USRP1 and using uhd_fft, we can see that we are
detecting the carrier signals put out by the nanoBTS.
We are trying to use uhd_rx_cfile for the capture. When running the
program, it does appear to be capturing data (at least a large file is
created), but we are unable to decode the datafile that is created.
A typical run of uhd_rx_cfile that we have tried (for ARFCN 800) is:
root# uhd_rx_cfile -g 52 -N 2000000 -f 1987800000 output.cfile
When we try to decode the output.cfile using gsm_receive.py, we get the
following:
root# ./gsm_receive.py -I output.cfile
input_rate: 406250.0 sample rate: 0.375 filter_cutoff: 145000.0
filter_t_width: 10000.0
>>> gr_fir_ccc: using SSE
>>> gr_fir_ccf: using SSE
Key: 'ad6a3ec2b442e400'
Configuration: ''
No configuration set.
configure_receiver
gr_buffer::allocate_buffer: warning: tried to allocate
115 items of size 568. Due to alignment requirements
512 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
The cfile2.out file that gets created automatically from running
gsm_receive.py is empty (size 0), and nothing appears in a Wireshark
capture.
Obviously, we are missing something (a parameter? using the wrong
program/script?). We have tried many different combinations of parameters
and earlier versions of airprobe programs that mailing lists have said are
now deprecated, but we have not been able to get one successful run.
At this point, we don't know whether we are capturing the data correctly,
or decoding it improperly (or both). When we compare (using a hexdump) our
output file with the sample capture given on the SR Labs Airprobe How-To (
https://srlabs.de/airprobe-how-to/), we notice differences (odd numbered
columns in the SR Labs file are for the most part 0000):
Our output.cfile:
0000000 810b bc85 012c bb96 0140 baa0 0108 bc04
0000010 01c8 3b64 0100 bc80 01dc bbee 4174 bcba
0000020 0176 bc3b 0122 bc91 c174 bcb9 c116 bc8a
0000030 c12e bc96 01e2 bc71 0154 bc2a 4110 bc88
0000040 41c2 bce1 01d8 bcec 416a 3cb5 01c0 ba60
SR Labs sample file:
0000000 0000 3b04 0000 3b20 0000 3b3a 0000 3b26
0000010 0000 3b48 0000 3b2a 0000 3ae8 0000 3b76
0000020 0000 baf4 0000 3b52 0000 bb24 0000 3b3a
0000030 0000 bbab 0000 bbb9 0000 3ac8 0000 3b82
0000040 0000 bb98 c000 bca2 0000 3c44 4000 3cde
However, we don't know if this is due to different hardware (SR Labs is
using a USRP2) or something else (improper capture).
Any suggestions on what we could try on our captures or decodes would be
greatly appreciated!
Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/b39698b8/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 11 Apr 2013 11:51:48 -0700
From: Ian Buckley <[email protected]>
To: GSM Research <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Problems using Airprobe with USRP1
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I know practically nothing about using Airprobe but here's a few starter
pointers:
hexdumping a file full of binary complex floats is going to make far more sense
with some command line options:
hexdump -e '1/4 "%f" " "1/4 "%f" "\n"' output.cfile
Explicitly setting the sample rate used to capture the off-air data is probably
a tremendously good idea, I believe for USRP1 "-d 112" is what is typically
used for Airprobe but you should check that.
Starting with the RX gain low and working up would be a good methodology,
starting with it turned way up is a guarantee that the RFX900 is operating in a
non-linear range.
On Apr 11, 2013, at 9:39 AM, GSM Research <[email protected]> wrote:
> Hello,
>
> We are trying to use Airprobe to capture gsm traffic from an OpenBSC setup
> using an IP.Access nanoBTS PCS 1900 as our cell tower.
>
> For the Airprobe setup, we have a USRP1 with two FLEX900 daughter cards (both
> of which have been modified to work as RFX1800 cards) attached to a
> workstation on which we have installed GnuRadio. We have also downloaded the
> Airprobe repository and the additional USRP drivers and programs found on the
> Ettus website.
>
> We have tested the USRP1 and using uhd_fft, we can see that we are detecting
> the carrier signals put out by the nanoBTS.
>
> We are trying to use uhd_rx_cfile for the capture. When running the program,
> it does appear to be capturing data (at least a large file is created), but
> we are unable to decode the datafile that is created.
>
> A typical run of uhd_rx_cfile that we have tried (for ARFCN 800) is:
> root# uhd_rx_cfile -g 52 -N 2000000 -f 1987800000 output.cfile
>
> When we try to decode the output.cfile using gsm_receive.py, we get the
> following:
> root# ./gsm_receive.py -I output.cfile
> input_rate: 406250.0 sample rate: 0.375 filter_cutoff: 145000.0
> filter_t_width: 10000.0
> >>> gr_fir_ccc: using SSE
> >>> gr_fir_ccf: using SSE
> Key: 'ad6a3ec2b442e400'
> Configuration: ''
> No configuration set.
> configure_receiver
> gr_buffer::allocate_buffer: warning: tried to allocate
> 115 items of size 568. Due to alignment requirements
> 512 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
>
> The cfile2.out file that gets created automatically from running
> gsm_receive.py is empty (size 0), and nothing appears in a Wireshark capture.
>
> Obviously, we are missing something (a parameter? using the wrong
> program/script?). We have tried many different combinations of parameters
> and earlier versions of airprobe programs that mailing lists have said are
> now deprecated, but we have not been able to get one successful run.
>
> At this point, we don't know whether we are capturing the data correctly, or
> decoding it improperly (or both). When we compare (using a hexdump) our
> output file with the sample capture given on the SR Labs Airprobe How-To
> (https://srlabs.de/airprobe-how-to/), we notice differences (odd numbered
> columns in the SR Labs file are for the most part 0000):
> Our output.cfile:
> 0000000 810b bc85 012c bb96 0140 baa0 0108 bc04
> 0000010 01c8 3b64 0100 bc80 01dc bbee 4174 bcba
> 0000020 0176 bc3b 0122 bc91 c174 bcb9 c116 bc8a
> 0000030 c12e bc96 01e2 bc71 0154 bc2a 4110 bc88
> 0000040 41c2 bce1 01d8 bcec 416a 3cb5 01c0 ba60
>
> SR Labs sample file:
> 0000000 0000 3b04 0000 3b20 0000 3b3a 0000 3b26
> 0000010 0000 3b48 0000 3b2a 0000 3ae8 0000 3b76
> 0000020 0000 baf4 0000 3b52 0000 bb24 0000 3b3a
> 0000030 0000 bbab 0000 bbb9 0000 3ac8 0000 3b82
> 0000040 0000 bb98 c000 bca2 0000 3c44 4000 3cde
>
> However, we don't know if this is due to different hardware (SR Labs is using
> a USRP2) or something else (improper capture).
>
> Any suggestions on what we could try on our captures or decodes would be
> greatly appreciated!
>
> Thanks,
> John
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/4732993a/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 11 Apr 2013 15:36:54 -0400
From: GSM Research <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problems using Airprobe with USRP1
Message-ID:
<CAKH+_5Ez2Ji1pzFw=tghjkbu9q9_3qse_mg4vc+bbjf9kml...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Apr 11, 2013 at 2:51 PM, Ian Buckley <[email protected]> wrote:
>
> hexdumping a file full of binary complex floats is going to make far more
> sense with some command line options:
>
> hexdump -e '1/4 "%f" " "1/4 "%f" "\n"' output.cfile
>
Thanks Ian, that does make the data in the files look more similar
> Explicitly setting the sample rate used to capture the off-air data is
> probably a tremendously good idea, I believe for USRP1 "-d 112" is what is
> typically used for Airprobe but you should check that.
>
I agree. But although the usrp_rx_cfile.py program had the -d option, the
same option doesn't exist on the uhd_rx_cfile program. It *does* offer a
samp-rate option, but we are puzzled on how to set that value to get the
proper decimation. We have tried values around 571428 (which is close to
64MHz / 112), but it doesn't seem to have any effect on the output we are
getting for gsm_receive.py
> Starting with the RX gain low and working up would be a good methodology,
> starting with it turned way up is a guarantee that the RFX900 is operating
> in a non-linear range.
>
We have been trying different values for the gain. The run I pasted into
the email is just one that was run recently. But, I guess we should stick
to the lower values for the time being.
Also:
On Thu, Apr 11, 2013 at 12:46 PM, Marcus D. Leech <[email protected]> wrote:
> I'd suggest contacting the folks who wrote gsm_receive.py, who are
unlikely to be adequately represented here.
Well unfortunately, there doesn't seem to be much activity for Airprobe
anymore, and the mailing list doesn't appear to allow new subscriptions
(not that there would be much activity anyway). The USRP-users list
appears to have the most recent discussions regarding Airprobe, so this is
where I have come in my quest for information. However, perhaps I will
also contact the folks in the AUTHORS file.
> uhd_rx_cfile produces a file containing complex-floats representing
the I and Q components of the sampled signal.
That is good to know and we didn't know that. Thanks Marcus!
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/b2008243/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 Apr 2013 21:46:09 +0200
From: Markus Hofer <[email protected]>
To: GSM Research <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Problems using Airprobe with USRP1
Message-ID:
<caef55litzpmxad+ui+x+aiaeasiwnfq0mrxksp74xzcuhrd...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
For the capturing part, it would be good to set the sample rate (previously
decimation was used, but that value depends on the clock rate, so setting
the sample rate should be preferred).
And as you are using the USRP1 it doesn't hurt to specify the daughterboard
and antenna. An example command would be:
uhd_rx_cfile -f 1987.8M -g 45 --samp-rate=400e3 -a usb --spec=A:0 -A TX/RX
output.cfile
For the decoding part, gsm_receive.py must have the correct key. If you
want to decode CCCH, use "00 00 00 00 00 00 00 00".
Also, since the capturing was now made with a sample rate of 400k, the
decoder needs to be aware of this. So instead of specifying the decimation,
directly set the sample rate with e.g. "self.input_rate = 400e3".
Hope that helps,
Markus
On Thu, Apr 11, 2013 at 6:39 PM, GSM Research
<[email protected]>wrote:
> Hello,
>
> We are trying to use Airprobe to capture gsm traffic from an OpenBSC setup
> using an IP.Access nanoBTS PCS 1900 as our cell tower.
>
> For the Airprobe setup, we have a USRP1 with two FLEX900 daughter cards
> (both of which have been modified to work as RFX1800 cards) attached to a
> workstation on which we have installed GnuRadio. We have also downloaded
> the Airprobe repository and the additional USRP drivers and programs found
> on the Ettus website.
>
> We have tested the USRP1 and using uhd_fft, we can see that we are
> detecting the carrier signals put out by the nanoBTS.
>
> We are trying to use uhd_rx_cfile for the capture. When running the
> program, it does appear to be capturing data (at least a large file is
> created), but we are unable to decode the datafile that is created.
>
> A typical run of uhd_rx_cfile that we have tried (for ARFCN 800) is:
> root# uhd_rx_cfile -g 52 -N 2000000 -f 1987800000 output.cfile
>
> When we try to decode the output.cfile using gsm_receive.py, we get the
> following:
> root# ./gsm_receive.py -I output.cfile
> input_rate: 406250.0 sample rate: 0.375 filter_cutoff: 145000.0
> filter_t_width: 10000.0
> >>> gr_fir_ccc: using SSE
> >>> gr_fir_ccf: using SSE
> Key: 'ad6a3ec2b442e400'
> Configuration: ''
> No configuration set.
> configure_receiver
> gr_buffer::allocate_buffer: warning: tried to allocate
> 115 items of size 568. Due to alignment requirements
> 512 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
>
> The cfile2.out file that gets created automatically from running
> gsm_receive.py is empty (size 0), and nothing appears in a Wireshark
> capture.
>
> Obviously, we are missing something (a parameter? using the wrong
> program/script?). We have tried many different combinations of parameters
> and earlier versions of airprobe programs that mailing lists have said are
> now deprecated, but we have not been able to get one successful run.
>
> At this point, we don't know whether we are capturing the data correctly,
> or decoding it improperly (or both). When we compare (using a hexdump) our
> output file with the sample capture given on the SR Labs Airprobe How-To (
> https://srlabs.de/airprobe-how-to/), we notice differences (odd numbered
> columns in the SR Labs file are for the most part 0000):
> Our output.cfile:
> 0000000 810b bc85 012c bb96 0140 baa0 0108 bc04
> 0000010 01c8 3b64 0100 bc80 01dc bbee 4174 bcba
> 0000020 0176 bc3b 0122 bc91 c174 bcb9 c116 bc8a
> 0000030 c12e bc96 01e2 bc71 0154 bc2a 4110 bc88
> 0000040 41c2 bce1 01d8 bcec 416a 3cb5 01c0 ba60
>
> SR Labs sample file:
> 0000000 0000 3b04 0000 3b20 0000 3b3a 0000 3b26
> 0000010 0000 3b48 0000 3b2a 0000 3ae8 0000 3b76
> 0000020 0000 baf4 0000 3b52 0000 bb24 0000 3b3a
> 0000030 0000 bbab 0000 bbb9 0000 3ac8 0000 3b82
> 0000040 0000 bb98 c000 bca2 0000 3c44 4000 3cde
>
> However, we don't know if this is due to different hardware (SR Labs is
> using a USRP2) or something else (improper capture).
>
> Any suggestions on what we could try on our captures or decodes would be
> greatly appreciated!
>
> Thanks,
> John
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/03fb2eb4/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 11 Apr 2013 17:51:19 -0500
From: Josh Blum <[email protected]>
To: Youri Westerman <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD driver segault
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/11/2013 04:07 AM, Youri Westerman wrote:
> Hi Josh,
>
> I've also tried 64, 128, 256 as values. Unfortunately that produces the
> same segfault.
I suspect that is too small. I think powers of two between 512 and 32k
are probably ok. May I ask what you are trying to do?
-josh
>
> Youri
>
>
> 2013/4/11 Josh Blum <[email protected]>
>
>>
>>
>> On 04/10/2013 03:29 AM, Youri Westerman wrote:
>>> Hi,
>>>
>>> I'm trying to get the uhd driver working properly in combination with a
>>> B100 USRP. Unfortnuately when using the gnuradio block "UHD: USRP Sink"
>> and
>>> setting the send_frame_size=1023 (or any other value I've tried) libuhd
>>
>> Try to keep the frame sizes to powers of two. Non powers of two may make
>> issues somewhere in the USB stack.
>>
>> -josh
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
------------------------------
Message: 6
Date: Thu, 11 Apr 2013 19:38:36 -0400
From: Sean Nowlan <[email protected]>
To: <[email protected]>
Subject: [USRP-users] N200 clock ref info on application notes page
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
I noticed that this N200 application notes page is missing a mention of
jumper J510 to switch between front panel SMA (J501) and internal SMA
(J507). I must have switched it at some point, because
query_gpsdo_sensors was reporting the 10 MHz ref was sometimes locked,
and sometimes unlocked (the PLL was freewheeling without a reference).
I think this information would be useful here, even though the N200
schematic shows the jumper. Perhaps the layout is different for other
revisions, for USRP2, or for N210, but I can confirm this configuration
for N200 r4.
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz
--sean
------------------------------
Message: 7
Date: Fri, 12 Apr 2013 11:11:19 +0200
From: Youri Westerman <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD driver segault
Message-ID:
<cafsnd_ryf3_hv53eq2x3-ykpdngzjrhydtwamlucahfej5h...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Ok it's now working with 2048. Didn't know the value could be that high up.
I'm trying to get a DAB signal sent out using mmbTools crc-dabmod,
crc-dabmux, etc...
So far I'm seemingly able to sent out a signal, but unable to pick it up on
a receiver. I'm really new to this, so I'm having a hard time
troubleshooting this. Any advice is more than welcome.
2013/4/12 Josh Blum <[email protected]>
>
>
> On 04/11/2013 04:07 AM, Youri Westerman wrote:
> > Hi Josh,
> >
> > I've also tried 64, 128, 256 as values. Unfortunately that produces the
> > same segfault.
>
> I suspect that is too small. I think powers of two between 512 and 32k
> are probably ok. May I ask what you are trying to do?
>
> -josh
>
> >
> > Youri
> >
> >
> > 2013/4/11 Josh Blum <[email protected]>
> >
> >>
> >>
> >> On 04/10/2013 03:29 AM, Youri Westerman wrote:
> >>> Hi,
> >>>
> >>> I'm trying to get the uhd driver working properly in combination with a
> >>> B100 USRP. Unfortnuately when using the gnuradio block "UHD: USRP Sink"
> >> and
> >>> setting the send_frame_size=1023 (or any other value I've tried) libuhd
> >>
> >> Try to keep the frame sizes to powers of two. Non powers of two may make
> >> issues somewhere in the USB stack.
> >>
> >> -josh
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> >
> >
>
--
Youri Westerman
Developer
Pluxbox
Sumatralaan 45
Mediapark - Studio 21
t: 035-7606060
e: [email protected]
w: http://www.pluxbox.nl
Pluxbox
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130412/4a2b7898/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 12 Apr 2013 08:35:53 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD driver segault
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Ok it's now working with 2048. Didn't know the value could be that
> high up.
> I'm trying to get a DAB signal sent out using mmbTools crc-dabmod,
> crc-dabmux, etc...
> So far I'm seemingly able to sent out a signal, but unable to pick it
> up on a receiver. I'm really new to this, so I'm having a hard time
> troubleshooting this. Any advice is more than welcome.
Have you visited this site:
http://www.opendigitalradio.org/index.php/Main_Page
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 9
Date: Fri, 12 Apr 2013 16:12:48 +0200
From: Youri Westerman <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD driver segault
Message-ID:
<CAFSNd_T3OUi9=At0mSxoHYKoJ2SHujWMMSO7M8p=hjyjsad...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I sure have. That is where I got the baseband player I'm using. Furthermore
I'm using crc-dabmod and generated an ETI file with the webtools from CRC.
When I start the process it gives a warning which I don't quite understand,
it tells me the decimation and interpolation are odd and I should expect
CIC rolloff. Followed by:
decimation = dsp_rate/samp_rate -> 33 = (32.768000 MHz) / (1.000000 MHz)
However the sample rate I specify is 2048000. I tried doing this by passing
-r2048000 to the baseband player and by entering it into the gnuradio block
directly...
2013/4/12 Marcus D. Leech <[email protected]>
> Ok it's now working with 2048. Didn't know the value could be that high up.
>> I'm trying to get a DAB signal sent out using mmbTools crc-dabmod,
>> crc-dabmux, etc...
>> So far I'm seemingly able to sent out a signal, but unable to pick it up
>> on a receiver. I'm really new to this, so I'm having a hard time
>> troubleshooting this. Any advice is more than welcome.
>>
> Have you visited this site:
>
> http://www.opendigitalradio.**org/index.php/Main_Page<http://www.opendigitalradio.org/index.php/Main_Page>
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ______________________________**_________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
--
Youri Westerman
Developer
Pluxbox
Sumatralaan 45
Mediapark - Studio 21
t: 035-7606060
e: [email protected]
w: http://www.pluxbox.nl
Pluxbox
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130412/ba472624/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 12 Apr 2013 10:22:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: Youri Westerman <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD driver segault
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> I sure have. That is where I got the baseband player I'm using.
> Furthermore I'm using crc-dabmod and generated an ETI file with the
> webtools from CRC.
> When I start the process it gives a warning which I don't quite
> understand, it tells me the decimation and interpolation are odd and I
> should expect CIC rolloff. Followed by:
> decimation = dsp_rate/samp_rate -> 33 = (32.768000 MHz) / (1.000000 MHz)
>
> However the sample rate I specify is 2048000. I tried doing this by
> passing -r2048000 to the baseband player and by entering it into the
> gnuradio block directly...
>
Well, if you're using a USRP1, 2048000 isn't a valid sample rate for the
hardware.
The hardware sample rate must be an integer fraction of 64e6.
Which tool are you using for the actual transmission part, after crc_dabmod?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 11
Date: Fri, 12 Apr 2013 16:31:23 +0200
From: Youri Westerman <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD driver segault
Message-ID:
<CAFSNd_SaN349v1FEDZ5tW=brdrw6yqjgdkq65r9r2+pdbpq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Al right, well I'm using a B100 with the WBX daugtherboard. I got those
values through this post:
https://groups.google.com/d/msg/crc-mmbtools/x-QgwDNQmp0/5HdHWzrPYxgJ
The tool I'm using to transmit is this one:
http://www.opendigitalradio.org/index.php/UHD_Band_3_baseband_player
It was written by Matthias Coinchon from the EBU.
2013/4/12 Marcus D. Leech <[email protected]>
> I sure have. That is where I got the baseband player I'm using.
>> Furthermore I'm using crc-dabmod and generated an ETI file with the
>> webtools from CRC.
>> When I start the process it gives a warning which I don't quite
>> understand, it tells me the decimation and interpolation are odd and I
>> should expect CIC rolloff. Followed by:
>> decimation = dsp_rate/samp_rate -> 33 = (32.768000 MHz) / (1.000000 MHz)
>>
>> However the sample rate I specify is 2048000. I tried doing this by
>> passing -r2048000 to the baseband player and by entering it into the
>> gnuradio block directly...
>>
>> Well, if you're using a USRP1, 2048000 isn't a valid sample rate for the
> hardware.
>
> The hardware sample rate must be an integer fraction of 64e6.
>
> Which tool are you using for the actual transmission part, after
> crc_dabmod?
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
--
Youri Westerman
Developer
Pluxbox
Sumatralaan 45
Mediapark - Studio 21
t: 035-7606060
e: [email protected]
w: http://www.pluxbox.nl
Pluxbox
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130412/a18a7c81/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 12 Apr 2013 11:24:02 -0400
From: Joseph Payton <[email protected]>
To: [email protected]
Subject: [USRP-users] VRT Passthrough
Message-ID:
<CAJmawsY7K1o=61oygmwyt00hta5t2nuk_pjzfyh_oe7nywt...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Is there any straightforward way to receive and re-transmit the VRT packets
directly using UHD, configuring a streamer or otherwise? (I am using the
USRP N200)
I know that the conversion is done under the hood, but I have utility in
getting the VRT packets onto a disk. Also, the overhead of raw packet
capture is not attractive to me due to CPU constraints.
Right now the options that I see so far are:
1. To keep track of the metadata on my receives and reconstruct the VRT
packet for my own use.
or
2. To override / extend the io implementation to provide a "null" unpacker
to be used in recv_pirate_loop, and just make sure that I am aware on
the receive side that I am not receiving the usual output.
Many thanks in advance and thanks for help given in the past.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130412/67b2ae3e/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 32, Issue 9
*****************************************
