Open whallmann opened 1 year ago
Is there no error printed at all? None of the error messages should be inhibit when using start_rtlsdr.sh
Hi Mark
indeed, no Error messages at all. If next balloon comes in reach, i will save the console output and push it here. tnx
Mark Jessop @.***> schrieb am So., 29. Jan. 2023, 22:25:
Is there no error printed at all? None of the error messages should be inhibit when using start_rtlsdr.sh
— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/125#issuecomment-1407773781, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKZWUCROH4QMR6LYZPEGYLWU3N4JANCNFSM6AAAAAAUKLE6GU . You are receiving this because you authored the thread.Message ID: @.***>
I got news today. i put verbose mode to the demod module - file atached. I see also a second and more packets flowing throu. Then i added instead a verbose to the python and added to logging.info before and after the read cmd from stdin. I see its reading on that stdin but did not got anything more then the first decoded packet from the demod module. I am not a real unix guy but i think the pipe maybe not work properly, or alternativly the demod do not send a second packet to then uploader. How to investigate more? Some ideas? Wolf DF7PN
What signal are you testing this with? I would suggest verifying operation with a local transmitter that transmits at known regular intervals, rather than listening to something in the air.
I did this with the Sonde IDA with good signal. It shows on amateur.sondehub a V1 binary on sidebar. Sure i have a sonde ready in testmode with horus-v2 mode lying but i dont think this produces other results. what workflow you suggest Mike? i will do my very best to catch this.
Mark Jessop @.***> schrieb am Mi., 8. Feb. 2023, 22:34:
What signal are you testing this with? I would suggest verifying operation with a local transmitter that transmits at known regular intervals, rather than listening to something in the air.
— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/125#issuecomment-1423268314, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKZWUD7OUB3MIA6DTCAP3DWWQGMRANCNFSM6AAAAAAUKLE6GU . You are receiving this because you authored the thread.Message ID: @.***>
There are a few things that could be happening here:
I noticed you have your frequency estimator bandwidth set pretty narrow (2.5 kHz wide), is there a reason for this? If the signal drifts near the edges of that bandwidth, then it will stop decoding.
Some news about that problem: now there is a local rs41 prepared to HorusV2 mode with lowest tx power. I activated -v (verbose) on the decoder module and noticed, that the checksum rx /tx is only on the first packet ok. The following packets never will match the both values on horus v2 mode again. Tried 20 samples rushing over the screen after each restart. If i abort and started the rtl_sdr.sh again the first packet matches the rx/tx crc again, the following never do.
I tried different levels on gain - and naturally drop a 10k value to the bandwidth setting.
Did you ever heard about this funny problem? What else i can dig in?
Unfortunately I'm not sure what going to be going on here...
What might be useful is to get a recording of the IQ that I can have a look at? You could do this by replacing the final line in start_rtlsdr.sh with:
rtl_fm -M raw -F9 -s 48000 -p $PPM $GAIN_SETTING$BIAS_SETTING -f $SDR_RX_FREQ > test.bin
60 seconds should be enough.
Here we are Mike: unfortunately today less packets are decoded. Same condx as yesterday. Do not now whats going on. Maybe the bin file helps. otherwise ask for more. tnx. test.bin.tar.gz
It looks like the first 2 packets decode OK, the last one doesn't. Looking at the file I don't see anything obviously wrong with the recording.
I'm stil unsure what the issue is sorry... I think it might be worth trying this out with a different receive system, perhaps use the RTLSDR with something like SDR++ and feeding demodulated audio into Horus-GUI, as a separate test of the SDR.
Ok Mike. I see i must change the computer. Now its a debian 11 laptop. Followed the instruction on page: https://github.com/projecthorus/horusdemodlib/wiki/1.2--Raspberry-Pi-'Headless'-RX-Guide
but after running start_rtlsdr.sh this messages comes on screen. Can not handle with this messages, sorry. So stopped again.
3: Realtek, RTL2838UHIDIR, SN: 00001002
Using device 3: Generic RTL2832U OEM
Traceback (most recent call last):
File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/wolfgang/horusdemodlib/horusdemodlib/uploader.py", line 18, in
This suggests that the horusdemodlib library isn't correctly installed for some reason. Are you running this all within a virtual environment, as is described here: https://github.com/projecthorus/horusdemodlib/wiki/1.2--Raspberry-Pi-'Headless'-RX-Guide#25-installing-the-horusdemodlib-python-library ?
Yes sir, i did used this venv. but meanwhile i think i hold you to long with this. Close this issue. There a better things to go for, hi hi. 73 Wolf
Mark Jessop @.***> schrieb am Mi., 15. Feb. 2023, 22:47:
This suggests that the horusdemodlib library isn't correctly installed for some reason. Are you running this all within a virtual environment, as is described here: https://github.com/projecthorus/horusdemodlib/wiki/1.2--Raspberry-Pi-'Headless'-RX-Guide#25-installing-the-horusdemodlib-python-library ?
— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/125#issuecomment-1432081033, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKZWUFDRUPPMXXVSL4O6D3WXVFFTANCNFSM6AAAAAAUKLE6GU . You are receiving this because you authored the thread.Message ID: @.***>
here is the solution:
After a long time of playing around with parameters, i droped the -F9 param of the rtl_fm program. Suddenly the decodes runs smoothly now. please check if this -F9 is nessesery on the sample sh files.
The -F9 option is important, as it provides better channel filtering. It does use somewhat more CPU, but i didn't think it would have been enough to cause any issues.
Ok F9 is needed, so my Core2 cpu is 100% under load and data gets lost. Now a borrowed RPi3 with core 4 cpu stands here and everything is normal. Sorry for that trouble. Maybe i overread that hint for cpu usage?! 73 wolf
What platform were you running this on when you had issues? I know of a few people that have been running it on a Pi Zero W OK.
The board was an BananaPi M1 and supported by armbian https://www.armbian.com/. I selected an console version with no gui. While looking with htop there were 2 cors schown but one done nothing and other hangs on 100% Maybe i had to watch this CPU load earlier. 😕
I wounder why the last line in start_rtlsdr.sh with pipe signs seperated programms decodes only one transmission of horus v2 after start. If i cancel the batchfile and restart it again, the next paket will be decoded. Then silence again. I tried to start the programms seperatly they show data running over the console. So it seems they talking to each other. What kind of trace is available and what kind of data is interessting?? 73 Wolf DF7PN