Skip to content

Commit

Permalink
Implementation of BPSK receiving
Browse files Browse the repository at this point in the history
  • Loading branch information
phaethon committed Jan 21, 2018
1 parent a3f9dd9 commit 7257ce5
Show file tree
Hide file tree
Showing 2 changed files with 181 additions and 12 deletions.
168 changes: 156 additions & 12 deletions mchf-eclipse/drivers/audio/psk.c
Original file line number Diff line number Diff line change
Expand Up @@ -111,26 +111,39 @@ uint16_t psk_varicode[] = {
0b1011010111 // ~
};

#define PSK_BND_FLT_LEN 5

float32_t PskBndPassB[] = {
0.00068698,
0.000069360488,
0,
-0.00137396,
-0.000138720977,
0,
0.00068698
0.000069360488
};

float32_t PskBndPassA[] = {
1,
-3.40096044,
4.81713149,
-3.27487565,
0.92725284
-3.44370261,
4.94118045,
-3.40314202,
0.97658316
};

float32_t bnd_ibuffer[PSK_BND_FLT_LEN];
float32_t bnd_obuffer[PSK_BND_FLT_LEN];
float32_t PskCosDDS[] = { 6.12323400e-17, -9.95678466e-02, -1.98146143e-01, -2.94755174e-01,
-3.88434796e-01,-4.78253979e-01,-5.63320058e-01,-6.42787610e-01,
-7.15866849e-01,-7.81831482e-01,-8.40025923e-01,-8.89871809e-01,
-9.30873749e-01,-9.62624247e-01,-9.84807753e-01,-9.97203797e-01,
-9.99689182e-01,-9.92239207e-01,-9.74927912e-01,-9.47927346e-01,
-9.11505852e-01,-8.66025404e-01,-8.11938006e-01,-7.49781203e-01,
-6.80172738e-01,-6.03804410e-01,-5.21435203e-01,-4.33883739e-01,
-3.42020143e-01,-2.46757398e-01,-1.49042266e-01,-4.98458857e-02,
4.98458857e-02, 1.49042266e-01, 2.46757398e-01, 3.42020143e-01,
4.33883739e-01, 5.21435203e-01, 6.03804410e-01, 6.80172738e-01,
7.49781203e-01, 8.11938006e-01, 8.66025404e-01, 9.11505852e-01,
9.47927346e-01, 9.74927912e-01, 9.92239207e-01, 9.99689182e-01,
9.97203797e-01, 9.84807753e-01, 9.62624247e-01, 9.30873749e-01,
8.89871809e-01, 8.40025923e-01, 7.81831482e-01, 7.15866849e-01,
6.42787610e-01, 5.63320058e-01, 4.78253979e-01, 3.88434796e-01,
2.94755174e-01, 1.98146143e-01, 9.95678466e-02, 3.06161700e-16 }; // TODO to replace with soft_dds

soft_dds_t psk_dds;
soft_dds_t psk_bit_dds;
Expand All @@ -144,6 +157,23 @@ void PskBufAdd(int len, float32_t buf[], float32_t v)
buf[0] = v;
}

float32_t Psk_IirNext(float32_t b[], float32_t a[], float32_t x[], float32_t y[], int idx, int taps)
{
float32_t resp = 0;
int iidx;

for (int i = 0; i < taps; i++)
{
iidx = (idx - i + taps) % taps;
resp += b[i] * x[iidx];
if (i>0)
{
resp -= a[i] * y[iidx];
}
}
return resp / a[0];
}


#define PSK_VARICODE_NUM (sizeof(psk_varicode)/sizeof(*psk_varicode))

Expand Down Expand Up @@ -179,6 +209,41 @@ void Bpsk_ModulatorInit(void)
Bpsk_ResetWin();
}

void Bpsk_DemodulatorInit(void)
{
psk_state.rx_phase = 0;
psk_state.rx_bnd_idx = 0;

for (int i = 0; i < PSK_BND_FLT_LEN; i++)
{
psk_state.rx_samples_in[i] = 0;
psk_state.rx_samples[i] = 0;
}

for (int i = 0; i < PSK_BUF_LEN; i++)
{
psk_state.rx_vco[i] = 0;
psk_state.rx_sin_prod[i] = 0;
psk_state.rx_cos_prod[i] = 0;
psk_state.rx_scmix[i] = 0;
}

psk_state.rx_idx = 0;
psk_state.rx_last_bit = 0;
psk_state.rx_err = 0;
psk_state.rx_last_symbol = 0;
psk_state.rx_symbol_len = psk_state.rate / PSK_BUF_LEN;
psk_state.rx_symbol_idx = 0;

// for (int i = 0; i < psk_state.rx_symbol_len; i ++)
// {
// psk_state.rx_symbol_buf[i];
// }

psk_state.rx_word = 0;
UiDriver_TextMsgPutChar('>');
}


