KE5EUA's 818 Build

[mobileauto2000]

I like it.

 

[ke5eua]

Managed to get a couple coats on this today.



Gonna get some clear lacquer tomorrow and put on them before they go in the truck. I want the paint to last a little bit.

 

[ke5eua]

So I've been pondering the past couple days how I want to approach my parking brake rebuild and make it better and I believe I have come up with a solution.

Going to remove the manual lever and replace it with a standard air brake pack with spring brake. While I'm under there I'm going to go ahead and do the sprag disengage mod.

I want something that is a little more reliable than me remembering to set a parking brake, and with my electronic design once I shut the truck down it will bleed the air from the system forcing it to set.

Also having a spring brake will minimize the need to adjust it and will give a good grip with out worrying about a cable stretching.

For my sprag mod I'm going to use the same push pull knob instead of the normal front engage lever we are all use to. Doing this also adds the safety barrier of if forget to disengage it as once the air bleeds from the system the valve will automatically disengage at 35 psi.

I am toying with the idea of adding the parking brake into the system brake but I'm not so sure it would be a great idea at this point.

If anyone has converted the air/hydraulic to air brakes I'm all ears as I would love to do that instead, that would give me true parking brakes.

 

[Jeepsinker]

All you need is a 939 series truck to just rob all those parts off of and transplant to your truck. The 939s already have full air brakes and and air operated park brake.

 

[ke5eua]

All you need is a 939 series truck to just rob all those parts off of and transplant to your truck. The 939s already have full air brakes and and air operated park brake.

I thought about that. I know it has the manual drive shaft brake also along with the air spring brakes on the rear.

I might make a run down to the scrap yard and see about pulling parts off the mrap axles if I do switch over.

I would love to do the disc conversion but I don't think my pockets to that deep.

 

[Tow4]

Unless you have a good reason to add spring brakes or in your case, to replace the hand brake handle with a spring can, I would think twice about it. It's nice to be able to move the truck after you start it without having to wait for the air to build enough to release spring brakes.

 

[Jeepsinker]

Also nice when the truck won't run, or is otherwise disabled. A lot less fuss without the air cans.

 

[ke5eua]

Unless you have a good reason to add spring brakes or in your case, to replace the hand brake handle with a spring can, I would think twice about it. It's nice to be able to move the truck after you start it without having to wait for the air to build enough to release spring brakes.

Also nice when the truck won't run, or is otherwise disabled. A lot less fuss without the air cans.

I like making things difficult, lol

 

[tim292stro]

If you were to do the disc conversion I'd say just do an axle swap - all the parts already install on them.

 

[ke5eua]

If you were to do the disc conversion I'd say just do an axle swap - all the parts already install on them.

Yeah I was thinking that, might get with one of the surplus places that has them and see if they would want the old axles if I bought the disc ones from them.

 

[ke5eua]

Alright so I ordered some stuff last night to start the electronics project.

Micro controller is going to be an Arduino Mega 2560. I ordered an eight channel relay board for now, might upgrade to a 16 channel later if needed. Got 3 pressure sensors, 1 500 for fuel rail, and 2 150 for oil and air pressure. Going to get two converters for the fuel sendersto provide the digital signal I need to provide to the arduino, and 9 temp sensors for all 3 diffs, transfer, transmission, coolant, oil, air intake, and ambient air temperatures. Still have to get the pulse modulators for the tac and spedo.

I have a 20x4 lcd display and I'm hoping it's big enough, if not I will add another to it.

Right now the list of stuff the controller is going to handle is:

• Engine monitoring. Oil pressure, oil temp, coolant temp, fuel pressure, and fuel flow. By monitoring fuel flow I can calculate exact fuel used and remaining. Flow rate will be taken on both the PT inlet and return lines and compared.
• Drive line monitoring. Transmission, transfer, and all 3 diffs temperature
• "Tac" idle. I will have a high torque servo attached to the throttle linkage to allow for a high idle function that will auto adjust based on several parameters. This will also serve for cold starts where it monitors the ambient air temp and intake air temp. If the intake air temp is bellow a set threshold it will elevate the idle to prevent wet stacking during prolonged idling.
• Startup and shutdown function. I want to automate this somewhat like on the M1 tank. No more pumping the pedal, turning on and off the glow plug, I'll let the computer handle everything. It will use oil pressure, tac speed, and fuel pressure to determine running status. I will also implement a starter lockout function to prevent damage. The shutdown function, just like on the M1 will have a cool down timer of 5 mins that can be overridden by pressing the shutdown button a second time during the cool down. There will also be an abort function to abort either the start or shutdown sequences. Manual override keyed switched will be installed in case of an emp strike.
• A second arduino uno will take over all lighting functions. Turn signals, brake, hazards, headlights, etc.

