Question to SR22 owners with Engine Monitoring PLUS How the SR22 is wired

Guest Discussion
1

I learned more about how the SR22’s avionics are wired and I’ll describe this after a request for all SR22 owners with the engine monitoring package:

Let me know who you are. I think there are four of us SR22/EMM-35 owners. I would like to know if your Sandel has a “WX” with a red line through it in the upper right corner of the Sandel.

Now for some information on the avionics:

The Stormscope emits its information on an RS-232 channel and receives commands via this same channel. The Stormscope has other interfaces, but the RS-232 port is the only one used in the SR22.

Before the addition of the EMM-35 (the box added for engine monitoring), the Stormscope was connected directly to the ICDS-2000, which both receives SS data and sends commands to the Stormscope over their RS-232 link. There aren’t any commands that have to be sent to do normal operations. The only commands I know of have to do with diagnostics. Putting the Stormscope into cell or strike mode or turning it off don’t really affect the SS, they just change what the ICDS (or Sandel) do with the data stream from the SS.

After the EMM-35 is installed, it sits between the ICDS-2000 and the SS. I.e., the EMM-35 has two RS-232 channels, one to talk to the SS and one to the ICDS-2000. The EMM-35 receives the SS data stream, adds all the engine monitoring data, and spits out the combined data stream to the ICDS-2000. One implication of this is that if you pull the engine monitoring CB, you’ll loose SS data. The EMM-35 will also take commands destined for the SS from the ICDS-2000 and forward them to the SS.

The Sandel takes the same SS (or SS+Engine) data that the ICDS-2000 takes. It does this by simply listening in, so to speak, to the data stream. I.e., it is a passive RS-232 receiver of data on this channel and has no way to send commands to the Stormscope. This is why the stormscope diagnostic command in the Sandel has no effect – the Sandel’s RS-232 channel with the SS is in just one direction: to the Sandel.

One theory that the Sandel support guy and I have is that the EMM-35’s output, to which the Sandel listens, confuses the Sandel and so the Sandel gives up and puts the red line through the “WX”. The Sandel guy said that if the EMM-35 adheres to the standard protocol and extends it in a compatible way to add the engine monitoring information to the SS data stream, all should be well. But since the EMM-35 was made by Arnav and it requires a simultaneous update the the ICDS-2000, we can guess that those two boxes are speaking to each other in a format that suits them, but not the Sandel.

More wiring information: the RS-232 signal that comes from the EMM-35, to the ICDS-2000, and then goes to the Sandel, goes through a standard stereo 1/4" jack that is mounted just above the pilot’s right theigh just before it gets to the Sandel. This jack allows one to plug in a laptop (or other) computer to the plane in order to update the Sandel’s database. I saw the avionics guy at Cirrus do this just before I got my plane. So when there is plug in this jack, the data stream from the SS/EMM-35/ICDS-2000 is disconnected from the Sandel. No big deal, who needs lightning info when you’re updating the Sandel database? But it means that there is a convenient places to watch the RS-232 channel with SS data going to the Sandel. I put a meter on it today and saw characteristic voltages of an active RS-232 line. Given how close this connector is physically to the Sandel, and that there is just one connector between it and the Sandel, my guess is that the Sandel is receiving the data stream. And since the Sandel has the “WX” with red line, my guess is that it doesn’t like what it sees.

What would help me a lot is to hear from the other SR22 owners who have the EMM-35 and to find out if any have stormscopes and if so, whether they have the same problem as I do.

2

One theory that the Sandel support guy and I have is that the EMM-35’s output, to which the Sandel listens, confuses the Sandel and so the Sandel gives up and puts the red line through the “WX”

Sounds very likely to me - the fix should be easy - instead of splitting the EMM-35’s output to the ICDS2000 and the Sandel, instead split the output of the Stormscope so that the Sandel receives unadulterated SS data.

