Please note: Friday June 18 is a holiday celebrating Juneteenth, please allow extra time for your order to arrive and plan accordingly.
0

Glowplug controller
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Glowplug controller

by seasidemotors on Wed Mar 24, 2021 10:45 pm

Hello All, my name is Robert and I am new to the forums. I have come here to request help in product selection and to get general ideas in getting direction. I want to learn to program microcontrollers in the automotive realm, this would be for custom projects and I am at the moment not interested in CAN bus or OBDII connectivity.

I want to work with raw sensor signalling, 9-16v i/o signalling, relay controls, data output to digital displays, etc...

For my first ambitious project I want to build a glow plug controller for a 4 cylinder diesel. So glow pugs are basically resistance heaters for the combustion chamber to bring the chamber temps up for initial cold starting. I have a original basic controller from 1986 that uses a simple microcontroller to control a single relay. It has 1) 12V Bat Pwr. (input) 2) 12V Key On Pwr (input) 3) 12V Start Sig. (input) 4) 12V Grnd (Input) 5) 12V Light Signal to Dashboard 6) 12V Output to GlowPlugs. The electronics on this are all on a single board with the 70amp relay hard soldered to the board, all included in a sealed plastic housing. Its operation is very basic in the following order: 1) Key On signal, energize relay, output light signal to dash, start 8 second count down...if start signal, stop countdown, de-energize relay...sequence complete. If key is turned off and then turned back on, restart sequence. Always kill sequence on starter signal or key off signal, restart sequence at key on.

What I would like to do is to make things more advanced and possibly adding in user interrupts/controls. I would like to add in additional inputs such as engine coolant temperature, ambient outside temperature, variable glow timing based on temperature inputs, afterglow functionality after engine start with reduced glow (pwm volt/amperage control?), individual relays per cylinder for glow plug health monitoring (current monitoring, as glow pugs wear or possibly short circuit as they age they will draw more amperage which is a sign there is a problem in the circuit. If a glow plug starts disintegrating the ceramic will quickly destroy a cylinder). And a RPM signal input would be nice as well, would also output to lcd as mentioned next...

Now if that where not enough I want to be able to tie this into a LCD display (128x64??) that will show coolant and ambient temperature, glow countdown to engine start and count down after glow. LED monitors, blue flashing during glow operations, blue during normal engine operation and flashing red for over-current situations. Possible user interrupts maybe to manually operate glowplug relays in the event of software failure or other yet determined features. Oh yes, and I will need a traditional buzzer to sound during initial glowplug operation.

Once this is installed in the vehicle it will be a hands off self contained operation. There is no need for further programming or user intervention. There is no need for bluetooth/wifi/eth connectivity. I could literally burn the program to a ROM chip and ship to end user.

My question is what board should I consider given the above parameters? Ultimately to get started I could use low voltage 3.3v relays and simulate glow plugs with leds, I could bread board the various components and build the code. I could get the sensors programmed etc..

Speaking of building code, I am assuming I would use micro-python for this, but perhaps I might have to learn ada or C+? I have almost zero programming experience, ;p so hey I am an empty cup ready to learn. I am on Linux and am good enough to get have configured vim as a python ide so not completely inept at the game.

Any guidance would be kindly appreciated.
Thank You,
Robert

seasidemotors
 
Posts: 20
Joined: Wed Mar 24, 2021 9:55 pm

Re: Glowplug controller

by adafruit_support_mike on Thu Mar 25, 2021 8:51 pm

Right now, the biggest threat to your success is overloading. Start by getting familiar with microcontrollers in general, then duplicate the feature set of the existing device. Once you have that working, build out in small steps. Choose the next feature you want to add, get familiar with any new sensors or displays one by one, then combine them with your most recent working version of the total system.

Start cultivating good habits from the start: make a new version of the project every time you want to change things. Learn how to use a version control system like git, or just duplicate your existing files before changing anything. You'll learn to appreciate the practice the first time you forget to do it. Take photos before you disconnect or move anything.. about one time in five you'll find you need to know something after it's too late.

Keep a notebook in the following format: before you do anything to the code or hardware, write a general description of what you plan to do and what you expect to happen. Then do the work, and test it to see what happens. If things go as you expected, write 'worked'. If they don't, write what did happen, then start debugging. Once you know what went wrong, write that down. If you can think of any reasonable measure to keep the same thing from happening again, write that too.

