Jump to content

Wheelemetrics: Custom Gotway/King Song -app


esaj

Recommended Posts

@Sam Clegg: I published the project in Github, although I'm still working on refactoring & cleaning up code, but as that might take a while, thought I wouldn't keep you waiting. It's not the cleanest code by a long shot... :D

https://github.com/esaj/Wheelemetrics

It was originally meant to go to another repository, but the Android Studio Github-integration pushed it under my account, and then just thought fuck it, and refactored the package names to match that ;)

Edit: Also there isn't any documentation yet (except for some Javadoc in the code, but even most classes aren't documented there yet).

Link to comment
Share on other sites

  • Replies 146
  • Created
  • Last Reply

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. 

I meant just going into the Android phone's Settings>Bluetooth and trying to pair it.  I believe the 800w uses some "new bluetooth" but I am not certain.  I see the KS14 800w in the bluetooth device list but when I try to pair it it would time out and say unable to connect.  Since I cannot get it to connect, no I can't get it to work with Gotway App or the older KS app.

Link to comment
Share on other sites

@esaj, I guess we need the new KS App to give you BT packet captures that will serve a purpose?   

If it's Bluetooth LE, the captures need to be done "both ways" (ie. what the phone is sending to the wheel and what the wheel is sending to the phone).

Wheels using "classic" Bluetooth are simple in the sense that the wheel will just start transmitting data once the phone/other device connects to it, nothing else is needed to start receiving. With Bluetooth LE, the phone must query what values ("handles" or whatever they were called) the device is advertising, and then subscribe/send read commands to them to get the data (well, this is the basic idea, there's all sorts of nuts and bolts to go with it). I think (but am not sure) that the Android HCI Snoop mode (requires developer mode enabled) can capture the data both ways, and then Wireshark can be used to analyze it (as it will likely contain all the Bluetooth frame-data and other bits and pieces that aren't the actual wheel data).

@Kevin already did Bluetooth LE captures with the IPS Xima Lhotz, but I think he used just a Bluetooth LE -dongle on his computer with Wireshark & the BTLE -plugin? Guess it can eavesdrop somehow or route the phone app data for that? Never asked further...

I have a BLE sniffer that I've used to capture some packets going between a IPS XIMA LHOTZ wheel and my iPhone. 

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

If the new KS app isn't obfuscated, that will help a lot with reverse-engineering. The longest taking part is probably just building the Bluetooth LE-parts to the app for the communication-"infrastructure" and define some new interfaces for protocols that use LE. Unless the app IS obfuscated, in which case it'll take a lot longer while to guess what all the data means  ;)

 

Link to comment
Share on other sites

 

If it's Bluetooth LE, the captures need to be done "both ways" (ie. what the phone is sending to the wheel and what the wheel is sending to the phone).

Wheels using "classic" Bluetooth are simple in the sense that the wheel will just start transmitting data once the phone/other device connects to it, nothing else is needed to start receiving. With Bluetooth LE, the phone must query what values ("handles" or whatever they were called) the device is advertising, and then subscribe/send read commands to them to get the data (well, this is the basic idea, there's all sorts of nuts and bolts to go with it). I think (but am not sure) that the Android HCI Snoop mode (requires developer mode enabled) can capture the data both ways, and then Wireshark can be used to analyze it (as it will likely contain all the Bluetooth frame-data and other bits and pieces that aren't the actual wheel data).

@Kevin already did Bluetooth LE captures with the IPS Xima Lhotz, but I think he used just a Bluetooth LE -dongle on his computer with Wireshark & the BTLE -plugin? Guess it can eavesdrop somehow or route the phone app data for that? Never asked further...

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

If the new KS app isn't obfuscated, that will help a lot with reverse-engineering. The longest taking part is probably just building the Bluetooth LE-parts to the app for the communication-"infrastructure" and define some new interfaces for protocols that use LE. Unless the app IS obfuscated, in which case it'll take a lot longer while to guess what all the data means  ;)

@esaj,  I've got captures from the Ninebot One if you want to add that to your app.  I may try modifying your app but I know you could do it faster since you know your code and everything.  I got your source.  Thanks for releasing that.  I guess later today I will see if I can get it to compile and then go from there.

As far as the 9B1 goes the app sends a request for the Dashboard screen and the 9B1 sends all of the data for that screen or it sends a request for the Detail Info screen and the 9B1 sends all of the data for that screen.