I’m puzzled as to why Arnav chose to go this route, since the ICDS2000 specs say it has seven (7!) RS-232 interfaces, so it should have been simple to just use one of the spares to interface the EMM. Also, the ICDS2000 has numerous digital and analog inputs that were clearly intended to connect directly to the thermocouples etc. but for some reason (probably the fact that the hardware doesn’t work as intended) they evidently did not use them, but designed an add-on hardware box instead.

3

I learned more about how the SR22’s avionics are wired and I’ll describe this…

Robert,

Bravo! I don’t have an SR22 or a Sandel, but your description makes perfect sense - I’m saving a copy in my “Forum Keepers” directory. What makes no sense is why it was wired this way in the first place.

I agree with Clyde – feeding the Sandel directly from the Stormscope should solve the problem.

  • Mike.
4

I can’t help myself: Jim, does this sound more like a Mac or PC to you?
Sounds like the worst of both worlds to me: complicated and inflexible.

Joe

I learned more about how the SR22’s avionics are wired and I’ll describe this after a request for all SR22 owners with the engine monitoring package:

Let me know who you are. I think there are four of us SR22/EMM-35 owners. I would like to know if your Sandel has a “WX” with a red line through it in the upper right corner of the Sandel.

Now for some information on the avionics:

The Stormscope emits its information on an RS-232 channel and receives commands via this same channel. The Stormscope has other interfaces, but the RS-232 port is the only one used in the SR22.

Before the addition of the EMM-35 (the box added for engine monitoring), the Stormscope was connected directly to the ICDS-2000, which both receives SS data and sends commands to the Stormscope over their RS-232 link. There aren’t any commands that have to be sent to do normal operations. The only commands I know of have to do with diagnostics. Putting the Stormscope into cell or strike mode or turning it off don’t really affect the SS, they just change what the ICDS (or Sandel) do with the data stream from the SS.

After the EMM-35 is installed, it sits between the ICDS-2000 and the SS. I.e., the EMM-35 has two RS-232 channels, one to talk to the SS and one to the ICDS-2000. The EMM-35 receives the SS data stream, adds all the engine monitoring data, and spits out the combined data stream to the ICDS-2000. One implication of this is that if you pull the engine monitoring CB, you’ll loose SS data. The EMM-35 will also take commands destined for the SS from the ICDS-2000 and forward them to the SS.

The Sandel takes the same SS (or SS+Engine) data that the ICDS-2000 takes. It does this by simply listening in, so to speak, to the data stream. I.e., it is a passive RS-232 receiver of data on this channel and has no way to send commands to the Stormscope. This is why the stormscope diagnostic command in the Sandel has no effect – the Sandel’s RS-232 channel with the SS is in just one direction: to the Sandel.

One theory that the Sandel support guy and I have is that the EMM-35’s output, to which the Sandel listens, confuses the Sandel and so the Sandel gives up and puts the red line through the “WX”. The Sandel guy said that if the EMM-35 adheres to the standard protocol and extends it in a compatible way to add the engine monitoring information to the SS data stream, all should be well. But since the EMM-35 was made by Arnav and it requires a simultaneous update the the ICDS-2000, we can guess that those two boxes are speaking to each other in a format that suits them, but not the Sandel.

More wiring information: the RS-232 signal that comes from the EMM-35, to the ICDS-2000, and then goes to the Sandel, goes through a standard stereo 1/4" jack that is mounted just above the pilot’s right theigh just before it gets to the Sandel. This jack allows one to plug in a laptop (or other) computer to the plane in order to update the Sandel’s database. I saw the avionics guy at Cirrus do this just before I got my plane. So when there is plug in this jack, the data stream from the SS/EMM-35/ICDS-2000 is disconnected from the Sandel. No big deal, who needs lightning info when you’re updating the Sandel database? But it means that there is a convenient places to watch the RS-232 channel with SS data going to the Sandel. I put a meter on it today and saw characteristic voltages of an active RS-232 line. Given how close this connector is physically to the Sandel, and that there is just one connector between it and the Sandel, my guess is that the Sandel is receiving the data stream. And since the Sandel has the “WX” with red line, my guess is that it doesn’t like what it sees.

What would help me a lot is to hear from the other SR22 owners who have the EMM-35 and to find out if any have stormscopes and if so, whether they have the same problem as I do.

