[Discuss-gnuradio] [GSoC19] Final results announced!

[Wunsch, Felix (CEL)]

?Hi all,


today, the final results for this year's Google Summer of Code were announced. 
We are happy to say that both students that worked for GNU Radio during the 
summer successfully completed GSoC! Congratulations, Arpit Gupta and Bowen Hu, 
thank you for extending GNU Radio with your work! Arpit created a block header 
parsing tool while Bowen dealt with the integration of the simulation of 
Verilog code in GNU Radio. Both will soon publish a blog post on gnuradio.org 
where they go into further detail about their respective projects and reflect 
about their personal GSoC experience.


We really hope that both of them will stay with the community as active 
developers! Also, their work will be showcased at GRCon19 through posters, so 
don't miss them if you can make it to Huntsville!


Last but not least, we should not forget Marcus Müller, Sebastian Koslowski, 
and Nicolas Cuervo, who supported the students through their mentoring and 
continuous feedback and surely played an integral role in the successful 
completion of the projects.


Cheers,
Felix (GSoC Org Admin 2019)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC19] Final results announced!

[Albin Stigö]

That's great news!

On Wed, Sep 4, 2019, 11:08 Wunsch, Felix (CEL)  wrote:

> ​Hi all,
>
>
> today, the final results for this year's Google Summer of Code were
> announced. We are happy to say that both students that worked for GNU Radio
> during the summer successfully completed GSoC! Congratulations, Arpit
> Gupta and Bowen Hu, thank you for extending GNU Radio with your work! Arpit
> created a block header parsing tool while Bowen dealt with the integration
> of the simulation of Verilog code in GNU Radio. Both will soon publish a
> blog post on gnuradio.org where they go into further detail about their
> respective projects and reflect about their personal GSoC experience.
>
>
> We really hope that both of them will stay with the community as active
> developers! Also, their work will be showcased at GRCon19 through posters,
> so don't miss them if you can make it to Huntsville!
>
>
> Last but not least, we should not forget Marcus Müller, Sebastian
> Koslowski, and Nicolas Cuervo, who supported the students through their
> mentoring and continuous feedback and surely played an integral role in the
> successful completion of the projects.
>
>
> Cheers,
> Felix (GSoC Org Admin 2019)
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ISDB-T transmitter working on commercial TVs

[Federico 'Larroca' La Rocca]

Hello everyone,

