MEGABOBRA: Bosch Smart System Derestriction for Rim Magnet - DIY Project with Support

[megabobra]

That's fine, mine looks exactly the same

 

[manu.w]

And now, who will be the first brave tester that will install the flow firmware upgrade and see if all still work

 

[megabobra]

And now, who will be the first brave tester that will install the flow firmware upgrade and see if all still work

View attachment 126698

I'm running version 1.13.7(1017) of the app, but latest motor firmware version.

 

[manu.w]

My flow app version is 1.15.10 (110)
Don’t know about the motor firmware, how can i find that out?

 

[megabobra]

My flow app version is 1.15.10 (110)
Don’t know about the motor firmware, how can i find that out?

Go to Settings > 'xxxxx's eBike' > Components > Drive unit > software version.

 

[manu.w]

Go to Settings > 'xxxxx's eBike' > Components > Drive unit > software version.

Ok, my drive unit : 4.21.0

Will this change when applying the update ?

 

[AlumiPro]

When my bike was in the shop 3days ago to have the LPP turned on they did several firmware updates.

 

[manu.w]

When my bike was in the shop 3days ago to have the LPP turned on they did several firmware updates.

And the speedhack is still working?
Can you share your app version and drive gear firmware?
Thanks

 

[AlumiPro]

I’ve only tested the bike after the Megabobra instal while in a bike stand. Haven’t ridden it.
How do I find the current firmware it’s got? I wasn’t finding it in the flow app

 

[manu.w]

I’ve only tested the bike after the Megabobra instal while in a bike stand. Haven’t ridden it.
How do I find the current firmware it’s got? I wasn’t finding it in the flow app

Go to Settings > 'xxxxx's eBike' > Components > Drive unit > software version.

 

[AlumiPro]

Software version 8.16.0

 

[FINJP]

Hello from Finland.
Thanks @megabobra for a great topic!
I will do it, just sourcing the parts. Winter and snow is coming soon, so why not some more speed and fun.

 

[manu.w]

Software version 8.16.0

Wow, I am “half” that far 4.21.0

 

[megabobra]

Wow, I am “half” that far 4.21.0

I'm on 5.17.0 - guess it's not the latest after all!!

 

[manu.w]

RemoteXY with Bluetooth hm10

 

[manu.w]

Software version 8.16.0

Is this version compatible with the megabroba speed hack?

 

[AlumiPro]

Is this version compatible with the megabroba speed hack?

I haven’t had time to go on an actual ride with it yet. But it’s working while the bike is held off the ground in a stand.
I can’t see how up dating the software would cause problems, due to the simplicity of the Megabobra creating a slower magnet pulse which reflects the actual speed slowing down or going faster. It’s not tied into the Bosch computer system, manipulating it.
Megabobra will have the best response to this question though….

 

[megabobra]

I haven’t had time to go on an actual ride with it yet. But it’s working while the bike is held off the ground in a stand.
I can’t see how up dating the software would cause problems, due to the simplicity of the Megabobra creating a slower magnet pulse which reflects the actual speed slowing down or going faster. It’s not tied into the Bosch computer system, manipulating it.
Megabobra will have the best response to this question though….

Well, as it turns out your motor firmware is far ahead of everyone else's, so you're treading new ground!!

I agree with your assumption, but I can't prove it

 

[aegidius]

I've been trying to figure out how Bosch is detecting tampering. My best guess atm is that they are calculating the energy used per km (Wh/km) based on the sensor speed, and subtracting out hill climbing power which would otherwise swamp any measurements of power usage. They can compensate for hills using an accelerometer, similar to the way an opposing-force power meter works - but I have yet to see a teardown of the gen 4 motor PCB to check if one is present. Based on a roughly-known power usage expected to overcome rolling and air resistance, they can see if the power usage is a bit high from what it should be, and accumulate a deficit in kms travelled. When this gets too high, it throws an error 504 - based on the behaviour over possibly hundreds of kms, obfuscating any obvious cause. So just slowing down the pulse train from the wheel might not get you out of trouble (esp. if you wanted to up the speed a lot) even though it seems to work at first glance.

This is probably why some speed unlocker chips makers tell you to run it after stopping so that the missing kms can be put back, reducing the Wh/km to acceptable levels again. Now Bosch should easily be able to detect and discard this trailing train of pulses from the wheel with no accompanying pedal cadence or torque input. With an accelerometer (which as above they must have to cancel out hill climbing power) they could even detect whether the bike was moving or parked., thus spotting legitimate long downhill runs at the end of a ride. So they will probably, if they haven't already, issue a SW update to do this detection, and I wouldn't rely on it long term.

 

[manu.w]

Why in the hell would they do this over complicated logic an loose possible customers …?, if it is a legal obligation, they could just proof they apply a speed limit…

If all this is true, then I would output the real speed if <=25 km/h, and all speeds above reduce it progressively to 25?

 

[tatane]

