Messages

46

Technical Support / Re: Wi-Fi loss after reset / reload

« on: June 13, 2023, 02:31:21 pm »

Hi Alan,

Thanks for letting us know.

You don't say which version of software you were trying to update from and to or the update method you were using. Please let us know as this might be significant to what occurred.

You were lucky - although the 'unpack' phase of an update should only take 5-10 minutes at most, it can take longer. Powering down or rebooting during this process can easily corrupt the microSD card, which then requires a full overwrite reformat of the card and reload of the software from scratch. The trick is to wait until the WiFi Hotspot reappears on your tablet or phone, or (as Steve has said) where there is a suspicion that all hasn't gone smoothly (such as if the WiFi Hotspot doesn't reappear), wait 20minutes or so, then connect the unit via its HDMI port to a monitor or TV before rebooting it. This allows the progress to be monitored to the point where the software reaches its 'login prompt', which identifies that the update or install has been successful. (You don't actually 'log in' but at that point can remove the HDMI / monitor.)

Best Regards

Peter

47

Technical Support / Re: USB output messages and iGrid

« on: June 13, 2023, 02:16:45 pm »

Hi Bob and Welcome back,

I'm guessing Lee won't have progressed this any further in view of his post of 23rd January where he reports that he was unable to recreate the issue reported, and the lack of any further response from @russp since then.

If you are still running PAW Version 20220805, that is well behind the curve - so I suggest you update to the latest public release (20230316) and see if that sorts out your problem.

Please let us know.

Best Regards

Peter

48

Technical Support / Re: CAP1391 shows as bearingless in SkyDemon via PAW

« on: May 26, 2023, 05:00:29 pm »

Hi again Alex,

Thanks for the further update.

Ok, so…. This time I spent a good amount of time trying different settings of a SE2.

I tried:

1) transmit setting at 0 kts and at 10 kts
2) position SE2 within 2-3 meters of paw and within 10-15 meters of paw
3) Ensured that the actual aircraft was parked and OFF

This time I did not manage to replicate the bearingless target issue in any configuration…in fact, initially SE2 signal did not show at all. After a couple of reboots it did show on SD via PAW with either transmit setting and distance from PAW.

SE2 shouldn't show on PAW or the flight tracking app if its Tx setting was set (and saved) at 10Kts, unless the unit was moving at more than that threshold speed. If as you say, it was reporting on SD via PAW (and on the flight tracking app) after a couple of reboots with either transmit setting, (and when presumably stationary), that would indicate that the VSO setting in the SE2 clearly isn't working as it should.

Very inconclusive tests to be honest… the only thing that remained consistent was that SE2 was always visible on a flight tracking app (even when not visible on PAW). I know for sure that in principle (and probably in most cases) I do see SE2 from flying aircraft. But what happened here will still remain a mystery.

