Wheelemetrics: Custom Gotway/King Song -app

[esaj]

14 hours ago, ChernJie Lim said:

@esaj I created a simple drag-and-drop visualizer on Github pages using Google Chart's Annotated Timeline: 

To use it, go to http://chernjie.github.io/Wheelemetrics/ and drop the record.csv anywhere within the browser window. The chart will be generated in a few seconds.

Let me know what you think!

Looks really nice, much handier than building the graph in LibreOffice/Excel   And seems really fast, I dropped my longest (484kB) log there, and the chart generated in less than two seconds...

I needed to change to https (vs. http) on the link, otherwise I got 404 (page not found).

Is there a way to zoom in on the graph? I couldn't figure that out...

[ChernJie Lim]

Yes you should be able to zoom in, there is a timeline bar at the bottom where you can scroll to the time range you want to view

[HEC]

I've not read through the whole thread in detail yet (scheduled for this weekend though) so apologies if this has been already asked / answered here or elsewhere however @esaj - have you considered expanding your app to include support for some other EUCs supporting BT communication? Specifically Solowheel Xtreme in my case? Two currently available apps are very basic (made by customers / enthusiastic rather than Inventist themselves) and I simply love what have you done here. I'd be glad to offer any support / cooperation needed with testing or developing if that would be something you'll interested in / have time for. Thank you.

[sbouju]

Wheelemetrics on a smart watch? It works

 

 

[esaj]

6 hours ago, HEC said:

I've not read through the whole thread in detail yet (scheduled for this weekend though) so apologies if this has been already asked / answered here or elsewhere however @esaj - have you considered expanding your app to include support for some other EUCs supporting BT communication? Specifically Solowheel Xtreme in my case? Two currently available apps are very basic (made by customers / enthusiastic rather than Inventist themselves) and I simply love what have you done here. I'd be glad to offer any support / cooperation needed with testing or developing if that would be something you'll interested in / have time for. Thank you.

There is architecture in place for "autodetecting" the protocol based on data the wheel sends (that's how it distinguishes between old King Songs and Gotways, as there are slight differences in the protocol), but currently it's only made for the Bluetooth SPP (Serial Port Profile), which works pretty differently than newer Bluetooth LE GATT-stuff. It is possible to make it support that too, but as I don't have any wheels or devices that use it, I have nothing to test it against (well, I didn't have a Gotway or KS either at the start when doing that, later on Vee aka EUC Extreme sent me his MCM2s for testing & debugging). The way I got started with Gotway was by disassembling their own app and snooping around how the protocol works, then asking for datacaptures from Gotway and KS owners and working from there. Similar approach could be used with other wheels (including the newer ones using BT LE), but without protocol specification or ready-made app that already uses the protocol to disassemble for "clues", it can be very slow to get it to work.

Right now, my hands are more or less full on other stuff, but anyone's free to grab the source and do whatever they please with it   There are already other people in these forums who have made apps using BT LE (at least for Xima Lhotz and I think someone did some modifications for some KS app that uses their newer BT LE -based protocol?).

6 hours ago, sbouju said:

Wheelemetrics on a smart watch? It works

Nice!  Although the UI doesn't seem to really fit there

[electric_vehicle_lover]

@esaj maybe you could try support the MicroWorks 30B4 board. It is a cheap and great board for 30km/h. Also I hope to develop my firmware for this board.

I am developing the EGG EUC and that uses that board and many components from MicroWorks. It is cheap and simple to make our owns EUC for DIYers and MicroWorks board seems a great option.

I am using Milkway app to control the board.

[esaj]

15 minutes ago, electric_vehicle_lover said:

@esaj maybe you could try support the MicroWorks 30B4 board. It is a cheap and great board for 30km/h. Also I hope to develop my firmware for this board.

I am developing the EGG EUC and that uses that board and many components from MicroWorks. It is cheap and simple to make our owns EUC for DIYers and MicroWorks board seems a great option.

I am using Milkway app to control the board.

If it uses the older BT SPP, then adding support on current Wheelemetrics-version shouldn't require much more than to figure out the protocol and write a decoder -class & hook it up into the autodetection.

[electric_vehicle_lover]

I am pretty sure it uses that old SSP profile.

I just connected on Android and the boards seems to output something constantly...

Do you have an idea how I can record data that flows??

[esaj]

21 minutes ago, electric_vehicle_lover said:

I am pretty sure it uses that old SSP profile.

I just connected on Android and the boards seems to output something constantly...