A large majority of bugs, both in software and hardware, are the result of simple mistakes.. accidentally changing a value instead of comparing it to something, forgetting you disconnected power to one part of a circuit, and things like that. It's easy to fall into a fix-and-forget pattern if you just keep working, but having to write down the same dumb mistake over and over makes it personal.

Another very easy way to have problems is a practice I call 'shotgunning': changing things without keeping track of what you're doing, and without having a clear reason for each change. After half a dozen steps of that, the changes you've made will start interfering with each other, you'll have half-complete modifications sitting around that you've forgotten, and you'll have no idea how to revert what you've done. Taking the time to plan ahead and record progress feels like it slows you down, but it saves hours of pointless frustration.


With those general comments out of the way, automotive electronics is a specialty field, and one where we really aren't experts. Automotive parts are subject to temperatures, vibration, oil, dirt, and other conditions that most electronics never see.. automotive tolerances are a whole category for semiconductor manufacturers.

Your best source of information in that field will be an experienced diesel fitter or an instructor from a good technical school.


In terms of microcontrollers, you'll be working at 5V or 3.3V. You'll need to manage the conversion between those voltages to make things work. Some parts of that will be easy, like using mosfets to control relays.. that provides two steps of isolation between a microcontroller that drives the mosfet and the power switched by the relay. You also have the option to use things like thermocouples to measure temperature, which don't require a 12V+ supply. Down-shifting 12V+ digital signals to 5V or 3.3V is also fairly simple.

Scaling 12V+ analog signals down to the 5V or 3.3V range presents more challenges, but will be less common. The 12V+ supply in a vehicle tends to be extremely noisy.. spikes up to double the nominal voltage are known to happen.. so circuits that depend on precise voltages tend to be rare. Again, a good mechanic will know the kinds of devices that are normally used, and what kinds of signal protection are popular these days.

adafruit_support_mike
 
Posts: 62799
Joined: Thu Feb 11, 2010 2:51 pm

Re: Glowplug controller

by seasidemotors on Thu Mar 25, 2021 10:36 pm

Sometimes the most unexpected reply is the best reply. Mike, thank you for taking the time to write such a detailed reply. The advice you give is priceless and really appreciated. I really like the idea of using a note book and using git hub as a version control and file repo. ( I am still new to git hub, but now its time to start learning it)

I have just begun to understand the small mistakes breaking things as I am venturing into python and forget a quote or bracket and the program errors out, simple mistakes. I had to grin at your use of the 'shotgunning' example, as a automotive mechanic for about the last 30 years I have unfortunately seen that play out several times and usually at the unfortunate expense of the customer. I myself am guilty of getting caught in that trap a time or two.

I am very familiar with automotive system design and diagnostic testing, but I don't know how things are coded. I have cracked open a few control modules and see all kinds of electronics that I am somewhat unfamiliar with so I think that is where I need a little reading in that department to do as well. Anyways to get things started on the hardware side I think I will pick up something like the STM32F405 Express, a Bosch BMP 388, and a 128x64 display, and maybe a qt py, a couple relays, some mosfets, bread board, etc and just start digging in...and keeping a detailed log book of each experiment, like a electronics scientist ;)

Thanks again for the very well articulated response,
Cheers!

seasidemotors
 
Posts: 20
Joined: Wed Mar 24, 2021 9:55 pm

Re: Glowplug controller

by adafruit_support_mike on Sun Mar 28, 2021 2:51 am

seasidemotors wrote:as a automotive mechanic for about the last 30 years

Ah.. that's fantastic for two reasons:

First, specifically to the subject of building electronics for automotive applications, you already know the things that will be hardest for a beginner to acquire. Adding new things to an existing vocabulary, even if they're totally unfamiliar, is easier than becoming fluent in the first place.

Second and more generally, you're in a position to understand the really good advice. Acquiring skill is a skill in its own right, and the hard parts.. like how the tedious fundamentals blend together and become working intuition.. carries over to other skills.

seasidemotors wrote:like a electronics scientist

That's exactly correct.. electronics is an applied science, and doing it well is an ongoing back-and-forth between theory and application. An hour working at the bench turns a week of reading into useful knowledge. A week at the bench gives you observations that send you back to the books to see how other people have made sense of them.

