Remote Linrad & Teamviewer on Linux

[HB3YPO]

I am trying to figure out how to make a remote Linrad station work on Linux Mint.
The problem is if I connect the remote station with Teamviewer the "Computer sound" under Audio/Video is inactive on the linux pc.

But If I use Windows 7 on the remote computer this "Computer sound" is active and I can hear the audio.

I am using the latest Mint 17.1 and latest Teamviewer 10.0

Has anyone made such work on Linux?

I would prefer to use Linux on the remote computer

[Alex Crow]

Hi,

I've used x2go from the ubuntu x2go ppa. Sound works fine and it's open source.

Cheers

Alex

--
You received this message because you are subscribed to the Google Groups "Linrad" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linrad+un...@googlegroups.com.
To post to this group, send email to lin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[HB3YPO]

Hi,

My remote operation issues:

the remote station is behind a NAT/firewalled network

- Teamviewer can be used but audio is not supported in linux (Mint)
- Skype can be used to provide audio but Skype no longer support ALSA just Pulse Audio that I cant not make work with Linrad yet.
- X2Go is an alternative of Teamviewer but as the remote station is behind NAT, not possible to connect to it

I am thinking to make skype work with Linrad but even if all system sound can be routed to skype I can not make Linrad to route in it.

when I select portaudio, I get  a message:
"Could not load library /usb/lib/libportaudio.so.

Library not compatible with Linrad. Maybe too old?

Remove library and run ./configure --with-help"

Also here I read troubles with PulseAudio and Linrad.

I am not sure which way I go forward.

Cheers
zsolt

[Alex Crow]

Can you port-forward on the router in front of your remote box? Can you set up a VPN between your local system and the remote?

If so you can use any method to access the remote box. Setting up a VPN would be the least painful method as it would just be as if you were on a LAN with the remote. If your remote box is Linux then why not use OpenVPN or IPSEC (eg OpenSWAN) to get a proper connection? Or if you can change the router use something suitable from EnGenius, TP-Link or best, DrayTek (these are really solid, IPSEC or SSL VPN, VoIP, decent WiFi).


Cheers

Alex

>> <javascript:>. To post to this group, send email to
>> lin...@googlegroups.com <javascript:>. For more options, visit
>> https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.

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

> <mailto:linrad+un...@googlegroups.com>. To post to this group,
> send email to lin...@googlegroups.com
> <mailto:lin...@googlegroups.com>. For more options, visit
> https://groups.google.com/d/optout.

[Leif Asbrink]

Hello Zsolt,

> when I select portaudio, I get a message:
> "Could not load library /usb/lib/libportaudio.so.
>
> Library not compatible with Linrad. Maybe too old?
>
> Remove library and run ./configure --with-help"

This means that you have to uninstall Portaudio because
the version that is distributed with your linux package
is too old.

Once you have removed all libportaudio.so files you can
run "./configure --with-help" to get the sequence of
commands to install Portaudio v19. It is from 2011 and
I find it remarkable that modern Linux distributions
supply older versions - but, there is of course a risk that
I made a mistake somehow. I have not tested the latest Ubuntu
so I do not know whether the Portaudio problems can be
worked around somehow.

73

Leif

[Sid Boyce]

Using the latest svn.

Input soundcard selection A option L to select openHPSDR does not work.
Option B to select output sound card returns asking for option A to be
selected first.

openHPSDR hardware is Hermes/Hermes-Lite.
73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[Leif Asbrink]

Hello Sid,

The Ethernet protocol for HPSDR has not been implemented yet
(as far as I know.) Currently a wrapper around the old USB
protocol is used in PowerSDR. I am waiting for a proper
Ethernet protocol.

You must select the input before you can select an output.
The reason is hardware problems in some cases where the
same soundcard is used for both input and output.
Sometimes different speeds is not allowed. Linrad has
the input running while you select the output
soundcard and that way (sometimes) you can only
select the same speed for the output.

You can select explicitly to not have any input,
that would allow playing recorded files.

73

Leif

[Sid Boyce]

Thanks Leif,
As I suspected after a bit more thought.

The only answer to Ethernet protocol questions I have seen on the
openHPSDR reflector is a reference to
http://openhpsdr.org/support/Ozy/USB_protocol_V1.57.pdf
73 ... Sid.

[andrea montefusco]

Leif,

>> The Ethernet protocol for HPSDR has not been implemented yet (as far as I know.)

First off, really it is not an "ethernet" protocol at all, because it is an IP/UDP protocol (pure ethernet frames are only used in special cases by the HPSDRProgrammer and the other utilities, but not during the normal duty).

Both the  "ethernet" protocol and the UDP one (the latter being that more interesting for us), are documented here (since late 2010 I believe):

      http://svn.tapr.org/repos_sdr_hpsdr/trunk/Metis/Documentation/Metis-%20How%20it%20works_V1.32.pdf

I agree that the original document Sid mentioned, has now a very misleading name; it should be fixed because it is referring to the USB transport details, that are not anymore relevant (or, at least, are not for the recent radios in HPSDR project).

Moreover, even "Metis - How it works" title is misleading, because the document applies not only to Metis, but to all recent ethernet enabled HPSDR radios, so, Metis aside, Hermes, Angelia, and Orion and maybe I forget something.

I could second that, in a perfect world, three documents should be there:

1) application protocol document (mainly all of the USB_protocol_V1.57.pdf contents, but without any USB mentioned )

2) IP/UDP transport protocol ("Metis - How it works", as is, just with a more proper title)

3) USB transport protocol 

So, IMO, the design is a good one, in the sense that the application protocol is well encapsulated and indipendent from the transport (USB or UDP), only the documentation should be reorganized a little bit, anyway the info are all there.

