Can add a function of CW/PSK/RTTY/SSTV decode in mchf about uhsdr

[df8oe]

Some of them are possible (CW, PSK, RTTY) - SSTV may be not, because horsepower of MCU maybe too small.

This will be a subject for the future and maybe a STM32F4 with a larger Flass is needed (the one Chris has choosen has only 512KB - the one I choose in our project group has 1MB).

Before this on my roadmap are the following improvements:

1. adding support for serial EEPROM
2. finishing touchscreen support
3. adding 160m, 6m and 4m

vy 73
Andreas

I believe that there is plenty of horsepower available to support PSK31
and, likely, RTTY: There are very few "good" CW decoding algorithms out
there (but a LOT of bad ones!) so I'm a bit reluctant to go there: One
of the few that works reasonably well is that associated with the CW
"skimmers" - but I seem to recall that these are not open-source,
although I could be wrong.

One necessary step (besides enhancements to the UI) to having such modes
available is getting the USB keyboard interface to function. While this
would not have much bearing on simply decoding, receiving is where most
of the work lies and if that is done it is not a large step to make to
being able to transmit such a mode: Producing RTTY and PSK signals is
trivial - I have done it with low-end PICs (4 MHz 16C84/16F84s - which
have no PWM hardware or UART) using DDS techniques!

---

With the addition of the serial EEPROM, I was wondering what, exactly,
was in mind for storage in this EEPROM? The write cycle of a typical
EEPROM is marginal for real-time audio.

---

As for the STM32Fx specified in the BOM (at least the one that I
maintain) the data sheets show all "G" suffixed parts (STM32F405VG and
STM32F407VG) as having 1 MB of Flash. To which 512kB part are you
referring, and where is it listed? (I believe that CooCox is set up for
the "VG" part.)

---

In order to properly support 160 meters and avoid coverage "holes" at
the lower frequency range of the Si570 the tuning algorithm will need to
be revisited: See my previous email to the group (which included links
to the Dutch site) on this topic.

73,

Clint
KA7OEI

On 10/22/2015 1:16 AM, DF8OE wrote:

Some of them are possible (CW, PSK, RTTY) - SSTV may be not, because
horsepower of MCU maybe too small.

This will be a subject for the future and maybe a STM32F4 with a
larger Flass is needed (the one Chris has choosen has only 512KB - the
one I choose in our project group has 1MB).

Before this on my roadmap are the following improvements:

1. adding support for serial EEPROM
2. finishing touchscreen support
3. adding 160m, 6m and 4m

vy 73
Andreas

—
Reply to this email directly or view it on GitHub
#9 (comment).

[df8oe]

I think too there is enough hp for doing CW, RTTY and PSK31. Because of I have had working on USB and reading USB Memory sticks I am digging into USB stuff now :)

+++++++++

I want to implement "memory mode" so that you can store 100...200 different frequencies, modes, bandwidhts and station names for "fast-access" to favorite stations/frequencies. And I want to implement CW-memory (call-loop, contest-mode and so on). Because it is ever a good idea to have more (of what however) as you need I pointed to a 24LC01025.

+++++++++

Some of our project group have got their complete kits. Inside was a STM32F407VET6, Farnell part 206-4367. That may be a problem in future...

+++++++++

I do want to support the extended bands with a small pcb which has to be placed above rf pcb. It will contain a new LO design (working only at freq x 2) and a switchable divider for coverig the lower bands/frequencies. So there is no need for struggling on tuning algorhythm because of SI570 is used "nearly in specs".

vy 73
Andreas

[phaethon]

I would like to work on adding PSK functionality. My current focus is receiving. Sending requires keyboard as stated above, otherwise it should be easy. Currently, I play around a prototype code in python on a PC, which already works for decoding BPSK31, but I have not tested it with high noise levels. Couple of issues for discussion:

• I see it as an additional separate mode PSK besides SSB, CW, etc. Baud rate could be adjusted with Enc3 (like WPM rate for CW). Specific PSK mode (BPSK, QPSK, etc.) shall be selectable in the menu (though currently I am interested only in BPSK). Decoded text could appear as scrolling text over spectrum/waterfall (as on overlay in a different color or making spectrum/waterfall smaller)
• For optional functionality like this it would be nice to have some way to install/not-install optional modules. E.g. various firmware versions, or modules to be selected in firmware upload software, etc. Has this been discussed previously and is it planned?
• Some sort of adjustable squelch functionality would be nice not to display gargabe text when the signal is too low. Has it been discussed/planned in other contexts?
• I created a new branch based on testing branch. Is it the suggested way to develop such functionality?
• Shall I separate this into an request issue of its own?

Any feedback and hints are welcome.

[df8oe]

Welcome to our programming team!
we are working on implementation of digital modes, too. Because we do not have much code (flash) space and not much horse (CPU) power way of implementation is quite different to working on a PC.
We split this in different parts:

• freedv
• sstv
• slow S/N modes like WSPR, JT9, JT65 and so on
• all modes that can be decoded via fldigi

These four parts will grow to firmware step by step. Transmitting AND receiving are planned to be integrated.

Start will be with freedv, because of input and output devices are already available. next will be sstv, and the adding a keyboard is the start of all digital modes supported by fldigi.

The branch for developing is the devel-DF8OE - branch. Because of develoment is very fast it is neccessary to get the latest actual code every day - sometimes more than one time a day...

You can find informations to contribution in our CONTRIBUTING.MD:
https://github.com/df8oe/mchf-github/blob/master/CONTRIBUTING.md

So if you only plan to integrate PSK31 this code will be removed in future because of it is single mode and not best way of integration to firmware. If you will start this at a part using modificated modem code of fldigi it can be a base for the future.

vy 73
Andreas

[phaethon]

Could you clarify the last paragraph - Do you mean that the implementation should be expandable to include all PSK modes (or even including non-PSK) supported by fldigi in order to be useful? Or that it must be based on fldigi code?
Have you checked to what extent fldigi code is suitable for microcontroller environment?

[df8oe]

Because of you do not need to change analog audio to digital stream (it is already a digital stream at mcHF) code of fldigi modem is 100% usable on microcontroller - so no need to invent the wheel again. Of course it must be ported and many parts (ui...) must be developed new. But the big part which provides rx and tx functions for many digital modes is already there! Non-PSK-modes like rtty and many others should be implemented, too. Because of I have already started this work using fldigi as base is a MUST. We can split the work in parts (ui / structuring of modes / implementing keyboard and so on) so that you can participate in this of course.

vy 73
Andreas

[phaethon]

OK, using fldigi as the reference code is fine for me. First I will need some time to learn my ways around the existing mcHF code. Is any of your efforts on fldigi already committed into github?

[phaethon]

Separated PSK into a separate issue #1002