On the hardware side, electronics has deep connections to what mathemeticians call 'power series': a/10 + b/100 + c/1000 + ... 'a' is called the 'first-order term', 'b' is the 'second order term', and so on. We tend to solve problems by finding a simple approximation for a, then correcting with an approximation for b, and so on. Instead of working with exact numbers, we spend a lot of time working with orders of magnitude.. common resistor values range from 0.01 Ohms to 10 million Ohms, capacitor values range from picofarads (1e-12F) to Farads, and in most cases it's safe to ignore variations of less than 1%. That's a mental shift from the machine shop where a few thousandths of an inch mark the difference between a good part and a catastrophic failure.

On the code side, you'll spend years learning that 'lookup table' and 'iteration' are bottomless pits of useful and interesting ideas.. lists are lookup tables that map integers to other data; associative arrays are lookup tables that map arbitrary strings to other data; data structures are lookup tables for collections of data; variables are an open-ended lookup table that map identifiers to regions of memory the computer can read and modify; functions can be reduced to lookup tables than map their input parameters to output values; the function parameters themselves are a lookup table that associates names the function knows with values defined at the time you call the function; any list of (a,b,c,...) tuples can be turned into a lookup table equivalent to a function; the philosophically deep concept of 'scope' is based on where lookup tables have any meaning, some meaning, or always the same meaning; etc, etc, etc.

On the applied side, almost all the work you do will be handled in terms of simple variables, lists, associative arrays, data structures called 'nodes' that point to other structures of the same kind, and 'objects' which are roughly data structures where some names are functions that can read/modify other values in the same structure.

The basic data structures are used in a handful of common ways: iterated lists, heaps, queues, stacks, trees, and graphs. There's a family of basic algorithms for working with each kind.. adding a new item, finding existing items, removing items without breaking what's left, and so on. Putting things in order is extremely common, and there are dozens of sorting and searching algorithms. Learning insertion sort for small collections of data, heapsort for medium collections of data, and quicksort for large collections of data will cover 99.9% of your programming needs. Learning about directed graphs in general, and how to topologically sort a graph will give you a fallback tool when none of the simpler data structures/algorithms work.

All programming problems can be reduced to three types: those that can be solved by state machines (pattern matching with a lookup table that uses its current state and the input value to choose its next state), pushdown automata (interpreting structured data with a stack of state machines and the operations 'create a new state machine' and 'use the output of this state machine as input for the previous one'), and Turing machines (everything else.. code that can create, modify, or use a lookup table counts as a Turing machine). The biggest problem in writing well-structured code is that it's so damned easy to create and iterate a Turing machine whose behavior is largely independent of the functions listed in the source code. Once you learn all three kinds of machine, you'll spend 10% of your time designing and using them and 90% keeping yourself from creating and using them accidentally.

The closest mechanical analogy is to imagine that putting any collection of parts in a box and shaking it will create some kind of motor or 'drive train' in a sense that includes 'moving the vehicle down the road' and 'moving fuel to or through the engine'.. you can build something that looks like a normal engine, but on analysis you learn that all the power to the wheels comes from the things that look like the starter, alternator, and fuel pump, and the thing that looks like an engine block is driven by the wheels and moves all the liquids including fuel, oil, water, brake fluid, and windshield wiper fluid.

The extreme ease of separating 'what the code actually does' from 'what the code looks like it should do' leads to the working programmer's obsession with 'style', which is driven by two goals: 1) keeping the program's behavior in sync with the written code, and 2) being readable by other programmers. The reason medium-experience programmers hate global variables and experienced programmers use them with caution is that it's so easy to create a hidden program with them.

Contrary to popular belief, code exists for human communication, not communication between humans and computers.. there are *much* better ways to arrange information for human-to-computer communication than we see in most programming languages. The two languages with the smallest human-to-machine gaps are LISP and Forth, which most expert programmers have learned, but don't use directly. Instead, we apply key ideas from those languages when writing C, Python, Javascript, etc. LISP teaches you ideas like 'write functions that take a list as input and produce another list as output' and 'always write for lists with zero, one, and many items'. Forth is basically a pushdown automaton (the efficient way for humans to talk to computers) and teaches you how to write efficient, well-structured code with a small footprint.. there are complete Forth interpreters smaller than 1k.

Since code does exist for humans, learning to write good code involves reading code.. something many programmers never do. This idea ties tightly to the 'predict, test, and record' loop of keeping notes. The idea is to predict what a given chunk of code will do before you read it in detail, read it slowly and try to follow it, then record whether your prediction was right. Thing is, this time the match between your predictions and the results measure how well the code is written. If you can't make heads or tails of what the code is doing, it's more likely to be the programmer's fault than yours.

