BatchDrake
CW, RTTY and PSK31: Scan, autocorrelate and output modulation data feature requestio
Somewhat related to #140, would it be possible to add scanning, autocorrelation and data output for CW, RTTY, and PSK31?
I'd like to use this functionality for another application my friends are (generously) coding for me (probably in .NET, will be published openly on GitHub):
- Basically, I'm wanting to feed this data into a bigger system to support amateur radio disaster response operations.
- It basically acts as a gateway between modes and ways of moving messages around (example: capture request to send Winlink email via CW, RTTY, or PSK31 -- and then send it).
- Also, CW, RTTY and/or PSK 31 could be used to send "voicemail" commands to the server. Example: someone sends request to Nexus over the air via CW, like "I am K7LEE, do I have any voicemails". Radio then plays stored audio message.
Thank you for considering my request!
More details about Project Nexus:
@BatchDrake: Is there anything I can try to help with? I can't code to save my life, but I know a healthy number of coders, mathematicians, etc.
Hi @pete-k7lee , sorry for not answering you earlier (lots of pending features that are still in the process of being merged)
What you are requesting is actually what I originally designed suscan for. However, right now, SigDigger is growing beyond the limits of sanity, and I'd like to think twice before adding more fuel to the fire.
This said, I'm not giving up on this feature yet. This should be implemented as a plugin, and for that I will have to implement a well-defined plugin API. This requires some engineering effort that steps a bit outside the regular feature-coding work and requires feedback from the users. I can of course design an API all for myself, shaping it under my individual biases and bad habits, and turning it into something that will not always align to what other developers have in mind.
What I need is an exact description of the features requested so far (which you did), what will their main use cases be (which you did as well) and of course how would users use it (which I miss, e.g. what will the user interface look like? how would the user trigger the scan? how are the results presented?).
PS: Have in mind that SigDigger is still a software to analyze signals you don't know anything about. It is designed for characterization and debugging purposes. Ad-hoc features will be possible once the plugin support is ready, but we will have to figure out first how these features fit in the current analysis workflows (otherwise we may end up having.
Of course, if you know coders with knowledge on C/C++ that have some background on software engineering, that can always help speed up the process.
Good to know! Do you happen to have a Slack channel or StackOverflow sort of thing where you discuss code needs?
I have opened a Reddit community for that purpose: https://www.reddit.com/r/SigDigger/ it's in a very early stage, but as long as I can write chunks of code in it, it should be enough.