Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: Remote control of EESDR2 or EESDR3 connected by STARLINK

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 06:07 #16

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 296
  • Thank you received: 138
spacex wrote:
Why do you need such on your home router when you can have IPv6 connectivity on usually all end user devices
Well, unfortunately, SunSDR is not "usually all end user devices" and currently does support IPv4 only.

At this forum we are not talking about "Starlink in common home environment", instead we are talking about environment running specific equipment called SunSDR trasceiver, combined with cross-platform operation SW called ExpertSDR. Each device (SunSDR and PC with ExpertSDR) has own IP address. When PC can be assigned with IPv6, SunSDR cannot.

The remote operation topology we are trying to solve is the following:
IPv4 LAN (SunSDR) <-> GW <-> Starlink <-> Another Provider <-> IPv4/6 LAN PC with ExpertSDR.
Last Edit: 09 Feb 2022 06:08 by VK6NX.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 06:24 #17

  • spacex
  • spacex's Avatar
thats impossible what you try to do.
Reason is Starlink gives you IPv6 address that you can reach from external / Internet side but it will never give you IPv4 address that can be used to reach you router from external.
Now what SDR needs is dead simple. It may not be the question of the SDR software.
All you need is to have IPv6 address on the PC thats controlling the SDR and then you will be able to reach it from anywhere over IPv6.
No need to overcomplicate something which is very simple.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 06:37 #18

  • spacex
  • spacex's Avatar
the IPv6 end-to-end connectivity is given, available - yes you need to configure it - the only question is how to implement.
If the home PC has IPv6 address, then you can Remote Desktop onto it for example.
If the SDR can deal with IPv6 connection, thats even better
If you want to do the most secure way, implement IPv6 Ipsec tunnel, thats pretty widely used in Asia, China, almost noone ever talked about this on the West.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 07:08 #19

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 296
  • Thank you received: 138
spacex wrote:
Reason is Starlink gives you IPv6 address that you can reach from external / Internet side but it will never give you IPv4 address that can be used to reach you router from external
Well... I do not know the term "impossible" :D , alternatively I know that everything is possible, just with little help of couple extra things: time and big enough hammer.
The problem you have described can be solved with NAT64 static mapping. For example, Juniper and Cisco, both have vendor approved configs for those. However, it will also require remote site (ExpertSDR PC) provider to support IPv6 and have full IPv6 routing between this provider network and Starlink network.

Dead simple IPv6 support in SunSDR? Well, lets see... The percentage of Starlink users (amongst all SunSDR users) is, perhaps, close to 1-2% and amongst those 1-2% less that 1/10 will require remote operations. We are talking about 10-20 users max, in global. Because of above I do not see IPv6 in SunSDR as realistic in next 2-3 years. There are other and more important priorities for new feature sets ahead of IPv6.

Alternatively what we are trying to do is perfectly possible with IPv4 and VPN (with known caveats). I am currently running the working config, described here: eesdr.com/en/forum-en/other-questions/9637-sunsdr-over-vpn-based-on-starlink-background-and-basics

Remote desktop is not an option, because SunSDR-to-iExpertSDR traffic is similar to common RTP and if is is affected by latency, jitter, delay and packet lost, then operations is failing. Any RDP also add voice latency, which is practically breaking the topology purpose.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 07:39 #20

  • spacex
  • spacex's Avatar
i saw the link about one potential way. Thats the one which works on the good old IPv4. All you need is outbound VPN from the SDR box side.
However that VPN and Network Address Translation will create jitter, which may be issue for SDR.

the clean way is what i described, IPv6 end to end, no NAT used which slowing down especially if no hardware support for that on the router.
Those who are not much into networking it is possible to buy a pair a IPv6 IPsec tunnel routers made by China.

IPv6 is not only about Starlink, the very same story at all mobile/cellphone operators. Remote SDR seems to be a modern techie toy but missing this not so modern technology looks like
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 09:33 #21

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 296
  • Thank you received: 138
Yes, there will be jitter while using VPN, there is absolutely no doubt about that. How big the jitter will be - completely depending from cypher algorithm complexity and HW CPU. There should be reasonable "value for money" balance, dependent on particular user's needs. For some cases (like high speed CW) even minimum achievable jitter will not be acceptable.

Mobile? Forget about it. Minimal upstream bandwidth needed is 8Mbps.

End-to-end IPv6 is currently achievable between very selected providers. For example, in AU half of operators are not currently supporting IPv6 interconnects.

There is also the alternative - just use EE cloud for Remote connects.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 13:32 #22

  • spacex
  • spacex's Avatar