Therefore, the most valuable code to read is your own. Let it sit for a month or two so you no longer have all the details fresh in your mind, then go back and look at what's in the files. The point of the game is to learn how much information about the program's structure and operation is on the page, and how much was in your head. The goal of writing good code is to get as much knowledge as possible out of your head and onto the page, so you can re-acquire it the next time you read the page.

The experience will not be pleasant. There's a famous story of Bill Gates scanning and editing code in a meeting and saying, "what idiot wrote this?" about a section he'd written a few weeks earlier. I can't front-load strongly enough that the process can be frustrating and demoralizing. When that happens, watch these two videos:

https://www.youtube.com/watch?v=rDjrOaoHz9s Ira Glass on "the gap"
https://www.youtube.com/watch?v=X2wLP0izeJE Fail Faster

Watch them over and over. Watch them until you can say it along with them. I still hit them both every couple of weeks just to reset my basic principles of how to make things.

The two most useful ideas I use daily that aren't covered in either of those are:

1) "Try anything. If that doesn't work, try something else."

If something is possible, it's hard to find new ways of failing that don't teach you something. If you don't know anything about a subject at all, your initial prediction can be anything accompanied by the almost certain knowledge that it will be wrong. But even the roughest guess about why it was wrong will bring you closer to what's really happening. There's also a huge amount of value in seeing a wide variety of different failures. Getting something to work by following a pre-tested recipe doesn't teach you much about the dynamics of the system.

Having a mental map with dozens (hundreds) of points grouped as 'this works', 'this is iffy', and 'this fails for this reason' makes you a legitimate expert in the field. It also gives you much better knowledge of how to evolve one thing into another.

2) The correct response to "I don't know" is "let's find out."

There will always be places in the design process where you get stuck on the limits of what you know. That's when you need to stop dealing in abstractions and collect new data. Build the simplest, fastest, cheapest test you can imagine, predict it, do it, record the results, and analyze them. When you have option paralysis, do fast tests with as many options as possible. Give yourself permission to be a bit silly with the tests so they're fun, and you enjoy doing them for their own sake.

It's perversely easy to get caught in a loop of protecting and maintaining ignorance. Learn to recognize that state and bludgeon it out of existence with new, applicable information.

adafruit_support_mike
 
Posts: 62799
Joined: Thu Feb 11, 2010 2:51 pm

Re: Glowplug controller

by seasidemotors on Sun Mar 28, 2021 1:38 pm

Wow! Speechless...In an amazing way. Again, the knowledge drop and the time taken to articulate so much information is so appreciated. I feel in a way an obligation to some how pay back for the time you took to write all of this down for a individual you don't even know. I honestly can't say thank you enough.

I am a fan of 'do anything', ' do something' & 'fail faster'

I knew I wanted to get into microcontrollers but did not really know what I needed to get there so in the interest of 'do something' I purchased a R-Pi3. As my goal has become more defined I am ready to move onto something like the smt32f405, etc. I don't know exactly what I want to do for a programming language but in the interest of 'do anything' I chose Python and started taking a online tutorial. Right now it isn't always clear what or why I am typing the commands but I know that just going through the steps I will 'learn something' and things will become more defined and my path forward more clear. Will I eventually settle on circuit-python, micropython, will I just jump into 'c'? right now I don't know but doing something is better then doing nothing.

You can't run a marathon if you won't lace up the shoes and take the first step, sign up, show up, finish first, finish last, don't finish at all, but just get in the game and do anything to get started in whatever it is that you want to do.

In my case today my goal is to start reverse engineering an existing glow plug controller I have. I am going to identify all the components on the board, identify every capacitor, learn how to read the color bands, identify the different types, and physically draw out the pcb traces. I want to see how the voltage is flowing through, what are the control gates, buck converters, etc. Look up the existing microcontroller currently on the board, compare its published pinouts to what is actually happening on the board, etc. After that I will get a test battery and start making it do its thing. Once I can physically see how it is put together and how it works then I can have a better idea of how to build a better version.

Mike, thanks for such amazing advice, knowledge and time spent writing it all out. I truly feel really welcome here, on other forums I have been met with mediocrity, or even made to feel inferior or just plain unwelcome. Thanks again for the amazing responses, you are a true gentleman and a scholar ;)

