Software for brakes, yah right

The problem is that one of the big efficiency issues is to use regenerative braking. In other words, to slow the vehicle, you use the motor as a generator and then charge the battery with it. The regen braking does virtually all the braking.

The question becomes, how do you mechanically control that? It is going to take electronic hardware and software. The problem really lies in production cycle times. In order to be first to the market, companies press engineering to do upgrades fast. Not enough time is take any more to test equipment well enough before being pushed into production. One of the reason FBW aircraft cost so much is the level of testing performed.

I have a bit of background in this. I finished the test hardware and software for the ATFLIR (advanced targeting forward looking infra Red) system for the FA18 last year.
 
Why does everyone hate electronics so much? I mean inevitably more parts = greater chance of failure, but simply because something is electronic, rather than mechanical, doesn't make it inferior... Simply different.

/EE student.

I've nothing in particular against electronics, when they're used where they're appropriate.

That place is not as a replacement for mechanical or hydraulic systems with a well-proven track record. I don't even like ABS - I find it limiting. "Speed sensitive" steering just screws me up, although "Electronic Stability Control" is sorta useful to the inattentive. Electronic engine controls are more adaptable than old mechanical systems, although it did take me a while to get used to them (especially when you deal with non-OBD DIS systems that allow for full programmability of spark and fuel delivery parameters. Killer!)

But I want my throttle controlled by a simple mechanical cable linkage, I want my brakes controlled with a simple hydraulic circuit, and let's not screw those up. "The more they overhaul the plumbing, the easier it is to stop up the drain."
 
the number 2 in binary is written "11".
That help?
Something about keep your mouth shut and be thought a fool rather then open it and remove all doubt. What the hell was it dad said all those years ago,....:doh:
 
It is when there's a single bit error :dunno:

I thought you got the joke, you shoulda kept your mouth shut :spin1:
 
I thought you got the joke, you shoulda kept your mouth shut :spin1:
Yeah, well,... live and learn. Or at least live.
I was thinking about something else. Funny part is, I was thinking, "That looks wrong." when I posted it :dunno:

Maybe I should pay attention more then twice a day.
 
Yeah, well,... live and learn. Or at least live.
I was thinking about something else. Funny part is, I was thinking, "That looks wrong." when I posted it :dunno:

Maybe I should pay attention more then twice a day.

"You live and learn. Or you don't live long."

Engineer's Error Maxim - "1+1-3. For extremely large values of 1."

If you have to remove the system to remove the potential for error, then do so. Electronics have their place, but their place is not everywhere.
 
It's not just engineers- most people who wear ties to work, think they're better than people who don't. Just simple insecurity from folks who have no useful skills. A good engineer would be too busy making his project work to blame a bunch of tinkerers for pointing out that he did it wrong. edit- And in my experience, they're normally tinkerers themselves.

Sometimes they're tinkerers themselves. In my experience working in the Manufacturing Industry (a summer of running/fixing a injection molding machine that spit out Toyota ignition parts), the Engineers upstairs looked down at us floor workers as morons.....dumb machine operators. Yet when we discovered problems in the parts and tried to inform them about it, they wanted to hear nothing of it. Most times, it took physically running a bad batch of parts, right before their eyes, as instructed by their designs to prove to them there was a problem. It was quite fun to explain to them why it was a bad design, or even better when the machine went down for repairs and they got all riled up because parts weren't bein spit out. We'd purposely speak "machine lingo" and watch their heads spin :D

