PilotAware
British Forum => Technical Support => Topic started by: crisisguy on March 31, 2017, 08:02:43 am
-
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?
-
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
-
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
-
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
-
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
-
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
-
Cheers Lee
As ever thanks for the support
David
-
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?
-
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
-
Here is Dynon's reply:
Currently, it does not. We are looking into adding it in a future release.
-
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
-
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.
-
Jp62, crisisguy
What versions of SV are you running ?
Maybe you have different versions, hence different behaviour
Thx Lee
-
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?
-
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...
-
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...
I agree 100% - im using mainly the audio alerts
may get a second ipad to show the radar view although i think the next version of SD may have a pop up display
-
Ive flown another 15 hours since last posting including a trip around Paris. Most of the time the PA is stable although every few flights i'm getting the PA dropping the serial feed to the PA. the Pa is stil lworkign as im getting audio alerts. It seems to never be the first flight of the day, could it be a heating issue affecting the serial out? > Its also not related to traffic density. It appears to drop out at times when there is no traffic around. And a few seconds later it re establishes the data link.
-
Hi all,
I fly with SV. You need to set the baud rate to the fastest common rate both PA and SV support. I can't remember off the top of my head what this is, but the problem described is exactly what I was experiencing when I first used them together. As soon as I'd upped the baud rate all was OK.
Regards
Carl
G-URMS
-
Hi all,
I fly with SV. You need to set the baud rate to the fastest common rate both PA and SV support. I can't remember off the top of my head what this is, but the problem described is exactly what I was experiencing when I first used them together. As soon as I'd upped the baud rate all was OK.
Regards
Carl
G-URMS
Hi Carl,
You are correct, but in version 20170619 this issue is fixed for all baud rates.
The probelm was that PilotAware was overflowing the UART buffers, so parts of some messages got lost, SV got very upset with that, even when the messages rectified themselves.
Now, PilotAware will restrict the number of traffic messages sent to SV, based upon the baud rate selected.
Bear in mind, that this means for low baud rates, only the most critical (closest) traffic messages are sent for the available data rate.
The best choice is to select the highest baud rate available by both PAW and SV
Thx
Lee
-
Great news on the update, thxs for sorting Lee.
I'Ve updated my PA this morning via USB, no glitches in the process. I will hopefully fly tomorrow and will report back.
-
I flew 6 legs yeardays, 5 there were no issues, on one leg the old behaviour occurred. It seemed to be bearingless targets that caused the hiccup.
Still seemed a big improvement. that said, there wasnt a lot of traffic about.
Thanks Lee for attempting to resolve this.
-
I think we need a definitive statement from dynon as to whether they support bearingless targets, then we can address the issue accordingly
Can you contact dynon for help on this, or if you can get a contact for me, I will pursue
Thx
Lee
-
heres the email ive bene using for technical support
support@dynonavionics.com
-
Hi,
I'm having the same problem with my interface between the Rosetta unit and the Dynon Skyview. I initially increased the baud rate from 57600 to 115200 and thought it improved but now I don't think it has. I keep getting comms fails and "Caution" warning from Skyview. Interestingly it virtually always happens on the return flight aswell?
I was not going to reduce the baud rate but wondered how you got on with 9600 and whether this still works for you?
Thanks,
Chris.
-
We should contact their support
We can replay the track file to see if they have an issue with the data
Thx
Lee