iFly GPS Forum

We have a new Forum!  Go here to get started: https://adventurepilot.community.forum.  
The new forum is easier to use and much more capable than the old, we hope you will join our community! 

Below is a copy of the old forum. This will remain available for a short period so you can access and review the information contained here. To continue a conversation, or start a new one, please register and create a post at our new forum location.
HomeHomeDiscussionsDiscussionsADS-B Discussio...ADS-B Discussio...Horribly messed up radarHorribly messed up radar
Previous
 
Next
New Post
5/5/2021 8:10 PM
 

Further, I don't expect your "help them help you" snarky response to a commercial software product with a paid subscription.

Aside from it not being a snarky comment, Cobra is just another user/customer like you and I.  AFAIK unless you see the banner on the left side under the avatar, the person asking/answering is similarly another customer/user.

 

 
New Post
5/7/2021 2:52 PM
 

Thanks, Cobra and Mike!

They're not being "snarky" at all. if you show me a screenshot of radar issues the literal only thing i can say is "wow steve yeah that looks messed up". That's why any time there's an issue that isn't user error we always, always need a bug report/ahrs log. My developers are the smartest people I know, but if you say "my app isn't working" and we don't know anything specific then we can't fix it. 

With that being said, a couple of issues I can think of: 
First, you're using stratux. Notoriously finnicky. Out of all my experience, that is 99% likely the culprit.
The other issue could be that FAA/NOAA did recently have an outage. 

 
New Post
5/10/2021 4:27 PM
 

Stratux may be finnicky at times, though without AHRS or GPS in mine it's been rock solid so far. What is important here though is the original post was from a user with an echoUAT which is sold by iFly. So, at least two of us are seeing similar radar corruption from two different ADS-B IN devices. This doesn't prove iFly is causing the problem, it could be upstream, but I think iFly should at least be catching this error in validation checks on the ADS-B data received.

I deliberately flew the other day looking for this issue. In one of the radar frame updates, I did catch a single missing, four-row block. There wasn't much on the radar and it was near the 150nm extent, so there is no way to know if other blocks were missing or corrupt. After landing and back in WiFi connectivity I tried to send the bug report. However, after selecting a previous session log file in iFly to send, it failed to attach the file to the email (gmail app error displayed in a toast) and instead pasted the current session log file into the message body. So I guess I won't be sending a bug report until the bug report bug is fixed. Sigh.

It can be a little frustrating to see corrupt radar data across the screen, but at least in the original post's images it is obvious to the user that a problem has occurred. What's more concerning to me is that iFly provides no indication that a radar data block is missing or corrupt. When the ADS-B tower sends the regional nexrad data, it provides the complete region in blocks and fills it with valid data. The display software then chooses not to show the low values (usually 0 and 1 valued pixels are not displayed). What's clearly happening in the attached images is that data blocks, or in some cases rows within the blocks, have become corrupted or are missing. The bigger issue is that, to the user, a regional radar block with no precipitation echos (0 or 1) looks identical to a region block with missing or corrupt data. If iFly did simple radar message validation checks and had an option to depict missing pixels within the radar region that were either corrupt or missing (maybe grey or barber pole/striped like some avionics systems handle this condition), then pilots could have confidence that no diplay equals no precipitation. Currently, no precipitation display might mean no actual precipitation or it might mean there was no data received in that block.The latter condition should really be shown to the user in my opinion.

 

 
New Post
5/10/2021 10:33 PM
 

I think you may have a reasonable point about alerting the user to areas where radar data has been lost, if that can be detected.  You seem to know something about how the datastream is formatted; I do not, so I don't know if that's easily implementable or not.

At the risk of offending you, I will mention again (because it wasn't clear from your previous post) that for the AP folks to fully engage and dig into what you are seeing specifically with radar data, they will need the *ADSB* data log, not just a standard bug report.  While iFly automatically logs quite a bit of app performance data every time it runs, ADSB data is NOT captured by default.  You need to turn on ADSB logging *before* you see the issue...or at the least, while the issue is still occurring.  The instructions for how to do that are in my previous replies.

FYI, once recorded, log files persist for some time (indefinitelyd until manually deleted?).  If you have trouble sending a log, you can try again...it's not a one-shot thing. 

Also, please know that the auto-generated email created by the "send bug report" feature always includes a substantial text component in the body of the message, as well as attaching the log file.  So while I've never seen the "gmail app error" message you alluded to (what was the exact text?) and that could be an actual issue, your coment that it "instead pasted the current session log file into the message body" is simply a misunderstanding of how the bug report email is normally generated.

What type of device are you using?  (Android, iOS, Windows?)  For Android and Windows, if necessary I can help you to manually navigate to the folders where the log files live and you can use whatever email app you like to attach the file.  (I'm not an iOS guy and don't know if or how you can manually search for the log files on those devices.)

 
New Post
6/1/2021 8:44 AM
 

I observed some dropped radar frames during a flight this weekend, and managed to capture ADSB data during the event.

I also tried to send a bug report from my Android 10 device for the first time, and it did not attach the selected log file when it opened the auto-generated Gmail template.  (I did not get an error message like Steve reported, though.)  It also took a few extra steps to manually locate and attach the log file due to Android 10's increased privacy/security re: app access to data files (which is also probably the root cause behind why the auto-attachment failed).

At any rate, I did submit a bug report with the ADSB data I captured in case the iFly folks have time to think about this.

 
Previous
 
Next
HomeHomeDiscussionsDiscussionsADS-B Discussio...ADS-B Discussio...Horribly messed up radarHorribly messed up radar