tom-mcdermott / gr-hpsdr Goto Github PK

Hello dear N5EG sysop McDermott,

I hope this time in the right place to ask for a feature request.

We are working with gnuradio and today several receivers on the protocol hermes / metis can with up to 6 receivers on 384khz.

So I would like to ask you if it would be possible to adapt your librairy to use these 6 receivers?

Obviously we are consicent of the implication that this requires and we thank you in advance.

We will not fail to quote you in our publications because it is the only way for us to prove our gratitude to you.

In the meantime, please accept my sincere thanks.

73 F4HTB

I'm using RedPitaya SDR in HPSDR receiver mode with CW Skimmer Server - it supports up to 8 receivers no problem.

Does the gr-hpsdr with RedPitaya SDR support 7 or is also capable of 8 receivers?

Hello Tom-McDermott,

My system components:

Ubuntu (Mate) 22.04.3 LTS
Gnuradio 3.10.1.1 (Python 3.10.12)
OOT gr-hpsdr 3.0-2build2
Radio Anan-100[D] - Software version: 5.4 (angelia)

The hermesNB module acknowledge the NIC's IP, but it shows a MAC address that is not the real one. The real one is showed by ifconfig command and HPSDRProgrammer_V2. By the way, there's only one NIC in my desktop.

1. When MAC Address is left in automatic ("*") in the properties of the module, the radio is not aknowledged:

Looking for Metis/Hermes card on interface enp2s0f0
Interface[0]:lo Interface[1]:enp2s0f0
enp2s0f0 IP Address: 169.254.15.238
enp2s0f0 MAC Address: 00:00:a9:fe:0f:ee <== unknown
unexepected discovery response when not in discovery mode
metis_start_receiver_stream unknown target. MAC: IP:

The flowchart interrupts itself, showing this message:

Done (return code 1)

2. The radio's IP is only recognized if the radio's MAC address were designed in module properties:

Looking for Metis/Hermes card on interface enp2s0f0
Interface[0]:lo Interface[1]:enp2s0f0
enp2s0f0 IP Address: 169.254.15.238
enp2s0f0 MAC Address: 00:00:a9:fe:0f:ee <== unknown
Metis MAC address 00:1E:C0:A5:C3:00 <== radio MAC address
Metis IP address 169.254.195.0

But the flowchart freezes and no output. When it is killed it shows this message:

Done (return code -15)

What would be the problem?

Thanks in advance for your attention.

Best regards.

lcomd

Hi Tom,

This is the error I had when I followed the instructions on building the interface with HPSDR,
and it shows after the 'make' command:

/Users/ben/gr-hpsdr/lib/metis.cc:163:19: error: use of undeclared identifier
'SIOCGIFHWADDR'
if (ioctl(sock, SIOCGIFHWADDR, ifr) < 0) {
^
1 error generated.
make[2]: *** [lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
make: *** [all] Error 2

and likewise the computer doesn't recognise this command too:

sudo ldconfig

Is there any method to resolve these issue?

Thanks,
Sam

Solved: see below..

I set up a simple flow graph with a constant source and a QT Frequency sink.

The flow graph is running, the verbose output is printing the information, but I see nothing on the spectrum.

The unit is an Anan 10E, the Hermes reported version is 12(dec) C(hex).

I do hear the input antenna relays change state when I change the antenna configuration.

I am set for a single receiver, at 48000.

I compiled and installed the source from the latest repository.

Is it possible that the Anan. Hermes I have uses revision 2 or a latter version of the protocol?

I am using Gnuradio 3.7 on Ubuntu 16, gnuradio installed from package.

Thank you in advance.

It seems gnuradio-3.9 dropped swig.

The following files were created when building gr-hpsdr-3.0 (from the https://github.com/Tom-McDermott/gr-hpsdr/releases/tag/v3.0):

/usr/lib64/libgnuradio-hpsdr.so.1.0.0git
/usr/lib64/libgnuradio-hpsdr.so.v1.0-compat-xxx-xunknown

The 1.0.0git suffix is weird (especially for the stable release) but somehow acceptable, the v1.0-compat-xxx-xunknown is crazy.

Hi,
I am doing a few tests with your great OOT on gnuradio 3.10 and I noticed that if:

• I close the flow graph window the plugin doesn't close/return correctly and only "kill the flow graph" button is enabled
• I try to close the flow graph with "kill the flow graph" doesn't close/kill the graph.

In attachment the grc that I use.
I moved from 3.8 to 3.10 therefore I don't know if this problem is present on 3.9.

thank you
hpsdr-test.grc.zip

When building on Fedora 29 the build fails with the following error:

/usr/bin/c++  -std=c++11 -DNDEBUG  -Wl,-z,relro  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rdynamic CMakeFiles/test-hpsdr.dir/test_hpsdr.cc.o CMakeFiles/test-hpsdr.dir/qa_hpsdr.cc.o  -o test-hpsdr -Wl,-rpath,/builddir/build/BUILD/gr-hpsdr-1.2/build/lib -lgnuradio-runtime -lboost_filesystem -lboost_system -lcppunit -ldl libgnuradio-hpsdr.so -lgnuradio-runtime -lboost_filesystem -lboost_system 
/usr/bin/ld: CMakeFiles/test-hpsdr.dir/test_hpsdr.cc.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: CMakeFiles/test-hpsdr.dir/qa_hpsdr.cc.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC

I used workaround:

cmake .. -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=true

which allows me to compile it.

Hi,

Python 2 will be unsupported soon, so Linux distro's are dropping Python 2 packages. E.g. in Fedora Rawhide (f32) all Python 2 packages without FESCO exception have been mass orphaned.

GNURadio 3.8 is fully Python 3 compatible, but GNURadio modules have to be ported to it. In Fedora downstream we used the following patch [1]. It's not the cleanest solution, but it helped us to keep the gr-hpsdr in the distro. We will switch to the upstream solution once available.

[1] https://src.fedoraproject.org/rpms/gr-hpsdr/blob/master/f/gr-hpsdr-1.2-gnuradio38.patch

The library should have soname, for Fedora I added dummy one (0.0), but maybe the package version (1.2) should be used instead.

I added the soname by:

set_target_properties(gnuradio-hpsdr PROPERTIES SOVERSION 0)
set_target_properties(gnuradio-hpsdr PROPERTIES VERSION 0.0.0)

I could create pull request if needed.

Hello,

Can you add one or more .grc examples using the hermesWB source?

Thank you!

Hello,

When the code start we call HermesProxy::HermesProxy to initialise.
HermesProxy::HermesProxy is calling UpdateHermes(); to send registers.

in UpdateHermes function we call only for two receivers at this moment:
Ligne 875 to 883.

BuildControlRegs(0, buffer);
metis_write(ep, buffer, length);
BuildControlRegs(4, buffer);
metis_write(ep, buffer, length);

BuildControlRegs(0, buffer);
metis_write(ep, buffer, length);
BuildControlRegs(6, buffer);
metis_write(ep, buffer, length);

this must be modified for all numbers of rx right?

Hello,

i need to turn on the Common Mercury Frequency, which would be a one for the MSB of C4 while C0=0.
Is there a way of achieving that with the hermesNB or is there an easy way to change that in the code of gr-hpsdr? That would be awesome.

thank you and best regards,
Hannes

Hello Tom, do these blocks send a timestamp with beginning of the stream and after any overflow?
I'm asking because when saving streams into a File Meta Sink the "rx_time" of the file header is always reading 0.0
Thanks for the great work.