Medallion MDC data messages

[justgary]

So I had a little time today and decided to take a shot at decoding medallion marine data concentrator output.  I see a handful of addresses coming out, but I only have about a half handful of gauges.  Correlating data words with gauge output is generally pretty easy, but I'd like to figure out the other messages also. 

I have the following gauges: hours, rpm, oil pressure, engine temperature, battery volts, fuel level, and speedometer.  What other outputs did the Malibu varieties of MDC have?  Have you seen some funky gauge on any year boat? 

Thanks in advance for any help. 

[UWSkier]

Hours are tied to gauges on older boats. We replaced the tach on my dad's 2001 3 years in and lost 180 hrs from the counter. Think you've captured the gauge possibilities for the older boats. Not sure if the 06+ with the center digital gauge consumed additional telemetry from the MDC. 

[justgary]

Thanks.  I was puzzling just a bit over the engine hours thing because I didn't immediately see it in the data. 

I'll log some data when I go out next time (hopefully Friday) to make sure I don't see anything else that I missed. 

What about newer boats?  Any new gauges or messages out of the MDC?

[Eagleboy99]

Whatchya gonna do with?

[justgary]

19 hours ago, Eagleboy99 said:

Whatchya gonna do with?

The possibilities are so nearly endless... but they start with understanding what is there and how to use it.

So basically only one message has me stumped.  It has two extra bytes of data and appears to be 11 messages subcommutated round robin (so as to get a lower rate output of more items).  I don't have enough data yet to give it a shot at deciphering.

[Eagleboy99]

Checksum?

 

[justgary]

Each message has a checksum.  I am calculating that correctly.  This is a whole message.  I'm taking the boat out Friday morning.  I hope to have a data recorder done by then, but it will be a stretch.

[proey]

@justgary

I now have a waterlogged/fried MDC 1600, all gauges worked a few weeks ago.  I could do a gauge swap but I’m thinking I could make an Arduino MDC pretty easily after poking around the MDC harness and reading a few docs.

Can you confirm that it’s 9600baud 8n2, 7v high/0v low as posted on teamtalk (couldn’t find the details here)
https://teamtalk.mastercraft.com/forum/maintenance-tips-how-tos-and-refurbishing-topics/electrical/66239-mdc-1600-communication-protocol#post1801353

Also can you post some data from your log so I can see I get the gauge addresses?

[skisky89]

Hmmmm I wonder the round-robin looking data is for the optional RPM gauge LCD.  Lake temp, depth, etc.

[ShuManChu]

On 8/21/2022 at 6:35 PM, skisky89 said:

Hmmmm I wonder the round-robin looking data is for the optional RPM gauge LCD.  Lake temp, depth, etc.

That was introduced in 2004 and to my knowledge it uses CAN (or similar) between the MMDC and the LCD Gauge, and does not use the Medallion serial protocol. The actual needle in the gauge (could be tach or speedo depending on configuration) is still controlled by the Medallion serial protocol though. 

[ShuManChu]

On 8/14/2022 at 4:16 AM, proey said:

@justgary

I now have a waterlogged/fried MDC 1600, all gauges worked a few weeks ago.  I could do a gauge swap but I’m thinking I could make an Arduino MDC pretty easily after poking around the MDC harness and reading a few docs.

Can you confirm that it’s 9600baud 8n2, 7v high/0v low as posted on teamtalk (couldn’t find the details here)
https://teamtalk.mastercraft.com/forum/maintenance-tips-how-tos-and-refurbishing-topics/electrical/66239-mdc-1600-communication-protocol#post1801353

Also can you post some data from your log so I can see I get the gauge addresses?

Do you have access to a digital logic analyzer? The person in the TeamTalk thread used a Saleae logic analyzer, which work really well for reverse engineering this stuff. They are expensive though. Cheaper china knock offs that are compatible with Saleae's Logic software can be found on ebay, but they are flaky. I do not know what the gauge addresses are, that information is sadly not in any of the literature I have seen. 

[proey]

6 hours ago, ShuManChu said:

That was introduced in 2004 and to my knowledge it uses CAN (or similar) between the MMDC and the LCD Gauge, and does not use the Medallion serial protocol. The actual needle in the gauge (could be tach or speedo depending on configuration) is still controlled by the Medallion serial protocol though. 

I agree, that's my understanding too.  The "Message center" LCD, water temp, depth are all on CAN.  I think @justgary started this thread focused on the serial data to gauges.

[proey]

