Recent Posts

Pages: 1 ... 7 8 [9] 10
81
Technical Support / Re: FX data in and out - Skyview Compatible for both?
« Last Post by Admin on March 25, 2024, 07:36:14 am »
Hi Russ

I think there is some confusion here


The gps input should be fed into the input flarm nominated rj45, pretending to be a flarm unit which only provides gps and no traffic

The display output rj45 should be used to provide the output gps and traffic

Thx
Lee
82
Technical Support / Re: FX traffic filters not working as advertised?
« Last Post by russp on March 24, 2024, 07:37:16 pm »
You are correct about the behaviour being the same on the rosetta as I just tested it. If I can ever get the FX to connect to the skyview (see my other post) I'll be able to feed back on use in practice but I can't help thinking that being able to limit the RS232 feed (out only) separately to the wifi feed would be very useful. You're either going to have to change the behaviour or the documentation and the presentation of the App as it's definitely misleading currently.
83
Technical Support / Re: FX data in and out - Skyview Compatible for both?
« Last Post by russp on March 24, 2024, 07:29:58 pm »
Hi Russ,

I've discussed this with Lee and Ashley and have found it is all possible. Attached is my question in diagram form (the same as yours). I was hoping to have it installed and documented but delayed at the moment.

The main thing is, yes, what you want can be done......it just hasn't been yet  ;D

Well I wired it all up as per your details and went and tried it ... and nothing.. Dynon doesn't see the traffic from the FX and the FX doesn't see the GPS from the Dynon. I wired up the PAW supplied RJ12 connector cable cut in half to a DB9 serial connector to simply mirror the USB to DB9 serial cable currently running from the Rosetta so it seems some clarification of the connections is required - I'll be on to the office tomorrow.

Cables wired as follows :-
PAW supplied leads
RJ12 -> DB9
6- white - GRND  — to pin 5 on DB9
5- black - RS232 data out to pin 3 TX
4- red - RS232 data in to pin 2 RX
3-green
2-yellow
1-blue - 12V out (DO NOT CONNECT)
84
Technical Support / Re: FX data in and out - Skyview Compatible for both?
« Last Post by russp on March 23, 2024, 10:33:56 am »

I have asked about the exact layout of the FX RJ11 plugs but have not got a definitive answer. Lee did say to wire them as per Flarm but, unfortunately, they may have had a standard layout once but they don't any more, it would seem. As an example, I have attached what would appear to be the Flarm layout for RJ11, however, the other day when installing a Flarm indicator (LXLED+) we had one manual saying pins 2 & 3 were RS232, 4 GND and 5 DC but a slightly newer manual saying pin 1 is GND, 2 & 3 RS232 and 6 was DC. Same Flarm device and a couple of months difference made a big difference to how they were wired and did nothing to convince me there is a Flarm standard.

SO, the upshot of this is we need a kind soul from PAW to give us the definitive answer on the RJ11 pin layout for the FX. Pretty please  :)

Quote
don't suppose it can be pushed into the same plug can it rather than needing to use two like the standard PAW?

HMmmm, I don't know but I can see no reason why not but it would depend on how the FX has been configured internally. It might be that the 'In' RJ11 socket does not have an RS232 out connection internally and the same for the 'Out' wire. If both RJ11 slots are wired internally for in and out then you could (in theory) use the In from your SkyView GPS serial Out and the Out to your SkyView Flarm Traffic serial In.

SO, another pretty please; are the FX RJ11 sockets wired internally for RS232 in AND out (Rx/Tx)?

Hoping someone from Pilotaware will pick this up and answer the two questions..

1. we need a kind soul from PAW to give us the definitive answer on the RJ11 pin layout for the FX. Pretty please  :)

and

2. are the FX RJ11 sockets wired internally for RS232 in AND out (Rx/Tx)?
85
General Discussion / Re: Aircrew.co.uk and PilotAware Playback Sites
« Last Post by Admin on March 22, 2024, 10:50:36 pm »
We are upgrading our servers to add more capacity
So machines are up and down at the moment

Thx
Lee
86
Technical Support / Re: adsb (out) not showing on Vector
« Last Post by JCurtis on March 22, 2024, 05:11:30 pm »
I suspect you are transmitting ES just fine, regardless of what Vector is logging.
ADSBexchange will display MLAT or ADSB depending on what the feeders send.  I feed them ADSB and participate in MLAT too, same for FR24. 

If you flew nearer to Cambridge, and I knew when to keep and eye out, I could check my receiver in real-time to see precisely what is being transmitted.
87
General Discussion / Re: Aircrew.co.uk and PilotAware Playback Sites
« Last Post by BobD on March 22, 2024, 11:35:52 am »
It appears the Playback program is having problems again.
After chosing a file, and uploading it, it sticks at 100%, and doesn't run the track replay.
88
Technical Support / Re: adsb (out) not showing on Vector
« Last Post by Mach2 on March 22, 2024, 10:41:04 am »
To answer the last post, the FUNKE transponder was new 2 years ago - I had to exchange the old one which did not support adsb.  There is no warning of GPS failure in the transponder.  I can check the GPS data input using the setup mode but that is only available with the transponder in standby.  So I have checked it on the ground only.  I will check the cable continuity but it is a very simple single cable into the Trig and Funke plugs.

Flew yesterday and adsb exchange tags the flight as sourced from adsb data but nothing shown on vector.  After flight spoke to Pete Pengilly about the issue and he is going to put his test set on it next time he is at our base.

Thanks for all the help
John
89
Technical Support / Re: adsb (out) not showing on Vector
« Last Post by exfirepro on March 21, 2024, 11:21:20 pm »
I picked an aircraft at random (a PA28) that was live and showing MLAT. Then went back to look at previous flights for the same aircraft and they showed as MLAT too. Just to see what ADSBExchage recorded for historical flights.

So isn’t Mode-S shown as MLAT and with added ES becomes ADSB. If so it looks like things are working on the aircraft in question.

Thanks for the clarification Jeremy.

You are of course correct, that Mode-S aircraft are reported as (and using) MLAT - otherwise, without their own ground radar, it would of course be impossible for the tracking sites to report the position and track of aircraft transmitting solely Mode-S signals.

You are also correct that Mode-S with ES is ‘accepted’ colloquially as ADSB and reported as such on tracking sites, even though the type of signal transmitted (known as DF17) is measurably different from ‘True ADS-B’. In practice FLARM and PilotAware are also forms of  ‘ADSB’ (Automatic Detection Surveillance (by) Broadcast (of position and other relevant information). They just operate on a different frequency to the normally accepted 1090 MHz used by ‘Traditional ADS-B’.

Together with cellular-based systems like SafeSky, PilotAware and FLARM are now referred to by EASA as part of the ‘ADSB-Light’ suite of surveillance tools being considered by EASA and the CAA as acceptable for use in ‘common usage airspace’ known as ‘U-Space’ - where it is anticipated that manned and unmanned aircraft will be allowed to operate together without the need for exclusion zones. This being the case, might the tracking sites not simply be using the generic term ADSB to describe reports derived from ‘known-position’ transmissions of any sort, possibly combined where available with positions derived by MLAT of ‘Pure Mode-S’?

I am not convinced that the label ‘ADSB’ on a tracking site, without further clarification and corroboration, provides incontrovertible proof that a Mode-S/ES installation is operating as intended. If that was the case, how do you account for the lack of specifically DF17 ADSB reports from the multiple sites on the ATOM-GRID Network which reported P3i and FLARM data from the G-RUVE, when the database also contains multiple DF17 reports from other aircraft in the same area during the same time periods?

Unless and until we can find another explanation, the logic clearly supports the likelihood of a problem with DF17 Mode-S/ES transmissions from G-RUVE rather than the reverse.

Regards

Peter
90
OGN-R PilotAware / Re: FLARM to change protocol
« Last Post by DY691 on March 21, 2024, 10:21:55 pm »
By safesky directly
Pages: 1 ... 7 8 [9] 10