EUC Dash

[Freestyler]

Backstory

Around a year ago I had an overlean accident.

I felt that this was easily preventable and should not have happened.

My mission became to make gotway wheels safer for everyone. (sounds like the start of super-hero movie)

@enaon found the PWM alarm in the bluetooth protocol after my accident and and that was a huge step towards safety.

For the past few weeks I've been reverse engineering gotway wheels (with the help of @enaon and @Lefteris) and we are now ready to report our findings.

 

Web APP

 

We made a lot of discoveries and I realized it would be very hard to present them without something tangible. (not everyone has an euc watch)

For this reason, I created the following site https://freestyl3r.github.io/euc-dash/

You can connect to your gotway / begode wheel through a web bluetooth compatible browser (laptop & phone) and get all the available information for your wheel.

 

Walkthrough

When you connect you'll see a following a screen.

Wheel info section

First we have the wheel info section.

We have 3 new information available to us: Wheel model, Wheel code name and IMU model (aka gyro sensor).

The apps can request the above information instead of relying on custom heuristics.

Why is this information useful? Gotway reports the voltage as a 67v wheel for backwards compatibility even if you have a 84v, 100v or above.

The app makers need to scale up this value. Having the model, you can make a mapping and only ask the user to enter if the detection is wrong (for example Nikola comes in 84 & 100v versions).

The code name looks like a version, but is not. Do not mistake it for one. It does not increment on software updates and it is unique for every wheel (almost...).

IMU model is crucial component of our wheels. It provides gyroscopic, acceleration, temperature and other data.

The wheel advertises the model when powering on. It is hard (if not impossible) to connect fast enough to get this message.

Instead, you can place the wheel on the side until the motor disengages (the wheel beeps 5 times) and put it back up so that the motor re-engages. The wheel initializes again and sends the IMU model name along with some more info (such as current voltage, ADC voltage etc).

 

Why is this important you ask? The wheel reports temperature in the native IMU format.

All apps assume that the IMU is the MPU6050 and they use its formula to convert to celsius.

All the new gotway wheels ship with the MPU6500 though and that model's data needs a different formula to convert.

The MPU6500 formula yields a lower temperature by around 10-15 degrees celsius.

At first we thought that everything we knew is a lie  , but @RagingGrandpa kindly provided temperature measurements directly from the IMU chip and we came back to our senses.

It turns out that gotway once again for compatibility reasons (notice the trend) always reports the temperature in the MPU6050 format.

Moving on!

 

Live data section

Nothing new here, except for the fact that the voltage reports the minimum voltage as well. (correct for black controllers only)

 

Settings section

When we want to disable tiltback we set it to 100. Haven't confirmed if that's a magic value for disable or just a high enough value, because wheels that exceed 100 km/h are approaching (looking at you master)

Speed alarms have 4 states. 

0) fixed speed alarm 1 & 2

1) Fixed speed alarm 2

2) PWM alarm

3) ?

 

3 is a new state I found, but I don't know if it does anything (maybe it silences low voltage beeps?)

Mark it for now and we'll return later to it

 

Tilt angle is now available as well. Only the official begode app was aware of it afaik.

 

Settings section

Alarm 1 & 2 report all sorts of "faults".

I have personally verified PWM and fixed speed alarms (1 & 2), but overvoltage, low voltage, high temp, hall sensor error, gyro error etc.

Fun fact, the wheel does not report overvoltage. For 84v wheels 84v is the max value you'll see (and 100.8v respectively). My guess is for backwards compatibility once again to not confuse apps.

 

Resets: Remember the procedure to find the IMU model above? Every time the wheel is re-initialized, the counter increases.

Think of it as a wheel drop counter.  (it resets when the wheel is powered off for few seconds)

Power off timer! The wheel auto powers off after a specified inactivity period (different for every wheel).

For the mcm5 it is set at 50 minutes. If you move the wheel (even with the motor disengaged) the counter resets.

 

Computed data section

Simple but useful section. First we calculate the battery percent using a linear calculation (which means that voltage drops are accounted for).

If you do a free spin test (I suggest you do it slowly for best results) and your wheel reports the PWM alarm, we show the speed it was triggered.

Using a linear drop formula, we can calculate the speed that the PWM alarm would be triggered for different battery levels. (including the current battery level)

I tested it on my MCM5 and the euc watch and the speed was accurate within +- 1 km/h.

Illustration video: https://streamable.com/6vdriq

 

That was all the information found in the main packets.

No unmapped / uknown data remain.

 

One more thing...

It turns out that another set of packets reside in the wheel.

