Fisker Buzz Forums banner

Bad Karma - it left me stranded!

33530 Views 111 Replies 26 Participants Last post by  kabalah70
My car has about 160 miles on it with 6.14 loaded. On Monday it would not go into D or R. I did several hard reboots and it didn't fix it. The Altanta Fisker tech came over to my house and did another hard reboot and it worked.

So this morning I go to take the kids to school and it wouldn't go into D or R. I did a hard reboot and it worked.

Dropped off one of the kids at pre-school and when I came outside, the car wouldn't go into D or R. I tried several hard reboots and it didn't work. So there I sat in a parking lot with my hood open for 30 minutes wondering what would have happened if my wife were driving with our two small kids. This is not acceptable.

A car made in 2011 or 2012 should never leave a person stranded. Software bugs I can handle, but this is not going to be a car I can depend on until they work out this bug.

After 30 minutes I did another hard reboot and it worked. Took the car home and parked it. I'm be driving the Ford today.
41 - 60 of 112 Posts
Fabulist said:
I am not going to argue with Newtonian physics, but as a practical matter, no manufacturer is going to purposely over engineer any part of a car only to limit it by software. There is undoubtedly one component in the
Battery+Generator->Inverter->Motor circuit that cannot handle more power than the maximum stated limit and that could be the inverters, the motors, or even the power cables. So even if you can get the power generation system to liberate more than 300KW, you may end up burning up the inverter, motor, the cables, or something else.

-- Fab.
The other big problem with any linear calculation is that the thrust available from the electric motors is not constant, and not even linear.

Consider the torque graph here, of a typical electric-pump motor: http://www.engineeringtoolbox.com/electrical-motors-torques-d_651.html

Horsepower is torque x RPM. In an ideal motor horsepower remains constant as torque approaches infinity (because torque at 0 is infinity, and torque at infinity is zero, and in between, the product is a constant, so the limit from above zero and the limit from below infinity are the same constant as the horsepower anywhere in between). No electric motor is ideal, though. Here's a graph of an actual EV electric motor:

http://www.evme.com.au/performance/power/

The green line is horsepower (well, actually kW output as read off the right hand scale, just multiply by 4/3 to get hp). The red line is torque. The maximum available torque (about 225 Nm) is essentially constant, rather than rising to infinity, below about 3500 RPM.

I don't have a torque curve for the Karma's electric motor, but we do know the maximum value (1300 Nm). We can find an approximation though ... let's assume it's flat up to about X mph and then drops in a nice curve from then on, giving linear horsepower (which we know is ~403 hp, which is 300 kW) as in an ideal electric motor.

