request to port gr-lora

[LoraLightLuke]

​https://github.com/rpp0/gr-lora is a radio block for gnu radio

With a small tweak to CMakefiles.txt I get to the linking stage

if(APPLE)
    add_definitions(-std=c++11)
endif()

but there it fails

[ 23%] Linking CXX shared library libgnuradio-lora.dylib
Undefined symbols for architecture x86_64:
  "_volk_32f_accumulator_s32f", referenced from:
      gr::lora::decoder_impl::detect_preamble_autocorr(std::__1::complex<float> const*, unsigned int) in decoder_impl.cc.o

MacOS 10.12.6 AppleClang 8.1.0.8020042

[kencu (Ken)]

hate to ask this, but do you have volk installed?

<​http://libvolk.org/doxygen/volk_32f_accumulator_s32f.html>

one of these should provide that function.

volk @1.3 (science, comms)
    Vector-Optimized Library of Kernels

volk-devel @20170814 (science, comms)
    Vector-Optimized Library of Kernels

If you _do_, then perhaps there is a missing link library to be added to that CMakeFiles.txt.

[LoraLightLuke]

I had checked and even reinstalled it clean before filing the request

$ port installed volk
The following ports are currently installed:
  volk @1.3_0+docs+orc (active)

I'm ready to test a hint as to what that type of line I need to add to CMakeFiles.txt for that link...

[kencu (Ken)]

<​https://cmake.org/cmake/help/v3.5/command/target_link_libraries.html#command:target_link_libraries>.

Hard to imagine whoever wrote the cmake file doesn't have this in already, but you should find a line where that library is requested.

Other issues could be that it's not being found, or is built with the wrong (nonmatching) architecture.

Here's where your full build log would be useful, which is why we usually need that.

[michaelld (Michael Dickens)]

Another option is: ​https://github.com/BastilleResearch/gr-lora ... and I think this is the original. Is there a benefit to the rpp0 version over Bastille's?

The Volk linking issue is that Volk is probably not included properly in the CMake configure scripts. This is an easy fix.

[michaelld (Michael Dickens)]

Interesting: it looks like rpp0 & BastilleResearch created their respective gr-lora independently. Have to figure out a way to install multiple same-name GR OOT modules in parallel ... hmm ....

[LoraLightLuke]

The following white paper suggest that Bastille and gr-lora are one and the same... (see authors at top of paper) ​https://pubs.gnuradio.org/index.php/grcon/article/view/8

As for the question regarding CMakeFiles.txt content: there is no references to any libraries in there... but the reason I have requested a port is because I do not shine at this subject. I attach the CMakeFiles.txt and let you judge.

If you need a build log, tell me how to capture one and I'll upload it. Don't be shy with details ;-)

[michaelld (Michael Dickens)]

OK. So how about I get Bastille's version into MP first. Hopefully that will do the trick for you.

[michaelld (Michael Dickens)]

In 0735b7dbb0c51769f24c5b1061a67c8e77b06f8d/macports-ports:

gr-lora: new port.

addresses ticket #54709

[michaelld (Michael Dickens)]

The CMakeLists.txt file you attached does not look for Volk. I'd guess then that this is from the rpp0 repo, since Bastille's build out of the box without requiring patching.

I've pushed Bastille's gr-lora into MacPorts. Please update your ports & see if it works for you.

[LoraLightLuke]

OK, i try to load the new gr-lora port but cannot find it ( new to the macports ecosystem)

$ sudo port selfupdate
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.4.1 installed,
MacPorts base version 2.4.1 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
$ port search gr-lora
No match for gr-lora found

[michaelld (Michael Dickens)]

Hmmm .. my only memory is that it takes an hour or so for changes to go live. Maybe try again in a few hours? Sorry I can't be more helpful! I install everything from the MP git repo, which is updated very quickly.

[LoraLightLuke]

let me state that I am more than impressed with the speed at which you are helping out. KUDOS!

[LoraLightLuke]

Edited, I seemed to have missed the point that there is a separate demodulator and a decoder...

Good, the Bastille port works and I'll check it out

Considering the earlier remark that the fix might be easy, lets try to fix the rpp0/gr-lora variant and compare side by side?

The Volk linking issue is that Volk is probably not included properly in the CMake configure scripts. This is an easy fix.

TIA, L3

[michaelld (Michael Dickens)]

I just pushed ​https://github.com/macports/macports-ports/commit/f113c50278cd00d5c0413a078c8c453a7cfe8605 , which adds variants for the sources: +BastilleResearch and +rpp0. The default is the latter, since they are actively maintaining the port. I've patched everything to at least build and install and pass "make test" properly. Please "sudo port selfupdate" and then upgrade to get these changes & let me know if this helps. With your feedback, I can push changes upstream for them to consider.

[LoraLightLuke]

The rpp0 variant definitely compiles and loads in gnuradio so i'd say mission accomplished. Whether it is better than the Bastille variant will be found out in the near future. Do you consider it a criterium?

The Bastille variant had some flaws but at least the simulator part of it did something, although e.g. sending in test<cr> you got out tes

Thanks a million for this speedy help!

[michaelld (Michael Dickens)]

You're welcome! I don't consider which is better; I just try to get them to work. Glad they are both working for you. Have fun playing with them!

[LoraLightLuke]

Replying to michaelld:

You're welcome! I don't consider which is better; I just try to get them to work. Glad they are both working for you. Have fun playing with them!

I think you made a good choice by setting rpp0 as default. I have already been able to decode actual transmitted messages!

Question about MacPorts: if rpp0 makes new releases, do they flow into MacPorts automatically or is there a need for human action? (I do not refer to port selfupdate and port upgrade gr-lora that I would need to type obviously). I see that we have 5 commits since and rpp0 has declared this current state official as release 0.6.1

My impression that it is not automatic. So, what could I do to trigger a refresh?

[michaelld (Michael Dickens)]

I'm glad the gr-lora port is working for you & that's awesome that you've used it to successfully decode some signals!

No port (nor "port") will update itself; that requires human intervention. There are 2 things that happen here: 1) developers push changes to the MacPorts repo, and 2) end-users update those ports locally.

1) Luckily (for you and, maybe, others), that's where I come in. I update my ports weekly, plus or minus a few days with a few exceptions. If a new release version comes out, I generally try to update it as soon as I can. For devel (or non-release) ports, I'll update for critical fixes but otherwise just weekly. Thus, for gr-lora +rpp0, I see some fixes have already some in & I'll get them in place early next week.

2) On your end, to update your MacPorts install you can do:

sudo port selfupdate
sudo port upgrade outdated

As a MP developer I update pretty much daily to make sure everything plays nicely together. As an end-user, I'd recommend weekly to monthly -- but, you can always do a "selfupdate" and "port installed and outdated" to see what ports have updates compared with your current install & then update just those ports you really care about (instead of all of them via "upgrade outdated").

Hope this helps!