OK-

Just wanted to start a roll-call thread... and maybe have some suggestions as for a meeting place on the web to through all our stuff =)

late
~wrx300

Originally posted by WRX300
OK-

Just wanted to start a roll-call thread... and maybe have some suggestions as for a meeting place on the web to through all our stuff =)

late
~wrx300

eh?

whats the plan here?
some group project?

any lone developer should be able to cook up a VB or Java GUI for the sucker pretty quick.

Id do it if I was getting paid

or for a free UTEC


=)

this is pointless

UTEC>

SORRY probably shouldnt have put GUI to each his own... im all about a shell

~wrx300

ok.. for every 100 posts you owe me a royalty on the "call to arms!!!" name ;)

Jorge (RiftsWRX)
www.ProjectWRX.com

data logging would greatly benefit from a gui
as it is now I would feel compelled to import the data to excel

something that SHOULD be left as an option if a GUI was developed of course.

and a gui would make tuning much much easier

dragging around points on a graph is more fun than typing numbers in a billion cells

Originally posted by jmott


Id do it if I was getting paid

or for a free UTEC


=)

Me too! TurboXS do you hear me!?!?!?!?:lol:

Originally posted by jmott

Id do it if I was getting paid
or for a free UTEC
=)

i know you're joking, but that's a selfish additude. someone will come along and do it without asking for money, and it will be much appreciated. someone needs to create the first version of a shell that can be improved upon, however.

What's wrong with being selfish? We all want to make some money in this world. ;)

Over on the other side of the fence, Rich and I have already begun work on this project. Send either of us your feature ideas and suggestions and we'll get it all organized. Rich's I-Club name is 'digitaltekniq'. We will probably eventually setup a web site for the project and make it all a little more formal. I know it will be .Net, but we're undecided on C# vs. VB. I want to go VB, and he wants C#. I guess we'll just have to box it out. :lol: If you haven't used VB in VS.NET yet, it's pure joy. It's by far the best IDE I've ever used.

Drop me a line if you want to get involved. No, we're not going to pay anything. :p

JD

Oh yeah we're designing this thing in the standard nTier style. So throwing a GUI on it vs. creating a console app will be trivial once we have the data abstraction layer done.

JD

I would try to do it in vb not vb.net that way people dont have to dl and install the entire .net framework if they are using win9x or win3k. Just a thought.

Hell do it in perl if your l33t nuff. If turboxs will send me a test model ill do up a perl or vb interface.

Other wise ill just stick to hacking the tec2 software :)

You don't have to worry about re-dist any more than you did with VBRUN based applications.

In any case, win16 based clients will have a hard time with any application these days - and .NET wont run on anything as a client under Win98. If you can implement something for people on this OS then please let us know, we can share learnings and techniques.

Like JD said - re-use in a console application would be simple to produce - the majority of the effort involved is parsing the command args.

Cheers

Rich

:lol: ... I love how people are taking something thats portable ... and making it not portable ... thats an improvement.

stick with the telnet guys ... develop your own guis for playback

im just gonna work on a open source shell... cause thats where the portability lies.. and besides im sick of everything running in windows only

Ya'll hear that?


We're usin' code names.


May, you tekki types are scary with your "IT code".


More power to ya'! Thanks for stepping in to try to make this easier for the masses. Have some fun along the way.

I do this kind of thing every day for a living, it's called 'Legacy Extension', and it's my specialty. I take terminal-based (VT100, TN3270, whatever) applications, either UNIX or Mainframe, and make them talk COM, CORBA, or SOAP. At that point, developing a GUI front end for the application, or integrating it with other applications, becomes a trivial matter. There are specialized tools available on the market that allow you to quickly develop a GUI front-end to a terminal application, but they are very expensive. There are also tools that will allow VB, C, or Java to 'screen scrape' VT100 and other terminals quite easily, but are also somewhat expensive and not as good as the stand-alone tools. Other options are using scripting languages built into some good commercial terminal emulators. While this might make the process of mapping, logging, reloading maps easier, the final result would hardly be a replacement for a full fledged GUI. Writing an app without the specialized tools to help 'screen scrape'? Sure, it's doable, I've done it when the tools available didn't allow for VT100 scraping. Is it hard? No, just tedious, but certainly doable. I volunteered to help out when I first saw that the UTEC was using a VT100 terminal interface.

