Speedset will not adjust

[IDBoating]

You're right, the serial data and clock aren't accessible once the module is assembled. (I wrote my comments from memory late last night, didn't have the schematic in front of me.) So that does mean the Medallion module cannot be sending data to the MCU. However, we do know for certain that this module communicates TO the Medallion because its buttons run Medallion's menu system.

on my boat this goes directly to the ECU which needs an open collector enable signal, now since we only have a momentary input and need a latching signal this is about all the MCU can be doing for me, it will also be debouncing the input.

Seriously? This is the first I've heard of this about your boat. As I mentioned, this three-wire ECU based cruise control does exist but are you saying that this panel plugs directly into your ECU? Does not pass through any sort of helm box? I theorized they could do this given the pinout on this module but didn't know they had actually used it that way early on.

You know, I just can't quite get past the "it's too complicated" feeling. They have 12VDC available, and there are logic family choices that run at that voltage. If the only thing they are doing is turning a momentary switch into a toggle, they didn't need two IC's and a discrete FET and the PCB real estate and the cost and testing and decreased reliability from more parts just to do that. Seems like someone, somewhere along the line, would have realized they could save money and hassle. Makes me think we're missing something. Hmmmmm.

Also: On boats with Medallion the center button does not enable/disable cruise. There's a dash toggle for that. Meaning that on Medallion boats the entire two-IC's+FET setup is utterly useless, just bringing out the snap dome would have sufficed. All they need is momentary contact to talk to Medallion's menu system. In fact, it makes it worse because (if our theory is right) they now have to do edge triggering in software to OVERCOME the toggling "feature" and turn the button back into a momentary contact!

I'm going to dig out my ECU cruise documentation and see if I can confirm that the on/off signal is level triggered. If the ECU itself handles the toggling function then we still don't have an explanation for the onboard MCU. It's not like the ECU doesn't have the horsepower to deal with it.

it looks like they also decode the LED signal to determine what's going on which is nice

I don't see this. The LED signal comes in JP2 and goes straight to the keypad. Where's this decoding of which you speak?

the up and down has a common 12V, see attached diagram that I hope is correct

Did you ring this out? I believe fixing JM's panel is simply a matter of restoring the lost common side of those switches, but I need to make certain I'm going to the correct side (+V or ground). I could tear his apart to find out, but since yours is already open you can confirm without me having to damage his. How did you make certain of this?

[ChrisSnow]

here's a photo of my "ACCUSET" from the front, vastly different visually but functionally identical bar the exclusion of back lightingIMAG0001.jpg

Apologies for misleading you last night re the common signal, it was late and I was tired..



the enable has a ground on one side but the up and down has a common 12V, see attached diagram that I hope is correct :-)
tige.png
I also noticed they mis labled the schematic, In the scheme of things it didn't matter to them as they are not using any peripherals on the pins just digital IO,

as far as I can tell from various sources it''s momentary for the up and down and needs a latching signal on the enable to be in cruise control mode.

I know it seems silly to use an MCU here, but I do genuinely think they just did it without thinking about traditional logic gates etc.

If you think about what the MCU could be doing it's not a lot. heres my reasoning.

it has a single digital input, the on/off switch. they will be using an internal pull up.

it has a single external IO line which goes via a FET which converts this signal into a open collector output. this therefore means it has to be unidirectional and obviously it's an output.

this means that there can be no communication from the medallion to the SpeedSet.

now it would be possible to send serial data over this open collector output but don't forget that on my boat this goes directly to the ECU which needs an open collector enable signal, now since we only have a momentary input and need a latching signal this is about all the MCU can be doing for me, it will also be debouncing the input.

I guess you could encode the enable button presses and send status like how long the button was pressed for etc but that seems a bit pointless.

There could be different versions of MCU firmware between mine and yours , the connector JP3 that isn't populated is for ICSP and is not needed afterwards.

I don't have medallion kit in mine but there's no reason why they couldn't take these signals and do their own thing then mimic them back to the ECU.

one option that i have thought about would be that certain models of the Faria Commander speedo actually have the controls and a connector integrated for what they call "PerfectPass cruise", interestingly this alongside the dash mounted cruise control switch might actually be able to replace the speedset.

it looks like they also decode the LED signal to determine what's going on which is nice, might not work with direct ECU connection though.

