Wheelemetrics: Custom Gotway/King Song -app

[Kevin]

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.

2 hours... I guess that is roughly how long a EUC lasts at faster speeds? Might not be too big a problem. The 1fps is though - as you mentioned I want very frequent speed updates, and even the official app for my wheel refreshing at 2fps is too slow for me. Do you know if it's possible to go faster than 1fps if desired?

"there is no chance to just run your regular smartphone android app on the Jet" - because the sdk does not allow it, or because it is not powerful enough? I was sort of thinking of doing as you said with doing all processing on the smartphone first, I think this is also how Apple Watch works (until recently anyway).

Anyway this is pretty interesting, I might have to look into getting a Pebble too instead... how is the responsiveness of the UI on Pebble?

[Tilmann]

2 hours... I guess that is roughly how long a EUC lasts at faster speeds? Might not be too big a problem. The 1fps is though - as you mentioned I want very frequent speed updates, and even the official app for my wheel refreshing at 2fps is too slow for me. Do you know if it's possible to go faster than 1fps if desired?

"there is no chance to just run your regular smartphone android app on the Jet" - because the sdk does not allow it, or because it is not powerful enough? I was sort of thinking of doing as you said with doing all processing on the smartphone first, I think this is also how Apple Watch works (until recently anyway).

Anyway this is pretty interesting, I might have to look into getting a Pebble too instead... how is the responsiveness of the UI on Pebble?

The OS on the Recon Jet is "android based", but it's not your standard android with access to all sorts of apps from google play, etc. Any app supposed to run on the Jet needs to be adapted to its unique behavior (and resource limitations, I suppose) and specifically compiled for it. I assume, you can use the standard tools for that (like android studio or eclipse for the Java programming) plus some additional classes provided by Recon. To do that, you need access to the source code of any app you want to bring to the Jet (either to port it completely as a stand-alone Jet app or to send the display info to the Jet). @esaj's Wheelemetrics is the only EUC app I know, for which source code is readily available. It has been built without manufacturer support by "reverse engineering", i.e. Esa figured out the protocol between EUC and app by wiretapping the bluetooth traffic (and I'm eternally grateful for this brilliant skunk works exercise ). As is, it works with Gotway and KingSong EUCs and Esa considers it a prototype (so, don't expect the quality and reliability of a commercial app). Whether that protocol analysis can/will be repeated for the IPS/Xima protocol I can't say. Whether the manufacturer is interested in cooperating and opens its sources, I can't say either.