jb

Isn't that exactly what they are doing? I think all anyone is wanting to do is build a GUI front-end to the telnet interface.

Also, the only gain I see from a GUI is on the data logging side. For generating the maps, give me the pure text version ANY DAY. However, some nice GUI windows for individual data lines would be nice. I'd say the way to go is build the ground layer (customized serial wrappers specifically for the UTEC) and let the individual choose their requirements from there. Then the non tech types could pick and choose from those that give theirs out.

The fact that all of this is non-profit should subside all criticism IMO.

VV

Originally posted by JenisonWRX
:lol: ... I love how people are taking something thats portable ... and making it not portable ... thats an improvement.

stick with the telnet guys ... develop your own guis for playback

Sheese. Why don't the people making the VTEC just put a web server on the chip along with a IP implementation and an Ethernet port. The thing would have a 10 address (like 10.0.0.3) or similar. Then you plug a cat 5 cable into the board and the other end into your ethernet port on your laptop (use a crossover cable). Then you browse to the 10 address and use either IIS or Netscape to configure the VTEC. The user doesn't have to have any special client software on the PC. If you think this sounds a little crazy, it is this sort of thing that is going on with a lot of devices including cell phones. My nextel phone as an IP address and you can download java applications onto the phone. It's not browser based on the cell phone, but the idea is the same. Shoot, put a bluetooth interface on the thing.

Note that if it can communicate via RS232 (I'm guessing here) then as an alternative, you might get the manufacturer to replace that with an ethernet port and/or some sort of bluetooth interface. Then you put the micro-unix kernel on the chip. Note that since this thing is a computer already, it is running some sort of OS and it very well may be linux/unix based or WinCe.....

im very, very confused. :o

Originally posted by tolnep
Sheese. Why don't the people making the VTEC just put a web server on the chip along with a IP implementation and an Ethernet port. The thing would have a 10 address (like 10.0.0.3) or similar. Then you plug a cat 5 cable into the board and the other end into your ethernet port on your laptop (use a crossover cable). Then you browse to the 10 address and use either IIS or Netscape to configure the VTEC. The user doesn't have to have any special client software on the PC. If you think this sounds a little crazy, it is this sort of thing that is going on with a lot of devices including cell phones. My nextel phone as an IP address and you can download java applications onto the phone. It's not browser based on the cell phone, but the idea is the same. Shoot, put a bluetooth interface on the thing.

Note that if it can communicate via RS232 (I'm guessing here) then as an alternative, you might get the manufacturer to replace that with an ethernet port and/or some sort of bluetooth interface. Then you put the micro-unix kernel on the chip. Note that since this thing is a computer already, it is running some sort of OS and it very well may be linux/unix based or WinCe.....

The ecm's name is UTEC, we're talking Subarus not Hondas ;)

Bill

As a professional I honestly think you guys might be wasting your time reinventing the wheel with this. From what I have seen the console GUI seemed do the job just fine and you're just going to over complicate things and introduce bugs and problems into a very working interface.

Some of you guys are too much with the suggestions of running webservers. ethernet ports and bluetooth. Does this run Linux too?? ;) :lol:

Originally posted by eric m.


i know you're joking, but that's a selfish additude. someone will come along and do it without asking for money, and it will be much appreciated. someone needs to create the first version of a shell that can be improved upon, however.

im not joking
and since when is doing work for money selfish?
do you live in the woods?


:monkey:


if you monkeys want to do work for TurboXS for free go ahead. I have no problem with that.
I have better things to do with my time.

but don't call me selfish!

Guys guys guys!

