Longer range Wifi *without* modifying TX.

Joined
Jan 1, 2017
Messages
191
Reaction score
17
Age
56
I'm going to try this and there is no reason it should not work really well
It *should work great.

Stock TX and Solo.

My ground station will consist of

* Good battery power for a day
* 2 Ubiquity or similar 2.4GHz Wifi POE devices setup as AP and client with directional antennas.
* wired network switch.

Like these: Ubiquiti Networks - NanoStation® M
*in wifi mode*

Or: ENH202 Outdoor Wireless Bridge | EnGenius


I'll hook them back to back over wired ethernet or hook them into a wired switch.

One device will be setup as a client bridge and associated/connected to the solo tx.
The other will be setup as an access point and use the same SSID as the TX.

So there will be TWO access points that the solo can connect to- the solo TX and the bridged
secondary AP.

Secondary AP can be put on another RF channel or kept on the same.

Client bridge device can be MAC locked so it will only connect to the Solo TX and not connect to the other AP

When the solo gets out of range of the Solo TX with stock antennas it will still be able to connect to (if it is not already connected to) the ground station access point with the big directional antenna which is ethernet bridged/connected to the client bridge device which is connected to the the Solo TX wirelessly.

Simple!!!! but also a bit confusing. LOL.
 
Last edited:
What I don't know yet until I try is if the Solo is hard set to only connect to the MAC address of the Solo TX.
Or if it it will roam / connect to another access point with the matching SSID.
 
Because I'm a network guy I have the equipment and want to play :) So far I did get the Solo to associate/connect to another outdoor AP with the same SSID as the TX :)
 
I'm getting there...
My initial try sorta worked but then failed when the DD-WRT client bridge connected back to the secondary AP
I was for a few minutes had the solo associated to the secondary AP which is wire bridged to the DD-WRT client bridge (which was associated and connected to the TX.
Soon as I turned off the TX the DD-WRT bridge connected to the secondary AP and started a cute little network broadcast storm. :)

So I ssh'd into the Solo and tried to rename the SSID in it to another name so it would connect to secondary AP on a different SSID.
I edited wpa_supplicant.conf which had the SSID in it and renamed it.
Since then I lost it.. and will probably have to factory reset it and the controller to get it back.
I must have edited the wrong file or something..

To make matters even more fun I SSHed into the TX and edited hostap.conf where the SSID was to change it..
After a reboot it came back up broadcasting something like SoloLink_4677
NOT what I had tried to change the SSID to.
So that didn't work either.

And now the TX is going to need a reset apparently.
 
Last edited:
Factory reset everything got it all back connected and tried again.

In Solo only file I can find that has my defined SSID is /etc/wpa_supplicant.conf.
It contains the "SoloLink_name" line that I configured in the solo app.
It also has the WAP2 key on a line.
If I manually change the line to something like "Sololink_name2"
Then I never see it again it does not associate to an ap with an SSID of "Sololink_name2"
Although before manually editing the file and sticking with the name set in the solo app "Sololink_name".
If I bring up an access point with that SSID and WAP2key and turn on the solo WITHOUT the tx on the solo connects to the AP sending the proper SSID.

On the TX the only file that contains my SSID is /etc/hostapd.conf

It also has my SSID on it's own line "SoloLink_name and my wpa2 key on another line.

If I manually change the SSID here in this file to "SoloLink_name2"
on next restart of the TX it goes back to default "SoloLink" and wpa key is "sololink"

Grrrrr......


Irritating!!!

How the heck can I manually change the SSID that the Solo is using as a client

And Manually change the SSID the TX is using as an access point?

Also for cosmetic purposes how do I get the "SoloLink_" out of the SSID and actually use a completely custom SSID?

I'm able to quickly recover the Solo connection now by using the pairing switch on the solo.
This sets the solo back to default SSID client configuration with original factory SSID and wpa2 password

Simply editing the SSID line in /etc/hostapd.conf causes it to reset back to factory default SSID and password on TX restart.

Grrrrrr WTF! :)
 
Last edited:
There is some python involved in the wireless setup. Let me see if I can find something for you.
 
Very interesting. Nothing to add but I'm very curious how far you can take this??
 
Will keep this updated. Ive not been back home to try editing sololink.conf yet. :)
 
Will keep this updated. Ive not been back home to try editing sololink.conf yet. :)

Considering the flight time of the Solo, what is the mission that requires significantly longer ranges than the Solo with a 3rd party antenna like FPVLR? My vision makes it very hard to see the Solo out at 3200', with the FPVLR I can go a little further but cannot maintain LOS.
 
sololink.conf does not contain any SSID settings. as far as I can tell.

sololink.conf:


[solo]
artooIp = 10.1.1.1
soloIp = 10.1.1.10
rcDestPort = 5005
sysDestIp = %(artooIp)s
sysDestPort = 5012
pairReqDestPort = 5013
pairResDestPort = 5014
mavDestPort = 5015
buttonEventPort = 5016
buttonFunctionConfigDestPort = 5017
setShotInfoDestPort = 5018
updaterDestPort = 5019
telemDestPort = 14550
appServerPort = 5502
appAddressFile = /var/run/solo_app.ip
stm32Dev = /dev/ttymxc1
stm32Baud = 115200
telemDev = /dev/ttymxc1
telemBaud = 921600
telemFlow = True
telemLogGap = 1000000
telemLogDelayMax = 100000
rcDsmDev = /dev/ttymxc2
rcDsmBaud = 115200
rcSourceIps = 10.1.1.1,127.0.0.1
useGpsTime = True
pwmInMinThrottle = 1000
pwmInMaxThrottle = 2000
pwmOutMinThrottle = 1000
pwmOutMaxThrottle = 1900
rcTimeoutUS = 400000
uiUnits = metric

[pairing]
user_confirmation_timeout = 30.0
controller_link_port = 5501
wifi_connect_timeout = 5.0
connect_request_interval = 1.0
connect_ack_timeout = 0.5
solo_address_file = /var/run/solo.ip
button_filename = /dev/input/event0

[net]
ApEnable = False
StationEnable = True

[loggers]
keys = root,stm32,pix,pair,net,app,tlm,shot

[handlers]
keys = consoleHandler,sysLogHandler,sysLog2Handler

[formatters]
keys = simpleFormatter,syslogFormatter

[logger_root]
level = INFO
handlers = consoleHandler

[logger_stm32]
level = INFO
handlers = sysLogHandler
qualname = stm32
propagate = 0

[logger_pix]
level = INFO
handlers = sysLogHandler
qualname = pix
propagate = 0

[logger_pair]
level = INFO
handlers = sysLogHandler
qualname = pair
propagate = 0

[logger_net]
level = INFO
handlers = sysLogHandler
qualname = net
propagate = 0

[logger_app]
level = INFO
handlers = sysLogHandler
qualname = app
propagate = 0

[logger_tlm]
level = INFO
handlers = sysLogHandler
qualname = tlm
propagate = 0

[logger_shot]
level = INFO
handlers = sysLog2Handler
qualname = shot
propagate = 0

[handler_consoleHandler]
class = StreamHandler
level = ERROR
formatter = simpleFormatter
args = (sys.stdout,)

[handler_sysLogHandler]
class = handlers.SysLogHandler
level = DEBUG
formatter = syslogFormatter
args = ("/dev/log", handlers.SysLogHandler.LOG_LOCAL1)

[handler_sysLog2Handler]
class = handlers.SysLogHandler
level = DEBUG
formatter = syslogFormatter
args = ("/dev/log", handlers.SysLogHandler.LOG_LOCAL2)

[formatter_simpleFormatter]
format = %(asctime)s %(name)-4s %(levelname)-8s %(message)s
datefmt =

[formatter_syslogFormatter]
format = %(name)s: %(message)s
datefmt =

[video]
videoMinFR = 24
videoMaxFR = 24
videoMinBR = 800000
videoMaxBR = 1800000
videoFRStep = 5
videoBRStep = 100000
varStreamRes = True
cropRecordRes = True
 
  • Like
Reactions: fvincent
Considering the flight time of the Solo, what is the mission that requires significantly longer ranges than the Solo with a 3rd party antenna like FPVLR? My vision makes it very hard to see the Solo out at 3200', with the FPVLR I can go a little further but cannot maintain LOS.

The mission is not to necessarily fly further than an antenna like FPVLR.
The mission is to to fly off another AP that has longer range and is bridged and routed to another network.
There are a number of other reason for me to make this work beyond the scope of this post.

Right now if I could ONLY get the SOLO to be programmed to use a different SSID than the TX it will actually work.
 
Instead of being in AP mode, DD-WRT can be in repeater mode, and you also have the ability to tweak and boost the up the signal on the DD-WRT. The extra power from the DD-WRT might give you more range even though the AP and repeater are right next to each other. I'd like to find out what is in the Solo controller to figure out if you can do some linux tricks to boost the signal. 'iwconfig wlan0 txpower 30' I've ssh'ed into the controller and iwconfig isn't being used.
 
