Wheelemetrics: Custom Gotway/King Song -app

[esaj]

This is my "labor of love" that was born out of the need for hobby16 to have a app for recording data from his custom telemetry-devices (he's still working on those, as far as I know) and reverse-engineering the protocol used by Gotways and (at least) older King Songs. If your wheel works with the Gotway-app, it should work with this. It's pretty rough around the edges still, and not extensively tested, should work fine now, but I give no guarantees of anything. This is the first time I've written any software directly to Android, and in total have maybe about one weeks worth of experience with it, so there can be all sorts of quirks and problems with different Android-versions (and even different devices using the same version). YMMV

I tested the application installation & usage process with vee's Huawei-phone (Android 4.2.2, that's where the screenshots are from) and I've tested it during development with my Lenovo A10-70 A7600-F (or something along those line, Android 4.4.2) -tablet. Here's instructions for installation & usage:

Github-release:

https://github.com/esaj/Wheelemetrics/releases/tag/160126

Github sources:

https://github.com/esaj/Wheelemetrics

Forum download:

It's a basic Android apk, should be no developer-mode needed or anything, but your phone must be allowed to install software outside Google Play/whatever they're usually got from. If you've installed the Gotway-app from outside Google Play, you should be good to go, otherwise: 

Quote

From your smartphone or tablet running Android 4.0 or higher, go to Settings, scroll down to Security, and select Unknown sources. Selecting this option will allow you to install apps outside of the Google Play store. Depending on your device, you can also choose to be warned before installing harmful apps. This can be enabled by selecting the Verify apps option in the Security settings.
On devices running an earlier version of Android, go to Settings, open the Applications option, select Unknown sources, and click OK on the popup alert.

 

After downloading the app, and starting to install it, you are requested to accept the permissions the application needs:

Modify or delete the contents of your SD card:
The application writes log files to your sd-card & stores settings

Access Bluetooth settings / pair with Bluetooth devices:
Well, duh, the application uses bluetooth to talk with your wheel

Control vibration:
Vibration is used for speed warnings (the warnings can be disabled inside the app, see later in this post)

Test access to protected storage:
I must admit that I have no idea what this is... read-rights for SD-card?  

No usage data or similar is collected or sent anywhere (as you see, the app has no rights to connect to internet), also I don't keep any records of when, who or where is accessing the file for download (probably the server hosting it has some logs, but I don't think I even have access to those). Use as you wish, but if you decompile it (it isn't obfuscated) and make a gazillion dollars thanks to it (like that's going to happen anyway :D), please do at least consider giving a small donation to me  

For the more technically inclined, here are the required permissions from AndroidManifest.xml:

Quote

    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-permission android:name="android.permission.BLUETOOTH" />
    <uses-permission android:name="android.permission.VIBRATE"/>
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>    

After installation, this is shown:

 

