Gotway/Kingsong protocol reverse-engineering

[Tilmann]

Easier said than done... while I have designed & written software in Java (the same programming language that Android uses) for living for the last 7 years, I've never before written a "pure" Android-app, so even that's going to take a while to do "properly". While Google Glass is based on Android, I'm under the impression that you just can't take any Android-software and turn it into Glass-software "just like that". At the very minimum, I think I'd need a real device to test with to see what works and what doesn't.

Sorry, I dunno about Google Glass, but I could not resist and sniped a Recon Jet yesterday on ebay (same concept as Glass). They offer a SDK for their product. Actually, it seems to be a set of libraries to plug into the standard android SDK (Jelly Bean version): http://www.reconinstruments.com/developers/

I am not a qualified developer by any means, but I work in an IT department and hope for some advise from Java-savvy colleagues on the usefulness of that SDK in its present early stage. @esaj, as we both live in the EU, maybe we can work something out with shipping that toy back and forth? I see a long winter in our future and at least one of us will stop riding when there's ice on the road .

The other challenge I see waiting for us, is to extract the necessary telemetric data from our wheels. Sure enough, my Msuper sends at least some of it via Bluetooth, but I haven't seen the interface published anywhere. I got no clue what it takes to reverse engineer such a radio link (i.e. "hack it").

[esaj]

Sorry, I dunno about Google Glass, but I could not resist and sniped a Recon Jet yesterday on ebay (same concept as Glass). They offer a SDK for their product. Actually, it seems to be a set of libraries to plug into the standard android SDK (Jelly Bean version): http://www.reconinstruments.com/developers/

I am not a qualified developer by any means, but I work in an IT department and hope for some advise from Java-savvy colleagues on the usefulness of that SDK in its present early stage. @esaj, as we both live in the EU, maybe we can work something out with shipping that toy back and forth? I see a long winter in our future and at least one of us will stop riding when there's ice on the road .

The other challenge I see waiting for us, is to extract the necessary telemetric data from our wheels. Sure enough, my Msuper sends at least some of it via Bluetooth, but I haven't seen the interface published anywhere. I got no clue what it takes to reverse engineer such a radio link (i.e. "hack it").

That could be interesting, although the device itself seems to have some serious limitations, for example, 1FPS refresh rate recommended for apps, otherwise the battery won't last four hours at a time and the input is fairly limited (four directions and two buttons), but that's probably true for all of this type of devices. Their own API is pretty small, looks like head tracking and connectivity. "Our philosophy is to rely on the Android API as much as possible and to extend it only when it makes sense.".

I've taken a peek at the Gotway app (it doesn't appear to be really obfuscated, but the decompiled code is sometimes pretty weird, probably due to some compiler optimizations or such which occurred when it was turned into bytecode), it's built on top of the same example I've used as a base for the prototype, and looks like it's using a text-based protocol, which shouldn't be really hard to reverse engineer (it would be easier if I could work with protocol data capture from a real Gotway). We could probably use the same app to support both Gotway/Kingsong data (if they indeed are the same) & the protocol from hobby16's telemetry hardware.

[bleu9mm]

Wow !!! Really cool, those glasses !!! I ordered my used Google glass last tuesday for $560 on Ebay. Can't wait to get them !!

If you buy on Ebay, ask not the item to be shipped via their proprietary global shipping service, it takes an extra 5 days !!!

Bleu9mm

[Tilmann]

@esaj: wow, you're amazing! Gotway and Kinsong appear to use the same protocol to a large extent. I can use the Kingsong app to connect to my GW 18 and everything works, just the odometer (total kilometer count) shows zero.

If I can be of any assistance producing a data trace with my Gotway, I am happy to do so. But: you would need to explain the "how to" to a total noob, sorry.

As for the technical limitations of the Recon Jet: give it a few days to arrive here from the UK and another few for me to explore what it does with its standard SW. Then I'll try a review from an EUC riders perspective.

[esaj]