The uplink bandwidth wont be a problem with Starlink at least. Do you know that several fiber optic ISPs are also giving static IPv6 but dont give static IPv4 address.
As the Cloud alternative, well, that's the one which adds the most delay as you have 1 more hop instead of end-to-end connection.

I recommend to carry on this discussion once you make the IPv6 working otherwise i feel like it is a bit like "can't teach an old dog new tricks" situation. As you are HAM you probably like testing, this is a good area to test i believe. 73s
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 14:44 #23

  • VK6NX
  • VK6NX's Avatar
  • OFFLINE
  • Posts: 296
  • Thank you received: 138
spacex wrote:
I recommend to carry on this discussion once you make the IPv6 working otherwise i feel like it is a bit like "can't teach an old dog new tricks" situation. As you are HAM you probably like testing, this is a good area to test i believe. 73s
I recommend that I am no longer interested in that level of conversation. Neither expecting any respond.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 09 Feb 2022 15:06 #24

  • spacex
  • spacex's Avatar
very sorry i meant it feels to me whatever i try you drive it to those bad alternatives instead of test a good solution. I posted here only for help but i will not push, no worries
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 10 Feb 2022 04:25 #25

  • spacex
  • spacex's Avatar
i did not mention i only use Linux systems and all devices are dual stack IPv4 and IPv6 configured.
Without any magic when i start the application i see the control PC is actually via IPv6 UDP6

udp 0 0 0.0.0.0:5353 0.0.0.0:* 760/avahi-daemon: r
udp 0 0 192.168.122.1:53 0.0.0.0:* 1094/dnsmasq
udp 0 0 127.0.0.53:53 0.0.0.0:* 649/systemd-resolve
udp 0 0 0.0.0.0:67 0.0.0.0:* 1094/dnsmasq
udp 0 0 0.0.0.0:631 0.0.0.0:* 11447/cups-browsed
udp 0 0 0.0.0.0:52200 0.0.0.0:* 760/avahi-daemon: r
udp6 0 0 :::5353 :::* 760/avahi-daemon: r
udp6 0 0 :::44346 :::* 760/avahi-daemon: r
udp6 0 0 :::50001 :::* 11688/ExpertSDR2
udp6 0 0 :::50002 :::* 11688/ExpertSDR2
Last Edit: 10 Feb 2022 04:27 by spacex.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 10 Feb 2022 17:39 #26

  • Bigboy
  • Bigboy's Avatar
  • OFFLINE
  • Posts: 75
  • Thank you received: 4
I've been testing the Rigpi remote system/MFJ 1234 with my MB1 and it does work with the Cat control by using the kenwood ts480 setting but it seems to have some glitches, I do have audio on transmit and receive and can control some functions of the radio remotely but like I said have some glitches. One way is also to use the audio board of the Rigpi, the mic in( from headphone out of the radio and audio out( going to the mic1 input of the radio). Total control of the radio i use Google remote desktop and I use mox as ptt/transmit. I use plumble for android and mumble for IOS. This what I use for my remote system for now, honestly I'm a bit disappointed with the remote system of Expert Electenics because until now its not yet implemented.
Last Edit: 10 Feb 2022 17:41 by Bigboy.
The administrator has disabled public write access.

Remote control of EESDR2 or EESDR3 connected by STARLINK 10 Feb 2022 18:27 #27

  • spacex
  • spacex's Avatar
I am not expert on SDR topic, but ExpertSDR guys should be expert on software side as the name suggests..
The hardware is awesome, but software, well i only been using the linux ones and EESDR2 feels unfinished, EESDR3 feels like not ready.
EESDR2 is better for me in linux but i have issues with the audio.
Sometime it just stops working on PC speaker or once i connect USB sometimes recognized, sometimes not.

I wondered why cant they write it properly? Audio works perfectly with almost all applications in linux like skype or all web browser based video tool.
This is not even remote setup, first a proper audio should function.

As for remote there some ways:
1) the narrow bandwidth route is just pass the audio and radio control to the remote end.
2) the wide bandwidth method is passing the HF sample data to the remote end just like you process with the local PC. This was impossible in the past but now remember the whole internet is all about HD, 4K, UHD high bandwidth video streaming. The current version EESDR2 using about 8-9Mbit/sec data that is easily passing thru via good internet lines as fiber to home or Starlink and within the same country or continent no issue at all. Within one continent you have about 60ms latency via Starlink.

Again SunSDR2 DX is amazing as hardware, maybe the best on the hamradio SDR market but there is room to improve on the software side.
Last Edit: 10 Feb 2022 18:29 by spacex.
The administrator has disabled public write access.
  • Page:
  • 1
  • 2
Time to create page: 0.107 seconds