seasidemotors
 
Posts: 20
Joined: Wed Mar 24, 2021 9:55 pm

Re: Glowplug controller

by adafruit_support_mike on Sun Mar 28, 2021 11:51 pm

seasidemotors wrote: I feel in a way an obligation to some how pay back for the time you took to write all of this down for a individual you don't even know.

*laugh* If you stick around for a while, you'll find that I do this sometimes. You gave me a perfect excuse. ;-)

seasidemotors wrote:Right now it isn't always clear what or why I am typing the commands but I know that just going through the steps I will 'learn something' and things will become more defined and my path forward more clear. Will I eventually settle on circuit-python, micropython, will I just jump into 'c'? right now I don't know but doing something is better then doing nothing.

Ding! another cue. ;-)

Programmers tend to get philosophical because of something called the Church-Turing Thesis, which is the mathematical foundation of our whole field. It can be summarized (with no loss of accuracy) as "a computer is anything that can do what a computer can do."

Seriously.

In the 1645, Blaise Pascal invented a machine that could add, subtract, and perform multiplication and division by repeated addition/subtraction. It was impressive technically, but a bombshell philosophically: it reduced the most highly respected form of human reasoning to a process that could be done by a machine with no understanding. That led people to wonder, "how far can we take this?"

Great mathematicians butted their heads against that question for centuries. Charles Babbage invented his own version of a calculator, and expanded that to his Analytical Engine which could feed the output of its calculations back to its input. Lady Ada Lovelace, a friend of Babbage (and the origin of Adafruit's name), wrote a set of instructions for the Analytical Engine that we now recognize as equivalent to a computer program. Unfortunately the Analytical Engine was never built, so it remained a theoretical curiosity.

The question got more theoretical interest in the early 20th century. David Hilbert, one of the greatest mathematicians of the age, was interested in finding unanswered questions that would have a major influence on the nature of mathematics. He and William Ackermann formally defined the problem as 'effective computability', defined as the ability to label every possible logical statement as 'true' or 'false' (the Entscheidungsproblem.. I just like saying the name). Kurt Godel refined the definition of effective computability and called the set of all possible solutions 'general recursive functions'.

Godel didn't believe that general recursive functions could be defined systematically, but Alonzo Church did. He created a system called 'lambda calculus', then used that to define a concept of 'lambda-definable functions' that might be equivalent to the set of general recursive functions. He was eventually able to use lambda calculus to prove that the Entscheidungsproblem couldn't be solved (which kind of followed from Godel's work on logic and Incompleteness Theorem). Instead of being able to compute all logical truth mechanically, we're stuck with an infinitely large and complex set of problems we can solve mechanically, an equally large and complex set of problems we can't, and no easy way to know if a given problem can be solved or not.

... As an aside, the unsolvability of the Entscheidungsproblem and Godel's incompleteness theorem were philosophical bombshells of 'sun doesn't move around the Earth' scale.. ever since Pythagoras, people believed that all truth could be derived from a set of self-obvious, self-consistent axioms. Godel and Church proved that couldn't be done, and most of society still hasn't caught up.

When Alan Turing was assigned to break the German Enigma code, he needed a machine that could describe and compare an enormous set of calculable patterns. He defined a logical system that could be converted into a machine, and then began to think his machines could solve any generally recursive/lambda-definable function. He proved it by designing a Turing machine that could do lambda calculus.

A few years later, Church and one of his students, Stephen Kleene, created a set of lambda-calculus expressions that could duplicate a Turing machine. Since each system could implement the other, the set of problems they could solve had to be identical.

And that's as far as we've ever gotten in defining 'computation' or 'computability'. Best we can tell, that's as far as it's possible to go.

That has implications that are important to anyone wanting to learn programming:

First, there's no 'there' there. Programmers are fond of quoting the first line of the Tao Te Ching: "The Tao that can be spoken is not the Tao." There's a natural desire to search for the core ideas of a field so you can build a mental framework to organize the details. In programming the fundamental idea is, "you can only understand fundamental ideas by understanding what makes the details similar." The fastest way for a beginner to generate frustration on both sides is to demand that experts "just tell me how to do it." If the experts are really annoyed, they'll give you half a dozen provably-working solutions that don't seem to resemble each other in any way.

Second, all programming languages are functionally equivalent. Each one pushes some ideas forward and moves others to the background, but all the differences are what Larry Wall, who created the language Perl, calls 'syntactic sugar'. He also makes the interesting point that, since all languages can express the same ideas, the difference between languages isn't so much what you /can/ say as what you /must/ say. In C you have to mark the boundaries between expressions with a semicolon. In Python, you have to put them on different lines. C creates groups of instructions by putting them between braces, Python uses matching indentation. Same chocolate center, different candy shell.

The good news is that anything you learn about programming in one language gives you insight about new ways to program in any language. I don't write many programs in LISP directly, but I use ideas like "write functions that take one list as input and produce another list as output" and "always account for the 'zero', 'one', and 'many' cases" all the time. It's generally called 'programming with a LISP'.

Third, there are no single answers. You can't learn 'programming' from one language, and you can't learn algorithms from only one implementation. Those only give you a view from one angle. You have to see the same ideas expressed in many different ways to discover more and more general ideas of what a thing is.. how the front, side, top, bottom, skin, bones, footprints, call, and DNA are all 'an elephant'.

That's one of my main objections to Python: its determination to enforce one 'correct' solution to any problem. The idea makes sense in the context of Python's history: Guido van Rossum is a computer science professor, and created Python to enforce good programming habits like proper indentation in first-year programming students. Since then, the language has grown and evolved to define 'standard' solutions for any given programming task. I agree that all the standard solutions work, and are worth considering as examples, but they don't stop Python from being able to do anything any other language can do.. which includes creating an ugly mess. The "One True X" mindset is something Python programmers have to un-learn before they can grow beyond the beginner stage as programmers.

On the other hand, programmers who do outgrow Python have a good sense of the fundamentals, and can get a rush from discovering how much bigger and more interesting the world really is.

adafruit_support_mike
 
Posts: 62799
Joined: Thu Feb 11, 2010 2:51 pm

Re: Glowplug controller

by seasidemotors on Mon Apr 26, 2021 10:47 pm

Wow, once again, love the awesome response. I haven't had a chance to swing back by this post in about a month, so I just read your post last night, and again just thoroughly enjoyed everything you put down, amazing. Am I to assume you where once or still are a wise and knowledgeable electronics engineering professor? Your words seem to come from a place of someone who has been around and participated in this industry for quite some time. Anyways, as before I am super appreciative, thank you.

Ok so where have I been, I reversed engineered, the best I could the original GlowPlug controller to see what made it tick and first I made it smoke, but then I got it to tick! LOL

I attempted to identify all the components on the board and was able to get a few things but the resistors eluded me as to their ratings. The main component being a Motorola MC14069UBCP (FHV963B) Hex Inverter. I had originally through this was a ROM chip but it appears not. It seems to drive the time to live (TTL) function although that remains a mystery to me as from what I gathered in data sheet it should be in the order of micro seconds, not 8-10 seconds. I also found what I believe to be 5 Zenner Diodes, 4 Shcottley Diodes, a pair of MPS W13 1w Darlington Transistors( I think these are the smokey culprits from my initial testing :) 12 barrel resistors of varying ratings, 1 ceramic disk capacitor of unknown rating, and a big fat 16v 220uf(M) electrolytic capacitor.

I was able to ID all the pin functions and replicate the operation of the relay and pins. Its really basic in operation but interesting to see exactly how these things work during bench testing. I was able to initially correctly id 3 of the 6 circuits, and speaking of 3 and 6...If I powered both of those pins at the same time the magic smoke started to come out of the smoke box, lol. Turns out pin 3 is Key On power and Pin 6 is a -12v ground the triggers the dash light indicator. But Pin 6 doesn't go low until you apply power to Pin 3.

The operation is as follows, you have a isolated power in, out circuit on the controlled 70amp relay. These are pins(studs) 1 and 5. The other 4 pins are the function and control pins.
Pin 2 is chassis negative ground, Pin 3 is Key On power, Pin 4 is a starter input signal, Pin 6 is negative ground for dash light indicator circuit.

So you have main high amp battery power going to the glowplug relay and multiple power wires going out to power the glowplugs, when you turn the key on this initiates the timer sequence and the relay closes allowing power to flow to glowplugs, while at the same time pulling the indicator light circuit negative. If left uninterrupted the relay will close and the light circuit (light out) will go neutral in 8 seconds, typically this is your signal to crank the engine. When the controller sees the start signal it initiates the glow plug relay during cranking only but does not change the light circuit(It will stay off).

Also, if you are in the 10 second glowplug light sequence and you hit the starter prior to this finishing its full 10 second run, it will obviously kill the timer. The glow plugs will operate during cranking but otherwise the process stops. Example, the engine is already warm and you jump in and don't need to wait for the glow plugs, when you turn the key it will start the 10 second sequence but as soon as it sees the start signal that sequence stops.

In addition to all of this fun I also looked into some official education and started taking an IBM course on Python for data science hosted by edX. It unfortunately was not a pleasant experience and I dropped the class after a few weeks. I got some fundamentals down and am looking into other class options. I see Lady Ada has a circuit python course available on code academy, I will look into it and see if that makes sense for me.

I also happened to pick up a copy of Hackspace and wrangled myself a free Pico in the process so I have been playing with that. I ordered about a $100 worth of loot from the lovely lady ada and am going to follow along with the basic Pi Foundations Pico handbook and just go through all the exercises to keep picking up more knowledge. I was able to successfully solder all 40 of the pico pins without burning the board or bridging any of the pins so that was a good starting victory, lol

I also have been investigating buck converters for automotive use that filter out the noise, reverse polarity protection etc. My thought was to get something like that and datalog the 12-16v signals in and the 5v signal out while driving with a small LCD display. I also found a line of Honeywell pressure sensors that use a 5v sig input and a linear .5v-4.5v output to indicate the pressure reading, so again using the same hardware, add in the sensor, drive the car and datalog the oil pressure and voltages as I give it a good rip through the mountain highways ;)

Oh and I wrote my first 5 led blinky program, tied it in to a push button and it works really well and I kept the code clean, commented on the blocks and what they do. I did get some help here on the forums as to getting some output text to the screen to work properly. I have now used Thonny, JupyterLabs and my go to code writing environment is Vim and remote upload via rshell. Using Vim has been a good experience and it actually works well, and when I was doing the IBM course I would duplicated everything in a Xterm running Python3 so I didn't become crutched on the Jupyter environment. Also forced me to figure out errors, how to install libraries using the pip package manager for Python, etc... Using Vim forces you to really look your code over and really think it through in your head becuase there is no simple run button, the only way to find out is to actually upload that to the controller, get a repl and import it, only then will you get the dreaded error. Then its back to the drawing board, well text editor in this case. Oh ya, you learn Vim in the process, kinda like when your old man just threw you into the deep end of the pool and yelled 'SWIM'! :LOL

Anyways that is my current direction at this point. Look forward to hearing from you again :)
Thanks again and cheers!