Look, I personally - and I am not speaking for JD here, are doing this for a bit of fun, if you don't like the idea, that's cool - stick with what you're happy with. If people like the idea, and they like what the app does at the end of the day, wonderful - we've made someone happy.

As for the portability people out there - JD and myself are happier in an MS environment than a Linux environment, or a Mac environment. If someone else wants to write something for those OS's then, great - please go ahead, we will completely defer to them because we don't have the expertise in those OS's to produce a good quality application. We can share the core ideas though.

As for the "do it in Telnet/Hyperterminal/whatever" people - yes, we can do that, some of us like GUI's, and again, this is a bit of fun to build on top of the existing functionality of the VT100 based interface.

This seems to be generating more of an argument instead of an honest open discussion of tools which might make something which is already cool, more fun. Seems every thread goes this way on I-CLUB now. :confused:

Rich

I have no idea what yall are talking about:p

I can't offer programming skills just yet (I start school Full time in January at UMD for Computer Science), however I will offer my services as test platform since Jorge's ride is down for the count. Any info I can provide on the Utec (except for technical details of the inner workings, as I simply don't know) will be available. I currently connect to the Utec using a Win98SE platform. I personally, would love to have a better interface that resembled something like Delta Dash but obviously the possibilities are endless. Right now it looks more like I'm consoling into one of my routers @ work :lol:

Ryan

i agree...why are you taking something that works on all systems and making it useless to half of us?? :rolleyes:

on a sidenote...is there a way to interface with the UTEC using 802.11b?

thanks,
-Mike

Mike

We're not REPLACING anything - we're building a more GUI oriented interface on top of the existing VT100 terminal interface!

Once JD and I have got where we want to, we'll put it up for download, if you want it - use it, if you don't - well don't! :D

To drive the UTEC over 80211.b you will need some sort of permanent PC installation in your vehicle - with wake up on LAN enabled, and more than likely for simplicities sake, a remote desktop connection of some sort.

Rich

Edit: As an aside, I don't have the time nor resources to develop something for other OS's - if someone else wants to do this, please do, it's not a competition. ;)

Java!

=)
just write it once


Originally posted by digitaltekniq
Guys guys guys!

Look, I personally - and I am not speaking for JD here, are doing this for a bit of fun, if you don't like the idea, that's cool - stick with what you're happy with. If people like the idea, and they like what the app does at the end of the day, wonderful - we've made someone happy.

As for the portability people out there - JD and myself are happier in an MS environment than a Linux environment, or a Mac environment. If someone else wants to write something for those OS's then, great - please go ahead, we will completely defer to them because we don't have the expertise in those OS's to produce a good quality application. We can share the core ideas though.

As for the "do it in Telnet/Hyperterminal/whatever" people - yes, we can do that, some of us like GUI's, and again, this is a bit of fun to build on top of the existing functionality of the VT100 based interface.

This seems to be generating more of an argument instead of an honest open discussion of tools which might make something which is already cool, more fun. Seems every thread goes this way on I-CLUB now. :confused:

Rich

Originally posted by SleeperWRX
i agree...why are you taking something that works on all systems and making it useless to half of us?? :rolleyes:

on a sidenote...is there a way to interface with the UTEC using 802.11b?

thanks,
-Mike

they arent

they are adding a feature
that will work only in windows

you can still use the text interface

relax
=)

An idealistic view if I ever saw one - please don't tell me Java isn't vendor specific!

--Rich

Right :rolleyes:

write once, debug everywhere :(

VV

Originally posted by jmott
Java!

=)
just write it once

Here's the list of features as I see them, if you have ANYTHING to add, discuss/remove please email either JD or myself directly - or post it here.