@esaj: wow, you're amazing! Gotway and Kinsong appear to use the same protocol to a large extent. I can use the Kingsong app to connect to my GW 18 and everything works, just the odometer (total kilometer count) shows zero.

If I can be of any assistance producing a data trace with my Gotway, I am happy to do so. But: you would need to explain the "how to" to a total noob, sorry.

You could try with https://play.google.com/store/apps/details?id=es.pymasde.blueterm&hl=en to see if you can connect to the wheel, if you can and if the data is indeed plaintext (probably numbers and maybe letters, may still look like gibberish, from a quick look it appears the numbers will be right after another with four digits each, like voltage, speed etc.), and maybe something else in between, capture (I haven't actually used Blueterm myself, but there should be option to capture the data to a file ) something like ~10 seconds worth of it (while the wheel is stationary, I think that should be enough to get a clue) and send to me or post here. If you need further instructions with Blueterms' use, I'll try to test it myself and write better instructions.

 

Edited August 11, 2015 by esaj

[esaj]

Ok, I got to a start from the data captures sent by @Tilmann. It's NOT a plaintext protocol, as I first thought, due it being parsing integers from text, but thankfully it seems to be a simpler binary protocol than, say, ASN.1 or Zigbee. I've got to the point where I can locate the following values:

62,84V
0,00km/h
0,000 "mRunNow" (trip-meter?)
-0,25A  Current
36,530   Temperature (Celsius?)

They're using a somewhat weird (and inefficient) way of parsing the binary data, where it's first turned into a hex-string and at some point decoded to string with GBK-charset ("GBK is an extension of the GB2312 character set for simplified Chinese characters, used in the People's Republic of China"), and then parse the values 2 bytes at a time as base-16 (hex) integers (which are later cast to shorts) from the middle of other data (I didn't notice at first that the integers were parsed as base-16). The datapackets seem to be separated by "18 5A 5A 5A 5A" (as hex), but it's not always the voltage etc. data after that. I'll try to dig deeper when I got the time.

Here's an example of the datacapture with seemingly correct values (after one of the 18 5A 5A... -headers):

INDEX
0       188C  Voltage, 1/100th
1       0000  Speed, fixed point, 3.6 * value / 100
2-3     00000000  "mRunNow", 32bit-value, first bytes are high bits (shifted up 16 bits), the later low bits, 1/1000th (so probably meters turned into kilometers)
4       FFE6  Current, 1/100th
5       F808  Temperature, 1/340th + 36.53

The decoding seems to end (to start a new round later) after it detects something like "00 00 04" (called "type_ch" in the code) after the measurement values:

                      str2 = str1.substring(i + 4, i + 4 + 4);
                      BluetoothChat.this.mPackageTemp[(i / 4)] = Integer.parseInt(str2, 16);
                      continue;
                      str2 = str1.substring(i + 4, i + 4 + 4);
                      BluetoothChat.this.mPackageTemp[(i / 4)] = Integer.parseInt(str2, 16);
                      continue;
                      str2 = str1.substring(i + 4, i + 4 + 2);
                      BluetoothChat.this.type_ch = Integer.parseInt(str2, 16);
                    }
                  } while (BluetoothChat.this.type_ch != 4);

 

The odotemeter seems to be sent out in it's own packet, terminated again with 00 00 04:

18 5A 5A 5A 5A 55 AA 00 08 82 EE 00 00 00 00 00 00 00 00 00 00 00 00 04

Don't know what the 55 AA is, but the 00 08 82 EE corresponds to 557 806 which is closest to the trip meter value of 557,798km I could find (that should be Tillmans odometer, but I think there's some rounding error, as so far I can't find that exact figure anywhere, and the value is divided by 1000 (to get kilometers from meters) and then formatted for display.

If someone has the Kingsong App, could you please send it to me (or just link where I can get it), if it's using the same protocol, getting it decompiled too might give some more clues.

 

Edited August 12, 2015 by esaj

