Resume Speed Function Operation

[SmartieParts]

Hmm.  Thinking about the math, there are some bits in the code relating to resume where it does the resume routine until it is within X of the set speed (where X is a very small number) and then it goes on to the normal cruise routine.  So I wonder if perhaps if the person attempts a resume already within that narrow band if maybe a bug in the code could produce unforseen behavior?  I'm purely speculating.  I can't test it as my smart is off the road for the season.  Of course, in this case it would have absolutely nothing to do with the rate of speed.  So if its 60 and if (and that's only an "if") there's a problem with resuming at 59-61 say, then the same problem would exist at a target of 40 and resuming at 39-41.

Anyway, as the primary person that worked on the algorithm for the resume function, I have to acknowledge that I didn't code with the concept of resuming so close to the target speed and I doubt if I would have tested specifically for that.  It was a long time ago now, so I don't remember either way.

Hopefully someone can perform the test soon.  I propose these steps (correct me if I'm missing your point):

 1) get up to a particular speed that is easily read on your speedometer and tap (press and release in < 0.5 seconds) the button to engage the standard cruise routine.
 2) tap on the brake or otherwise disengage the cruise.
 3) manually get back to that speed, attempting to be within 1mph of it.
 4) press and hold the button (> 0.5 seconds) to engage the resume routine.
 5) note the behavior.  Does it resume normally?  Does it accelerate beyond the expected speed?  If the latter, does it continue far past the target, or is it only a couple mph?

Obviously, please perform the test on an open road as safe as possible.

 - Steven

[wizard of ahs]

I'll do that on my way home tonight 

[wizard of ahs]

I tried as you asked Steve.

I was at both 50mph and 60 mph, tapped the brake, brought her back up to 49 mph and 59 mph (using scan gauge) and both times the cruise brought her back to 50 and 60 and locked in 

It did NOT exceed the "set" speed.

Hope this helps 

BTW.... Congrats on the new baby

[Little John]

My experiences at various speed is consistent with Steve's explanation. I am running version 1.30. When the button is held in to resume the speed the car starts to accelerate, mimicking the behavior I would expect from pressing the button while the cruise is engaged.

Would you expect a difference in operation between the versions?

[mvaldes]

