odd behaviour when PA hooked up to dynon skyview

[crisisguy]

First time i flew with PA working through the SV, everything worked fine.

Second and third flights, each time a traffic alert was announced via the SV, the SV then announced it had lost the FLARM signal and all contacts would vanish.  A few seconds later the system would reconnect to the serial data, and then again the moment it announced "traffic" the same thing would happen.

The PA is still working fine as i was receiving audio alerts and I checked the PA via the wifi webpage and all was good.

I thought it may be a loose contact so rechecked these on landing - and they were fine.

Ive changed the baud settings on both the PA and the SV from 56,000 to 9,600. Ive yet to test this configuration.

any other suggestions?

[AlanG]

Hi Crisiguy

That sounds very much to me like a power supply issue.  How are you powering the PAW unit.
There are lots of threads on here about this issue and the fact that it must have 5v at a minimum of 2amps and it is essential you use the supplied power cable or one of at least 20 awg  to reduce power loss through the cable.  The PAW might run quit happily until extra demand is placed on the processor to produce audio alerts etc.  This was one of the main reasons for changing to the RPi2  and supplying a power cable when the Classic Kit was released.
Some info on how you are powering your unit will be useful for diagnosis.

Alan

[crisisguy]

Thanks Alan - thats interesting

Im using this power supply which claims its rated at 2.6 amps per output https://www.amazon.co.uk/gp/product/B01B7MY5YQ/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

Im using the supplied PA USB cable

[Admin]

Actually I think this is something reported by another user.

When there is too much data for the selected baud rate, it seems the dynon skyview cannot recover from the data loss.
This is especially seen in high volumes of traffic at low baud rates.

There is an internal fix which will limit the number of contacts sent over RS232 depending upon the baud rate selection.

I supplied the internal fix to the user who logged the bug initially, but have not yet had feedback.
This fix will be in the next release.

Although the fact you say that it happens when the 'traffic' announcement is heard, was this a bearingless report,
did it report a bearing and distance, or just height and threat level

I wonder does SV accept bearingless traffic reports ?

Thx
Lee

[crisisguy]

Thanks Lee -so lowering the baud rate will make matters even worse?

What you say makes sense, i think when it was a bearingless target it didn't drop out, when the data contained more info, the PA gave the full audio alert with distance and direction and  the SV cutout

Can you send the fix or shall i wait for the next update?

thxs

David

[Admin]

I believe that lowering the baud rate, will make the issue more likely to occur

I can provide the fix, but it is an engineering release - so has not completed full testing.
I have asked the other party if they have had the opportunity to evaluate yet, so lets wait on his response first

Thx
Lee

[crisisguy]

Cheers Lee
As ever thanks for the support

David

[crisisguy]

Further update

some flights the PA works through the SV perfectly, other flights it acts up and as soon as the SV announces Traffic, the SV then alerts traffic failure and then a moment later picks up the signal again and works and repeats this each time a traffic alter is announced.

Seems like the first flight of the day is fine then the second return flight to base does this - could it be a heat issue?

[Admin]

The traffic annoncements are they ADSB or Mode S/C ?

I am wondering if we are sending bearingless traffic to SV, and it does not like that.

I think you need to check with SV if they accept Flarm PFLAA messages for bearinglesss traffic

Thx
Lee

[crisisguy]

Here is Dynon's reply:

Currently, it does not. We are looking into adding it in a future release.

[Admin]

I think what we need to know is, what happens when SV is provided with messages of bearingless targets ?

From the descriptions it sounds like it gets a bit upset and performs some kind of reset, this is not good - their parser should simply discard the messages it is unable to decode, and not choke

Thx
Lee

[jp62]

I flew Lee's updated engineering release software with restricted data bandwidth.  Apart from one weird repeat of the error on the first sortie with this, the Skyveiew has been error free since then.  Well done Lee!

I've not seen bearingless targets on my Skyview, but perhaps because I don't fly with the Map display much.  But I understand Skyview does show bearningless targets as a ring of targets around the own ship position.  I'll look tomorrow.  I've not seen it throw a wobbly though.

[Admin]

Jp62, crisisguy
What versions of SV are you running ?
Maybe you have different versions, hence different behaviour

Thx Lee

[crisisguy]

Lee

im running the latest version - 15.0

Now i think of it I wonder if the behaviour started after the upgrade which was only a couple of weeks ago?

[jp62]

I'm not actually sure what version of SV it is.  It is recently installed (February) with the latest verstion then, but not updated in the last couple of weeks

More data for you Lee:

1. Setting both PAW and SV baud to 57,600 and I started getting the same FLARM Failure error again.  So I set it back to 9600 and no errors.

2. There are NO bearingless targets displayed on SV.    However, this may be due to the selection of "Flarm traffic" as the input type in the Dynon serial port setup.  I believe a friend who has Flarm has got bearingless targets displayed on SV, BUT he had to purchase a Garmin TIS licence and I believe that is his setting for the SV he used.

Actually, I'm pretty unimpressed with the SV traffic display.  It shows them in the EFIS irrespective of their range.  So I get ADSB targets showing that are 30 miles away.  As much use as a chocolate fireguard.  And no bearingless targets when that is the majority of the threat out there.  So I'm a bit down on my SV traffic display...