Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - exfirepro

Pages: [1] 2 3 ... 165
Hi Tim,

I wasn't aware of that change myself, though I suspect it was made quite a while back.

The option to run individual PAW units as Base Stations was very useful in the early days when we needed 'actively transmitting' ground units to test airborne PAWs but that need has essentially been removed because of the ready availability of 'active' PAWs and of the custom designed ATOM Ground Station software. (but see below)

That, however, still leaves your question re 'testing your PAW without antennas' essentially unanswered.
The reason we shouldn't run transmitters without an effective antenna (or equivalent matched impedance 'dummy load') is to prevent damage to the output stage of the transmitter by the transmitted signal having nowhere to go and being reflected back into the transmitter. This is particularly important with high-power transmitters, though less so with PAW.

The significant change, however, is that PAW software has for some time now included an 'Aircraft Transmit Speed' feature (on the 'Configure Screen' just below 'Aircraft Type'). This was originally designed to prevent transmissions from essentially 'non-moving' aircraft on the ground - in order to reduce 'clutter' on displays and repeating audio alerts received by aircraft in close proximity (e.g. in the circuit). The 'Base Station' options were presumably removed at the same time, or shortly afterwards, though as I say I wasn't aware until now that this had been done.  :-[

The trigger threshold for Aircraft Transmit was originally set at a default of 10Kts* - which means that PAW wouldn't transmit when not moving, or when taxying extremely slowly, but I can't recall if this default is still current, so my advice would be to power up and go straight to the PAW/ Config Screen and check this setting. If it isn't set at 10Kts (or higher) set it to this level and your unit won't transmit unless it is moving at this speed or above. Remember to review your setting if you decide you do want your PAW to transmit when not moving (e.g. for testing) once you have connected the appropriate antenna, but please reset it to a sensible threshold before actual use.

*Remember that aircraft such as helicopters may need to set this threshold lower than 10Kts to keep PAW transmitting while in the hover.

I hope this helps clarify the situation.

Best Regards


Technical Support / Re: Corrupted track files?
« on: November 17, 2022, 02:53:06 pm »
Hi Trevor,

I did look into this a few days back when I first saw your post, but not sure what is causing it. I was hoping Lee might have responded.

For my part, I have checked the database for the date concerned and there are loads of reports from your flights (both PAW and ADSB) from a wide range of ground stations (sometimes up to 6 or 7 at a time) which is why groundstation playback replays properly, so your systems must have been working. But there definitely seems to be something missing or corrupted in your track files which is causing the track replay to show as ‘level flight’ with sudden altitude fluctuations.

I know we have seen this before during testing, where the altitude suddenly reports as much higher or lower than the actual altitude. This artificially compresses the replay track, making it look like you have been flying level except for the sudden jumps, but unfortunately I can’t recall what the cause (or solution) was. Hopefully this will prompt someone reading this and they will come on and remind me.

The only things I can suggest from what you’ve posted is to check that your GPS and PAW Bridge are both seated correctly, though either of those would have affected the groundstation reports too, so unlikely.

Let me know if you find anything. In the meantime I’ll keep racking my brain to see if I can recollect what the earlier problem (and solution) was.

Best Regards


Technical Support / Re: Help Connecting to Dynon skyview
« on: November 14, 2022, 05:54:10 pm »
Hi again Paul / Bob,

If you are using two FTDI USB to RS232 adaptors (which unless I haven't been told of changes you still need to do - i.e. separate ones for data in and data out - as the PAW ports still can't be configured to do both at the same time), then the 'Data Out one needs to use the FTDI Orange and Black wires, and the Data In (whether Flarm or GPS) needs to use the FDTI Yellow and Black wires.

I am not aware of any specific technical problem arising from both 'Data In' and 'Data Out' wiring being connected at the same time, on the same cable, though I have never actually done this myself in any of the installations (mainly Flarm In or Data Out to various Transponders) I have done personally - mainly because of the fact that AFAIK it doesn't achieve anything worthwhile, other than potentially 'future-proofing the installation as you say Bob!

Best Regards


Technical Support / Re: Aircrew Instrument Firmware Update
« on: November 07, 2022, 10:50:43 am »
Hi Bob,

Thanks for the update. Good to know you have now got things running properly by powering your Aircrew from your aircraft 12 volt supply (suitably switched and fused I trust).

The Raspberry Pi's used in PAW (Classic or Rosetta) are both generally fine with their designed power draws (including USB to RS232 converters and the 'extra' WiFi for iGRID, as these have all been tested in development. As we have discussed before, adding any additional loads can be asking for trouble (especially if anything goes wrong - such as an SDR or GPS developing a fault).

Remember that when James compiled the Aircrew Manual, he would have been working with a 'bare' PAW without USB to RS232 or iGRID, so it would be perfectly capable 'power wise' of supporting the Aircrew in that state. In a similar vein, that's why we always recommend powering PAW from its own dedicated supply - i.e. not 'sharing' a 2-port USB adaptor - especially with a power-hungry 'flat' tablet or phone. As you are of course now aware, connecting the Aircrew to the PAW by USB (rather than WiFi) also prevents display of aircraft Reg ID as I reported previously, so swapping it to an external supply with WiFi connection to your PAW automatically resolves that issue.

Good result!

Best Regards


Technical Support / Re: Maximum range on Vector for PAW vs ADS-B
« on: October 28, 2022, 06:05:24 am »

Just picking up on one of your comments:

"Also be aware that the list of traffic shown at the bottom of the Traffic Screen (with ‘C xxxx codes’) is ‘under investigation’ as part of the ‘Mode-C’ identification process and usually proves to be one of the aircraft positively identified further up the chart rather than a ‘Pure Mode-C’ signal - after which the ‘Cxxxx’ entry is automatically filtered out."[/i][/i]

With reference to the new attachment here, we have sometimes seen a contact pop up seeming to indicate it is exactly in our position, (although it often quickly disappears), but it has the 'Cxxxx' designator you mention above. We are not sure what this means. Is this 'co-location' where the Mode C contacts you mention are automatically shown until they are filtered out?  These sort of contacts get the heart rate going and we're not sure whether we should be concerned or not!

Hi David,

In view of the importance of this question, I have split it from this thread and started it as a separate topic 'Mode C Reporting' to make the question - and my answer - easier for other users to find in the future. Hope you don't mind.

Best Regards


Technical Support / Re: Mode C Reporting
« on: October 27, 2022, 06:43:39 pm »
Hi again David,

This is a very complicated subject, but I will endeavour to explain it in as simple terms as possible.

Mode C transmissions should be 'altitude' responses from a 'Pure' Mode C or from a Mode S transponder - but can in some circumstances also be 'ID Squawk' responses from either of the above. Due to limitations in what is in fact a relatively old and technically very complicated system, transponders sometimes use the same response 'code' to report a 'Squawk' of for example 7000 or an altitude of 7000 ft. There are numerous similar code 'duplications'. The interrogating Radar, of course, knows which type of response it is 'expecting' from the transponder, based on the interrogation it has sent out, and advises the radar operator accordingly, but we (unfortunately) don't have the benefit of this 'interrogation' information - which is sent out on a completely different frequency (1030MHz). Mode C responses are therefore extremely difficult to 'pin down' - unless they include an ICAO Hex Identifier which ties them to a specific Mode S transponder - though these identifiers aren't even present in every Mode S response packet - and they simply don't exist in the older 'Pure Mode C' transponders.

In order to be able to report the presence of 'Pure Mode C' aircraft therefore, PilotAware has to assess each individual 'potential Mode C' response it receives and try to work out whether it is from a 'known' Mode S or ADSB aircraft (including an 'altitude' response from your own Mode S), from the aircraft's 'own' Mode C transponder (if you are running one of those), or from a separate genuine Mode C 'target' aircraft, and then work out what level of 'risk' the target poses to your aircraft and report this accordingly.

In order to do this, the system has to monitor all potential Mode C responses over a fairly brief period of time and look for common or varying factors (if a series of received packets aren't varying (except in signal strength), they are almost certain to be an ID squawk) and then try to match and group each individual response to an aircraft, then eliminate it as being from your 'own transponder' or report it to your EFB as 'traffic'. This process is going on constantly and at high speed, with the results reported in the lower part of the PilotAware 'Traffic Screen' - primarily for system monitoring purposes - with system generated 'C' codes allocated to each data packet to allow them to be tracked and compared through the process. These codes are then used to report 'genuine' Mode C targets to your EFB as 'Traffic' and to generate associated Audio Warnings direct from your PilotAware.

In your screenshot, PAW has obviously assessed received reports and identified a Mode C transponder which it is reporting as 'High Risk' or 'Danger' (identified by the Red Circle). This means that it is likely to be within a relatively short horizontal distance from your aircraft (the actual distance will depend on the power of the transponder and your selected Bearingless Target Reporting 'Range' in PAW Configure). Note that we DON'T try to work out an actual distance as this can't be done accurately and - depending on your selected Bearingless Traffic Range Setting and the output power of the transponder, the aircraft may, or may not be inside the circle and is extremely unlikely to be concentric with your own aircraft - at least at the point where the warning first appears. The circle is purely indicative of the degree of perceived risk (see below*) and denotes the importance of trying to identify the aircraft position visually - especially if it is at or near your own level, or is climbing or descending towards your level. PilotAware has however been able to determine the actual altitude of the aircraft from the received data packets - which it is reporting in this case as 3,300 ft below your current level (-3.3). Note: if the reported aircraft is near your own level and the risk level is increasing, you need to try to locate the aircraft visually as a priority, or be prepared to initiate measures to increase separation (e.g by climbing or descending as appropriate, or turning away from your present course while keeping a very careful lookout for the reported aircraft), especially if the relative altitude continues to close. Be aware that PilotAware NEVER reports aircraft that don't exist (but see also below re high power transponders)*

* Any avoiding action will of course depend on your location and circumstances and must be decided on and implemented by the pilot after interpreting what the system is reporting and all other relevant issues - including the proximity of controlled airspace. NEVER 'knee-jerk' react to a PilotAware warning without considering ALL relevant factors. It is important to 'Learn' in advance what your display (and associated audible warnings) are telling you and think ahead as to what you could do in each of the various situations you might come across. In making your decision, you should also be aware that a high power transponder (such as a CAT Mode S), may report straight to 'Danger' or extremely quickly through the Notice / Alert / Danger stages (Progressively smaller Green then Amber then Red Circles) when the transponding aircraft may still be outside your visual range. This often occurs in the vicinity of major airports and the specific warning pattern or 'signature' once experienced is relatively easy to recognise. This is specifically why the use of Bearingless Target Reporting - whilst it is an extremely useful tool due to the high percentage of 'Pure' Mode C or Mode S equipped aircraft around - is usually not recommended until you have 'learned' how to use and recognise what it is telling you. If you aren't sure about this please read the information available on the website at - and if you are still not sure, please come back on here and ask!

In closing, a huge amount has been done over the past year or two to improve the accuracy and reliability of both Mode S and Mode C detection and reporting, so it goes without saying that users should always avail themselves of the most recent PilotAware software updates as soon as practicable after they are released. Recent developments - including the availability of the PilotAware Firmware Updater APP for both Apple and Android devices makes this a 'no brainer' and developments are even in hand (currently being tested in Beta) to introduce automatic downloading of latest updates in the background via iGRID  - where installed (though you do still need to manually prompt the actual install once notified of the availability of the update).

I hope this helps clarify the situation.

Best Regards


Technical Support / Re: Just updated - Radar screen not working
« on: October 24, 2022, 10:05:25 am »
Hi James,

Be aware that most of the recent software versions require a complete fresh install. IIRC you can only 'update' to the latest (20220805) if you are already running the last-but-one (20220531).

I've just been trying the Track Replay Function for myself to check its functionality - as I said above it's been a considerable time since I've used it. Like you, I also used one of the Demo Tracks, as most of the other tracks on this unit (my testing and development 'spare') are based on a fixed position at my home.

Track Replay still seems to work as it was designed to - i.e. sending data to SkyDemon - but we always had two issues. Firstly, the replay traffic always shows as 'Flarm' (possibly a legacy of when we developed direct Flarm Traffic Integration Lee?) and is always 'greyed out', but it still shows on SkyDemon (with my PAW and SD filters set wide open). Secondly, unless we completely remove all 'live' traffic inputs (antennas and SDRs) we get a 'mix' of replayed and 'live' traffic - such as I am seeing right now, with my ATOM Station and one fairly distant CAT showing live (but the CAT outside your previous 20Km filter range). Finally, the replayed traffic mixes with any received live traffic to create a new (corrupted) track file which is a composite of the combined historical traffic from the replay and any received live traffic.  :-\

Having said that, is it critical for the test traffic to be within your chosen 7Km range? I am just outside that range from Edinburgh Airport, but could probably pop down and grab some traffic with my unit and send you the track file if that would help.

Best Regards


Technical Support / Re: Just updated - Radar screen not working
« on: October 24, 2022, 08:20:57 am »
Actually something strange is going on
Many of the contacts are described as flarm, which does not sound correct
Please describe your entire setup in detail



That’s because James is using track replay as his traffic source.


Technical Support / Re: Just updated - Radar screen not working
« on: October 23, 2022, 11:03:16 pm »
Hi jcross,

Looking back at your previous posts, it looks like it’s been quite a while since you have been on here. If so, welcome back.

If you are trying to test the Radar Display, I would strongly advise powering the unit up outside, and waiting for live traffic, rather than trying to test from previous track files.

Things have moved on massively with PAW since you last posted. Although track replay buttons are still included on the Tracks Screen, we don’t do track replays on PAW these days. It’s been so long since I tried this facility in fact that I can’t even say if it still works. Quite frankly, I’d be surprised. Edit: it does, but with limitations as described in my later post below. As you can see, all the traffic on your traffic screen is as you say greyed out, which means it won’t be displayed on the traffic screen or sent to your EFB and most of the replayed traffic is reporting as FLARM - which will certainly confuse the software.

Track Files can be replayed far more effectively nowadays using the online Aircrew replay tools - see and so the ‘in-unit’ PAW Track Replay tools have effectively fallen into disuse.

While on the subject, I notice that you have ‘Positional Contacts Settings’ filters set in Configure for Horizontal and Vertical Display Ranges. These settings will limit your display and should only be set when the PAW is being used with an EFB which doesn’t have its own vertical and horizontal filters. For commonly used EFBs like SkyDemon or EasyVFR, we recommend that the PAW filters are left at the default ‘Display All’ setting, with Vertical Range set in your EFB where required. Horizontal range (for known position moving aircraft - which includes ADSB, Mode-S/3D and FLARM/OGN Uplinks) is automatically limited by your display screen range limits.

The RADAR Screen (as you can see) has its own horizontal and vertical range settings.

Hope this helps

Best Regards


Technical Support / Re: Vector display
« on: October 23, 2022, 10:01:11 am »
Hi Smaragd,

That is certainly the 'obvious' conclusion from what has been reported, though as Alan has been using Vector for some time I had ruled that out as unlikely - at least until I had done some more extensive tests.

I also received the following by email yesterday from another 'Non-PilotAware' Trig and PowerFlarm user who advised...

I have adsb out via a trig and power Flarm with no PAW fitted.

Hex code 40xxxx

Perhaps you can use mine as a comparison. I am definitely showing more Flarm hits, 41,000 as opposed to adsb 8,000 hits over five days.

I have just run checks on both the Database and Vector for this second aircraft, with the same end result - Lots of Flarm and ADSB Data (as expected), but again NO PilotAware data (as no PilotAware fitted to the aircraft).

I attach the (again anonymised) Vector reports from this second aircraft for comparison (I didn't post the combined one but the result was the same).

Bearing in mind that the principal purpose of Vector is not to report long range transmission, but to help identify obvious gaps in the aircrafts' transmission pattern due to obscuration or poor antenna placement, the fact that Vector has reported a higher level of Flarm contacts is not unusual. This is primarily due to two factors - firstly, the Flarm receivers on the ATOM Stations are using higher gain antennas, and usually more sensitive receivers than the ADSB side and secondly, to avoid swamping our server drives with ADSB data from high power transmissions, we have set a range limit for ADSB reporting at a maximum of 60Km - while Flarm data continues to be received (and stored and reported) from greater range where this is the case - as demonstrated by the coverage charts.


Although I can't completely rule out any possibility that there may have been a 'glitch' in the system when you tried to carry out your recent Vector analysis, I hope you can now accept my explanations as to why in my opinion Vector couldn't have reported that you were receiving PilotAware reports via your PowerFLARM Fusion (even if for some reason you were - see below) and that Vector is working as intended.

I am of course aware that due to ongoing developments, the OGN Network can now receive and display PilotAware Equipped Aircraft - as can Stratux Flarm (Europe Edition) - due to upgrades to their receiver software. The Flarm side of our ATOM software also incorporates the same provision (though we had to disable the PilotAware Reporting function from the OGN side of ATOM as it was misreporting the ATOM transmitters as aircraft). Under our agreement with the OGN we send all our Flarm / OGN data on to the OGN servers to supplement their own receivers, though we don't use OGN data from the OGN Network for our rebroadcasts as we use the data directly received by our own ATOM Stations. OGN data is however used by other systems such as the 'SafeSky' App to advise their users of the presence of Flarm, OGN Tracker, Fanet and PilotAware aircraft - so this is a potential source of PilotAware aircraft positions, which is why I asked if anyone in the plane might have been running SafeSky. Edit: Sorry, just realised I hadn't asked you this - I must have got mixed up with another thread :-[. It is of course possible that Flarm have developed their software to add PilotAware (or SafeSky) reception, though I am not aware of this. If you send me your Flarm ID, (assuming it is different from your ICAO Hex) I can also check for that on our database and if you have any screenshots or other evidence to show that Vector (or your Flarm Tool) is reporting you receiving PilotAware via your PowerFLARM Fusion, I would be very interested in seeing them.

Best Regards

Technical Support / Re: Vector display
« on: October 22, 2022, 03:27:31 pm »
Hi again Alan,

No suggestion here of any axe grinding I assure you, but I am still confused.

I have just checked the online Vector Tool (again!) and it is working exactly as intended.

You state that...
As you can see from the Hex number I sent to you it [Vector] shows the exactly same number of contacts for ADSB as Flarm which just can't possibly be correct regardless of the input type selected into the box.

No I can't.... - because it doesn't. It clearly shows different numbers of contacts from your Flarm and ADSB transmissions.

I have attached anonymised screenshots of the transmission patterns from your aircraft from the combined flights on 29th September, 10th & 18th October. The first screenshot shows the combined ADSB and Flarm transmissions, with the next two showing separate individual reports of Flarm and ADSB transmissions, from which you can clearly see that the number of contacts is only the same in the first screenshot, because it is reporting the combined total of ADSB and FLARM transmissions for the 3 days (in this case with Transmission 'Type' set to 'All'). The other two screenshots clearly show different numbers of contacts.

You also say...
It also now shows Pilotaware contacts and I don't have Pilotaware! This is all something that has happened to Vector recently.
There is I think something that has been changed in Vector recently and the thought is just maybe it posssibly now it isn't working correctly for Pilotaware users either?

Previously reported as...

Vector display shows that I can now see Pilotaware aircraft even though i don't have Pilotaware and my Powerflarmfusion is picking up these aircraft contacts?

Again, this is simply not the case.

I have already explained that for PilotAware equipped aircraft, Vector can gather reception data from individual PilotAware Units, via iGRID (if the PilotAware is iGRID equipped and connected), but that this is still in Beta development - and for Non-PilotAware systems, Vector can only report transmissions from the aircraft as received by the ATOM-GRID Network - so in your case (being Non-PilotAware) it can ONLY report on your ADSB or Flarm Transmissions as received by the ATOM-GRID Network.

Finally, remember that you are accessing Vector online on the PilotAware Server, so if it doesn't work properly for you, it would be the same for everyone else who tries to use it - and it clearly isn't!

I am therefore at a complete loss to see what you are reporting. As far as I can see, Vector is working just the way it was designed to.

Best Regards


Technical Support / Re: Vector display
« on: October 20, 2022, 03:55:44 pm »
Hi again Alan,

OK, definitely something strange going on, because when I looked at your range reports yesterday (via the same link you are presumably using - on the website at ) Vector was behaving exactly as I expected it to, and showing a significantly higher number of FLARM contacts than ADSB ones for the last 3 days flights (which is what I would expect). Remember number of contacts in this respect is the number of data packets received, not the number of aircraft.

(I also have an admin log in which gives me much wider access to the network and database, which is how I could check your older flight reports, but deliberately didn’t use that route to check your coverage so we would both be working from the same source.)

We need to investigate this further - I’ll have a think about what might be going on and get back to you.

Best Regards


Technical Support / Re: Maximum range on Vector for PAW vs ADS-B
« on: October 20, 2022, 02:22:37 pm »
Hi again David,

All of the ADSB Traffic received by PilotAware is passed to your EFB unless you have deliberately restricted this in the’Horizontal Display Range’ and ‘Vertical Display Range’ settings in PilotAware / Configure / Positional Contacts Settings. We recommend that these are both left at the default ‘Display All’ and that you only set a vertical reporting restriction in your EFB (e.g. +/- 1000ft or whatever you are comfortable with). You don’t need to set a horizontal visual reporting range filter as this is limited automatically by the screen zoom level. There is a separate set of filters for controlling the reporting of ‘Bearingless’ Mode-S’ and ‘Mode-C’ Traffic if you have Bearingless Traffic Reporting Enabled in PilotAware and in your EFB (it’s off in both by default). MLAT (triangulated) Mode-S positions are displayed in the same manner as other ‘known-position’ traffic provided you have Mode-S/3D enabled in PilotAware.

If you want to check traffic received by PAW, you would need to compare the ‘PAW Traffic Screen’ against something like FlightRadar24 or one of the other public reporting sites, but be aware that these sites don’t always report traffic accurately. PilotAware reports all traffic unless you have the PilotAware Traffic Filters set other than default (when filtered traffic will show as greyed out on the Traffic Screen). Also be aware that the list of traffic shown at the bottom of the Traffic Screen (with ‘C xxxx codes’) is ‘under investigation’ as part of the ‘Mode-C’ identification process and usually proves to be one of the aircraft positively identified further up the chart rather than a ‘Pure Mode-C’ signal - after which the ‘Cxxxx’ entry is automatically filtered out.

In practice, if you are seeing 1090 traffic on screen, that part of PilotAware is working properly and to its full potential (assuming you have Bearingless and Mode-S/3D enabled and the filters sufficiently wide open). It either works very well (99.999%+ of the time), or not at all - in which case we need to look at the 1090 antenna, cable or the SDR.

Hope this helps



Technical Support / Re: Vector display
« on: October 19, 2022, 11:45:36 am »
Hi Alan,

Thanks for the Hex Code.

There are lots of ADSB reports from your aircraft on the Database from our Ground Station Network, going back to February 2021, and for Flarm from March 2021, all with pretty good range reports. Bear in mind, however, that the reports you see on Vector are compiled from a maximum of the past 30 days flights. In your case your 'current' reports are in fact compiled from only 3 Days - namely 23rd September, and 10th & 18th October  - as shown by the calendar dropdown at top right of the Vector Screen, and will vary depending on the number of days, number of flights, number of Ground Stations you have flown within range of and the distance and bearing from each at which your transmissions were received by each Ground Station during the reporting period.

Unfortunately as I explained above, Vector is unable to report on signals actually received by your PowerFlarm Fusion as this type of data is currently ONLY reported back to our network by iGRID equipped PilotAwares.

I hope this clarifies the situation.

Best Regards


Technical Support / Re: Maximum range on Vector for PAW vs ADS-B
« on: October 19, 2022, 10:20:23 am »
Hi David,

As Paul has so eloquently explained, the ADSB transmission display is 'restricted' to a maximum range of 60Km to limit the amount of data we have to hold in the database to produce the diagrams. (This is also why we no longer report on Mode S transmissions as that was even more data hungry.)

Having looked at your Vector reports, I'd have no worries whatsoever about your transmission coverage on P3i or ADSB. Both are excellent examples of what can be achieved by the use of properly mounted external antennas. Well done!

Best Regards


Pages: [1] 2 3 ... 165