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. Re: UHD dissector for Wireshark (Alexander Chemeris)
2. Re: N210 w/ SBX - LO unlocked (Balint Seeber)
3. Re: UHD dissector for Wireshark (Dario Lombardo)
4. Re: Question about local oscillator error (Balint Seeber)
5. preserve individual vita headers (dave)
6. Re: preserve individual vita headers (Josh Blum)
7. Re: Xilinx Zynq-based embedded USRP (Matt Ettus)
8. Re: UHD dissector for Wireshark (Alexander Chemeris)
9. Re: UHD dissector for Wireshark (Dario Lombardo)
10. GPS signal Acquisation using USRP N210, DBSRX (Raj)
11. Gnuradio module tutorial (ZaInzAiN Jj)
12. Re: GPS signal Acquisation using USRP N210, DBSRX
(Carles Fernandez)
13. Re: GPS signal Acquisation using USRP N210, DBSRX (Mike Jameson)
14. Re: GPS signal Acquisation using USRP N210, DBSRX (Mike Jameson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Mar 2013 21:24:16 +0400
From: Alexander Chemeris <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID:
<cabmjbfwtohilvsw6l-ezuiq95xcy5pni1_a-wh31cfbz1hu...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dario,
There is no formal description, at least no which I know of. We based
our implementation on this header and relevant code:
https://github.com/fairwaves/UHD-Fairwaves/blob/fairwaves/umtrx/host/lib/usrp/usrp2/fw_common.h
On Wed, Mar 20, 2013 at 12:32 PM, Dario Lombardo
<[email protected]> wrote:
> I've downloaded and installed the plugin before submitting it to the
> wireshark community.
> It works fine, but I think that, before submitting, we should work on it a
> little bit more. To be inserted into the WS trunk, they want sample captures
> to test it. When dissecting my uhd flow, dissector shows me some
> "unkown/undecoded" fields. Where can I find protocol specs, so I can improve
> support before submission?
> I will branch on github and make a pull request when something relevant
> changes, if you are ok.
>
>
> On Tue, Mar 19, 2013 at 5:32 PM, Alexander Chemeris
> <[email protected]> wrote:
>>
>> On Tue, Mar 19, 2013 at 8:29 PM, Dario Lombardo
>> <[email protected]> wrote:
>> >
>> >
>> > On Tue, Mar 19, 2013 at 5:23 PM, Alexander Chemeris
>> > <[email protected]> wrote:
>> >>
>> >>
>> >> No. If you know the procedure, I'd appreciate if you submit it.
>> >
>> >
>> > For sure. I will keep you update with their comments (be prepared, since
>> > they are a very proactive community that follows strict rules :)).
>>
>> Thanks!
>>
>> --
>> Regards,
>> Alexander Chemeris.
>> CEO, Fairwaves LLC / ??? ???????
>> http://fairwaves.ru
>
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru
------------------------------
Message: 2
Date: Wed, 20 Mar 2013 11:43:04 -0700
From: Balint Seeber <[email protected]>
To: Tom Theisen <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] N210 w/ SBX - LO unlocked
Message-ID:
<capcb_2o3ttbhoquvcaqiamr1sfarnjzcrj6wnac+09ivooa...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Tom,
Sorry to hear you're having difficulties. If the LO is not locking, it's
possible that your SBX is not seeing the master clock distributed from the
motherboard (this also explains why you only see noise when running e.g.
uhd_fft).
Do you have a scope/CRO handy to check the clock at the daughterboard? Let
me know what you have available and we can go from there - if a scope isn't
handy, we can issue you an RMA and have a look at it here. Let me know...
Kind regards,
Balint
On Sun, Mar 17, 2013 at 12:21 AM, Tom Theisen <[email protected]> wrote:
> Hey,
>
> On 2013-03-17 08:07, zhe yang wrote:
> > You mean you phone can recognize the 433MHz from USRP? That's
> > interesting......
> No, the phone can see the 900MHz GSM carrier made by the OpenBTS
> software. I have 433MHz remote control "outlets" which you can switch by
> sending some data to them. That worked also.
> >
> > What is rtl-sdr stick?
> The rtl-sdr project ( http://sdr.osmocom.org/trac/wiki/rtl-sdr) makes it
> possible to use a cheap DVB-T television receiver with a certain chip as
> software radio receiver. Its clock drifts a lot but it is enough to see
> the output of the USRP.
>
> I just tried to send a carrier at 433,9 MHz and it is nicely received by
> the rtl-sdr. So i guess my transmitting section is working fine.
> >
> > FYI, if you have more than one USRP, I think you can play the trick
> > that use one of them as receiver, but just show the FFT of the
> > received signal, it can roughly gave some carrier frequency information.
> I have done that with the rtl-sdr now. It shows a really nice carrier :)
>
> Only the receiving part does not work apparently..
>
> - Tom Theisen
>
> _______________________________________________
> 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/20130320/e66f30e3/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 20 Mar 2013 23:31:15 +0100
From: Dario Lombardo <[email protected]>
To: Alexander Chemeris <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID:
<CAOYJJfuoa9mjfFHyOH-uzV05_qeEAZ-otjeR+EDS=+d+vtt...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Mar 20, 2013 at 6:24 PM, Alexander Chemeris <
[email protected]> wrote:
> There is no formal description, at least no which I know of. We based
> our implementation on this header and relevant code:
>
> https://github.com/fairwaves/UHD-Fairwaves/blob/fairwaves/umtrx/host/lib/usrp/usrp2/fw_common.h
At last I need some help from the UHD masters.
Once understood the protocol, the dissector will be complete. Hope someone
helps me.
CTRL support seems ok.
What is missing is decoding of frames as the following:
0x0000: 4500 0308 0000 4000 2011 c291 c0a8 0a02 E.....@.........
0x0010: c0a8 0a01 c004 8e97 02f4 0000 1411 00bb ................
0x0020: 0000 0003 0000 7078 413d ae59 f4ed ee0b ......pxA=.Y....
0x0030: fef3 02fa fd04 0112 f721 00ff fffd f5f7 .........!......
0x0040: f7fc fd0c ec08 ec13 130c f9fc 0800 0b0e ................
0x0050: 0605 f703 fcf0 0cfc 0914 f906 fdfb ea0e ................
0x0060: 0e04 0a0d 1608 1b03 ff04 f5fb ff0f 0713 ................
0x0070: faec fdfe 1afb f603 1507 0af6 fef8 f606 ................
0x0080: f7ff 00f3 f5fb f7f5 f5f9 fdf0 f6f1 ef09 ................
0x0090: 0304 f204 ecfd fa0c 02f0 fa08 04fd fc00 ................
0x00a0: 060a 07f6 f8f2 0fe5 15f6 0003 e910 0307 ................
0x00b0: 0a01 0215 ed24 f802 02ee f300 e701 f8ee .....$..........
0x00c0: faf2 fffe f902 f4fd 04fb 0105 fa0a fa01 ................
0x00d0: fb0e 0702 f60b 040b fd0c eb1a 0d10 0f07 ................
0x00e0: eff3 ef12 03ef e8f5 f6f4 03ec fd0c fefe ................
0x00f0: fe17 f6fc ef08 fb1d edf4 ed08 0601 f9fc ................
0x0100: f30d ff02 f3f7 0b04 11f1 fefc f101 0104 ................
0x0110: 1412 03fe 090d fbfe 020a 0d0f 0107 fdf8 ................
0x0120: 1104 feeb fbfb fc05 05e9 0bf2 0cf4 fff1 ................
0x0130: fb08 f908 0619 fb09 0005 0406 ee0a fcff ................
0x0140: 0600 ff04 19fc f707 06f4 fcf9 fa03 0004 ................
0x0150: e702 ed06 f6f5 f40d 0802 e4ef 0d09 07f1 ................
0x0160: 0aee 10f7 06e7 f90d 010b 00f3 0c0d 0205 ................
0x0170: 0605 0bfd fb10 010f fcf3 010b 11ff edfd ................
0x0180: 0a07 05fd 0cfa 130f 0406 050b 0113 0608 ................
0x0190: feff e3f4 0af7 02fd fffe 1a04 fcf7 fbf9 ................
0x01a0: 06e7 0506 fe07 fdf4 000a f70d 00f2 070b ................
0x01b0: 07f7 0a09 f8fa eef7 05fa 04f8 ecec 0ce3 ................
0x01c0: f7fa 0000 f906 f713 f20c f9fe 0002 0710 ................
0x01d0: ed0e f704 0100 f7ff 00fa 05f7 1bfa 0ef4 ................
0x01e0: f900 05f6 eff9 f3f9 ef04 f400 fdf1 f502 ................
0x01f0: f507 0903 0bf9 f3f8 06fc fe05 f315 ff03 ................
0x0200: 14f5 04f3 01ff 0302 0b17 fd06 f504 041c ................
0x0210: 00f3 0a08 edfa 03f8 1b01 f7ef 01fb 04f9 ................
0x0220: fbfb fbfe 01df 1ce0 11fd 0a00 0203 fb03 ................
0x0230: 11e7 12fd fc00 fbe5 02fb 07f9 e9e5 f10a ................
0x0240: f0f0 f1e3 070e f4fd 071b 220b 05fc f619 ..........".....
0x0250: 00f1 fcf8 0b0b fd10 ec02 f60d 0105 fc0b ................
0x0260: 1108 12f6 10f9 0ef8 0f03 fd1b ff12 fb05 ................
0x0270: e90c f110 07fa f9ff 0e0c 0df3 0df7 0af9 ................
0x0280: 0504 1616 f805 0e17 f614 02fe 00fa 0b06 ................
0x0290: 0604 0d01 0df6 fa04 0805 18fb f005 0f00 ................
0x02a0: 05fb 0415 01f0 f1f9 db02 0ffa f4fa ee05 ................
0x02b0: fe03 0107 f9f9 eef4 0104 f008 010b 08f7 ................
0x02c0: e218 eefb 0a06 ec10 ed01 fe11 f4fb 0ff9 ................
0x02d0: 00f2 dfff 0302 f7ea ff0d fa05 f40e fbf7 ................
0x02e0: 0b06 ff06 f903 f6fd 020f f8f0 0805 fd00 ................
0x02f0: 0105 04fc fffb f403 fdfb f502 140e f90d ................
0x0300: 0000 1008 0050 0400 .....P..
UHD section starts from 0x141100BB (second line).
Those frames are exchanged between my pc and my N210 when no software runs
(at least pc side...).
What are them? The dissector forces the header against them, and fails
(unknown UHD message type), but the header itself seems to be forced
wrongly, since casted "version" is 0x141100BB, that seems nonsense.
Can anyone explain me what is it and where I can find reference code in
libuhd?
Thanks anyone who helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130320/d30fb0e9/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 20 Mar 2013 15:56:16 -0700
From: Balint Seeber <[email protected]>
To: Wenjun Xu <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Question about local oscillator error
Message-ID:
<capcb_2qgntjjtjkqrccqggzne8sf8twyo4wjdmnvhayj6zx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Wenjun,
The LED on the front relates to the PLL clock chip on the motherboard
(whether is has successfully locked to the supplied reference signal).
I believe the exception is being thrown when the LabVIEW niUSRP code is
checking the 'lo_locked' sensor that indicates whether the PLL on the *
daughterboard* has locked (here that is unfortunately not the case -
usually caused by the daughterboard not receiving the master clock).
Do you have the means to probe the motherboard's master clock at points on
the daughterboard with a scope? If not, we can look at issuing you an RMA.
Let me know...
Kind regards,
Balint
On Tue, Mar 12, 2013 at 9:04 AM, Wenjun Xu <[email protected]> wrote:
> Hi, everyone!
>
> I am new to USRP and trying to run an example vi (niUSRP EX TX Continous
> Async.vi) on my NI USRP-2920. At the very beginning everything is ok but
> after about 2 seconds, the program stopped and threw out an error
> message as follows:
>
> Error code: -1074118626
> niUSRP Write Tx Data (CDB).vi<ERR> The local oscillator did not lock
> within the alloted time.
>
> I've checked the LED on the front panel but it shows that the LO was
> locked. Have anyone met this before or know something about it? Many
> thanks for your help.
>
> Best Regards,
>
> Wenjun Xu
>
> _______________________________________________
> 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/20130320/555fde92/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 21 Mar 2013 00:14:44 +0000
From: dave <[email protected]>
To: [email protected]
Subject: [USRP-users] preserve individual vita headers
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
I need to read the vita header of each packet. I can see each header if
I set oneblock=true in rx_stream->recv() and grab the packets one at a
time, but if I set up a buffer any larger than one vita packet and let
oneblock=false I can't figure out how to see any but the first header.
Are the rest rest gone forever? If I grab just one packet and don't get
back to that point in the program before come in will they get dropped
or are they buffered in the kernel until the program catches up?
Thanks!
------------------------------
Message: 6
Date: Wed, 20 Mar 2013 19:33:50 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] preserve individual vita headers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/20/2013 07:14 PM, dave wrote:
> I need to read the vita header of each packet. I can see each header if
> I set oneblock=true in rx_stream->recv() and grab the packets one at a
> time, but if I set up a buffer any larger than one vita packet and let
> oneblock=false I can't figure out how to see any but the first header.
> Are the rest rest gone forever? If I grab just one packet and don't get
Its basically filling the buffer you give it, for as many samples as you
give it. If the number of samples given is a multiple of max samples per
packet, I believe, every call you make to recv will be aligned at a
packet boundary.
> back to that point in the program before come in will they get dropped
> or are they buffered in the kernel until the program catches up?
>
They are buffered in a kernel socket buffer. Its ok to not read as long
as there is buffering, which can be quite large.
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers
-josh
> Thanks!
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 7
Date: Wed, 20 Mar 2013 18:09:19 -0700
From: Matt Ettus <[email protected]>
To: Sean Nowlan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Xilinx Zynq-based embedded USRP
Message-ID:
<CAN=1kn9r0fbi5awbobt0nhwg51mw3s_atodrs6e65hdqq6e...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sean,
We are still hard at work on that project. Expect a big announcement in
the next few months!
Matt
On Mon, Mar 11, 2013 at 1:45 PM, Sean Nowlan <[email protected]>wrote:
> At GRcon12 Ettus announced they might be developing a Xilinx Zynq-based
> embedded USRP. Is there anywhere I can follow news about this? Such a
> device would be *REALLY* cool!
>
> --sean
>
> ______________________________**_________________
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130320/a15e4943/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 21 Mar 2013 07:40:37 +0400
From: Alexander Chemeris <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID:
<CABmJbFVaJUT_HCH8QfQZ=A39Faf3=yy2mkiqfv3fj8gzqu4...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Looking at the size of the packet I think it's VRT aka VITA 49:
https://github.com/chemeris/vrt-dissector
On Thu, Mar 21, 2013 at 2:31 AM, Dario Lombardo
<[email protected]> wrote:
>
>
> On Wed, Mar 20, 2013 at 6:24 PM, Alexander Chemeris
> <[email protected]> wrote:
>>
>> There is no formal description, at least no which I know of. We based
>> our implementation on this header and relevant code:
>>
>> https://github.com/fairwaves/UHD-Fairwaves/blob/fairwaves/umtrx/host/lib/usrp/usrp2/fw_common.h
>
>
> At last I need some help from the UHD masters.
> Once understood the protocol, the dissector will be complete. Hope someone
> helps me.
>
> CTRL support seems ok.
>
> What is missing is decoding of frames as the following:
>
> 0x0000: 4500 0308 0000 4000 2011 c291 c0a8 0a02 E.....@.........
> 0x0010: c0a8 0a01 c004 8e97 02f4 0000 1411 00bb ................
> 0x0020: 0000 0003 0000 7078 413d ae59 f4ed ee0b ......pxA=.Y....
> 0x0030: fef3 02fa fd04 0112 f721 00ff fffd f5f7 .........!......
> 0x0040: f7fc fd0c ec08 ec13 130c f9fc 0800 0b0e ................
> 0x0050: 0605 f703 fcf0 0cfc 0914 f906 fdfb ea0e ................
> 0x0060: 0e04 0a0d 1608 1b03 ff04 f5fb ff0f 0713 ................
> 0x0070: faec fdfe 1afb f603 1507 0af6 fef8 f606 ................
> 0x0080: f7ff 00f3 f5fb f7f5 f5f9 fdf0 f6f1 ef09 ................
> 0x0090: 0304 f204 ecfd fa0c 02f0 fa08 04fd fc00 ................
> 0x00a0: 060a 07f6 f8f2 0fe5 15f6 0003 e910 0307 ................
> 0x00b0: 0a01 0215 ed24 f802 02ee f300 e701 f8ee .....$..........
> 0x00c0: faf2 fffe f902 f4fd 04fb 0105 fa0a fa01 ................
> 0x00d0: fb0e 0702 f60b 040b fd0c eb1a 0d10 0f07 ................
> 0x00e0: eff3 ef12 03ef e8f5 f6f4 03ec fd0c fefe ................
> 0x00f0: fe17 f6fc ef08 fb1d edf4 ed08 0601 f9fc ................
> 0x0100: f30d ff02 f3f7 0b04 11f1 fefc f101 0104 ................
> 0x0110: 1412 03fe 090d fbfe 020a 0d0f 0107 fdf8 ................
> 0x0120: 1104 feeb fbfb fc05 05e9 0bf2 0cf4 fff1 ................
> 0x0130: fb08 f908 0619 fb09 0005 0406 ee0a fcff ................
> 0x0140: 0600 ff04 19fc f707 06f4 fcf9 fa03 0004 ................
> 0x0150: e702 ed06 f6f5 f40d 0802 e4ef 0d09 07f1 ................
> 0x0160: 0aee 10f7 06e7 f90d 010b 00f3 0c0d 0205 ................
> 0x0170: 0605 0bfd fb10 010f fcf3 010b 11ff edfd ................
> 0x0180: 0a07 05fd 0cfa 130f 0406 050b 0113 0608 ................
> 0x0190: feff e3f4 0af7 02fd fffe 1a04 fcf7 fbf9 ................
> 0x01a0: 06e7 0506 fe07 fdf4 000a f70d 00f2 070b ................
> 0x01b0: 07f7 0a09 f8fa eef7 05fa 04f8 ecec 0ce3 ................
> 0x01c0: f7fa 0000 f906 f713 f20c f9fe 0002 0710 ................
> 0x01d0: ed0e f704 0100 f7ff 00fa 05f7 1bfa 0ef4 ................
> 0x01e0: f900 05f6 eff9 f3f9 ef04 f400 fdf1 f502 ................
> 0x01f0: f507 0903 0bf9 f3f8 06fc fe05 f315 ff03 ................
> 0x0200: 14f5 04f3 01ff 0302 0b17 fd06 f504 041c ................
> 0x0210: 00f3 0a08 edfa 03f8 1b01 f7ef 01fb 04f9 ................
> 0x0220: fbfb fbfe 01df 1ce0 11fd 0a00 0203 fb03 ................
> 0x0230: 11e7 12fd fc00 fbe5 02fb 07f9 e9e5 f10a ................
> 0x0240: f0f0 f1e3 070e f4fd 071b 220b 05fc f619 ..........".....
> 0x0250: 00f1 fcf8 0b0b fd10 ec02 f60d 0105 fc0b ................
> 0x0260: 1108 12f6 10f9 0ef8 0f03 fd1b ff12 fb05 ................
> 0x0270: e90c f110 07fa f9ff 0e0c 0df3 0df7 0af9 ................
> 0x0280: 0504 1616 f805 0e17 f614 02fe 00fa 0b06 ................
> 0x0290: 0604 0d01 0df6 fa04 0805 18fb f005 0f00 ................
> 0x02a0: 05fb 0415 01f0 f1f9 db02 0ffa f4fa ee05 ................
> 0x02b0: fe03 0107 f9f9 eef4 0104 f008 010b 08f7 ................
> 0x02c0: e218 eefb 0a06 ec10 ed01 fe11 f4fb 0ff9 ................
> 0x02d0: 00f2 dfff 0302 f7ea ff0d fa05 f40e fbf7 ................
> 0x02e0: 0b06 ff06 f903 f6fd 020f f8f0 0805 fd00 ................
> 0x02f0: 0105 04fc fffb f403 fdfb f502 140e f90d ................
> 0x0300: 0000 1008 0050 0400 .....P..
>
> UHD section starts from 0x141100BB (second line).
> Those frames are exchanged between my pc and my N210 when no software runs
> (at least pc side...).
> What are them? The dissector forces the header against them, and fails
> (unknown UHD message type), but the header itself seems to be forced
> wrongly, since casted "version" is 0x141100BB, that seems nonsense.
> Can anyone explain me what is it and where I can find reference code in
> libuhd?
> Thanks anyone who helps.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru
------------------------------
Message: 9
Date: Thu, 21 Mar 2013 09:38:50 +0100
From: Dario Lombardo <[email protected]>
To: Alexander Chemeris <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD dissector for Wireshark
Message-ID:
<caoyjjfulpdkg38sbxypvs1wp2-gviwxpivy4ovefxjpp3td...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Perfect, you're right.
If you agree I can try to submit both to the wireshark trunk.
Don't you think that the UHD dissector should be renamed to UHD CTRL?
Having a quick look at the uhd code, seems that each part of the
communication works on a different port, so different dissectors should be
implemented.
On Thu, Mar 21, 2013 at 4:40 AM, Alexander Chemeris <
[email protected]> wrote:
> Looking at the size of the packet I think it's VRT aka VITA 49:
> https://github.com/chemeris/vrt-dissector
>
> On Thu, Mar 21, 2013 at 2:31 AM, Dario Lombardo
> <[email protected]> wrote:
> >
> >
> > On Wed, Mar 20, 2013 at 6:24 PM, Alexander Chemeris
> > <[email protected]> wrote:
> >>
> >> There is no formal description, at least no which I know of. We based
> >> our implementation on this header and relevant code:
> >>
> >>
> https://github.com/fairwaves/UHD-Fairwaves/blob/fairwaves/umtrx/host/lib/usrp/usrp2/fw_common.h
> >
> >
> > At last I need some help from the UHD masters.
> > Once understood the protocol, the dissector will be complete. Hope
> someone
> > helps me.
> >
> > CTRL support seems ok.
> >
> > What is missing is decoding of frames as the following:
> >
> > 0x0000: 4500 0308 0000 4000 2011 c291 c0a8 0a02 E.....@
> .........
> > 0x0010: c0a8 0a01 c004 8e97 02f4 0000 1411 00bb
> ................
> > 0x0020: 0000 0003 0000 7078 413d ae59 f4ed ee0b
> ......pxA=.Y....
> > 0x0030: fef3 02fa fd04 0112 f721 00ff fffd f5f7
> .........!......
> > 0x0040: f7fc fd0c ec08 ec13 130c f9fc 0800 0b0e
> ................
> > 0x0050: 0605 f703 fcf0 0cfc 0914 f906 fdfb ea0e
> ................
> > 0x0060: 0e04 0a0d 1608 1b03 ff04 f5fb ff0f 0713
> ................
> > 0x0070: faec fdfe 1afb f603 1507 0af6 fef8 f606
> ................
> > 0x0080: f7ff 00f3 f5fb f7f5 f5f9 fdf0 f6f1 ef09
> ................
> > 0x0090: 0304 f204 ecfd fa0c 02f0 fa08 04fd fc00
> ................
> > 0x00a0: 060a 07f6 f8f2 0fe5 15f6 0003 e910 0307
> ................
> > 0x00b0: 0a01 0215 ed24 f802 02ee f300 e701 f8ee
> .....$..........
> > 0x00c0: faf2 fffe f902 f4fd 04fb 0105 fa0a fa01
> ................
> > 0x00d0: fb0e 0702 f60b 040b fd0c eb1a 0d10 0f07
> ................
> > 0x00e0: eff3 ef12 03ef e8f5 f6f4 03ec fd0c fefe
> ................
> > 0x00f0: fe17 f6fc ef08 fb1d edf4 ed08 0601 f9fc
> ................
> > 0x0100: f30d ff02 f3f7 0b04 11f1 fefc f101 0104
> ................
> > 0x0110: 1412 03fe 090d fbfe 020a 0d0f 0107 fdf8
> ................
> > 0x0120: 1104 feeb fbfb fc05 05e9 0bf2 0cf4 fff1
> ................
> > 0x0130: fb08 f908 0619 fb09 0005 0406 ee0a fcff
> ................
> > 0x0140: 0600 ff04 19fc f707 06f4 fcf9 fa03 0004
> ................
> > 0x0150: e702 ed06 f6f5 f40d 0802 e4ef 0d09 07f1
> ................
> > 0x0160: 0aee 10f7 06e7 f90d 010b 00f3 0c0d 0205
> ................
> > 0x0170: 0605 0bfd fb10 010f fcf3 010b 11ff edfd
> ................
> > 0x0180: 0a07 05fd 0cfa 130f 0406 050b 0113 0608
> ................
> > 0x0190: feff e3f4 0af7 02fd fffe 1a04 fcf7 fbf9
> ................
> > 0x01a0: 06e7 0506 fe07 fdf4 000a f70d 00f2 070b
> ................
> > 0x01b0: 07f7 0a09 f8fa eef7 05fa 04f8 ecec 0ce3
> ................
> > 0x01c0: f7fa 0000 f906 f713 f20c f9fe 0002 0710
> ................
> > 0x01d0: ed0e f704 0100 f7ff 00fa 05f7 1bfa 0ef4
> ................
> > 0x01e0: f900 05f6 eff9 f3f9 ef04 f400 fdf1 f502
> ................
> > 0x01f0: f507 0903 0bf9 f3f8 06fc fe05 f315 ff03
> ................
> > 0x0200: 14f5 04f3 01ff 0302 0b17 fd06 f504 041c
> ................
> > 0x0210: 00f3 0a08 edfa 03f8 1b01 f7ef 01fb 04f9
> ................
> > 0x0220: fbfb fbfe 01df 1ce0 11fd 0a00 0203 fb03
> ................
> > 0x0230: 11e7 12fd fc00 fbe5 02fb 07f9 e9e5 f10a
> ................
> > 0x0240: f0f0 f1e3 070e f4fd 071b 220b 05fc f619
> ..........".....
> > 0x0250: 00f1 fcf8 0b0b fd10 ec02 f60d 0105 fc0b
> ................
> > 0x0260: 1108 12f6 10f9 0ef8 0f03 fd1b ff12 fb05
> ................
> > 0x0270: e90c f110 07fa f9ff 0e0c 0df3 0df7 0af9
> ................
> > 0x0280: 0504 1616 f805 0e17 f614 02fe 00fa 0b06
> ................
> > 0x0290: 0604 0d01 0df6 fa04 0805 18fb f005 0f00
> ................
> > 0x02a0: 05fb 0415 01f0 f1f9 db02 0ffa f4fa ee05
> ................
> > 0x02b0: fe03 0107 f9f9 eef4 0104 f008 010b 08f7
> ................
> > 0x02c0: e218 eefb 0a06 ec10 ed01 fe11 f4fb 0ff9
> ................
> > 0x02d0: 00f2 dfff 0302 f7ea ff0d fa05 f40e fbf7
> ................
> > 0x02e0: 0b06 ff06 f903 f6fd 020f f8f0 0805 fd00
> ................
> > 0x02f0: 0105 04fc fffb f403 fdfb f502 140e f90d
> ................
> > 0x0300: 0000 1008 0050 0400 .....P..
> >
> > UHD section starts from 0x141100BB (second line).
> > Those frames are exchanged between my pc and my N210 when no software
> runs
> > (at least pc side...).
> > What are them? The dissector forces the header against them, and fails
> > (unknown UHD message type), but the header itself seems to be forced
> > wrongly, since casted "version" is 0x141100BB, that seems nonsense.
> > Can anyone explain me what is it and where I can find reference code in
> > libuhd?
> > Thanks anyone who helps.
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ??? ???????
> http://fairwaves.ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130321/b3bbcec2/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 21 Mar 2013 18:04:03 +0800 (SGT)
From: Raj <[email protected]>
To: USRP List <[email protected]>
Subject: [USRP-users] GPS signal Acquisation using USRP N210, DBSRX
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi
I trying to acquire GPS signal using USRP N210, DBSRX daughter board. The FFT
figure using grc are the same with and without GPS signal input. Any suggestion
would be highly appreciated, thanks in advance.
?
Regards
Raj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130321/eb09d3db/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 21 Mar 2013 18:12:58 +0800 (SGT)
From: ZaInzAiN Jj <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Gnuradio module tutorial
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear All,
Where I get tutorial explanations gnuradio module? I want to send some file
types on OFDM and the receiver can be constructed back to the original file.
Thanks,
Zai
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130321/bc10f0d8/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 21 Mar 2013 11:39:13 +0100
From: Carles Fernandez <[email protected]>
To: Raj <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210,
DBSRX
Message-ID:
<CAKYOsfvCvYHeFUGhCwX9o0W_JboqdvNmv=r+6i2w6r-z8zy...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear Raj,
this is as expected, since the GPS signals are under the noise floor. If
you are using a Low Noise Amplifier in your antenna, you should see the
shape of its transfer function when applying the FFT.
If you are interested in processing GPS signals, maybe GNSS-SDR (
http://gnss-sdr.org) could be of help. It is a c++ application based on GNU
Radio that implements all the processing chain, from the USRP output to the
computation of position, velocity and time. It supports UHD, so you will be
able to use your N210+DBSRX setup.
Best regards,
Carles
On Thu, Mar 21, 2013 at 11:04 AM, Raj <[email protected]> wrote:
> Hi
>
> I trying to acquire GPS signal using USRP N210, DBSRX daughter board. The
> FFT figure using grc are the same with and without GPS signal input. Any
> suggestion would be highly appreciated, thanks in advance.
>
> Regards
> Raj
>
> _______________________________________________
> 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/20130321/73e5708e/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 21 Mar 2013 10:44:01 +0000
From: Mike Jameson <[email protected]>
To: Raj <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210,
DBSRX
Message-ID:
<CAJcjmiSWkd4S8e3dew=xu0v0C+tSWg=vjdmbfn+jvesstyg...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Raj,
Have a play with balint's groovy gr-baz block called 'Fast
AutoCorrelation Sink' in GRC and look for peaks at 1ms (alter the
fft-rate). The autocorrelation technique allows you to see the GPS
signal below the noise floor.
See: http://wiki.spench.net/wiki/Fast_Auto-correlation
Here are two FFT plots from
http://sites.google.com/site/radiorausch/USRPFastAutocorrelation.html
to show you what to look for:
https://sites.google.com/site/radiorausch/usrp_fac_gps.png
https://sites.google.com/site/radiorausch/usrp_fac_gps_full.png
Mike
--
Mike Jameson M0MIK BSc
Radio Communications Technology Specialist
Email: [email protected]
Web: http://www.scanoo.com
On 21 March 2013 10:04, Raj <[email protected]> wrote:
> Hi
>
> I trying to acquire GPS signal using USRP N210, DBSRX daughter board. The
> FFT figure using grc are the same with and without GPS signal input. Any
> suggestion would be highly appreciated, thanks in advance.
>
> Regards
> Raj
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Thu, 21 Mar 2013 11:14:42 +0000
From: Mike Jameson <[email protected]>
To: Raj <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPS signal Acquisation using USRP N210,
DBSRX
Message-ID:
<cajcjmiqzhckh8vcphdt97zch8ttgpvso80-exx-1m4rdru2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I meant to say that the 'Size' variable in the 'Fast AutoCorrelation
Sink' block needs to be changed in order to view at 1ms. Use a
sampling rate of (100e6/20) and set the Fast AutoCorrelation Sink
'Size' to (2**14).
Also, if you happen to be using a 5v active GPS antenna don't forget
to power it! You can use the 5v bias on the DBSRX by shorting J101.
See: http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpDBoardDBSRX
Mike
--
Mike Jameson M0MIK BSc
Radio Communications Technology Specialist
Email: [email protected]
Web: http://www.scanoo.com
On 21 March 2013 10:44, Mike Jameson <[email protected]> wrote:
> Hi Raj,
>
> Have a play with balint's groovy gr-baz block called 'Fast
> AutoCorrelation Sink' in GRC and look for peaks at 1ms (alter the
> fft-rate). The autocorrelation technique allows you to see the GPS
> signal below the noise floor.
>
> See: http://wiki.spench.net/wiki/Fast_Auto-correlation
>
> Here are two FFT plots from
> http://sites.google.com/site/radiorausch/USRPFastAutocorrelation.html
> to show you what to look for:
>
> https://sites.google.com/site/radiorausch/usrp_fac_gps.png
> https://sites.google.com/site/radiorausch/usrp_fac_gps_full.png
>
> Mike
>
> --
> Mike Jameson M0MIK BSc
> Radio Communications Technology Specialist
> Email: [email protected]
> Web: http://www.scanoo.com
>
>
> On 21 March 2013 10:04, Raj <[email protected]> wrote:
>> Hi
>>
>> I trying to acquire GPS signal using USRP N210, DBSRX daughter board. The
>> FFT figure using grc are the same with and without GPS signal input. Any
>> suggestion would be highly appreciated, thanks in advance.
>>
>> Regards
>> Raj
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
------------------------------
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 31, Issue 20
******************************************