- A dashboard page, with a more graphical display of the current
settings/values, have to look into how responsive this would
be based on 19.2k baud speed of the serial connection - think HKS CAMP or Skyline monitoring setup
- Mapping of voltage readings from UTEC for things like MAF, EGT to real world values (if you want)
- A log graphing function, based on user selectable params
- A map editing screen using things like range limited sliders for setting values
- Map creation limited only by disk space (only 5 loaded to UTEC at a time)
- Batch map uploads
- UTEC BIOS update facility
- Simple map switching from n number of maps currently available on the host system
- Password protection on maps
- Map packaging facility to email to other users
- For the wireless guys - remote tuning
- Webservice debugging of UTEC over internet (this is not that serious - we'll have to see if it's do-able)
- DANGER TO MANIFOLD warning message with complementary bag of rivets for floor panels to throw around

It's all pie in the sky at the moment, we'll know what's truly possible when we dig in deeper. I can only thank Pete and Co at TurboXS for being so open with their information, it's very helpful!

--Rich

Programming for free? No problem. But, it got to be some sort of open source license agreement, like GPL (General Public License). That way, no vendor will be legally to take advantage of our hard work without exposing their implementation.

For programming language, since we need to support Win98 and handle native data type, the C or C++ language with MFC/WTL will be the best bet.

Email me if we want to kick off this opened source project!

the reason to write a gui...

try looking at a text graph of a/f values compaired to a graphic version

yes command line is nice an portable ....
but you simply can't decode as much information as you can on a graphic screen
the cool thing is that it ALREADY has a portable command line why write another?

while typeing somthing like "map conf fuel 1 1 +125"
is fun/geek i can garantee that i can change more values with a mouse in a shorter time.. and i can see all the sourounding values at the same time


y'all should start a yahoo group and take the devloping off line as you will just get pointless newbie posts on the board :(


features that would be cool

