A potentially useful C program 'ka9q_hpsdr'

[N1GP]

Hi Group,

I put together a C program ka9q_hpsdr, that translates ka9q-radio channel
data in to protocol2 hpsdr data and sent via ethernet UDP packets.

It currently supports up to 8 receiver channels from ka9q-radio
but could handle more depending on the host CPU. I put this together
to be able to use my RX-888Mk2 for CW skimming.

Its hosted on: https://github.com/n1gp/ka9q_hpsdr

If you can suggest improvements or find bugs please post something to the
Issues tab.

Happy Holidays,

-Rick / N1GP

[Dani YO5LD]

Yes, yes, yes!

I've been playing with this idea about 2 years ago, but my experience with C and all these IQ streams was not enough.

I'll try this out sometime in January.

Are you using a RPi for KA9Q and then CWSkimmer on a Windows machine?

Thanks!

Dani

YO5LD

--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/30a6e1b8-39e5-4fef-8b6f-795a85dc370cn%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[N1GP]

Hi Dani,

I first tried using ka9q-radio on my RPi5 but it wasn't able to handle also running

ka9q_hpsdr. So I loaded them on my NUC7i3 and they run smoothly with CPU to

spare on that.

I do run SkimSvr on Windows but sometimes I use it on my Linux PC running it

with wine (https://www.winehq.org/)

-Rick / N1GP

[Andy Z - K1RA]

#1 (Suggestion)

https://github.com/n1gp/ka9q_hpsdr/issues/1

73 & HNY!

andyz - K1RA

[N1GP]

Andy, tnx for that suggestion. I have implemented it and

checked it in to main.

HNY - Rick / N1GP

[Phil Karn]

There seems to be a bewildering variety of protocols out there for networked SDRs, many proprietary and/or closely linked to specific hardware. I'm sure I haven't even seen most of them. I hesitated to create still more when I began ka9q-radio, but I think it was necessary to accomplish many of my goals. Those included:

1. Support of as many simultaneous digital downconverters on a single front end as possible, limited only by the CPU and network speed of the host computer.

2. Use of IP multicasting for everything: not just the receiver data flows but also control and status monitoring. Any number of processes on any number of computers can consume the same data stream without ka9q-radio caring or even knowing how many there are. Multiple control/status monitoring programs can share control of a receiver channel, with everyone on the control/status multicast group seeing everyone's commands sent and responses received. All packet routing and duplication is handled by the Ethernet switches and routers, eg, with IGMP snooping and by the existing multicast support in the Linux kernel.

I wanted to use standard, widely used IETF protocols wherever possible for the data streams. All received signals are carried in RTP/UDP, the Real Time Protocol universally used for VoIP and some IPTV networks like AT&T Uverse. RTP provides the packet sequencing, time stamping and demultiplexing required to stream synchronous data over a network that can drop or reorder packets, and my use of it is at least somewhat compatible with existing applications like VLC.

But I rolled my own command/status protocol, and I'm still not sure this was the right thing to do. I did know that I could make mine a lot simpler and faster than anything using json or (God forbid) XML, yet remain flexible and extensible by borrowing the TLV (type/length/value) binary encoding used in many core Internet protocols. My protocol works but I don't pretend it's perfect so I'm open to any effort to combine efforts that allows me to extend or generalize my control/status functions without undue complexity.

I just added a spreadsheet to my github repository with my first real attempt at documenting the control/status functions; I'd be very interested in comments, corrections and any ideas on how to minimize incompatibilities and duplication of effort. It's in https://github.com/ka9q/ka9q-radio/blob/main/docs/ka9q-radio-commands.pdf. I created it with Apple Numbers and I think it needs a format cleanup. The source document is https://github.com/ka9q/ka9q-radio/blob/main/docs/ka9q-radio-commands.numbers

Phil

--

You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/644b9aff-02ea-4dc6-84ff-b124dca181cen%40googlegroups.com.