Messages

1

General Discussion / Re: Strange Pilotaware tracking outside the UK

« on: August 23, 2025, 12:05:16 pm »

There doesn’t seem much knowledge of or interest in this topic but rather than leave it open I might as well briefly describe my conclusions after some investigation.

Classic OGN groundstations throughout Europe do indeed receive PAW transmissions, and forward them to the OGN servers. The data forwarded is labelled in a way that distinguishes it from the same data received and forwarded by PAW groundstations (which are almost exclusively in the UK).

The OGN servers supply data from both sources (and several others) to clients such as the various public tracking websites . Whether traffic from any particular source is displayed depends on the client and it so happens that my favourite GlideAndSeek tracker, which I was using when my friend “disappeared” mid-channel, does NOT show PAW aircraft received by OGN groundstations. I don’t know if this is intentional, and I have tried to contact the site’s owner, but with no response. Other trackers, such as SpotTheGliders and PureTracker DO show this traffic.

Regarding the odd 2 minute spots on the PAW groundstation tracker site, I’m sure Admin could have explained this straight away, but this must result from PAW taking data from the OGN servers for their own purposes and choosing to store only 2 minute samples.  Presumably this is just for statistical info on where PAW is actually used which is fair enough provided they comply with the OGN privacy policy on data use.

2

General Discussion / Re: Strange Pilotaware tracking outside the UK

« on: July 09, 2025, 09:10:33 am »

Thanks for the background info but note my friend had no Igrid connection so I'm none the wiser how this flight was tracked and why the datapoints are 2 minutes apart. The ID was 405BE9 departing Thursday 3rd July at 9:06Z.

As far as you know, do classic OGN sites outside the UK receive PAW?

Alan

3

General Discussion / Strange Pilotaware tracking outside the UK

« on: July 08, 2025, 11:26:19 pm »

Warning: geeky! I noticed something very odd at the weekend and wonder if anyone can explain it.

I was using www.glideandseek.com to monitor a friend’s flight from the south of the UK to Le Mans (France). GlideandSeek displays data from the Open Glider Network, to which PAW groundstations contribute data, making PAW users visible in addition to the FLARM users. My friend has a PAW Classsic without airborne internet connectivity.

He was tracked perfectly to about mid-channel and then disappeared. I believe there are very few PAW groundstations outside the UK so at first sight this might be expected but I understand that “normal” OGN stations without the PAW hardware added (the vast majority of those outside the UK) should also receive PAW as well as their native FLARM using their SDR dongles. A bit of research however showed that this OGN receiver functionality reportedly does not currently work. So the loss of tracking outside the UK still made some sense.

Now (finally!) here’s the interesting bit. I later checked the flight in the PAW database using the PAW Groundstation replay facility which I think is now quite well known. At first sight the same happened:  perfect tracking but only to mid-channel. However looking more carefully, there are individual track points logged every 2 minutes all the way to the destination. You have to look very carefully to spot the individual red dots.

I can’t figure out how this is happening. I don’t believe there is PAW groundstation coverage all along this route and if there was then surely there would be a normal complete track.  I also don’t believe there can be any air to air relaying going on and there is no internet connectivity. The only other option is that the OGN stations are in fact receiving PAW equipped aircaft and PAW are importing this data back into their own system which I didn't think they did. But in that case why would GlideAndSeek not display this same intermittent data, and why is it intermittent?

Hope this isn’t too garbled. Can anyone shed any light on what’s happening please?

Alan

4

Technical Support / Re: ICAO HEX Code, not Callsign

« on: May 23, 2025, 12:51:57 pm »

Isn't this you?
Alan

5

Technical Support / Re: ICAO HEX Code, not Callsign

« on: May 23, 2025, 10:19:43 am »

Timothy, my apologies for wasting your time. I have the older PAW unit which records the track (and other data including received traffic information) internally. I didn't realise (and it's disappointing) that the new model no longer has that facility. Steve, if you look back you'll see that the ground based track logs won't help here.

Alan

6

Technical Support / Re: ICAO HEX Code, not Callsign

« on: May 19, 2025, 07:28:45 pm »

Timothy,