Now, actual power output (in watts) is torque (in newton-meters) times 2pi times rotational speed (in revs/sec aka RPS). (see: http://en.wikipedia.org/wiki/Torque)

The Karma's rear tires are Goodyear 285/35R22 with an outside diameter of 29.9 inches (0.759 meters). To go 1 mile, this tire must turn (1 mile / (29.9 pi) inches) times, or about 880.7 times. At 60 mph, one mile takes 60 seconds, so the tire turns 880.7 rotations per 60 seconds or about 14.7 RPS. We've assumed peak horsepower arrives at X mph (and remains constant from then on), so we get our peak output at X rather than 60, or X/60ths of this RPS. But hang on a second, that RPS is tire rotation speed, not motor speed. We need to put in the correction factor for the final drive ratio, which is 4:1.

Plugging all these in, we have: 300,000 = 1300 * 2pi * (X/60) * 14.7 * 4. Now we just need to solve for X. Move all the constants to the left, giving: 60 * (300000 / 1300 / 2pi / 14.7 / 4) = X, and compute. The result I get is about 37.5.

If this is correct, then the power output of the electric motors rises linearly with speed up to 37.5 mph. (This is because power is torque—which we've assumed is constant up to X, which we just calculated as 37.5 mph—times 2pi times RPS, and RPS is linear with speed.) After that the power has hit the 300 kW limit and remains constant.

(This fits pretty well with the feel of the car, where the acceleration eases up a bit above 40 mph.)

This all means that 0-60 time is not determined by 300 kW, but rather by the integration of the variable power output up to 37.5 mph, followed by the fixed 300 kW output from 37.5 to 60. I will leave that calculation for someone else, or another day, because it is almost 3 AM here now... :D
See less See more
Nimisys said:
Part of it is the current draw out of the batteries and heat build up in the inverters. There are limits to how much and how quickly you can pull current from the battery, and they are not that far out of reach in normal usage. You also have the additional heat generated from converting the DC voltage to AC voltage needed for the traction motors. The heat tolerances for the converters is also fairly low: 150F, any hotter and they go into a limp mode.
Nimisys
You seem to have inside info on the mechanics and software. Are you a Fisker tech?

BillyO[hr]
Sigurd said:
The greatest statement all morning:

ffcars said:
I'm not sure why my wife took the car. And I'm sure as heck not going to ask.
I have the same problem as FF. I'm married. I can't imagine what I'd have to listen to after spending $100K on a car that doesn't work, I could never complain about the price of hand bags again.

BillyO
I suppose it is fun to daydream about performance, but as others have stated in the forum, if that is what you are looking to buy or bought a Karma for, you will be dissappointed. As for asking Fisker to give us more performance, I would say that we should focus our efforts as consumers on getting things that were promised fixed like 'remote cabin preconditioning' and upgrades/changes that are simple things that can be done with a tweek of the software without worrying about parts degradation and warranty issues, like Command Center and instrument display formatting. Just my two cents.
I'd be happy if they just got the existing enabled functionality to be rock- solid for now. It may just be being in Northern California spoils me, but I'd rather have remote cabin AC come 3 months from now, and have the immediate focus be on getting the DNR issue, or the black dash cluster I had that last night, fortunately I was at home) fixed first. Get the automotive part working reliably before worrying about creature comforts. It'll be a nice day when we can all say "I haven't heard of anyone getting stranded or being scared to drive the car, in more than a month"...
Nimisys said:
Part of it is the current draw out of the batteries and heat build up in the inverters. There are limits to how much and how quickly you can pull current from the battery, and they are not that far out of reach in normal usage. You also have the additional heat generated from converting the DC voltage to AC voltage needed for the traction motors. The heat tolerances for the converters is also fairly low: 150F, any hotter and they go into a limp mode.
From what I read A123 battery is great for 'power' application. The data sheet shows a power curve versus % State of Charge. Looks like the battery is not a limiting factor. Cables might be.

The inverters are a limiting factor as you described it. How can you improve the inverter to soup up the Karma?

The 'limp' mode you described could explain why Siliconkiwi experienced less acceleration couple of times, then next day after it cools off, he got GREAT acceleration.

Also is it a race problem with the 'stuck' PRND when pressed too early during start up? Why not have shut down options like Windows Vista; 'sleep', 'shut off'? For 'sleep', the car can come out of boot quicker and avoid 1) the delay to the 'Agree' screen and 2) the race condition with the PRND. Is a complete shut down and reboot a requirement?


Fabulist said:
I am not going to argue with Newtonian physics, but as a practical matter, no manufacturer is going to purposely over engineer any part of a car only to limit it by software. There is undoubtedly one component in the
Battery+Generator->Inverter->Motor circuit that cannot handle more power than the maximum stated limit and that could be the inverters, the motors, or even the power cables. So even if you can get the power generation system to liberate more than 300KW, you may end up burning up the inverter, motor, the cables, or something else.

-- Fab.
Make perfect sense of what you said. :D

ct-fiskerbuzz said:
Fabulist said:
I am not going to argue with Newtonian physics, but as a practical matter, no manufacturer is going to purposely over engineer any part of a car only to limit it by software. There is undoubtedly one component in the
Battery+Generator->Inverter->Motor circuit that cannot handle more power than the maximum stated limit and that could be the inverters, the motors, or even the power cables. So even if you can get the power generation system to liberate more than 300KW, you may end up burning up the inverter, motor, the cables, or something else.

-- Fab.
The other big problem with any linear calculation is that the thrust available from the electric motors is not constant, and not even linear.

Consider the torque graph here, of a typical electric-pump motor: http://www.engineeringtoolbox.com/electrical-motors-torques-d_651.html

Horsepower is torque x RPM. In an ideal motor horsepower remains constant as torque approaches infinity (because torque at 0 is infinity, and torque at infinity is zero, and in between, the product is a constant, so the limit from above zero and the limit from below infinity are the same constant as the horsepower anywhere in between). No electric motor is ideal, though. Here's a graph of an actual EV electric motor:

http://www.evme.com.au/performance/power/

The green line is horsepower (well, actually kW output as read off the right hand scale, just multiply by 4/3 to get hp). The red line is torque. The maximum available torque (about 225 Nm) is essentially constant, rather than rising to infinity, below about 3500 RPM.

