Any general discussion around the firmware, what is does, how it does it etc.
User avatar
By Timus
#44057
That's weird. Even if my fork is somehow corrupting memory it should not affect original firmware and its baseline.

When I come back home I will start testing if such corruption is occurring on my board, and if so I will start searching why.

Edit:
I cannot reproduce afr table(or any other table) malfunction. But indeed I notice some problem with vertical load axis of wmi map, I'm on it.

My testing .msq in attachment.

Edit 2:
I found bug in table loading and saving. It's fixed now.

Edit 3:
I just changed wmi axis scales, up to now they were wrongly scaled.
Attachments
(64.66 KiB) Downloaded 238 times
User avatar
By DeeEmm
#44078
Hi Timus,

Thanks, the issue now appears to be solved. The Improved layout looks better too. I used a new Arduino and also reinstalled my version of TS. Not sure which of those things solved the issue, but it is fixed. When I get a spare 5 minutes I will try again with the first Arduino, just to see if it has some kind of memory issue.

I am still getting one warning relating to a unit offset. Not a biggie but I guess needs to be solved before it can be pulled into master.
Code: Select all
1 Warnings:
Warning: MSQ Units Mismatch for wmiOffset! ms found in current configuration, psi found in MSQ, values were not converted to new units.
So test driving the interface, everything looks good and functions how I would expect. I think that the only change to this would be to grey out the option for the 'WMI Duty Cycle' in the accessories menu when 'Simple' or 'Proportional' mode is selected.

I will carry out some bench testing this week and if it looks good then I think that you have satisfied the terms of the bounty and any further development and tweaking can be carried out afterwards. I'm also happy to continue on with further development if your interest was only the bounty.

I'm guessing that before anything can be considered for a pull request it really needs to have some successful real world testing and have things like terminology and interface approved along with documentation. Again I'm happy to take some / all of this on as required.

Thinking ahead... After I've bench tested it I will update the tune with that from my existing setup and get it loaded up into my car. I will need to put together some suitable hardware as it is currently running without WMI. I will also have to figure out how to undertake realtime testing. Might need to book some dyno time so that I can do it with the car static and see what's going on.

Really big thanks for picking this up Timus. I honestly thought this was never going to happen.
Attachments
Screen Shot 2020-07-05 at 9.56.52 am.png
Screen Shot 2020-07-05 at 9.56.52 am.png (6.09 MiB) Viewed 7956 times
User avatar
By Timus
#44084
DeeEmm wrote: I am still getting one warning relating to a unit offset. Not a biggie but I guess needs to be solved before it can be pulled into master.
It's because MSQ was created before I applied last changes. To make it always up to date I added new base tune with wmi to git "reference\Base Tunes" directory.
DeeEmm wrote: I think that the only change to this would be to grey out the option for the 'WMI Duty Cycle' in the accessories menu when 'Simple' or 'Proportional' mode is selected.
Done.
DeeEmm wrote: I will carry out some bench testing this week and if it looks good then I think that you have satisfied the terms of the bounty and any further development and tweaking can be carried out afterwards. I'm also happy to continue on with further development if your interest was only the bounty.
Well I cannt say that I will have time for further development, but I can help with it from time to time.
DeeEmm wrote: I'm guessing that before anything can be considered for a pull request it really needs to have some successful real world testing and have things like terminology and interface approved along with documentation. Again I'm happy to take some / all of this on as required.
I agree. I can help with documentation but I don't feel like my English level is good enough for that.
DeeEmm wrote: Really big thanks for picking this up Timus. I honestly thought this was never going to happen.
You are welcome. I would probably take on it earlier, but simple didn't know about it.

Some technical information:
Tank empty sensor in normal mode is controlled by ground, when grounded speeduino thinks its water in it(most washer fluid level sensor works that way). When in inverted mode you must add pull down resistor and then its controlled by positive voltage.
I would recommend to connect wmi enabled output through relay to control water pump and PWM to control solenoid, that's because water pump is using much more current than solenoid.
By ric355
#44095
Timus wrote: Sun Jul 05, 2020 11:43 am ...
Thanks for picking this up - some good work done by the look of it.

