DSMLink Type Program: Feature Request

[Max-Eclipse]

Hey, I am going to be making a custom DSMLink program, to basically do what DSMLink does, but go even further, and display the data in a nicer way, and just be all around more powerful... hopefully. It will do things like recreate your dash (speedo, tach, boost guage, and all that) on the screen for playback, and actually look like actual guages and stuff like that...

If you guys have any suggestions, or feature request, I would love to hear them...

BTW: it will be totally free to anyone who wants it, directly through me, or through DSMLink if they decide to host it too.

Maybe one of the mods would like to make this a Sticky

 

[DSMnewbi]

If you need a tester let me know! I can't think of anything to better a DSMLink other than visual, but you're already taking care of that so..

 

[Max-Eclipse]

If you need a tester let me know! I can't think of anything to better a DSMLink other than visual, but you're already taking care of that so..

ok, sure... ill need testers.

yeah, no offense to the makers of DSMLink, but their UI work just isn't all that appealing... but hey, its in Java, so what do you expect?

 

[16g-95gsx]

They created dsmlink the way it is, in order to make it as user friendly as possible. If you can redesign it while keeping it in a neat and user friendly package I'm sure dave and tom would be interested, however like I said user friendliness is their main priority.

One feature Ive always wanted them to do, is a boost dependent antilag setup for cruise conditions. It would retard the timing such as it does during stutterbox with antilag kicked in, but during cruise, when say X amount of throttle is applied, and it would return timing back to normal when X amount of boost had been achieved as read from a 0-5v Boost sensor such as the Greddy boost gauge or 3bar sensor. I figure this would seriously help alot of the huge turbo guys on the street by acting almost like an instant nitrous shot to spool up the turbo quicker. Id imagine it would work decently, I'm just curious how it would be in comparison.

 

[Max-Eclipse]

its funny you say that, because thats what i specialize in... is making applications user friendly, good looking, and efficient.

thx for the feature request ill put it on the list.

 

[16g-95gsx]

Like I said, its just something Ive always wanted to possibly try and see how well it would work. The lack of timing would cause hte car to bog a little, but if it was quick enough, which Id imagine it would be, then id imagine the turbo might be able to spool a good amount quicker, maybe 500rpms or more. I just figure with the abilities of DSMlink, and having a 3bar sensor on hand, would be excellent. In addition, Id like to have a boost dependent control for the nitrous feature. This would not only be nice for Nitrous, but also allow people to use it for WI controls, so there wouldnt be the need for a 30 dollar Hobb's pressure switch if you already are able to log boost. Ive had a few other thoughts of things Id like to see done, but dave and tom really have their hands full so it takes them a good amount of time to ever implement things. Please keep me informed of anything you do.

*edit*- O yea, another slider for say 25hz of airflow. My GM MAFT has two entirely different calibrations for idle (roughly 32hz or so) and 50hz. If I try to set it correctly for 50hz, then my idle LTFT becomes skewed because it meters differently at 32hz, Id really like to have the airflow perfectly calibrated, but at this moment in time I have to make a comprimise between perfect LTFT's at idle, and true calibration at 50hz, this causes a problem for global and deadtime figures since they must have perfect idle LTFT's.

 

[Max-Eclipse]

ok, ill look into those... i dont see why it wouldn't be quick enough... unless if you ran it on a really, really slow computer... but thats not smart...

Ive had a few other thoughts of things Id like to see done, but dave and tom really have their hands full so it takes them a good amount of time to ever implement things. Please keep me informed of anything you do.

hey, go ahead and let me know, ill put them in mine, and if they wanna put them in theirs they can, i just wanna make the best one i can, because i will be using it...

thanks

 

[16g-95gsx]

Sounds good, like I said keep me informed Id love to see new features being developed as the technology and hardware is already there, and the potential is incredible. Dave and Tom do their best but they also are burdened down and arent always able to develop things quickly.

Another thought I had was seperate timing controls, one for say closed loop, and the other for open loop. That way you could keep closed loop timing very high, for say gas mileage reasons, while still having the open loop controls at your normal values. The way DSMlink currently does it is just a global timing change. The ideas just keep coming .

 

[Ottoman]

just curious,

but do u plan on making a whole new interface from scratch, or more like a GUI that uses Dsmlink as a plugin/backend?

 

[Hal]

You will find that while you can do things in real time, the turn around time isn't fast enough to make it "adjustments on the fly" useful.

Unless you take the Java base client that Tom and Dave already have and build upon that, you are going to have quite a project ahead of you.

A "virtual dash" will require the ecu to be streaming data, and while it's doing that you can't send it commands to change settings.

Also, you can't add features to DSMLink with the client. The only thing you can do is modify the U/I for the existing feature set. The DSMLink chip itself must support a feature before the U/I can. As an example, you can't modify timing maps for open vs closed loop, because only one "global" timing table exists in the command set.

Have fun

Hal

 

