so2r

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

so2r

Matthew Balmer
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.

Reply | Threaded
Open this post in threaded view
|

Re: so2r

Nate Bargmann-4
* On 2020 18 Apr 05:02 -0500, m5evt wrote:
> 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?

No, Hamlib does not have any concept of controlling multiple devices
through a single instance.  However, there should be no limit, aside
from computer resources, on the number of Hamlib instances a program can
create so long as they're each accessing a unique device on a unique
port.  Likewise, multiple instances of rigctld/rotctld can be run so
long as each is opening a unique device on a unique port and each *ctld
instance is bound to a unique TCP port.

BTW, I like the rest of your ideas, even though I probably will never do
SO2R!

73, Nate

--

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: so2r

Matthew Balmer
In reply to this post by Matthew Balmer
I am still experimenting with the options for so2r and prototyping some ideas. However, I have had some luck with:

- x2 instances of TLF connected on LAN;
- split screen view within a terminal, tlf instances in left/right split view;
- shift key bind to switch between each split view terminal.

This works with no modification needed for tlf. I think this is a nice option for the more casual so2r operator.

73 Matthew M5EVT.
Reply | Threaded
Open this post in threaded view
|

Re: so2r

jim smith
Hi Matthew,

Sounds like you and I are experiemnting with the same thing.  Two
computers, each controlling a separate radio, and each computer running
an instance of TLF.  On the "main" computer, I ssh to the computer that
controls the second radio, and push the tlf terminal (urxvt) to the X
server on the main computer.  I have two urxvt sessions side-by-side,
each running separate instances of TLF on separate computers
controlling separate radios.

As you stated, this doesn't require any modifications to TLF.

73, Jim KK0U


On Sat, 23 May 2020 19:33:00 +0100
m5evt <[hidden email]> wrote:

> I am still experimenting with the options for so2r and prototyping
> some ideas. However, I have had some luck with:
>
> - x2 instances of TLF connected on LAN;
> - split screen view within a terminal, tlf instances in left/right
> split view;
> - shift key bind to switch between each split view terminal.
>
> This works with no modification needed for tlf. I think this is a nice
> option for the more casual so2r operator.
>
> 73 Matthew M5EVT.


Reply | Threaded
Open this post in threaded view
|

Re: so2r

jim smith-3
In reply to this post by Matthew Balmer
Hi Matthew,

Sounds like you and I are experiemnting with the same thing.  Two
computers, each controlling a separate radio, and each computer running
an instance of TLF.  On the "main" computer, I ssh to the computer that
controls the second radio, and push the tlf terminal (urxvt) to the X
server on the main computer.  I have two urxvt sessions side-by-side,
each running separate instances of TLF on separate computers
controlling separate radios.

As you stated, this doesn't require any modifications to TLF.

73, Jim KK0U


On Sat, 23 May 2020 19:33:00 +0100
m5evt <[hidden email]> wrote:

> I am still experimenting with the options for so2r and prototyping
> some ideas. However, I have had some luck with:
>
> - x2 instances of TLF connected on LAN;
> - split screen view within a terminal, tlf instances in left/right
> split view;
> - shift key bind to switch between each split view terminal.
>
> This works with no modification needed for tlf. I think this is a nice
> option for the more casual so2r operator.
>
> 73 Matthew M5EVT.