auto tune map- displays a/f map .. as you drive and hit a certin section of the map the program changes the color of the grid to red (too lean) green (stoich[yeah i can't spell]) or yellow (too rich).. based upon values from the front a/f sensor and target a/f values that you set
(edit 2) or egt temps using stock sensor

i can't think of another ecu that woudl be capable of this sort of thing (intagrated wide band 02 tuning)

does this thing have a debug mode that only outputs raw data?

Originally posted by VetteVert
Right :rolleyes:

write once, debug everywhere :(

VV




I've been writing java apps for the last year, and while I have run into cases where something wont work on a different platform.

I have no doubt that you could write ONE java code base for a gui of this nature that would work fine on all of java's supported platforms.

writing once with a bit of debugging everywhere is still better than writing 5 times
=)

Originally posted by VetteVert
Right :rolleyes:

write once, debug everywhere :(

VV



My vote is for Java. Write once debug everywhere???? Thats better than write everywhere debug everywhere right? Java will work fine for Mac, Windows and Linux for what we are talking about with very little OS dependent debugging. I have written C++ and Java GUIs for about 7 years now. I am very interested in helping with this effort. When I get the money to buy one of these bad boys. I will create my own GUI if this effort goes nowhere.

yeah, definitely gotta have "danger to manifold" msg box. also, "stage 1 complete" "stage 2 complete"...lol....and maybe
"NAAAAAAAAAAAAAAAAAAAAAWWWS!"

now i have a reason to buy the UTEC and install your GUI. pure rice! sweet!

Originally posted by digitaltekniq
Here's the list of features as I see them, if you have ANYTHING to add, discuss/remove please email either JD or myself directly - or post it here.

- UTEC BIOS update facility

--Rich

Just so ya know, it comes with a seperate GUI for uploading the image, so you don't need to reinvent the wheel (unless you see this as being part of the "package"). Love the "Danger to Mainfold" option tho'....SWEET! :lol: Another thing about tuning with the Factory Wideband, remember, it's only good down to about 11.2:1, below that it's apparently saturated.


Ryan

I'll agree on the Java platform as well. I write Java apps for my company. We have a very complicated SNMP based element management system for our DSLAM (dsl stuff). Its very graphic and network intensive... yet I do one build on my win2k box and it runs perfectly on my Solaris 8 and Linux boxen. Never tested it on a mac, but I'm sure it will work.

Well writen java is great... a little memory intensive, but RAM is cheap!!!

Oh yeah, free software is great too... any of you ever hear of Linux ? :rolleyes:

Someone just needs to start a project on sourceforge.net and let everyone that has skillz contribute. For something like this project, open source rules.

peace

After thinking about this for a while, there is a very serious issue of liability that needs to be discussed here. Imagine a scenario where a bug introduced a bad cell into a fuel map and damaged someones engine.

jb

Seriously you guys ... the best way would be to use an existing app that has scripting built in. That way you can display the logs as needed.

You look at data outside of the car a hell of a lot more then you do when your in it.

Even some of the link people wanted to develop a Excel script to just take our _TEXT_ logs that are tab delimited and somehow get what we wanted graphed.

Leaving the existing software/iterface to communicate with the ECU.

Where a GUI will come in handy is analyzing your data. Not the fuzzy cute animations you make when you update your fuel table

I have been thinking about interfacing to standard apps, i.e. Excel. Graphing + analysis for cause & effect is the appeal. Multivariate analysis anyone? Can be done stand alone, but why? Have made machine systems & inerfaces in the past via VB & Excel where the environment gave no indication that it is in Excel. I prefer C++, but not too popular for this sort of app. In other words, I am not too concerned about not supporting too many system envirionments. AND, I am interested in "for profit".

My pie (in the sky) are maps to be tweaked automatically given atmospheric changes, elevation, wheel weight, etc. Give me a couple more sensors on the car & I'll really go nuts.

Yes, you raise a good point - it would have to have the standard disclaimer applicable to all aftermarket stuff. "If it's freeware, it's free of any implied warranty."

Obviously, we don't want to do introduce issues into the system, so we would be looking for beta testers - as well as comprehensively testing it in our own cars.

To the Java guys - if we build an abstract data interface we could implement it in any language, we just need to agree on the requirements. We should pool resources on this, we wont necessarily be able to take code and use it independently, but the design pattern would be consistent. I haven't done anything in Java for 4 years - C# and Java are very close, I could learn it.

And this is open source AFAIK, not in it to make money....

Rich

Wow, don't check the board for a few hours and look what happens. To answer the most common questions.

-We aren't trying to make any money off of this (unless we are contacted very soon with an offer or something ;)).
-Oddly enough, we consider this project fun and you can make fun of us all day long. I have much more important things to spend my time on as well, but they're not nearly as fun.
-Yes it will be open source, and protected (GPL or something).
-We are NOT breaking the existing usability of the UTEC, just expanding on it and hopefully making it easier to use for us who like GUIs. You can still use the terminal if you want portability.
-We are not forcing anyone to use the product, and it is not endorsed by TurboXS.
-I've got no problems with Java, but like Rich said, that is not our area of expertice. And I really love the VS.Net IDE.
-We WILL put our software through rigorous quality assurance. There's no way I'd use this thing in my car without it.
-Rich and I are both professional software guys. Believe it or not, we may know a little about what we're doing and what we're getting ourselves into.
-We haven't written any code for this yet. We're just gathering requirements and doing some preliminary architecture work.

So, all that being said. We're really looking for feature ideas and a meeting of the minds on the design of this thing. The language it's implemented in isn't really all that important. You all know how easy it is to write an application in any language when you have a detailed design pattern to follow.

Jb: Thanks for the advice on the VT100 stuff. We could use your help on the detailed design. ;) We will be in contact.

That's all my feeble brain can think of to write about for now. :lol:

JD

Do new macintoshes even have serial ports? :)

jb

Originally posted by jimb
Do new macintoshes even have serial ports? :)

jb

New PC's don't even have serial ports. ;) You can buy a DB9 RS232 to USB adapter with drivers that create virtual serial ports for pretty cheap though. Sorry, couldn't resist. :lol:

JD