I should start by stating that my findings are from an MDC 1600, I'm looking at the serial protocol from the MDC to the gauges.  My gauge configuration is battery volts, oil pressure, engine temperature, speedo 1, tach with hour meter, speedo 2, fuel level.

My MDC is busted so I'm not snooping the data I'm generating data from my computer and observing the gauges moving.

I can confirm that the serial protocol is 9600 baud, 8 bits, no parity, 2 stop bits.

Data is sent in either 4 byte or 5 byte packets.  The first byte is always 0x80.  The second byte is address.  Bytes 3 and optionally 4 are the data.  The last byte 4 or 5 is a check sum (2s compliment, I've confirmed that the gauge will ignore a packet with bad check sum).

Next I sent 4 and 5 byte packets to all 256 addresses with data values 0 and 250 (arbitrary data) and recorded address and length for what gauges moved.

Length 4 messages:

Fuel: Address 64+32 = 96
Oil: Address 64+36 = 100
Temp: Address 64+46 = 110

Length 5 messages:

Voltage: 128 + 40 = 168
Speedo1 and 2: 128 + 50 = 178
Tach: 128 + 62 = 190

I'm writing the address as 2 high bits for size and 6 bits for address although I'll admit that was based on info I found in another forum and is largely unproven, but the trend did hold for my data.

Next I will sweep data values to determine what the scaling is, so far I've determined that oil pressure * 2 and speed * 20 are the approximate scalings to apply before sending the data.

The unexpected thing was the the speedos both responded to the same address, same data.  My setup has two pitot and two adjustment up/down toggle buttons to adjust the calibration of the speedos (run the course at a fixed speed and time it with a stop watch, if the time is fast or slow adjust the speedos).  A long while ago I played around with the calibration (but I'm clearly more of a geek than a great skier) but I'm not sure what message should be sent, or if that is internal to the MDC and somehow it was able to send separate data to the two speedos.  I have not yet tried to twiddle other bits in the 2 byte speed packet to see if I can one speedo but not the other to move.

BTW my boat is winterized and in the barn but I pulled the dash panel with the gauges to play around in the off season.

 

Edited October 15, 2022 by proey
fixed typo on 46 temp address

[ShuManChu]

I replied in the other thread, just as you were typing up this response, haha! I am getting my threads confused. I like the brute force address search. I am quite surprised that all of your gauges actually moved. Two of mine have dead stepper motors, which I plan to replace this winter sometime. 

Where is the calibration adjustment for the speedos? Is it possible each speedo is saving an offest in some internal EEPROM or something to apply to the incoming serial data?

[proey]

I've replaced two stepper motors already

I haven't opened the speedos so I'm not sure.  I have opened the back of the MDC in hopes that something in there was repairable but it wasn't.  I can clearly see there are two eproms (8kbit and 1kbit) close to the microcontroller which has is own internal eprom for the program.  The toggle switches go to the MDC.

The offset could be a separate message.  I had assumed that one speedo, one pitot, one toggle switch was an independent system and similarly the other set.

Another experiment I can try is to send the speed message get both gauges to ~20mph and then sweep the address space again sending non-zero messages and see if the needles move.

[ShuManChu]

Nice! I have the juken/Switec x27.168 replacement steppers, but I haven't tackled the job yet. Only my tach and speedo are out, and I have tach and speedo on the perfect pass, so I haven't been motivated to fix them. We still have water and 90 degree weather here in California, so our season isn't quite over yet. 

Do you have any tips for separating the gauge cover from the pod? 

If both gauges respond to the same address, I find it hard to imagine that they each also respond to another address. How would they decide which speed value to display as both speed messages are coming in on the bus? Let us know the results of your experiments!

I have a folder of resources relating to the gauges, let me know if you want access to that. I found this in the troubleshooting guide:

 

This suggests to me that each speedo should be getting an independent speed (i.e. each has a different bus address). You may have two speedometers with the same part number? I.e. two primary or two secondary speedos? Seems unlikely but worth checking on. 

[proey]

@ShuManChu thanks for those 4 points.  Certainly #3 reads that the primary/secondary are truly independent.  As for having two of the same, its possible.  I've checked the part numbers and they are different (but googling the parts doesn't find anything).  One of them has a sticker which says 3" SPEED PRI, so clearly its a primary.  Maybe the speedos have the same "address" byte but in the 2bytes of data there are primary/secondary flags and maybe if unset it applies to both, just trying to rationalize my current observation.

As for the stepper motors, yes I used x27.168 motors.  Pop the bezel off by hand, using a sharp thin knife you can press in on the joint and the glue between the housing clear "glass" will separate.  Next you pull the gauge needle and the face plate will come off.  Trickiest part is desoldering 5 pins to get the board out, so that you can desolder the old stepper then do it again in reverse

[ShuManChu]

It might be worth a call to Medallion? ((800) 828-8127). Who knows if they give out that kind of info or not. 

I was able to confirm that one of the EEPROMs in the MDC is for storing the speed adjustments: 

"EEPROM CHIPS
Two EEPROMs, one to
save important date, the
other for speed data."

My guess is that the offsets/adjustments are read out of the EEPROM and used to send two different serial packets, one to each gauge. I would try to find someone with a dual speedometer setup like yours and ask if you can plug in your setup and see if both of their speedos respond to the one address you have. Or maybe ask around on the forums for anyone who has a functional secondary speedo that they aren't using. A lot of people get fed up with the Medallion instrumentation, rip them out, and go full analog. Last resort is looking on ebay and other sites to buy a secondary gauge (since you can repair the steppers, you might find a "dead" one for cheap). 

 

@justgary could you post the raw data you captured from your MDC? This might give @proey a chance at reverse engineering the gauge addresses and resolving his dual speedo issue. 

To answer your question, the only gauge type that you don't have listed is ballast level. This was only an input on 2001 and later MMDC modules. In 2004 they introduced the multi-function LCD gauges, which have a separate CAN data bus for feeding information to the LCD screen. 

[ShuManChu]

Ebay finds: 

https://www.ebay.com/itm/155196132763?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=FBOXO57UTS6&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY

https://www.ebay.com/itm/155174938657?mkcid=16&mkevt=1&mkrid=711-127632-2357-0&ssspo=FBOXO57UTS6&sssrc=2047675&ssuid=&widget_ver=artemis&media=COPY

These were the only ones I could find that said "secondary." Apparently they know they're rare, because they are asking ~$250!

Edited October 13, 2022 by ShuManChu
added another find

[justgary]

7 hours ago, ShuManChu said:

could you post the raw data you captured from your MDC?

Sorry, but I never captured any useful data.

[uuuubbbb]

Hi All,

I am the one who started the TeamTalk thread - managed to successfully get the speed converted to GPS but did not bother reverse engineering all other gauges as I did have a working MDC1600.

Don't know if this somewhat helps, but here are all the readings I did all that time ago - https://1drv.ms/u/s!AoPa8u6x2cUSg-YK8mSpjWNr444sOg?e=EEOGwx, should be readable via https://support.saleae.com/logic-software/legacy-software/older-software-releases

I remember that these troubleshooting guides were quite helpful - https://1drv.ms/b/s!AoPa8u6x2cUSgcZqM-UgxcF3mykD9w?e=Fi2zt3 and https://1drv.ms/b/s!AoPa8u6x2cUSgcZpehfXvUQm6IotLA?e=GTjHTO

Hope this helps!

 

[ShuManChu]

@uuuubbbb THANK YOU!!! This is sooo helpful. If you are feeling extra generous, would you mind sharing the details on your GPS speedometer implementation? I would love to use an arduino micro or ESP32 or similar small micro to have a GPS speedometer. 

Here is what I was able to determine from your data:

 

I am certain that secondary speedo operates with address 51, since uuuubbbb has a separate capture where the data for that address fluctuates. 

The mystery is address 7 and address 52. Given this is a MDC1600, there was no ballast input. I'll take a look at the manual again and see which inputs it might be. 

[ShuManChu]

Address 7 doesn't really fit the mold. The second byte indicates that the data length is 3, but there are actually 4 bytes of data. 

[uuuubbbb]

This was my first and last Arduino project and I see I had a "creative" way of doing the average of last 3 measurements.

I am not sure if this is the actual code I ended up using, but I remember that it was very simple - https://1drv.ms/u/s!AoPa8u6x2cUSg9lPxYEJbFaUZo3uSA?e=P10Ele

[ShuManChu]

The troubleshooting guide lists the following types of inputs that aren't already accounted for:

Rudder Angle

Trans Pressure

Trim Angle

 

But those aren't typical on inboard ski boats. Perhaps some had the option for a trans oil pressure gauge. 

 

The Mastercraft Medallion Gauges training document lists one other input for the MDC1600: 

"Electronic" - 0V corresponding to "empty" and 2V corresponding to "full"

 

My guess is that the 10Hz address 7 message that does not fit the typical pattern is for something else, perhaps a clock, LCD or something?

The 1 Hz address 52 might be for that other "electronic" full/empty input. It is probably optional, and the data is always 0 in the packets in uuuubbbb's captures.