Do you have an idea how I can record data that flows??

Looks like that could very well be "plain" SPP-data. Android has some built-in capture functionality:  http://stackoverflow.com/questions/23877761/sniffing-logging-your-own-android-bluetooth-traffic

Also there are separate apps for that, I think we used something like Bluetooth SPP Pro in the past : https://play.google.com/store/apps/details?id=mobi.dzs.android.BLE_SPP_PRO&hl=en

But don't remember the specifics, it needs to be set to capture the data as raw binary / hex output or something like that, otherwise it'll replace some character combinations or spew out everything in ASCII (like in your screenshot), that's not very useful.

[HEC]

On ‎27‎/‎05‎/‎2016 at 6:37 PM, esaj said:

Right now, my hands are more or less full on other stuff, but anyone's free to grab the source and do whatever they please with it   There are already other people in these forums who have made apps using BT LE (at least for Xima Lhotz and I think someone did some modifications for some KS app that uses their newer BT LE -based protocol?).

I've read the whole thread now (interesting reading) and indeed I appreciate that this all needs time which none of us have unlimited amount. I'll try to poke around your source code together with looking at two existing Xtreme apps to see what could be done ...

[sbouju]

Any Gotway MSuper2 owners wanting to share their Weelemetrics log files recorded in real and various conditions?

Thanks in advance!

 

wheelemetrics_log_20160709_1+2.txt

wheelemetrics_log_20160710_192050.txt

[hehe2]

Hi, 

Just tried your wheelemetrics app on my Nexus5 on Android 6.

I gotta say I was kinda thrilled to discover this app and happy to see the open source community was active and working on EU Apps. Great Job for all your work. 

 

Now, after my first run,  I'm kinda sad to have to say that... for me it's unusable. Once I connected the wheel (Gotway MSUPER), started the record, turned the phone screen off, put it in my pocket then... huge vibration? whoot? (I had disabled all sounds and vibration warnings).  I unlocked the phone and was disappointed to see the app wasn't recording anymore nor connected to the wheel anymore. I had to keep the phone in my hand to be able to use the app, which is both unhandy and dangerous to say the least... 

So I wonder whether you could make this app work while the phone is locked and the screen turned off, like the car GPS's apps (SpeedView as an example). That would be awesome. 

Regards! 

 

PS : could you reverse the Gotway app riding modes too (maddened, comfort, soft) so that I would only have to use your app for setting everything up ? 

 

 

[esaj]

17 hours ago, hehe2 said:

Now, after my first run,  I'm kinda sad to have to say that... for me it's unusable. Once I connected the wheel (Gotway MSUPER), started the record, turned the phone screen off, put it in my pocket then... huge vibration? whoot? (I had disabled all sounds and vibration warnings).  I unlocked the phone and was disappointed to see the app wasn't recording anymore nor connected to the wheel anymore. I had to keep the phone in my hand to be able to use the app, which is both unhandy and dangerous to say the least... 

So I wonder whether you could make this app work while the phone is locked and the screen turned off, like the car GPS's apps (SpeedView as an example). That would be awesome. 

I'm not a real Android-developer, this was the first time I've written Android-software, so I'm not that familiar with how it behaves in different situations / Android versions etc. The app was originally built for Vee's (EUC Extremes) needs, ie. the phone is on a wrist case and the values are always visible (it prevents the screen from shutting off without pressing anything). Not sure if the Bluetooth-connections can be kept alive when the phone is locked, although I'd expect so?

Also, I don't have a Gotway or a King Song (I had Vee's MCM2s on loan a while during the development to test things), so I cannot test anything with a real wheel

 

17 hours ago, hehe2 said:

PS : could you reverse the Gotway app riding modes too (maddened, comfort, soft) so that I would only have to use your app for setting everything up ? 

There's a rudimentary text-input box & send -button at the bottom of the app, the commands are:

 

 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.

 

The "b"'s the original app sends after each command is just to make the wheel beep to inform the user that the command was received, so they're not necessary to send.

[Andr]

Hi!

I have a chineese controller "30B" that is a copy of early GotWay MCM. It works wit old GotWay app, but Wheelmetrics does not connect to it. Can you propose any solution?

[esaj]

4 minutes ago, Andr said:

Hi!

I have a chineese controller "30B" that is a copy of early GotWay MCM. It works wit old GotWay app, but Wheelmetrics does not connect to it. Can you propose any solution?