Using the Pebble looks much more promising to me. The "classic" model can be found at about 100 Eu in many stores and you can pick up used ones at 60 Euro on ebay. Battery life is ONE WEEK with a "constantly on" display! I find the screen update rate very sufficient. You can make your own judgement from my little demo video (https://youtu.be/h_b7er_8lQM - about 2:00 minutes in). The solution should work on all Pebble watch models.

 

EDIT: as an afterthought, the 2 fps limitation @Kevin observed with the official XIMA app may actually come from the EUC's transmit rate. If the wheel sends only 2 updates per second, that will be the bottleneck and any app on the receiving side has to live with that, sorry.

[Kevin]

The OS on the Recon Jet is "android based", but it's not your standard android with access to all sorts of apps from google play, etc. Any app supposed to run on the Jet needs to be adapted to its unique behavior (and resource limitations, I suppose) and specifically compiled for it. I assume, you can use the standard tools for that (like android studio or eclipse for the Java programming) plus some additional classes provided by Recon. To do that, you need access to the source code of any app you want to bring to the Jet (either to port it completely as a stand-alone Jet app or to send the display info to the Jet). @esaj's Wheelemetrics is the only EUC app I know, for which source code is readily available. It has been built without manufacturer support by "reverse engineering", i.e. Esa figured out the protocol between EUC and app by wiretapping the bluetooth traffic (and I'm eternally grateful for this brilliant skunk works exercise ). As is, it works with Gotway and KingSong EUCs and Esa considers it a prototype (so, don't expect the quality and reliability of a commercial app). Whether that protocol analysis can/will be repeated for the IPS/Xima protocol I can't say. Whether the manufacturer is interested in cooperating and opens its sources, I can't say either.

Using the Pebble looks much more promising to me. The "classic" model can be found at about 100 Eu in many stores and you can pick up used ones at 60 Euro on ebay. Battery life is ONE WEEK with a "constantly on" display! I find the screen update rate very sufficient. You can make your own judgement from my little demo video (https://youtu.be/h_b7er_8lQM - about 2:00 minutes in). The solution should work on all Pebble watch models.

 

EDIT: as an afterthought, the 2 fps limitation @Kevin observed with the official XIMA app may actually come from the EUC's transmit rate. If the wheel sends only 2 updates per second, that will be the bottleneck and any app on the receiving side has to live with that, sorry.

Ah. I actually already did the reverse engineering work here:

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

I've submitted my app to the iOs store and am waiting on review. Fingers crossed that they don't look to carefully at the fact that it's reverse engineered software for a powered vehicle

And yeah just looked at the Pebble last night, looks very promising! And the refresh rate looks pretty good too. Might have to pick one up off ebay or something and give it a try!

[esaj]

Pushed some changes into Github:

-Removed designated end-point classes from broadcasts

-Added intent-filters for broadcast-receivers
-Checked audio files for unnecessary "silent" portions in start or end (none found)

-Added flags for more controlled shutdown (data arriving when the ser

…vices are going down etc. could cause them to be restarted while the application should be shutting down)
-Added separate BT-detachment call to MainFragment
-Removed couple of obsolete TODOs

-Added time-based checks when sound should be played, apparently some…

…times MediaPlayer can act weirdly, and keep repeating "true" on isPlaying, even though the sound is NOT playing anymore

-Moved audio playing as the last thing in WarningVibratorService.chec…

…kSpeedWarning and added try-catch -block (apparently MediaPlayer can also throw IllegalStateExceptions sometimes when it goes haywire, so it could prevent the vibration warnings from working also)

-Yet another try-catch-block in WarningVibratorService.stopAudio, just in case

-Doh, almost caused another bug... wrong variable when checking warning2-sound timing

 

 

The first two commits are mainly just general housekeeping (there still might be some edge-cases where the services stay running in the background after the app should be closed), but the latter ones are something I just found out (I was supposed to do just a last test run to see that everything is still working as it should after all the changes). It looks like MediaPlayer.isPlaying can sometimes keep returning wrong information, suddenly the first warning sound wasn't playing anymore at all (the vibrations still worked though).

After some googling I found this:

MediaPlayer is very odd and very fragile. You have very little you can do to tell what state it is in--and anything you do know could end up wrong.

When working with MediaPlayer, track for yourself what it should be doing, and then never, ever trust that MediaPlayer will be in the same state where you left it. Anytime you do anything with the MediaPlayer, be prepared for that lovely IllegalStateException--maybe it was playing, maybe it was prepared, maybe it was paused, but you should be prepared that, at any point, it may be in the wrong state. When you write your code this way, you are less reliant on isPlaying() being accurate.

Not helpful I know, but unfortunately we don't have much in the way of alternatives to MediaPlayer

So, I added some time-based checking around as an alternative:

if(!warning1.isPlaying() || (System.currentTimeMillis() - warning1StartedTime > 100))
{
    warning1.start();
    warning1StartedTime = System.currentTimeMillis();
}

And same for warning2. Also added try-catch blocks around MediaPlayer usage, in case it might throw.

 

EDIT: Also updated the signed release-version, available here (same link as before).

 

[esaj]

The audio problem still persists in the current release, I did another test run last night and it worked just fine for a couple of kilometers, but then when "bouncing" back and forth at the edge of the warning-level, it stopped playing the sound... I have an idea how to probably fix this once and for all, but won't get to do it until later today after work.

[esaj]

Ok, I'm now trying with using SoundPool instead of the MediaPlayer to see if it helps with the sound disappearing after a while... looking good so far, but still need to do a longer test ride to see that it keeps also working. There's a slight problem with Vee's phone, that it seems to lack the processing power to both play the sounds and keep updating the graph-view, so the sounds start falling behind if both are on   Might have to add more delay between playing sounds and hope that solves it...

Another interesting feature of the SoundPool is the ability to control the sampling rate. Basically, when the sound is played at lower rate than the original, the pitch of the sound goes down, and at higher rate, it goes up. The way I tested this was using the speed data and the difference between the warning levels to calculate a rate between 1.0 (normal rate) and 2.0 (twice the rate => twice the pitch). The effect is... interesting. Basically, you can hear how far above the warning level you're going. At the second level, as there's no higher level anymore (currently, the software is built so that there could be N warning levels), it just calculates the rate as current speed / warninglevel start speed. So if the last warning would be at 30km/h, at 35km/h the rate would be 35 / 30 = 1.16666.... Doubling the speed (60km/h ) the rate would be double (and it's capped between 1.0 and 2.0, so after 2.0 it doesn't go higher anymore). Made a short video by playing back an earlier recording with the wheel through my fake-wheel-server from my computer to the app:

There's a separate "Pitch"-checkbox under Speed warning -settings to turn the pitch control on and off.

[cg]

nice tune @esaj

[esaj]

Pushed changes into github:

-Modified WarningVibratorService to use SoundPool instead of MediaPlayer

-Added pitch-shift option for warning sounds
-Modified BluetoothService to interrupt all threads when killing them off to speed up shutdown
-Modified the closing of services in MainActivity a bit (hopefully finally all the services get killed correctly)
-Modified right-shifts in BinaryUtils to use zero-fill shifts
-Shortened some strings so the pitch-option fits into the screen in small phones

And updated the app-download:  available here (same link as before).

[EUC Extreme]

I got this now also introduced themselves. It seems very good. So far, there have not been any problems. This is a very good app that will bring more driving comfort. I'm really grateful for that esaj made such. Thank you.

[Compuatic]

Esaj, is there an iPhone iOS version available of this gotway app?

[esaj]

17 minutes ago, Compuatic said:

Esaj, is there an iPhone iOS version available of this gotway app?

Unfortunately no. I believe iOS-development requires a Mac (I don't have one), and the software for iOS is written in another language (Objective-C) which I've never used, although it is possible to interface with libraries written in C/C++. Anyway, it's unlikely that I will personally be ever making an iOS -version, but maybe someone will port it over to iOS sometime. Also the current trend seems to be that the wheels are moving toward using Bluetooth Low Energy -communication, with which this app is incompatible (of course, it's "only" a matter of reverse-engineering the new protocols and writing code for BT LE -communications )

Edit: Actually, I'm not sure if iPhones are able to communicate with non-Apple approved BT chips anyway, so it might be impossible to make the older Gotways / King Songs "talk" to iOS..?

[andress]

Hi,

amazing job Esaj!

I was wondering if you are planning to make app compatible with the new King Songs as well? I would love to have features like this. The standard app is very limited...

[esaj]

10 minutes ago, andress said:

Hi,

amazing job Esaj!

I was wondering if you are planning to make app compatible with the new King Songs as well? I would love to have features like this. The standard app is very limited...

Maybe in the future, but not right now... the problem is that the newer wheels use Bluetooth Low Energy-profile, and the data transfer works completely different in comparison to the SPP-profile. I don't have anything to use for testing BT LE currently.

[andress]

1 minute ago, esaj said:

Maybe in the future, but not right now... the problem is that the newer wheels use Bluetooth Low Energy-profile, and the data transfer works completely different in comparison to the SPP-profile. I don't have anything to use for testing BT LE currently.

That would be really cool  I know about that BT LE issue. Is it true someone here managed to make an app for BT LE euc? I dont remeber the brand.

[esaj]

3 minutes ago, andress said:

That would be really cool  I know about that BT LE issue. Is it true someone here managed to make an app for BT LE euc? I dont remeber the brand.

@Kevin created a custom Xima Lhotz-app for iOS, it's here:  http://forum.electricunicycle.org/topic/1545-xima-lhotz-alternative-ios-app/#comment-15981

 

[EUC Extreme]

I think I've already said, but I will say one more time.

I have used esaj APP's by ever since it was completed.
It has been a truly reliable speed alarm. None of the only times it has not let me down.
Alerts you exactly where it should be.
Esa Thanks again for the great APP.
As a result, I can drive maximum speed without fear of surprising exhaustion.

 

[sbouju]

And finally, what is this exact "maximum speed without fear", for you...?

Because for me and at this time, my "no fear state" is very variable, and is not only speed dependant! A chance is that the Gotway alert bips have exactly the same variability...

[EUC Extreme]

I understand your point
Now I will be the first vibrator 38 km h. Beep is 42kmh. It is a safe area, and remains little room beyond it

[Jug]

I would really love to have this app paired with my MCM4! 

[esaj]

17 minutes ago, Jug said:

I would really love to have this app paired with my MCM4! 

I think MCM4 uses Bluetooth Low Energy also, as do many other newer wheels. Currently the app can only be easily expanded to support BT SPP only, as I don't have any LE-dongles or such to develop with, and someone would need to get me the data captures to reverse engineer the protocols with... Plus I've managed to swamp myself with all sort of other projects, I'll try to get around to improve this um... some time

[OliverH]

Is there a possibility to change the BT module to BT low energy on the current GW MSuper and cross compile the app to iOS? Has anyone modified the GW PCB in the MSuper?

I'm not an Android fan boy.

@esaj @zlymex

[esaj]

Just now, OliverH said:

Is there a possibility to change the BT module to BT low energy on the current GW MSuper and cross compile the app to iOS? Has anyone modified the GW PCB in the MSuper?

I'm not an Android fan boy.

@esaj @zlymex

Just changing the module won't work, the Bluetooth-protocol works entirely differently with low energy profile, the firmware of the wheel itself would have to be modified for it to be able to transmit data over LE.

[OliverH]

Just now, esaj said:

Just changing the module won't work, the Bluetooth-protocol works entirely differently with low energy profile, the firmware of the wheel itself would have to be modified for it to be able to transmit data over LE.

OK. So it's not RX/TX to the module and the magic happens on the module (protocol stack,..)?

[esaj]

2 minutes ago, OliverH said:

OK. So it's not RX/TX to the module and the magic happens on the module (protocol stack,..)?

I haven't digged really deep into the Bluetooth, but the little I did glimpse when helping Kevin with reverse engineering the Lhotz-stuff, the LE-profile seems to work more like Zigbee or such... with the SPP, it's basically like a TCP-stream (you read bytes coming in and write bytes out), whereas with LE you have lots of different "attributes"  and "subscriptions" to those different attributes, or can ask the attribute values directly (if memory serves). So you can ask the device to report back to you when a value changes or such, no need to poll it continuously or for the wheel to send the data when it hasn't changed. I'm a bit fuzzy on the specific details, but it is definitely very different way of working with the data vs. the straighforward way of the SPP, where the wheel just continuously sends all the data over and over.

[andress]

Hi @esaj,

would something like this help? I captured it using built in developer tool in android. I have KS14C the newest mark III. The app shows around 117,9 km on odometer (it doesn't measure correctly when I don't have the app on) and 58.3 V battery voltage.

first is me connecting, then riding the euc with hand for few secs between 0 and 5kmph

second is connecting and while the euc is stationary I apply pressure for few secs and the current shown in the app goes up to around 30 amps, velocity is no more than 1kmph

Third is just connecting and disconnecting two times while not moving the euc at all

I'm not sure if all the logs are captured correctly as it was first time I did something like this.

Ondra

connect 0-5kmh disconnect.log

connect no movement applied force current up to 30A disconnect.log

no movement 2x connect and disconnect.log