Messages

1

Technical Support / Re: “New Updates Available” message not clearing

« on: August 16, 2023, 12:13:56 pm »

Hi Martino,

I saw your message earlier, but was out in India at the time - and saw that Lee had already replied.

As this is a relatively new development, it has presumably not made its way through to the instruction manuals yet.

Standard functionality with the latest PAW software and iGRID installed, is for PAW to automatically check for updates in the background via iGRID, whenever iGRID is operating. If new software is found, this is then automatically uploaded to the PAW via iGRID and its presence announced on the PAW Updates screen (which is not immediately visible) and on the default PAW RADAR screen (as you found).

The standard procedure after noticing the 'New Updates Available' message should be to swap to the 'Updates' screen at the first available opportunity (once back on the ground) and initiate the installation of the already uploaded software from there. The 'New Updates Available' message will then disappear from the RADAR screen.

The procedure is the same for all PAWs (Classic or Rosetta) provided iGRID has been installed and is active.

Hope this helps clarify the position.

Best Regards

Peter

2

General Discussion / Re: Igrid phone

« on: August 03, 2023, 05:02:12 pm »

Hi cyclone1,

I don’t use a z fold 3, but I have been using a Samsung Galaxy S9+ very successfully ever since we first started testing the iGRID prototype software almost two years ago. It has performed consistently throughout - in fact it was originally ‘too good’, in that it was seeing too many 4G masts from altitude, so I had to reposition it so that it is partly screened from the ground. In practice, simply keeping the phone in your pocket with the hotspot turned on should give great results (my original tests involved flights of up to 2 hours at altitudes up to around 6,000 ft with consistent results.)

Hope this helps.

Best Regards

Peter
p.s. Thinking about it, I should probably consider a phone upgrade - but the S9+ still does everything I need it to do and continues to do them does well.

3

Technical Support / Re: No traffic showing on Radar display

« on: July 02, 2023, 09:25:32 am »

Point taken Paul,

But remember that historically, the PAW Config Screen filters were instigated way back in time, well before the development of the Radar Screen. At that time Lee had been asked to add filters for those using more basic display software that didn't have its own built in filtering options - hence the way it works. Filters set in Config automatically apply to all data being processed in the PAW - irrespective of where it is subsequently sent - which is why the standard recommendation is to leave them 'wide open' unless you have a specific need not to.

That then means that the only filtering that is done is your individual selection in your chosen display system - whether that be an external one such as SD, EVFR, etc or the 'pseudo external' PAW Radar Display (where the Radar Screen Vertical Setting acts as a 'traffic filter' and the Horizontal Setting acts as a 'Display Limit Zoom / Range Tool'.

Not sure how difficult (or appropriate) it would be to change the way it works unless there is a need to use the Config Range Filters to control display via RS232 yet for some reason allow the Radar Screen settings to be kept 'wide open'.

I'm sure Lee will respond in due course.

Peter

4

Technical Support / Re: PAW Classic now reports Volt=Error and works intermittently

« on: July 02, 2023, 12:14:51 am »

Hi EC,

As the designer of the Charge2 and Charge4 aviation power supplies, Jeremy is the expert when it comes to power supply issues and his advice here certainly bears out anything I would be suggesting myself.

4.8V with no dongles attached certainly sounds low to me - and 4.62V at the USB ports with the other dongles attached is clearly indicative of potential current overdraw in one or more dongles and certainly likely to trip in the Voltage warnings - though actual dropouts are obviously of greater concern than 'warnings'.

If you don't find any problem with the cigarette lighter socket supply voltage or ground resistance, I would certainly suggest swapping in a replacement juicEbitz Core Series Power Cable (with 20AWG power wire) and (if that doesn't improve the situation) another (preferably Anker) USB adapter - restricted at least initially to solely powering the PAW. If that still doesn't resolve the issue we need to ask Lee to take a look at log files from your unit(s) to see if they show any other voltage specific issues or pointers.

Best Regards

Peter

5

Technical Support / Re: No traffic showing on Radar display

« on: July 01, 2023, 11:56:05 pm »

