the one feature every EUC firmware should have

[Spark]

or so i thought  

 

bluetooth immobilizer for wheel theft protection!

 

no excuse not to have it lazy programmers! 

and im a little disappointed neither brand I had a chance to ride (inmotion & kingsong) had it.

[freetheoranges]

Drill a hole through the case to immobilise the wheel by inserting a metal rod of some sort. 

[Carlos E Rodriguez]

Yes we need a proper way to secure the wheel. 

Also no cutoff while rider is on top. 

I understand that if the wheel stops trying to balance you might fall forward but at least I would be able to feel that I correct myself instead of just flyof like superman and crash. There is no reason for cutoffs.  

[Mono]

12 hours ago, Spark said:

or so i thought  

 

bluetooth immobilizer for wheel theft protection!

 

no excuse not to have it lazy programmers! 

and im a little disappointed neither brand I had a chance to ride (inmotion & kingsong) had it.

You probably haven't thought a lot about the subtleties to program a decent EUC controller. Sure, theft protection is an obvious and nice-to-have feature and I would quite like to have it, but it's by no means the one most important feature of EUC firmware, far from it.

[Demargon]

Maybe a key makes the work but I more comfortable keeping my euc in a safe place or were I can watch it.

I really miss a place where attach safely a bike chain. Not the weak handle of my inmotion

[Spark]

1 hour ago, Mono said:

You probably haven't thought a lot about the subtleties to program a decent EUC controller. Sure, theft protection is an obvious and nice-to-have feature and I would quite like to have it, but it's by no means the one most important feature of EUC firmware, far from it.

Hey Mono,

I quite like the idea to add you own feature wish, like Carlos did for a safety standard (no cutoff with rider on top)

as for theft protection, this is an obvious feature imho, en/disable motor via Apple/Android TouchId or password key as fallback solution.

and it is very very easy to implement from a developers point of view. If you can store tacky led patterns you can just as well store

something useful like an optional password.

The password should also serve as a protection against 3d party bluetooth access

 

 

[Mono]

4 hours ago, Spark said:

I quite like the idea to add you own feature wish, like Carlos did for a safety standard (no cutoff with rider on top)

I agree, we all like to have our own feature list...

BTW, the demand that EUCs should never cut off when a rider is on top of them is about as old as this forum, at least in this forum  

[Chuts]

There was a EU a while back that had said feature.  The Dolphin One I believe it was called.  You could enter a pin into the accompanying app which disengaged the gyro.  You could still switch on the unit, I guess so you could still pair the bluetooth together.  Just that it wouldn't balance until you entered your pin on your phone via the app.

Unfortunately the wheel itself wasn't very good according to Austin Marhold.  Believe the review that he done is still on YouTube somewhere.

[johrhoj]

There are features that are easy to implement and cheap, while being very useful. There are also features that are very hard to implement and expensive, while also being very usefull. Who is to say what is more important?

A few idears:

- bikes have a simple "stand" to keep them upright while being left alone. Why not something like that on an EUC? (simple, cheap, useful)

- find a way to make ppl fall backward iso forward (hard and not always possible).

- make it lockable, maybe as oldfashioned as a phisical wheelblock with key. The usefulness is not that great I think, for most of us do not leave the wheel behind in public places, or even outside unattended.

- make it unstartable. Like a car, where you need contact key. Could be with key or electronically (but what if phone is dead?)

What should be standard (imho) on all EUCs:

- lights, overspeed tiltback, max poweruse alarm, good battery indicators, app

[LanghamP]

A remote kill switch that cuts power to the wheel once it reaches above 15 mph. If my wheel got stolen I would enjoy doing that greatly regardless (or especially) of the level of injury/death inflicted upon the thief.

Just the thought of a thief with his teeth all over the pavement gives me a warm feeling; I would happily lose my wheel if that was the end result.

[Mono]

2 hours ago, Chuts said:

There was a EU a while back that had said feature.

Apparently the InMotion V3 has this feature as well. 

 

[electric_vehicle_lover]

18 hours ago, Spark said:

or so i thought  

 

bluetooth immobilizer for wheel theft protection!

 

no excuse not to have it lazy programmers! 

and im a little disappointed neither brand I had a chance to ride (inmotion & kingsong) had it.

Should be very easy to implement... communications from the app to firmware only over a secure layer. Then a command for the app send to enable/disable motor. Do you know how I enable/disable the motor while developing my OpenSource firmware? Just commenting or uncommenting this lines that enable/disable motor phases:

  enable_phase_a ();
  enable_phase_b ();
  enable_phase_c ();

Good idea to implement this feature. But I see a problem!!! You know, EUCs like GotWays have this kind of boards that I am using to develop the firmware: https://github.com/EGG-electric-unicycle/documentation/wiki/MicroWorks-30B4-30kmh-controller-board-with-bluetooth

What is the problem? the microcontroller they use do not have a persistent memory!! and for the feature you mention, a persistent memory is needed to store the flag about motor enable or disable. There is no persistent memory on the board!