I don't have a torque curve for the Karma's electric motor, but we do know the maximum value (1300 Nm). We can find an approximation though ... let's assume it's flat up to about X mph and then drops in a nice curve from then on, giving linear horsepower (which we know is ~403 hp, which is 300 kW) as in an ideal electric motor.

Now, actual power output (in watts) is torque (in newton-meters) times 2pi times rotational speed (in revs/sec aka RPS). (see: http://en.wikipedia.org/wiki/Torque)

The Karma's rear tires are Goodyear 285/35R22 with an outside diameter of 29.9 inches (0.759 meters). To go 1 mile, this tire must turn (1 mile / (29.9 pi) inches) times, or about 880.7 times. At 60 mph, one mile takes 60 seconds, so the tire turns 880.7 rotations per 60 seconds or about 14.7 RPS. We've assumed peak horsepower arrives at X mph (and remains constant from then on), so we get our peak output at X rather than 60, or X/60ths of this RPS. But hang on a second, that RPS is tire rotation speed, not motor speed. We need to put in the correction factor for the final drive ratio, which is 4:1.

Plugging all these in, we have: 300,000 = 1300 * 2pi * (X/60) * 14.7 * 4. Now we just need to solve for X. Move all the constants to the left, giving: 60 * (300000 / 1300 / 2pi / 14.7 / 4) = X, and compute. The result I get is about 37.5.

If this is correct, then the power output of the electric motors rises linearly with speed up to 37.5 mph. (This is because power is torque—which we've assumed is constant up to X, which we just calculated as 37.5 mph—times 2pi times RPS, and RPS is linear with speed.) After that the power has hit the 300 kW limit and remains constant.

(This fits pretty well with the feel of the car, where the acceleration eases up a bit above 40 mph.)

This all means that 0-60 time is not determined by 300 kW, but rather by the integration of the variable power output up to 37.5 mph, followed by the fixed 300 kW output from 37.5 to 60. I will leave that calculation for someone else, or another day, because it is almost 3 AM here now... :D
Nice :thumbup:

Now, why did they pick a 4:1 final gear ratio and not a 3:1 or 2.5:1? :D
2.5:1 gives you 60 mph. :p
[hr]
kabalah70 said:
I suppose it is fun to daydream about performance, but as others have stated in the forum, if that is what you are looking to buy or bought a Karma for, you will be dissappointed. As for asking Fisker to give us more performance, I would say that we should focus our efforts as consumers on getting things that were promised fixed like 'remote cabin preconditioning' and upgrades/changes that are simple things that can be done with a tweek of the software without worrying about parts degradation and warranty issues, like Command Center and instrument display formatting. Just my two cents.
Agree to what you said. :p
Got carry away with mental exercise. :blush:
See less See more
Sparky168 said:
From what I read A123 battery is great for 'power' application. The data sheet shows a power curve versus % State of Charge. Looks like the battery is not a limiting factor. Cables might be.

The inverters are a limiting factor as you described it. How can you improve the inverter to soup up the Karma?

The 'limp' mode you described could explain why Siliconkiwi experienced less acceleration couple of times, then next day after it cools off, he got GREAT acceleration.

Also is it a race problem with the 'stuck' PRND when pressed too early during start up? Why not have shut down options like Windows Vista; 'sleep', 'shut off'? For 'sleep', the car can come out of boot quicker and avoid 1) the delay to the 'Agree' screen and 2) the race condition with the PRND. Is a complete shut down and reboot a requirement?

Now, why did they pick a 4:1 final gear ratio and not a 3:1 or 2.5:1? :D
2.5:1 gives you 60 mph. :p
The problem isn't the level vs SoC, its the rate in which the power is being pulled out. Pull too much out to quickly and you damage the cells, or their control modules. There is protection software present to prevent that from happening. Holding WOT for 10 seconds, lift off and then doing WOT for 10 seconds again and again and you will start to run into the protection limiters. they are outside normal usage, but not that hard to find either. generally only a minute or two of low throttle/cruise application is needed to get back out of the limited mode.

The stuck PRND and Agree Delay are mostly timing issues. the PRND switch actually is a module that communicates with 6 others before changing the LED indicating mode/gear. Similar for the Command center. You have 4 data busses and everything trying to talk to each other, and somethings need to happen in a very specific order. when you rush the commands in a "Race" condition, it is possible to interrupt some of those commands and knock requests and needed information out, causing longer delays, or modules not recieivng a wake up command or a state of health message, etc. It is a delicate balance prioritizing the messages and giving the user a feeling of quickness, something ALL manufacterers deal with. The ground re-works were to help lower resistance to the ground path for some modules, there by helping signalling quality and fewer dropped messages between modules. The 614 update is suppose to help further with the dash and command center