Hi Ray,

The filters for 'Known Position' Traffic  in PAW / Configure are designed for use only with display systems such as XCSoar which don't contain their own filter set. For all other systems, these filters should be left at the default 'wide open' setting - 'Display All' - and your personal preference then set in your display software. Bearing in mind that the horizontal display limits for known position traffic are automatically controlled by the zoom level (and hence horizontal display range) set by the limits of your tablet screen, you normally only need to select an appropriate vertical range (e.g. in SkyDemon - 'Show within Vertically' in Settings/Navigation Options).

Hope this clarifies the position.

Best Regards

Peter

6

Technical Support / Re: PAW Classic now reports Volt=Error and works intermittently

« on: June 25, 2023, 07:43:22 pm »

Hi Easy Cruising,

There are still plenty of PAW Classics on the go, but they are getting a bit long in the tooth. As with any electrical equipment, the early ones in particular are liable to show the occasional issue as they get older.

Looking at your problems logically, you state that 'you don't think it can be a power issue', but also say that '...on the Home Page and Radar Screen you often get 'Voltage Errors' reporting'. Those are both clear and unequivocal evidence that there is a Power Issue with your PAW - albeit one that may be intermittent. The question we need to address is 'what is causing the problem?' It could down to a number of reasons, and might be due to more than one single fault. The first thing we need to ensure is that the power source is adequate to maintain 5 volts when a current of 2.1 Amps or more is being drawn from it. It's easy to say that the unit is rated at (say) 5 volts at 2.4 Amps and 'has always worked fine', but remember that power adapters can develop faults just the same as any other electrical equipment and that if you are using a two port adapter to power your PAW and are also powering a second device from it (such as a tablet or phone - which is NOT Recommended by PAW BTW), the second device could well be overdrawing the supply, causing the Voltage to drop. This may well have been working for years, but as your display device gets older its batteries degrade and the power requirement on the 'charger' to keep it running can get higher and can easily overdraw the supply (which usually also causes high levels of RF interference in your comms systems).

The next check has to be the power cable, which (as Jeremy has reported) can degrade through use (they are not 'infinite life' items). The connectors can also degrade over time - especially if plugged and unplugged regularly or carelessly. The MicroUSB socket at the PAW is particularly susceptible to heavy-handed connecting or disconnecting. Fortunately the Power LED, which on the Classic is visible through the perforated end plate at the opposite side to the P3i Antenna SMA Connector provides an easy 'first check' (if you don't want to invest in a power meter). This is a Red LED, which should remain ON and solid Red at all times when the unit is powered. This allows a quick rough and ready test to be carried out by gently wiggling the power cable, while observing the LED. Any blinking or failure of this LED indicates a power dropout. Look for evidence of problems at the USB-A (power supply) end, along the length of the cable itself, or with the MicroUSB plug or the power socket in the PAW. Cable faults can be fixed by replacing with a suitable high quality* USB to MicroUSB cable available from the PAW website. A faulty power socket in the PAW is a harder fix and is usually easiest fixed by replacing the Raspberry Pi motherboard (which of course gives you the opportunity to 'upgrade' to a Raspberry Pi3 with on-board WiFi -  see later).

* NOTE: High Quality means having a minimum 20AWG Power wire inside the cable and a maximum length of not more than 1 metre.

Other known causes of power issues are individual components (such as dongles) developing faults and drawing a higher than normal current. This can apply to all 3 dongles, though the 1090 SDR or WiFi dongle are the more common culprits. You state that the ADSB dongle gets very hot, which could be an indication, though as you say they often run hot, but go on to say that you get the same continual voltage error with only the Wifi dongle inserted - which could point to that being the faulty component, though not necessarily the only fault.

I would therefore suggest carrying out the above tests and let us know what (if anything) you find.

Best Regards

Peter

7

Technical Support / Re: USB output messages and iGrid

« on: June 16, 2023, 09:44:01 am »

Thanks Bob,

Hopefully that has solved the issue for @russp too.

Best Regards

Peter

8

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

9

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

10

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

11

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

12

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

13

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

14

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

15

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