this is purely my thoughts and is there if anyone wanted to consider doing something.

This is probably getting a bit technical for here but I guess at least it's here for others in future.

I do find the 1250$ quoted to replace it an absolute disgrace. the components are worth very little, and unless they are building them one at a time it should be possible to sell them and make a profit for under say 200$

[IDBoating]

OK, latest update.

Presuming the side switches are active low (which is very likely), I believe we can make JM's touchpad functional again with a jumper wire that substitutes for what I suspect is a failed connection at the flex circuit connector shown in ChrisNow's photos. I've always hated those flex connectors, they've always seemed less than reliable to me. I'm sorry to be proven correct.

That will hopefully fix JM's situation. But that's not a general fix for the rest of the community. Here's where I think we are on that. The side buttons can be functionally replaced by momentary contact switches - no magic there. It's the center switch that is a bit challenging. Its contacts don't exit the module directly. Instead, the button's state is read by a very small microcontroller on the board and then the microcontroller controls a discrete FET (transistor) whose "output" exits the module. That microcontroller also has some connections coming to it from off-board - most likely a serial data line and its associated clock, based on the pin functions for that MCU.

A dedicated MCU for a single pushbutton? That's crazy. If all it's doing is toggling state, there are countless better and cheaper ways to do it. And why do they need a discrete FET, when the snap dome switches are obviously able to sink the current on the faster/slower signal lines?

Here's my present theory. We know this panel must connect to the Medallion module, and not directly to the ECU (where cruise control actually occurs), because those buttons ALSO control the menu system on the screen. If the panel connected directly to the ECU, the Medallion module wouldn't see them and you'd have no way to interact with the screen. So the Medallion module sits between this panel and the ECU.

The faster/slower buttons simply ground their data line, no problemo. But why not have the center button do the same? Normally a discrete FET indicates the need to handle greater voltage, current, or both. But this is undoubtedly just another signal line - very little current, low enough that a snap dome switch could easily handle it. So why the FET? Because these three circuits (Faster, Slower, and center) are 12VDC circuits, and the little MCU cannot handle +12VDC signals directly like the snap domes can. Remember: 1) The MCU can interact with or override the center button; 2) The MCU sits between that center button and the board's output for that button; and 3) The MCU is (I believe) getting serial data from off-board... from the Medallion module. The MCU receives the Medallion module's serial data, coordinates it with the center snap dome switch, makes a decision, and then uses the discrete FET to control the output signal that it cannot directly control because of the higher voltage.

And therein lies the rub. We don't know what decision is being made by that MCU. I believe the Medallion module is sending it serialized data telling it how to manipulate the cruise on/off signal. We don't know what is happening there. We could toss the whole circuit and just substitute another momentary switch - indeed, that's how the engine ECU's expect it to be wired - but then we will lose whatever intelligence is going on there. I'm fairly confident we could get cruise control to work, but I'm leery of cavalierly discarding whatever that MCU is doing. There is some interaction between Medallion and the ECU regarding cruise control and I'm not sure we should just throw that aside.

Beyond that, we would also have to duplicate the Medallion-related functionality of that center switch - its function to select things in the menu. That has nothing to do with the ECU. And with that MCU in the middle of things, it's not as simple as just swapping in a switch. We would have to study and duplicate the serial protocol in/out of the board. That's what the MCU is doing, and we'd have to replace it.

The good news in all of this is that the electronics is not likely to be the failure point. I think ChrisNow's analysis has nailed the most likely area of problems: That rotten flex circuit connector. I'm confident that's what has happened to JM's panel, Chris's makes it two, and I'll bet the majority of failures we see will be in that area. It will be delicate work, but I think we can fix most such events with a little care. Might take some specialized skills but I think it's at least possible. I intend to try it on JM's panel, and doing it won't require any damage.

I will work some more on it tomorrow evening, and report progress.

[IDBoating]

I noticed you say PREsume instead of ASSume. LOL!

That was not random. I try to give people the benefit of the doubt!

[Timmy!]

Interesting... pins one and two on the MCU are mislabeled on the schematic. I presume the actual design got them correct.

I noticed you say PREsume instead of ASSume. LOL!

[IDBoating]

Interesting... pins one and two on the MCU are mislabeled on the schematic. I presume the actual design got them correct.