So @Jason McNeil needs to find an Android 4.4 phone and enable Developer Options (if there are no repercussions (I hadn't heard of the ones that you mentioned. I always have it enabled on my phones.)).  It works great at capturing everything.

Link to comment
Share on other sites

@esaj,  I've got captures from the Ninebot One if you want to add that to your app.  I may try modifying your app but I know you could do it faster since you know your code and everything.  I got your source.  Thanks for releasing that.  I guess later today I will see if I can get it to compile and then go from there.

As far as the 9B1 goes the app sends a request for the Dashboard screen and the 9B1 sends all of the data for that screen or it sends a request for the Detail Info screen and the 9B1 sends all of the data for that screen.

So @Jason McNeil needs to find an Android 4.4 phone and enable Developer Options (if there are no repercussions (I hadn't heard of the ones that you mentioned. I always have it enabled on my phones.)).  It works great at capturing everything.

The Ninebot-data would be nice :) Not sure when I have the time to go over it, though

As for getting the project to work, I wasn't sure which project-files should be included, so I left most out, also people might like to use some other environment, so those would be just clutter. I just tested how to get the project to work, and although I'm not sure if this is the "correct" way of doing things, this seemed to work (in Android Studio 1.3):

-Create a new project via File -> New -> New project...
-Give it a name, company domain and location, click Next
-I left the Target Android devices to Phone & tablet, minimum SDK API 15
-Add no activity -> Finish

After the project is set up, close Android Studio (if I didn't close it & just copied stuff over, it would start complaining about missing MainActivity when running), then copy the app -directory from the repo over the app -directory of the project, overwriting everything conflicting. Finally delete \app\src\main\res\values\styles.xml. After this, restart Android Studio, and the project seems to build & run ok.

 

Link to comment
Share on other sites

Thanks for letting me know about Android Studio.  I have been using Eclipse (a while back).  I am installing Android Studio now.

 

I use Eclipse (well, three Eclipses ;)) for my work-projects, and thought about using it for this too, but seeing that Android Studio is spefically developed to make Android-development easier, it seemed the right way to go. Although it's a pain at the start, having accustomed to all the nifty keyshortcuts of Eclipse, and Android Studio is based on IntelliJ Idea... There's a setting somewhere there (don't remember where exactly anymore) to get more Eclipse-like keys, but it's still not the same.

Let me know if you get the project running with the above instructions, not 100% sure if they work outside my own computer...

Link to comment
Share on other sites

Whoooohoooo :lol:

After one day of clueless clicking, I got my build environment running and it compiles Wheelemetrics Proto like a charm :wub:. And while the pro's are scratching their heads ("so?"), that's a major achievement for a total noob like me. Haven't done any software dev in earnest for 30 years and never came closer to an SDK other than the arduino IDE which had been invented specifically to reward IT ignorants with quick successes.

What's next? While many wheelies here are excited about the prospect to make @esaj's marvel compatible with each and every EUC on the market that can radiate some Bluetooth, I'm obsessed with the idea to bring speed/power readouts and alarms on to something wearable. Through some bargain hunting, I assembled this collection of devices:

  • An original Pebble Watch (first black&white plastic model),
  • a Moto 360 (android Wear smartwatch),
  • and a Recon Jet (data glasses running on some android spin off).

Now I'm set for long and cold winter nights to come. Don't hold your breath for anything worth trying out - I see a long learning curve ahead of me and in my case, it won't be remarkably steep...

Thanks again Esa for your fantastic ground work and for publishing your sources!

Link to comment
Share on other sites

Whoooohoooo :lol:

After one day of clueless clicking, I got my build environment running and it compiles Wheelemetrics Proto like a charm :wub:. And while the pro's are scratching their heads ("so?"), that's a major achievement for a total noob like me. Haven't done any software dev in earnest for 30 years and never came closer to an SDK other than the arduino IDE which had been invented specifically to reward IT ignorants with quick successes.

What's next? While many wheelies here are excited about the prospect to make @esaj's marvel compatible with each and every EUC on the market that can radiate some Bluetooth, I'm obsessed with the idea to bring speed/power readouts and alarms on to something wearable. Through some bargain hunting, I assembled this collection of devices:

  • An original Pebble Watch (first black&white plastic model),
  • a Moto 360 (android Wear smartwatch),
  • and a Recon Jet (data glasses running on some android spin off).

Now I'm set for long and cold winter nights to come. Don't hold your breath for anything worth trying out - I see a long learning curve ahead of me and in my case, it won't be remarkably steep...

Thanks again Esa for your fantastic ground work and for publishing your sources!

You'll get there, Java is fairly easy language in the end, although it has it's quirks, and the Android as a platform isn't *that* hard to tackle. The code is pretty messy at a lot of points, and has some half-finished ideas, I'll try to get around to clean it up more properly over some time and rewrite some parts to make them better. Also I'll get some 10000-feet view documentation done, to make more sense of how things move around and what the different parts do (or should do, until I just put some evil haxx there to get on with it ;P). Not exactly the code quality I require from myself at work ;)

Link to comment
Share on other sites

Just confirming here that yes, my KS 500W works with esaj's wheelmetrics.  I've run a little stress test alongside some gps data from runtastic on my other phone, so we can look at gradients too. (yes, I started and stopped both at the same time)  Anyone have advice on how to interpret and graph the data wheelmetrics provides in the txt file?

Oh and the runtastic graph is imperial for some reason even though I have metric set in preferences, sorry!

chart.jpeg

wheelemetrics_log_20150918_195043[1].txt

Link to comment
Share on other sites

One thing I have noticed right off the bat, which I haven't logged yet but observed in real-time: the wattage peaks are dramatically larger when dealing with hills vs flat out high speeds.  Going well under 20kph (I'm guessing around 12-15kph) up a moderate incline, I was seeing 1300-1400W spikes all over the place.  But high speeds around 22-24kph on flat ground, it was staying around 400-600W.  I weigh 70kg for what it's worth.  I will try to log a good example of this in the coming days. 

Link to comment
Share on other sites

Anyone have advice on how to interpret and graph the data wheelmetrics provides in the txt file?

I don't think that's the right file, it looks like you've gone back and forth in it slowly (moving the wheel back and forth by hand?), and moved 7 meters in about 31 seconds total? ;)

Graphing can be done with Excel or LibreOffice for example, but at least with LibreOffice it takes some practice (but after that, it's pretty fast to do graphs from it).

One thing I have noticed right off the bat, which I haven't logged yet but observed in real-time: the wattage peaks are dramatically larger when dealing with hills vs flat out high speeds.  Going well under 20kph (I'm guessing around 12-15kph) up a moderate incline, I was seeing 1300-1400W spikes all over the place.  But high speeds around 22-24kph on flat ground, it was staying around 400-600W.  I weigh 70kg for what it's worth.  I will try to log a good example of this in the coming days. 

Climbing requires a lot more power, also wind resistance can be a big factor even when riding in flat. I got a bit over 2500W peaks out of vee's MCM2s in a short and steep (25 degree) gravel hill. Taking a longer route recordings with lots of high peaks both in power use and regenerative braking (+-2kW), the average power over the entire trips was still only around 270-280W.

 

 

Link to comment
Share on other sites

 

@Kevin already did Bluetooth LE captures with the IPS Xima Lhotz, but I think he used just a Bluetooth LE -dongle on his computer with Wireshark & the BTLE -plugin? Guess it can eavesdrop somehow or route the phone app data for that? Never asked further...

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

 

This is what I used:

https://www.adafruit.com/products/2269

It seems kind of finnicky (often gets lost when the app connects to the wheel, so I have to disconnect and reconnect the app multiple times until it 'catches' the connection).

It starts in the command line to select which device you want to sniff, then launches into Wireshark where the actual packet capture happens. It automatically installs protocol analyzers for BLE/GATT so the raw packets are parsed nicely for you in wireshark.

Link to comment
Share on other sites

  • esaj changed the title to Custom Gotway/King Song -app

You'll get there, Java is fairly easy language in the end, although it has it's quirks, and the Android as a platform isn't *that* hard to tackle. The code is pretty messy at a lot of points, and has some half-finished ideas, I'll try to get around to clean it up more properly over some time and rewrite some parts to make them better. Also I'll get some 10000-feet view documentation done, to make more sense of how things move around and what the different parts do (or should do, until I just put some evil haxx there to get on with it ;P). Not exactly the code quality I require from myself at work 

Hi @esaj, if you considered your beautiful source code "messy", I turned it into a brutal massacre:

Here's a first snapshot of my attempts to marry Wheelemetrics with my Pebble...

Link to comment
Share on other sites

Hi @esaj, if you considered your beautiful source code "messy", I turned it into a brutal massacre:

Here's a first snapshot of my attempts to marry Wheelemetrics with my Pebble...

That's great job! Was it hard to get the app to work with Pebble? Haven't ever checked how the communication between a phone/tablet and Pebble works (and I don't have a Pebble Watch either). @Gimlet would probably be interested in testing that... ;)  I could look into integrating it with the original master-branch, once you feel it's more "ready".

I didn't get any work done on the app this week, had some flu and didn't feel like working on it on top of my usual coding job, plus I still got the Firewheel in pieces (didn't get pretty much anything done today :P). Current todo-list for the app contains:

-Cleaning up the source more in general
-Using a more concise way of messaging within the application, instead of using both "normal" and broadcast intents, just one way of doing things for "publish-subscribe"-type of things (I think this should be possible so that the publishing-side doesn't need to know about the end-points, that was kind of the plan with the broadcasts, but didn't get them to work like I wanted, have to read up on it a bit)
-The warning audio-files should be checked for any unnecessary silence in the beginning, so there's minimal delay between warning triggering & the audio starting to play for situations where the user sets the warning just below cut-off, even very small timeframes count ;)  ("The average reaction time for humans is 0.25 seconds to a visual stimulus, 0.17 for an audio stimulus, and 0.15 seconds for a touch stimulus.")
 

In the longer run:

-Add adjustable warnings for low & high voltage, overpower and/or overcurrent
-Separate messages (intents?) for speed-warning, voltage-warning, overpower/overcurrent-warning, so other components can select which they listen to
-Add some options-menu (like "always show positive speed" should be user selectable, number of samples the graph-view shows before it begins to "forget" them)
-X latest samples should be stored, so changing the graph wouldn't clear everything, but you could check on other values even afterwards
-Better documentation about the code (maybe in Github-wiki)
-Wiki-page/project front page with usage instructions & download link (btw, the server hosting my current web-space will go down permanently sometime next year)
-Maybe option for selecting the audio-alerts would be a nice to have feature too...

In even longer run:

-Bluetooth LE-support
-Video overlay of speed/power etc...

I try to get back on track on finishing things, but won't make any promises. Also the UI needs a lot of tweaking, but that might be above my design-skills, probably the UI layout needs to be separately designed for different resolutions/aspect ratios to make it "work" better. For instance, that 5th button ("Pebble watch") wouldn't show up at all on phones like Vee's Huawei, because it won't fit into the screen.

 

Link to comment
Share on other sites

That's great job! Was it hard to get the app to work with Pebble? Haven't ever checked how the communication between a phone/tablet and Pebble works (and I don't have a Pebble Watch either). @Gimlet would probably be interested in testing that... ;)  I could look into integrating it with the original master-branch, once you feel it's more "ready".

I didn't get any work done on the app this week, had some flu and didn't feel like working on it on top of my usual coding job, plus I still got the Firewheel in pieces (didn't get pretty much anything done today :P). Current todo-list for the app contains: ....

Thanks for the flowers, but I have to earn'em yet. Like, I have no idea, how the communication to the watch actually works - the Pebble companion app on the phone takes care of that. I also didn't write a line of code in C yet. Instead, Pebble surprised me with a pre-installed "Sport" (and "Golf") app that's already installed in the watch without any hint in the menus. All it takes is making "Pebblekit" part of your android project and calling a few methods as described here: http://developer.getpebble.com/tutorials/android-tutorial/part1/

But: the price for this convenience is a dreadful lack of customization options (or I didn't find it). Other than choices of metric vs. imperial and speed vs. pace there is hardly anything changeable. When the trip counters are activated (time and distance) that's likely the upper limit of improvements using "Sport".

That's a pity, as the tiny watch features a respectable vibration alarm which I would love to use. And of course I would like options to display any telemetry values like voltage or power...

We'll see, how far my clicking exercises will get me :wacko:

Link to comment
Share on other sites

@esaj: inspired by the frequent discussions about the physical limits of our EUCs and the common uncertainties in the description of the event by face-plant victims ("did it cut off???"), I got another feature request to add to the wish list:

  • "Accident Recorder" function as a default setting. So, when you use the Wheelemetrics app it automatically records all data from, say, your last 3 days. It also automatically erases older recordings. In case of any incident you like to analyze, there's an easy option to preserve and share that recording, like sending the data by email. For people more concerned with their privacy, there should be a config option to disable auto recording.
Link to comment
Share on other sites

Wow, this is cool.

Makes logging the wheel's data easy without the need to tap into the circuitry.

Would it be a lot of work to add the phone's GPS data to the logfile?

This way one could correlate the motor data to the terrain and get a better understanding of the wheel/batteries capabilities, enhance the accident recorder and make awesome videos using  Dashware .

Link to comment
Share on other sites

@Tilmann Nice! Didn't realize you'd gotten a Recon Jet. I've been looking for something like that to use with my Xima wheel/app. Did you buy it at the full retail price or were you able to find it for cheaper somewhere?

Spent a few weeks hiding in the bushes, then sniped the first one under 500 Euro I could find on ebay (http://www.ebay.de/itm/161787425164). :ph34r:

Still working on my first impression though. Psychologically, I underestimated the impact on casual observers. As soon as I wear this mixture from space age and 80's design quirk, there's no more smiles and thumbs up's. While I thought, I look ridiculously funny like a Gizmoduck-impersonation, people on the sidewalks actually seem to be scared when I approach them in this outfit. On the positive side: they are much more willing to clear my way...  Perhaps the model with black frame will not provoke such strong reactions. Tinting on the standard glasses is pretty dark. Clear glasses are listed as on option, but I don't know price or availability.

Technically, it's a "first generation" product and it shows. The concept is great and indeed, I can pick up essential information from the screen without much distraction or reduction of my field of view.

What's rather poor: Screen resolution, operating speed, battery life, quality of the apps and GPS functionality. Haven't tried anything with the SDK yet.

If there is anything in particular you want more details about, please let me know.

Link to comment
Share on other sites

Spent a few weeks hiding in the bushes, then sniped the first one under 500 Euro I could find on ebay (http://www.ebay.de/itm/161787425164). :ph34r:

Still working on my first impression though. Psychologically, I underestimated the impact on casual observers. As soon as I wear this mixture from space age and 80's design quirk, there's no more smiles and thumbs up's. While I thought, I look ridiculously funny like a Gizmoduck-impersonation, people on the sidewalks actually seem to be scared when I approach them in this outfit. On the positive side: they are much more willing to clear my way...  Perhaps the model with black frame will not provoke such strong reactions. Tinting on the standard glasses is pretty dark. Clear glasses are listed as on option, but I don't know price or availability.

Technically, it's a "first generation" product and it shows. The concept is great and indeed, I can pick up essential information from the screen without much distraction or reduction of my field of view.

What's rather poor: Screen resolution, operating speed, battery life, quality of the apps and GPS functionality. Haven't tried anything with the SDK yet.

If there is anything in particular you want more details about, please let me know.

That's actually pretty interesting. I never even considered if it would intimidate people, but then I guess you kind of look like Robocop in that profile picture :P And I think it's understandable, high-tech 'gear' is sort of associated with law enforcement and/or military.

What kind of battery life does it get? Does it take any adjustment to make the HUD easily readable?

Link to comment
Share on other sites

That's actually pretty interesting. I never even considered if it would intimidate people, but then I guess you kind of look like Robocop in that profile picture :P And I think it's understandable, high-tech 'gear' is sort of associated with law enforcement and/or military.

What kind of battery life does it get? Does it take any adjustment to make the HUD easily readable?

Due to the "Robocop" effect, I didn't do much real life testing so far. The manufacturer states battery life is about 2 hours. The battery is changeable, but that requires a shut down and restart, which is time consuming (several minutes). What concerns me: @esaj looked briefly into the SDK documentation and found the recommendation to app developers to restrict the screen update rate of their software to max. 1 fps to preserve that 2h battery lifespan. My main motivation for using a HUD is to know exactly how fast I'm going when riding fast on my Msuper. 1 fps at 36 km/h means just one display update every 10 meters. BTW, the built in GPS feels extremely slow, too. When I brake to as stop from about 20 km/h, I see the speed figure counting down in steps of 3 km/h every second while already standing still. It takes about 7 seconds until the display shows 0 km/h.

The flimsy adjustment lever below the display takes a bit getting used to, but I find it very acceptable after that.

In terms of readability of the display, I'm a bad reference tester since needing reading glasses for screen work. The Jet requires to refocus the eye to "near" to read the screen and I can't find a setting to get a sharp display edge to edge. Reading one prominent figure like speed in the center of the screen is effortless, adding some power and voltage info seems possible for me - perhaps in a bar graph format. The build in navigation app is very primitive and reading street names is mostly impossible for me.

Ohhh, and in case there's room for misunderstanding: there is no chance to just run your regular smartphone android app on the Jet! My idea was to use the SDK and Esa's Wheelemetrics app to develop a little display app for the Jet. Given the low performance of the device, porting the essentials from the Wheelmetrics to run authonomously on the Jet may not be possible (i.e. the Jet's bluetooth connects directly to the EUC, decodes the data stream and displays the values). I would rather try to keep Wheelemetrics running on the smartphone and do the decoding and the send the pure figures to display to the Jet (similar to the approach I took with the Pebble watch). Since the "Robocop" effect lowered my enthusiasm for the Jet somewhat, I'm not sure anymore it's worth investing the time into that solution. Imporving the Pebble integration and looking into android Wear is higher on my list.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...