That is entirely possible. You must remember that flight tracking apps use multiple receivers with high-gain antennas to pick up 1090 Traffic Signals from multiple directions. These are then combined before being presented on the app, so the app can often report weak transmissions where the signal might be obscured from an individual PilotAware, SE2, (or any other aircraft-based receiver) by metal or carbon fibre, human body tissue or any other non-RF-friendly components in a specific aircraft equipped with PAW, SE2, or any other  receiver. This is why we strongly advocate the use of externally mounted antennas wherever possible (which of course isn't possible with SE2).

Best Regards

Peter

49

Technical Support / Re: Waiting for device

« on: May 13, 2023, 07:20:09 am »

I've been using my trusty Samsung Tab4 SM-T230 running Android 4.4.2 which worked with my PAW faultlessly for several years.
Now I've "upgraded" to a Samsung A7 lite SM-T225 Android 13, I keep getting the "waiting for device message" in Sky Demon, normally after about 20 to 30 mins from start up.
Usually need to turn the tablet wifi off and back on, but once the problem starts, it repeats at random intervals. It's been like this for the past 6-9 months and not changed behaviour even with several recentish PAW firmware updates.

I'm pretty sure its a tablet issue as I've been in P2 seat with P1 running his Apple table, my Samsung flags the message but the Apple functions properly. I've also repeated the test with my phone and tablet connected, tablet flashed the message but phone continues to work fine.

As far as i can tell, bth tablets are configured the same.

Any suggestions?

ATB
Deker

Hi Derek,

Definitely sounds like a WiFi connectivity issue to me, but of course not easy to determine exactly what.

Remind me - are we talking Rosetta or PAW Classic?

When you go to 'turn the tablet WiFi off and back on' do you notice whether it has connected to something else in the plane - such as another phone? If so, it might just be a question of adjusting the PAW WiFi strength / channel from the default settings. I have just dealt with a similar issue for a mate running an 'upgraded' Classic on a Pi3 board (so not simply a faulty WiFi dongle) into an full size iPad in his Emeraude - which we seem to have resolved by reducing the PAW WiFi power from 50mW to 20mW. Take a note of the defaults before you make any changes and just change one field at a time and test fly before changing anything else - and remember to try both reducing the WiFi strength and increasing it. I can't remember, but you may also have to reboot your PAW each time for the changes to take effect.

Let us know if that helps.

Best Regards

Peter

50

OGN-R PilotAware / Re: ADS-L (Automatic Dependent Surveillance - Light)

« on: May 04, 2023, 04:41:55 pm »

Hi Ian,

EASA project working towards combining various EC modes / systems (including 1090MHz Mode-S, Mode-S /ES, ADSB, FLARM, PilotAware, Stratux and Cellular Based systems like SafeSky) to produce an interoperable EC Network (something like an extended / expanded version of ATOM-GRID) and allow manned and unmanned aircraft to integrate together in certain classes of airspace (known as ‘U-Space’). Should be good for us as it expands on PilotAware’s policy of maximising integration of existing and future EC systems.

Hopefully a positive step forward and ‘should’ help to influence the UK authorities to go down a similar route, rather than simply trying to force everyone to adopt their preferred 1090 ADSB - based option.

Having said all that, I have seen a few videos and read several papers on ADS Light, but hadn’t seen that paper yet, so thanks for posting the link. I will read it tonight.

Best Regards

Peter
p.s. I have expanded the thread title for clarity

51

Technical Support / Re: P3I not connecting. RED status when others are GREEN

« on: May 02, 2023, 12:20:38 pm »

Hi Derek,

Great to meet up with you at Popham at the weekend. Glad to know it's now working OK. Investigations into exactly what caused the issue are in hand and we will post on here if we need to.

Best Regards

Peter

52

General Discussion / Re: Aircrew Traffic Display

« on: May 02, 2023, 12:13:29 pm »

Hi Sean,

I was speaking to James just last week, as a friend, (and because the small heatsink had come adrift off the voltage regulator in my own Aircrew prototype and I wanted to ask what to fix it back on with). I'm sure he won't mind me sharing the following with you.

The company has unfortunately become a victim of the parts shortage I'm afraid, but hasn't been fully shut down as far as I know - just 'mothballed' while James tries to make a living elsewhere and works out where to go from here. A great pity as he was just starting to see sales increase and was at an advanced stage of developing future products when the pandemic came along. Nothing has been sold on to my knowledge, except the Aircrew Track and Groundstation Replay Tools have been taken on by PilotAware. James still holds the IP and whatever other assets for Aircrew and we exchanged ideas about how he might be able to move things forward in future.

On the heatsink issue, BTW, he suggests opening Aircrew (4 small screws to remove the backplate) and checking the integrity of the obvious small black heatsink by applying gentle pressure. If it's loose and you aren't running the unit on 12 volts - simply gently remove the heatsink as the regulator isn't being used, rather than risk the heatsink coming loose in flight and shorting something out. If it's still stuck tight, leave it alone!

James still intends to support existing customers while waiting to see what develops. If you need to contact him urgently, PM me a number and some details and I'll pass it on.

Sorry I can't say more at present.

Peter

53

Technical Support / Re: CAP1391 shows as bearingless in SkyDemon via PAW

« on: May 02, 2023, 11:20:25 am »

Hi Alex,

Sorry for the delay in replying. I was away at Popham all weekend so rather busy, then had to fly all the way back up to East Fortune.

You still haven't given us your actual current PAW software version - it is reported on the first line of each track file, including the one you quote from in your latter post.

Thank you so so much! All super interesting and very details and triggered lots of thoughts, so might not be a short answer from myself either as some points are carry over from the original post idea and some completely new

1) The erratic behaviour you shared – does that mean that if I have mode-s 3D enabled – I am fairly likely to be displayed with similar output in my PAW? If so – I must admit I would probably go for disabling the 3D MLAT as got me thinking that I might be wrongly looking for a plane in a certain direction, so rather look all around due to a bearing less notification.