[Jason McNeil]

Here you go sir. You're quite a hard core developer!  
 King_Song.apk

[esaj]

Ok, after lots of trial-and-error, I've got something cohesive out of the data captures. Currently I'm scanning for the hex values "18 5A 5A 5A 5A", which seem to be some form of delimiter between messages, and if I then find "55 AA" after that, it looks like the following 4 bytes are the odometer. I keep a backbuffer of previous bytes, and if 18 bytes backwards from the last delimiter, a "AA"-byte is found, it looks like the following 12 bytes contain the Voltage, Speed, Trip, Current and Temperature -values. I modified the app-proto I've made to work with the captured data sent by a mock-server on my desktop (over a Bluetooth USB-dongle) and got it to display the values correctly (I assume).

If someone with a Gotway or Kingsong could test this, if they get anything out from the actual wheel, and tell me:

App  <-- Download here with your phone/tablet  EDIT: Whoops, typoed link...

It's an unsigned debug-app, so your phone/tablet may refuse to install it (maybe, I don't know if it works with "normal" phone/table), unless you've enabled developer-mode: http://www.greenbot.com/article/2457986/how-to-enable-developer-options-on-your-android-phone-or-tablet.html  (WARNING: it says you can't disable it anymore with certain phones without wiping the entire phone).

I don't know if it will connect to the actual wheel, as I've had nothing but the dongle to test it with. There are two connections options:

The first one is the Bluetooth-logo I've circled with red in the below picture. This tries to do a "Secure"-type connect to device. If that doesn't work, tap on the three vertical blocks besides it, and select "Connect a device - Insecure" and try with that. Also, I have no idea how the UI might look with a device that has a resolution below 720P.

 

PS. I'll move the whole "reverse engineering" -part of this conversation to another thread later on...

 

Edited August 12, 2015 by esaj
Typoed link

[Tilmann]

@esaj, you're unbelievable! The app connects and shows data. Voltage and odo seems correct, temp appears to be off at first glance ... will send the log in a few minutes by email ...

[esaj]

Ok, I split the topic of from the other thread, as it was going way off-topic from the original...

From the app proto -logs @Tilmann sent me while the wheel was moving, it looks like the data is transmitted somewhat differently during movement. I'm not sure, but it would look like the voltage, speed etc. data are sent in a similar way as the odometer during movement. Snippet from the log:

6420,0,220,0,0,0,570473,0

6420,0,220,0,0,0,420020118,0

The first line is similar as the "normal" data I got from the Blueterm/btsnoop -logs recorded while the wheel was stationary. The latter shows a weird number as odometer-value, but the app picked it up because it matches the odometer-pattern. From what I've gathered earlier going through the decompiled Kingsong/Gotway-apps, this is what I was expecting, but never got out from the stationary logs, it looks like voltage/speed/etc -data is sent similarly as the odometer. That's only one 32bit value, but if we look at 420020118 as hex:

1908 FF96

The first 16bits (1908) would be the voltage (6408 -> 64.08V), and the second would be speed. FF96 = 65 430 or -106 signed, the Gotway/KS apps just always display the number as positive (reverse the sign if value < 0), and calculate the actual speed like so:

              double d2 = (short)this.mPackage0[1] / 100.0D * 3.6D + 1.0E-4D;
              double d1 = d2;
              if (d2 < 0.0D) {
                d1 = -d2;
              }
              this.mSpeedNow = d1;
              this.mSpeed = localDecimalFormat.format(d1);
              i = this.mSpeed.indexOf(".");
              this.mSpeed = this.mSpeed.substring(0, i + 3);