If you can, grab me a raw binary data capture of what the mainboard sends over BT (something like a kilobyte should probably suffice to see enough repetitions to figure it out), I can (probably) decipher the protocol differences and write an auto-detection/decoder for it. The original Gotway app uses a bit different way of reading the data, so it's more "lax" when it comes to slight protocol differences. I didn't want to go that route with the Wheelemetrics, to leave open the possibility of adding totally different protocols.

[Andr]

31 minutes ago, esaj said:

If you can, grab me a raw binary data capture of what the mainboard sends over BT (something like a kilobyte should probably suffice to see enough repetitions to figure it out), I can (probably) decipher the protocol differences and write an auto-detection/decoder for it. The original Gotway app uses a bit different way of reading the data, so it's more "lax" when it comes to slight protocol differences. I didn't want to go that route with the Wheelemetrics, to leave open the possibility of adding totally different protocols.

Will it make sense if instead I send you "smali" or "jar" files got by decompiling the app?

[esaj]

Just now, Andr said:

Will it make sense if instead I send you "smali" or "jar" files got by decompiling the app?

That could work too, but deciphering decompiled code is not always very straightforward and may take some time. Plus, as I've got a ton of other projects to do, this isn't exactly a priority to me, so don't hold your breath  

If you've got a link to the app (.apk), I can decompile it from there.

[Andr]

5 minutes ago, esaj said:

That could work too, but deciphering decompiled code is not always very straightforward and may take some time. Plus, as I've got a ton of other projects to do, this isn't exactly a priority to me, so don't hold your breath  

If you've got a link to the app (.apk), I can decompile it from there.

OK, understood

You can find the file here: https://github.com/megadrifter/30B_Airwheel_apk

There is a class "bluetoothchat" there. It has all data transfer and calculations as I understood. 

[sbouju]

On 13/05/2016 at 0:05 PM, ChernJie Lim said:

Yes you should be able to zoom in, there is a timeline bar at the bottom where you can scroll to the time range you want to view

Hi,

Thank you for this very easy way for overviewing the Wheelemetrics logs !

Sorry, but I don't understand how to zoom or dezoom the graphic easily, nor what can do the buttons in the upper left corner of the window... May be the file needs to be very very large ? Or rnot too much...?

 

[Nicolas Kerspern]

Hi SBouju,

on the bottom of the window of http://chernjie.github.io/Wheelemetrics/ , you'll find the horizontal bar and in each end, you have a bubble with a double pipe which you can change the field to zoom ...

 

See you !

 

Nicolas

GW18#Nicolas2K

[sbouju]

Hi Nicolas,

Yes, I have seen that, but I cannot use it on a predictible way. Too slow in a web browser...?

I have to admit that most of the time, I try to handle very big log files: 3 hours or more of non stop recording!

 

wheelemetrics_log_20160814_143951.zip

[Andr]

On 13.07.2016 at 4:12 PM, esaj said:

If you can, grab me a raw binary data capture of what the mainboard sends over BT 

Hi. The mainbooard have two types of "words", 

In the "speed" mode: "584 dV     0 dM/S   1278 m"  - voltage=58.4 , speed, odo. (35 38 34 20 64 56 20 20 20 20 20 30 20 64 4D 2F 53 20 20 20 31 32 37 38 20 6D 0D 0A )

In the "current" mode: "23282 phase_cnt     0 start_times    12 dA    2 PitchAngle" - ?phase count? , current, ?angle? (32 33 32 38 32 20 70 68 61 73 65 5F 63 6E 74 20 20 20 20 20 30 20 73 74 61 72 74 5F 74 69 6D 65 73 20 20 20 20 31 32 20 64 41 20 20 20 20 32 20 50 69 74 63 68 41 6E 67 6C 65 0D 0A )

The question is how and how fast to swich between these modes  to get voltage and current at once.

The other problem is that I use 16" wheel, not 14", and with other pole pairs quantity (but this I can change later in my fork, for example).

"GotWay" app shows also the temperature and the "power" in % - I cannot see those in the payload.

If you point me what files to edit, I can try to make needed "interface driver". Yet I found  ProtocolAutodetectionLogic.java,  new file to do /protocol/resolver/30B.java.

Also I attached the app given by mainboard producer.

0715222223.txt

0715222650.txt

0715222704.txt

WheelBtApps1209.apk

[esaj]

1 hour ago, Andr said:

Hi. The mainbooard have two types of "words", 