Seems like a lot of good for nothing stuff but since I am going to drive this a lot I want some good monitoring of engine parameters in a central box. I had looked into using available hardware but after the cost of the hardware, sensors I realized building it myself I could do it for a fraction of the cost. Since I know the programming and electronics this is a somewhat simple task for me.

 

[tim292stro]

Sounds like an interesting project - I'd like to make a few safety recommendations:

1) High idle - you intend to have this directly control the speed of the engine, the same engine which you as a driver are responsible for controlling in traffic. For this "wet stacking prevention" feature, I'd advise that wet stacking is most likely to occur when you are idling for a long time, not in traffic. Place an electrical interlock on the parking brake, so that the solenoid cannot actuate the throttle once the brake is removed. For something as life-critical as this, I would actually say redundant interlock is the key (two switches, one one power supply, one on ground for the solenoid). A secondary interlock on the brake pedal would then be recommended (same dual switch concept) - as if the high idle were to accidentally trigger while you were driving, your default reaction would be to apply the service brakes. I mechanical interlock would also be a good idea - some thing which mechanically prevents the throttle from being altered in either of those two states (parking brake off, service brake on).

2) Your warning lights are there as your fail safe, you should not tolerate any failures in the air brake warning system - if you have a low-pressure warning that triggers at 85psi, a secondary system to do a non-electronic warning would be very important.

3) Your headlights and brake lights are the most important lights on your vehicle - you should have a backup system in place for your electronics. For example you could do the electromechanical equivalent of a watchdog timer, the Arduino would have to "prove" to the watchdog that it is functioning for the watchdog to allow the Arduino to control the lights, otherwise, fail back to old-school hardwired control.

 

[ke5eua]

Sounds like an interesting project - I'd like to make a few safety recommendations:

1) High idle - you intend to have this directly control the speed of the engine, the same engine which you as a driver are responsible for controlling in traffic. For this "wet stacking prevention" feature, I'd advise that wet stacking is most likely to occur when you are idling for a long time, not in traffic. Place an electrical interlock on the parking brake, so that the solenoid cannot actuate the throttle once the brake is removed. For something as life-critical as this, I would actually say redundant interlock is the key (two switches, one one power supply, one on ground for the solenoid). A secondary interlock on the brake pedal would then be recommended (same dual switch concept) - as if the high idle were to accidentally trigger while you were driving, your default reaction would be to apply the service brakes. I mechanical interlock would also be a good idea - some thing which mechanically prevents the throttle from being altered in either of those two states (parking brake off, service brake on).

2) Your warning lights are there as your fail safe, you should not tolerate any failures in the air brake warning system - if you have a low-pressure warning that triggers at 85psi, a secondary system to do a non-electronic warning would be very important.

3) Your headlights and brake lights are the most important lights on your vehicle - you should have a backup system in place for your electronics. For example you could do the electromechanical equivalent of a watchdog timer, the Arduino would have to "prove" to the watchdog that it is functioning for the watchdog to allow the Arduino to control the lights, otherwise, fail back to old-school hardwired control.

High idle will only be for when vehicle is stationary, not moving. This is where the speed sensor comes in also. Same as on emergency vehicles, brake is pressed idle returns to normal.

Air pressure warning will be a mechanical warning not controlled via the computer.

All major functions will still have a manual override. Just like in an airplane. Computers run the plane but in the event of computer failure manual overrides are in place to safely land.

I wouldn't implement something that would be a risk to myself, the hobby, or a bus full of nuns. I've been coding and doing electrical design since I was a teenager. Before it is ever put on the road several stress tests will be performed to ensure the survive-ability of the software and hardware. When it is put into the truck more stress tests will be implemented before going on an open road. I am lucky to have an open field behind my house with trails (no mud) I can dry test the system before it goes on the public road.

