Speedset will not adjust

[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]

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

[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]

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

[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.)

[IDBoating]

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

[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]

I noticed you say PREsume instead of ASSume. LOL!

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

[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.

[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]

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]

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.

that is correct, I have no additional electronics in the helm, check out the schematic's I sent to you a while back, it involves the electronic throttle control module obviously but certainly nothing else.

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.

The part isnt expensive and i guess minimises BOM count, also may have given them flexibility in future.

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.

I also have the dash toggle, see schematic. i agree, though if they didn't do it it wouldn't work with my ECU.
Do they even customise the ECU code or just tune and enable features?

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?

sorry this was with reference to the Faria gauge.

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?

here's a few more photos that should help you (hopefully) get to the same diagram as I drew. mines in a bit of a sorry state at the moment so optical assessment is easier than electrically!
you can see how the traces make their way from the connector to the switches, it's single layer so it's dead easy to do :-)

I am going to try and use a combination of conductive silver paint and silver wire to hopefully repair it, though to be honest I'm leaning towards a complete replacement with switches as it's probably going to fail again in future!
many of the tracks have cracked right by the connector, due to the FPC being bent 180 degrees in a very tight radius.

Overall a pretty dire assembly! I think it was actually designed with the FPC being put in from the top of the board, it's plenty long enough and even has a guide of sorts for it, this however would have made it a pain to pot and waterproof, but would have made the FPC much less likely to break
IMAG0002.jpgIMAG0004.jpgIMAG0005.jpgIMAG0998.jpg

[ChrisSnow]

couple more photos,
IMAG0007.jpgIMAG0008.jpg

[IDBoating]

I agree from your photos that the side switches appear to have their commons going to +12V. That was my impression from JM's panel too, but I couldn't be certain without disassembly. As you know, that's an odd choice... normally folks don't use passive pulldowns. Not unheard of, just unusual which is why I wanted a second pair of eyes on it.

FYI, here is the page of the PCM schematics that show how their ECU-based cruise is controlled:
PCM_Engine_Connections.jpg
You can see the four cruise-related signals running straight from the ECU to the boat wiring harness. Note that the panels we're working on would not be compatible with this scheme!

I'm hoping to have JM's panel reworked today. More soon.

[Timmy!]

Good luck!!!