seasidemotors
 
Posts: 20
Joined: Wed Mar 24, 2021 9:55 pm

Re: Glowplug controller

by adafruit_support_mike on Tue Apr 27, 2021 3:23 am

seasidemotors wrote:Am I to assume you where once or still are a wise and knowledgeable electronics engineering professor?

*laugh* No, I was a theatre major.. albeit one who took more semesters of calculus than the others.

I was exposed to the idea, "if you can't explain it to an intelligent five-year-old, you don't really understand it yourself" at an early age, and never recovered. I developed a knack of spotting the places where I wanted to hand-wave things I couldn't explain well, and of turning those into personal grudges. Along the way I slogged through far too many pages of equations only to find the authors were making simple ideas complicated as possible, which made me determined to try and do better.

seasidemotors wrote:I attempted to identify all the components on the board and was able to get a few things but the resistors eluded me as to their ratings.

If they have three bands of color, their tolerance is 5%. If they have four bands, their tolerance is 1%. The power rating determines their size, and you can calculate that from the voltage you measure across them when the ciruit is working.

The power equation is P=IV, and Ohm's Law is V=IR. You can combine those to get P=I(IV)=I^2R and P=(V/R)V=V^2/R.

As a rule of thumb, it's a good idea to choose a power rating at least twice the power that actually flows through any component.

