Thank you for the response on list and off list regarding cwdaemon. Between Kamil and myself we have got alsa working, but it needs more testing at high speeds.
Last weekend I used my tlf->linhpsdr->HL2 setup for over 150 qsos. It seems to be working reliably. It is great to not have a mass of cables and do everything through ethernet ports for CAT, netkeyer etc. As a side note, I have only enabled this for the Hermes-Lite 2 so far, but it should work with any protocol 1 OpenHPSDR/Anan SDR. If anyone on list has one and wants to be a beta tester for this please let me know?
The SDR setup really lends itself well to so2r (and at low cost). I have been thinking about implementing an OTRSP (
https://www.k1xm.org/OTRSP) listener within linhpsdr. I think I am correct in saying hamlib doesn't have this OTRSP protocol embedded within?
I have already got the basics in place in linhpsdr for audio in left/right channel for specific receivers etc. I'm not really proficient enough yet to make too much use of so2r, but it seems like an interesting challenge, both in terms of computer programming and operating so this motivates me.
I know that so2sdr exists for linux, but I'm not aware of any other logging software supporting so2r? I have read through the archives of this list and seen that with the LAN connection tlf can do pseudo so2r.
I have been looking at the tlf code and pondering over what it would take to add some basic so2r, single keyboard functionality using the OTRSP protocol. Shift key would seem a candidate to bind so2r switching. Shift is used for some things like "+" to switch S&P/CQ and resend last serial is an _. But does shift plus numbers or letters have a key bind?
The other stumbling point I hit in this mental exercise was the band map. You would need some sort of intelligence in code for grabbing a bandmap spot. It could perhaps figure out the band and if one of the radios was on this band, QSY said radio. It would result in the code being littered with if(so2r).
I am reasonably motivated to try and branch the code to see if this is possible in some sort of proof of concept. I would appreciate some advice about the general idea from the experts on this group. I'm not familiar with ncurses so it may take me some time to get up to speed.
Final question, unrelated, is there anything documented for the contest simulator? With pulseaudio, I was thinking we can have more than one audio sink, so with a seperate application listening on a netkeyer port, it could be possible to make pileups (from random callsigns in callmaster), add atmospheric noise etc. It seems like the simulator doesn't really give any feedback whether I have a callsign correct or incorrectly logged? Is this correct or am I doing something wrong? I feel like this could be a really nice feature to offer to people and enhance tlf. Lots of people seem to use MorseRunner and DXlog together.
73 Matthew M5EVT.