No definitely not - enabling Mode-S 3D simply allows you to see Multilaterated (triangulated) Positional Targets Reports for Mode-S aircraft where these are available, instead of just Bearingless Target Reports. It has no effect whatever on the performance of your own aircraft transmissions. My advice would always be to enable Mode-S 3D as soon as you are fully aware of what it does and how it works (which is why it isn't enabled by default).

2) I in fact flew today and experienced a situation when an aircraft was first showing as bearlingless target and then next minute as a specific position. My Mode S 3D was disabled then, so in such circumstances it would totally make sense that possibly that other aircraft had some portable device that was visible sometimes to my PAW but not always. See first screenshot attached.

Unfortunately the screenshots are a bit poor to see exactly what they are reporting (especially the one with the red ring). Even zooming in, I simply can't see enough to confirm whether the two reports are from the same aircraft.  Assuming, however that they are, that would be perfectly normal expected behaviour for a Mode-S aircraft if you had Mode-S 3D enabled. Mode-S displays as Bearingless (so a circle on SD with Relative Alt - and Reg ID if 'Show Registrations' is selected in SD Nav Options) when you have NO ATOM, iGRID or SkyGRID uplink. It then swaps automatically to a 'known position' target if you get a Mode-S 3D report from ATOM, iGRID or SkyGRID, then drops back to Bearingless if you lose the uplink(s) again. I note, however, that you say you had Mode-S 3D disabled. In that case the signal must have been swapping between raw Mode-S and CAP1391 (or PilotAware) - so between Bearingless and Known Position - which fits with what I found in my analysis of your earlier track reports for G-NXOE). PAW would then prioritise the 'known position' reports while they were being received (even from a weak CAP1391 or PAW signal) but would drop back to a Bearingless Report with no position whenever the CAP1391/PAW signal dropped out.

3) I have to point out that original question is unfortunately still remains a bit of a mystery because it was not really about MLAT or anything. I know for sure that they left a CAP1391 on by mistake in a parked and completely shut down aircraft and I was only 50m away from it, but still saw it as bearing less through PAW (second screenshot).

That is still a bit of a mystery.

The lower screenshot 'appears' to show G-NXOE reporting as 'Mode-S + ALT' - or we a.) wouldn't have a Bearingless ring, and b.) wouldn't have the Aircraft Reg showing. If it was only transmitting Modes A/C, it would report as 'C-xxxx'). The REG 'might' of course be coming from the SkyEcho, but I can't see how you would get a Bearingless ring associated with it - except as I explained earlier that there was a very short-term glitch in (I think) the Ground Station Software, which was reporting some CAP1391 units as DF17 - which is the mode transmitted by Mode-S/ES (ADSB) Transponders. That fault was however found and fixed extremely quickly, so shouldn't 't have persisted (hence why I need to know the PAW software version that was in use at the time of your log.

My log decoding skills are a bit rusty (I usually leave that to Lee), but your reported log-line certainly does seem to show G-NXOE reporting as Mode A/C - and not Mode-S or S/ES (ADSB), sorry I can't remember what the rest of it means. That might be explainable if the transponder had been left in 'Standby' or 'Ground Mode' or has a Squat Switch, to stop full transmission until in the air.

I still thing it's an issue with G-NXOE.

Best Regards

Peter

54

General Discussion / Re: Best settings to reduce clutter

« on: April 25, 2023, 08:38:54 am »

Hi James,

I have been using PAW extensively both for development testing and normal flying since 2015.

My settings depend on whether I'm testing (when I want to see the 'bigger picture' - so will run PAW Bearingless on 'Long Range' and +/- 4000ft  or even +/- 50,000ft to get maximum reports) or merely out for a local flight or transiting the UK (when I'd normally run Bearingless on 'Medium Range' and +/- 2000ft, or in busy areas - like the Midlands or South-east - on 'Short Range' and +/- 1000ft, with audio alerts ON - and be prepared to take avoiding action at shorter notice). Longer range and wider relative altitude generates more Bearingless alerts, which can be annoying especially in the vicinity of busy airfields, though I have a mechanical volume control fitted to allow me to turn the volume down easily if it gets too distracting.