void PskDecoder_Init(void)
{
Expand All @@ -189,10 +254,10 @@ void PskDecoder_Init(void)
psk_state.rate = 384;
break;
case PSK_SPEED_63:
psk_state.rate = 96;
psk_state.rate = 192;
break;
case PSK_SPEED_125:
psk_state.rate = 48;
psk_state.rate = 96;
break;
default:
{
Expand All @@ -206,6 +271,7 @@ void PskDecoder_Init(void)
psk_state.tx_bit_len = lround(ts.samp_rate / psk_speeds[psk_ctrl_config.speed_idx].value * 2);
psk_state.tx_zeros = - psk_speeds[psk_ctrl_config.speed_idx].zeros;
Bpsk_ModulatorInit();
Bpsk_DemodulatorInit();
}


Expand Down Expand Up @@ -245,6 +311,84 @@ uint16_t Bpsk_FindCharReversed(uint8_t c)

void BpskDecoder_ProcessSample(float32_t sample)
{
float32_t fsample, sum_sin = 0, sum_cos = 0, symbol_out;
int8_t bit;

psk_state.rx_samples_in[psk_state.rx_bnd_idx] = sample;
fsample = Psk_IirNext(PskBndPassB, PskBndPassA, psk_state.rx_samples_in,
psk_state.rx_samples, psk_state.rx_bnd_idx, PSK_BND_FLT_LEN);
psk_state.rx_samples[psk_state.rx_bnd_idx] = fsample;
psk_state.rx_bnd_idx++;
psk_state.rx_bnd_idx %= PSK_BND_FLT_LEN;

psk_state.rx_vco[psk_state.rx_idx] = PskCosDDS[(int)(psk_state.rx_phase * PSK_COS_DDS_LEN)]; // TODO This shall be replaced with soft_dds
psk_state.rx_sin_prod[psk_state.rx_idx] = psk_state.rx_vco[(psk_state.rx_idx - PSK_SHIFT_90 + PSK_BUF_LEN) % PSK_BUF_LEN] * fsample;
psk_state.rx_cos_prod[psk_state.rx_idx] = psk_state.rx_vco[psk_state.rx_idx] * fsample;

for (int i = 0; i < PSK_BUF_LEN; i++)
{
sum_sin += psk_state.rx_sin_prod[i]; // Could be optimized keeping the sum in memory
sum_cos += psk_state.rx_cos_prod[i]; //
}

symbol_out = sum_sin / PSK_BUF_LEN;
psk_state.rx_scmix[psk_state.rx_idx] = symbol_out * sum_cos / PSK_BUF_LEN;

psk_state.rx_err = 0;
for (int i = 0; i < PSK_BUF_LEN; i++)
{
psk_state.rx_err += psk_state.rx_scmix[i];
}
psk_state.rx_err /= PSK_BUF_LEN * 100000.0;
if(fabsf(psk_state.rx_err) > 0.001)
{
psk_state.rx_err = 0.001 * ((psk_state.rx_err > 0) ? 1 : -1 );
}

psk_state.rx_idx += 1;
psk_state.rx_idx %= PSK_BUF_LEN;

psk_state.rx_phase += PSK_SHIFT_DIFF + psk_state.rx_err;

if (psk_state.rx_phase > 1)
{
psk_state.rx_phase -= 1;
psk_state.rx_symbol_idx += 1;
if (psk_state.rx_symbol_idx >= psk_state.rx_symbol_len)
{
psk_state.rx_symbol_idx = 0;
// TODO here should come additional part to check if timing of sampling should be moved
if (psk_state.rx_last_symbol * symbol_out < 0)
{
bit = 0;
}
else
{
bit = 1;
}

psk_state.rx_last_symbol = symbol_out;

if (psk_state.rx_last_bit == 0 && bit == 0 && psk_state.rx_word != 0)
{
UiDriver_TextMsgPutChar(Bpsk_DecodeVaricode(psk_state.rx_word / 2));
psk_state.rx_word = 0;
}
else
{
psk_state.rx_word = 2 * psk_state.rx_word + bit;
}

psk_state.rx_last_bit = bit;

}
}

if (psk_state.rx_phase < 0)
{
psk_state.rx_phase += 1;
}

}


Expand Down
25 changes: 25 additions & 0 deletions mchf-eclipse/drivers/audio/psk.h
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,14 @@
#include "softdds.h"

#define PSK_OFFSET 1000
#define PSK_SAMPLE_RATE 12000 // TODO This should come from elsewhere, to be fixed
#define PSK_BND_FLT_LEN 5
#define PSK_BUF_LEN (PSK_SAMPLE_RATE / PSK_OFFSET)
#define PSK_SHIFT_DIFF (1.0 * PSK_OFFSET / PSK_SAMPLE_RATE)
#define PSK_SHIFT_90 (PSK_BUF_LEN / 4)
#define SAMPLE_MAX 32766
#define PSK_COS_DDS_LEN 64
#define PSK_MAX_SYMBOL_BUF 384 // Maximum for 12000 sample rate and 31.25; for higher sample rate should value be increased

typedef enum {
PSK_SPEED_31,
Expand Down Expand Up @@ -47,6 +54,24 @@ typedef struct
int16_t tx_ones;
bool tx_ending;
bool tx_win;

float32_t rx_phase;
float32_t rx_samples_in[PSK_BND_FLT_LEN];
float32_t rx_samples[PSK_BND_FLT_LEN];
int16_t rx_bnd_idx;
float32_t rx_vco[PSK_BUF_LEN];
float32_t rx_sin_prod[PSK_BUF_LEN];
float32_t rx_cos_prod[PSK_BUF_LEN];
float32_t rx_scmix[PSK_BUF_LEN];
int32_t rx_idx;
int8_t rx_last_bit;
float32_t rx_err;
float32_t rx_last_symbol;
int16_t rx_symbol_len;
int16_t rx_symbol_idx;
// float32_t rx_symbol_buf[PSK_MAX_SYMBOL_BUF];
uint32_t rx_word;

} PskState;

extern const psk_speed_item_t psk_speeds[PSK_SPEED_NUM];
Expand Down

26 comments on commit 7257ce5

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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)

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 22, 2018

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

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 22, 2018

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

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 22, 2018

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.

@phaethon
Copy link
Contributor Author

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.

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 22, 2018

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 . . .

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 22, 2018

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?

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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 :-)

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 22, 2018

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.

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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)

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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 :-)

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 22, 2018

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

@phaethon
Copy link
Contributor Author

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.

@sp9bsl
Copy link
Collaborator

@sp9bsl sp9bsl commented on 7257ce5 Jan 23, 2018

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).

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 23, 2018

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 ;-)]

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 23, 2018

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?

@DG9BFC
Copy link

@DG9BFC DG9BFC commented on 7257ce5 Jan 23, 2018

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)

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 23, 2018

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?

@sp9bsl
Copy link
Collaborator

@sp9bsl sp9bsl commented on 7257ce5 Jan 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

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

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 23, 2018

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:

  • we already have the (512) FFT magnitudes for the spectrum (48kHz wide) which can be displayed in the upper part (resolution 48000/512 per bin = 94Hz)
  • then do a Zoom FFT 16x (decimate and lowpass and perform an additional FFT512) and we have 3kHz width with 5.9Hz resolution per bin . . . could be switched to whatever zoom factor for more precision
    Needs considerable horsepower, but should be possible in the STM32F7
    But you are right, there are other priorities right now :-)

@DD4WH
Copy link
Contributor

@DD4WH DD4WH commented on 7257ce5 Jan 23, 2018

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):

  • does one really need to hear the PSK signal ?
  • if not, why not use a centre frequency of 0 Hz/no offset for PSK31? Would solve some of the problems we have

@phaethon
Copy link
Contributor Author

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 :)

@phaethon
Copy link
Contributor Author

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.

@db4ple
Copy link
Collaborator

@db4ple db4ple commented on 7257ce5 Jan 23, 2018

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.

Please sign in to comment.