seasidemotors wrote:I attempted to identify all the components on the board and was able to get a few things but the resistors eluded me as to their ratings. The main component being a Motorola MC14069UBCP (FHV963B) Hex Inverter. I had originally through this was a ROM chip but it appears not. It seems to drive the time to live (TTL) function although that remains a mystery to me as from what I gathered in data sheet it should be in the order of micro seconds, not 8-10 seconds. I also found what I believe to be 5 Zenner Diodes, 4 Shcottley Diodes, a pair of MPS W13 1w Darlington Transistors( I think these are the smokey culprits from my initial testing :) 12 barrel resistors of varying ratings, 1 ceramic disk capacitor of unknown rating, and a big fat 16v 220uf(M) electrolytic capacitor.

Post a photo of the circuit and I'll see what I can find. Learning to read the hardware is another basic skill, and gets easier with practice.

seasidemotors wrote:In addition to all of this fun I also looked into some official education and started taking an IBM course on Python for data science hosted by edX. It unfortunately was not a pleasant experience and I dropped the class after a few weeks. I got some fundamentals down and am looking into other class options. I see Lady Ada has a circuit python course available on code academy, I will look into it and see if that makes sense for me.

Keep looking until you find something that fits your needs and interests. A class/book/description that doesn't work for you comes from someone who's thinking about the subject in a different way, and there's infinite room to do that. Think of them as dialects you don't understand yet.

