Hi Russ,
I only rent aircraft from the flying school so I'm not always in the same aircraft. Also, depending on which aircraft I fly will have an impact on where I mount the PA unit. Having only a 50cm cable from battery to PA does somewhat limit that. If I'm on my own I expect it will just sit in the top of my flying bag on the pax seat else probably in the side pocket. I can hear people screaming about range impacts already but from inside the car low down even in built up areas I can see a/c at really much longer distances than I would need (ADS-B at least don’t know about P31 yet).
Longer cables, may be OK, we probably have to do some testing, the issue is cable quality, and this comes down to wire gauge versus length, the JuiceBitz cables seem pretty good, but I have not tried the cables greater than 50cm, possibly oithers could chip in here ?
Antenna placement is crucial to range - I don't need to tell you that, and especially at these high frequencies.
So after booting up my device I don't really need to go to the web interface at all other than to change the hex code from the auto generated code. You might say there is no need to change it as it will be unique to my device so all's fine.
Firstly, the hex code is persistent, so it will remember the last value entered.
If you leave it to the auto generated value, that is fine, but remember, if the A/C you are flying in is ADS-B equipped, then it will appear as a piggy-back aircraft on top of you, and I am not sure how the NAV tools will behave if they have collision detection algorithms enabled.
If I'm flying along and I can see another aircraft at a similar level getting picked up on SD and I hear G-ABCD talking on the radio I'd quite like to know if the aircraft I can see on the screen is the one I can hear. The Hex ID doesn't help me with that so I'd rather see the reg / callsign displayed. So I'm thinking if I'd rather see that then I should probably have the option of entering that data myself so others can see that about me.
There are 3 ways to manage this.
1. Have a lookup database which cross references the HEX value to a callsign, G-INFO will sell this database $$$
2. ADS-B can have the Flight Number/Call sign embedded within its messages, if the transponder supports that feature
3. An additional field is available in P3I, which I intend to use for this capability
Can the a/c reg be entered into the hex value instead or can it be entered as a separate value somewhere?
You cannot do this. This field is part of the protocol as a unique 24-bit identifier for each transmitter.
In fact the web interface is set up to not accept non-hex characters of length not equal to 6
Personally I want to continue using my BT GPS unit stuck to the windshield and with a definite clear view of the sky so I won't be adding a GPS dongle to the PA. CollisionAware is then still very useful to me. I have to go to CollisionAware in the workflow so to swipe the connect button and having the ability to enter the a/c reg / callsign will avoid having to also open up a web page. It would just feel like one less thing to configure (or forget to (re)configure).
I want to make CollisionAware (or you can also use NMEA GPS) as lightweight as possible.
There is a very good reason for this, the Apple/iTunesQA program.
Bug fixes and enhancements take a very long time to get through the Apple/iTunes QA program, I think the last upload took 12 days, this assumes no issues with your upload. If Apple decide there is a problem, you have to fix it, then re-submit. This kind of throughput is unacceptable. If you compare to how quickly I can rebuild the PilotAware release, and have it uploaded, you are talking a couple of hours.
So based upon this, the internal Web server is definitely the way to go, not to mention the fact this this is agnostic as to whether the host device is iOS, Android, WindowsCE or an eReader
Thx
Lee