FWIW, I tried multiple times to replicate the resume problem. I set the cruise at 66 mph (per my scangauge) and tried resuming from 65 and 67 mph (also per scangauge) and it resumed to 66 mph. I also tried it at 35mph; resuming at 34 and at 36 mph. All tries at both speeds only resulting in resuming the preset speed. (I can't exclude the possibility that I reset the speed rather than resumed it. Since I went back to preset number as read on the scangauge, I think it's unlikely. However, it's not perfectly flat terrain so there is a tiny possibility that I just happened to be on a slight incline or decline when I "resumed" and that made up for the 1 mph difference.)

[SmartieParts]

Thanks for testing and confirming guys.

John, there was no changes at all with the resume code from version to version.

 - Steven

ps. Thanks for the baby-grats   Exciting time for me.

[Little John]

Running a few more tests on my second unit shows that it has the same issue as the first.
The problem centers around how the unit operates if the button is held down for an extended period of time. This directly relates to a tactile feedback issue in understanding  how long to hold the button depressed until it feels like the unit is resuming the previous speed, has resumed the previous speed or has taken control of managing the speed of the car.
It is an interesting engineering issue related to state machines and the conditions which cause them to change state.
In the case of the cruise control, if the unit is 'off' and you push in the button and release, it will set the speed and maintain it.
If the unit is 'off' and you hold the button in for a longer period of time, perhaps a second, it will enter resume mode and eventually return to the prior set speed. This may involve slowing down or speeding up the vehicle.
If the car has been off, thereby resetting the unit’s memory, and you decide to set a speed then continue to hold the button depressed, the unit will set a speed, pause for a short time (maybe ½ a second) then start accelerating the car. It appears that the unit in the state change from SET to MAINTAIN failed to maintain knowledge that the button was not toggled by the human. It sees the button condition as depressed and enters ACCELERATION mode.
This also happens when a prior speed has been set and one tries to resume.
Slowing to ~5mph under the set speed then depressing and holding the button causes the unit to start the resume process. The car accelerates and when the prior speed is achieved the unit pauses the accelerating the car. It then shifts into accelerating the car after a short interval. This is the same symptom as described in an earlier paragraph.
Speeding up to ~5mph over the set speed then depressing and holding the button causes the unit to start the resume process. The car decelerates and when the prior speed is achieved the unit pauses the deceleration. It then shifts into accelerating the car after a short interval. This is the same symptom as described in an earlier paragraph.
If you are too close to the prior speed when you try to resume the feedback from the unit that the car is under cruise control is difficult to discern and the unit starts accelerating the car.
So I see two problems. The first being the user’s ability to tell when the cruise control has taken charge of the speed of the car. The second being the unit assuming a toggle in the condition of the button and performing a task not intended by the user.
I have 1.30 with the standard mapping as the program in both units. I don’t recall ever having this issue with holding the button in for longer periods of time with the software shipped with the unit I purchased in July of 2009.
It will be interesting to hear the answers.

[SmartieParts]

I read your post 3 times and I fail to see the problem.  If I understand what you're saying, you are describing the operation(s) as it was intended, with the possible anomaly (depending on point of view) of what happens if you hold the button down an excessive (?) amount of time.  The solution of which, I suppose, is to not hold it down so long or in situations where the press-and-hold function does not apply (at least as you perceive it should).

If there is no speed in memory, then a resume is not possible and an accelerate will occur because, in effect, that is what you're telling it to do.  Similarly, pressing and holding the button past the completion of resume may also result in acceleration because again, that's what you're telling it to do.

Again, I may not be understanding what you're saying... but I think you may be misunderstanding the operation of the "press and hold" functions (ie. Resume and Accel).  Press-and-hold means this:

press the button and do not release it for > 0.5 seconds.  Release the button when:
a) in the case of resume, when the operation commences.  Youo do not need to (and should not) continue holding the button while it resumes to the speed in memory.
b) in the case of accelerate, when you reach the desired speed.

You can know that the the resume function has engaged by looking at the LED.  It will begin to flash the moment the resume function engages and will continue to flash until the speed is close to the target, at which point the normal cruise routine will kick in and the light will shine steady.

If you feel it is a difference between the 1.3 and earlier versions, then I encourage you to re-flash your firmware with the stock version and confirm.  But I am certain there were no changes regarding resume at all.  Could there be some other code changes influencing it?  I wouldn't think so, but with confirmation that the "problem" (if that is the case) is a version-specific one then I can attempt to seek it out.

 - Steven

[Little John]

It is my belief that actions by a user should be positive and not implied.

In this case the unit does not require the user to release and re-engage the button to demonstrate a change in thier intention.

The flashing LED, being hidden behind the steering wheel, is difficult if not impossible to see in most circumstances. There is no difference in the flashing rate between RESUME or ACCELERATE modes.

When I started this thread it was because the unit reacted differently than I expected when attempting to resume at higher speeds. I have a much better understanding of the operation and pecularities of the unit. In general it works very well. There are aspects of the operation which make decisions on implied rather than explicit operator intent. It's a livable situation.

[SmartieParts]

Many things take implied actions, so we can't really look at that as an absolute no-no, I don't believe.  For example, when you press the brake you are explicitly telling the car to slow down and that "implies" that the cruise should also shut off (and it does) but you didn't explicitly tell it to do so.  Still, we take that action for safety sake.  I'm still not sure I'm clear on what you're describing, but if it is what I think it is - holding down the button during the entire resume process until it is finished and beyond - then there is no implied action intended (its probably just that it was no programmed with the expectation that someone would do that) and I think we can "correct" the behavior if there is call to do so and if I can confirm its behaving the way I think you're describing. At least I think I now have a better understanding of what you're trying to describe.

 - Steven