5

One theory that the Sandel support guy and I have is that the EMM-35’s output, to which the Sandel listens, confuses the Sandel and so the Sandel gives up and puts the red line through the “WX”. The Sandel guy said that if the EMM-35 adheres to the standard protocol and extends it in a compatible way to add the engine monitoring information to the SS data stream, all should be well. But since the EMM-35 was made by Arnav and it requires a simultaneous update the the ICDS-2000, we can guess that those two boxes are speaking to each other in a format that suits them, but not the Sandel.

I can add a tidbit which might also lend credence to this theory –

When trying to figure out why the stormscope no longer showed up on the Arnav after enigne monitoring was installed in my SR20, I hooked up the stormscope back directly to the Arnav (i.e. took the EMM box out of the loop). And the Arnav still could not communicate with the stormscope.

So that means that the Arnav is now (post engine-monitoring) no longer able to accept JUST SS data, but can only accept this combo SS/EMM data on the RS232 port.

This doesn’t PROVE that the datastream of SS/EMM is significantly different/incompatible with the put SS datastream, but indicates that it might be.

It DOES indicate that if, for whatever reason, later on you want to remove the engine monitoring feature, you will not be able to use the stormscope on the Arnav unless you up- or down-grade your Arnav software to a version not expecting the EMM data.

Steve

6

Here’s an immodest daydream: we need an “open architecture” for the ARNAV. Since the software is so easily accessible on a data card, it might not be that hard to “disassemble” the code. This might allow adventurous and technically-minded owners to do things like change checklists, fix database mistakes, and possibly even add features. With a decent open architecture, interfacing a new instrument and displaying it in a new window would not be all that hard. Of course it’s illegal, so none of us will ever do it. But the ARNAV is “just for reference” anyway, right?

Sounds very likely to me - the fix should be easy - instead of splitting the EMM-35’s output to the ICDS2000 and the Sandel, instead split the output of the Stormscope so that the Sandel receives unadulterated SS data.

I’m puzzled as to why Arnav chose to go this route, since the ICDS2000 specs say it has seven (7!) RS-232 interfaces, so it should have been simple to just use one of the spares to interface the EMM. Also, the ICDS2000 has numerous digital and analog inputs that were clearly intended to connect directly to the thermocouples etc. but for some reason (probably the fact that the hardware doesn’t work as intended) they evidently did not use them, but designed an add-on hardware box instead.

7

Here’s an immodest daydream: we need an “open architecture” for the ARNAV. Since the software is so easily accessible on a data card, it might not be that hard to “disassemble” the code. This might allow adventurous and technically-minded owners to do things like change checklists, fix database mistakes, and possibly even add features. With a decent open architecture, interfacing a new instrument and displaying it in a new window would not be all that hard. Of course it’s illegal, so none of us will ever do it. But the ARNAV is “just for reference” anyway, right?

Gary,

The thought has crossed my mind before! :slight_smile: Unfortunately, it does not seem like a simple proposition. Having no idea what the data format is on the datacard means that it would probably take a while just to “find” the executable code, i.e. differentiate it from the Jepp data, performance chart data, etc.

Even after you find it, wading through tons of disassembled x86 assembly language to try to improve things is not my idea of a good time.

Now, what we need is a “Jeff” equivalent (i.e. disgruntled Arnav employee) to leak the source code! :slight_smile:

Seriously, though, I think it would be a pretty mammoth undertaking to do something like this without the backing (i.e. assistance, docs, etc.) of the manufacturer.

This leads me to another question. The MX20 “datasheet” on the Apollo web site mentions the following:

  • Open Software Architecture

  • PC-104/PC-104L expansion bus

among other points. (PC/104 is a common form factor for embedded computers – electrically it’s just the ISA bus (and possibly PCI bus), but physically it’s in a smaller, more vibration resistant form factor than the typical desktop PC.)

So does this mean that any old user could slap on a commercially available PC/104 peripheral card, and then write the driver & code for said card, and all of a sudden you can access that card through the MX20?

