-
Notifications
You must be signed in to change notification settings - Fork 19
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
decode, computing efficiency #9
Comments
That CPU does not have NEON, which then needs to be emulated for the Polar list decoder. It also has very little cache. |
You should probably play with the OSD And then change the list See if that helps. |
Hello Ahmet
Thanks for your prompt reply. I will try that. What file should I edit?
Regards
El mar., feb. 20, 2024 a 9:41, Ahmet ***@***.***> escribió:
You should probably play with the OSD ORDER first and set it to two: CODE::OrderedStatisticsDecoder<255, 71, ORDER> osddec;
And then change the list SIZE to maybe four: typedef SIMD<code_type, SIZE> mesg_type;
See if that helps.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Hi again,
I recompiled with your instructions. Now decode runs very fast:
time ./decode /dev/null encoded.wav
symbol pos: 2326
coarse cfo: 1500 Hz
oper mode: 14
call sign: ANONYMOUS
demod .... done
coarse sfo: 0.0669286 ppm
finer cfo: 1500 Hz
Es/N0 (dB): 30.9216 29.7801 30.3704 31.0269
bit flips: 0
real 0m0.233s
user 0m0.179s
sys 0m0.022s
in a Raspberry 1, without NEON instruction set. But I don't know how robust it will be. I will test in real RF scenario.
En martes, 20 de febrero de 2024, 09:54:53 CET, Ahmet Inan ***@***.***> escribió:
decode.cc of course ;-)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
keep me posted |
Hello, My findings so far. As I posted above, decode modified with your notes now runs very fast in a RPi 1. I wanted to make a comparison on how robust the alternative version was, and planned to record signals and have them processed by the two decode versions. I wanted to do that in a computer as it runs faster. Now I can see that the modified program ends with segmentation fault after showin Es/N0 data. This only happens in the PC, as it runs fine in a RPi. I also tried downloading the latest version of "modem" and compiling it again, unmodified, and it also gives a segfault. But it works in RPi. |
You should also update the code repository. I made a lot of SIMD related changes lately that might cause the problems you see. If that does not help, please add more info here, and please give me the output of: |
Hello |
That's good to hear. I did more improvements in the DSP and CODE repositories and would be interested to know how well they work on the old pi as well. |
Hi, |
Hello,
Not really an issue or a bug, but a question. I can run decode command in a linux computer with i5 cpu; the computing time is 50 ms. I have compiled your program in a Raspberry pi 1 model B with BCM2835 (ARM1176JZF-S 700 MHz). There, decode takes exactly 10 seconds to process an audio file. I must say the program works and provides a nice result. Do you think this is the time it must reasonably take, or could it be improved maybe with a different compiling method? It puzzles me that the Rpi is 200 times slower than a regular computer.
The point of using a RPi is running, non-stop, a digipeater and http gateway, instead of using a desktop pc.
Thank you and best regards.
The text was updated successfully, but these errors were encountered: