A little concerned...
I myself am becoming a little concerned with how this box will perform long term. I've only flown it 2 flights yet, due to extreme cold up here, but here are some issues I see or am concerned about.
First, regarding Fred's workaround, I think that it's a major band-aid to take off without powering on your ADS-B system and then fly to that class B area for the testing. Sure, that can produce a 100% or nearly so, reliable test, but then it's not a real world situation. It's akin to using cliff notes to pass a test, but in the end you are just stupid, because you never did the homework. If your system performs 100% for the "test", and only 85% for the 10 years after, some day the FAA is going to come knocking at your door.
I've been working this past week with someone doing major data capture and processing of the output of these boxes and have learned a lot more too.
First, don't be surprised if you don't get baro alt, and you have no altitude encoder input. You may very well end up in situations on many flights when your system simply doesn't get this baro altitude all of the time, due to it not being sent from the transponder, or sent frequently enough. Same potential for squawk code. I don't see this as the biggest urgent issue, but it's just one that has me concerned with how the long term prospects of using the box will be. Coming from an ADS600B NavWorX unit, I had hard wired transponder codes, and hard wired baro alt. That really is the "better" way to do things.
But the differences get much bigger when you look further at the feature list:
First, the 2 serial ports are not asynchronous and you'll see in settings that you can't set a different baud rate for RX than you have for TX on a port. Originally I wired mine for GTX transponder control, 38,400 baud GDL90 out for the EFIS (both COM1) and then GPS NMEA in at 115,200 baud from the SkyFYX, and then hoped to output on COM2 115,200 baud GDL90 to another system. Right now, this in so many ways is simply never going to work, but, the ADS600B did it perfectly. The GTX requires 9600 baud, my EFIS 38,400 baud. You simply have to choose, which one do you really want. Of course, traffic on the EFIS, right? So there goes the hard wired squawk, and with the asynchronous issue, you will never have any way of getting in altitude encoder input either. The box is simply handicapped. We're flying behind boxes that were not built for GA, they were built for drones, and were adapted for just barely be suitable for GA if you can live with the tradeoffs. Output power is also less than the ADS600B. The 2 places it has the ADS600B beat handily are, DUAL FREQ, and a very convenient configuration interface with wifi. Other than that, when you look at the molex connector and things like MCX connectors, we're looking at something really not designed for our environment.
Second, and this I think is going to be bigger than people know today, is that this box is not going to necessarily serve you traffic alerts reliably. Here's why. The NavWorX ADS600B performed traffic filtering and sorting for you before it delivered it to your EFIS. This was for very good reason. #1, if your EFIS is handicapped by a baud rate limitation like mine is, you simply can't handle 50 intruders on your screen at the same time. Personally, I really don't think you'd WANT to anyway...if you had that many, you couldn't even read airport identifiers and airway designations and features on your MFD. There's a real limit to how many targets you would want to display.
#2 though is much worse. The traffic coming out of the EchoUAT is not at all sorted by distance, filtered to limit altitudes, or anything like that. The NavWorX filtered traffic to within, I believe +/- 8000' of your altitude. Having the airliner show 30,000' above you is not only unnecessary screen clutter, but if you aren't able to pick out traffic up close due to this clutter, it's a safety issue. Beyond that, since it's delivered UN-sorted to your EFIS, your EFIS may or may not receive the targets that are out there. GDL90 spec doesn't allow for multiple batches being sent, but that's what they're doing right now...sending one pile and if it is too much it sends some in a second batch. This can lead to missing targets, blinking targets, or other issues....but the worst of it is, since it's NOT sorted by range, you may very well receive 40 targets that are 60 miles away at the nearest class B area, but NOT receive the 2 that are 2 miles away from you, headed right for you in the practice area by your local airport. NavWorX specifically sorted it so that you would ALWAYS be delivered the targets in order, from closest to furthest, and only those that were real factors for you. THAT is the way it really should be done. It's simple software pre-processing to rework this data and serve it up in sorted order. I know, because right now a friend of mine is writing code for an interface box that can fix this mess...gathering up GDL90 out of the UAT, produce a list of traffic, sort the list, and transmit the list in sorted order. But this should be done by the UAT manufacturer.
So given what I see today, I think that Uavionix will need to step up to the plate a little and start working hard on their software and/or hardware, if they want to keep playing in the GA space. NavWorX played games with their GPS module, but had a pretty good box built, otherwise. They just needed to add dual-frequency ops and upgraded their GPS and it would have been fine. And in their case, the GPS issue probably from a functional standpoint never caused any real issue...it was a paper problem and a potential integrity problem. I always knew I'd have to replace the GPS module...I just wish they'd have stuck to their original plan of selling us upgrade modules in the future, as we were told back in the 2010-2013 time period. Hopefully Uavionix doesn't play rinky dink games with their systems just the same. If they don't address baro alt and traffic display reliability, I fear that we'll all be told some day that we have to buy yet another box, and re-integrate it all over again.
If you're on the fence about an ADS-B system, and have been looking at swapping transponders to the GTX345, that may be your one guarantee of getting a system that you won't later have to yank out. But, if Uavionix steps up a bit, hopefully we will get the performance we require.