is the project alive?

[voltangle]

As in name, is it alive? I am now making a project for making custom lighting system for unicycles, and I was stuck in a problem of getting data from that unicycle to make animation of LED strip speed be the same as the unicycle speed.
So, is the project alive?

[T-vK]

Not really. I mean it's still functional, but I haven't added support for any new unicycles. This probably only works with older Gotway unicycles.

[voltangle]

Oh, okay. But why you stopped working on this awesome library? It will be really helpful in a lot of projects)

[T-vK]

I kinda lost my interest in electric unicycles. So I never bought any new ones and thus never had the need to improve upon the library. For the older Gotway models this library is already pretty polished.

In case you are interested in reverse engineering your unicycle, odds are it uses a Bluetooth Serial connection for receiving/transmitting data to its app. Using a Bluetooth Serial monitoring app you could log the data the unicycle is sending.
Then it's just a matter of analyzing it. For example if you get 10 bytes and one of the bytes increases when the unicycle spins faster and decreases when it slows down, that byte is probably the speed. And if there is a byte that decreases when the battery gets lower and increases when charging this would be the battery voltage or capacity... This way you can slowly figure everything out.
For the other way around (analyzing data sent from the app to the unicycle) you might want to get one of these hc bluetooth modules and immitate your unicycles bluetooth mac address and name and then connect the app to it and see what you get when you press certain buttons in the app.
It might also be worth it to just decompile the app and see if you can decipher it.

[voltangle]

Thanks! And sorry if it this question is a lil off, but why you lost interest in EUCs? And yes, I don't even need to decompile the app or reverse engineer the data, I can just talk with WheelLog(custom EUC app) developer about the data sent by unicycles.

[T-vK]

Legal reasons. Because of the big lithium batteries it is difficult if not impossible to take them with you on an airplane and in many countries riding them in public traffic is legally considered to be be a crime.

If you post the data I can try to evaluate how difficult it would be to add it to this library.

[voltangle]

I can post the example data, and here it is:

5A5A5A5A55AA000060D248001C20006400010007

55AA19B4000000000000012CEFF20001FFF80018

5A5A5A5A55AA000060D248001C20006400010007

these are GotWay data

The WheelLog dev said that this data is nearly the same as the old GotWays data

[T-vK]

I meant the data the developer has deciphered. For example:

Byte 1-8: header (never changes)
Byte 9-10: battery voltage
Byte 11-12: speed
Byte 13-16: trip milage
Byte 17-18: current (ampere)
Byte 19-20: temperature
Byte 21-24: unknown
Byte 23-30: secondary Header (never changes)
Byte 31-34: total milage
Byte 35-46: padding (all zeroes)

[voltangle]

Yes, I have the data, but it is in the source code of the android app. And I have a question, can I help you in development of this library? If you allow me to help, I can try to add more EUC data decoding functionality to this library, for e.g. add InMotion, KingSong, new GotWays, Ninebots and more. And also, can you tell me which part of the code does what, I need that to know how to write actual decoder

[voltangle]

I have already created a fork, so I can do all work there, and then create pull request here

[T-vK]

Of course you can help, we are on GitHub after all. You can make a fork of this repo and create a pull request any time.

At the moment the code is written in a way that it would require making a lot of fundamental changes in order to support unicycles that send different packets.

But essentially this struct definition:

Electric-Unicycle-Interface/EucInterface.h

Line 13 in 235764f

struct RawData {

contains the information on what properties the unicycle sends and how many bytes each property takes in bytes and where in the packet it is located.

And this is where the data received over the serial connection gets stored in such a struct:

Electric-Unicycle-Interface/EucInterface.cpp

Line 30 in 235764f

Euc::RawData Euc::receiveRawData() {

At that point the data is simply stored in the struct byte for byte.

In order to make that data useful it then gets converted from byte arrays into proper data types:

Electric-Unicycle-Interface/EucInterface.cpp

Line 17 in 235764f

Euc::UsableData Euc::makeRawDataUsable(Euc::RawData eucRawData) {

Using some bit-wise operations and casting.

The data types to be used for the final casting are defined here:

Electric-Unicycle-Interface/EucInterface.h

Line 30 in 235764f

struct UsableData {

Adding unicycles with different package formats would require making all of that dynamic and ideally split it into one base class that is relevant for all unicycles and classes for each unicycle that inherit from that base class.

[voltangle]

So, I think we can declare this project to be alive. And now, lets move this conversation to another issue called "Supporting different EUC models"