(i.e. Does Apollo provide documentation for interfacing to their MX20 menus and display?)

Thanks!

Steve

8

Open source so you can modify the code??

Yeah, I’m sure the FAA would be THRILLED with that idea. In an experimental…

9

Now we’re talking! An “open architecture” for avionics display platforms might do wonders for the business. Look what it did for computers. (Remember when Thomas Watson of IBM estimated that the worldwide market for computers would be about five. He was right, for the IBM architecture of the day.) This might be what it takes to achieve Cirrus’s original vision of the MFD as the expansion platform.

The thought has crossed my mind before! :slight_smile: Unfortunately, it does not seem like a simple proposition. Having no idea what the data format is on the datacard means that it would probably take a while just to “find” the executable code, i.e. differentiate it from the Jepp data, performance chart data, etc.

Even after you find it, wading through tons of disassembled x86 assembly language to try to improve things is not my idea of a good time.

Now, what we need is a “Jeff” equivalent (i.e. disgruntled Arnav employee) to leak the source code! :slight_smile:

Seriously, though, I think it would be a pretty mammoth undertaking to do something like this without the backing (i.e. assistance, docs, etc.) of the manufacturer.

This leads me to another question. The MX20 “datasheet” on the Apollo web site mentions the following:

  • Open Software Architecture
  • PC-104/PC-104L expansion bus

among other points. (PC/104 is a common form factor for embedded computers – electrically it’s just the ISA bus (and possibly PCI bus), but physically it’s in a smaller, more vibration resistant form factor than the typical desktop PC.)

So does this mean that any old user could slap on a commercially available PC/104 peripheral card, and then write the driver & code for said card, and all of a sudden you can access that card through the MX20?

(i.e. Does Apollo provide documentation for interfacing to their MX20 menus and display?)

Thanks!

Steve

10

Actually, from reading the data sheets, the ICDS2000 hardware is fairly impressive for the era that it was designed in. It is still a reasonable display and horsepower for the type of activities we’d need in a MFD/PFD.

I wonder if this was OEMed equipment or something they developed? My bet is that it is OEM (PC development is a serious pain in the ass, having been there, there are many outsource shops to get this stuff done). It seems to be a 200mhz ruggedized PC with a lot of additional A-D converters and serial inputs.

I’d bet that the PCCARD looks pretty much like either a standard hard disk, or like a big floppy, and you might even be able to stick it in your laptop and mount the darn thing.

You could probably write your own software for the thing from scratch. Maybe play a good game of Adventure in the sky?

That said, I do not want to trivialize the software effort that ARNAV has put into this thing. You do NOT want to try to reinvent the wheel unless you’re willing to put the time and resources into it to build one of these from scratch.

Paul

p.s. Did everyone else also notice that ARNAV has announced a PFD display as well? I didn’t see any mention of HITS support, but dang, if they are interested in prioritizing their software development to focus on the Cirrus realm, that could be very nice.

Sigh, in all honesty, I’d like to simply buy ARNAV, Sierra flight systems, and Avidyne and take the best from each.

11

Actually, from reading the data sheets, the ICDS2000 hardware is fairly impressive for the era that it was designed in. It is still a reasonable display and horsepower for the type of activities we’d need in a MFD/PFD.

I wonder if this was OEMed equipment or something they developed? My bet is that it is OEM (PC development is a serious pain in the ass, having been there, there are many outsource shops to get this stuff done). It seems to be a 200mhz ruggedized PC with a lot of additional A-D converters and serial inputs.

I’d bet that the PCCARD looks pretty much like either a standard hard disk, or like a big floppy, and you might even be able to stick it in your laptop and mount the darn thing.

You could probably write your own software for the thing from scratch. Maybe play a good game of Adventure in the sky?

That said, I do not want to trivialize the software effort that ARNAV has put into this thing. You do NOT want to try to reinvent the wheel unless you’re willing to put the time and resources into it to build one of these from scratch.

Paul

p.s. Did everyone else also notice that ARNAV has announced a PFD display as well? I didn’t see any mention of HITS support, but dang, if they are interested in prioritizing their software development to focus on the Cirrus realm, that could be very nice.