We call them the "extended packets". Press the aptly named button on the top to get them.

 

Oh boy. Gotway really kept the "main packets" unbroken in the name of backwards compatibility (that's a good thing IMO), but they went all out in the extended packet format!

Voltage reports the real value for example without the need to scale it and Tem is in the native MPU6500 format we discussed above. (I used the appropriate formula to convert to celcius)

We also have the tiltback speed (close raise mark), speed, distance, roll, angle a bunch of Current values etc.

The RoatCurrMax is the real battery current from what I gather, but unfortunately it only holds the max value.

The star of the show, is the PWM though.

Yeap, that's right. Gotway wheels report the true PWM.

This is NOT just speed dependent. It reacts to the voltage drop as well. If you jam the wheel on the wall you will see the value increasing.

I've also done a riding test with the ratio of PWM / speed and the ratio changed with the road conditions (incline, decline, hitting pot holes etc)

I provided a gauge at the bottom of the screen in order to better visualize it and also find the exact PWM % that your wheel beeps (hint: it's not 80% for every wheel  )

Keep in mind that every wheel has different information. Other have more, others have less, the names also change between wheels.

All in all, it's very difficult to parse reliably for all wheels.

You can switch back to main packets at any time by pressing the button or by sending any command to the wheel (or re-engaging the motor like we discussed).

The bad

The main packets alternate between 2 data frames of 24 bytes which are split into 3 packets because the bluetooth packet size (MTU) of the wheel is 20.

So every 3 packets we have a full rotation.

Roughly 900 packets per minute are sent from the wheel.

900 / 3 = 300 frame data rotations / minute  (5 data frame rotations / second)

Remember, 1 rotation equals 2 data frames packets, so 10 data frames / second.

Put it simply: A value (such as speed) is updated every 100ms.

 

Unlike the main packets and their binary form, the extended packets in plain string format.

This format is ill suited for the space constrained bluetooth protocol of the wheel, but allows for rapid prototyping.

In order to build one data frame, 9 packets are required. The sent rate stays the same though.

So 900 packets / 9 = 100 rotations per minute or 1.66 per second.

Put it simply: A value (such as PWM) is updated every 625ms...

That's a kinda low rate and it makes the extended packets less attractive.

Stay tuned for solutions to this problem.

 

Additional findings

Something other of note, is that most wheel commands require one byte of data (such as beep or changing the pedal mode), but some commands like changing the LED mode, require 3 bytes.

I think that most (if not all) apps, send these bytes in 3 different write commands, but they can be combined in one.

In the future I will add support for changing every available setting.

All commands are present in the source code, I just haven't got around to adding them in the UI.

 

Source code

The source code is available on Github. I've tried my best to keep it as cleanly as possible in one file in order for interested parties to get the information easy.

https://github.com/freestyl3r/euc-dash

 

Stay tuned for more info. It's impossible to fit everything in one post

Here's a teaser:

Edited March 22, 2022 by Freestyler

[enaon]

summoning  @Seba @Alla Shkolnik @supercurio @Pickelhaupt 

thanks Bill for all the info and the mention, you are being humble I think, this is all you the way I see it, thanks again, I will import to the watch.

Edited March 22, 2022 by enaon

[Lefteris]

This whole process was quite fun. 

@Freestylerwent full vamp mode in order to have it ready for the public. It is rough between the edges but this project isn't about the looks. 

It's about the data findings. This project is going to change how apps work and currently places Gotway/Begode wheels at the top of data that we can read. 

All this wouldn't have happened without the team, and we hope that team gets bigger ☺️

Stay tuned. 😉

p.s./teaser: Some wheels have pwm at 80% if alarms are on, and 75% if alarms are off 
 

Edited March 22, 2022 by Lefteris
Pwm in the end

[Lefteris]

p.s.2 this needs to by sticky 

Calling for mod powers 🔥🔥

@John Eucist? 

@meepmeepmayer ?

Edited March 22, 2022 by Lefteris
Mod's cc

[Freestyler]

I didn't realize there was a project already named EUC-Dash-ESP32 by Pickelhaupt.

I'll rename when I think of a better name. Suggestions welcome  

some alternatives: EUC Web Dash, EUC Web Dev, EUC Web Tool

[Lefteris]

4 minutes ago, Freestyler said:

EUC Web Tool

This but "Tools" cause i know for a fact, you won't have the project only fetch information  

But, I prefer "EUC Dev Tools" as a 4th option  

Edited March 22, 2022 by Lefteris
4th option

[supercurio]

Awesome job @Freestyler!
Cool idea to implement that as Web Bluetooth so that can run on every computer OS as well and Android phones in Chrome on the go.

Did you find how to switch to the extended packets form clues in the firmware binaries, now available for black motherboard updates?

Some preliminary thoughts:

• RoatCurrMax could still be used to help calibrate a battery current estimates algorithm, instead of hooking up hardware
• Real PWM is awesome!
• Sadly, PWM at 1.66 Hz is not enough for safety alarms
• Real PWM could be used to calibrate the computation of a better estimated PWM from phase amp & speed (and maybe battery voltage)
• This extended packet looks like it's here for development & debugging
• EUC makers must learn how to use BLE properly, with characteristics, notifications and indications instead of treating it like a wireless serial port.
  I think we have to show them how! (hence the idea of the standardized EUC/PEV wireless protocol)
• I think there's an opportunity to suggest implementing a version of a space-efficient protocol as 3rd protocol, available in software update, that would contain PWM.

However from your "stay tuned" if it's possible to select which data the firmware adds in the extended packet, instead of of all them then it could make the PWM value usable for alarms 😃

[Lefteris]

7 minutes ago, supercurio said:

hence the idea of the standardized EUC/PEV wireless protocol

I'm all for it, really! 💪💪

[enaon]

18 minutes ago, supercurio said:

However from your "stay tuned" if it's possible to select which data the firmware adds in the extended packet, instead of of all them then it could make the PWM value usable for alarms 😃

he tried that, removed unnecessary info to make the packet shorter, it didn't help, but there is an easy way if one has a n lcd screen on the gotway, thus do not need the temperature reading on the app. He was able to build a custom testing firm with the pwm in the place of the temperature on the normal packet. 

this way it was possible to compare EUC World's calculated PWM, to the reported one, realtime. Thus. we already know for a fact that the software calculation is a bit off. 

this is a simple demo, top left is wheel reported pwm, not temperature in this case. 

 

Edited March 22, 2022 by enaon

[supercurio]

A hacked firmware to output the desired data, brilliant!

Until official firmwares output the data in a good format so it works out of the box for everybody, that could work for prototyping 😃

[supercurio]

Feature request for hacked firmwares: output real PWM value in both A and B frames for 2x the data rate 

[Lefteris]

Don't go there yet, there are so many things to consider..  

[enaon]

2 minutes ago, supercurio said:

Feature request for hacked firmwares: output real PWM value in both A and B frames for 2x the data rate 

don't think for a moment we didn't think of that. 

The thing is that changing the temp to pwm requires minimal intervention, the function is almost identical. And PWM on the main packet is quite fast, one can depend on it.

But this is now, more time, more people getting involved, a lot can happen. 

[Freestyler]

Like Enaon said, we tried many things already.

First we removed a lot of information from the extended packets and that reduced the packets from 9 -> 3.

The data frame rate stayed the same though. The packets were spaced out in time and we still received a full data frame every ~600ms.

I guess there is a function controlling the rate somewhere.

 

We also tried to duplicate a reading such as speed in more than one packet, and the value was updated indeed. (so 2 speed occurrences in one data frame)

The next step was to bring the PWM into the main packets.

The easiest value to replace was temperature. Changing another value, requires more advanced assembly skills that I lack for the time being.

The result can be seen in the euc watch video above and on this video as well: https://streamable.com/s9usqe

Please excuse the Greek language. You can see that Euc world is oblivious to the fact that the temperature reading is replaced by PWM.

If we manage to replace a more useless value such as the poweroff idle time, then it will be very usable.  

 

I also changed the PWM trigger value to 70% for my wheel and to 90% for when setting the speed alarms to 3 (I mentioned the hidden speed alarm setting in my first post).

 

I've also tried to reset the max battery current on each extended frame.

(ps: some wheels seem to have a real time battery current and not just the max value)

Unfortunately I crashed the wheel and had to disconnect the batteries and flash a working firmware.

I cannot test things aggressively, because I don't want to have to open my wheel or risk a hard brick.

We need an open wheel / spare controller :/

Edited March 22, 2022 by Freestyler

[supercurio]

Thanks for all the details @Freestyler

Copying the PWM value into the temperature is a genius hack, since it allows to get working customizable PWM alarms in WheelLog, EUC World and DarknessBot right now without any other modification.
Since all the apps out here already have over-temperature alarms.

Simply brilliant!

It's so good that it would be worth making hacked firmwares doing just that for all the wheels that can be flashed, especially in case the mod can be automated.

Edited March 22, 2022 by supercurio

[Freestyler]

8 hours ago, supercurio said:

Cool idea to implement that as Web Bluetooth so that can run on every computer OS as well and Android phones in Chrome on the go.

There is also a paid browser for iOS (2 dollars) with web bluetooth support that should work (WebBLE).

We know because some guys use it to connect to the Euc watch loader in order to update the watch.

There is also a free version (Bluefy), but I have no info on that.

 

EDIT: WebBLE browser confirmed to work. Bluefy didn't work.

Edited March 22, 2022 by Freestyler

[Lefteris]

3 hours ago, Freestyler said:

There is also a paid browser for iOS

What is going on on iOS, everything is pay to use nowadays 😵😲

[RafaPGarcia]

Oh boy!! You're gonna save my day!

Two years ago I thought on building a webapp for managing EUCs, but I gave up because it was too difficult for me to read Java code (I had EUC world's old repo), so I wasn't able to understand HOW to talk to wheels.

Now that I'm managing a website to find/compare EUCs, this idea came to my mind again. And again, I've been struggling on how to get readable info from wheels.

This porject is opening new roads for me, and I'm really grateful for it.

That said, I would like to make my app compatible with KS and Inmotion wheels, and I'm wondering if you have services' ids for those brands :O

[Chriull]

53 minutes ago, rafa.pgarcia said:

That said, I would like to make my app compatible with KS and Inmotion wheels, and I'm wondering if you have services' ids for those brands :O

Should be all in https://github.com/Wheellog/Wheellog.Android

16 hours ago, Lefteris said:

p.s.2 this needs to by sticky 

Is as link in the pink  app summary/overview topic https://forum.electricunicycle.org/topic/22558-euc-apps-and-projects/

Feel free to propose better links/description if i got something not right.

20 hours ago, Freestyler said:

Yeap, that's right. Gotway wheels report the true PWM.

That's great, now only leaperkim misses pwm reporting!

21 hours ago, Freestyler said:

Yeap, that's right. Gotway wheels report the true PWM.

This is NOT just speed dependent. It reacts to the voltage drop as well. If you jam the wheel on the wall you will see the value increasing.

Yes - it's more or less the percentage of how near one is to an overlean/"used torque percentage". 100% pwm duty cycle is all the wheel can give...

https://forum.electricunicycle.org/topic/7855-anatomy-of-an-overlean/?do=findComment&comment=314654

 

[Freestyler]

I'm glad you found it useful @rafa.pgarcia! A goal of mine is to demystify the whole process.

For information on kingsgong / inmotion wheels, you can look at the source code of Euc watch here:

https://github.com/enaon/eucWatch/blob/main/P8-testing/eucKingsong/eucKingsong.js

https://github.com/enaon/eucWatch/blob/main/P8-testing/eucInmotionV1/eucInmotionV1.js

 

Edited March 22, 2022 by Freestyler

[Freestyler]

3 minutes ago, Chriull said:

That's great, now only leaperkim misses pwm reporting!

We might have something to say for this soon enough 

[Freestyler]

Veteran support added

https://freestyl3r.github.io/euc-dash/veteran.html

 

Same story as in Begode wheels. We can request an extended set of information.

The extended information haσ 3 pages of data. Use "Next page" to cycle through the pages.

I counted almost 96 values! 10 times the extended data of Begode wheels.

 

I didn't find an alarm state in my limited test, but feel free to test and report back any findings!

Have a look at this thread as well for some reference: https://forum.electricunicycle.org/topic/23925-sherman-1058-menu-items/

One value that looks suspiciously like a PWM, is "VQ".

When this values reaches 5700, the alarm activates. Its maximum value at the end of the free-spin is 7600.

5700 of 7600 is 75% which seems like a possible PWM limit.

 

 

In the homepage (https://freestyl3r.github.io/euc-dash/) you now select Begode or Veteran. The "UI" is beyond sad as you can see, so anyone with UI skills, please do help!

Edited March 24, 2022 by Freestyler

[enaon]

attached is a sample of a sherman free spinning if one wants to see VQ compared to dKM ( I think it is speed).


vet2.txt

[Freestyler]

Begode alarms (faults) added, if an app maker wishes finer granularity.

Quote

const faultAlarms = {
 0: 'high power',
 1: 'high speed 2',
 2: 'high speed 1',
 3: 'low voltage',
 4: 'over voltage',
 5: 'high temperature',
 6: 'hall sensor error',
 7: 'transport mode'
}

 

[supercurio]

Thanks I will look into adding that in EUC Alarm @Freestyler

Edited March 28, 2022 by supercurio