So, 106 / 100.0 = 1.06, times 3.6 = 3,816 km/h (or maybe it's m/s, then it would be around 13,73km/h). The values following this are lost, because the app assumes the two values to be combined as odometer-value.

A Blueterm/btsnoop -data capture of a moving wheel could help, but it's hard to work with without knowing the numbers I'm looking for. It looks like even stationary, there's lots of "extra" data moving about, and I have no idea what it is, the app doesn't seem to use it either, but it complicates reading the data. But, I could just "blindly" try to take a stab at reading the values to see if I get anything coherent out of them.

 

Edited August 12, 2015 by esaj

[Gimlet]

Is there any way of applying this to a Pebble Time watch?

 

[esaj]

Is there any way of applying this to a Pebble Time watch?

If it has Bluetooth and can connect to other devices (SPP at least in case of Gotways to be exact), probably yes, but I don't know anything about developing software to it.

Edited August 12, 2015 by esaj

[Gimlet]

Well it's definately bluetooth and has its own app developers page and tools but it all way beyond me.

[Tilmann]

@esaj: I am eternally thankful for your analysis and feel bad, that my hasty snapshots of data leave you with such a guessing challenge. Unfortunately, my workload does not permit me to produce more systematic data sets before the weekend. I assume it would be helpful to capture some movement data with both your app logging and the btsnoop function while carefully noting the values displayed by the GW and Kingsong apps. 

@Gimlet: As luck has it, I've got a Pebble watch, too (1st gen) . And the Pebble SDK is likely much more mature than the Recon Jet's. I would happily mail my Pebble to Esa if he wants to experiment with it. How about it Esa? Who needs a day job anyway ?? 

[esaj]

Well it's definately bluetooth and has its own app developers page and tools but it all way beyond me.

I took a quick look at the documentation, but didn't find anything else except messaging with a phone. Of course the app could "talk" to a Pebble Watch, but I think the watch needs its own app that shows what the app tells it to. So basically it'd be like  wheel <--> phone <--> Pebble, you'd always need to have the app also on. I don't think I have the time right now to start investigating this further, as I've already promised to work on the app for hobby16's telemetry hardware, and now am also looking into integrating Gotway/Kingsong support into it  

@esaj: I am eternally thankful for your analysis and feel bad, that my hasty snapshots of data leave you with such a guessing challenge. Unfortunately, my workload does not permit me to produce more systematic data sets before the weekend. I assume it would be helpful to capture some movement data with both your app logging and the btsnoop function while carefully noting the values displayed by the GW and Kingsong apps. 

Don't feel bad, I'm not really in that much of hurry   My friend was going to buy a Gotway earlier, but then cancelled the order, it would be so much easier with a real wheel to test with.

And yes, probably the most useful set of data would be both the log-file from app and btsnoop -capture, that way I could probably find the "matching positions" from both data files, and take much better guesses () at what they are. I could maybe also build a version of the app that does much more detailed log of what it's reading.

 

@Gimlet: As luck has it, I've got a Pebble watch, too (1st gen) . And the Pebble SDK is likely much more mature than the Recon Jet's. I would happily mail my Pebble to Esa if he wants to experiment with it. How about it Esa? Who needs a day job anyway ?? 

I'm already currently supposed to be on vacation, yet spent my time writing code    Plus I've got an infinitely postponed wall paint job, because it's been mostly raining all the time (plus I haven't even sanded it all yet )...

[Tilmann]

 