Sigh, in all honesty, I’d like to simply buy ARNAV, Sierra flight systems, and Avidyne and take the best from each.

Pfeeewhhhhhhhhh guys!.. The amount of write ups about the Arnav is approaching the Encyclopedia Britannica on my shelf.

Marty had a lot of hard work put into the engine monitoring system and his encounters with Arnav technicians. Bob, Steve and Paul are right up there with the pioneers, trying to find and conquer the riddles of the ICDS2000.

I read about Trimble conking out on us, then Garmin stepping in. I have heard hymns sung about the UPS boxes, and some of the others available out there.

My wish would be as follows:

may the powers to be grant a flash of wisdom to the decision makers at Garmin and let them design an almighty MFD that would encompass ALL of their systems. I think that a Garmin MFD, a 530 and a backup 430 with all the other Garmin in the stack would be the best there is. Now if Garmin would also have a “GEM” or “JPI” graphic capability on this MFD, we would have the ultimate panel! With the NASA Future Vison in the Sky in the not too distant future, Garmin MUST be making some pretty futuristic stuff. I wish we would have a “glue dude” there with some info coming our way.

AND…I almost forgot in my wish list: I hope that Cirrus would finally abandon Arnav, and would go with an all Garmin suite.

12

Actually, from reading the data sheets, the ICDS2000 hardware is fairly impressive for the era that it was designed in. It is still a reasonable display and horsepower for the type of activities we’d need in a MFD/PFD.

I wonder if this was OEMed equipment or something they developed? My bet is that it is OEM (PC development is a serious pain in the ass, having been there, there are many outsource shops to get this stuff done). It seems to be a 200mhz ruggedized PC with a lot of additional A-D converters and serial inputs.

I’d bet that the PCCARD looks pretty much like either a standard hard disk, or like a big floppy, and you might even be able to stick it in your laptop and mount the darn thing.

You could probably write your own software for the thing from scratch. Maybe play a good game of Adventure in the sky?

That said, I do not want to trivialize the software effort that ARNAV has put into this thing. You do NOT want to try to reinvent the wheel unless you’re willing to put the time and resources into it to build one of these from scratch.

Paul

p.s. Did everyone else also notice that ARNAV has announced a PFD display as well? I didn’t see any mention of HITS support, but dang, if they are interested in prioritizing their software development to focus on the Cirrus realm, that could be very nice.

Sigh, in all honesty, I’d like to simply buy ARNAV, Sierra flight systems, and Avidyne and take the best from each.

Pfeeewhhhhhhhhh guys!.. The amount of write ups about the Arnav is approaching the Encyclopedia Britannica on my shelf.

Marty had a lot of hard work put into the engine monitoring system and his encounters with Arnav technicians. Bob, Steve and Paul are right up there with the pioneers, trying to find and conquer the riddles of the ICDS2000.

I read about Trimble conking out on us, then Garmin stepping in. I have heard hymns sung about the UPS boxes, and some of the others available out there.

My wish would be as follows:

may the powers to be grant a flash of wisdom to the decision makers at Garmin and let them design an almighty MFD that would encompass ALL of their systems. I think that a Garmin MFD, a 530 and a backup 430 with all the other Garmin in the stack would be the best there is. Now if Garmin would also have a “GEM” or “JPI” graphic capability on this MFD, we would have the ultimate panel! With the NASA Future Vison in the Sky in the not too distant future, Garmin MUST be making some pretty futuristic stuff. I wish we would have a “glue dude” there with some info coming our way.

AND…I almost forgot in my wish list: I hope that Cirrus would finally abandon Arnav, and would go with an all Garmin suite.

I may have missed something at the beginning of this thread, but I would think that Cirrus would have ALL of the answers to the original questions about Sandel/stormscope operation and general wiring architecture since it is factory installed on SR22’s(correct?) Are we going through these excercises so we don’t have to call Cirrus’ tech support, i.e. why does Cirrus seem to be out of the loop in this discussion of a factory installed option? Just looking for a straighter line to the answer of these questions.