A sleep mode isn't possible because you need the modules to use as little 12v power as possible when the car is shutoff, a 500mA draw will kill a 12 volt battery overnight, and with no 12V battery you can not power up the modules needed to control the HV supply.

4.1:1 was choosen to give better off the line performance as its avialable torque to the axles is 3836ft/lbs vs the 2397.5ft/lbs of 2.5:1.
See less See more
Nimisys said:
...when you rush the commands in a "Race" condition, it is possible to interrupt some of those commands and knock requests and needed information out, causing longer delays, or modules not recieivng a wake up command or a state of health message, etc.
Why does the system allow you to interrupt initialization and proceed with startup before it's fully ready?
Nimisys - thanks! Either you're making this all up or you know exactly what you're talking about ;-) I'm inclined to believe the latter.

What is WOT? My sluggishness issues have been either at metering lights (or stop lights), and there is no discernible difference in environment between a "good day" and a "sluggish day". Temperature and driving patterns are about as close as you can get (Northern California is pretty temperate, and the weather over the last week has been very constant).

I'm not sure I buy the race condition excuse. Designing out race conditions is hard but far from impossible. Albeit this is a complex car and the number of permutations for input conditions and timing of state machine inputs is more than average cars, but it's well below many other control systems (aeronautics, industrial control, server loads, etc.), all of which have to factor in unreliable delivery of messages too. I'm definitely not criticizing the information sharing (again, thank you for that!), but to the many engineer owners on this forum it seems like these problems should be able to be addressed provided the car has sufficient processing power and the SNR on message delivery is high. Beyond that the usual iron triangle issues (schedule versus cost versus quality/functionality/complexity) apply, from the outside it seems like a iron triangle issue, not that the engineering problems are insurmountable. I'd love to hear your opinion on this, of you're comfortable expressing it.
See less See more
Nimisys said:
The problem isn't the level vs SoC, its the rate in which the power is being pulled out. Pull too much out to quickly and you damage the cells, or their control modules. There is protection software present to prevent that from happening. Holding WOT for 10 seconds, lift off and then doing WOT for 10 seconds again and again and you will start to run into the protection limiters. they are outside normal usage, but not that hard to find either. generally only a minute or two of low throttle/cruise application is needed to get back out of the limited mode.

The stuck PRND and Agree Delay are mostly timing issues. the PRND switch actually is a module that communicates with 6 others before changing the LED indicating mode/gear. Similar for the Command center. You have 4 data busses and everything trying to talk to each other, and somethings need to happen in a very specific order. when you rush the commands in a "Race" condition, it is possible to interrupt some of those commands and knock requests and needed information out, causing longer delays, or modules not recieivng a wake up command or a state of health message, etc. It is a delicate balance prioritizing the messages and giving the user a feeling of quickness, something ALL manufacterers deal with. The ground re-works were to help lower resistance to the ground path for some modules, there by helping signalling quality and fewer dropped messages between modules. The 614 update is suppose to help further with the dash and command center

A sleep mode isn't possible because you need the modules to use as little 12v power as possible when the car is shutoff, a 500mA draw will kill a 12 volt battery overnight, and with no 12V battery you can not power up the modules needed to control the HV supply.

4.1:1 was choosen to give better off the line performance as its avialable torque to the axles is 3836ft/lbs vs the 2397.5ft/lbs of 2.5:1.
Thanks so much for providing facts and inside knowledge to explain the engineering design decisions and behavior of the Karma. We all appreciate it. :thumbup:

I have about 1000 miles on my Karma, the last 250 with the grounding changes and 6.13.5 installed. I don't sense that it has reduced the dropped messages between modules. In the past week I have seen the speedo not work, the front parking sensors beeping not shut off (twice), the Agree screen not be presented such that only the Fisker logo is displayed, the backup camera image not activated when selecting Reverse, etc.

My daily routine has a lot of short trips, so my Karma goes through quite a few startup/shutdown cycles in a day. Hopefully 6.14 will improve this - I plan to have my dealer install it as soon as it becomes available. IMO it is critical that Fisker completely solve this class of problems. I hope it is being given the highest priority within Fisker Engineering.
See less See more
dennis said:
I have about 1000 miles on my Karma, the last 250 with the grounding changes and 6.13.5 installed. I don't sense that it has reduced the dropped messages between modules. In the past week I have seen the speedo not work, the front parking sensors beeping not shut off (twice), the Agree screen not be presented such that only the Fisker logo is displayed, the backup camera image not activated when selecting Reverse, etc.
Ditto here. I'm beginning to lose faith that they know what they're doing.