I heard that the protocol was undergoing radical changes, in order to split the several receiver's I/Q streams, each over its UDP flow (i.e. using different UDP ports), but I don't know if this was ever made/attempted.

In any case, if in Linrad the application protocol over USB (#1 + #3 above) is already implemented, it is not so difficult to implement even the IP transport; I will try to submit a patch.

Ciao

  73 iw0hdv Andrea Montefusco

PS: for a C++ implementation you may take a look to my Extio code in https://github.com/amontefusco/extio-iw0hdv/tree/master/hpsdr but there is even cuSDR (a complete receiver), Hetherodyne and several other software implementing the HPSDR "ethernet" protocol.

[Leif Asbrink]

Hi Aandrea,

> >> The Ethernet protocol for HPSDR has not been implemented yet (as far as
> I know.)
>
> First off, really it is not an "ethernet" protocol at all, because it is an
> IP/UDP protocol (pure ethernet frames are only used in special cases by the
> HPSDRProgrammer and the other utilities, but not during the normal duty).
>
> Both the "ethernet" protocol and the UDP one (the latter being that more
> interesting for us), are documented here (since late 2010 I believe):

I am refering to a document I have: "openHPSDR Ethernet Protoicol"
which was discussed October 2013. As far as I know, the new protocol is
not compatible at all with the old one.

I am interested in both the rx and the tx side. The old protocol
does not allow full performance of the hardware. The transmit spectrum
has quantization noise from inadequate number of bits in the USB transfer
for example. I also want the receiver to display at least 2 MHz and there
are several other issues. I have many other interesting projects
and I do not want to implement a protocol that does not use
the hardware well so I have not tried to implement anything for
HPSDR yet.

Linrad can use ExtIO dll files. I have downloaded Extio_hpsdr_mgw.dll
and it detects my Angelia, but it says: "Hardware unsupported,
unable to start receiver"

Maybe the dll will work with other HPSDR hardware in Linrad??


73

Leif

>
>
> http://svn.tapr.org/repos_sdr_hpsdr/trunk/Metis/Documentation/Metis-%20How%20it%20works_V1.32.pdf
> I agree that the original document Sid mentioned, has now a very misleading
> name; it should be fixed because it is referring to the USB transport
> details, that are not anymore relevant (or, at least, are not for the
> recent radios in HPSDR project).
>
> Moreover, even "Metis - How it works" title is misleading, because the
> document applies not only to Metis, but to all recent ethernet enabled
> HPSDR radios, so, Metis aside, Hermes, Angelia, and Orion and maybe I
> forget something.
>
> I could second that, in a perfect world, three documents should be there:
>
> 1) application protocol document (mainly all of the USB_protocol_V1.57.pdf
> contents, but without any USB mentioned )

> <http://openhpsdr.org/support/Ozy/USB_protocol_V1.57.pdf>

>
> 2) IP/UDP transport protocol ("Metis - How it works", as is, just with a
> more proper title)
>
> 3) USB transport protocol
>
> So, IMO, the design is a good one, in the sense that the application
> protocol is well encapsulated and indipendent from the transport (USB or
> UDP), only the documentation should be reorganized a little bit, anyway the
> info are all there.
>
> I heard that the protocol was undergoing radical changes, in order to split
> the several receiver's I/Q streams, each over its UDP flow (i.e. using
> different UDP ports), but I don't know if this was ever made/attempted.
>
> In any case, if in Linrad the application protocol over USB (#1 + #3 above)
> is already implemented, it is not so difficult to implement even the IP
> transport; I will try to submit a patch.
>
> Ciao
>
> 73 iw0hdv Andrea Montefusco
>
> PS: for a C++ implementation you may take a look to my Extio code in
> https://github.com/amontefusco/extio-iw0hdv/tree/master/hpsdr but there is
> even cuSDR (a complete receiver), Hetherodyne and several other software
> implementing the HPSDR "ethernet" protocol.
>

[andrea montefusco]

On Tue, Feb 10, 2015 at 3:35 AM, Leif Asbrink <le...@sm5bsz.com> wrote:

I am refering to a document I have: "openHPSDR Ethernet Protoicol"
which was discussed October 2013. As far as I know, the new protocol is
not compatible at all with the old one.

Probably that document (that I am not able to find  on the openHPSDR web site, where did yoi find it ?) is describing the new protocol that I was mentioning in my email.

I am interested in both the rx and the tx side. The old protocol
does not allow full performance of the hardware. The transmit spectrum
has quantization noise from inadequate number of bits in the USB transfer
for example. I also want the receiver to display at least 2 MHz and there
are several other issues. I have many other interesting projects
and I do not want to implement a protocol that does not use
the hardware well so I have not tried to implement anything for
HPSDR yet.

More than a protocol limitation is an FPGA limitation; Phil Harman reported on the HPSDR reflector that a new FPGA image is able to use the fully capability of ethernet interface up to 1 Gb/s, maybe in that mode larger bandwidth can be vehiculated to PC.
For the receiver side the bandwidth is limited to 384 kHz, even if PowerSDR manages to show more "stitching" (whatever this word means in terms of DSP) more 384 kHz segments together,at least on the spectrum display.

 

Linrad can use ExtIO dll files. I have downloaded Extio_hpsdr_mgw.dll
and it detects my Angelia, but it says: "Hardware unsupported,
unable to start receiver"

Maybe the dll will work with other HPSDR hardware in Linrad??

No, that is just because I don't have Angelia but only Hermes, hence I cannot test Angelia; so the DLL is limited to Hermes and Metis, that is what I own and I can test.

   *am*
 

[HB3YPO]

 I have managed to make it work and wrote a guide about this here: http://prig.ch/linux-applications/software-defined-radio-sdr-/nano-sdr/index.htm