Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

122-16, 384khz bw and sdr_receiver_hpsdr_122_88 #1040

Closed
F4HTB opened this issue Mar 21, 2022 · 11 comments
Closed

122-16, 384khz bw and sdr_receiver_hpsdr_122_88 #1040

F4HTB opened this issue Mar 21, 2022 · 11 comments
Labels

Comments

@F4HTB
Copy link

F4HTB commented Mar 21, 2022

Description of the setup:

  • Device: redpitaya 122-16
  • SD card image: red-pitaya-alpine-3.14-armv7-20211119.zip
  • Application: sdr_receiver_hpsdr_122_88
  • Other relevant information:

Server on HP DL 380 G7 24x3.4GHZ, dédicated network card HP NC364T.
Linux ubuntu 20.04 custom kernel up to 384khz alsa loopback
Tested with gnuradio https://github.com/Tom-McDermott/gr-hpsdr and https://github.com/F4HTB/hpsdr2alsaconnector

Description of the problem:

Hello Pavel, I hope you are good at this moment.
I comme back to some redpitaya project for f4kji websdr.
I have buy 3 years ago a redpitaya 122-16 and dev a litle arround McDermott code to make hpsdr2alsaconnector tool.

I have mount my new old server with characteristic as mentionned.

I have try on 7 rx 192khz without problems more than one day. After i stop it.
When i try on 384khz i get lots of underrun very quickly when i use more than 3 rx.
So i try a script based on gr-hpsdr like actual F4KJI production method on a 125-14 RP.
I have the same effect.

It's like if sdr-receiver-hpsdr was sending at a rate below what would be needed for 384khz.

I try on my laptop is same.

I check irq, hadware, network bandwith, cpu usage on server and redpitaya.
Nothing indacate a saturation of ressources.

I check the sdr-receiver-hpsdr code and see some usleep in while loop for sending datas.
Maybe must be reducted for 384khz?
I try to compile it on a raspberry pi but it seems to dont work when i try to execute on the redpitaya.

I have thinking about something like hardware limitation on memory access is to slow something like 7192khz ~ 3.5384khz, so i try 3rx and seems to work but not 4 and more but i don't no if this limitation is real because I already tested my redpitaya 125-14 on 6Rx 384khz and it's work...

Many thanks in advance for all your reply.
73 F4HTB.

@pavel-demin
Copy link
Owner

I quickly compared the version of sdr_receiver_hpsdr that supported the 384k sample rate and sdr_receiver_hpsdr_122_88. Buffer sizes and usleep parameters are the same.

Could it be a network connection problem? 7x192k can work with 100Mbps Ethernet, but 7x384k requires 1Gbps Ethernet.

Could you please send me a GNU Radio diagram that I could use to reproduce the problem?

@F4HTB
Copy link
Author

F4HTB commented Mar 21, 2022

Hello Pavel,

Of course i verify and network link and force to 1gb full duplex.

I send my code on your email adresse because files dont come here.
But i am going to use the C code from my repo in the futur because of cpu usage gain.

Thanks for your reply.

@F4HTB
Copy link
Author

F4HTB commented Mar 21, 2022

I have of course test network with dd and nc command.
I seems to get up to 250Mbit/s.

@F4HTB
Copy link
Author

F4HTB commented Mar 29, 2022

Hello Pavel,
I just whant to ask you if you have receive my email with the grc file on your mailbox?
73!

@pavel-demin
Copy link
Owner

Hello Olivier,

I have received your e-mail and installed gr-hpsdr. So I can run your GNU Radio diagram. I did not have time to test it together with the Red Pitaya board. I will try to do it this week.

Best regards,

Pavel

@pavel-demin
Copy link
Owner

I can reproduce the problem.

Looks like the loop at lines 343-353 in sdr-receiver-hpsdr.c is not copying the samples fast enough and the FIFO buffers are being overrun.

If I comment out the last 4 lines of the loop, then I can run two instances of GNU Radio, each with 4 receivers at 384 kSPS. So it is possible to run up to 8 receivers with this workaround.

When running two instances of GNU Radio, the MAC addresses of the eth0 and mvl0@eth0 interfaces should be specified in the parameters of the hermesNB blocks.

@pavel-demin pavel-demin added the bug label Apr 2, 2022
@pavel-demin
Copy link
Owner

I try to compile it on a raspberry pi but it seems to dont work when i try to execute on the redpitaya.

Here are the commands to compile the code directly on the Red Pitaya board:

apk add gcc make
cd apps/sdr_receiver_hpsdr_122_88
rw
make
ro

@F4HTB
Copy link
Author

F4HTB commented Apr 3, 2022

Hello Pavel,

I have verify my hpsdr2alsaconnector code and found a bug in gr-hpsdr.
The reg information for receivers frequency is not corectly initialised in the hermers initialisation.
I have push a request on his repository for correction.

I have also correct my repo:
https://github.com/F4HTB/hpsdr2alsaconnector

hpsdr2alsaconnector is operational yet in normal opération 7x 192khz or 2 x 4 384khz as you have describe.

Thanks for all!

PS: if you whant to add my project to your webpage: http://pavel-demin.github.io/red-pitaya-notes/sdr-receiver-hpsdr-122-88/ is also okey :D

Many thanks and 73! F4HTB

@pavel-demin
Copy link
Owner

I now have a better optimized version of the sdr_receiver_hpsdr_122_88 application that works with 14 receivers at 384 kSPS. I use hpsdr2alsaconnector for 7 channels and GNU Radio for the other 7 channels and I can listen to FM radio on one of the GNU Radio channels without any problem.

If you want to try this new version, you can download it from the following dropbox link:

https://www.dropbox.com/sh/5fy49wae6xwxa8a/AAAAXYsmMI0RLBYzboc9nkwIa/sdr/sdr_receiver_hpsdr_122_88_20230115.zip?dl=1

@pavel-demin
Copy link
Owner

@pavel-demin
Copy link
Owner

The better performing version the sdr_receiver_hpsdr_122_88 application is now in the new release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants