Messages

1

Technical Support / Re: Connecting Funke transponer to pilotaware

« on: September 01, 2019, 10:54:03 am »

Your engineer should check if the Funke transponder is set up for NMEA input (described in the Funke manual), and that the PAW is hard configured to send 4800 baud on the serial link (default is auto-baud, this will not work)

2

General Discussion / Re: Support for classic systems?

« on: September 01, 2019, 10:46:53 am »

The email was sent while I was on vacation. I'm planning to renew at a later time, perhaps after the winter. Does a renewal start at the date of payment, or at the date of expiry of the last license?

I'm still very much in favour of a perpetual license. All equipment in my plane keeps on working, although for some the manufacturer is no longer in business. All except for PAW.

3

General Discussion / Re: GPS Splitter

« on: February 09, 2019, 10:30:56 pm »

I am thinking RS232 wire to a USB adapter (makes a change from the other way round) to 'feed' my PAW with GPS position information

This is possible, and essentially what I did.

..and, possibly, an RS232 wire to SMA adapter to 'feed' the same position to my Funke BFI57 'back up' instrument (I haven't seen if this adapter is a real thing yet). Any snags with this please feel free to shout out 

SHOUT!! That's not going to work. The SMA connector isn't a serial input, it is an RF antenna input. The BFI has its own integral GPS receiver (pretty much like the SP12) and really needs its own dedicated GPS antenna. As it is your backup device, it would be best to reserve a spot for that antenna and not try to mix it with any other GPS RF side. You'd re-introduce a single point of failure, which means you risk losing the primary and backup at the same time.

Now, going a bit techie, does anyone know what baud rate would be acceptable to the PAW box, assuming it was being fed the GPS position as described above? The SP12 usually uses 115200 as the default and, I believe, this allows SDA 2, SIL 3. The baud rates of the SP12 can be changed and, obviously, this would not affect the PAW as it doesn't need those 'certified' numbers but I have no idea if going to a different baud rate reduces the SDA 2, SIL 3 of the SP12. I think I'm talking Greek at the moment 

As Lee already replied, PAW will work fine with 115200 Baud. Some other devices (notably RS-232 connected ELT's and transponders) require 4800 Baud or 9600 Baud. As the documentation of the SP12 shows, this will reduce the number of position messages per second. The simple reason is that at 4800 Baud you can only transmit approx 480 characters per second. If you add the length of all NMEA sentences ($GPGGA, $GPRMB etc) you simply can't fit two full sets of position data in 480 characters. At 19200 Baud you are already up to almost 2000 characters per second so you can have four full position sets in a second, enough to allow SIL=3. At 115200 there's plenty of room to transmit position from the SP12 to the attached devices several times per second.

So unless you must feed RS-232 at 4800 baud to some other device, leave the SP12 at default 115200. Better yet, if you have something else that wants 4800 or 9600 Baud, you might be able to feed that from your BFI57 which also supports NMEA out.

4

Technical Support / Re: Avmap EKP IV

« on: February 08, 2019, 09:19:15 pm »

Whoops... Just noticed you wrote EKP IV. Pretty sure it won't work with Flarm or PilotAware

5

Technical Support / Re: Avmap EKP IV

« on: February 08, 2019, 09:16:28 pm »

I had an EKP V for a while and tried to make it work. No luck back then, but AvMAP at the time claimed they were working on Flarm compatibility. You may want to check their website if your firmware supports Flarm yet. If so, you should be able to use NMEA Out from PilotAware and send it to your EKP V.

6

General Discussion / Re: GPS Splitter

« on: February 04, 2019, 01:11:32 pm »

I would think that as soon as you mess with the SP12 on the RF side, it looses its certified status and its rights to transmit SIL=3.

From the installation manual:
"GPS antennas supplied with the SP-12 by MGL Avionics are the only approved GPS antennas to be used with the SP-12. Other antennas may work but may invalidate the SP-12's GPS approval for use as a GPS source for ADS-B purposes."

You might consider splitting the SP12 NMEA serial output. I had the same GPS sprawl until I found out that my AvMAP UltraEFIS supports NMEA Out. I've fed that into a USB-Serial line and into PAW. That eliminated the PAW dedicated GPS and works very well.

7

Technical Support / Re: Changing Host-ID MAC address to aircraft registration

« on: February 01, 2019, 09:12:42 pm »

There's already a field for specifying your own HEX code. I'd think it would be a relatively small change to have a second field to input the WiFi SSID you'd want to use? That could even be useful as an 'own ID' filter as that information is available in Extended Squitter data

I would love to have mine reflect the aircraft registration as well, as it is a fixed installation. Perhaps prepend "paw_" to make clear that it is a PilotAware unit.

8

General Discussion / Re: Raspberry Pi3B

« on: October 13, 2018, 12:19:26 pm »

I fell into the B+ trap. Luckily there are many builder communities where people have the B and will be happy to trade-up for a B+.
My problem lasted less than a day.

9

Technical Support / Own position without GPS fix

« on: September 14, 2018, 07:37:46 pm »

Just a thought.. Assuming that those interested in PilotAware are a bit tech savvy, I would think many are feeding a GPS signal into their transponder so they too are transmitting their position through ADS-B Extended Squitter. That may well be an independed GPS signal of much higher quality than the dongle/rosetta can provide.

If this is the case, then I'd think PilotAware can use the plane's own ADS-B signal to establish position, even if the GPS dongle fails to provide a decent fix. You already need to fill in your 24-bit identifier anyway, so when you receive your own transponder, it will have your exact position included.

This way you may have redundancy in GPS location.

What do you think?

10

Technical Support / Re: Yet again - ghost target 100 feet above

« on: August 06, 2018, 06:38:32 pm »

..Interesting the same encoder which has +/-125ft accuracy

 I recall that this is a left-over of parallel altitude encoders for early Mode-C transponders. They used octal encoding (just like the xprd codes themselves) and this allowed for a good trade-off between bits required and accuracy. A single octal digit (3 bits) is enough to encode 1000ft. Flight levels are divided up in 500ft increments (East/West, IFR/VFR), so having 125ft steps are plenty to have error margin and still keep things safe.

The fact that we now have cheap sensors that can do +/-10cm for penny's wasn't so obvious when the Mode-C standard was cooked up.

11

Technical Support / Re: GDL90 vs Flarm

« on: June 24, 2018, 04:04:24 pm »

Thanks Lee, good to know it's already understood and fixed.

If you want me to verify, then you know how to contact me. 

Cheers,
Rob

12

Technical Support / GDL90 vs Flarm

« on: June 24, 2018, 02:03:44 pm »

This morning I updated PAW to the latest release, to play with GDL90. I'm using EasyVFR on a Samsung tablet.

When I use the Flarm interface, planes close by are displayed red, and planes that are further away are shown in green.
When I switch to GDL90, all planes are displayed in red. Even airliners at 35K feet 

Which device marks the planes as safe/dangerous? Is this something done by PAW, or does EasyVFR make that decision? If EasyVFR, could there be an issue with the GDL90 stream that prevents EasyVFR from making the right call?

EasyVFR displays 'GPS Fix' and shows altitude, direction and speed of other planes in both modes.

13

General Discussion / Re: Support for classic systems?

« on: June 24, 2018, 01:55:16 pm »

I'd sign up for 90 as well. Having a device with a hard stop date is not good. Especially when you only find out by the time the license has expired. Since mounting the PAW in my plane, I haven't used the web interface until this morning when I updated the system to the may release. There's no advance warning, so unless you start putting reminders in agendas it's going to bite you when you are about to leave for a nice trip.

So yes, I am *very* much interested in a fixed, non-expiring license. I would even be OK with a split license into a 'never stops working' for 90 part, and 'updates available until' date. So if I'm happy with what I have, it will just work, and if three years from now I find that there's new functionality then I'd be happy to pay another 15 or so for the latest and greatest update (*if* that still runs on my hardware)

Rob

14

General Discussion / Re: Support for classic systems?

« on: June 21, 2018, 05:37:07 pm »

Hi guys,
Fair enough. I'm just a bit weary having to replace an otherwise well-working device in my plane, especially now that it's a fixed install. With most old equipment you can keep using it, even if the vendor stops supporting it or vanishes, but as PAW is an annual licensed device, as soon as updates are no longer supported the clock starts ticking for having to plan replacement. Still wouldn't mind a perpetual license option to avoid this.

Anyway. at this time it sounds like I was too nervous. Sorry for that.

15

General Discussion / Support for classic systems?

« on: June 20, 2018, 09:57:55 pm »

In the early beta days , PAW required a different RPi and bridge board. I bought those early on. Those became obsolete after new functionality was added and a new bridge board was required. A couple of software versions later, support for the old hardware was gone and we needed to buy new hardware. Which I did. I now have a fixed install in my plane, and it works very well.

Now Rosetta comes in, with RPi 3 and some extra's. 3rd generation in just over two years. More features, more processing power required. This begs the question: How long before my current hardware will be declared obsolete? What commitment for ongoing support for the now-classic hardware can existing users expect?