Plans for an iBox V2 & related?

[mviowa]

To start, I'm a huge fan of MGL. From a technical perspective, I like the design. While I was drawing up my installation documents, I was thinking about a few alterations that would appeal to me and drew them up. Just sharing to see what others think.

Here are the key points I wanted to accomplish:
offload AD from iBox (redundant pressure transducers over can bus? just replace the sensor module if it fails.)
eliminate the hose barb from AD sensors ( I like threaded)
eliminate 'jumpers' and resistors; incorporate into hardware design with dip switches
switch to Amphenol aerospace connectors

Let me know what you think!

[rainier]

Well the V2 IBox is already shipping.

But it's not what you want.
It's a redesign of the V1 to remove parts and use some new components. In the main this was required as we needed to get rid of the NXP pressure senders as they are virtually unobtainable or we can only get at huge cost.
We designed a new pressure sender ourselves which has been fitted into the MX1 for some time and now the iBOX as well. These senders are much better than the NXP sensors and are extremely accurate and free of drift. Effectively if you now do a pitot/static test and it's out - suspect your test kit !
In addition it has a new processor and all serial ports are now high speed (not just the first two).

The high speed option is gone - only one ASI sender is now needed and it has a wide enough range to cater for both low and high speed applications.

We have also changed to a rechargeable internal battery rather than the CR2032 cell used in the past. It is a Nicad cell so there are no transport restrictions which are now a huge issue with shipping - if a shipper even gets a whiff of "Lithium" there are issues.
We only just managed to prevent an entire shipment from getting destroyed in a hazardous waste facility in UK customs because we had Lithium coin cells in some devices. It is hard to explain to Customs officials that these coin cells are exempt as they have an energy density well below the limit.
Even arguing that these are instruments that actually get fitted into an aircraft cockpit holds no value - you are not allowed to transport them.

As to the connectors - we will definitely not change to the connectors you suggest - if we were making stuff for the military we would - but we are not. Those connectors are hugely expensive and difficult to source for many users on the planet. D-Subs on the other hand are just fine, use less space and weigh much less.

[adamoconnor]

To start, I'm a huge fan of MGL. From a technical perspective, I like the design. While I was drawing up my installation documents, I was thinking about a few alterations that would appeal to me and drew them up. Just sharing to see what others think.

Here are the key points I wanted to accomplish:
offload AD from iBox (redundant pressure transducers over can bus? just replace the sensor module if it fails.)
eliminate the hose barb from AD sensors ( I like threaded)
eliminate 'jumpers' and resistors; incorporate into hardware design with dip switches
switch to Amphenol aerospace connectors

Let me know what you think!

I enjoy seeing posts like this because I enjoy seeing the enthusiasts at work.

One thing though that I did want to mention is that unless you expect to see these products in Bombardier Challenger aircraft, the majority of consumer avionics will never see AMP aerospace connectors. The price of just one MIL-SPEC connector is a factor of 10 above a d sub, and d subs are proven to be great connectors in pretty much all brands of GA avionics, and even in many part 25 aircraft these days.

I will say that from a wiring standpoint I agree that being able to enable CAN termination on a per-unit basis would be nice, as opposed to doing so on the harness. That said though, coming from a support standpoint, the reason many of these jumpers exist on the harness side is so that if a unit ever needs replacement, there is minimal configuration on the unit itself ultimately reducing support calls and downtime because someone forgot to or doesn't know about turning on the termination resistor.

While I am 100% on board with you on moving to threaded pressure connectors, offloading the air data from the iBox (or EFIS itself in most cases) and onto another unit doesn't really seem to me like you're solving much. Pressure sensors are probably one of the least troublesome things that I am aware of and making a new unit dedicated to air data will only serve to take up more space, use up more precious microcontroller chips that we desperately need, and adds additional wiring complexity to the CAN bus. In one example you're moving the AD to the SP-9, making it an ADAHRS but other than copying Garmin's method, you're only moving the sensors to another box that would still need an entire replacement if the sensors did go bad.

[Viggenbuilder]

Well the V2 IBox is already shipping.

It's a redesign of the V1 to remove parts and use some new components. In the main this was required as we needed to get rid of the NXP pressure senders as they are virtually unobtainable or we can only get at huge cost.
We designed a new pressure sender ourselves which has been fitted into the MX1 for some time and now the iBOX as well. These senders are much better than the NXP sensors and are extremely accurate and free of drift. Effectively if you now do a pitot/static test and it's out - suspect your test kit !

Hi Rainier,
I recently sheared the pitot port on my V1 iBox. Do I understand correctly that this is a MPX12 sensor ?
I note that the MPX10DP is available and the same package except it is 3.5 mV/kPa not 5 mV/kPa. Is there a way it can be substituted for replacement ?
Otherwise can the new v2 sensor be retrofitted to an existing v1 box ?
Thanks
Richard

[rainier]

No, we use MXP5010DP and MPX5050DP for the high speed side (if fitted).

We used MPX12 in older devices starting with the original Flight some 22 years ago up to the Odyssey/Voyager. MPX10, while similar cannot be used die to the high drift of the sensor.
Both MPX10 and MPX12 have been discontinued a long time ago. The 50xx series has also been discontinued now.

These sensors where originally made by Motorola which became Freescale - then Philips aka NXP bought the line and ran with it for a while but seems to have neglected it to the point of it slowly vanishing into history.

[Viggenbuilder]

Hi Rainier,

iBox V1.

Question, To replace the MXP5010DP sensor the processor board has to be removed for access, so the keep alive is not maintained, which I assume causes loss of boot data ?
So just replacing the MXP5010DP is possible at field level but will need bench set up and calibration at the factory post change ?
Thanks,
Richard

[rainier]

There is not a huge amount of data kept by this - it's your virtual tank levels, hobbs and it keeps your real time clock alive.
If you take a note of your current readings - you can always reenter them afterwards through the EFIS. Not a train smash...