Triacom

[Dave Zug]

....Add a dip switch selectable single raw output to display 3 digits on the
interface cable itself. Allow the 3 digit display to be remotely located on
the end of a ribbon. offer plug in processors for different streams, or even
plug in 1k PROM for the config data.. Expand the interface to collect the
data and store to ram (like a black box kinda) then have a pushbutton dump
the data to the cable end, which when connected to a PC will download the
data at 9600 or something.  makes you NOT have to own a laptop, everyone's
got a PC... also lets you view ONE raw data item (o2 commonly) , and drive
and constantly log data, rolling old data out FIFO. when theres a car
problem, simply stop the recording (freeze button) and take the black box
into the house. use cheap IDE hard drives for memories and record zegabytes
of data - hey theres the name - "the zegabyte" ha haa.

Patent it first (too late oops) and then sell to GM so they can put it in
all their cars, for diagnosing mechanics use.  it doesnt really matter if
its very useful (but it is)  - if they market it and they are first, public
will shift their "votes" and other car companies will follow.

we can make things better than a dia-thingy... the difference between most
of us and them is they actually did it, and we're still poor :-(

I'm sure the "monitoring" community at least thunk a little about the black
box - guess we'll see it marketed in a few months and I'll be balling my
eyes out... again ;-)

Yes I have this black box device's ASM code and test board "started" (using
ram, not HDD) - years ago.  no I'll probably never actually finish it. :-(

okay I havent babbled for a while.. it was ECM related though!


----- Original Message -----
From: Craig Moates <craigmoates at home.com>
To: <gmecm at efi332.eng.ohio-state.edu>
Sent: Tuesday, November 30, 1999 5:16 PM
Subject: Triacom


> Noble goal:
>
> Create PC code, independent of existing software, which utilizes the
> parallel interface to communicate with the ECM. This would rationally
> justify the existence of supporting hardware. Hey, the software could be
set
> up to support parallel and serial. I'm sure there could be all kinds of
> desired functionality added, particularly if it was made open-source
public
> domain. Who knows, while no profits would roll in, it might be fun as a
> bonus. It would certainly exceed the utility of commercially available
> products.
>
> If the protocol happened to be similar to existing systems, I guess one
> would have to steer clear of infringement on that account. Patent search
> might be in order. Who knows, maybe existing commercial cables could come
in
> handy for the new generation of Comm software in the 3rd millenium? (only
a
> few days left)
>
> As for building a piece of hardware which supports only copyrighted
> software, the intent is pretty clear if the builder does not own the
> software. This is my only comment on it. Heck, I was a pirate at a very
> young age: no judgement here. Just don't see the benefit of using
bandwidth
> without a cause. Thus, this is my only injection (no pun intended) to the
> issue.
>
> -Craig
>
>
>