I've been trying to figure out how Bosch is detecting tampering. My best guess atm is that they are calculating the energy used per km (Wh/km) based on the sensor speed, and subtracting out hill climbing power which would otherwise swamp any measurements of power usage. They can compensate for hills using an accelerometer, similar to the way an opposing-force power meter works - but I have yet to see a teardown of the gen 4 motor PCB to check if one is present. Based on a roughly-known power usage expected to overcome rolling and air resistance, they can see if the power usage is a bit high from what it should be, and accumulate a deficit in kms travelled. When this gets too high, it throws an error 504 - based on the behaviour over possibly hundreds of kms, obfuscating any obvious cause. So just slowing down the pulse train from the wheel might not get you out of trouble (esp. if you wanted to up the speed a lot) even though it seems to work at first glance.

This is probably why some speed unlocker chips makers tell you to run it after stopping so that the missing kms can be put back, reducing the Wh/km to acceptable levels again. Now Bosch should easily be able to detect and discard this trailing train of pulses from the wheel with no accompanying pedal cadence or torque input. With an accelerometer (which as above they must have to cancel out hill climbing power) they could even detect whether the bike was moving or parked., thus spotting legitimate long downhill runs at the end of a ride. So they will probably, if they haven't already, issue a SW update to do this detection, and I wouldn't rely on it long term.

This doesn't look like a sensible option to me : this Wh/km is going to vary greatly based on rider's weight. They sure could have boundaries but a 60Kgs (~132lbs) kit'd rider will have this waaaaaaay lower then, say nrml_mtber and his ~330lbs and Bosch would likely run into huge problems if it came to locking fat bikers engines because they consume too much.

Not saying it couldn't be one of the factors, but I believe such a protection is multi-factored (which is why it only triggers after a certain distance, and rendering something you paid for unusable requires them to be able to prove beyond any reasonable doubt that the engine have indeed been tampered with) and we will have to figure out all of them to have something that can't be detected

 

[aegidius]

This doesn't look like a sensible option to me : this Wh/km is going to vary greatly based on rider's weight.

Agreed. The other thing they can't measure is wind. Gathering evidence for any of this is tricky, since the motors are (possibly deliberately) slow to respond with the error, making it hard to link cause and effect. But if there were more errors on windy rides, hilly rides, or with heavier riders, that would point to the details of any power consumption based algorithm. When this anti-tamper nonsense was first released, they went a bit too hard on it and there were anecdotally many false positives. It would have been useful to see if there was any pattern in them.

Certainly if you used a simple divide-by-two on the speed, and/or get greedy and want to go 50+ km/h all the time, the Wh/km based algorithm can easily detect it. (I've done it in a spreadsheet based on a few FIT files from real rides) But with a better algorithm that preserves lower speeds unchanged, and a modest 32km/h cutoff, those differences disappear in the noise. (I won't be trying it for real anytime soon - bike warranty is still too fresh!)

In any event - what else could motor SW do? It only knows a (possibly altered) speed from the wheel sensor, its own pedal cadence and torque, and motor amps. Maybe there's an AI-based analysis of the overall patterns of the rides, that would take training on a bunch of rides of chipped vs. unchipped bikes? Just speculation until someone breaks cover with real data.

 

[tatane]

@Koekie posted in another thread a while ago a link to a Bosch patent that's pretty interesting. Based on this I started working a while ago on introducing a H-bridge to the MegaBobra cricuit to simulate the behavior of the electromag passing by the sensor (polarity reversing at the middle of the impulse). We can also see that this is indeed what's happening with the original rim magnet (Thanks @Mervious for doing that test/posting the results) :

Whereas the MegaBobra as it is would get this :

Took me a while as I had some issues with the code for that but finally got something that seems to work as I want it to and now waitiing for some parts to build a live test device, but this is what would now get output to the magnet instead of a square pulse :

Will post diagrams and code update as soon as I have it tested in the field

Also spent some time porting it to ESP32 so I can also play with RemoteXY and get some infos as well as configure the multi on the go

 

[megabobra]

@Koekie posted in another thread a while ago a link to a Bosch patent that's pretty interesting. Based on this I started working a while ago on introducing a H-bridge to the MegaBobra cricuit to simulate the behavior of the electromag passing by the sensor (polarity reversing at the middle of the impulse). We can also see that this is indeed what's happening with the original rim magnet (Thanks @Mervious for doing that test/posting the results) :
View attachment 127643
Whereas the MegaBobra as it is would get this :
View attachment 127648
Took me a while as I had some issues with the code for that but finally got something that seems to work as I want it to and now waitiing for some parts to build a live test device, but this is what would now get output to the magnet instead of a square pulse :
View attachment 127645

Will post diagrams and code update as soon as I have it tested in the field

Also spent some time porting it to ESP32 so I can also play with RemoteXY and get some infos as well as configure the multi on the go
View attachment 127647

Awesome work Tatane! Super keen to see how the live device goes.

 

[aegidius]

Good scoping there
There seem to be a few patents around the idea of looking at the waveform of the induced current to determine the wheel circumference (from a known length of magnet). For a spoke magnet and Hall sensor the signal is digital and all you have is the length of the pulse, so that's something that needs to be replicated faithfully in a pulse generator.
I'll keep nosing around those patents, there might be more interesting disclosures to be found. Will post if so.

 

