Wakespeed WS500 Regulator monitoring app

The friendliest place on the web for anyone who enjoys boating.
If you have answers, please help by responding to the unanswered posts.

DDW

Guru
Joined
Apr 26, 2018
Messages
3,213
Location
USA
I’ve posted before about a little application I wrote for the Wakespeed regulator. It is a great piece of equipment, however the user interface is the source of much derision, harking back to teletype terminals and command line interfaces. Nothing wrong with that, it just needs to be buried under a modern UI. There are a couple available, I have one or two but didn’t like them for one reason or another.

My efforts of last year’s trip just logged the data, and allowed some programmability. This year in my spare moments between piloting and ogling the scenery I’ve improved it a little. I’l post the completed app after a little more refinement, I’m posting here to see if there are some useful features that ought to be included that I haven’t thought of. Not everything is easy to do or can be done of course, but if you have any ideas, please share and I’ll consider. I may be the only one here geeky enough to find this stuff interesting, but just in case, here goes.

It uses the serial interface of the WS500, requiring a cable (USB-B I think on the WS500 end, and USB-A or C on your laptop end as needed). I have one permanently strung up to the pilothouse nav table where my laptop sits, normally running OpenCPN. You launch the app, plug in the cable, and it should automatically connect and begin logging. If it picks the wrong serial port you can pull down the menu and pick the right one, the click the Connect button. The log screen looks like this:

LogTab.jpg


This is the raw data which Wakespeed calls “human readable” and technically it is, but it could be a little better ;). On the log tab, the latest data (sent by the WS500 once a second) is parsed and the more interesting parameters are displayed in the data boxes at the top. You can pause the scrolling and select a line and the selected line’s data will be displayed. The check boxes do what they say: Enable Debug forces the log to verbose with much more info, no definitions as to what they mean but Wakespeed may ask for the debug log if you have an in-depth problem. Force to Accept and Force to Float puts the regulator in those modes - note that it may immediately change back , depending on the regulator settings and current operating conditions. Most useful if it has made the jump to float early. Pause stops the scrolling for examination.

You can save the log as a text file at any time, and also read in a saved log file to examine it later using the OS menu bar Save and Read menus. There is an alternative mini view accessed from the menu bar View menu, which is a small window with just the data boxes, you can put this in a corner of the screen for monitoring without hogging all the screen space. The app will continue to run and log in the background until you quit it.

MiniView.jpg


There is also a window to view the battery parameters of most interest, it will be populated when it sees the first data lines with this information, sent every minute or so. It is also accessed from the menu bar View menu. You can edit any of the values displayed to change the WS500 settings, then write them back to the regulator (this will cause a reboot, but seems to be safe to do underway). The reboot kills the serial port, the app attempts to reconnect after the reboot but you may find you have to do that manually. You will have to consult the Wakespeed literature for the parameter definitions, though a brief description is provided.

BatteryParams.jpg


The biggest addition I made this year is the Graph tab in the main window. Clicking on this changes the display to a graph of the data, drawn in real time (or rendered from a saved log file) and is much more entertaining than the log file. It normally free runs and scrolls as new data is captured, the color coded data boxes at the bottom represent the last data line captured. However you can pause the scrolling, or by clicking anywhere on the graph, a cursor will appear and can be dragged where ever you like, now the data boxes will represent the cursor position. Also, as the cursor is dragged around, the selected line in the log tab is highlighted so you can examine the actual data if needed without having to search for it. Unchecking any of the data boxes removes that parameter from the graph. Time of day is the horizontal scale.

Here is a whole day’s run of several hours from the saved log, in it you can see pretty much every electrical event that happened on the boat that day. The amps charge into the house battery (in dark blue), and the field drive (in green) tell a lot of the story. The graphics look a bit sharper than this on the laptop, the forum software down samples the screen capture, making it fuzzy:

GraphTab.jpg


The graph can be zoomed in or out with the arrow controls to the left, and panned with the slider bar. Zooming in a little at the beginning of the day:

Begin.jpg


The large downward spikes in amps (dark blue) is the anchor windlass being operated intermittently while the chain was washed of sticky brown mud at about 9:32 AM. The field drive is maxed at 82% (I have that set as a maximum in the regulator). When the rpm drops from fast idle to idle at 9:36 (maneuvering to leave the narrow anchorage exit) the amps drops as the alternator has insufficient speed for max output, even though the field drive is maxed. The very large dip in amps (to -20) at 9:38 is the microwave running for a minute to warm breakfast. Then the rpm is slowly increased as the engine warms, reaching cruising rpm at 9:49. At about the same time, there are little momentary dips in the field drive (green), this is the regulator responding to the temperature slope of the alternator (in black) approaching the 100° C limit I have set in its parameters. These get deeper and more frequent to control temperature. (This is the reason I have the field limited to 82%, otherwise the approach to 100° is very steep and the field cutbacks are much more radical).

