-
Notifications
You must be signed in to change notification settings - Fork 189
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
181 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bpsk decoding works fine here
using filter 300/950 and x16 magify
sadly x32 shift it out of the view!!! could the clever programmers make the software that HIGHER zoom ratios keeps signal inside the display?? (shift 3 kc left or right depending on lsb usb setting in x32 zoom)
x32 zoom ratio will only be used for ssb or cw or rtty ... not for am or fm
so adding that shift (only in display not in frequency setting) and we could use the higher zoom ratio for precise tuning on a signal (example in psk or rtty)
finding the correct qrg is a bit tricky ... but overall decoding in bpsk seems to work fine (that is what my first results are after just a few minutes testing)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Eriks, hi Sigi,
could one of you explain to me how to find the centre frequency?
It doesnt say in the code . . .
What is the frequency where the PSK decoding takes place?
73 Frank
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, now I had the first decoding! GREAT WORK, Eriks!
The frequency where to centre is the line in the middle of the filter passband, which is displayed when you switch to PSK-L or PSK-U.
Cool!
But it needs really strong signals, S9+20dB with > 20dB SNR, otherwise no decoding possible
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
congrats ... but it does not need 9 + 20 signals here when i use the 300/950 filter
but it needs a more or less clean signal ... yes (time to build some more filters?!?)
a narrow filter around 1000 hz that is matched to the bw (so for psk only 100 to 150hz or so)
here i had also good decodes with lower signals but tuning is very tricky
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, you are right, now I decoded several signals of much lower strength.
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still work in progress, especially, regarding filtering.
There is an IIR bandpass filter as the first step of PSK decoding, but apparently it is not optimal. Currently the frequency shift is constant at 1000 Hz. In the future it could be possible to attempt decoding within wider range at the same time (like Fldigi does), but I don't know if that will work due to performance limitations. Meantime, for this reason I would like to have separate PSK filtering and not relying on general filtering mechanism. If choosing 300/950 filter works significantly better, it means I need a sharper filter.
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment, the filtering does not seem to be the problem, but finding the precise frequency. How precise does your algorithm need the frequency to be tuned by the user in order to decode correctly?
If it is not necessary to be tuned very accurately, then your IIR seems to be too narrow, because the whole thing is very sensitive to frequency offtune.
If we use the FFT magnitudes of the 16x display as a start and use a snap algorithm as the one used in AM/SAM, we could autotune to the PSK carrier with an accuracy of under 1 Hz, I would say . . . :-)
Do you think that would be helpful for the decoding? But that would only be a help for decoding ONE PSK signal. If you really want to decode several of them at one time, you would need several NCOs, I think.
Just a thought . . .
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
512 point FFT over 48kHz with magnify 16x is:
48000 / 512 / 16 = 5.85Hz per bin
So a three-point-interpolation of a quadratic parabel could easily do the desired frequency estimation of the PSK carrier with an accuracy of a few 0.1Hz, which could be used to adjust the receive frequency to the exact PSK carrier. What do you think?
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for an easier tuning for the end user you should add a 3kc shift to the x32 zoom mode
then you have a better view of the signals
and add a narrow filter around 1000hz (wide enough for 125 bpsk of switchable depending on selected mode??)
sure an autotunig only works for one signal ... but that is ok
user tunes in a signal that he hears in the filter ... the press snap and it is finetuned ... thats ok for normal use
decoding several at once is to be left for pc software :-)
the decoding also has to have a not tooo fast afc for signals with a slow drift over time (say other stations is heating up and slowly drifts a bit ... then either the vfo or the decoding window has to follow the signal
so ... decoding has to have a slow afc ... plus you have to add a fast snap on the signal function for easier use
... BUT FOR THE FIRST TESTS THAT I HAVE DONE HERE ... THUMBS UP :-)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Sigi,
audio filtering is not necessary, as Eriks has a separate very sharp bandpass directly in the PSK decoding routine. So the filter you choose does not matter as long as 1000Hz is inside the passband. The audio you hear does not reflect the auio that is being decoded ;-).
And I will think about the magnify mode. It is not easy to have an frequency offset, probably impossible with slow processors.
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
audio filtering is needed that the user can hear that signal (and not a mix of 10 signals ... otherwise not easy to tune in) ... and what is when you wanna decode a signal at 1000hz and a stronger station inside passband of the filter lowers agc (so low that your 1000 hz signal falls down in noise)????
if you wanna hear low signal levels (and tune them in) then a narrow filter also for the audio (and agc chain) is a must (remember with that narrow filter it worked better right?!?)
with a narrow filter is easier to tune in a signal plus decoding goes lower down in the noise
....
for the shift ...
shift the zoom view ONLY in x32 zoom
that should not be difficult and also doable with the slow cpu and ram i have in my mchf :-)
carrier point then is on left or right display edge and you see the "full 3 kc passband" instead of viewing only half the ssb filter (lower end) plus half of the the not used "wrong" sideband
and that should be possible also with slow cpu and low ram
otherwise the x32 zoom mode is more or less useless
then a better manual tuning is possible (maybe even 2 markers where the signal has to be centered instead of the one marker we have now?!?) ...
shift is needed in ssb, rtty, cw and bpsk (freedv?)
but only in that narrow modes a user will ever use x32 zoom mode (so not needed in am, fm)
in am and fm a user will only use max x4 zoom but for narrow modes the full view would be nice
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needed signal here is about s5-s6 (with noise hovering around s4)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you asked where the frequency is in the code??
is it "define psk offset 1000hz" ?!?
add a snap funtion and we have no problem anymore with tuning in :-)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
peakfilter is useless ... that sure could be improved
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My plan is to simulate decoding on PC using the same C code and random bitstream with variation in frequency and noise added. In this way selecting the best performing filter. Likely, there shall be 3 different filters for psk31, 63, and 125.
Adding a snap function would be good. I, also, agree to the comments about 32x zoom and display shifting. If anyone could look at those issues, it would be great.
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
in 32x zoom we have 48kHz/32=1.5kHz viewable spectrum, so it is +/- 0.75kHz. Wouldn't it to be easier move the 1kHz decoding to lower freq? For example 500Hz? If you shift the whole spectrum, you have to move it according to receiving side (PSK-L, PSK-U).
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eriks, your approach to test variation and performance on the PC sounds very good and straightforward!
I will try to add a SNAP function in the next week.
One idea for proceeding: would it be good to add on-the-fly-calculation of the IIR coefficients in the code? We do this already for the bass, treble and notch IIR filter in the audio path. The way how to do this is here (but I guess you already know this source :-)):
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt
see also in our UHSDR code in audio_driver.c: function AudioDriver_SetRxTxAudioProcessingAudioFilters
So you just pass the frequency and the Q of the bandpass to the function and your coefficients are calculated. (that is for biquad filters, i.e. a simple 2nd order IIR or cascading stages: 4th order, 6th order etc.).
The advantage would be that we would not have to decide now which centre frequency we use for PSK decoding.
The most important advantage would be that the IIR filter coefficients could be adjusted by the frequency estimation of the SNAP algorithm, so that the IIR filter could be positioned exactly even if the user has adjusted to the wrong frequency. AND: it would even make decoding multiple PSK signals possible, if you implement several IIR filters with different frequencies . . . [well, we would have to think about a way to scan the whole frequency range and then perform the snap algorithm for each signal found, but that is for a much later point in time, I think ;-)]
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slawek, yes, I think it would be much easier to take a lower frequency for decoding, eg. 500Hz!
The frequency translation for the IF (+-12kHz) has low processor load and is fixed to translation by 12kHz, the frequency translation by +-6kHz is much higher in processor load and could be adjusted to translate different IFs including the offset for the display.
BUT: we would have to include this offset in every little bit of the code in the whole audio chain, which is a work load I would not be able to spend on this.
So, 500Hz centre frequency for PSK would be a good idea, what do you think, Eriks?
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then use same as in cw (default 700hz) ... would make things easier when you can use same narrow filters that we also use for cw decode (now i use the 300hz shifted up to 950 but that is sure not the best solution)
i was asking for a REGULAR SHIFT of plus minus 3 kc when using upper lower sideband and x32 zoom ratio ... then in ssb you see the whole filter (and not lower half plus half of the unused passband
i am sure the clever programmers can add that shift without needing tooo much additional ram
ok so what about using lower tone ... say 700hz?!? (same as cw) ...
my keyboard beep is also set to 700hz (and after a while you can tune in each cw station by ear when you are used to hear that 700hz with every keypress ...
i was asking for that shift cause then tuning by view is a lot easier in EVERY mode (rtty, freedv, psk etc.)
my first tests with switching on the peak filter were not so good ... i could better HEAR the signal but decoding was not as good as when not using peak filter
if you can add a snap function (snap to sidetone ... not carrier in ssb modes) that would make tuning supereasy ... when that is then solved (with snap) we can think about also making the psk decode usable with nr and /or peakfilter (maybe some "buffers needed" ??)
so i would say use the sidetone frequency ... automagically set filter centered around that (default 700hz in cw and also in bpsk .... maybe also rtty could be shifted down to that?!?)
the user already can set the frequency used in the menue ... so then just use it in all digital modes (when possible) .... and add possibility of using nr or peakfilter
maybe nr disturbs signal too much but peakfilter could be usable
no need for decoding several signals at once ... lets just make ONE decoding window perfec
that is enough for a qrp rig ... having a panoramic view with several psk signals decoded at once is for fldigi (or similar pc apps)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Sigi,
I try to structure the points a little bit:
1.) AGC
I think there are good reasons not to use AGC at all when you are doing Digimode DXing
http://elecraft.365791.n2.nabble.com/AGC-and-RTTY-Decoding-was-K3-AGC-White-Paper-td7627781.html
So the argument of having narrower filters because of AGC action does not hold.
2.) NR, peak filters etc.
As Eriks has pointed out, there is no point in using sophisticated filtering in the audio chain, because the PSK algorithm already has the right filtering (which Eriks will be tweaking in a very sophisticated way!). So DO NOT USE any filtering/noise reduction etc. with PSK, otherwise your results will be worse!
3.) Audio chain vs. Digimode signal chain
try to start thinking of digimode decoding inpendently from the audio chain. What you decode, differs from what you hear! There is no point in hearing when using Digimodes. The audio chain in UHSDR differs from the signal path in the digital decoding (at least in the last part of the signal processing ;-)).
4.) magnify 32x
As Slawek has pointed out, we only have 1.5kHz bandwidth in 32x magnify mode. So an SSB signal does not fit in. As you pointed out, we can program an offset, but that is impossible (correct me if I am wrong) without considerable processor load (we need an additional NCO for that). So not possible with mcHF for example.
My suggestion: Let us try different things in the next weeks, not expecting too much from the results :-).
A priority list could be:
tweak internal PSK filters (Eriks): [No, you will not hear that in the audio ;-), but you will see the improved PSK decoding capability]
try out SNAP option to snap a PSK carrier as accurately as possible (Frank DD4WH)
improve documentation of PSK decoding in the Wiki (Frank, it would be nice, Eriks, if I can come back to you for some questions for that purpose)
think about a better way of optically seeing the PSK signal in order to finetune/AFC the signal during decoding (this could be 32x magnify, but maybe it will be something totally different)
it would be good, if every testing could be carried out under STANDARD conditions with 500/950Hz filter, WITHOUT AGC and WITHOUT any NR, WITHOUT peak filter, WITHOUT notch filter. That ensures comparability and then we can interpret better decoding results directly as a cause of better internal PSK filters.
Is that alright for you guys?
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I just dreamed on something like IC7300 has... The divided screen for "normal view" and zoomed receiving part of it... But definitelly not in mcHF, we have better UI ;)
IC7300 has worse resolution display (480x272) but more powerful DSP core (TMS320... + FPGA). But this is the mellody of the future :)
73 Slawek
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm, very good point!
only for large screen:
If the screen could be divided as in DUAL mode, this could be relatively easy:
Needs considerable horsepower, but should be possible in the STM32F7
But you are right, there are other priorities right now :-)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one question (sorry, my knowledge on Digimodes is rather poor):
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DD4WH The plan looks good. My short term action list is a) filter experiments (tests on PC with random generated data, testing on-the-fly IIR filter generation, etc..); b) check impact from moving to 500 Hz frequency; c) some other decoding algorithm tuning ideas (e.g. calibration of convergence coefficient).
Speaking about display, besides zooming for better tuning, I see a different issue (I wrote about it earlier under #1002) - overall display arrangement is not convenient for working with text modes. E.g. received text is quite quickly scrolled off the screen. I would love to see received text in a separate line or window than text being sent (as it could be sent from a buffer or from memory and it is important to see what is sent already and which part is not sent yet). Now that we have split spectrum/waterfall option, I start to think about split waterfall/received text screen (sent text to be still displayed on the existing text line). Feedback or considerations regarding this are welcome.
And yes, I personally love to hear the sound of PSK signal, especially during tuning. Not a must, but still important :)
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to move this discussion to #1002, so that more people notice this and participate.
7257ce5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
the move to 500 Hz makes most sense to me as it keeps the processor load where it is today and does not require any other change besides in the BPSK code.
However, I don't agree to the conclusion that a "variable" shift would require changes throughout the whole audio chain. We could apply the "normal, fixed" shift for the audio chain data and use a second "variable" shift just for the zoom data (more memory and more processing time required due to doubled shifting and use of a more cpu intensive shifting, but this may not be much extra load).
Or we simply double the size (i.e. resolution) of the Zoom FFT and throw away part of its output before displaying it (more memory and more processing time required) .
The second option is a little easier to implement as it basically requires "just" resizing of some parameters and the implementation of a "window" on the Zoom FFT data.