Once you're more comfortable with the language and the basic practices of coding, you can often come back to those and think, "oh, that's what they were saying." Your opinion of whether it was worth saying will also evolve, but never to the point of excusing everything.

seasidemotors wrote:I also happened to pick up a copy of Hackspace and wrangled myself a free Pico in the process so I have been playing with that. I ordered about a $100 worth of loot from the lovely lady ada and am going to follow along with the basic Pi Foundations Pico handbook and just go through all the exercises to keep picking up more knowledge.

That's tremendously good when you're just getting started. Copy, copy, copy, and copy some more. The simple act of typing code from a page verbatim into a computer is valuable because it forces you to look at every line, every variable, and every function call. Mark Twain was a printer's devil in his early teens, and later said, "one can only set so many acres of type before developing opinions about the writing." Code is the same way. The basic furniture gets used over and over again, and will become familiar through repetition. A large fraction of any program is basic bookkeeping, and doesn't present much challenge. The parts where you have to think are where the original programmer chose to approach some problem in a specific way.

As you get more experienced, you'll learn that almost all code is either trivial or copied from somewhere else. The trick is building a good bag of tricks and learning to apply them in different circumstances. Before long, you'll find yourself copying the ideas and strategies instead of the exact keystrokes.

seasidemotors wrote:I was able to successfully solder all 40 of the pico pins without burning the board or bridging any of the pins so that was a good starting victory, lol

Well done!

Honestly though, solder wick and extra flux are the circuit builder's secret weapons. Everyone get a bridge or a chubby joint once in a while, and being able to pull the excess solder away is a secondary skill. The tricks that turn a slightly messy board into a showpiece aren't hard to learn.

seasidemotors wrote:Oh and I wrote my first 5 led blinky program, tied it in to a push button and it works really well

Bravo!

seasidemotors wrote:I kept the code clean, commented on the blocks and what they do.

Set a reminder to go back and read the whole thing from beginning to end a couple of months from now.

There is no better way to learn how to organize code and write comments than reading code that already exists. Every time you do, your programmer side learns more about what the reader side will eventually want to know. I'm still evolving my own style, and being surprised at how different the two mindsets are.

seasidemotors wrote:my go to code writing environment is Vim

Gabba gabba, one of us! one of us! ;-)

People have strong opinions about code editors, but most of us eventually learn peaceful coexistence. I also happen to like vim, so it's worth a high-five to any other partisan.

seasidemotors wrote:Using Vim forces you to really look your code over and really think it through in your head becuase there is no simple run button, the only way to find out is to actually upload that to the controller, get a repl and import it, only then will you get the dreaded error. Then its back to the drawing board, well text editor in this case.

The older tools do have some advantages over the newer ones.

First of all, they were written for programmers by programmers and relentlessly tuned to fit a general workflow. Second, the things that some people find clunky are good at maintaining the programming mindset.

The programs we have today are called 'text editors' because that's what 99% of their features do: change something that's already been written. They make it easy to spend hours twiddling and changing things, only to delete it all and vaporize a few hours of work. The effort of moving the cursor around the page in vim, and of dealing with the commands to change something, makes editing less atrractive than writing.

BTW: if you haven't learned ": set autoindent", it makes programming even nicer.

adafruit_support_mike
 
Posts: 62799
Joined: Thu Feb 11, 2010 2:51 pm

Please be positive and constructive with your questions and comments.