sololink.conf does not contain any SSID settings. as far as I can tell.

sololink.conf:


[solo]
artooIp = 10.1.1.1
soloIp = 10.1.1.10
rcDestPort = 5005
sysDestIp = %(artooIp)s
sysDestPort = 5012
pairReqDestPort = 5013
pairResDestPort = 5014
mavDestPort = 5015
buttonEventPort = 5016
buttonFunctionConfigDestPort = 5017
setShotInfoDestPort = 5018
updaterDestPort = 5019
telemDestPort = 14550
appServerPort = 5502
appAddressFile = /var/run/solo_app.ip
stm32Dev = /dev/ttymxc1
stm32Baud = 115200
telemDev = /dev/ttymxc1
telemBaud = 921600
telemFlow = True
telemLogGap = 1000000
telemLogDelayMax = 100000
rcDsmDev = /dev/ttymxc2
rcDsmBaud = 115200
rcSourceIps = 10.1.1.1,127.0.0.1
useGpsTime = True
pwmInMinThrottle = 1000
pwmInMaxThrottle = 2000
pwmOutMinThrottle = 1000
pwmOutMaxThrottle = 1900
rcTimeoutUS = 400000
uiUnits = metric

[pairing]
user_confirmation_timeout = 30.0
controller_link_port = 5501
wifi_connect_timeout = 5.0
connect_request_interval = 1.0
connect_ack_timeout = 0.5
solo_address_file = /var/run/solo.ip
button_filename = /dev/input/event0

[net]
ApEnable = False
StationEnable = True

[loggers]
keys = root,stm32,pix,pair,net,app,tlm,shot

[handlers]
keys = consoleHandler,sysLogHandler,sysLog2Handler

[formatters]
keys = simpleFormatter,syslogFormatter

[logger_root]
level = INFO
handlers = consoleHandler

[logger_stm32]
level = INFO
handlers = sysLogHandler
qualname = stm32
propagate = 0

[logger_pix]
level = INFO
handlers = sysLogHandler
qualname = pix
propagate = 0

[logger_pair]
level = INFO
handlers = sysLogHandler
qualname = pair
propagate = 0

[logger_net]
level = INFO
handlers = sysLogHandler
qualname = net
propagate = 0

[logger_app]
level = INFO
handlers = sysLogHandler
qualname = app
propagate = 0

[logger_tlm]
level = INFO
handlers = sysLogHandler
qualname = tlm
propagate = 0

[logger_shot]
level = INFO
handlers = sysLog2Handler
qualname = shot
propagate = 0

[handler_consoleHandler]
class = StreamHandler
level = ERROR
formatter = simpleFormatter
args = (sys.stdout,)

[handler_sysLogHandler]
class = handlers.SysLogHandler
level = DEBUG
formatter = syslogFormatter
args = ("/dev/log", handlers.SysLogHandler.LOG_LOCAL1)

[handler_sysLog2Handler]
class = handlers.SysLogHandler
level = DEBUG
formatter = syslogFormatter
args = ("/dev/log", handlers.SysLogHandler.LOG_LOCAL2)

[formatter_simpleFormatter]
format = %(asctime)s %(name)-4s %(levelname)-8s %(message)s
datefmt =

[formatter_syslogFormatter]
format = %(name)s: %(message)s
datefmt =

[video]
videoMinFR = 24
videoMaxFR = 24
videoMinBR = 800000
videoMaxBR = 1800000
videoFRStep = 5
videoBRStep = 100000
varStreamRes = True
cropRecordRes = True

I'm away from my SOLOs, but I have to pull the SDCard for an image next week, so I should be in front of the whole file system then. Sorry can't help sooner.
 
No rush got really busy at work.
I'll mess with it more this weekend.
Just getting the solo configured to associate to a different SSID and not to the SSID that is on the TX will open up a lot of cool possibilities!!
It could also be done in reverse (change the SSID on the TX while leaving the Solo configured for the OLD SSID

I also started investigating trying to MAC Lock the solo or the other client devices to associate to a BSSID (MAC) instead of the SSID
But got a bit lost on that as PWA2 PSK somehow uses the SSID and /or BSSID as part of the keygen so it gets complicated really fast.
And that probably is not the way to go.
 

New Posts

Members online

No members online now.

Forum statistics

Threads
13,094
Messages
147,748
Members
16,057
Latest member
Motoxxx1986