New L6/L8/P8 Pectel Monitor Software Development
07-01-2009, 10:37 PM
#201
BANNED
BANNED
Thread Starter
iTrader: (1)
Join Date: Jul 2003
Location: Wiltshire
Posts: 12,483
Likes: 0
Received 0 Likes
on
0 Posts
stu21t,
It wont mean anything except to Stu and I would hope he appreciates what I am saying
It isnt a secret IMO but I wont divulge what it means as that would break PF rules.
It wont mean anything except to Stu and I would hope he appreciates what I am saying
It isnt a secret IMO but I wont divulge what it means as that would break PF rules.
07-01-2009, 10:49 PM
#202
Its no secret, anyone with a reader can see its there so I don't mind you saying. At least it proves I don't just copy any old EPROM and hope it works. I take care to ensure they will work properly and then put my name to them.
Last edited by Stu @ M Developments; 07-01-2009 at 10:50 PM.
07-01-2009, 10:59 PM
#203
Stu, om this rare occasion I am not a paranoid.
You said go for it initially when I first said about mapping features then now advised me against it. ??
I can kind of see that it could damage cars but only if missused but it is a tool and like any tool has to be used properly.
At this point in time, only monitor and global adjust features will be available.
You said go for it initially when I first said about mapping features then now advised me against it. ??
I can kind of see that it could damage cars but only if missused but it is a tool and like any tool has to be used properly.
At this point in time, only monitor and global adjust features will be available.
08-01-2009, 07:00 AM
#205
PassionFord Post Whore!!
Join Date: Sep 2003
Location: Macclesfield - you'll never leave....!
Posts: 4,519
Likes: 0
Received 1 Like
on
1 Post
simon,
an idea for some more features:
can you have the abaility to save the layout of the screen as a templte file that can be loaded once the main program is running. you could then have several template files with different readings displayed at different sizes and locations of the screen.
you could even have a autoexec one that is loaded as soon as the main program starts so no clicking on screen is necessary if it was loaded on an in-car install.
an idea for some more features:
can you have the abaility to save the layout of the screen as a templte file that can be loaded once the main program is running. you could then have several template files with different readings displayed at different sizes and locations of the screen.
you could even have a autoexec one that is loaded as soon as the main program starts so no clicking on screen is necessary if it was loaded on an in-car install.
08-01-2009, 08:15 AM
#206
Been giving this some more thought and going back to my original point about the data being slow to process as it is, I wonder how many datasets (with all the data you are offering) can your program access per second?
Also, how do you plan to distinguish between one software version and another when you have potential different memory locations allocated for certain variables, e.g. knock retard not being at location X, but at location Y? How would you distinguish software versions not having knock retard, or lambda control at all?
Also, how do you plan to distinguish between one software version and another when you have potential different memory locations allocated for certain variables, e.g. knock retard not being at location X, but at location Y? How would you distinguish software versions not having knock retard, or lambda control at all?
08-01-2009, 08:44 AM
#207
This is a great project, I also had similar ambitions and I believe others on here have similar interest and skills.
Given this is purely an interest project I would suggest the source code be open sourced so we can collaborate and build something even better as a group.
My plan was to enable people to share MAP's and performance data using open source model. Even my simple eprom loader demystified a lot of the changes made in ecus.
Here is an example:
I have written some code to decode the eproms on various weber Marelli ECU's As I said this was useful in comparing what had been done by various mods... With this program you start to see that the ecu is not that complex and presenting your engine settings in a readable format makes it easier to understand whats changed, and whats going on.
It might be a useful integrated with this code. Apply the same context to all the source code and you get a lot better understanding and interest in what was otherwise dated technology. Take a look at Mega Squirt... for a model we could use.
Tuners can still value add to this model, they just raise to a higher level, open information and source code can be scary at first to stakeholders... Once they get it they love it the only trouble is that some people don't like change and will not let go of their existing business model.
I have also written various embedded software apps and visualization code in my job over the last 20yrs which would be of use... Get a few guys like me on the job and we have an even better project, stuff like proper documentation of the ecu maps and forums to compare maps and settings.
Given this is purely an interest project I would suggest the source code be open sourced so we can collaborate and build something even better as a group.
My plan was to enable people to share MAP's and performance data using open source model. Even my simple eprom loader demystified a lot of the changes made in ecus.
Here is an example:
I have written some code to decode the eproms on various weber Marelli ECU's As I said this was useful in comparing what had been done by various mods... With this program you start to see that the ecu is not that complex and presenting your engine settings in a readable format makes it easier to understand whats changed, and whats going on.
It might be a useful integrated with this code. Apply the same context to all the source code and you get a lot better understanding and interest in what was otherwise dated technology. Take a look at Mega Squirt... for a model we could use.
Tuners can still value add to this model, they just raise to a higher level, open information and source code can be scary at first to stakeholders... Once they get it they love it the only trouble is that some people don't like change and will not let go of their existing business model.
I have also written various embedded software apps and visualization code in my job over the last 20yrs which would be of use... Get a few guys like me on the job and we have an even better project, stuff like proper documentation of the ecu maps and forums to compare maps and settings.
Last edited by oohogwash1; 08-01-2009 at 09:28 AM.
08-01-2009, 10:50 AM
#209
BANNED
BANNED
Thread Starter
iTrader: (1)
Join Date: Jul 2003
Location: Wiltshire
Posts: 12,483
Likes: 0
Received 0 Likes
on
0 Posts
Nothing to do with the mapping features pal, I don't care about those, in fact, the RP labs Pro has them already. Its the ability to inspect other tuners maps that I disagree with and it makes me wonder if I would want to be the one supplying it.
All the features I mentioned are possible and I suppose I am just giving info out to say what is possible.
What features the software end up with and how many versions of it etc.. will largely depend on who/how I end up with putting this in teh public domain.
Been giving this some more thought and going back to my original point about the data being slow to process as it is, I wonder how many datasets (with all the data you are offering) can your program access per second?
Also, how do you plan to distinguish between one software version and another when you have potential different memory locations allocated for certain variables, e.g. knock retard not being at location X, but at location Y? How would you distinguish software versions not having knock retard, or lambda control at all?
Also, how do you plan to distinguish between one software version and another when you have potential different memory locations allocated for certain variables, e.g. knock retard not being at location X, but at location Y? How would you distinguish software versions not having knock retard, or lambda control at all?
This is why I examine every eprom I have access to.
I identify how and where the data I need is and create an ecu chip profile.
As you know there are many tuner maps but not that many base files (relatively speaking)
When the comms logs in, it does many tests to identify the eprom.
If it is identified, then a profile is selected to enable the reading of extra
stuff like lambda etc. and also locate maps, settings etc...
If the eprom cannot be identified, then ONLY the standard pectel monitor data can be displayed as this is base file independant providing of course the ecu has the protocol.
simon,
an idea for some more features:
can you have the abaility to save the layout of the screen as a templte file that can be loaded once the main program is running. you could then have several template files with different readings displayed at different sizes and locations of the screen.
you could even have a autoexec one that is loaded as soon as the main program starts so no clicking on screen is necessary if it was loaded on an in-car install.
an idea for some more features:
can you have the abaility to save the layout of the screen as a templte file that can be loaded once the main program is running. you could then have several template files with different readings displayed at different sizes and locations of the screen.
you could even have a autoexec one that is loaded as soon as the main program starts so no clicking on screen is necessary if it was loaded on an in-car install.
It already does that
You can select 1 of 10 layouts to be loaded automatically on start up.
08-01-2009, 10:54 AM
#210
BANNED
BANNED
Thread Starter
iTrader: (1)
Join Date: Jul 2003
Location: Wiltshire
Posts: 12,483
Likes: 0
Received 0 Likes
on
0 Posts
This is a great project, I also had similar ambitions and I believe others on here have similar interest and skills.
Given this is purely an interest project I would suggest the source code be open sourced so we can collaborate and build something even better as a group.
My plan was to enable people to share MAP's and performance data using open source model. Even my simple eprom loader demystified a lot of the changes made in ecus.
Here is an example:
I have written some code to decode the eproms on various weber Marelli ECU's As I said this was useful in comparing what had been done by various mods... With this program you start to see that the ecu is not that complex and presenting your engine settings in a readable format makes it easier to understand whats changed, and whats going on.
It might be a useful integrated with this code. Apply the same context to all the source code and you get a lot better understanding and interest in what was otherwise dated technology. Take a look at Mega Squirt... for a model we could use.
Tuners can still value add to this model, they just raise to a higher level, open information and source code can be scary at first to stakeholders... Once they get it they love it the only trouble is that some people don't like change and will not let go of their existing business model.
I have also written various embedded software apps and visualization code in my job over the last 20yrs which would be of use... Get a few guys like me on the job and we have an even better project, stuff like proper documentation of the ecu maps and forums to compare maps and settings.
Given this is purely an interest project I would suggest the source code be open sourced so we can collaborate and build something even better as a group.
My plan was to enable people to share MAP's and performance data using open source model. Even my simple eprom loader demystified a lot of the changes made in ecus.
Here is an example:
I have written some code to decode the eproms on various weber Marelli ECU's As I said this was useful in comparing what had been done by various mods... With this program you start to see that the ecu is not that complex and presenting your engine settings in a readable format makes it easier to understand whats changed, and whats going on.
It might be a useful integrated with this code. Apply the same context to all the source code and you get a lot better understanding and interest in what was otherwise dated technology. Take a look at Mega Squirt... for a model we could use.
Tuners can still value add to this model, they just raise to a higher level, open information and source code can be scary at first to stakeholders... Once they get it they love it the only trouble is that some people don't like change and will not let go of their existing business model.
I have also written various embedded software apps and visualization code in my job over the last 20yrs which would be of use... Get a few guys like me on the job and we have an even better project, stuff like proper documentation of the ecu maps and forums to compare maps and settings.
Wow, you sound like you have a similar tech background to me.
I have spent many years collecting and reverse engineering my data and until now have made no use of it.
Cosworth chips are quite a bit different from normal weber IAW and the most common versions are encrytped with hardware baby boards.
I am not sure which direction my knowledge will be used at this point in time.
However, if all this was to be come fully public domain, I fear loads of peopel would be breaking their engines or worse case make money out of my knowledge without giving me any of it or the credit for it...LOL
Where do you live, may be good to meet up some time
08-01-2009, 11:16 AM
#211
I live in Australia but work for an American control system company (long commute to work). I lived in USA for years and relocated to Aus for lifestyle, I work remote to my USA office. Yeah we do have similar background, complimentary in many ways and similar in others. Wished I travelled to UK but I rarely do.
Take a look at how the Squirt Ecus evolved, we have a base ECU to start with otherwise very similar objectives.
I do not think you will get a slew of people willingly blowing up cossies... it does not happen in these other tech forums. It does require thinking on how to structure things. Remember that most people are not focused on the areas you are, they want different things no one willingly does stupid crap especially if safeguards are in place.
The open source idea allows a lot of extensibility, I understand your concern on recognition financial and otherwise, thats what I referred to in thinking the open source way... but in this environment its the best way I believe. The IAW community is too small to warrant time and effort by one person (financially that is).
I am sure you have thought long and hard on that. Developers (myself included) always want to build it all... but thats not always the best way. Remember that things like closed loop etc are such common concepts that you don't want to waste time reinventing this stuff...
If you like PM me your tel number and I will give you call to talk over this in more detail. It will save bothering people on here with needless details off topic.
Regards
Gavan
Take a look at how the Squirt Ecus evolved, we have a base ECU to start with otherwise very similar objectives.
I do not think you will get a slew of people willingly blowing up cossies... it does not happen in these other tech forums. It does require thinking on how to structure things. Remember that most people are not focused on the areas you are, they want different things no one willingly does stupid crap especially if safeguards are in place.
The open source idea allows a lot of extensibility, I understand your concern on recognition financial and otherwise, thats what I referred to in thinking the open source way... but in this environment its the best way I believe. The IAW community is too small to warrant time and effort by one person (financially that is).
I am sure you have thought long and hard on that. Developers (myself included) always want to build it all... but thats not always the best way. Remember that things like closed loop etc are such common concepts that you don't want to waste time reinventing this stuff...
If you like PM me your tel number and I will give you call to talk over this in more detail. It will save bothering people on here with needless details off topic.
Regards
Gavan
Last edited by oohogwash1; 08-01-2009 at 11:32 AM.
08-01-2009, 11:59 AM
#213
PassionFord Post Whore!!
if your worried about people adjusting maps without knowing what they are doing could you not password protect that side of the programme then release the monitor and faultcode reader only, to the public (apart from my version obviously, LOL)
But sell/give tuners the password to unlock the whole programme so they can use it for mapping?
But sell/give tuners the password to unlock the whole programme so they can use it for mapping?
08-01-2009, 01:43 PM
#214
Stu,
This is why I examine every eprom I have access to.
I identify how and where the data I need is and create an ecu chip profile.
As you know there are many tuner maps but not that many base files (relatively speaking)
When the comms logs in, it does many tests to identify the eprom.
If it is identified, then a profile is selected to enable the reading of extra
stuff like lambda etc. and also locate maps, settings etc...
If the eprom cannot be identified, then ONLY the standard pectel monitor data can be displayed as this is base file independant providing of course the ecu has the protocol. an select 1 of 10 layouts to be loaded automatically on start up.
This is why I examine every eprom I have access to.
I identify how and where the data I need is and create an ecu chip profile.
As you know there are many tuner maps but not that many base files (relatively speaking)
When the comms logs in, it does many tests to identify the eprom.
If it is identified, then a profile is selected to enable the reading of extra
stuff like lambda etc. and also locate maps, settings etc...
If the eprom cannot be identified, then ONLY the standard pectel monitor data can be displayed as this is base file independant providing of course the ecu has the protocol. an select 1 of 10 layouts to be loaded automatically on start up.
Also, you missed this question:
Been giving this some more thought and going back to my original point about the data being slow to process as it is, I wonder how many datasets (with all the data you are offering) can your program access per second?
08-01-2009, 02:41 PM
#215
BANNED
BANNED
Thread Starter
iTrader: (1)
Join Date: Jul 2003
Location: Wiltshire
Posts: 12,483
Likes: 0
Received 0 Likes
on
0 Posts
I am lucky my chip decoder program can shake out the secrets quickly as every new chip makes it more inteligent !
(Shame it cant do the same for me ...LOL)
Originally Posted by Stu @ M Developments
Also, you missed this question:
Been giving this some more thought and going back to my original point about the data being slow to process as it is, I wonder how many datasets (with all the data you are offering) can your program access per second?
Speed of data wont affect ecu performance as the protocol is self timing and syncronous to other ecu functions...to a limit.
I have done tests to prove that the ecu loop time doesnt decrease beyond what a standard pectel type monitor would add normally.
Yes I do request extra data but this is done intelligently.
As an example...The CO pot doesnt need a fast update as it doesnt change much.
Obviously the more data displayed will reduce update time but I think my alogithim for display time slots does this very efficiently and transparently to the user.
I think given what is available, the software perform well enough.
Umfortunately, as you know the protocol is slow so there are limits no one can overide !
Last edited by ECU Monitor Enthusiast; 08-01-2009 at 02:42 PM.
08-01-2009, 08:00 PM
#217
PassionFord Post Whore!!
09-01-2009, 10:37 AM
#218
BANNED
BANNED
Thread Starter
iTrader: (1)
Join Date: Jul 2003
Location: Wiltshire
Posts: 12,483
Likes: 0
Received 0 Likes
on
0 Posts
stu21t,
I will
Strange, the only real professional interest I have had are those who want the ability read complete eprom files and bypass encryption boards. LOL
I have been approached by a non passionford trader and will now probably follow that up now and release a full unstricted version as well as the basic ones.
I had hoped it would have been an official trader on here but its not to be
As this is most likely to become a commercial project now I have no choice but to stop posting updates here as it probably is pushing the trader rules now. The thread will probably get removed anyway..LOL.
Many thanks to all who have hepled, further updates will be else where and I am sure those still interested will find the new home when its sorted in the next few days.
Simon
I will
Strange, the only real professional interest I have had are those who want the ability read complete eprom files and bypass encryption boards. LOL
I have been approached by a non passionford trader and will now probably follow that up now and release a full unstricted version as well as the basic ones.
I had hoped it would have been an official trader on here but its not to be
As this is most likely to become a commercial project now I have no choice but to stop posting updates here as it probably is pushing the trader rules now. The thread will probably get removed anyway..LOL.
Many thanks to all who have hepled, further updates will be else where and I am sure those still interested will find the new home when its sorted in the next few days.
Simon
Last edited by ECU Monitor Enthusiast; 09-01-2009 at 10:38 AM.
09-01-2009, 10:43 AM
#219
To be fair Simon, you have KEPT ON mentioning you want to sell the project when you promised me this topic would have nothing to do with sales at all and it was to be informational only to benefit only the community and nobody else. So on that basis, I am locking this topic now as unfair to paying traders.
Thread
Thread Starter
Forum
Replies
Last Post
DixieTheKid
Ford Sierra/Sapphire/RS500 Cosworth
11
06-06-2020 11:20 AM