Known position targets are much less of a problem, as they simply appear on screen based on the current zoom range of your tablet - so you don't set horizontal display limits in PAW (the settings options in PAW/Config for 'known-position' targets are only intended for use with display systems that don't have their own inbuilt settings). The vertical limits for known-position display are dependent on your SD (or SV) settings and audio alerts for known-position targets are preset as the aircraft crosses any of 3 defined horizontal/vertical boundaries, starting at 10Km and +/- 2000ft, and you can select whether you want to be alerted at all 3 boundaries or just the closer ones in PAW/Config.

See here for further information... https://www.pilotaware.com/knowledgebase/configuration

Hope this helps...

Best Regards

Peter

55

Technical Support / Re: CAP1391 shows as bearingless in SkyDemon via PAW

« on: April 24, 2023, 11:46:53 pm »

Edited

Alex,

That aircraft reports as a Cessna 172 out of Goodwood.

I don't of course have the full picture, but looking at PilotAware Replay and the PilotAware Database for the date in question, the aircraft was reporting what appears to be a very weak Mode S signal (via MLAT) around the south coast in the Goodwood / Selsey area from about 9:15am - initially operating what appear to be circuits out of Goodwood until about 09:30, but with pretty erratic position reporting. The weak MLAT reports on our network were to be fair probably partly attributable to the aircraft operating at very low level (less than 1000ft). It then appears again from about 10:30 to 11:30 - again as an extremely poor Mode-S (MLAT) signal, but with very occasional bursts of ADSB 18 - probably from a poorly sited CAP1391 device. It next appears from about 12:15 to 12:30 - again as a very irregular CAP1391 ADSB 18 Only signal between Goodwood, Selsey and Hayling Island, before suddenly switching from CAP1391 ADSB Only back to Mode-S again (as if the transponder was suddenly switched on) and thereafter showing a poor mix of ADSB / Mode-S MLAT back to Goodwood - again with extremely erratic position reporting (at low level) and lots of gaps. There is then a single 'ping' at 14:06 at 375ft (at Goodwood - presumably in the circuit or on the ground), followed by a re-appearance as a mixture of CAP1391 ADSB and MLAT in the Goodwood /Selsey/Bognor Regis area from 15:40 to 16:15, after which it seems to be operating as purely Mode-S at a fairly consistent altitude of between 750 and 950ft until it returns to Goodwood at around 16:50.

The erratic nature of the Mode-S reports would mean that PilotAware would keep changing between known-position (when the MLAT is reliable) and Bearingless (when it is not) and the aircraft would be reported as such on SkyDemon (provided you had 'Show Bearingless Targets' enabled). This would certainly explain (at least as far as I can tell from what you have sent us) what you were experiencing - i.e. intermittent known position reports from the poor MLAT/CAP1391 interspersed with random intermittent Bearingless target reports from the Mode-S - NOT the CAP1391.

It's certainly one of the most erratic reports I have ever looked at. If it was my aircraft I would be extremely concerned about the poor quality signals which appear to be being transmitted from it - with ADSB CAP1391 (perhaps understandably) only reporting out to less than 10Km, but my greater worry is the extremely poor quality of the MLAT reports which may well indicate a problem with the aircraft's Mode-S transponder.

Best Regards

Peter
p.s. you can check this for yourself at https://playback.pilotaware.com/playback/groundstations/ by selecting the Transmission Type, putting in the ICAO code and Start Time (3 hour segments max, though shorter periods give a more detailed expanded report) and clicking on 'Search'.

56

Technical Support / Re: P3I not connecting. RED status when others are GREEN

« on: April 23, 2023, 11:29:38 pm »

Edited to improve clarity and provide a bit more detail

Hi Derek,

There are several obvious differences between the two screenshots, but it's extremely difficult to determine a cause remotely as we have very limited information available.

