Ballast Fill Level Monitoring

[IDBoating]

ID, I will confirm the options of my current hardware relative to the CAN network.

Reply with the part number of your CAN transceiver chip and I'll take a look for you. Not the PHY chip, but the transceiver.

Are the height of your sensor tubes custom made lengths for each manufacturer and each boat, or do you offer manufacturers standard lengths?

Generally a single length can be shared across multiple applications, but there aren't any "off the shelf" standard lengths/heights because there aren't any standards in the industry for ballast compartment sizes, storage/hull dimensions, etc. See below for more info.

Since there are no post modification option, you would have to make "universal" lengths to work for most after market applications. If you use a tube that exceeds the height of the ballast bag, can you calibrate the tube to use a smaller function length or does the height have to match to height of the bag?

Yes, exactly. And this answers the above question too. Our recommendation is that the sensor be made as tall as possible within the hull compartment in which it's mounted. Presuming the factory ballast isn't the full height of that compartment (to allow for storage space on top of the factory ballast), the sensor is calibrated for the max height of the water in the factory ballast. Then, if the user increases the height of the ballast (by adding fat sacs over the top, or outright replacing the entire sac/tank), the sensor is simply calibrated for the new height. The sensor knows to divide its calibrated range into one percent increments, so by recalibrating its max value it automatically adjusts for changes in ballast configurations. And by making the sensor the full height of the hull compartment, the sensor is automatically prepared for any size fat sac or tank that could possibly fit in that compartment - thus future-proofing everything.

I assume you make large runs for specific lengths and custom one off orders would be significantly more expensive.

Yes, we produce them in volume to the sizes required. For your project we'd have R&D pop out a couple to your measurements like we do for new manufacturers, new boat models, etc. but that's not something we'd do on an ongoing basis.

Great questions... keep 'em coming!

EDIT: Recalibration of the ballast sensor is simple: Send it the appropriate recalibration command over the CAN network. Calibration settings are retained in nonvolatile memory within each sensor so this only has to be done one time, whenever the fat sac/tank is modified. Murphy typically hides this command within a special "dealer" menu in their touchscreen systems, although I believe the boat manufacturers will give customers access to it if they ask.

[oldwakedoc]

ID:
He surfaces again.
Sorry again, just completing a run at work of 128 hours over the last 10 days, once a little recovery going to get back to this. You were correct, the CAN shield handles both 2.0A and 2.0B. Can you send me an example of the Bus message from a sensor with a reading of 0 and 100. Please also include the PGN and resulting SPN that I should be able to read off each to see if my setup is working. I believe you mentioned that the sensor sends a result of 0-100.

questions:
Are the PGN's customizable or defined in the firmware of the sensor?
How frequently do each of the sensors broadcast on the CAN Bus?

Sleep now, will return soon

[IDBoating]

You were correct, the CAN shield handles both 2.0A and 2.0B.

Good! One less obstacle.

Are the PGN's customizable or defined in the firmware of the sensor?

PGN's are fixed in the firmware, as is standard for almost all CAN devices. If you really want a deep dive on PGN's, look up the J1939 standard... it defines hundreds (thousands?) of PGN's. They are not reconfigurable, and for good reason... it would be a nightmare trying to support that for everyone on the CAN network. Literally moving targets.

How frequently do each of the sensors broadcast on the CAN Bus?

Every 500mS.

Can you send me an example of the Bus message from a sensor with a reading of 0 and 100.

Here's a quickly annotated screen capture of a typical ballast sensor CAN message:
BAL_BasicCAN.jpg
The CAN-ID contains the CAN priority, the PGN, and the Source Address (SA). Our sensors support up to nine separate SA's so you can have up to nine sensors of a given family on a single CAN network. For the ballast sensor family, the base address is 0x69 with the next eight sequential addresses selectable via two pins on its Deutsch connector. You'll note the last byte of the CAN-ID is the SA... for differently addressed sensors you'll get messages that differ in that last byte so you can distinguish port aft ballast from bow starboard ballast, etc.

Create a hardware receive filter for your CAN messages that specifies the last eight bits of the SA as "don't care" (match anything) and then you'll restrict what your firmware has to actually process to messages from our sensors. Your CAN transceiver chip will support this. From there you simply examine the SA to know which sensor you're looking at. Trust me, you really want to do this because some of the CAN messages have repeat periods in the tens of milliseconds (Indmar Fast Packets are one example). Your firmware will be swamped discarding all of the CAN data you don't care about, if it can keep up at all. That's why CAN transceivers implement this in hardware, and you configure it from firmware to stem the flood of data.

Strictly speaking the PGN here is 0xF780, but you can't ignore the leading priority bits. When you configure your receive filter you'll need to specify them, which is why I'm giving you a snapshot of the CAN sniffer. This is the REAL DATA from the network. Many people get frustrated because they don't know about or pay attention to things like the priority bits, then wonder why their stuff isn't working.

Digest this and let me know if you need more!

[oldwakedoc]

This is exactly what I needed. Yes, I am seeing how the CAN transceiver uses filters to decrease the load it needs to process. Thanks, will try to post update soon.

[IDBoating]

Do you have a way to read and write CAN data on the network? Something like a CAN "sniffer" tool? You really need one if you're going to do much in this area... it will cost a couple hundred bucks but will save you ENDLESS hours of frustration. Very early on I tried to limp along without one but when I finally gave in, I kicked myself for not doing it years earlier.

I recommend the PCAN tool from Peak Systems. Available from PHYTools: https://phytools.com/collections/usb...an-usb-adapter. The folks at PHYTools are also very knowledgeable (unlike other vendors who are just salespeople). The PCAN tool will give you the ability to capture CAN messages, save them to disk for later analysis, transmit your own CAN messages either by manual trigger or programmable intervals, etc. There are more powerful tools but this is 98% of what anyone will ever need to develop CAN software.

[NG572]

freeheel4life,