Sorry, I know you're techie but I obviously presumed too much PAW specifics. PAW maintains a text based "track" file for each flight containing useful information about, well, your track but also the traffic information sent to your downstream device, and other internal status information. Unfortunatey the format is not public but it's mostly obvious, although some records need a bit of "interpretation". You can download the file from the PAW to your tablet/phone but it sounds like this would need to await your next visit to the aircraft.

Hopefully you have used the PAW web interface on 192.168.1.1? one of the many items is (from memory!) TRACKS, displaying a date and time ordered list of files. Hit "Download" to copy any of them interest to your device. I'm not an Apple user so I'll need to leave you to figure out where they get stored and how to email them to yourself.

One official use of the files is via the flight replay app:

https://playback.pilotaware.com/playback/

Upload the track file and you can then drag the little white circle in the lower part of the display to replay your flight. You will see your own aircraft and also all the traffic that was reported during the flight. Hover or click on the traffic to see it's identity. If you can recall a situation of interest (and your posted screenshots would be examples) it would be interesting to see if the ID displayed corresponds.

Alternatively, and perhaps more interestingly if you're that way inclined, viewing the track file in a text editor will show the detail of what was sent to your device. Admin previously described the $PFLAA messages that convey traffic information, and the differing formats with and without callsign. I expect that this will simply confirm that PAW is at times just omitting the callsign but who knows? There may be some pattern or other clue.

About 5 seconds or so prior to the first $PFLAA message for a particular aircraft you should see a lengthy $PALOG message containing the it's hex code and which appears to convey (not very obviously) the source of the traffic. I assume this message indicates the first receipt of information about that aircraft (and BTW why the 5 second delay in informing the downstream device)? I wonder if this message might reveal anything.

Might be easiest just to send me the file? I'm not saying any of this will help, so don't go out of your way to retrieve it, but sometimes an indirect route leads to useful clues and as you say things have ground to a halt otherwise.

Alan (no connection to PAW, just a mis-spent youth).

PS should just add that I have a PAW Classic, not an FX but I hope and believe that the track logging functionality has not changed.

7

Technical Support / Re: ICAO HEX Code, not Callsign

« on: May 19, 2025, 11:11:09 am »

Would it be helpful to download the PAW track file and see what is displayed using the PAW track replay utility, but also have a look with a text editor? If nothing else it will check that the erratic data is indeed being emitted by PAW but you never know what other clues may show up. You can also get some insight into the ultimate source of the data although this needs a bit of imagination as the log format is not documented. The joys of a closed system! Search for the ICAO code obviously. It seems that the source log entry $PAWRT is only written on first contact but you might, for example, see multiple entries if it is flipping between ADSB/PAW as the source perhaps. PM me the file if you like.

Alan

8

Technical Support / Re: New Raspbery Pi 3B+ does not boot

« on: January 18, 2025, 01:11:19 pm »

It's only been ground tested in conjunction with a SoftRF device but seems fine. It's only the boot process that's different after all.

I have also checked on a Pi 2B and that is OK too as far as I can tell - the licence doesn't work obviously.

But yes - please check it out!

Alan

9

Technical Support / Re: New Raspbery Pi 3B+ does not boot

« on: January 16, 2025, 04:37:57 pm »

Hi Ashley, many thanks for that. I was at a loose end today so investigated a bit further and it seems it is quite easily fixed with basic IT skills. I was on the right track yesterday, but the reason the standard fix didn’t work is that PAW uses the old NOOBS installer which I wasn't familiar with and which doesn’t directly load the operating system. This means you need to replace the old firmware files in 2 different places. In case it’s of interest to anybody else, this is what I did :

Get a copy of a recent Raspbery Pi distribution – I used Bookworm 32 bit. You will need 9 files from the distro root: bootcode.bin, start*.elf (4 files)  and fixup*.dat (4 files). Ignore the ones with "4" in the filename - these are for Pi model 4.

Take the SD card from a working PAW installation and mount it on a Windows PC (other OS's are available but don't ask me!) using an adapter. You should see 2 volumes: BOOT and RECOVERY

1) In the BOOT volume root, you will see the old versions of the above 9 files. Overwrite them with the new ones.

The additional steps, that I was missing yesterday are:

2) In the RECOVERY volume root, overwrite bootcode.bin with the new version.
3) In the RECOVERY volume root, delete recovery.elf, copy in the new start.elf and rename it recovery.elf.

That’s it! If you are starting with a brand new PAW card that has not yet been run, and you don’t have an old version Pi in which you can do so in order to set everything up, then it’s a bit more fiddly but you get the idea.

I think Lee could probably update the official image quite easily to reflect this.

Kind regards, Alan

10

Technical Support / Re: New Raspbery Pi 3B+ does not boot

« on: January 15, 2025, 06:14:47 pm »

Hi Peter,

Yes that was the version that I tried. Like you, I have been using a Pi3B+ for some time but it recently packed up and needs replacing. The problem is that the Pi3B+ that you can buy today (Version 1.4) is not quite the same. The power management chip has changed and needs different code. They have kept this rather quiet but it is all taken care of if you use a modern version of the OS. I suspect the PAW OS version, which seems to date from 2018, doesn’t have that. Here is a thread from the Raspi forum which exactly describes the issue:

https://forums.raspberrypi.com/viewtopic.php?p=2147085&hilit=3b+version#p2147085

In brief:

1) The Stretch operating system (used by PAW I believe) does NOT support the new Pi 3B+ version out-of-the-box.

2) Overwriting 8 or 9 files in the boot partition with the ones from a newer OS version DOES fix the problem on a standard Stretch system, and for many people this is the answer.

3) There are others, especially those using a closed image such as is the case with PAW, for whom this does NOT fix the problem. The implication is that there is something else apart from the bootloader that needs fixing. Unfortunately nobody seems able to answer this although it has arisen on multiple Raspi forum threads.

I'm  hoping the PAW people will be able to shed some light.

Alan

11

Technical Support / New Raspbery Pi 3B+ does not boot

« on: January 15, 2025, 02:13:08 pm »

I need to replace a dud Raspberry Pi 3B+ in my PAW classic but the new one does not boot. It continuously gives 4 long and 7 short flashes on the green LED (on the PI itself).  After much digging it seems this usually happens due to a change in the Pi 3B+ hardware about 3 years ago. The power management chip was changed and unless the boot firmware on the SD card is updated, this new device is not recognised and it thinks there is a power supply fault, giving the LED flash pattern I described. Given the apparent age of the PAW files this sounds likely to be the case.

The official fix is simply to replace 8 boot files (startup*.elf and fixup*.dat) in the boot partition with ones from a more recent version of the OS but this doesn’t seem to work with the PAW setup. What I have tried:

Created a standard Raspberry Pi OS card (Bookworm 32 bit) works fine, suggests the Pi3B+ is OK.
Created a new Pilotaware card from scratch with the latest issue, doesn’t work on 3B+, OK on 2B.
Copied the 8 updated boot files to the PAW boot sector, no change (still works on 2B, not 3B+).

I don’t know exactly how the PAW boots but I wonder if it is not using the new files that I copied over. Does it perhaps use files from the recovery partition instead and if so what files should I replace there?

Before I spend a load more time, I wondered if anyone has got PAW running on a recently purchased Pi 3B+ and obviously would appreciate any comment from PAW?

12

Technical Support / Re: Android firmware updater not on Play Store?

« on: November 13, 2024, 10:31:50 am »

I hate to nag, but I'm puzzled why this simple question remains unanswered. "Admin" is clearly active on the forum and must surely know the answer? I imagine the majority of PAW users are on Android, are they forever doomed to USB updating?

Alan

13

Technical Support / Re: Android firmware updater not on Play Store?

« on: October 25, 2024, 12:13:11 pm »

Any news on this? In the meantime I've updated via USB stick but it's a relative faff.
Alan

14

Technical Support / Android firmware updater not on Play Store?

« on: October 17, 2024, 10:22:02 pm »

I can't find the Android firmware updater app on Play Store, am I being dim?
Alan

15

General Discussion / Rosetta FX

« on: January 05, 2024, 01:54:21 pm »

Mid-December has come and gone! Is there any news on Rosetta FX launch and availability?
Alan