Paul

13

At the time, the engine monitor was not a factory installed option. In fact, as far as I know, the STC has not yet been issued. We have heard it will be a factory installed option this fall.

14

I can’t help myself: Jim, does this sound more like a Mac or PC to you?
Sounds like the worst of both worlds to me: complicated and inflexible.
Joe
Joe,
Complicated? Go “under the hood” of anything (even a Mac), and you’ll find this stuff. Like anything else, to those who don’t work with it, its complicated. If I gave a technical description of the inner workings of my simple-to-operate-yet-utterly-reliable Infiniti automobile, that would be complicated, too.
Inflexible - agreed 100% relative to this one issue. Sounds like this aspect of the avionics wiring could have been better thought out. But the majority of the avionics in the airplane, and most aspects of the airplane itself, have been thought through very well indeed, IMHO. That’s why I bought it. [Also - this wiring just doesn’t taste as though it was designed by Cirrus. I’ll bet it wasn’t.]

  • Mike.
15

Complicated? Go “under the hood” of anything (even a Mac), and you’ll find this stuff. Like anything else, to those who don’t work with it, its complicated. If I gave a technical description of the inner workings of my simple-to-operate-yet-utterly-reliable Infiniti automobile, that would be complicated, too.
I agree, but some have argued here that Cirrus is marketing to a whole new and untapped segment of potential aviation enthusiasts who have been heretofore put off precisely by having to go under the hood in other airplanes. They want, the argument goes, Mac-like simplicity and functionality without having to read (much less write) posts like Robert’s above.
Inflexible - agreed 100% relative to this one issue. Sounds like this aspect of the avionics wiring could have been better thought out. But the majority of the avionics in the airplane, and most aspects of the airplane itself, have been thought through very well indeed, IMHO.
In most respects, but even this “clean sheet” is still unable to prevent a certain amount of messiness from creeping in. Like deciding what to display where among units with overlapping capabilities. Robert’s post is a perfect example. But there are some glaring exceptions. How’s this: The Arnav is absolutely integral to the aircraft’s philsophy and certification (according to Cirrus), to the point where no alternatives are offered. Yet, if the #1 GPS dies, your’re pretty much out of luck as far as Arnav situational awareness is concerned. There is no provision for the #2 GPS to drive it (at least there wasn’t in the early GNS430/GPS250 setup). How hard could that be to arrange?
That’s why I bought it. [Also - this wiring just doesn’t taste as though it was designed by Cirrus. I’ll bet it wasn’t.]

Probably not, but if Cirrus is hanging its hat on user-friendliness they had better insist that its suppliers get with it.

Joe

16

Joe,
Good points, all. In the spirit of friendly discussion, counterpoints below.
Mike.

Complicated? Go “under the hood” of anything (even a Mac), and you’ll find this stuff. Like anything else, to those who don’t work with it, its complicated. If I gave a technical description of the inner workings of my simple-to-operate-yet-utterly-reliable Infiniti automobile, that would be complicated, too.

I agree, but some have argued here that Cirrus is marketing to a whole new and untapped segment of potential aviation enthusiasts who have been heretofore put off precisely by having to go under the hood in other airplanes. They want, the argument goes, Mac-like simplicity and functionality without having to read (much less write) posts like Robert’s above.

Yes, to a point. In this case, I don’t believe that the particular problem that gave rise to this discussion was of Cirrus’ making. That said, it’s also true that the rest isn’t perfect either (nothing’s perfect). It’s also true that Mac-like simplicity is achieved through the innovation and dogged tenacity of technically oriented dreamers, like the Klaps; but also like some of the customers, who buy the airplane and can’t help but be intrigued by the work that’s been done already, and add their comments, suggestions and critique. This is what you’re seeing at work here.

Inflexible - agreed 100% relative to this one issue. Sounds like this aspect of the avionics wiring could have been better thought out. But the majority of the avionics in the airplane, and most aspects of the airplane itself, have been thought through very well indeed, IMHO.

