[noisymime]

So September has been largely focussed on hardware for me, but as always there's been some more solid improvements and new features added in the firmware.

On the hardware front, I've finally had a bit more time to play with the new surface mount design, specifically the MX5 PNP board that has been in the works for a little while. Here's a little preview of the current incarnation:


This board is not yet ready to go and there were some showstopper issues found on this testing version, but given the ground up design, this was expected. The board did run an engine, but a few of the onboard features are not functional due to design issues. Still, it's getting there

Around the firmware, it's been fantastic to see a few people putting forward pull requests for their own work. I will need to begin putting in place some processes to make this smoother in the future (Eg a style guide) but I'm thrilled that others are putting up good quality pull requests that I am confident in bringing into the main code.

As usual, here's the list of major changes:

• A critical fix to the Multiply MAP option to correctly calculate PW for this. Note: If you've had this enabled, you will likely need to make changes to your VE table with this fix. . If you are not using Multiply MAP (Default is to have this off) then there is no impact
• Changes required to support TunerStudio 3.0.7 and newer. This was caused by a change in TS to drop support for a certain label in the ini
• Oddfire support for engines up to 4 cylinders has been added
• More flexible pull up / switch configuration for launch control (Thanks go to Connor McLaughlin for this)
• A 'Non-360' degree decoder. This is a version of the dual wheel decoder that allows for primary tooth counts that don't divide evenly into 360
• A live histogram of O2 and tpsDOT has been added to the acceleration enrichment dialog. This is a huge help in tuning this enrichment as you can directly see the impact that throttle movements are having on the O2 and adjust the curve accordingly.

REMEMBER TO ALWAYS LOAD IN THE NEW INI FILE INTO YOUR PROJECT ONCE YOU'VE UPLOADED THE FIRMWARE ONTO YOUR ARDUINO

This firmware can be downloaded from: http://speeduino.com/wiki/images/a/a1/S ... Sep16b.zip
Or from the release on github: https://github.com/noisymime/speeduino/ ... tag/201609

As always, if there are any issues or problems experienced with this release, please leave a comment below or raise a bug.

[Old Grey]

That board is crying out for a top mounted Mega, it's so sparse. I'm was half way through doing a flipped Mega with the silk for all those protruding parts - that stupid USB caught me out on mine -, because I was thinking of doing a single with top mount Mega. It's probably too hard for yours because the mega is 100mm long, so it would have to be sideways.

[cx500tc]

So September has been largely focussed on hardware for me, but as always there's been some more solid improvements and new features added in the firmware.

On the hardware front, I've finally had a bit more time to play with the new surface mount design, specifically the MX5 PNP board that has been in the works for a little while. Here's a little preview of the current incarnation:


This board is not yet ready to go and there were some showstopper issues found on this testing version, but given the ground up design, this was expected. The board did run an engine, but a few of the onboard features are not functional due to design issues. Still, it's getting there
....

The hose barb for the MPX is going to have interference issues with the pins from the header. Since you're dealing with SMD, is there an SMD pin header that could mount to the underside, at least where the barb passes? Or maybe split that header so the adjacent pins aren't used and don't require a header installed?

*** edit ---> Just did a test fit on a board with an MPX and it does look like the hose will clear the pins. My apologies.

Nice to see the MC33814 getting some love.

Where's the TVS and such? U2, right? Shouldn't that be close to where power enters so it can shunt out as quickly as possible?

The IC just below and left of the MPX... looks like the trace routing could be cleaned up if it were rotated 90 clock-wise (looking down).

Is this board in the download?

[androidcho]

Good work as always! I really hoped for squential, but I'm sure it'll happen soon.

[noisymime]

The hose clearance on the map sensor is fine, you'd have to use some fairly thick hose for it to be a problem.

There is an issue with clearance with the pins and the power jack on the arduino, butbit just requires cutting off the pins after soldering. Not sure if it's worth changing.

The board is in the download, but I wouldn't recommend making one yet, it has known routing issues and some grounding issues on the 33814.

PVT3 has been sent for production and should clear up the known issues, but it's a wip.

[Old Grey]

The barb might clear the pins, but does the barb with the hose clear the pins.

[noisymime]

The barb might clear the pins, but does the barb with the hose clear the pins.

It does easily for the hoses I've tried with. I'm using some fairly thick silicone hosing and it hasn't been a problem.

[cx500tc]

The barb might clear the pins, but does the barb with the hose clear the pins.

Trying to lay things out best as I can based on the picture, the pins are about 3mm from the barb fitting directly above the pins.
What would help is moving the MPX out towards the edge so the pins are closer to the body of the MPX.

*edit-

It does easily for the hoses I've tried with. I'm using some fairly thick silicone hosing and it hasn't been a problem.

That settles it then.

But is silicone hose really stiff enough to adequately transmit vacuum and pressure signals?

[PSIG]

But is silicone hose really stiff enough to adequately transmit vacuum and pressure signals?

Yes.
 
David

[cx500tc]

But is silicone hose really stiff enough to adequately transmit vacuum and pressure signals?

Yes.
 
David

Any deformation of the hose/tubing under vacuum or pressure conditions will affect the propagation of the signal... maybe not enough to affect the system operation, but it is something to keep in mind. By that, I mean you likely wouldn't use silicone / surgical tubing... would you?