Sorry to stole some more bandwidth on this group about this topic and not on the Digital one, hope to be of general interest.
That's not a problem that Walter could solve. It lives on any start point, in ours machine, where we run each PSK program and thus also on the MMVARI application use by the RBS collectors.
Each PSK program by itself doesn't report the audio offset. Even RXing, as the RBN worse, using MMVARI in background wouldn't be easy at all. Adding, or subtracting, the audio offset isn't one of the bullets to be fired by MMVARI. It may doesn't even give the provision to give back the audio offset data for each decoded signal as to do the math inside the RBN ... AFAIK MMVARI, and others PSK decoders, doesn't have this ability.
... one palliative solution would be be to use a tied filter, 50/100 Hz, RXing and to move this thing window slowly over the PSK sub bands. Then you would have a decode at CAT QRG plus or minus the filter offset. In short for a filter large 50 Hz and centred at 1500 Hz when you listen somebody at 14070,100 the real QRG would be at 14071,600 +/- 50 Hz.
But it is too slow and too tricky.
Think about having you at home such a thin RX filter and the need to find a correspondent over a 3 KHz space. you would have 3000/050 (60 stops) steps or the the double steps number (120 stops) to be sure to get who is on the edges of yours tiny RX window, not feasible. More, the time you would spent gearing CAT QRGs toward the 3 KHz slice and waiting to decode for the whole 3 KHz would be, worst case, 120 times the time you will spend to decode the full 3Khz. This even using SDR.
Whe are speaking about seconds that are needed to get in sync with the PSK signals and to decode any valid signal as to spot it, not 73 or GL, but call signs and CQ or other strings pairs, whatever they are. The first time is < than 5 seconds, but the second one could take much more time or, even if properly decoded, any signal will not be spotted.
So what we would need, it may be, a new PSK founding library that would take care of the audio offsets as the radio QRGs ...
Things aren't changing so much for ours programs since a lot of time ago, absolutely a lot. Programming efforts is heavy, ours radio doesn't offer consolidated features (modelas are preaded over years) and several more reasons give us such a scenario as we face today.
But then a subtle question arise, why the same software doesn't present the same behaviour in RTTY ... well, I suspect that ... any suggestion out there?
Hope my non native English make all this readable ...
73 de iw1ayd Salvo