When you have a minute can you see if you can git squash your repo so that all of the changes for WMI are visible in a single commit? Thanks.
By ric355
#44114
Timus wrote: Tue Jul 07, 2020 4:44 pm
ric355 wrote: Mon Jul 06, 2020 10:54 am When you have a minute can you see if you can git squash your repo so that all of the changes for WMI are visible in a single commit? Thanks.
Done: https://github.com/Timu5/speeduino/tree/wmi
Thanks for doing that. Very much appreciated.

There is this quote on an earlier page in this thread;
Dziku wrote: Fri Jan 17, 2020 6:59 pm
noisymime wrote: Thu Jan 16, 2020 12:49 am This has actually (FINALLY) bubbled up near the top of my TODO list :D

I expect to be getting this usable sometime in Feb if you can hold out that long
And it would use vvt?
It would be great if not, because it would be great to use vvt, meth injection and ebc on the same time...
It looks like that isn't how it has turned out if I have correctly understood the logic and comments (tests always check vvt is turned off and the vvt table seems to be used internally for a wmi function). It is what it is; I just wanted to make sure you realized it had been discussed.

I see, unsurprisingly, it adds quite a lot of new eeprom entries. You might need to do some work in updates.ino to ensure things are being properly initialized when a firmware upgrade is done. We had this with another feature which if not manually initialised after upgrade would pull 15 degrees of timing everywhere due to not being initialised. Standard practice is to check every setting after an upgrade, but not everyone does. You might already have this covered through ini file defaulting.
User avatar
By Timus
#44131
ric355 wrote: Tue Jul 07, 2020 7:14 pm It looks like that isn't how it has turned out if I have correctly understood the logic and comments (tests always check vvt is turned off and the vvt table seems to be used internally for a wmi function). It is what it is; I just wanted to make sure you realized it had been discussed.
Yes, I'm aware of this post. I explained few post earlier why it is work that way and that's because of no free timer to use.
ric355 wrote: Tue Jul 07, 2020 7:14 pm I see, unsurprisingly, it adds quite a lot of new eeprom entries. You might need to do some work in updates.ino to ensure things are being properly initialized when a firmware upgrade is done. We had this with another feature which if not manually initialised after upgrade would pull 15 degrees of timing everywhere due to not being initialised. Standard practice is to check every setting after an upgrade, but not everyone does. You might already have this covered through ini file defaulting.
I've just added same basic initialization to update.ino.
User avatar
By DeeEmm
#44177
Timus, I've carried out some bench testing and as far as I can see everything is working. I've not been able to test how effective the 'closed loop' mode is as I need to do this with a real pump / valve combination but any change here will just be a minor refactoring of the pulse width calculation...
Code: Select all
wmiPW = max(0, ((int)currentStatus.PW1 + configPage10.wmiOffset)) * get3DTableValue(&wmiTable, currentStatus.MAP, currentStatus.RPM) / 100;
I'm not really sure how well the fuel injector pulse values will work on a clunky solenoid valve or how it will work if driving the pump directly, so those things may need some fine tuning down the track. I've got a pump and FAV on order so will undertake further testing when they arrive as I don't have any to-hand.

I think that if no one else has any comments / suggestions / objections then I am happy to release the bounty. My understanding is that you need to apply for it before I can release it.

/DM
User avatar
By Timus
#44180
Should I wait for more feedback or just create a pull request to master now? or not create pull request at all?

It's my first time using bountysource, but from what I can read in faq, one clicks on solve issue(I done that), do what he need to do, author close issue on github, an then one can claims it and backers accept it or not. See attachment.
Attachments
bounty.png
bounty.png (8.23 KiB) Viewed 7765 times
User avatar
By DeeEmm
#44182
Haha, yes, my first time too. :D

Getting it into master would be awesome. I guess it depends on how much more work it is to get from where it is now, to being accepted into master.

I guess it would be good to get Josh to chime in.

/DM
  • 1
  • 4
  • 5
  • 6
  • 7
  • 8
  • 11

I think possible reasons for that would be: 1) loo[…]

It looks like you have a fuel supply issue. readin[…]

Will this have an updated version about this featu[…]

Perhaps some different points and pictures. Instr[…]

Still can't find what you're looking for?