I know things like this make people nervous, but take a brand new car off the lot and I guarantee if the ecm goes out your dead in the water. Everything is computer controlled on vehicles nowadays. My wife's van's lights goes through the ecm to control the relays. I'm at least thinking of a backup, can't say the same for most modern cars.

 

[tim292stro]

Usually high idle on emergency vehicles is a switch and taking it out of park or stepping on the brake will disable it. There are cheap versions out there too for sure. I'm not thinking you're blazing new trail, I'm trying to look out for you in the liability department and maybe point out risks you may not have considered.

Sure you code and have been doing hardware design for years - however that P.O.S. Body Control Module (BCM) in your wife's car was made by people who went to school to do that for a living, and they couldn't get it right (but they are insured for such failures) - that's kind of what I'm trying to get at. The speed sensor you mention is still software-level control, the interlocks I'm talking about are hardware-level. What I'm trying to impress upon you is that no matter how good you think you are at coding or electronics design, you must always assume you made a mistake and think about how to mitigate that risk. If you're wrong, will you be thinking about the manual override at that very instant that the truck is lurching towards a mother with her infant twins in a stroller in a cross-walk? Would someone else driving your truck be trained for that contingency?

It's true fail-safe to have the entire high idle circuit physically cut when there is a condition that it should not be operated in - a manual override for such a circuit would be a switch that prevents power from actuating the solenoid (such as in the case of a software bug or a failure of the electronics due to other factors), a true mechanical override would be something which physically disconnects the solenoid shaft from the throttle (like in the case the solenoid becomes stuck, or a return spring breaks). I know the Arduino is cheap, but we're probably talking about a $2 switch on the parking brake, and a $2 switch on the service brake to be absolutely sure the Arduino doesn't take a spike and latch an IO in the wrong state or a rubbed wire short something and turn the solenoid on, or a metal shaving you missed when cleaning out an enclosure that hits that bump in the road and falls on the circuit board holding an IO pin high or low... (just another reason to conformal-coat the boards by the way)

Just think that if Toyota/Lexus had made it possible to shift from drive to neutral with the accelerator pedal pressed all the way to the floor and actually have it do something, or have a hard brake application (>50lbs) override the accelerator pedal input entirely, they probably wouldn't have killed that CHP officer and his family (which started all the trouble for them). Whatever you decide to build should be able to ingest conflicting information and control stimulus and act is the safest possible manner for the vehicle and the people around it. I would not encourage you to look at other enigneer's failures as a reason not to try to improve on their design.

FYI, the standard automotive spike test for 24VDC vehicles is 600V (this would be the worst-case alternator load-dump transient, not even EMP or ESD) - your power lines and IO lines on the Arduino would need to to be able to survive these constantly to be reliable from a hardware point of view, never mind the software reliability.

And yes, I don't yet trust all hardware engineers and probably never will (nature is rather efficient at producing new revisions of "idiot," no matter the pay scale), I like my vehicles: mechanical, manual, with a hardwired ignition switch... Of course you can do it your way, and you should by all means. As I say I'm just trying to look out for you.

 

[ke5eua]

Usually high idle on emergency vehicles is a switch and taking it out of park or stepping on the brake will disable it. There are cheap versions out there too for sure. I'm not thinking you're blazing new trail, I'm trying to look out for you in the liability department and maybe point out risks you may not have considered.

Sure you code and have been doing hardware design for years - however that P.O.S. Body Control Module (BCM) in your wife's car was made by people who went to school to do that for a living, and they couldn't get it right (but they are insured for such failures) - that's kind of what I'm trying to get at. The speed sensor you mention is still software-level control, the interlocks I'm talking about are hardware-level. What I'm trying to impress upon you is that no matter how good you think you are at coding or electronics design, you must always assume you made a mistake and think about how to mitigate that risk. If you're wrong, will you be thinking about the manual override at that very instant that the truck is lurching towards a mother with her infant twins in a stroller in a cross-walk? Would someone else driving your truck be trained for that contingency?