[tatane]

Good scoping there
There seem to be a few patents around the idea of looking at the waveform of the induced current to determine the wheel circumference (from a known length of magnet). For a spoke magnet and Hall sensor the signal is digital and all you have is the length of the pulse, so that's something that needs to be replicated faithfully in a pulse generator.
I'll keep nosing around those patents, there might be more interesting disclosures to be found. Will post if so.

Ideally we'd want a precise measurement of what is seen by the hall sensor at various speed or figure out a formula to output such a pulse and according variations in a truthful manner. Right now I'm using the detected pulse time to try and replicate that (or slow it according to the selected reduction factor), which was a pain to code for Arduino tbh due to most of the function that work really well being blocking ones (delay, while loops ...) and therefore getting the rest of the code to freak out eventually due to not being able to run at the right time to catch a reed sensor input or do other useful stuff
Still not 100% happy with what I got tbh since there's a ~150ms delay where current falls down before being reversed and I'm yet to check if that's the H-bridge I'm using transient response time being that high or my code not being optimized enough ...
Another thing I've been thinking while looking at those graphes again is that it seems like the magnetic field is somehow always higher with the rim magnet then with the bobra, negative levels falling at similar levels to what we see when no current is applied by the bobra device to the magnet. Maybe we could get away with just using pwm there and keeping a small current sent at all times to simulate that field being always present and just somehow "nullified" (or maybe just slightly inverted, wich we could also do with pwm). This would also require some sharper measurements tho which I don't have the hardware for ...
Open to ideas and help there (especially if there's a decent dev around to show me my code mistakes as I'm sure there's a lot lmao)

 

[aegidius]

This one is interesting:
Method and device for checking the plausibility of speed data

Comparison of two speeds recorded by first and second sensing means (where the first is the good old spoke magnet and Hall sensor), possibly averaging or accumulating errors in the comparison, and triggering an error when the accumulated differences exceed a threshold.

They are pretty vague about exactly what the second means should be. They mention an acceleration sensor, or deriving an idea of speed from cadence and pedal torque.

 

[manu.w]

…, which was a pain to code for Arduino tbh due to most of the function that work really well being blocking ones (delay, while loops ...) and therefore getting the rest of the code to freak out eventually due to not being able to run at the right time to catch a reed sensor input or do other useful stuff
…

“Blink without delay”, but I think you know that…

I planned to measure the speed by capturing the reedswitch pulse length! (How long the reedswitch stay closed)
Depending on the magnet orientation (see earlier post) the reedswitch stay closed for a certain amount of time, magnet passes along the reedswitch if you see what I mean, see picture
(And the magnet N-S orientation influences the close time a lot, perpendicular to reedswitch = length of reedswitch, magnet// to reedswitch = +-5cm!)

My setup is still in progress, next week I am on Holliday and I should make some progress.,,

 

[manu.w]

And I think we can just mimic the pulse length as a square wave, that should be enough

This is the signature that I measured with my phone. (If I remember wel it is the one from the electromagnet, n’y the rim magnet...?)
I suppose Bosh is only taking the overall (sum of xyz). I c’ant imagine they capture and analyze each individual magnetic field?….

 

[manu.w]

Here my logic: reduction factor 2 (PulseCount % 2 ), pwm energize the coil on reedswitch isreleased during not more than 2x the original pulse width (if (LoopTime-PWMpulseStart>ReedUpTime*2) {
analogWrite(PWMPIN,0).
High duty for short pulses, low for long pulses (map(ReedUpTime, 555, 0, 40, 255)

  if (ReedUpTime>555) {ReedUpTime=555;}
  if (ReedDownTime>2000) {ReedDownTime=2000;} // 4000*36

  if ( reedswitch.isReleased()) {
    if ((PulseCount % 2 == 0) && (PWMup<=0)) {  // if (x & 0x01)
      PWMpulseStart=LoopTime;
      PWMup=1;
      //map(ReedUpTime, 500, 0, 30, 255);
      PWMpulseDuty = map(ReedUpTime, 555, 0, 40, 255);
      analogWrite(PWMPIN,PWMpulseDuty);
      digitalWrite(LED, HIGH);
    }
    doPrintDebug((String)"Cnt:" + PulseCount + " ReedTime Up/Down/PWMpulseDuty:"+ReedUpTime + "/" + ReedDownTime+"/"+PWMpulseDuty);
    //Serial.println((String)">ReedUpTime:"+ReedUpTime);
    //Serial.println((String)">ReedDownTime:"+ReedDownTime);
  }
//  if (LoopTime-PWMpulseStart>PWMpulseLength*2) {
  if (LoopTime-PWMpulseStart>ReedUpTime*2) {
    analogWrite(PWMPIN,0);
    digitalWrite(LED, LOW);
    PWMup=0;
  }
  if (PulseCount>SAMPLES+1) {
    doPrintDebug((String)"Reset PulseCount:"+PulseCount);
    reedswitch.resetCount();
  }  
  //doPrintDebug((String)">Cnt:"+PWMup);