In the "speed" mode: "584 dV     0 dM/S   1278 m"  - voltage=58.4 , speed, odo. (35 38 34 20 64 56 20 20 20 20 20 30 20 64 4D 2F 53 20 20 20 31 32 37 38 20 6D 0D 0A )

In the "current" mode: "23282 phase_cnt     0 start_times    12 dA    2 PitchAngle" - ?phase count? , current, ?angle? (32 33 32 38 32 20 70 68 61 73 65 5F 63 6E 74 20 20 20 20 20 30 20 73 74 61 72 74 5F 74 69 6D 65 73 20 20 20 20 31 32 20 64 41 20 20 20 20 32 20 50 69 74 63 68 41 6E 67 6C 65 0D 0A )

That's weird, it looks like it's plain text ascii-data. I thought this was a Microworks 30B-board? Are you sure this is what the board sends?

 

Quote

The question is how and how fast to swich between these modes  to get voltage and current at once.

The other problem is that I use 16" wheel, not 14", and with other pole pairs quantity (but this I can change later in my fork, for example).

"GotWay" app shows also the temperature and the "power" in % - I cannot see those in the payload.

At least the older Gotway app I decompiled only read binary data, so not sure how it can even work with the data you showed.

 

Quote

If you point me what files to edit, I can try to make needed "interface driver". Yet I found  ProtocolAutodetectionLogic.java,  new file to do /protocol/resolver/30B.java.

In addition to the resolver, you need to write a codec for the data, then add the resolver to the resolvers-array in ProtocolAutodetectionLogic. I don't know if Android supports reflection, if so, it would be possible to just scan through the available implementations and pick them up automatically without needing to add them to the array... But that's besides the point, the todo-list is:

-Create a codec implementing the com.github.esaj.wheelemetrics.protocol.codec.ProtocolCodec -interface
-Create a resolver implementing the com.github.esaj.wheelemetrics.protocol.resolver.ProtocolResolver -interface
-Add an instance of your ProtocolResolver-implementation class into resolvers -array in com.github.esaj.wheelemetrics.protocol.ProtocolAutodetectionLogic

After the wheel connects, the ProtocolAutodetectionLogic will call each ProtocolResolver-implementation until it finds a perfect match (resolver returning 1.0 -match, ie. 100%). If no "perfect" match is found, it will return the codec given by highest matching resolver (but if the protocol isn't close enough to that, it still might not work ). The idea was to leave it open to add more resolvers/codecs, and make it possible for a partially matching codec to at least try to parse the data.

I can do these myself too, but it might take a while (especially without the wheel ).

Quote

Also I attached the app given by mainboard producer.

I'll take a look at that once I got some time, I'm currently at work.

 

[Andr]

2 hours ago, esaj said:

That's weird, it looks like it's plain text ascii-data. I thought this was a Microworks 30B-board? Are you sure this is what the board sends?

This is what the app "Bluetooth spp pro" recorded. Yes, this is Microworks 30B. Looking inside their bt-app I see them using data parsed only from the "voltage" data. (see CDecodePacket.java )

BUT: I use GotWay app version 3.4.51 (with little changes) and it works.
I could only find the file BluetoothChat.java there. On the linr 391 they use "if(check_55AA55AA) {" condition and then utilize variables ch1 -- ch6 to get data. But I could not find those variables anywhere else.

Good thing is that sending the message "m" seems to change to "current" mode and "n" to "speed".

[esaj]

3 minutes ago, Andr said:

This is what the app "Bluetooth spp pro" recorded. Yes, this is Microworks 30B. Looking inside their bt-app I see them using data parsed only from the "voltage" data. (see CDecodePacket.java )

Then the problem might be that Bluetooth SPP Pro only captures text data and discards non-printable characters, which makes the captures unfortunately fairly useless. I think we ran into similar problems before when people were getting the Gotway and King Song data captures for me (I don't have either wheel myself nor access to any), don't remember which software we finally got the working captures with. Probably there's some settings in the app...

 

3 minutes ago, Andr said:

BUT: I use GotWay app version 3.4.51 (with little changes) and it works.
I could only find the file BluetoothChat.java there. On the linr 391 they use "if(check_55AA55AA) {" condition and then utilize variables ch1 -- ch6 to get data. But I could not find those variables anywhere else.

The 55AA55AA-thingamabob is the binary datapacket header. If the wheel works with the Gotway-app, there must be data coming in with binary format... One thing that came to me to try might be modifying the GotwayProtocolCodec and trying to drop the first 0x04-byte from the MSG_TAG -header array.