In most respects, but even this “clean sheet” is still unable to prevent a certain amount of messiness from creeping in. Like deciding what to display where among units with overlapping capabilities. Robert’s post is a perfect example. But there are some glaring exceptions. How’s this: The Arnav is absolutely integral to the aircraft’s philsophy and certification (according to Cirrus), to the point where no alternatives are offered. Yet, if the #1 GPS dies, your’re pretty much out of luck as far as Arnav situational awareness is concerned. There is no provision for the #2 GPS to drive it (at least there wasn’t in the early GNS430/GPS250 setup). How hard could that be to arrange?

No argument. Let’s agree that it’s good, but it could be improved. I think we can also agree that such is the condition of almost all technology. This Forum is one of the lubricants of the machinery of improvement.

That’s why I bought it. [Also - this wiring just doesn’t taste as though it was designed by Cirrus. I’ll bet it wasn’t.]

Probably not, but if Cirrus is hanging its hat on user-friendliness they had better insist that its suppliers get with it.

101% agreed.

Joe

  • Mike.
17

Good points all, too. It must be frustrating to try to meld together all this super gear, a lot of it overlapping.
Joe

Joe,

Good points, all. In the spirit of friendly discussion, counterpoints below.

Mike.

Complicated? Go “under the hood” of anything (even a Mac), and you’ll find this stuff. Like anything else, to those who don’t work with it, its complicated. If I gave a technical description of the inner workings of my simple-to-operate-yet-utterly-reliable Infiniti automobile, that would be complicated, too.

I agree, but some have argued here that Cirrus is marketing to a whole new and untapped segment of potential aviation enthusiasts who have been heretofore put off precisely by having to go under the hood in other airplanes. They want, the argument goes, Mac-like simplicity and functionality without having to read (much less write) posts like Robert’s above.

Yes, to a point. In this case, I don’t believe that the particular problem that gave rise to this discussion was of Cirrus’ making. That said, it’s also true that the rest isn’t perfect either (nothing’s perfect). It’s also true that Mac-like simplicity is achieved through the innovation and dogged tenacity of technically oriented dreamers, like the Klaps; but also like some of the customers, who buy the airplane and can’t help but be intrigued by the work that’s been done already, and add their comments, suggestions and critique. This is what you’re seeing at work here.

Inflexible - agreed 100% relative to this one issue. Sounds like this aspect of the avionics wiring could have been better thought out. But the majority of the avionics in the airplane, and most aspects of the airplane itself, have been thought through very well indeed, IMHO.

In most respects, but even this “clean sheet” is still unable to prevent a certain amount of messiness from creeping in. Like deciding what to display where among units with overlapping capabilities. Robert’s post is a perfect example. But there are some glaring exceptions. How’s this: The Arnav is absolutely integral to the aircraft’s philsophy and certification (according to Cirrus), to the point where no alternatives are offered. Yet, if the #1 GPS dies, your’re pretty much out of luck as far as Arnav situational awareness is concerned. There is no provision for the #2 GPS to drive it (at least there wasn’t in the early GNS430/GPS250 setup). How hard could that be to arrange?

No argument. Let’s agree that it’s good, but it could be improved. I think we can also agree that such is the condition of almost all technology. This Forum is one of the lubricants of the machinery of improvement.

That’s why I bought it. [Also - this wiring just doesn’t taste as though it was designed by Cirrus. I’ll bet it wasn’t.]

Probably not, but if Cirrus is hanging its hat on user-friendliness they had better insist that its suppliers get with it.

101% agreed.

Joe

  • Mike.
18

It DOES indicate that if, for whatever reason, later on you want to remove the engine monitoring feature, you will not be able to use the stormscope on the Arnav unless you up- or down-grade your Arnav software to a version not expecting the EMM data.

I have been informed that my earlier statement above is false. There is apparently a setting on the Arnav which can be changed to allow the stormscope to be connected directly to it again, if you wish to bypass the EMM box for whatever reason, without having to change the software version.

I had not tried changing this setting (as I didn’t know about it) when performing the experiment I described above.

My apologies for the error!

Steve