-Brian
matrix said:
Nimisys said:
...when you rush the commands in a "Race" condition, it is possible to interrupt some of those commands and knock requests and needed information out, causing longer delays, or modules not recieivng a wake up command or a state of health message, etc.
Why does the system allow you to interrupt initialization and proceed with startup before it's fully ready?
I am guessing (not involved in writing the software, haven't seen the hardware specs, etc) but I think you are misinterpreting what Nimisys said, and the answer to "why does it" is "it doesn't".

The problem lies in sending messages across the data buses (think Ethernet or wi-fi network, except it's probably CAN and I2S and all the other crappy automotive buses :dodgy: that I have been fortunate enough never to have to write low level software for). Depending on the design and so on, it's possible for multiple different devices sitting on a bus to attempt to send something at the same time, and "knock each other out". This happens all the time on Ethernet; there's a defined back-off protocol. It happens "never" on token-ring networks but they simply trade off for a different problem (but back in the late 1980s IBM used to try to sell token ring instead of Ethernet with a bunch of nonsense about how token ring never suffered from packet collisions).

Most inside-a-computer or in-a-room-full-of-computers networks have the luxury of high-grade signals and low noise levels (i.e., high signal-to-noise levels) and plenty of power and so on. When you start working in the "icky dirty environments" inside a car you lose all that. (Airplane software and hardware has similar constraints, except that they re-acquire the luxury of the cabin crew telling everyone that they have to turn off all their cell phones and other electronics.)

Anyway, it can be done, it just takes a lot of skull-sweat.[hr]
siliconkiwi said:
What is WOT?
WOT = Wide Open Throttle

(I can't really address any of the rest that you wrote, since I agree with it :D)
See less See more
I was just stranded with essentially the same problem. Car engine never came on in stealth mode despite a full tank of gas and therefore battery ran all the way out and died on the freeway with 2 kids in the back. Did have PRND warning light that came on while driving earlier today but it didn't affect the driving and thought it may be a software problem that the dealer could fix next week. I already have the 6.14 upgrade so that clearly is not the answer....Oh well,
dbjr said:
I was just stranded with essentially the same problem. Car engine never came on in stealth mode despite a full tank of gas and therefore battery ran all the way out and died on the freeway with 2 kids in the back. Did have PRND warning light that came on while driving earlier today but it didn't affect the driving and thought it may be a software problem that the dealer could fix next week. I already have the 6.14 upgrade so that clearly is not the answer....Oh well,
Strike 2. :( I was really hoping ffcars was an isolated incident. Hopefully no others will be stranded. [hr]
ct-fiskerbuzz said:
Anyway, it can be done, it just takes a lot of skull-sweat.[hr]
Okay, I guess I just don't understand the problem. If the PRND problem is occurring because of race conditions, the software should not allow the car to proceed into start mode until all components have successfully communicated they are "ready". I must be missing something. ;)
What was your exact situation so the rest of us with our kids can avoid it. Did you run in Stealth mode right down to zero without switching into Sport? Did you subsequently drive around in stealth at 0 miles left (appropriately thinking as others do on this forum that the battery charge would be held at 0 and slowly charging it back up?)

If that is the case, I think it would be safe for all to not let the battery run to 0 until Fisker fixes this issue.

I have little kids too and this terrifies me.

bdo



dbjr said:
I was just stranded with essentially the same problem. Car engine never came on in stealth mode despite a full tank of gas and therefore battery ran all the way out and died on the freeway with 2 kids in the back. Did have PRND warning light that came on while driving earlier today but it didn't affect the driving and thought it may be a software problem that the dealer could fix next week. I already have the 6.14 upgrade so that clearly is not the answer....Oh well,
matrix said:
Okay, I guess I just don't understand the problem. If the PRND problem is occurring because of race conditions, the software should not allow the car to proceed into start mode until all components have successfully communicated they are "ready". I must be missing something. ;)
I'd bet that they've fixed various deadlock issues and are running into livelock now.

Here's a classic example, from the old "dining philosophers problem": http://en.wikipedia.org/wiki/Dining_philosophers_problem (linking to wikipedia is a lot easier than me writing it up here!). Read the paragraph under "issues" that starts with "resource starvation".

If the system's mutexes have priority propagation, that helps avoid resource starvation, but you still have to get your priorities right.
dbjr said:
I was just stranded with essentially the same problem. Car engine never came on in stealth mode despite a full tank of gas and therefore battery ran all the way out and died on the freeway with 2 kids in the back. Did have PRND warning light that came on while driving earlier today but it didn't affect the driving and thought it may be a software problem that the dealer could fix next week. I already have the 6.14 upgrade so that clearly is not the answer....Oh well,
Did dealer pick you up and give you a loaner car? I have to admit, I've never just let the car run down the battery... I usually pop it into Sport mode when it has 2 or 3 miles of range left.
dbjr said:
I was just stranded with essentially the same problem. Car engine never came on in stealth mode despite a full tank of gas and therefore battery ran all the way out and died on the freeway with 2 kids in the back. Did have PRND warning light that came on while driving earlier today but it didn't affect the driving and thought it may be a software problem that the dealer could fix next week. I already have the 6.14 upgrade so that clearly is not the answer....Oh well,
I think you may be describing a different problem. In @ffcars case, the car was parked and would not go into D or R. It sounds like in your case the ICE did not come on when the battery was depleted by driving.

Also, I was informed by Fisker HQ Consumer Affairs late Friday afternoon that 6.14 has not yet been released. It is likely you are running on 6.13 or 6.13.5, unless your dealer hacked into an HQ server and downloaded 6.14. ;)
ct-fiskerbuzz said:
Here's a classic example, from the old "dining philosophers problem": http://en.wikipedia.org/wiki/Dining_philosophers_problem (linking to wikipedia is a lot easier than me writing it up here!). Read the paragraph under "issues" that starts with "resource starvation".

If the system's mutexes have priority propagation, that helps avoid resource starvation, but you still have to get your priorities right.
Does this mean we need to be chauffeured by a waiter to eliminate the bugs? :D

Seriously, thanks CT for helping us understand this. :thumbup: I assumed there was some type of "conductor" managing everything, and it would only greenlight the startup if/when all is ready. Sounds much more complicated than that.
matrix said:
ct-fiskerbuzz said:
Here's a classic example, from the old "dining philosophers problem": http://en.wikipedia.org/wiki/Dining_philosophers_problem (linking to wikipedia is a lot easier than me writing it up here!). Read the paragraph under "issues" that starts with "resource starvation".
Does this mean we need to be chauffeured by a waiter to eliminate the bugs? :D

Seriously, thanks CT for helping us understand this. :thumbup: I assumed there was some type of "conductor" managing everything, and it would only greenlight the startup if/when all is ready. Sounds much more complicated than that.
Actually, you've just described one of the tricks to making the system work right. The "dining philosophers" livelock example occurs in part because it's entirely a peer-based system. There's no "master" (the waiter) who determines whose turn it is to eat. If you add one, and give him the task of determining who gets to go when, you've solved that particular livelock issue.

The skull sweat comes in when you realize that your conductor/waiter now has a deadlock condition with the underlying resources he's handing out, and now you need to rebuild your entire "lock tree structure" (as determined by "lock resource X then Y" => lock X is "above" lock Y in the tree). (Locks don't technically have to have a tree structure but if they do you automatically have no deadlocks. At the most basic graph-theory level, what you have to do is avoid cycles in the lock graph. Trees have no cycles by definition, so you're done.)
See less See more
Nimisys said:
The stuck PRND and Agree Delay are mostly timing issues. the PRND switch actually is a module that communicates with 6 others before changing the LED indicating mode/gear. Similar for the Command center. You have 4 data busses and everything trying to talk to each other, and somethings need to happen in a very specific order. when you rush the commands in a "Race" condition, it is possible to interrupt some of those commands and knock requests and needed information out, causing longer delays, or modules not recieivng a wake up command or a state of health message, etc. It is a delicate balance prioritizing the messages and giving the user a feeling of quickness, something ALL manufacterers deal with.
How about buffering the packets at each module so that nothing gets dropped or corrupted if the PRND module has to wait for one module to clear before you proceed to another module. This way, you get a delay but no aberrant behavior. Buffer memory is cheap and plentiful.

The larger question is that pretty much all of these problems have already been solved for other very complex systems. I am sure the aiming system for the machine gun in @Kab70's Blackhawk has to communicate with a bunch of other systems before it lets the pilot fire at a target. So these are not new and previously unsolved problems we are dealing with, but a less-than-perfect execution and insufficient testing.

-- Fab.
41 - 60 of 112 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top