[16g-95gsx]

I think Id listen to Hal

 

[Max-Eclipse]

Hal, by recreating the dash, i mean, ill take all the info that it gets (what DSMLink puts into the graph, which mine will have also) and let you play back your run watching your guages. (visual representation like that is sometimes better than looking at a graph for certain things)

I am totally redoing it, not building off of theirs, and yes, its a pretty good sized project.

I don't plan on adding new features to DSMLink with this, I plan on using the features in a better/different way for different data representation, and different interface.

Its something im doing just for the fun of it, so Im not gonna loose anything trying

 

[Hal]

Before you spend any time on the analog display, I'd make sure the chosen language and platform will support communications with the ecu.

Study the source for the P/C client and write a program that allows you to retrieve the "base" list. If you can do that, any other i/o issues can be handled.

It's not quite as simple as reading and writing data to/from the serial port.

That's why the Palm client can't run on just "any" Palm OS/PDA model combination.

I'm not trying to disuade you from doing anything, just pointing out that getting data to and from the ecu (or out of a log file) is a non-trivial task.

Hal

 

[Max-Eclipse]

Ok, Hal, I'm not saying your wrong, but I'm reall curious how the language can make a difference?

If the language supports I/O with the serial port, then why wouldn't it be able to do it? What is there that im not seeing here? The ECU recieves the info from the serial port, it doesn't know whats connected to it, it just knows that its getting something, then it replies to that, and it should always be the same, as long as you send the right info on the serial port, its just raw information being sent... as far as i know.

but, i haven't looked into the DSMLink client very in-depth yet, so im not sure exactly how it works... But, I'm sure if Java can do it, VB.Net can do it...

I'll do what you suggested though, and just start off with the basics to make sure it works.

 

[Hal]

You have to connect the dots... ie language -> o/s -> hardware.

Just because the hardware supports a feature doesn't mean the O/S does, and just because an O/S supports a feature doesn't mean the compiler/run time library does.

All three must support the feature set you need to use in order for it to work.

In some cases, you can bypass the O/S support and manipulate hardware registers directly, assuming the O/S allows it.

Don't assume the "serial support" means you have complete access to the UART features that you need.

Being able to read/write data via the UART is only one aspect of communicating with the DSMLink ECU.

You can not use the DSMLink "FakeECU" to test the serial communications. For that, you will need the actual ECU (both 1g and 2g) as well as all 4 versions of the adaptor.

Without this, you may find the subtle differences are enough to "break" your serial communications solution when it is used in the real world.

That's why I strongly suggest you take the Java client and simply use that as a base.

Hal

 

[LandoAWD]

Title edited.

 

[Max-Eclipse]

That's why I strongly suggest you take the Java client and simply use that as a base.

I'm not good with Java, or any other C style language... I know just enough to be able to read it and see what parts of it do... and get help from a few of my friends (one of which is a pro java developer) I'll look into how vb.net will work for this... if vb.net won't work for it, then I most likely won't be making this program, but as i said, vb.net *should* be able to handle it... and I know the OS does, because thats what I ran the regular DSMLink program on, so the only thing is making the actual program work...

Ill probably use a plugin architecture, and load plugins for w/e ECU it is, and stuff like that, which will make it easy to add in new ECU features..

anyways, ill look into it and let ya'll know what i find out asap.

 

[HighPSI TSi Guy]

DSMlink is good at what it does.. provides a user interface that any idiot can use...

but there is miles and miles of room for improvement, if they ever decide to cater to people who want to go beyond the idiot friendly interface and do more intricate tuning. GREAT product, but anyone who's ever worked with hondata knows what i'm talking about.. unless there's something i'm missing, it seems like the capabilities are there to go much further to a more hondata-ish type program, it just hasn't been done for whatever reason

 

[Max-Eclipse]

DSMlink is good at what it does.. provides a user interface that any idiot can use...

but there is miles and miles of room for improvement, if they ever decide to cater to people who want to go beyond the idiot friendly interface and do more intricate tuning. GREAT product, but anyone who's ever worked with hondata knows what i'm talking about.. unless there's something i'm missing, it seems like the capabilities are there to go much further to a more hondata-ish type program, it just hasn't been done for whatever reason

any specific exampls of what your talking about? what do you think needs a lot of improvement? what do you think it should do differently?

thanks

 

[HighPSI TSi Guy]

any specific exampls of what your talking about? what do you think needs a lot of improvement? what do you think it should do differently?

thanks

more thorough map control, more than anything else, i guess... honestly, as i already said, hondata style map editing would really be what i am getting at.. the ability to fully edit maps (timing and fuel), not just a couple sliding bars.. check out www.hondata.com and you'll see what i'm talking about... look at the examples of what it can do map editing wise

 

[Max-Eclipse]

hmm... theres lots of hondas around here... maybe someone will have it and i can see it in action...

then again, i doubt any of them around here have even looked under their hood...

*sigh*