> It would be better if you could use the 13.12 branch directly instead of
> copying files. Then I know we are testing exactly the same code.
> svn co svn://svn.code.sf.net/p/svxlink/svn/branches/releases/13.12
Ok I now checked out and compiled that version.
Things I changed locally (and for now are now gone again) are only:
- I added a couple of assert statements in places where I had seen it crash before (e.g. rattleOn)
- I made a small modification in the logging so that stderr was not redirected, and I could see
the actual assert failure. however, it could also be read in the coredump using gdb.
- when daemonized, I added a chdir /tmp so that it could actually dump core when running as svxlink user
- I had temporarily changed the upper limit of siglev from 120 to 200 late this week (after previous mail)
> Yes, it's probably so. There were two bugs. I have now fixed another bug which
> caused the voter to crash. I do not get exactly the same stack trace as you
> but I hope it's the same bug causing both the crashes.
> Please try the new code out. I hope it will fix your crash problems.
It is now running the unmodified 13.12 checkout.
>>> Have you properly calibrated the signal level measurements for all your
>>> receivers? If not, that could have been a reason for the system producing
>>> very low siglev values. Normally they should be within 0 to 100.
>> Ok it has been a theory in our group as well that the calibration has
>> something to do with it. But it was not completely pinpointed what the
>> exact requirements are. We have recalibrated several times, and at the
>> moment the values sometimes are slightly below zero but not -100 anymore.
>> So while this may have been a factor, it probably is not the cause of the
>> current problem. I sometimes see values slightly above 100 (e.g. 109), is
>> that a problem as well?
> 109 is not a problem but too high values may be a problem. There is an upper
> limit of 120 above which SvxLink will interpret it as a bogus value and
> instead report a zero signal level.
I had seen this and I changed this limit to 200 last thursday evening because I guess that
our secondary receiver sometimes peaks above 120 during normal operation. This may
explain the random switchovers that we sometimes hear (signal is good on secondary
receiver but suddenly it switches to main receiver, maybe because the siglev is above
120 for a short time and changed to 0 by that code, and then shortly afterwards it is below
It may even be that this situation causes the quick changeovers that ultimately make the
software crash on the main site. I noticed that this change would only be effective once it
was made on our secondary site, but I could not install it at that time.
> I'm not happy with this limitation but it
> was introduced as a workaround for receivers where unsquelched audio is not
> available. When the squelch close, SvxLink "hear" maximum silence and
> interprets this as a very strong signal. The voter will then switch to this
> receiver which of course is wrong. Since that is a special case, this behavior
> should probably be turned on by configuration. It's presently hard coded.
Ok now I understand the reason for that check. I already wondered what would be the
condition where a value above 120 would have to be considered as zero. Maybe it is better
to use a squelch signal via the RS232 port in that case, to fix the quality to zero when that
signal indicates the receiver is squelched. Or indeed put the limit in a config variable so it
has to be set only in systems like that.
The observation has been that the signal level mechanism works well in a clean environment,
but when there are other strong signals present locally there may be effects that make the
detector return bogus values or make the previously made calibration again invalid.
(on a site where several broadcast programmes are transmitted around 100 MHz there
unavoidably is a higher noise floor on 145 MHz and it of course is not completely constant)
The hardware we use at the central site (and will use on the secondary sites in the future)
has a calibrated RSSI (signal strength) value available on the management inteface, although
it is doubtful if we can poll it at a sufficient rate without making the firmware crash
(there appears to be such an issue).
When RSSI is available it could be used, possibly in combination with the existing mechanism.
(use signal/noise ratio for low SNR signals, returning a quality e.g. up to 50, and for stronger
signals use the RSSI with a transfer function that results in values 50..100)
Hopefully then we don't have to work with the measurements from signals with good SNR
anymore (where the small interferences have the largest effect on the detector now).