But there is a way to emulate a persistent memory on the microcontroller, however, I believe the flash memory for that should be almost full for the firmware and so should be impossible to implement this persistent memory on the EUCs controllers - AN2594: EEPROM emulation in STM32F10x microcontrollers : http://www.st.com/en/embedded-software/stsw-stm32010.html

Anyway, with our OpenSource firmware, we will be bale to explore and implement this features!!

 

[Mono]

2 hours ago, johrhoj said:

There are features that are easy to implement and cheap, while being very useful. There are also features that are very hard to implement and expensive, while also being very usefull. Who is to say what is more important?

A few idears:

- bikes have a simple "stand" to keep them upright while being left alone. Why not something like that on an EUC? (simple, cheap, useful)

I have that on my InMotion V8 (it stands on the mudguards). It only works on pretty even ground, yet pretty useful.

Quote

- find a way to make ppl fall backward iso forward (hard and not always possible).

I have no idea what you are talking about 

2 hours ago, johrhoj said:

- make it unstartable. Like a car, where you need contact key. Could be with key or electronically (but what if phone is dead?)

IMHO the lock function should be temporarily, where the user can define the lock time (by default, say, 24h). Like this, one can prevent that the wheel becomes permanently unusable.

[Mono]

6 minutes ago, electric_vehicle_lover said:

What is the problem? the microcontroller they use do not have a persistent memory!! and for the feature you mention, a persistent memory is needed to store the flag about motor enable or disable. There is no persistent memory on the board!

Though any recent EUC does keep track of the mileage and all kind of other settings, don't they? If they forget their mileage, it might not be so bad if they also forget the motor disabled setting.

[steve454]

9 hours ago, Spark said:

Hey Mono,

I quite like the idea to add you own feature wish, like Carlos did for a safety standard (no cutoff with rider on top)

as for theft protection, this is an obvious feature imho, en/disable motor via Apple/Android TouchId or password key as fallback solution.

and it is very very easy to implement from a developers point of view. If you can store tacky led patterns you can just as well store

something useful like an optional password.

The password should also serve as a protection against 3d party bluetooth access

 

 

Ninebot one has a lock function in the app, you lock the wheel and it will still turn on with the power button but it starts shaking and beeping and is unrideable.  The only way someone could steal it and ride it is to also have your phone that the app is on.  In fact, when you do a calibration of the Ninebot, it locks the wheel until calibration is complete.  Maybe if the thief had the app on his phone he could turn off the lock feature, but the odds of someone knowing about the app are slim to very slim.  But most likely someone would steal it just because it looked valuable, even if they didn't know what it was.  The best protection is to keep it in sight always.  

I think the lock function for Ninebot is mainly to protect children who might turn it on and get hurt by the wheel moving, and preventing calibration while riding.  Mainly a safety feature.

[Vik's]

9 hours ago, steve454 said:

Ninebot one has a lock function in the app, you lock the wheel and it will still turn on with the power button but it starts shaking and beeping and is unrideable.  The only way someone could steal it and ride it is to also have your phone that the app is on.  In fact, when you do a calibration of the Ninebot, it locks the wheel until calibration is complete.  Maybe if the thief had the app on his phone he could turn off the lock feature, but the odds of someone knowing about the app are slim to very slim.  But most likely someone would steal it just because it looked valuable, even if they didn't know what it was.  The best protection is to keep it in sight always.  

I think the lock function for Ninebot is mainly to protect children who might turn it on and get hurt by the wheel moving, and preventing calibration while riding.  Mainly a safety feature.

Yes, 9b1 have this feature and i've used it on a few occasions. Useful in the office etc.

[Spark]

Anyway, with our OpenSource firmware, we will be able to explore and implement this features!!

hey electric_vehicle_lover,

an open source EUC firmware sounds great!

Do you happen to know if the KingSong mainboards are much different from the gotways?

I'm afraid there might be no persistent memory on the KS-16b either.

However if you have already dismantled your wheel, there might be a possiblilty to just add

a simple eeprom chip to the circuit somewhere?

 

I currently still spent most of my free time trying to improve my riding skills, phase 2 would be

convincing my gf to learn to drive too  phase 3 would be improving the device itself.

Currently all my tools to write flash chips are in some box in the attic (last time I needed them was

when we were watching satellite tv back in the early 90ties )

 

[electric_vehicle_lover]

40 minutes ago, Spark said:

Do you happen to know if the KingSong mainboards are much different from the gotways?

I'm afraid there might be no persistent memory on the KS-16b either.

However if you have already dismantled your wheel, there might be a possiblilty to just add

a simple eeprom chip to the circuit somewhere?

I think KingSong also use some STM32 microcontroller, not sure if is the same.

I want first to add features on firmware only, so anyone take advantage of it, without touching wires. I already did a mod, adding and Arduino + RGB led bar, and it is really nice :-)

Firmware should be flashed over bluetooth, so users will be able to flash using Android phones, I hope to make an app for it. No touch on hardware on first phase, then more customizations can be done.

My girlfriend and my son of 6 years old, both ride, you can see videos here: https://github.com/EGG-electric-unicycle/documentation/wiki