The term 'Unavailable' usually indicates that the device pertaining to the function is either ''not present' (for example it has been removed or accidentally become disconnected) or is defective in some other way. So although you say 'it doesn't seem to be a radio bridge problem or a loose connection', these are to my mind the most likely issues which would cause this response, i.e. something (in this case the Bridge) having come loose and moving in flight, yet not moving when on test at rest later at home. That said, there is a standard sequence of checks to try, to help pin down the fault.

The first is to confirm that you have a good solid reliable power supply. Up to around 90% of PAW faults can be traced back to power supply issues. This doesn't seem to be a problem in your case as the power status reports are all showing 'OK' in both screenshots - but I would still perform a 'wiggle test' of the power cable with the unit up and running to check the integrity of the microUSB connection at the PAW and the integrity of the power cable as a matter of course. Watch for any changes to the power reports or any change in the 'steady solid red' Power LED under the PAW antenna (difficult to see but usually visible through the slots next to the power plug). Another common power issue is that the power cable has been 'swapped out' (deliberately or accidentally) and the 'replacement' is of inferior quality to the one originally supplied by PilotAware - you'd be surprised at how often this proves to be the problem.

The next thing I would do is check that the microSD card is properly seated in its slot (between the two antennas) by carefully removing and replacing it (with the unit powered off). If that doesn't show up a fault, try powering up the unit connected to a monitor or TV via the HDMI socket on the PAW to see if this shows up any software loading issues. If it gets to the 'login prompt' without any errors or showing (in red) or freezing, all should be OK (you don't actually log in at the login prompt - this merely shows that the boot sequence has finished). Again I'd be surprised if this shows any issues in your case, but always worth checking anyway.

If nothing has shown up in the earlier checks my next step would be to check that the bridge is correctly mounted onto the Raspberry Pi inside the case, and that the connection between the P3i antenna and the Bridge is intact. To do this, you need to open the Rosetta case - which you may not want to do if the unit is still on warranty. If you do decide to do so, first remove the cap from the end opposite the antennas by gently pressing down in the centre of the cap next to the join to release the clip, then sliding the cap away from the main body of the Rosetta. It's worth checking at this point for anything out of place or loose in the USB sockets inside the end cap.

Next remove the P3i antenna from its SMA connector and remove the brass nut which secures the SMA (and Bridge) into the top half of the case. (You don't have to remove the nut from the 1090MHz SMA, but it would be advisable to remove the antenna) and remove the microSD card by carefully pulling it out of its slot between the two antenna connectors (if you don't remove it at this point, you risk physically breaking the card as you split the case). You are now ready to split the case itself. There are two hidden clips on each side holding the upper and lower halves of the case together. They can be released by carefully inserting a thin blade into the joint between the two halves of the case at the appropriate points and pressing it in firmly but carefully  - just enough to release each clip in turn. It's best to start with the clip which is located approximately midway between the 3.5mm Audio Socket and the now open end of the case as this is the easiest to find and release. Once this clip has been released it makes it easier to find and release the next one on the same side - which is midway between the power and HDMI sockets. The clips on the other side of the case (which are located at corresponding points to the ones on the first side) can then be released by gently inserting the thin blade or even a thumb nail, following which the top of the case can be removed by lifting and carefully slipping it off the P3i SMA connector.