At about 10:01, it switches to Accept from Bulk, which can be seen by the field drive and amps beginning to slope downwards, while the voltage (in red) flattens at accept voltage. Some of the little dips and bumps in the amps are due to the refrigerator cycling or other small DC loads.

Toward the end of the day some different things can be seen:

End.jpg


At 10:25 the throttle is cut back to look at some whales. This lowers alternator RPM, to maintain regulation the field is bumped up again. Since the cooling fan drops capacity with rpm, the alternator temp is seen to climb. A bit later at 11:26, there are some sharp spikes in amps, field, and even voltage - this is the bread machine doing a kneading cycle which switches the motor on and off. It occurs again a few times. The machine doesn’t draw that much, what you are seeing is transient response as the regulator deals with the step in demand (this is obvious when zoomed in closer). At about 12:07, the throttle is cut to anchor for lunch, again the field comes up to maintain regulation, and the alternator temp climbs. Finally there is a large spike in field, this is the anchor windlass dropping the chain.

I have been capturing every day's run and saving it, keeping the graph view active for entertainment. If you are having a charging issue, this gives much easier visibility into what is actually going on over the whole charge cycle.

Would anyone but me find this useful? Am I missing a key feature? One thing I've thought of is the ability to write comments into the log, for later reference.
 
Very cool for anyone really wanting to see under the covers. I am selling the boat that has the wakespeed installed but I would have been interested. Nice work.
 
Very very nice. Soon I will swap out my old Balmar for either the WS500 or the Zues. Still waiting for the dust to settle there. But this is fantastic.
 
I did add the comment facility. It's been working well keeping a record of all the activity for the last 800 miles or so. I've been using it on my Mac, but will compile for W11 also. I have limited ability to test on W11, but will give it a try - should work ok.
 
Disclaimer: I am Al Thomason of Wakespeed.

I have not participated in Forums for a number of years, for reasons. But someone passed on a link to this, and I wanted to reach out with some thoughts and a bit of history.

First off, nice! I am a big fan of Data!

I have always believed in openness, hence the publishing of the Wakespeed API in our Communications and Configurations guide. Along the way a few folks have taken advantage of it. I remember a couple of NodeRed projects, a SignalK. And of course today OPE and OGSS and Victron and Garmin and .. We made a choice not to offer Yet another fixed/closed display, instead enabling existing surfaces already commonly installed via standardized and published communications methods and protocols.


Going back a ways in history, what 14+ years?, to the original VSR project. Back then another person was going to create a cell phone app, something I personally have no skill in. For a number of reasons the CSA protocol method was selected for M2M communications, as you are doing your program, and as used with the Wakespeed Configuration app. And yes, it just happens to be readable by humans. But its primary purpose was for reliable M2M communications without introducing a mess of problems some other approaches have.




But another insight I want to pass on is: the CSA data is present not only via a Serial Terminal interface using VSP on USB, but we also support the same format within a CAN Terminal wrapper, as well as a Bluetooth wrapper for our Pro offering. If you are interested, would be happy to help you with your program extending it to make use of a CAN based communications. It might not be well known but the Wakespeed Universal Transfer tool is able to utilizes a low cost CAN-USB like this USB to CAN Analyzer Adapter with USB Cable for transferring configurations to a Wakespeed using the external CAN connection. Myself I used it in early days aboard Viking Star: I set up an RPI connected to the ships WiFi added a CAN Hat and wrote a simple Term program to apply the CAN wrapper. Then SSHed into the RPI for ready access and logging. No USB...

You could of course also port in SignalK as a way to gain data access, almost all operational data is really available via existing CAN packets, without the need to drop into the Terminal Wrapper.


If you are interested in pursuing something like this drop me a PM with your direct contact information and I will be happy to reach out to you as well perhaps share simple code snippets. If you wish.

And if you end up posting this somewhere, let me know: will add a link to it in the comms guide.
 
Last edited:
Hi Al, we have talked before when I first put this unit in. Some issues with premature switching to float. It has been working fine, I just wanted more (and easier to interpret) visibility into what was happening in the charging system.

What I want, and I think what most people want, is a very simple system to monitor. From my perspective, the best would be a cheap SSP Bluetooth dongle that could be plugged into the WS500 serial port, the pretty much any laptop and Android device could wirelessly do what my app does (not iOS unfortunately).

I'll get in touch with you.
 
Right. Not really possiable though - fully metal box. ‘tis why the new Pro comes in a plastic one.

If you are interested in enabling a CAN based approach, check out the Terminal section in the RV-C spec at rv-c.com | Your Source for RV-C Information.

Or look to the new Pro offering itself. (trying hard to keep away from being an advertisement here, but still giving info..)

Let me know if you go further with this project!
 
Back
Top Bottom