Now that i'm about to graduate with a MET degree, i'm seeing even more of the same types of Engineers looking to hire graduates. They're looking for grads who have insanely high GPA's (meaning they're book smart and have little to no hands on experience)...which sucks for people like me who are the opposite.
 
the Engineers upstairs looked down at us floor workers as morons.....dumb machine operators. Yet when we discovered problems in the parts and tried to inform them about it, they wanted to hear nothing of it.

Tell me about it. The production engineer i worked with was really good. The ones above him though were assholes and most wouldn't even talk to me because I was common "floor scum" as we have been called by management. If it wasn't for us they wouldn't have a job! The two of us could usually get the machines running pretty quick. Of course they were very new when i ran them so we didn't have replacement parts built up in the factory yet. So if there was a major problem, we had to call the company who we got them from and have them send out a service guy since they were under warranty! :D


Toyota will figure it out I am sure and the Priece of Junk will be selling once again! I love electronics but for something that i am going to use for camping, fishing and wheeling. I don't need all that stuff!
 
Sometimes they're tinkerers themselves. In my experience working in the Manufacturing Industry (a summer of running/fixing a injection molding machine that spit out Toyota ignition parts), the Engineers upstairs looked down at us floor workers as morons.....dumb machine operators. Yet when we discovered problems in the parts and tried to inform them about it, they wanted to hear nothing of it. Most times, it took physically running a bad batch of parts, right before their eyes, as instructed by their designs to prove to them there was a problem. It was quite fun to explain to them why it was a bad design, or even better when the machine went down for repairs and they got all riled up because parts weren't bein spit out. We'd purposely speak "machine lingo" and watch their heads spin :D

Now that i'm about to graduate with a MET degree, i'm seeing even more of the same types of Engineers looking to hire graduates. They're looking for grads who have insanely high GPA's (meaning they're book smart and have little to no hands on experience)...which sucks for people like me who are the opposite.
I hate that. Most (not all) of the 4.0 GPA guys I interviewed couldn't tell me much of anything. I asked a question about how to debug/fix a multiprocessor system with an issue in firmware causing error log corruption (one error log, multiple processors writing to it - huge hint there) and he couldn't even give me the word "semaphore" or "mutex". Either of those would have answered the question... The guys with low 3.x GPAs could though, and usually knew where such code was located in the Linux kernel, heck, one of them had ported Linux to a processor he and his teammates had DESIGNED THEMSELVES as their senior project. He knew exactly what I was talking about and his GPA was lousy, nearly as bad as mine :roflmao:. Maybe I expect too much, but how are you supposed to find bugs on a many-processor prototype server if you don't even know basic operating systems/microprocessor arch stuff?

Too much emphasis is placed on rote learning and grades and not enough is placed on understanding. As a result we get engineers who will bust their asses working on something but never truly understand what they are actually DOING, they are just bashing on it until it "works as specified" and then shipping it.
 
I hate that. Most (not all) of the 4.0 GPA guys I interviewed couldn't tell me much of anything. I asked a question about how to debug/fix a multiprocessor system with an issue in firmware causing error log corruption (one error log, multiple processors writing to it - huge hint there) and he couldn't even give me the word "semaphore" or "mutex". Either of those would have answered the question... The guys with low 3.x GPAs could though, and usually knew where such code was located in the Linux kernel, heck, one of them had ported Linux to a processor he and his teammates had DESIGNED THEMSELVES as their senior project. He knew exactly what I was talking about and his GPA was lousy, nearly as bad as mine :roflmao:. Maybe I expect too much, but how are you supposed to find bugs on a many-processor prototype server if you don't even know basic operating systems/microprocessor arch stuff?

Too much emphasis is placed on rote learning and grades and not enough is placed on understanding. As a result we get engineers who will bust their asses working on something but never truly understand what they are actually DOING, they are just bashing on it until it "works as specified" and then shipping it.

Yeah tell me about it. I could care less about keeping my head stuck in the books...i've always been a "take it apart and see if it works when you put it back together" guy....best way to learn! Just have a hard time even getting employers to talk to me since I don't have at least a 3.0.
 
I graduated with a 3.03. Somehow managed to pull all As my last semester, well, rather, failed everything I didn't ace - WPI has the A/B/C/NR (No Record) system, so it affected my grades just like the ones I failed didn't even exist.

Yeah, I cut it a little close...
 
I used to get that crap all the time, had super paper qualified individuals applying and pressure from above to hire them vs the ones with experience and knowledge. Ended up setting up a test lab, 2 hp 9000, Gateway novell server, NT4.0 server, cisco router, two work stations, hp_ux and a windows box. All the media and startup manuals and config sheets, all machines wiped and blank. Simple test, install the OS's, bring the network up on the net, oh and I'll keep your cell phone for you. I could usually tell in less than 30 minutes if they had a clue. The person who fired off all the installs in a row was usually done in less than 3 hours. Amazing the number of green card engineers with masters degrees in computer science from bombay U that could not even figure out how to boot a HP9000 off of the cd drive or even start the install of a Novell server.
Our HR manager that found all these cheap degreed people used to give me death looks but my hiring test was pretty non partial, simple and straight forward. One time I hired two of his choices based on his word alone and made sure he understood that, cost the company close to a half million to fix what they screwed up on the customers site in less than 2 months. While I still got the death looks he never questioned my choices after that.
 
Which is why I am a huge fan of the "practical interview."

I'll talk with you for fifteen minutes or so, then I'll hand you a problem to solve. Chances are pretty good it's something I'm in the middle of anyhow, I'll tell you it's something I've been working on, and it's a bad sign when you don't ask me for my notes (or even ask how far along I've gotten...)

Even if I end up paying them for an hour's work, it's worth the trouble. I'd rather pay them for screwing up an hour on an isolated issue than find out they're worthless when the fit really hits the shan...
 
One of my interviewers was confused when he gave me his zero-credit, "pet question" - which was a simple non-base-ten math problem. He picked numbers out of a hat and wrote "divide 1Ch by 2o (2 octal)" on the board.

Me: Should I write the answer down or just say it?
Him: Whatever works for you...
Me: oh, well, it's 0Eh (14).
Him: uh, how'd you do that?
Me: dividing by any power of two is easy, bit shift right by log2(divisor)

Apparently everyone he had ever asked did it the textbook way - convert to decimal (sometimes making a mistake), divide, convert to whatever number base (sometimes making a mistake again.) He said most people get it wrong (these are computer engineers being interviewed! WTF?!) and no one ever just bit-shifted right by one in their head and told him the answer before...

How the hell do computer engineers get away with not knowing stuff like that?

Reminds me, next time I'm interviewing someone I need to ask them how to multiply an 8 bit number by 256 using only 16 wires...
 
One of my interviewers was confused when he gave me his zero-credit, "pet question" - which was a simple non-base-ten math problem. He picked numbers out of a hat and wrote "divide 1Ch by 2o (2 octal)" on the board.

Me: Should I write the answer down or just say it?
Him: Whatever works for you...
Me: oh, well, it's 0Eh (14).
Him: uh, how'd you do that?
Me: dividing by any power of two is easy, bit shift right by log2(divisor)

Apparently everyone he had ever asked did it the textbook way - convert to decimal (sometimes making a mistake), divide, convert to whatever number base (sometimes making a mistake again.) He said most people get it wrong (these are computer engineers being interviewed! WTF?!) and no one ever just bit-shifted right by one in their head and told him the answer before...

How the hell do computer engineers get away with not knowing stuff like that?

Reminds me, next time I'm interviewing someone I need to ask them how to multiply an 8 bit number by 256 using only 16 wires...


This reminds me of a Lab assignment I did last week. I had to design a simple circuit that would multiply (in base 2) by either 0,1, or 2.

obviously 0*x = 0, and 1*x = x. Then everyone started to design these insanely complex circuits to multiply by two... I just bit shifted. (extra credit :laugh2:)
 
Clever. If you've done any x86 assembly...

what's a way you can multiply a register by 3, 5, or 9 with a single instruction that is NOT a multiply? (note: the values 3, 5, and 9 are a HUGE hint!)
 
One of my interviewers was confused when he gave me his zero-credit, "pet question" - which was a simple non-base-ten math problem. He picked numbers out of a hat and wrote "divide 1Ch by 2o (2 octal)" on the board.

Me: Should I write the answer down or just say it?
Him: Whatever works for you...
Me: oh, well, it's 0Eh (14).
Him: uh, how'd you do that?
Me: dividing by any power of two is easy, bit shift right by log2(divisor)

Apparently everyone he had ever asked did it the textbook way - convert to decimal (sometimes making a mistake), divide, convert to whatever number base (sometimes making a mistake again.) He said most people get it wrong (these are computer engineers being interviewed! WTF?!) and no one ever just bit-shifted right by one in their head and told him the answer before...

How the hell do computer engineers get away with not knowing stuff like that?

Reminds me, next time I'm interviewing someone I need to ask them how to multiply an 8 bit number by 256 using only 16 wires...


I remember learning that. Our professor emphasized the point that you should NOT be switching between the numbering systems for it. I'm surprised that real world engineers are unaware of it.

I haven't touched any kind of computer engineering work since I graduated (now a systems engineer)...been moving more towards modeling civil communications networks.
 
Clever. If you've done any x86 assembly...

what's a way you can multiply a register by 3, 5, or 9 with a single instruction that is NOT a multiply? (note: the values 3, 5, and 9 are a HUGE hint!)

Hmmm, cant think of anything off the top of my head. Fill me in.
 
example...

lea eax, [eax*4+eax]

The *4 makes use of the SIB (scalar, index, base) byte included in some instructions that allow extended addressing modes. You can only multiply by those numbers because they are powers of two, plus one, from the allowed range (*2 is also allowed, but there are a million other uninteresting ways to do that - lea eax, [eax*2] or lea eax, [eax+eax] or even just add eax, eax, or shl eax, 1...)

</nerd>
 
example...

lea eax, [eax*4+eax]

The *4 makes use of the SIB (scalar, index, base) byte included in some instructions that allow extended addressing modes. You can only multiply by those numbers because they are powers of two, plus one, from the allowed range (*2 is also allowed, but there are a million other uninteresting ways to do that - lea eax, [eax*2] or lea eax, [eax+eax] or even just add eax, eax, or shl eax, 1...)

</nerd>


OK less of this: :paperwork and Nerd stuff more Toyota accelerator issues! :D You may as well be speaking Swahili to me!
 
Back
Top