Having opened the case, you then need to check two things - first that the SMA connector is still intact on the Bridge board (i.e. it hasn't become physically detached from the board - usually as a result of physical force having been applied to the antenna) and second that the Bridge is fully and squarely seated home on all 40 GPIO pins onto the Raspberry Pi motherboard. If either of these are incorrect, you have found your cause. If not, or if you don't want to disassemble the unit, I'd suggest returning the unit to PilotAware for further examination and testing (contact support@pilotaware.com to arrange this).

Best Regards
Peter

57

Technical Support / Re: iGrid connection

« on: April 23, 2023, 08:00:06 pm »

Hi Derek,

Thanks for the info.

By the way, I notice that your device is showing a software update available on the bottom of the PAW Radar Screen. Are you aware of how this works?

For those not aware, if you are running iGRID, your PAW will check for updates via iGRID and if available, will download the new software over iGRID  in the background, while the PAW is running and then present you with the 'update available' message on the bottom of the PAW Radar Screen. PAW will only install the update once you instigate the installation via the PAW Update Screen.

After you see the new software alert, go to the PAW Updates Screen and select the option to install the new software then initiate the installation from there. This usually takes around 5 minutes and will cause the unit to disconnect and reboot during the process, so you need to watch for the PAW WiFi reappearing. JUST REMEMBER NOT TO POWER OFF THE PAW WHILE THE UPDATE IS IN PROGRESS AS THIS IS LIKELY TO CORRUPT THE INSTALLATION.

Best Regards

Peter
(PilotAware Development)

58

Technical Support / Re: iGRID WiFi dongle not working for normal WiFi connection?

« on: April 23, 2023, 09:38:59 am »

Hi Alex,

You are correct, a quick search on Amazon shows a few WiFi dongles which look like the ones used with the PAW Classic, but only one of them mentions the RT5370 chipset. In the early days (when PAW was a self-build project) we found that lots of the 'generic' dongles advertised for sale on the internet - even those which were advertised as based on the RT5370 chipset - simply wouldn't work with the PAW software. You would have to take a gamble and buy one and try it.

If you do, please let us know how you get on.

Best Regards

Peter

59

Technical Support / Re: iGRID WiFi dongle not working for normal WiFi connection?

« on: April 22, 2023, 12:03:26 pm »

Hi OGM,

You are correct in what you say about the dongles only working on 2.4GHz, but that's not the reason why the 'iGRID' dongles won't work as 'primary' WiFi dongles with Alex's PAW Classic.

The reason for that is that the PAW software was configured to operate with WiFi dongles using the RT5370 chipset as PAW's primary WiFi 'transmitter' to generate the WiFi Hotspot in the PAW Classic. The iGRID dongles use a different chipset so are only recognised as 'Receivers' by the current PAW software.

Unfortunately the older (RT5370 chipset) dongles are now virtually unobtainable. The solution to address faulty primary WiFi dongles in PAW Classics is now therefore to 'upgrade' the motherboard in the PAW Classic to a Raspberry Pi 3B which has a 'recognised' internal WiFi chipset on the board. This also releases a USB port for those who also run other facilities to/from their Classic such as 'GPS Out' to a Transponder or 'Direct Flarm In' from a Flarm Transceiver.

Alternatively, if the PAW Classic is otherwise still working, consider trading it in against a new Rosetta and we will repurpose the useable parts and donate them towards the installation of another ATOM Station. 

Best Regards

Peter

60

General Discussion / Re: Best settings to reduce clutter

« on: April 21, 2023, 10:04:21 pm »

Hi James,

I agree likewise - actually posting your settings would be helpful - and when you are talking 'clutter' do you mean visual or audio? Also what are you displaying the 'traffic' on? (by which I mean tablet, phone or other - such as Dynon display) and if a phone or tablet, which software are you using? (presumably something like SkyDemon or EasyVFR - or are you using something else?)

As a general principle when setting up PAW, we usually recommend leaving the settings in PAW 'wide open' (i.e. at maximum vertical and horizontal range) and using the display system filters to control what is or isn't displayed. In SkyDemon, for example, this is set in 'Settings/Navigation Options/Show Within Vertically'. This setting allows you to choose the relative (vertical) altitude range you want to be warned about. Most will set it to somewhere around +/- 1000 or +/- 2000 feet. That should exclude most of the stuff you don't want to see (and aren't likely to collide with unless one of you is climbing or descending steeply), while ensuring you get sufficient warning of anyone climbing or descending rapidly towards you. Remember of course that within your chosen relative altitude band all traffic is automatically displayed within the range limits of your display screen. If this is showing too far out for you, you need to adjust the display range scale setting. I normally fly with SkyDemon on the 500K (1:500,000) scale, which seems about right. If you set yours to a smaller scale - e.g. 250K (1:250,000) - your display will of course only cover a smaller area, with correspondingly less aircraft, but at the same time less advanced warning of any potential conflict.

The exception to the above is the display of 'Bearingless' target aircraft (which are becoming less and less as people fit modern EC devices and the coverage areas of ATOM and iGRID expand). With 'Bearingless' targets, you have to choose an appropriate 'Range' in the Bearingless targets section of PilotAware / Configure. I normally advise using the 'Medium Range' setting, unless you are happy to only get warnings (without a directional bearing) at relatively close range, when the 'Short Range' setting should be selected.

Hope this helps.

Peter