[simpits-tech] Marv: driving DBQ gauges??

[Marv De Beque]

Well, my observation is that it is easy to be overly concerned about issues
that may not be real issues, but our motive is to select the path of least
resistance.

I know one of my reasons for selecting the EPIC system was that there was
probably a large support base to draw from.

Knowing what I know now I might reconsider that selection.  The road blocks
that I have found for EPIC is the cost (which I now have already invested)
and the need to use a custom compiler and programming language (that is not
as powerful as C, at least not quite yet).

Longer term it would seem to be better to use a standard C compiler on a
standard hardware platform (PC) that has already had most of the bugs sorted
out.

Nevertheless, I have the investment in EPIC and I will probably continue
with it.

To the original point of using EPIC to drive gauges, I would probably advise
against it.  Although the Phidget Servo USB board might be a new learning
curve, I think it will not be too steep.  That, and you do not need to debug
hardware and its interface.  That has already been done with the USB board.

Additionally, you can still use EPIC and the Phidget Servo board at the same
time.  That could be the best of both worlds.  That is what I plan to do.

However, if you do design your own hardware for teh EPIC to drive servos,
please keep us informed!
-- 


> From: "Mark Doran" <msdoran@attbi.com>
> Reply-To: simpits-tech@simpits.org
> Date: Wed, 4 Sep 2002 17:42:36 -0700
> To: <simpits-tech@simpits.org>
> Subject: RE: [simpits-tech] Marv: driving DBQ gauges??
> 
> Yikes!  Ask a simple question, get a lecture :)
> 
> I have responses for your points; we spent some time in considered
> research before committing to an approach.  I'm not sure it's useful to
> debate you here though.  I'm almost sorry I responded at all when you
> asked why we chose EPIC -- I wasn't looking for a drubbing or to provoke
> a reaction.
> 
> Please understand that I certainly didn't mean to imply anything other
> than phidgets don't make sense for *us* in *our* project context and
> "cost" model...everyone else must make their own conclusions based on
> their context.  I have no intent or motivation to promote EPIC over any
> other solution to anyone else.  If my comments gave offense, I'm sorry.
> 
> Obviously your conclusions and our conclusions are at odds for our
> various reasons.  If you do want to hear more about our thinking, I
> believe I live locally to you (somewhat: OLM) so perhaps offline over a
> beverage or two would be the best way :).
> 
> I'll offer one observation in general that I think is germane based on
> being a relatively silent observer here for the last couple of years:
> 
> I think integration of components from multiple engineering disciplines
> is *the* most underestimated problem that the home cockpit builder
> faces.  Throwing time at it is an approach but throwing money as
> well/instead might in fact be necessary to succeed in the end.  Everyone
> has their own trade-off on that scale based on the
> cash/time-availability and "pressure to ever finish one of these things"
> ratios.
> 
> Cheers,
> 
> Mark.
> 
> 
> -----Original Message-----
> From: simpits-tech-admin@simpits.org
> [mailto:simpits-tech-admin@simpits.org] On Behalf Of Gene Buckle
> Sent: Wednesday, September 04, 2002 12:40 PM
> To: simpits-tech@simpits.org
> Subject: Re: [simpits-tech] Marv: driving DBQ gauges??
> 
>> EPIC ties together inputs/outputs and transducers of
>> various sorts together in ways that would only be
>> possible with phidgets by writing code for the phidgets
>> that replicates much of what EPIC EPL does already.
>> 
> This doesn't make any sense to me.  EPL doesn't provide anything special
> that can't be done with the same ease in another environment.
> 
>> Our analysis is that the extra
>> coding/testing/integration work involved in using
>> phidgets far outweighs any initial cost saving you
>> might realize in buying hardware.
>> 
> I think the word I'm looking for here is "poppycock". :)
> 
> Starting from a pure input standpoint, you're already $350 ahead with
> the
> 255 input Phidget. (They're $50).  With EPIC, you have to write programs
> for EPIC in EPL as well as for the PC.  With Phidgets, you only write on
> the PC.  An EPL/PC solution is _more_ expensive to deal with, especially
> when looking at the total cost to build a solution.
> 
> I own both the ISA and USB EPIC boards as well as a host of their
> peripheral boards.  I also work with some of the Phidgets that are
> available.  There is _no_ way you're going to tell me (or anyone else
> that
> can think) that a total EPIC solution is cheaper than the same solution
> implemented in Phidgets.  (ok, technically it's possible, but it
> involves
> hiring a prima-donna programmer that's charging FAR more than he's
> worth)
> 
> 
> 
>> Tight integration is important because Falcon4 SP3, our
>> software of (no- ;) choice at present, has some serious
>> gaps in the way analogs, button inputs, lamp outputs
>> and shared memory data are managed.  These gaps require
>> some "papering" over with code bound to the
>> simulator...that's harder to do if your various I/O
>> systems are not controlled from the same code (or code
>> that at the least has other means to share "event"
>> handling).
> 
> You'll maintain two code bases (EPL and host pc) with EPIC, and one
> codebase with Phidgets.  You're not losing any "integration" by using a
> Phidget.  If someone is telling this, they're blowing smoke up your
> butt.
> 
> BTW, Falcon is a _very_ poor example.  It's shared memory area is a
> kludge
> at best.  If you _must_ use Falcon, download the source code (it's still
> floating around out there) and implement *correct* interfacing support.
> 
> BTW, Both Battle of Britain and MiG Alley from Rowan Software have been
> released in source form so they'd both be great candidates for adding
> cockpit integration routines to support both Phidget and EPIC solutions.
> 
> 
> 
>> Hence my question of Marv (or anyone else
> ;)...has > anyone already thought about how to hook servos up to
>> an EPIC??
>> 
> Grab a PhidgetServo.  Add the code to your existing host pc code.  Done.
> Hell, Robert Favre could add phidget support to his MFD program in
> seconds and for that matter so could you.  It already talk to Falcon4
> and
> is freely downloadable from the ftp site.
> 
> g.
> 
> 
> 
> _______________________________________________
> Simpits-tech mailing list
> Simpits-tech@simpits.org
> http://www.simpits.org/mailman/listinfo/simpits-tech
> To unsubscribe, please see the instructions at the bottom of the above
> page.  Thanks!
> 
> _______________________________________________
> Simpits-tech mailing list
> Simpits-tech@simpits.org
> http://www.simpits.org/mailman/listinfo/simpits-tech
> To unsubscribe, please see the instructions at the bottom of the above page.
> Thanks!