For those interested in our ISDB-T transmitter project (see my previous
mail to the list below), I wanted to share the news that we (finally) got
it working with commercial TVs. So far, the transmission was correctly
displayed by SDR-based receivers, but the behavior with "off-the-shelf" TVs
was erratic (to be more blunt: it didn't work). This week we found out why
and it's now working nicely. We are still testing it, and in particular
we'll try to use it with cheap SDR transmitters (rpitx and osmo-fl2k).

As usual, it would be very interesting to receive feedback (both failures
and successes).

best
Federico

--
*From*: Federico 'Larroca' La Rocca
*Subject*: [Discuss-gnuradio] ISDB-T transmitter OOT
*Date*: Fri, 21 Dec 2018 14:13:03 -0300
--
Hi everyone,

I'm very glad to announce that our OOT gr-isdbt now includes the
transmitter and may be considered (almost) complete. The repository is at
https://github.com/git-artes/gr-isdbt.

For those of you who did not know it, we developed gr-isdbt some years ago
now (I think 2015 was the year we considered it useful) and it was a
receiver-only for ISDB-T (the TVD standard used mostly in south america and
Japan).

To give a little bit of context, last year two students of ours (Santiago
Castro and Javier Hernández) here in the university started to work on the
implementation of the transmitter. Their work is still available at their
repo (https://github.com/jhernandezbaraibar/gr-isdbt-Tx), although it may
be considered deprecated, since over the last few months I've integrated
their work into gr-isdbt and significant changes were introduced in the
process.

For those interested in using it, please note that the transmitter is still
WIP. In particular, I have tested it somewhat thoroughly in software and I
am confident it works as it should (we have included a full transceiver
example in the corresponding directory). I am now seriously testing it in
over-the-air transmissions with not-so-satisfactory results. However, I'm
leaving for some weeks for holidays, thus the announcement.

Feedback is, as usual, more than welcome.
best
Federico
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase Align two RFNoC Radio Blocks in GRC

[Simona Sibio]

Hi Felix and community,

I have the same problem with the phase offset.
I read that if you control the CORDIC module, you can synchronize the phase
in USRPs.
I found the following commands for UHD for receiver and for transmitter:

uhd::stream_cmd_t
 stream_cmd(
uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE

);
stream_cmd.num_samps = samps_to_recv;
stream_cmd.stream_now = false;
stream_cmd.time_spec = time_to_recv;
usrp->issue_stream_cmd(stream_cmd);
uhd::tx_metadata_t
 md;
md.start_of_burst

= true;
md.end_of_burst

= false;
md.has_time_spec

= true;
md.time_spec

= time_to_send;
//send a single packet
size_t num_tx_samps = tx_streamer->send(buffs, samps_to_send, md);


Also, I read that I can do the synchronization only with X-series.
Maybe, I cannot do the synchronization in phase with the N-series because
there is the FPGA Spartan 6, doesn't it? Or is there some other problem?

Thank you for every help.
Best Regards,

Simona

Il giorno ven 30 ago 2019 alle ore 15:49 Felix Greiwe <
felix.gre...@tu-dortmund.de> ha scritto:

> Hello together,
>
> I am trying to transmit one complex cosine from both TX - Antenna of my
> USRP-x310 with two UBX-160 Daugtherboards. I am transmitting a cosine with
> the frequency of 100 kHz and the center frequency of my RFNoC Radio Blocks
> is 2.45 GHz. So basically I see a peak at 2.45 Ghz + 100 kHz at my
> spectrum analyzer (plus the lo leakage at 2.45 GHz). Additionally I
> receive the spectrum on another x310.
>
> In the following link you can see my flowgraph in GRC:
> https://ibb.co/7W6mTKf
>
> As you can see i have two multiply blocks to change the phase of the
> complex cosines, the value of the multiply blocks are
>
> > pow(math.e, 1j*phi*(math.pi/180)) and
> > pow(math.e, 1j*psi*(math.pi/180)).
>
> I can change phi and psi with a qt gui range slider. Default value ist
> multiplication by 1.
>
> My goal with this setup was to check the MIMO capabilities of the USRP
> x310.
> I calculated the Phase offset both transmitted waves should have at the
> antenna of my spectrum analyzer. With my multiplication blocks I created
> different phase offsets, thus causing destructive interference at the
> receiving end (peak at analyzer is the smallest at this phase).
>
> However most of the time when I start different runs of my flowgraph (or
> when I power cycle the device) I always have to set a different phase
> offset to see the destructive interference. To me it seems pretty random
> which phase offset both transmitting path get even though i don't
> understand why.
>
> In another thread I read that maybe timed tuning will work for me but I
> did not quite understand what that improves in particular nor who I use it
> in my  GRC generated python file. (Using the RFnoC Radio Blocks does not
> make it easier by the way.) This is the link:
>
>
> http://ettus.80997.x6.nabble.com/USRP-users-use-a-usrp-x310-as-MIMO-transmitter-daughterboard-synchronization-tt11642.html
>
> Any ideas, suggestions and explanations on how to phase align the transmit
> path of my (single) USRP x310 would be greatly appreciated!
> (I posted to the USRP List too, but I think maybe it's more of a python
> code fix and not HDL where you guys are better in..)
>
>
> Best regards
>
> Felix
>
> P.S:
>
> One last point if that helps: When I use the same setup with the USRP sink
> block with two inputs the phase seems to be locked and does not change
> with each new start of the flowgraph, even though i did not use timed
> commands there. When I try to use the RFNoC Radio Block with two inputs it
> does not work at all.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Errors trying to build gr-radioteletype for version 3.8

[Barry Duggan]

I tried to build gr-radioteletype for version 3.8 and got the following 
errors:


"""
pi@raspberrypi:~/gr-radioteletype/build $ cmake 
-DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release ../

CMake Deprecation Warning at CMakeLists.txt:54 (cmake_policy):
  The OLD behavior for policy CMP0026 will be removed from a future 
version

  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only 
under
  specific short-term circumstances.  Projects should be ported to the 
NEW

  behavior and not rely on setting a policy to OLD.

CMake Deprecation Warning at CMakeLists.txt:57 (cmake_policy):
  The OLD behavior for policy CMP0043 will be removed from a future 
version

  of CMake.

 (ditto of above)

CMake Deprecation Warning at CMakeLists.txt:60 (cmake_policy):
  The OLD behavior for policy CMP0045 will be removed from a future 
version

  of CMake.

 (ditto of above)

CMake Deprecation Warning at CMakeLists.txt:63 (cmake_policy):
  The OLD behavior for policy CMP0046 will be removed from a future 
version

  of CMake.

 (ditto of above)

-- Boost version: 1.67.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Checking for module 'cppunit'
--   No package 'cppunit' found
-- Could NOT find CPPUNIT (missing: CPPUNIT_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:143 (find_package):
  Could not find a configuration file for package "Gnuradio" that is
  compatible with requested version "3.7.2".

  The following configuration files were considered but not accepted:

/usr/local/lib/cmake/gnuradio/GnuradioConfig.cmake, version: 
3.9.0.0-git


-- Configuring incomplete, errors occurred!
See also "/home/pi/gr-radioteletype/build/CMakeFiles/CMakeOutput.log".
"""

It appears that the CMakeLists have not been updated for 3.8.

--
Barry Duggan KV4FV

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio