Implementing PSK mode

[phaethon]

I have started the work on implementing PSK mode. The objective is to be able to fully communicate in PSK without using a computer. There is a multitude of design issues.

1. Selecting the PSK mode
   Should it be a separate PSK mode or a submode of existing Digital mode? If the latter, how to select it?
   There is BPSK, QPSK, 8PSK with many variations (e.g. error correction option) and different speeds (BPSK31, BPSK63, etc.). How to select specific PSK submode? For the start I prioritize implementation of BPSK, and the speed to be selectable (and displayed) the same way as WPM in CW. Implementing other PSK modes should be more a UI issue as the rest should be easy.
2. Displaying decoded (and transmitted) text
   Should it be separate display mode with text window, or an overlay over existing waterfall and scope? Showing received text and transmitted text in separate windows or in one with different colours? What variations/configuration options would be needed to cover different preferences (e.g. font size)?
3. Entering the text
   I have already created a prototype paddle iambic mode input decoder. Probably, straight mode decoder would be needed for some. USB keyboard might be very convenient, but I understand that constantly polling keyboard could be a performance issue.
   Also, it should be possible to switch between tx and rx modes. Likely using one of the physical buttons.
   There should be a buffer of text, which is displayed and sent once switching to tx mode, and some very simple editing possibilities should exist (cancelling all text, deleting last character).
4. Memory keyer buttons
   Using PSK without possibility to send a predefined block of text would not be convenient and wouldn't replace computer usage. One idea is to use long press power button to switch 5 buttons into 4 memory buttons (sending the recorded text when pushed) + 1 tx/rx button. Long press on power button again switches back to normal arrangement with Menu, Meter, etc.
   Memory keyer buttons could be interesting for CW mode as well.
   Ideally, it would be possible to select callname from conversation (probably using touchscreen), and simple macros could be supported. This is more for a later phase, and not for the start.
5. Simple logging
   This is optional, but as we have frequency, time (if using RTC), band, mode, call, we can keep a simple list of QSOs . Not doing anything now, but returning to this idea in the future.

Feedback welcome.

[db4ple]

There are already provisions in the digital mode handling code for multiple digital modes. I am about to integrate RTTTY into that framework. That means I basically have the same questions you have.

1. I think we should, like in CW use some of the encoders to select some properties of the digital mode.
   RTTY has baud, shift and stopbits (and parity) for instance. Right now it needs to be coded into the respective functions, but that should be no problem except for being a little messy.

2. Good question. It would be relatively easily possible to reduce the height of the scope/waterfall on demand to make some room for text but it is not much room anyway. Overlaying the text would put a lot of stress on the display (i.e. it would take much more time to do it, as we have to set pixels individualy) OR requires writing code which merges characters and waterfall graphics before it goes out. Not trivial as we have no easy and high performance access to the framebuffer. And the STM32F4 does not have enough RAM for us to create virtual framebuffer.

3. Any USB keyboard does not cause any significant extra "stress". Of course the driver takes some time for its doing, but this will be neglectable. I wanted to look into that soon, should be simple. But i like the idea of keyer input. The trick part is the text editor. But I think we might have to repurpose the menu buttons below the display for that purpose when in digital modes which need this as you suggested.
   But I don't like the power button idea. We will find other, less dangerous buttons for that.

4. see above.

[DG9BFC]

what about a keyboard on the touchscreen??? that could be only switched on when needed and with a touch stick it should be possible to type some short texts (or select a marco text) ... (ok maybe a bit difficult with fat fingers) ... no need for having 26 buttons ... do it like on a phone keyboard ... then only 10 buttons needed (and the sms junkies already know how to use it ... grin)

[yo2ldk]

...or if CPU have one more free pair RXD/TXD, to add bluetooth module, and that be paired with one keyboard. PSK decoder will be SUPER if can be implemented!    73, ______________________     alexander - yo2ldk From: DG9BFC <[email protected]> To: df8oe/UHSDR <[email protected]> Cc: Subscribed <[email protected]> Sent: Thursday, August 17, 2017 9:17 PM Subject: Re: [df8oe/UHSDR] Implementing PSK mode (#1002) what about a keyboard on the touchscreen??? that could be only switched on when needed and with a touch stick it should be possible to type some short texts (or select a marco text) ... (ok maybe a bit difficult with fat fingers) ... no need for having 26 buttons ... do it like on a phone keyboard ... then only 10 buttons needed (and the sms junkies already know how to use it ... grin)— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ok1cdj]

Great to see progress in digimodes. For me is the best USB keyboard as input. For config memories we can use usb flash with txt file.

Maybe this code https://github.com/rubund/gmfsk will be usefull, there is implementation of various digimodes.

73 Ondra OK1CDJ

[phaethon]

2. My current draft idea is to create a new display mode for text. Scope/wfall part would be replaced with two vertically split windows. One for received and actually transmitted text (in different colors and/or on separate marked lines); the other for text to be sent. Additionally, there could be a small waterfall display for the meter part (selectable among other meters). This is the best compromise I could think of by now due to screen size limitations if overlay is not possible.
   For PSK operation we need TX/RX button. I have 2 ideas at this point: utilize M1 as I don't see another use for PSK mode (compressor should be automatically turned off anyway and sidetone could be as loud as rx audio); use some button (could be the same M1) to switch between normal mode and 'keyer mode', and then use e.g. F5 for TX/RX switching.
   @db4ple please, give your vision on the buttons we could use. I agree that power button is not a perfect fit.

[db4ple]

I may have misunderstood you: Did you mean Power or G3? see https://github.com/df8oe/UHSDR/wiki/Operating-Manual for the "official" mcHF button names.

Now for the actual question:

1. Why not use PTT? If you type while PTT is active: send as you type. Before: Type and edit. Send buffer content if PTT becomes pressed. We could make PTT "sticky". I.e. it behaves like a switch (press once to enable PTT, second time disables PTT). Of course only in digital modes with text input where you need your hands for typing.

2. F5 (Tune becomes TX)

3. In fact G3 "long press" is available and it is the only available one. But not really good (not as worse as "Power" though).

[phaethon]

Yes, I meant G3, sorry for vagueness.
It has advantage of being available across the modes (and memory keyer may be interesting for cw mode, too). But it is not in an intuitive location. Location of M1 is better, but not available for other modes. We could use short press (instead of long press of G3), which is somewhat resembling CAPS button on keyboard (and location is matching for such intuition, too). F1-F4 could become mapped to memory locations of 'keyer', F5 becomes TX/RX. Pressing M1 again returns to normal. Permanently replacing F5 with TX/RX in PSK mode is not good, as Tune is needed in PSK mode, too.
My current design idea is to enter text (as one of the options, I like USB keyboard too, but we don't have it working yet) via morse paddle. Then press TX/RX button to send it. PTT is connected to DAH of the paddle, I cannot use them both in the same mode.

[phaethon]

@ok1cdj thanks for the link. Current idea is to start with fldigi code.

[db4ple]

For PSK, you may want to have a look at https://github.com/STM32-SDR, they integrated a PSKCore derivate in C. It might also be worthwhile to look at Moe Wheatley's PSKCore DLL Sources (LGPL).

73
Danilo

[phaethon]

I will have a look. Thanks!

[DD4WH]

Very nice that you are pushing forward the PSK decoding!
Just one point to think about. Would it be best to take the IQ signals directly and code the filters and decimation exactly as needed in the PSK routine or would you use the audio from the audio path [audio_driver.c audio_rx_processor]?
73 de Frank

[phaethon]

@DD4WH I cannot answer that yet. More likely starting with audio path for the first attempt, but open for recommendations.

[db4ple]

Regarding Buttons: yes, with CW keyer input PTT is not your best choice :-( . Maybe the design should have separated PTT from keyer inputs.

But I am not completely without hope: Why not "move" tune to long press of G3? Tune is not the most frequent operation. Then F5 is free to be used. What I don't like about this is, that we have "Tune" on different buttons.

So if we go down this route, tune should eventually move to G3. This would free up F5 for various jobs such as a "User" button (with some user selectable commands mapped to it unless it is needed by the various modes such as digital modes).

[phaethon]

I used Tune quite often with my external tuner. Also, I use Long press of F5 to disable TX (to test some morse sequence sending temporarily). So, I would not be happy to permanently remove this possibility. But what do you think about M1 long press being like caps lock changing functionality of F1-F5 (giving way for possible 'keyer mode' implementation using F1-F3, F4 would probably go for deleting last character, with long press cancelling all buffer, F5 become rxtx)? Long press of M1 returns F1-F5 as they are now.

I will be away for a vacation for 2 weeks without a computer. Not much progress expected during that time.

[db4ple]

Hi Eriks,
M1 could be a good option. Happy vacation. I will see how I can improve the existing infrastructure a bit to cope with the added complexity of more modes with different settings controlled via encoder. This could be also kind of a template for the dynamic button reassignment, we will see. Right now we have just two sets of button assignments (menu mode, no menu mode) all handled by direct per button coding.

[phaethon]

One thing I would like to understand - how the mode switching will work for digital modes? Currently there is just FreeDV, but I have understood that it should be possible to switch when we have multiple. I have not investigated the code in this regard yet.

[db4ple]

That is why I said RTTY will be the template. This weekend I implemented RTTY as a second digital mode. Essentially there is a variable called ts.digital_mode which is used to discriminated the current digital mode. If you search for ts.digital_mode use (best done using Eclipse "References" menu but text search should work too), you'll see how it is being used. I currently limited the choice to None, FreeDV, and RTTY. There are about 2 places where we have to change the limit so that PSK is included.

Then as a user you can select PSK and when the digital mode is activated, it will be in PSK mode.
Not a big deal. You can also search for DigitalMode_RTTY, this way you can find all the place where I did something special for RTTY integration.

[db4ple]

Hi Eriks,
just want to ask how you envision to store the "text memories" permanently or if we postpone that part? The normal "Parameter" Storage in Flash would be quite inefficient for that, since it uses 4bytes for 16bit of data (I2C EEPROM does not have that overhead).

[phaethon]

@db4ple long term storage is not in the priority list yet. EEPROM sounds more appropriate though. Any recommendations welcome.
Current plan is to finish minimal keyer without long term storage for working with CW (likely can be easily used for RTTY as well). In parallel I am investigating PSK decoding samples to choose the prototype for the code. This is taking quite a lot of time.

[df8oe]

Hi Eriks,

there is already good work (and code) for implementing PSK into STM32. It is in German but Google translate will do its job:

https://www.mikrocontroller.net/topic/163505

The most interesting posts come from Bernd K. ( prof7bit ) ~ in the middle of the thread.

vy 73
Andreas

[phaethon]

As of my last PR the keyer now actually does something useful in cw mode. Everybody interested, please, see Digimodes page of Wiki for description how to use it and current limitations (e.g. not saving to eeprom yet).

[DG9BFC]

@ dd4wh
yes i mean the peak filter should be automagically set to sidetone (in cw mode ... maybe also in ssb if you wanna do cw with ssb moduation (tone from pcs digital software) BUT ALSO TO THE BPSK PEAK VALUE IF THAT MODE USED (in our example 1000hz ... so filter of 300 950 or 500 950 is close enough as prefilter)
for the rtty filter ... ok if already included (see coments below!)
my question then is does it not make a difference selecting a wide ssb or a narrow cw filter when decoding rtty??? my guess is yes .... a narrow filter would help
i use 500hz 950hz cause the 300 hz 950 is a bit too low (for ham ... for dwd i use 1.4khz bpf)
i have to try out if it works with the 300 hz filter when i also add some "rit" to get the two peaks inside the filter passband
@ df8oe ... no andreas i do not speak of filters like we have in a pc sdr soft (take whatever you like) ... i speak about the filters we already have (maybe some has to be tuned a bit more up for a special case like rtty) ... we have a dozen filters in mchf ... so the horsepower is there .... i was just asking if we could switch some filters and some setiings automagically depending on used mode (and depending from a user setting like the side tone qrg)
for the rtty filter .. i wanna only hear that one station that i am decoding (if possible) thats why i asked for the notch in centre of a small bandpass (we have a 300 hz bandpass that would fit ham rtty but it is tooo low in frequency so you have to take the 500 hz filter)
i am guessing that when you select an upwards tuned 300hz together with a notch ... that would be a perfect fit for rtty signal ... and a signal that is outside of that double peak ... can not lower the decoded stations signal or disturb any decoding ... ok if it is included in the DECODING STREAM of rtty (those already mentioned filters) ... but it also should be in the AUDIO stream (and getting the agc signal only from the received signal inside those two peaks etc.) ...
with clever combining the peak and notch filter that is already there with the filters we already have (tuned to needed centre setting depending on mode) we could "squeeze" the very rest out of the hardware without the need for more horsepower ... yes some filter maybe have to be calculated new in matlab ... but thats all .... then combine the needed filter with peak/notch and all is well
so ... let me do an educated guess ... frank 100% understood what i am after ... andreas missunderstood me a bit :)
... could we add a marker for the peak/notch setting to show in spectrum/waterfall??

[DG9BFC]

ok i tried it ... together with rit??? no way ... does not work

[WD8BXS]

So, is receiving BPSK possible yet? I know I can not get it to receive here, tried for hours.
Chuck

[df8oe]

RX not possible yet - only TX. BPSK is highly experimental alpha stage and under progress.

73
Andreas

[WD8BXS]

Can’t wait to see it working. Keep up the great work. I just upgraded to the 429MCU, working great! 73, de WD8BXS Chuck

[phaethon]

Posting comment just to confirm I am still working on PSK receiving.
If anybody wants to help, testing transmitting part (already in the code for some time), would be the best thing to do.

[phaethon]

Just submitted a PR with basic BPSK rx functionality. A star means that an unknown symbol is decoded. Mostly tested using PSK31 until now. PSK63 and PSK125 might need separate wider filter.
Feedback and testing welcome.

[DG9BFC]

it works !!!!! now for the filter programmers add a narrow filter around 1000hz

[DD4WH]

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

[DD4WH]

Hi Eriks, if you want, I can add the existing snap button to the PSK mode, so we could test out how well that works for finetuning to the PSK carrier. Preliminary test show that the carrier can be snapped, however the precision could be better . . .

[DD4WH]

Snap is now implemented in the newest version. Pull request has been submitted.
Works pretty well from my point of view!
However, you still have to manually tune 1-3 Hz +- sometimes.

[DD4WH]

there is an AFC in the code that can be found here:
https://github.com/gmtii/STM32-SDR/blob/master/STM32-SDR/code/main/src/PSK_Det.c
maybe of help!?

[DG9BFC]

you need both .. snap for coarse tuning and the decoding has either to do the finetune ... or give the mistune additionally to the vfo (do the finetune over the last few hertz).... all psk soft that i know have some kind of afc (against slow drift) .. if we can add such a function then you do the coarse tune and let the decoding do the rest (send offset to vfo and finetune)
by the way ... if not already nailed in stone ... use 700hz (that is also cw default in a dozen software and is also used in a dozen other rigs) ... so when we use it for cw (and have already (listening not decoding) filters for that ... we could also use it for psk (and maybe some other modes?)
the user already has the "tone" in his ear (i also set my keybeep to 700hz ... grin)
so a tuning by ear is easy when you use same frequency for all modes (where possible)
and 700 is just inside the zoom view right??
just tested the new snap
sometimes need two or three tries but when it matches is is decoding fine
could the snap maybe take alonger time??
tune to first calculation ... measure again (or get data from decoding part?) and do a "slow finetune" till decoding says "gotcha"

[phaethon]

I would prefer 500 (or 1000) to 700 Hz as 500 divides by 31.25, but 700 does not.

[DG9BFC]

ah ok .. it has a reason why you selected 1000 (or would take 500) ... i understand that
....
you do not take the decoded audio but use a complete seperate decoding chain ... right?
then any filtering can not help (yes you do the own filtering ... i got that ...)
but i was thinking that a user can easier "hear" the signal when turning around in the band
for that case a narrow filter (maybe with peak filtering or noise reduction?) would help the user (not the decoding chain)

i tested the peak filter and it lifts out a psk signal even from close to noise level to a much stronger signal
now my thinking was ... could a peak filter be of any use for such a signal?? (but it should lift out the signal for the user but not distirb the decoding)

just thinking how low signals could be improved ... stronger signals decoding fine here after you found frequency :-)
we need an afc (and that should not drift when there is NO sig

about frequency ... would a 1000hz signal be easier to decode then a 500hz signal (cause you have 32 instead of 16 swings per 31 baud)

[phaethon]

Please, test the new commit. Feedback welcome.

[phaethon]

Question for discussion - shall we mark this issue as closed? In a basic form it works. Improvements (AFC, improving decoding, more code optimization, different display, etc.) can be separated into issues of their own and thus better managed.

[G3WKW]

The user guide for PSK under DigiModes needs updating to change the suggested filter to I would guess 300Hz/500Hz. it took me a while to realise something had changed.