It's true fail-safe to have the entire high idle circuit physically cut when there is a condition that it should not be operated in - a manual override for such a circuit would be a switch that prevents power from actuating the solenoid (such as in the case of a software bug or a failure of the electronics due to other factors), a true mechanical override would be something which physically disconnects the solenoid shaft from the throttle (like in the case the solenoid becomes stuck, or a return spring breaks). I know the Arduino is cheap, but we're probably talking about a $2 switch on the parking brake, and a $2 switch on the service brake to be absolutely sure the Arduino doesn't take a spike and latch an IO in the wrong state or a rubbed wire short something and turn the solenoid on, or a metal shaving you missed when cleaning out an enclosure that hits that bump in the road and falls on the circuit board holding an IO pin high or low... (just another reason to conformal-coat the boards by the way)

Just think that if Toyota/Lexus had made it possible to shift from drive to neutral with the accelerator pedal pressed all the way to the floor and actually have it do something, or have a hard brake application (>50lbs) override the accelerator pedal input entirely, they probably wouldn't have killed that CHP officer and his family (which started all the trouble for them). Whatever you decide to build should be able to ingest conflicting information and control stimulus and act is the safest possible manner for the vehicle and the people around it. I would not encourage you to look at other enigneer's failures as a reason not to try to improve on their design.

FYI, the standard automotive spike test for 24VDC vehicles is 600V (this would be the worst-case alternator load-dump transient, not even EMP or ESD) - your power lines and IO lines on the Arduino would need to to be able to survive these constantly to be reliable from a hardware point of view, never mind the software reliability.

And yes, I don't yet trust all hardware engineers and probably never will (nature is rather efficient at producing new revisions of "idiot," no matter the pay scale), I like my vehicles: mechanical, manual, with a hardwired ignition switch... Of course you can do it your way, and you should by all means. As I say I'm just trying to look out for you.

Concerning emergency vehicles, taking it out of park or pressing the brake is still sending the signal to a software controlled device.

As far as fail safes. There is the clutch, ability the put the truck in natural , and the emergency shut off pull.

Out of all the things my computer is going to control your biggest concern is the high idle. I'm more worried the shutdown routine would decide to run while going down the road than anything. The high idle will be a simple high torque servo motor found on model airplanes. Something I can overcome with pulling up on the gas pedal. It's no more a concern, or fault as when my return spring broke when I was driving from Texas to Louisiana in the truck. Rpms shot up but I was able to pull the pedal up to control it, and when it initially happen I put it in neutral, pulled off to the side of the road and shut to truck down to figure out what had happened.

As far as the people who do it for a living part. I went to school for electrical design and programming before I joined the army.

I have thought of mistakes, and the possibility of things going wrong. That is why I have error correction built in to the code, and if all fails I have the shut down pull on the dash.

 

[ke5eua]

Here's a couple videos from youtube showing what I am planning to do with the idle control. My setup will obviously be cleaner, no zipties and tape, lol. I will also use cable instead of a solid wire so the servo doesn't move when I am depressing the pedal.

https://www.youtube.com/watch?v=v7GLQU-0Nwc

https://www.youtube.com/watch?v=wcz2lRRiYs4

 

[ke5eua]

Parts have started to arrive. Started on the coding matrix, and I have a complete revamp of what I had planned but I'll wait before I divulge it.

Found some capacitance type fuel senders that output a digital signal so I'm going to ditch the floating senders for these and tie into the system.

Air and oil pressure senders and power supply for the system. Guy forgot to put the 500 psi sender in the package, ehh I can wait since the arduino is coming from China.

 

[ke5eua]

Got some work done today. Pulled the dash and had it stripped of components and paint withing 3 hours.

First picture is the relays that replaced the master power, run and start switches. The single relay with the white wire is for the horn. Second one is the warranty sticker, I'm torn on stripping it off or just clear coating over it. I have another coat of clear to put on the transmission hump then i'll start on the transfer hump. I'll get all the stuff out of the cab and take a wire wheel to it and give it a coat of paint.

 

[ke5eua]

Got some more goodies in today and stripped and painted the inside of passenger door.


8 channel spdt relay board for the arduino


500 psi transducer for fuel pressure

 

[ke5eua]

Well it turns out my dogs decided I didn't need my brand new 7" touch screen for the truck project. Right now the electronics side of the project is being put on hold till I figure out if I want to spend another 200 on a new screen, warranty doesn't cover beagle damage.

So I will be redoing the wiring like I had planed, just a little different now. Give it a stock look with a modern twist. Also I have to redo the wiring as I cut the harness out of the truck since I had intentions of changing up things anyway.

Off to the surplus stores, lol