Does anybody else have a Skyecho2 ads-b transmitter and notice they do not show up on any tracking pages?
We currently have about ten of these units flying around Northern NSW and the reporting on them is not happening. At best they have one packet received over a period of a few months.
We’re reasonably sure that the units are transmitting correctly as some of them have reported in the past or have provided very precise live tracking in specific locations with other pages.
There might still be a transmitter issue or a config issue with the transmitters but I think this is unlikely.
If the transmitter is well within the range of a flightware receiver, nothing is being reported.
The suspicion is of course on the individual receiver, but the transmitters have been flown past multiple ground stations and driven past many on the ground and nothing is being reported. It’s at this point in time that I’m not questioning the receivers and software.
For all of them not to be reporting most of the time makes me question my own sanity first.
I now wonder how much ads-b traffic is actually not being seen and more importantly, are the transceivers in the air seeing each other. I fly a microlight, so I’m slow moving and hard to see. If my ads-b isn’t being seen, then how many others are not. The problem might be more serious than just my transmitter.
I’m interested in hearing what others have noticed.
Is there a way to see text packets or raw data from the receivers? This might help in identifying what they are or are not seeing.
A partial answer, but it might point you in the right direction.
Those SkyEcho devices show up as DF18, which is normally rebroadcast aircraft. Normal DF18 is rebroadcast TIS-B or ADS-R. Most of the 1090 receivers will receive it just fine, but some of the sites filter it out and do not upload the DF18, since it can be a bit confusing. I would think you would see it on a local view, if you use that. It will probably not be uploaded to FA and visible there.
All my local traffic is viewed on PlanePlotter software. I decode with dump1090-fa and also dump978. Both of those receive DF18 from a local tower about 3 miles away. All that DF18 traffic shows locally, is visible on the PP network, but likely not visible on the FA network.
When the SkyEcho devices first showed up a few years ago on the PP network in Europe I tracked down the details. Their web site and user PDF explains it fairly well, and I believe it even explained the DF18 part that we had already figured out.
Those are nice devices. The last time I checked a year or so ago, I believe they were only authorized in Europe, and possibly Australia and/or New Zealand. I have never seen one in the US and don’t know if there are any plans for approval. The US is already tricky enough with 1090/978 and rebroadcast traffic on both 1090/978.
The above details are from memory and I have not looked at those devices recently.
If you have access to the local SkyAware view on a receiver, the DF18 will show up on that view. It is easier to spot if you “Select Columns” and enable the Data Sources. Normal traffic will show as ADS-B or Mode-S, your SkyEcho DF18 devices will likely show as TIS-B.
If you have local access, you can also use view1090 on a Pi to connect to dump1090-fa which is already running.
To record all traffic for a specific aircraft hex registration, just run a command like below.
view1090-fa --show-only AC6AAE > AC6AA-log.txt
The --show-only will display only messages from that specific aircraft. They will be decoded and human readable.
The > xxxx-log.txt will send the output to a file instead of the screen if you like. While logging, you can also use Linux “tail” to follow the file while logging.
It’s possible that we’re hearing data fine but never deciding to create a flight from that data because of the characteristics of that data. We don’t create flights for every bit of data we hear, only those that we consider to actually reflect an aircraft in the air. Microlights are sufficiently low-and-slow that, in the absence of other data e.g. a flightplan via Airservices Australia, it’s quite likely we never decide it’s enough of a “real flight” to depart the flight.
(I believe we did fix a DF18-related issue in flight tracking that meant that these transponders would never result in a flight without additional data sources; but that issue was only present between, IIRC, October - February or so)
If you can give me an ICAO address + a timestamp for a flight you think should have been tracked, I can take a look at what we heard.
DF18 is the “non-transponder” message type, i.e. “there is no full Mode S transponder here, don’t interrogate me”. While TIS-B/ADS-R is indeed DF18, it’s not the only DF18 traffic and the message formats do distinguish TIS-B from directly-transmitted messages. I would expect a correctly-formed message from a SkyEcho to turn up as ADS-B, not TIS-B, in SkyAware.
(outside the US – i.e. where there’s no TIS-B / ADS-R – most DF18 traffic will be ground vehicles, balloons, and things like the SkyEcho. Maybe the occasional fixed obstacle, though I think those more commonly turn up on DF17 for some reason)
Being in the US, I have only received the SkyEcho devices through the PlanePlotter network received in the UK. Those were classified as the rather generic DF18 group on that network. When they first appeared we were lucky enough to have a hot air balloon instructor pilot that owned one and did some testing for us. Interesting devices.
No, these units are independent of the aircraft. They are completely standalone and work out of the box. There’s no external connectors or antenna other than a USB-C charging cable.
Installation involves me putting the transceiver in my pocket. In reality I have it mounted on the aircraft cowling.
And it’s more likely that we’re going to be seeing a lot more ads-b traffic in the future like this.
As an example I will be taking this unit with me in another aircraft, a paraglider. It’s only a matter of time before this becomes a trend, normal behaviour or expected or regulated.
In terms of confirming it is working, the expectation is of course that you turn it on and it works. It only has one button, power on. So once it is configured, it can be left to just report. It does have ads-b in functionality. So apart from the three Green LED’s there is very little indication that it’s operational. If it doesn’t show up on any flight reporting, you might be suspicious it’s not working. I have other ways to confirm the operation, but you can understand why it’s not obvious if the units are working correctly or if at all.
Thanks guys,
It’s a bit of a learning curve for me because I’m coming it on the ground floor for the ads-b protocol and working my way up from layer1.
Some of these thoughts like; assuming both the transmitter and the ground stations are both working, why are flights not being displayed?
Air speed, altitude, configuration settings. I have tested these and got either no answer or no consistent answer. It’s not just my unit, it’s quite a few other units too.
When they have reported the results are inconsistent. In the past some units have worked fine but now don’t report. For weeks we’ve been trying to work out why and then suddenly there are some reports but then none again. One unit has reported on the ground to my flightaware receiver, but then never again. It’s flow in a ga aircraft at +100knts past several FA ground stations and no reporting. My own unit, reported a very accurate ground track past one airport but since has be a bit invisible. It’s never reported via a FA receiver.
With such consistent inconsistent results the question had to be asked, How much other traffic is missing? This is something I can test and actually answer.
It turns out from the few observations that I have made, a lot of real ads-b traffic is missing.
Using the ads-b in function I watched some air traffic moving from some local airports. Each of these has several FA receivers within range. It appears that it’s not just Skyecho2 units, (I exaggerate) it’s almost everybody that doesn’t burn avtur.
As you might imagine, we don’t really care who’s in class A airspace. We want to see all the little guys in class E and G airspace.
I haven’t worked out how to log into my FA receiver yet. (login/pw) It would be very helpful to be able to look at the raw packets and confirm they are being heard and decoded. I have a weird skillset. A lot of RF and comms experince, but also seeing things for the first time.
(thanks MC130E - just trying to get to the shell command line first before I can poke the box.)
I don’t have any flight times I can remember at the moment.
I can provide the ICAO and of course just take it for another flight and make careful note of the time.