Damn the computer industry. First we lose ISA slots, now serial ports? Floppy drives are already on their way out (I think macs got rid of these too) and parallel ports will be gone just as quickly. A few months later everything will be wireless, because, hell, if mr. joe average is going to pay 2 grand for a computer he better not have to worry about hooking up a keyboard, mouse, and monitor. So, might was well make all the peripherals bluetooth or some other standard. Mice would already be gone if people didn't have greasy fingers (read: touchscreen monitors). Keyboards will go soon too, because, well, mr joe average paid 2 grand for the computer, he shouldn't have to actually type anything to make it work either. Maybe a few years later we'll just have mind controlled computers, hell, at that point they'll be small enough to actually be in our minds. Hmm.. maybe they'll be controlling our minds.. :eek:

jb

P.S. Don't take my serial and parallel ports away.

P.P.S. Something about my brain-embedded computer running a Microsoft OS scares me.

P.P.P.S. What kind of scam are they running? They take away a perfectly good serial port and make you pay more to have a USB port. Then, the zinger, they actually make you have to buy a new fangled device for possibly twice the price that the serial port would have cost had it not been eliminated just to get your serial port back! :)

Keep on doing what you are doing. It's amazing how scope creep and misunderstanding of intent can derail a project.

I'm not a software developer, but I for one fully support what you are doing. I'm very used to a telnet interface myself since I spend about 6 hours or more a day on one. :rolleyes: That being said, the GUI is a great idea and we appreciate you guys giving up your valuable time to pursue it. Face it: some folks are not going to be happy with 'your' implementation and will want it done differently. It's kind of like cars, isn't it!

Keep up the good work gentlemen, let me know if you need a beta tester. 15 years in IT has to be worth something. I think. Maybe? Ugh.

:D

Scott

Originally posted by jimb
P.P.S. Something about my brain-embedded computer running a Microsoft OS scares me.

Rather gives a whole new meaning to BSOD -- Blue Screen Of Death.

--
Bill Flowers
Clearwater, FL

You both have mail...

I don't have access to my home email from work, but if you guys are looking for some help, I'm definitely down for grabbing some practical experience.

Let me know if you're looking for some extra cycles, I'll do what I can.

Catch you guys later.

Jason

Originally posted by Jaxx


features that would be cool

auto tune map- displays a/f map .. as you drive and hit a certin section of the map the program changes the color of the grid to red (too lean) green (stoich[yeah i can't spell]) or yellow (too rich).. based upon values from the front a/f sensor and target a/f values that you set
(edit 2) or egt temps using stock sensor

i can't think of another ecu that woudl be capable of this sort of thing (intagrated wide band 02 tuning)

well your assuming two things

1. You have a wideband
2. You have an egt probe thats worth something

both false ... Tec3 will datalog real wideband o2 readings. That stock egt is used for your cat and detecting abnormalites there.

Tec3 upgrades sensors and controls a lot of stuff. Utec does not ...

I've talked with Links developers and it looks like color coded zones will be based on knock. Sample rates of o2 sensors are just not fast enough to make out whats really going on. The utec doesn't upgrade any sensors.

The auto tune feature ... your putting too much faith in. Tuning is more then just an AF ratio and again...your 02 sensor isn't fast enough to give a real picture of whats going on.

It's been awfully quite in this thread

Sproing!

JD and myself are AWFUL busy doing things that pay the bills, we aint forgotten though - promise.

Cheers

Rich

You guys probably already thought of this. But it would be great to have some sort of accelerometer feature. Something that could give you 0-60 and 1/4 mile figures(my guess if to work it off of RPM's). With that, you could get approximate horsepower figures too(like the G-Tech). It'd take a lot of work, but it'd be really cool.

That would be so awesome!

Wouldn't have to buy a Blitz power meter

The people at TXS beat me to it with the UTEC. I was going to do everything they did and maybe a little more with something called LabVIEW6.1. you can take data with it and do whatever you want in it. anyway, I think i still will. you can buy these fancy touch screens that will fit in the dash. basically, everything was going to be touch screen with real time graphs, numbers, warning lights, electronic guages, etc. the only catch is that you need a laptop, or a small computer under the seat. but even better, i did it myself and there will not be anyone else with it!!