Run in background is probably needed so that the app won't fall asleep even if your phones' screen does (there are calls to prevent the display from turning off, but I have no idea whether they work on all phones and all power-saving settings and whatnot). If you plan on trusting the vibration-alerts to keep you from riding over the speed-cliff, better turn that on (it was off by default at least on vee's phone).

Opening the application should show you the following screen (note that it's locked into landscape-mode, but will rotate 180 degrees if you turn your phone upside down):

The Speed, Power, Voltage, Current, Temperature, Trip & Odo -texts are replaced with actual values after the wheel is connected. On the right side are buttons for connecting to the wheel (Connect), hiding/showing speed warning settings (Speed Warnings), hiding/showing the graph in the middle (Graph view) and for recording telemetry data (Record).

When Connect-button is tapped, this view will be opened:

By default it will show all already paired BT-devices that support the SPP (Serial Port Profile), others will be filtered off the list. If your wheel is not yet paired, you can tap the "Scan for devices". Wait a while, as the scanning might take some time. I left out the filtering of SPP-devices only from scanning, in hindsight, probably should have done that. Anyway, this is the result when I scanned for devices:

That's my TV, and my work computer. GotWay_0763 is probably vee's MSuper, and GotWay_1200 is his MCM2s, so I connect to that (of course the wheel must be already turned on at this point).

After successful connection (you might have to try it again in case it doesn't go on first go, but usually it seems to work pretty well), the values on the main display will start updating and the graph is being drawn:

The graph -view can be scrolled back and forth by swiping (I think I set it to save last 500 samples or so), and zoomed in with pinching.

Under the graph view are a couple of text boxes, button to clear the graph and selection for which value is graphed:

Update graph - controls whether the graph is updated or not, in case you want to "stop it" to check something closer

Scroll to end - controls whether the graph will jump to the end when new data arrives, you might want to uncheck this if you want to scroll backwards while new data is coming in (ie. graph is updated)

Clear graph - clears the graph. Pretty self-explanatory, huh?

Voltage - This is the button (well, a "Spinner" in Android-lingo, kinda like a drop-down list) used to change what is being shown in the graph, hitting it you're given a list of choices:

Picking any of these, the graph will be cleared and it will begin graphing the chosen value from incoming data. Here I've switched it to show power and nudged the wheel a bit (it's actually leaning against my desk here, so the power is really low):

(BTW, the grey rectangles below are the text-edit field for writing commands to the wheel, and the lighter gray is the "Send"-button, they just don't fit in this small screen, and you probably won't need them. If you want to play around with those, see the command listing in the Gotway/Kingsong protocol reverse-engineering -topic: http://forum.electricunicycle.org/topic/870-gotwaykingsong-protocol-reverse-engineering/?do=findComment&comment=10155).

The graph can be hidden with the "Graph view"-button, if you want to see just the immediate values and the graph feels like it's distracting:

"Speed Warnings" -button show the current settings for the speed warnings:

You can set the values between 4/5 (first/second warning) and 43/44km/h (first/second warning).

Enable warnings"-checkbox can be used to enable/disable the warnings, they're enabled by default. Settings are saved & remembered after restart.

Note that if you don't hide the graph-view before pulling up the speed warning-settings, it will look a bit weird on small screen:

If you haven't got enough screen real-estate, hide the graph view first so it's easier to use the settings  Sorry, I know that the UI still sucks balls

The last button (Record) on the right-side controls the recording of telemetry-data. If you tap it, the text will change to show "Stop record". The app is now recording incoming data from the wheel. You can change the graphed value and warning settings etc., it will store all incoming data regardless of the UI:

After you hit stop record, the app will ask under what name the file should be saved:

Actually, the file is already saved in the directory & name the dialog shows, basically you can just rename it here. If you hit cancel, the file will still be there under the original name "wheelemetrics_log_YYYYMMDD_HHmmSS.txt", where Y/M/D/H/m/S are replaced with year, month, day, hour, minute and second of the time you started to record. WARNING: Should you choose an existing filename the app will NOT ask whether you want to overwrite, but simply overwrite directly, destroying the original data... Probably something I should work on

The format of the file is comma-separated values, as follows:

TIMESTAMP, SPEED, POWER, VOLTAGE, CURRENT, TEMPERATURE, TRIP, ODO  where

TIMESTAMP is milliseconds since the epoch (1.1.1970 12AM GMT). The data rate seems to be 5Hz (one data packet per 200ms), but the timestamp drifts a bit as it's stored in the app, and there can be delays, like BT-packet retransmits and the software handling of the packets might cause some delays here and there

SPEED is the speed in kilometers per hour (dot as separator)

POWER is the power used, calculated simply as VOLTAGE * CURRENT (the wheel does not send this), rounded down to nearest integer

VOLTAGE is, well, voltage in volts (dot as separator)

CURRENT is current in amperes (dot as separator)

TEMPERATURE is the temperature in Celsius (dot as separator), I think it's measured from the mosfets of the mainboard itself, not from motor

TRIP is the trip meter since last start up, in kilometers (dot as separator)

ODO is the odometer, ie. the total mileage of the wheel, in kilometers  (dot as separator)

And that's pretty much it. The app is closed totally by hitting Back-button, before which it will still check with you. 

(And this time it really should close itself up properly, unlike the earlier version linked elsewhere in the forums )

The app SHOULD work fine even if it's backgrounded but still running, but I haven't tested this very extensively, so please be careful in case you're using it to prevent going over the speed cliff and it crashes/falls asleep while you don't notice

[esaj]

Here's a video of me testing the app (slightly earlier version) a couple of days back with vee's MCM2s:

I start from front of my house with the graph showing voltage, go up the street (slight incline), after a little while I change the graph to show current. Then I go downhill, there are negative values because regenerative braking is charging the batteries. After 1:37 I turn around (the graph is showing power) and come back up the hill, then down the street and do a few circles before stopping.

[DiasDePlaya]

Congrats! You did a very good job!

[John Eucist]

That is so incredible.  l33t hax0r you are esaj!

[Gimlet]

Well done esaj!

It looks great and I like the idea of being able to see what was happening after something has gone wrong.

On the recorded data what do you use to review it? Does it open in your program or do you need to export it to some other program to analyse what has happened in the event of a wheel failure?

[esaj]

Well done esaj!

It looks great and I like the idea of being able to see what was happening after something has gone wrong.

On the recorded data what do you use to review it? Does it open in your program or do you need to export it to some other program to analyse what has happened in the event of a wheel failure?

The file is just a text-file with CSV-data (Comma Separated Values), a simple format supported by most (if not all) graphing and spread sheet programs (like Excel and LibreOffice). Here's a graph I made with LibreOffice from a recording I made while doing power braking twice in a row:

Right hand side scale is power (Watts), left hand scale is everything else (speed, voltage, current, temperature). Left out the trip- and odometer-values, as they're not that useful (but still in the data if someone needs them for something, like measuring distances with the data).

[esaj]

Jason McNeil had tested the app with a King Song (don't know which, the 14" / 800W -version?) and while it connected, it didn't show the values, don't know if the newer King Songs use different protocol or if there's some bug in the app. At least the older King Song-app I took a look at used the same protocol as the Gotway-app, so I'd expect it to work with King Songs that work with the Gotway-app, but don't know for sure. Kinda hard to guess the problem without a real device to test with, probably need raw data captures from the wheel to see if the protocol is different.

[Sam Clegg]

Would you be interested in open sourcing this so we can all help work on it?   github?    I was thinking of doing something similar with the solowheel xtreme (which seems to be a bluetooth low energy device).

[esaj]

Would you be interested in open sourcing this so we can all help work on it?   github?    I was thinking of doing something similar with the solowheel xtreme (which seems to be a bluetooth low energy device).

In time, yes, but not just yet, I still need to restructure the code somewhat, and maybe add a couple more features (vee also asked for audio-warnings and warning for dropped BT-connection, and I want to make the reconnecting logic better by detecting dropped connection based on not receiving data over something like 3 seconds, the default timeout seems to wait more like 10-15 seconds before the socket throws an exception)... Just try to find the time for everything, vee's also going to want his phone & wheel back soon   I want to give the project a fairly solid start with well-structured codebase, and on the other hand, I don't want to make code that looks like a turd public, in case any potential future employers should take a look at it  

Do note that this one uses SPP (Serial Port Profile) with Bluetooth "classic", which works entirely differently than LE (simple incoming/outgoing binary streams vs. publish/subscribe-type of thing), so the Bluetooth-side needs to be separately written for LE-devices. I did help @Kevin reverse-engineer the IPS Xima protocol (which uses Bluetooth LE) here:

http://forum.electricunicycle.org/topic/1133-reverse-engineering-xima-bluetooth-protocol/

and the app is supposed to also support the protocol for @hobby16's custom telemetry-hardware, so the long term goal is to provide some sort of an automatic detection for device/protocol, and if that fails, ask the user which type of wheel it is. I also have the Ninedroid and Fastwheel apps decompiled, but those are obfuscated, so a lot harder to reverse-engineer (especially since I don't have any of these wheels or data captures from them ).

[esaj]

Just went for a longer test ride, and at the end of it, found out that you shouldn't set the speed-warnings the wrong way around! While another one of those will still react, it seems the other one won't. Didn't test it for long after I noticed it, so not 100% sure on that, but if you use and especially if you rely on the speed-warnings, please set them so that the "First speed warning" is lower than the "Second speed warning". I will get this fixed ASAP, probably tonight.

Edit: and another related problem, if you close down the app through the "Are you sure you want to exit?"-dialog, while the warning-values are the "wrong way around", the app can crash on next start ups (and doesn't close up properly). The way to get around it is to go and clear the data for the app (it will only remove the settings, not any saved telemetry-data) from the Settings -> Manage Apps -> Installed -> Wheelemetrics Proto -> Clear data (the name of the "Manage Apps"-menu item may be a bit different on different Androids?)

I'm fairly sure I know where the problem is, I think I'm sorting the values before saving, when the sorting should only happen when the WarningVibrationService is reading the values at start up / listening for changes in them... 

[esaj]

The above condition is now fixed, the second warning level will be always forced to be at least 1km/h higher than the first one (and the min/max values are one higher on second). I thought that would be a better way to handle the problem in general, as it also prevents anyone from setting them "wrong" in the first place.

The download link is the same as earlier in the first post: 

On a brighter note, the only other problem that I found out while testing, which is fairly minor, was that the vibration warnings weren't distinctive enough from one another. I set the first warning to be "slower" vibration, so you can tell them apart more easily.

Also what did work just fine on my earlier test ride was (as long as the warning-levels were in "right order" ;)):

-Turning the Huawei screen off with power button  (the vibration-alerts still work)

-Sending the app to background with home-button (the vibration-alerts still work while it's in background)

-Starting another app while Wheelemeter is running in the background, I actually started the Gotway-app   (the vibration-alerts still work while it's in background)

 

Change log:

-Fixed problem with "out-of-order" speed warnings
-Fixed Bluetooth-reconnect stopping trying after first retry (whoops...)

-Modified speed warning UI to prevent user from setting the values in wrong order
-Modified first speed warning vibration to be more distinguishable from second (slower pulsing)

-Added vibration on device connected
-Added vibration on connection lost
-Added changing main layout background to red on connection lost / back to black on successful connection

Known bugs:
-Temperature-value still uses DecimalFormat, can cause the decimal-separator to become a comma in locales that use dot for thousand separator and comma for decimal separator (ie. Finnish ), making it hard to use recorded CSV-files without cleaning them through regular expression or such

TODO:

-Investigate King Song protocol problems?
-Recognizing lost Bluetooth-connection faster (if no data arrives within 3 seconds or so)
-Audio alarms
-Low voltage warning
-High voltage warning (excessive charge on regeneration)
-High/low current and/or power warnings?

 

metsa_20150915_204344.txt

asfaltti_20150915_210726.txt

[SirGeraint]

@esaj I downloaded the ble-sniffer WireShark plugin but as I expected my laptop is too old to have BLE.  So I have ordered a BLE dongle.  Should be here on Friday.  Hopefully I will be able to get it working to capture Ninebot One data.  Then either you could make a Ninebot version of your App or if you open source it then maybe I could modify it to work.

My career started out in Electronics, then I did some programming for Embedded controllers (Intel based).  I used to do a lot of fun stuff like you are doing but it was easier back then.  Now I get bogged down with the minutia of setting up the GUI and everything when I just want to get to the actual 'guts' of the program.  And I don't seem to have as much time as you.

[esaj]

@esaj I downloaded the ble-sniffer WieShark plugin but as I expected my laptop is too old to have BLE.  So I have ordered a BLE dongle.  Should be here on Friday.  Hopefully I will be able to get it working to capture Ninebot One data.  Then either you could make a Ninebot version of your App or if you open source it then maybe I could modify it to work.

Thanks, not sure when I have the time to start peeking at the Ninedroid closer, as said, it's heavily obfuscated and barely readable, it's going to take a lot longer than anything before. The open sourcing might also be a while away, I mean to write at least some general conventions on code style, maybe draw a few class diagrams etc.

My career started out in Electronics, then I did some programming for Embedded controllers (Intel based).  I used to do a lot of fun stuff like you are doing but it was easier back then.  Now I get bogged down with the minutia of setting up the GUI and everything when I just want to get to the actual 'guts' of the program.  And I don't seem to have as much time as you.

Lately I've slept around 4-5 hours a night, and then "reset" with a full night sleep every 3-4 days. Also working with sliding hours from home and not having kids is handy  Well, I do have a dog that needs to be taken out every now and then...   Still I feel that I don't have "enough" time  (especially since many things are dependant on the time of day or year, I can't visit a store at night, I can't ride during winter etc.)  

[sylvere]

Good job, thanks a lot  !

[Kevin]

I think the goal should be to get the UI to a good spot, and a framework in place that 'drivers' can be dropped in with relative ease for wheels of different capabilities/protocols. Perhaps this would attract interest from the companies themselves, so that they would write the drivers themselves or at very least provide internal information such that we could write the drivers without having to reverse engineer things every time a new version of hardware ships.

[esaj]

I think the goal should be to get the UI to a good spot, and a framework in place that 'drivers' can be dropped in with relative ease for wheels of different capabilities/protocols. Perhaps this would attract interest from the companies themselves, so that they would write the drivers themselves or at very least provide internal information such that we could write the drivers without having to reverse engineer things every time a new version of hardware ships.

I drew out a simplified class-diagram (leaving out the UI-details):

At first I thought that this is a complete mess, but it isn't as bad as I feared (but not really good either ). Mostly the problems are some direct calls and broadcasts that name their receiver-class (which stems mostly from my inexperience with Android, I didn't get them to work with intent-filters yet). Also the code is pretty messy from time to time (especially on the UI-side), and the class naming isn't always that spot on... but it'll get there. Once I get my todo-list cleared & this sorted, I will push this to github.

I'm used to working with Spring framework, so suddenly having to "wire" things together yourself, it seems there's sooo much boilerplate

The "architecture" has spawned out pretty organically, since I started with the BluetoothChat-example, made the first version which @Tilmann helped me to refine with the data captures & testing to work out with Gotway, then set out to refactor the bits & rework the UI, and adding more features, and the end result is the above...

[Sam Clegg]

I drew out a simplified class-diagram (leaving out the UI-details):

At first I thought that this is a complete mess, but it isn't as bad as I feared (but not really good either ). Mostly the problems are some direct calls and broadcasts that name their receiver-class (which stems mostly from my inexperience with Android, I didn't get them to work with intent-filters yet). Also the code is pretty messy from time to time (especially on the UI-side), and the class naming isn't always that spot on... but it'll get there. Once I get my todo-list cleared & this sorted, I will push this to github.

I'm used to working with Spring framework, so suddenly having to "wire" things together yourself, it seems there's sooo much boilerplate

The "architecture" has spawned out pretty organically, since I started with the BluetoothChat-example, made the first version which @Tilmann helped me to refine with the data captures & testing to work out with Gotway, then set out to refactor the bits & rework the UI, and adding more features, and the end result is the above...

I understand your desire to wait until you have something as little cleaner before making it public.  However, remember that the sooner you release it the sooner we can all help you with it.  Also, don't wait until it is perfect and feature complete, since as we all know this never happens with coding.   Eagerly awaiting the first commit so I can start hacking!

[esaj]

I understand your desire to wait until you have something as little cleaner before making it public.  However, remember that the sooner you release it the sooner we can all help you with it.  Also, don't wait until it is perfect and feature complete, since as we all know this never happens with coding.   Eagerly awaiting the first commit so I can start hacking!

I did plan out a better system for data-handling last night, but haven't written a single line of code for it yet  Still needs maybe some refining...

 

[esaj]

Vee wanted audio alerts, so I set out to see how audio can be used in Android. Turned out to be fairly straightforward, so I spent more time on finding suitable free audio than writing the actual code. I picked the most annoying sound I could find for the second warning (and there's of course no disable-button for the sounds yet ).

Warnings set at 17km/h and 21km/h:

Sorry for the blurry video...

[Jag_Rip]

Blurry video is on purpose to protect your IP

[esaj]

Blurry video is on purpose to protect your IP

Not much to protect there  

 

After a few trial & errors, @Jeffrey Scott Will sent me a small log from King Song this morning. While I only had the time to take a quick peek at it in the morning, I'm fairly sure I've already identified a couple of problems which cause the app not to recognize the data sent by the King Song (namely, one byte difference before the "starting" header, and apparently King Song does not send odometer data at all). I'll get around to fix them later tonight when I have the time.

 

About the problems with capturing data from King Song, the lesson learned was don't try to capture raw binary data with Blueterm on Android, I didn't test it thoroughly before asking people to do so, it will try to store the data as UTF-8 -text and mangle it to useless by replacing some bytes with EF BF BD.

The three characters correspond to the bytes EF BF BD (in hex), which is the utf-8 encoding of the Unicode character U+FFFD REPLACEMENT CHARACTER.

After seeing that, I checked the Blueterm source-code, and sure enough, it uses PrintWriter to write the bytes into the file 

public class PrintWriter
extends Writer

Prints formatted representations of objects to a text-output stream. This class implements all of the print methods found in PrintStream. It does not contain methods for writing raw bytes, for which a program should use unencoded byte streams.

Currently, the "best" app I've found has been https://play.google.com/store/apps/details?id=mobi.dzs.android.BLE_SPP_PRO&hl=en , although it has some problems too (you must set the IO mode to hex, or it too will try to write the data as UTF-8 -stream, and the app seems to slow to a crawl after logging the data for a few seconds...). Another option is the built-in Bluetooth traffic capturing in Android 4.4, but that requires you to turn on the developer mode on your phone, so I'd prefer to offer an app for less technical people (especially since not all phones let you disable the developer mode later on without wiping the entire phone): http://www.fte.com/webhelp/sodera/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm

If more capturing is required in the future, I'll write my own simple app for raw data capture (I once did a quick hack for Tilmann already, but it was built-in to the CSV-recording and mangling the CSV-output, so not really a long term solution ).

[SirGeraint]

 Another option is the built-in Bluetooth traffic capturing in Android 4.4, but that requires you to turn on the developer mode on your phone, so I'd prefer to offer an app for less technical people (especially since not all phones let you disable the developer mode later on without wiping the entire phone): 

Awesome!  I wish I had known about this before I ordered my Bluetooth 4.0 LE dongle.  I've always had Custom ROMs w/ Developer option enabled on all of my phones.  I now have a log loaded up into Wireshark and I hope that with the information about the Gotway/KS protocol that maybe I can unravel it (depending on how hard they've tried to obfuscate it).

Thanks!

[esaj]

Well, I then decided to rewrite the protocol-side of the application like I planned above (it did come similar as that fast class-diagram sketch, but somewhat different structure, same basic ideas of running data first through ProtocolResolvers to find out what kind of a wheel it is). After 5 hours of coding, refactoring and wiring things back together, between which I couldn't test it at all, I was very surprised that it still worked with the Gotway on the first try, warnings, graphs, recording & all. After picking up my jaw from the floor, I then wrote a ProtocolResolver & -Codec for KingSong & added it to the autodetection list.

I tested it a bit by sending the couple of data packets I had from the capture by faking the wheel with a simple test-software on my computer, and the voltage & current seem at least plausible, but since it's from a stationary wheel, hard to say about anything else.

So, now I'd need a someone with a King Song to volunteer as a test monke... Quality Assurance Specialist, and try if the damn thing actually works with a real King Song (don't be too surprised if it doesn't, but let's hope for the best). Also, even if it only shows garbage values, that'd be useful information too (at least then it has come close enough to identify something resembling Gotway or Kingsong protocols, but something's a little off).

 

Edit: I did make a little booboo, the temperature-reading is shown wrong in UI & logs... 

Edit: temperature-output fixed

[John Eucist]

Tested to work on my Mten2 and MCM2.  Could not get it to work on my KS14-800w because I can't even pair it on my Galaxy Note 4's native bluetooth interface.  I couldn't pair it even with their own beta app the last time I was at their factory.  HOWEVER, using one of the engineer's phone, I also reproduced the fact that it couldn't connect on HIS phone's native bluetooth interface BUT he was able to connect using the same beta app.  I was running Android 5.0.1 while he was running Android 4.x.  This is a big mystery.

[esaj]

Tested to work on my Mten2 and MCM2.  Could not get it to work on my KS14-800w because I can't even pair it on my Galaxy Note 4's native bluetooth interface.  I couldn't pair it even with their own beta app the last time I was at their factory.  HOWEVER, using one of the engineer's phone, I also reproduced the fact that it couldn't connect on HIS phone's native bluetooth interface BUT he was able to connect using the same beta app.  I was running Android 5.0.1 while he was running Android 4.x.  This is a big mystery.

When you say "native bluetooth interface", do you mean simply pairing or something else? And do you know if the 800W uses "classic" Bluetooth or LE? Does it work with Gotway App & the older King Song app (if you get it to connect) or only the new beta KS-app?

@Jeffrey Scott Will tested this to work with his KS14C 500W, so at least it seems to work with older King Songs.