Gegroet, Leigh L Klotz, Jr. schreef:
Please count me in on such a list, but I wouldn't want to do anything to discourage Tomi. Are you going to contact him?
I did email him; but -from what I understand from other people- he is a very busy man.
My main goal would be to separate the modem back end from the GUI front and and have them communicate something like the way X Windows does, so we could have clients (GUIs like gpsk, or services like PSKMail). Also the modem server would more easily run on Windows, Mac, etc. that way, and be able to have a great UI for the platform.
Well, I agree. gmfsk would be a great "toolbox" for all kind of protocols; so a system which is "open" so that other protocols and applications can be added inside into it, on top of it and below it).
The way I see it, there are about 4 different parts:1/ The "lower-layer IO", i.e. everything that has to do with the audio- and PTT-devices.
What would be nice is a way to make gmfsk read from files instead of from the audio-interfaces. (would be nice to do debugging or analise audio-samples that where recorded before-hand).
2/ The GUI: Is very good.The only thing I see that is but something that might be added is -on one side- a full 4 Khz spectrum/waterfall, but also a "zoom" into a very small part of the spectrum.
3/ The DSP-related stuff (FSK/MF/BPSK/QPSK/...) and the protocols that run on top of it. (let's call it layer 3a and 3b).
The reason I would seperate the two is that certain protocols use the same modulation-sceme and could then use the same code. So, as gmfsk now already has RTTY, if you seperate the FSK-decoding from the upper-layer stuff; you could then use the same FSK-decoding modules for other protocols.
So if you would then like to write (say) a navtex-decoder; you can do it by just adding code for the navtex/sitor-B/amtor-FEC stuff, and place it on-top of the FSK-decoding module.
Another nice thing would be that a upper-layer protocol-code could use receive a dump of the FFT-process without any decoding. This would allow you to write (say) a wefax decoder.
4/ The "upper-layer IO",So provide a standardised way to attach higher-level applications on top of the core communication protocols. This would allow applications like PSKmail to connect to a gmfsk using standard ports (unix-sockets, tcp-sockets) without the need to hack the code of gmfsk; or a decoder for digital sstv. (to name just two of them).
Infact, as you also said, it would actually be possible to run this remotely from another machine over a network.
No a more general note.I have the impression that most ham-software is writen by a single person or by just a very limited group. That's a bit strange as if you look at the open-source world; most applications overthere are writen by tens or even hunders of people. (how many people are working on -say- firefox, open office, GNOME or KDE, the linux-kernel, ...)?
Perhaps, if we redesign fmfsk into a generic toolkit for digital radio; this would attract more people into this; as there wouldn't be a need to write everything from scratch again for your little program for your little new digital mode.
Just write a "module" and plug it into the toolkit. A bit like lego. :-) Cheerio! Kr. Bonne.
smime.p7s
Description: S/MIME Cryptographic Signature
