Redsea is loosing contact? #94
Comments
|
Interesting, is there any possibility you could send me some of that raw
I know it's going to be a big file, but it would really help investigate this problem further. I also have some questions regarding your system:
|
|
The hardware is a raspi 3b where uname -mprs gives: Linux 6.1.21-v7+ armv7l unknown the redsea version is: redsea 0.21-SNAPSHOT by OH2EIQ a simple rtl_udp -l 0 -A fast -p 0 -s 171k -F -f 101.2M > rtl_udp_output raw data recording with approx 10 sec silence with squelch 1000 is in my cloud: https://magentacloud.de/s/g4sEoz6BwWy7qmP if you should need a dump with another parameters, please let me know! Thank you very much for your help! |
|
And does this file exhibit the problem? If you give the file as an input to redsea, what happens? On my M1 Mac I get the output below. If you get fewer groups (fewer than these 27), then I suspect you may have encountered an old mystery problem where redsea on 32-bit Arm Raspberry Pi has worse tolerance for very noisy signals. I've mentioned it in the wiki once but at this point I only have wild guesses as to what the reason might be. |
|
I tested on a Raspi 3 B and got the same result, so that theory was probably wrong. But something else was found that's interesting - when the squelched signal comes back, this causes our phase error tracker to momentarily imagine a phase error of 10^5 degrees... this throws the PLL frequency off target and it doesn't easily recover. I'll experiment with a limiter later. |
|
Yes, very interesting. I installed a 64 bit system on a raspi 3B and I could verify your test in 4, I got the same hex-data and the data in json: This looks very good, but nevertheless it stucks during life-performance like in 1 described. But you found an error in 5 :-) Thanks for helping! :-) |
After a period of digital silence, the PLL sometimes suddenly jumps frequencies and can't recover. This was caused by a large transient value of phase error (on the order of 10^5). Clamping the phase error seems to improve this.
|
@Saeco , if you could once more test if this problem has been improved by the latest commit in master. |
|
@windytan , hello, thanks, today I found time to compile an test it: it seems to work after silence perfectly and after noise very good and after crossmodulations of 2 stations during scanning the FM band manually satisfactory: it mostly comes back again, after noise sometimes it takes a little bit longer time than after silence to come back. But it's very good so far. I will watching it and give report, if there is a (reproducible) situation when it gets out of order. Thank you very much for your help! |
|
I tested it unter "working" conditions: while the rds processing is stable over hours and hours when the receiving is also stable, it is furthermore coming out of order, when scanning the band. I don't find a scheme, under with conditions My idea is: resetting the decoder with a token sending over an udp-port or resetting the decoder with a watchdog if the output is "quiet" for or than 10sec. What do you think of it? This would a smart solution to coming back to decoding without stoping listening. |
|
That's a really good idea! I'll try and have it reset the receiver automatically after some period of lost carrier. And I'll try to record some long-running test sets. Notes for my future self, I suspect the PLL frequency is slowly drifting into unrealistic territory when cross-modulation is happening or even with the presence of strong noise. After this, it can't find its way back. All noise-free stations seem to have a little less than 57 kHz - so maybe it's biased low. It's an interesting mystery that could be investigated at a later time. |
When carrier is lost the PLL keeps looking for it and starts drifting slowly. This can make it harder to lock on to the carrier when it comes back. One solution is to reset the frequency back to 57 Khz after 10 seconds of loss of block sync being detected. Open question: is the PLL interface being used correctly?
|
Has there been any improvement from these changes? |
|
I'm taking that as a yes, closing the issue. |
* Change any potentially overflowing signed variable to unsigned. Signed integer overflow is not well-defined in C++. * A signed integer overflow may have caused the 'reset' functionality of #94 to stop working after ~3.5 hours. * Another one may have broken the block synchronization after 41 days of data. * Document/cassert some lines that may look like a buffer over-read.
* Change any potentially overflowing signed variable to unsigned. Signed integer overflow is not well-defined in C++. * A signed integer overflow may have caused the 'reset' functionality of #94 to stop working after ~3.5 hours. * Another one may have broken the block synchronization after 41 days of data. * Document/cassert some lines that may look like a buffer over-read.
Hello,
I really appreciate your famous work you've done with this rds decoder - I'm using it in the combination with node-red and rds_fm/rds_udp and use node-red for switching channels / volume , displaying data ...
What I found out during making experiments what are the best parameters: sometime redsea seams to loose contact to rtl_fm/rtl_udp, especially when rtl_fm/rtl_udp is sending no data because the muting is set with squelch or the frequency is set the way, that the signal is very noisy - then redsea doesn't "find back" to correct demodulation. Here's an example:
$ rtl_udp -l 0 -A fast -p 0 -s 171k -F -f 101.2M | redsea --feed-throug 2>/dev/udp/127.0.0.1/4567 | demux -r 171k -R 44.1k | aplay -f S16_LE -c 2 -r 44100
After muting (squelch 1000) it doesn't find back after unmuting (squelch 0). The same effect is, when you hear noise for some time ... But every 30 sec (felt, not measured) redsea gives the pi of the station ... But the sound comes back again immediately when unmuting.
How can this be solved BESIDES starting all 4 processes in a row ...? It's not very nice for the listener to break listening just to get rds data again.
The text was updated successfully, but these errors were encountered: