Hex / Reg for renters

[rg]

Lee

A couple of thoughts about using the units. 

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).

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.

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. Can the a/c reg be entered into the hex value instead or can it be entered as a separate value somewhere? 

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).

Russ

[Admin]

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

[rg]

OK.  Understood. 

[ianfallon]

1. Have a lookup database which cross references the HEX value to a callsign, G-INFO will sell this database $$$

Some options for number 1 :

1a: We split the work between a bunch of us - building our own lookup manually.

1b: We split the $$$ of 1 G-INFO CD for Lee between us (assuming copyright issues can be avoided)

Am sure there will be a small number of additions over time but I would think it's largely static given we're only interested in reg and hex code.

[Rastus]

Lee you said   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 Others could chip in here ?

I am chipping in to say I have both a 50 cm and a 2 metre JuiceBitz power cable with identical specs and they both work fine hooked up to an iPad charger.

[Admin]

Lee you said   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 Others could chip in here ?

I am chipping in to say I have both a 50 cm and a 2 metre JuiceBitz power cable with identical specs and they both work fine hooked up to an iPad charger.

This is good news.
I would be very interested if you were able to measure the voltage at the PI, to see what the difference truly is.
It could be just over the minimum voltage, or way beyond it - hard to say

[The Westmorland Flyer]

ICAO code to callsign conversion for 3PI data  is a very good idea, analogous the the code/callsign conversion system used at control centres to convert mode-A squawk codes to callsigns. 0X406178 means nothing to anyone, but G-JONL does, to the cognoscenti.

Provided there is space on the SD card and a way of getting the data into the RPi then I think a crowd-sourcing approach to building the database would work. At my airport there are perhaps 50 aircraft that might be interested in PAW over time. A few of those would also be ADS-B equipped but not many. It would be an hour or so's work to manually interrogate G-INFO and make a CSV or whatever of ICAO codes and callsigns. I'd do Carlisle and if everyone else did the same for their airports we'd be most of the way there I reckon.

I'm a bit new to all this and still building my first kit, so I don't know how the ICAO code is used/displayed in PAW 3PI ATM. If I'm taking rubbish I hope someone will put me right!

John.

[Richard W]

At the very least, we could all specify the aircraft we are likely to fly when applying for our license. That way the PA cohort could be covered quite easily.

[DavidArcher]

Hi Lee

Like rg I rent flying school aircraft and currently have a choice of 6 aircraft.  Often I won't know which one I'm going to fly until I turn up.  Getting a bit long in the tooth I find ICAO codes a bit difficult to remember, call signs would be so much easier.  But I understand your reasons for not implementing this.

Would it be possible to provide a table in the web interface, where Users such as myself could enter the call signs and ICAO codes of all the a/c they are going to fly (say maximum 10), then include a selector of their aircraft call-signs (preferably in CollisionAware - beta users might be prepared to type in http://192.168.0.0 but your average pilot won't be)?  Then your magic software could look up the required ICAO code.