[IDBoating]

Last post from me tonight as its latest. basically the traces bend a bit and then straighten out. It is common ground.

I know from testing that the center switch is active low. Are you absolutely certain that the common side of the side snap domes is ground? Can you trace it out to be certain? Or better yet, test for continuity? (I can't do that with JM's touchpad without physical damage.)

[ChrisSnow]

It's an 06. I do have some more photos. Will email you them tomorrow.

[IDBoating]

I don't have back lights and only have 1 switch per area. What year is this off?

The date on the connector sticker is 08/07/08. The date on Timmy's touchpad earlier in this thread is 09/06/06. Your sticker is 10/18/05. So it appears in 2005 they started with a single snap dome, redesigned and went to three snap domes in 2006, and by 2008 they had dropped to two per side but stayed with the second design iteration.

[ChrisSnow]

Last post from me tonight as its latest. basically the traces bend a bit and then straighten out. It is common ground.

[IDBoating]

Have you got continuity from the fpc all the way back to the external connector?

For some pins yes, others no. In the case of the center snap dome, one side isn't brought out to the external connector (as you know). It goes to that 8 pin MCU.

At the moment I believe the common side of the side switches has lost continuity to the external connector. I'm studying your torn-apart photos to see if I can discern whether that common side is meant to be +12V or ground.

Most troubling so far: The keypad connector (the one you're considering replacing) is an eight contact device. But the flex circuit appears to be a NINE contact... and its pitch appears to be different than the contacts on the connector. I'm examining it under bright light and magnification, trying to figure it out without doing anything irreversible. Yet.

[ChrisSnow]

That is odd the placement of the snap domes and especially the difference between mine. I don't have back lights and only have 1 switch per area. What year is this off?

Bit of cross posting going on here!.

[ChrisSnow]

Have you got continuity from the fpc all the way back to the external connector? Peeling the overlay off may have released the domes.

[IDBoating]

Figured out the "weird feel" thing. Here's a photo of the unit with the faceplate removed:
IMG_20150513_143248965_HDR.jpg

Look at the back of the faceplate on the right. It has little dimples that are intended to depress the snap domes. There are three such dimples for each side (the "Faster" and "Slower" sides).

Now look at the assembly on the left. Note that while there are three locations for snap domes on each side, only two of those positions are populated on this unit. For some reason (reliability?), the original design intended for three snap domes on each side but in production they only populated two per side.

That black rubber surface that you press with your finger is backed by that cream-colored stuff with the dimples on the right. I expected the area on the left and right to be stiffer, such that pressing anywhere in that "zone" would cause multiple snap domes to be actuated. But the entire assembly is really quite flexible. You can take it out and bend it all around. Pressing one snap dome isn't going to actuate the other(s) on that side. And - interestingly - pressing over the MISSING snap dome may not actuate either of the two that are there! It's a "feel" thing, and it's weird that the center area where you're most likely to press is the area that now doesn't have a snap dome. That's what I was "feeling", the lack of a snap dome in the middle.

Reassembling things and intentionally pressing at the top or bottom of the sides, where we know there to be a snap dome, actuates the dome properly.

With that mystery solved, back to electronics....

(Let me know if this is too much detail for everyone. I can take this offline privately to JM and just post the conclusions if so.)

[IDBoating]

First observations.

JM's touchpad is in good physical shape. First level disassembly revealed no water intrusion, no delamination, everything looks fine.

So... out come the microprobes. These allow me to test the flexible circuit traces without having to disassemble the layers. All of the traces test fine, and - importantly - all of the snap domes are working. They are mechanically fine, they retract when released and snap down properly when pressed. They also break contact when released and make contact when pressed. The pairs on either side operate in parallel as the traces indicate they are meant to.

That's somewhat bad news, because if it were just a snap dome problem it would be easier to fix. I fear ChrisNow's connector problem may be endemic to the design, and as he's noted it's a bugger to access and work on without damaging stuff on JM's touchpad that isn't broken.

I am troubled by the fact that the switch actuation felt "wrong" when the unit was assembled, yet feels OK when disassembled. JM, did you ever plug this in and test it with the faceplate off, just pressing the snap domes directly with your finger? I will investigate if something appears wrong with the rubber overlay assembly.

Analysis continues....