So, 106 / 100.0 = 1.06, times 3.6 = 3,816 km/h (or maybe it's m/s, then it would be around 13,73km/h). 

Sorry, I forgot to answer in my previous post: 3,8 km/h sounds much more plausible than 13,7 km/h. I was spinning my Msuper in my living room in circles around me until I got all dizzy .

Edited August 12, 2015 by Tilmann

[esaj]

Sorry, I forgot to answer in my previous post: 3,8 km/h sounds much more plausible than 13,7 km/h. I was spinning my Msuper in my living room in circles around me until I got all dizzy .

Yeah, figured so too, as it appears that the Gotway/KS apps just place the value then to the UI.

I did some hasty notes on a screenshot of hex editor of what I (think I) know so far:

The odometer-value seems to always come after 18 5A 5A 5A 5A (that's four times 5A, I've highlighted only three in the screenshot) -header + 55 AA. After that, the following 4 bytes contain the odometer value as 32bit int. Going 17 bytes backwards from the 18 5A... -header, you hit the part which seems to hold the values for voltage (int16), speed (int16), trip (int32), current (int16) and temperature (int16). Sometimes though, there's something other data when you go back the 17 bytes, so I first check if there's "AA" before the assumed voltage etc. data, then it seems to hold true. It could also be that it even isn't actually the right data, but just happens to match and give believable values for those measurements...

EDIT: Oh, right, the data also seems to be big endian.

So I'm assuming that once the wheel is moving, there's a similar "18 5A 5A 5A 5A 55 AA" -pattern in front of the voltage etc. data also, and that's why the app log alternates between the actual odometer-value and "something else" (which looks like the first 4 bytes from the data, as the voltage- and speed-values seem to make sense). We'll see...

I don't know what all the other data is, it doesn't seem like the app is using it either, although it's hard to say for sure, as the decompiled code is very complex. Of course at least some of it is the Bluetooth SPP-protocol, I tried to figure out how to export the payload only with Wireshark, without much success.

This is the part of the decompiled code that reads the values (to see how the final values are calculated), the this.mPackage0 -array contains the values for voltage etc., read from the binary data (after it's first turned into a hex string and then parsed back 2 or 4 hex values at a time as integers, don't know why, probably they didn't know how to handle binary data in Java ). Also I don't know why they add +1.0E-4D (that's D for double, 64bit float) to the values, rounding issues? And the whole format, look for "." (dot, for example, this.mSpeed.indexOf(".") ) and then substring also makes no sense. Actually the character to look for is "," (comma) in Finnish locale, which might explain at least partially why the app only seems to work with US and Chinese locales (and probably anything else that uses dot as a decimal separator instead of comma?).

		      DecimalFormat localDecimalFormat = new DecimalFormat("##.####");
		      this.mVoltage = localDecimalFormat.format((short)this.mPackage0[0] / 100.0D + 1.0E-4D);
		      int i = this.mVoltage.indexOf(".");
		      this.mVoltage = this.mVoltage.substring(0, i + 3);
		      double d2 = (short)this.mPackage0[1] / 100.0D * 3.6D + 1.0E-4D;
		      double d1 = d2;
		      if (d2 < 0.0D) {
		        d1 = -d2;
		      }
		      this.mSpeedNow = d1;
		      this.mSpeed = localDecimalFormat.format(d1);
		      i = this.mSpeed.indexOf(".");
		      this.mSpeed = this.mSpeed.substring(0, i + 3);
		      set_vibrator_speed(d1);
		      this.mRunNow = localDecimalFormat.format((this.mPackage0[2] * 65535 + this.mPackage0[3]) / 1000.0D + 1.0E-4D);
		      i = this.mRunNow.indexOf(".");
		      this.mRunNow = this.mRunNow.substring(0, i + 4);
		      this.mCurrent = localDecimalFormat.format((short)this.mPackage0[4] / 100.0D + 1.0E-4D);
		      i = this.mCurrent.indexOf(".");
		      this.mCurrent = this.mCurrent.substring(0, i + 3);
		      this.mTem = localDecimalFormat.format((short)this.mPackage0[5] / 340.0D + 36.53D + 1.0E-4D);
		      i = this.mTem.indexOf(".");
		      this.mTem = this.mTem.substring(0, i + 4);
		      this.mRunAll = localDecimalFormat.format((this.mPackage4[0] * 65535 + this.mPackage4[1]) / 1000.0D + 1.0E-4D);
		      i = this.mRunAll.indexOf(".");
		      this.mRunAll = this.mRunAll.substring(0, i + 4);
		      if (this.mChatService.getState() == 3)
		      {
		        this.dialview.setVoltage(this.mVoltage);
		        this.dialview.setSpeed(this.mSpeed);
		        this.dialview.setRunNow(this.mRunNow);
		        this.dialview.setCurrent(this.mCurrent);
		        this.dialview.setTem(this.mTem);
		        this.dialview.setRunAll(this.mRunAll);
		      }

The "mRunAll" (odometer) -value is read from another array (this.mPackage4, not this.mPackage0), as it's sent separately in the data.

So all the values are integers (16 or 32bit), which represent fixed point values, and are calculated as follows:

Voltage = signed 16bit int / 100.0  (ie 188C = 6284  / 100 = 62.84V)

Speed =  signed 16 bit int / 100.0 * 3.6  (absolute value, negative sign is removed if riding "backwards", as Gotways do not have front and back?) Apparently in km/h

Trip = signed? 32 bit int / 1000.0  (so meters, changed into kilometers)  (signing probably doesn't matter, as the range is around 2.1 billion meters before it wraps over...)

Current = signed 16 bit int / 100.0  (A)

Temperature = signed 16bit int / 340.0 + 36.53  (Celsius?)

Odometer =  signed? 32 bit int / 1000.0  (meters, changed into kilometers)

 

 

Edited August 13, 2015 by esaj

[Rotator]

Great work!

Edited August 13, 2015 by Rotator

[esaj]

Ok, I built a specific debug-version for @Tilmann , who then has graciously provided me with log files with all the extra-bluetooth traffic removed and just plain data dump of a wheel spinning freely in one direction and then to the other, until it cuts out. This data set was enough to find the fairly simple pattern (I was mostly thrown off by the unimaginably complex way Gotway-app-developers have went to read the binary data, and all the extra Bluetooth-frame data that was in the btsnoop-captures) that holds the data.

Basically, if you want to read it yourself, you need to look for two byte patterns (in hex):

04 18 5A 5A 5A 5A 55 AA

Once you detect this, the following 12 bytes will contain the following data, and calculate the real value:

Voltage = signed 16bit int, real value = value / 100.0   (ie 188C = 6284  / 100 = 62.84V)

Speed =  signed 16 bit int, real value = value / 100.0 * 3.6  (km/h, Gotway app negates the value if < 0, so it never shows negative speeds in case the motor is running in "reverse")

Trip = signed/unsigned 32 bit int, real value = value / 1000.0  (kilometers)  (signing probably doesn't matter, as the range is around 2.1 billion meters before it wraps over...)

Current = signed 16 bit in, real value = value / 100.0  (A)

Temperature = signed 16bit int, real value = value  / 340.0 + 36.53  (Celsius)

 

After you've read these, the next pattern is: 

18 5A 5A 5A 5A 55 AA

So basically the same as above, except there's no 0x04 before it. After this, the following 4 bytes will contain the odometer-value:

Odometer =  signed? 32 bit int, real value = value / 1000.0  (kilometers) (same thing with signing as in trip-value)

 

And that's it. There's some other data between these, but I really haven't even tried to figure out what it is, doesn't seem to change. Here's three messages with voltage & odo

 04 18 5A 5A 5A 5A 55 AA 19 A7 FF FF 00 00 00 01 FF E0 F8 BD 00 01 FF F8 00 18 5A 5A 5A 5A 55 AA 00 09 1A 9D 00 00 00 00 00 00 00 00 00 00 00 00 
|  <---   header  --->  |Volt |Spd  |   Trip    |Crnt |Temp |    Unknown   | <---  header  ---> | Odometer  |  Unknown, padding? Always zeroes  |

 04 18 5A 5A 5A 5A 55 AA 19 A7 FF FE 00 00 00 01 FF D0 F8 C2 00 01 FF F8 00 18 5A 5A 5A 5A 55 AA 00 09 1A 9D 00 00 00 00 00 00 00 00 00 00 00 00 
 04 18 5A 5A 5A 5A 55 AA 19 A7 00 00 00 00 00 01 FF CC F8 C9 00 01 FF F8 00 18 5A 5A 5A 5A 55 AA 00 09 1A 9D 00 00 00 00 00 00 00 00 00 00 00 00 
 04 18 5A 5A 5A 5A 55 AA ...

Here the wheel has been *almost* stationary (speed is around -1 / 100 * 3.6 = -0,036km/h). On the next sample, still moving a bit, then stationary. The "unknown" parts seem to repeat the same all through the logs I have.

I've modified the Android-prototype app I have to support Gotway & Kingsong. It's a bit (ok, a lot) rough around the edges, but if anyone wants to give it a go to see it really works with the real device, please do (and tell me whether it works or not):

In the upper right, there's the Bluetooth-logo. Tapping that, you can do a "secure"-type connection to your wheel (According to Tillman, this should work with Gotways). If that doesn't work, you can try "Connect a device - Insecure" -option (found under the menu to the right of the Bluetooth-logo, it's the image with three blocks on top of each other).

On the left upper corner, latest received voltage/current/temperature/speed -etc. values are shown (+ Power calculated simply by  voltage * current). Unlike the Gotway-app, I'm not reversing negative values here, so if you ride "backwards" (from the motor/mainboard perspective), you will see negative current & speed.

Next to the view is the graph-view, that shows 500 latest samples plotted on a graph. There are a couple of options below it, namely, is the graph updating enabled ("Update graph"-checkbox), should it jump to the end when new data arrives ("Scroll to end on data") and a button to clear the graph. You can pinch zoom and scroll around the graph (that's why there're the options for update & jump to end, it's kinda hard to zoom and scroll the graph if it keeps jumping to the end or the data you're looking for disappears because the samples are over 500 rounds old ). 

Below it, is a drop-down menu which you can use to select which value to graph. The graphing only use incoming data, so it will clear and start graphing from current incoming data, you won't see the previous values (yeah, yeah, we'll do that for the "real" app).

On the middle/lower left is the log view. Completely unnecessary for now

On the middle/lower right is another log view. Completely unnecessary also. 

Near the bottom you see and edit box (next to the send-button) and record button. If you write something to the edit box and click send, it will be sent to the wheel (like Gotway's mode changes and such). Record will begin recording the incoming data, and tapped again, stop recording and ask you where to save the data. For now, it's rendered half-useless as the log file contains debug-crap & bluetooth raw-data I needed from Tillman to figure out the protocol  

Btw, the Gotway commands are as follows, I captured these by connecting the app to a custom-server and outputting what the app sends:

Tapping the loudspeaker icon apparently makes the wheel beep, also there's Ring five seconds under the menu, which sends 'b's to the wheel for 5 seconds:
b

Madden mode:
h   
b

Comfort mode:
f
b

Soft mode:
s
b

View current (I don't know if the wheel needs this, the data captures I've had so far always have contained the current-information):
m

Turn off level 1 alarm:
u
b

Turn off level 2 alarm:
i
b

Turn on speed alarm:
o
b

 

Calibrate (the first character's a comma, it might be that only the first c y -pair is needed, or maybe all of them...):
,
c
y
c
y
c
y

There's still 'n' -command in the code, but I don't know what it does, it looks like it could be continuously send to the wheel at some point, but I haven't figured out the logic which does it at least yet.

 

 Here's the link to the app, it's unsigned debug-build, so I have no idea if you need to have developer-mode enabled or not.

http://ezbe.underkround.fi/Application-debug-gotway.apk

 

Edited August 28, 2015 by esaj

[Tilmann]

Flamethrower! Yeahhh!!!  Thank you Esa 

[esaj]

Flamethrower! Yeahhh!!!  Thank you Esa 

No, thank you     If you hadn't recorded the logs for me, I'd still be scratching my head with the decompiled Gotway-app, which makes the protocol look much more complex.

If anyone's interested, in a nutshell, they read the binary data out, then mangle it into a string as hex values (like "A0 FF 18 AA"), at some point they change the charset of the string to chinese, then in yet another part of the program, they remove the spaces (to get "A0FF18AA"), then later on parse them with Integer.parseInt using 16-base (hex) -values and copious amounts of substringing, throw them through a couple of arrays, until finally they use a very suspicious looking (could be the reason why the app doesn't work with all locales) DecimalFormat, and even then they still fix the string by "hand" (looking for the dot and then substringing)... The whole app is full of these kinds of brain farts, at times I've suspected if they knew themselves what they were doing. The garbage collector is probably screaming its head off in the background, when all they needed was a couple of binary operations, literally one line of code for each type of value (signed 16bit int and 32bit int in this case), and they could read the values just directly from the bytestream... of course the decimal formatting is still then needed, but even that was done wrong (at least from my point of view).

 

Edited August 16, 2015 by esaj

[Tilmann]

 Here's the link to the app, it's unsigned debug-build, so I have no idea if you need to have developer-mode enabled or not.

http://ezbe.underkround.fi/Application-debug-gotway.apk

 

Hi @esaj, between my first and second shot of coffee, I did a quick indoor check: your app displays very plausible values with my GW18!! I'take it out for a ride later...

BTW: just installed and checked your app also on a Lenovo tablet running android 4.4.2 without developer options. When in "Settings", look at the "Security" section for "Allow apps from unknown sources": this needs to be activated.

Interesting detail: I have seen a debate elsewhere, which side is front and which is back on the GW18. I just followed the example given by my distributer on the demo ride and use it with the power button in front, which puts the pointy side of the pedals forward. As I don't do really steep turns, that didn't bother me (yet). Using your app, speed and power show negative values in this orientation. I guess that reveals, that Gotway meant the wheel to be used with the power button on the rear side?

Edited August 16, 2015 by Tilmann
Added the "detail" observation

[Gimlet]

I've given up on the Gotway and KingSong apps for general use as holding my phone continually is just inconvenient.

I tried linking runtastic to my pebble but the information was not configurable and speed wasn't shown but Endomondo works well and shows speed and distance whilst the phone is recording all the other info including your track. Unfortunately it lacks the coloured track of Runtastic where you can show things like gradient and speed on each section but it's the best I can find that works with pebble.

[Tilmann]

I've given up on the Gotway and KingSong apps for general use as holding my phone continually is just inconvenient.

I tried linking runtastic to my pebble but the information was not configurable and speed wasn't shown but Endomondo works well and shows speed and distance whilst the phone is recording all the other info including your track. Unfortunately it lacks the coloured track of Runtastic where you can show things like gradient and speed on each section but it's the best I can find that works with pebble.

Hi @Gimlet, I like http://www.pebblebike.com/ for it's simplicity and ability to export the tracks. Yet none of the GPS-based speed displays is anywhere fast and accurate enough to serve as a substitute for real time speed (and power) data coming from the wheel. That's why I'm so excited about @esaj's hack of the GW protocol. Eventually, that will open the door to a really usable EUC dashboard 

[esaj]

Hi @esaj, between my first and second shot of coffee, I did a quick indoor check: your app displays very plausible values with my GW18!! I'take it out for a ride later...

Did you have the time today to go out for a ride and see if the numbers look plausible in real situation?

BTW: just installed and checked your app also on a Lenovo tablet running android 4.4.2 without developer options. When in "Settings", look at the "Security" section for "Allow apps from unknown sources": this needs to be activated.

Ok, I guess then that the developer-mode is needed for debugging and such only.

Interesting detail: I have seen a debate elsewhere, which side is front and which is back on the GW18. I just followed the example given by my distributer on the demo ride and use it with the power button in front, which puts the pointy side of the pedals forward. As I don't do really steep turns, that didn't bother me (yet). Using your app, speed and power show negative values in this orientation. I guess that reveals, that Gotway meant the wheel to be used with the power button on the rear side?

Could be, I'm just showing the numbers the wheel sends to the app as they are, no sign reversing