PilotAware
British Forum => Technical Support => Topic started by: ILIMB on November 05, 2023, 10:53:46 am
-
Hi all,
I recently purchased Rosetta and am amazed by the possibilities.
Only, as recently shared with the tech support, I have some doubts about the architecture / suggestions on how to improve it.
First of all, I'm open to any advice or comment based on the experience of long time users. The conversation and reading the below can get quite advanced due to the sheer nature of technical details, but I'm sure there are many advanced users out there who might also benefit of this thread, other than PAW's tech support of course.
The problem - all in one
Another pilot advised me to purchase the WiFi module to benefit of iGRID features, which I was unaware of. Having to use a separate WiFi seemed quite odd from the start, but went for it anyway: in fact, I immediately noticed that on my smartphone (Samsung Galaxy S22 with the latest Android) I could not achieve all the following 4 goals simultaneously:
- stable and reliable setup
- internet connectivity
- Skydemon displaying traffic
- Rosetta connecting to iGRID
Internet connectivity seemed impossible to achieve: in the recent Android versions WiFi is disconnected automatically in case hotspot is enabled and viceversa, but anyway before if you did so you would have just shared the WiFi connection over the hotspot, as once on WiFi you bypass the mobile carrier connectivity.
Not too bad, I though initially, as using another phone or iPad I could have Skydemon and Rosetta's radar displayed in split screen... but nope, once connected to the PAW wifi, Skydemon cannot reach pilotaware, because the folks at SD hardcoded 192.168.1.1 as default target address (and seem also quite proud of this allegedly under the light of "UX simplification", by reading their forums - it's normal, companies often mistreat UX, not having the faintest clue about what cognitive ergonomics are and used as an excuse for not doing what's required).
Yes, I could fix it partially on my main device by using Speedify to obtain both Internet connectivity and PAW, but still I would not have access to IGRID. As said, not all goals can be achieved simultaneously, apparently .
Portable hotspot
So, I decided to use a portable hotspot I already had with a dedicated SIM card (necessary anyway when outside Europe), only to find out that 99.9% of portable hotspots don't allow DHCP reservation, hence it was impossible to assign 192.168.1.1 to satisfy SD's weirdness. The setup worked so and so, anyway, but sadly the devices should not connect to the hotspot directly, which is supposed to be the center of the network, but to PAW wifi, which then reroutes to the hotspot (I get the shivers only by writing this). 3 goals were achieved, but stability... very poor, the wifi interfaces cyclically resetting (as visibile on the home screen), and anyway all mobile devices had to be prevented for connecting to the hotspot directly, when losing connectivity from paw.
Portable hotspot with Ethernet and DHCP reservation
Being goal-oriented (aka stubborn 8)), after some scouting I purchased a XE300 portable router which features an Ethernet port... alongside the DHCP reservation I couldn't find anywhere else in a portable router! Hoorah! ;D
I set up XE300 for my usual SSID, password, security, etc. and reserved 192.168.1.1 for the MAC address of Rosetta's ethernet port, obviously using another static IP for the router itself to avoid conflict, could connect to rosetta via the browser on all devices, incredibly smooth, no additional USB WiFi dongle required, the flat ethernet cable passing nicely through the case tolerance, all seemed good. Until... i opened SD: connecting to device. How come? I was using split screen, I was connecting to paw.local on the browser but SD couldn't see the very same address?
Current stable setup
Well, out of frustration, I scrambled the settings and configured the router on 192.168.0.x to allow the ethernet port sit on 192.168.1.1 and benefit of the routing feature, so still mis-using Rosetta as the center of my network rather than one of its clients. Still way more stable than any other setup, still not requiring the additional WiFI radio, and I'm sticking to it for the time being, but I'm not yet satisfied. What am I missing here?
Further experiments
I got an enlightenment: perhaps the folks at SD also want to ensure I am connecting to a Rosetta, by checking the SSID? You won't believe it, seems I was right: I eventually got SD to see Rosetta, yay! Why is this not in the previous section, current stable setup? Because, for some weird reason which I haven't had yet time to figure out, this setup doesn't allow connecting the device to the Internet while accessing Rosetta via SD, or the opposite.
If this set up worked 100%, all 4 goals would be achieved, and I would also try and disable the onboard wifi, to avoid any unnecessary consumption and interference (so far I only lowered to 1mw in this setup).
Obviously this is all due to the weird constraints on the SD's side, but if anyone could take a look and give some advice on how to fix the "ultimate setup", I'd very grateful.
Solution as of 26.11.23, TLDR version
Instead of banging my head with the PilotAware protocol, which apparently relies on UDP unicast (rather than multicast)... better use FLARM as suggested by Admin 8)
Thanks PilotAware folks for supporting on this setup.
All the best
-
The following is just my opinion. A grown up like Lee or Keith may come along and mark my homework, whatever they say is gospel. I'm using a Huawei MiFi for my Internet access.
The iGrid network to access the Internet via your hotspot and your PAW feeding traffic info to anything on 192.168.1.1 are two separate networks. That's why there's the internal Rosetta WiFi and a second iGrid WiFi network.
The "Router" function when turned on in the PAW will do just that, and route between the two. The IP addresses therefore do not need to be part of the same subnet.
I think you've over analysed it and should just set everything up as per the instructions, You do not need to reserve IP addresses. Even if things were as you say they were, you could just set your DHCP range to 192.168.1.32 to 192.168.1.64, with the gateway at .254, and then 192.168.1.1 would be a safe IP address anyway for that subnet. No reservation needed, but you've gone down a rabbit hole there. The iGrid and the PAW main Wifi are not the same network, so don't try to make them thus.
Leave the PAW base IP address as is. Connect the mobile phone to the PAW on the PilotAware-whatever network, which you should really change to G-YOURREG IMO.
Configure the MiFi/Internet router on a sensible subnet, mine as stock was 192.168.8.1 gateway, with subnet 255.255.255.0, DHCP range is therefore a WGAF, but needs to exist for other devices and fault finding/config.
Turn on the PAW router function, connect to the MiFi, and then you will find (I was doing this last time out) that the split screen on your Android phone has PAW radar in one part of the split screen, SD on the other with traffic and internet access for winds and NOTAMs.
Rosetta is not exclusively a device connected to Android; later iPhones can make the hotspot and WiFi work simultaneously. I have seen this and watched it set up - there is a certain sequence to it that must be followed. Rosetta can't be constrained by Android, as the Android/iOS split in the UK allegedly close to 50%?
Use the portable hotspot as outlined above. Forget DHCP reservation, Ethernet connections, etc., etc.. Put it on a separate subnet, connect to it, and set the "Router" function on.
There is a gotcha with your Ethernet option - the router function is only on AIUI in the PAW if the second dongle is plugged in, so then the routing between subnets can only be turned on then.
Follow the destructions for best results.
-
Sometimes ignorance is bliss. I really don't have any in-depth knowledge of DHCP, sub net whats its etc.
My set up:
1. SkyDemon with PilotAware enabled as a 3rd party device and 'Use Internet in flight' switched on in Navigation Options. Installed on iPad Mini 4. It is the GSM version (so has an internal GPS) but no sim card in place.
2. 4G dongle plugged into USB power supply (NOT plugged into PilotAware)
3. 4G Dongle SSID and password saved in the Hotspot section of the Network configuration page in PilotAware & router function enabled
4. Switch the power on. iPad connects to PAW WIFI (if it doesn't, select PAW SSID in Settings). 4G dongle connects automatically to PAW (it always does but, if not, connect in Network settings).
5. Hit 'Go Flying' and use PilotAware
6. Behold GPS position, traffic displayed and Internet on iPad Mini to update SkyDemon winds etc.
7. Normally split screen with SkyDemon and Safari. Go into the Safari address bar and type 192.168.1.1 (okay, I actually have it as a bookmark but you know what I mean) and have the Radar display alongside SD.
No mucking around trying to outsmart the kit. No idea that 168.192.1.1. is somehow a bad thing. To me it's just an address to type.
It works.
Not a brilliant e.g below as I'd just lost the 4G signal but at least the orange blob lets me know that
-
Thanks both for your contribution, and I'm sure you are happy with your setups.
The setup I described with the Ethernet port replacing the second wifi is actually superior in terms of reliability, and this thread is primarily about getting brains to solve the issues outlined. Not understanding them in the first place might not help, but I'm still happy to brainstorm and read anything, including "we always did like this" or "read.the instructions", which I did. Didn't like what I read and the experience I described, hence the need to go beyond.
-
@Admin, @Keithvinning, can you please shed some light in here?
I am trying again to make the simplified setup work, and I cannot understand why it shouldn't with the attached configuration, which I'm also pasting here:
PilotAware Rosetta-RX : Version(20231022) License Expires(20281009)
_ Interface Status
HOSTID B827EBFE2851
PLATFORM Model B Pi 3+, 9 (stretch)/4.14.79-v7+
DATE Sun Nov 26 14:06:03 2023
IP eth0=192.168.1.1 wlan0=UP iGRID-wg=10.200.0.48
UPTIME 14:06:03 up 0 days 00:06, Load 1.20:0.84:0.41
STATUS Volt=OK Freq=OK Thro=OK Temp=52.1/52.1 EM=0 SG=0
1090 Connected RX=1510(+6)
P3I Connected UP=0.06% DN=0.00% Mode=Airborne
Traffic=0 METAR=0 Status=0 ATOM=0 SkyGRID=0
Barometer Configuring (Manual) QNH=1013mb QNE=426ft GNSS=0ft
GPS RX=2863(+0) Fix="No fix" Mode="Not Available" Sat=4(use)/10(view)
It all work perfectly, except... Skydemon for some weirdness of their own can't see Rosetta. All protocols are enabled by default, eth0 is on 192.168.1.1. Could it be that for some reason UDP doesn't get through in this configuration, that it only relies on WiFi?
-
It all work perfectly, except... Skydemon for some weirdness of their own can't see Rosetta.
Is the router function on? I'm guessing not, as it only appears when the second wlan is there...
Might not be needed as you may be on the same subnet...
If you can open a terminal app in Android, can you ping 192.168.1.1 from it? Or can you see the phone's IP address on the WiFi? Select the i next to the wireless network for info on the phone...
-
Is the router function on? I'm guessing not, as it only appears when the second wlan is there...
Yes it is, but as you correctly say it's not required, as in this setup the router is the portable modem itself and Rosetta is just a client in the network, as it should be.
If you can open a terminal app in Android, can you ping 192.168.1.1 from it?
Of course. I can also ssh and access PAW web interface. All it's missing is SD "seeing" it.
Or can you see the phone's IP address on the WiFi?
Of course, it's on the same subnet.
The irony is in the previous posts: I thought I fooled SD by labelling the SSID PilotAware-xxx, and partially I did, but based on the selection of a random MAC address Vs. the phone's actual one, I can respectively get either access to SD or connection to the Internet, but not both at the same time, which apparently does not make any sense. In both circumstances, though, I can access PAW's web interface and Rosetta is connected to the Internet.
I'm still banging my head on this not just because it's the very last mile of the most logical network setup, but because using it with the standard configuration I still haven't managed to get a stable, reliable WiFi connection with more than a single device. The moment I connect two devices to Rosetta's WiFi, things get weird: one gets correctly routed to the Internet, the other not.
I also thought it was a problem with my android, but with an iPad I still get the same result. The next attempt will be trying to fit Rosetta in my home network, which requires a little bit more than just some tweaking, to exclude that the limitation lies with the portable hotspot itself...
-
Rosetta sends UDP packets to its clients
If I understand correctly your ipad is a client of the router, not of rosetta
Therefore Rosetta does not send udp packets
You could try using skydemon FLARM connection method, this uses tcp instead
-
But it's strange, I checked the network configuration with ssh and I saw that the hotspot has a br-lan bridge interface including UDP multicast between wlan0 and eth0, so UDP should have passed.
Anyway, great! Didn't know about FLARM, it works flawslessly! Sooo... seems the ultimate stable setup is ready, PAW wifi back to 1mW, router disabled and hopefully I should be able to use it on my next flight! :)
Is there any significant loss by using FLARM Vs. PilotAware?
Btw, does this strictly rely on Rosetta being on 192.168.1.1, right?
-
The UDP data is unicast, not multicast
The address of 192.168.1.1 is hardcoded into skydemon
Thx
Lee
-
Ah I thought multicast! Why bother using unicast on a veeery private network?
Anyway, is connecting with FLARM equivalent or is there any loss of functionality?
P.S. Now Rosetta seems to be so happy to do only what she's meant to do, that even the GPS fix is much quicker. Normally I put her on the window for testing and it takes half an hour, now it's a matter of minutes. Also the web interface is much quicker without the hassle of WiFi connections.
-
Rosetta sends UDP packets to its clients
If I understand correctly your ipad is a client of the router, not of rosetta
Therefore Rosetta does not send udp packets
The UDP data is unicast, not multicast
The address of 192.168.1.1 is hardcoded into skydemon
@admin out of curiosity, how would you explain the attached screenshot, according to the quoted texts above? As you can see, SD was happily connected to PAW (no GPS fix, meaning connection established, only indoor), the only issue being that the mobile device could not connect to the Internet. But it was indeed connected to the hotspot, not directly to Rosetta, and apparently was still receiving UDP unicast / was recognized as Rosetta's client?
PilotAware-TopGun is the hotspot, DoNotUse is Rosetta.
-
Have you ever considered how much time tinkerers, like you, take up in having to reply to unnecessary queries, brought about because you can’t just simply turn it in and allow it to do it’s job? I get people with similar ‘what about’ questions in my job; continually trying to fix something that isn’t broken. My patience is much reduced compared to Lee and Peter and I can only imagine what I’d be thinking.
Just leave it alone and go and build something else to play with.
-
Have you ever considered how much time tinkerers, like you, take up in having to reply to unnecessary queries, brought about because you can’t just simply turn it in and allow it to do it’s job?.
This rant coming after the intended setup is complete, only increases the satisfaction.
You already showed unmistakable signs of functional illiteracy with the previous judgemental post, leaving only a stale smell as if coming from the past, only I was kind enough to avoid putting a spotlight on them earlier.
In case you haven't noticed during your *valuable" time spent commenting hundreds of posts on this forum (...), Rosetta isn't exactly an industrial, monolithic toaster, but rather the sheer result of tinkering with an open innovation platform (Raspberry PI) itself: bits and pieces of hardware produced for other purposes, assembled in a way that wasn't intended to be before, somehow squeezed in a plastic case. Far from being perfect, and little research shows it's constantly evolving, as it should.
What's an open forum like this supposed to be for, otherwise? Only sharing your experience about how to operate a toaster, accordingly to the manual, and occasionally fix it?
-
Have you ever considered how much time tinkerers, like you, take up in having to reply to unnecessary queries, brought about because you can’t just simply turn it in and allow it to do it’s job?.
This rant coming after the intended setup is complete, only increases the satisfaction.
You already showed unmistakable signs of functional illiteracy with the previous judgemental post, leaving only a stale smell as if coming from the past, only I was kind enough to avoid putting a spotlight on them earlier.
The use of the phrase, "only increases the satisfaction" seems to imply some sort of taunt.
Then you accuse someone of "functional illteracy". This is a personal attack, which is not what this sort of forum is for, IMO.
-
It is true that I have lost touch with programming. That stopped with my A Level computer science in 1984 and the world advancing from Machine Code, Fortran etc. Until then I was pretty good.
The fact that my PAW Classic, with Serial connection to my Dynon HDX, GPS from the HDX, WIFI to my iPad/SkyDemon and iGrid all work perfectly, without me trying to re-program anything, would indicate slightly better than ‘illiterate’……….whilst accepting the expertise of the likes of Lee and Co, who have made such a good job of making it plug & play for the other ‘illieratii’.
My ATOM station also works very well, despite me not interfering.
You’re not actually trying to improve things for the benefit of others. You’re just attempting to show off how much better your ideas are compared to Lee and Co. Whereas they are far too polite to say, there are others amongst us who are quite happy to say we really don’t care how clever you think you are.
-
For the avoidance of doubt
- if you find a bug, report it, we will fix it
- if you want an enhancement, report it (enhancements page) we will consider it
For enhancements, we are always looking at feasibility, ease of implementation, and how many likes get assigned in order to gauge how broad the request is from the community
We have limited resources, and must apply them where best applicable
Finally, lets keep positive- we surely don’t need another flyer forum :o
Thx
Lee
-
Finally, lets keep positive- we surely don’t need another flyer forum :o
Wise words!