TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

mrfusi0n said:
So, I'm actually going to take back what I said before. Or, at least, I need to test things out a little more. It appears something was acting up a bit for one of my last rides - torque sensor? I saw "human power" spike to 1000, then 1500, then up to 3000! I never knew I was so strong!
Yes, there seems to be an issue that makes human power to be measured +1000W sometimes. I still don't know what triggers that issue... the solution for now is to power off and power on again the system.
 
Has anyone ever had a motor blocked error triggered by a sudden emergency stop, is that possible?

Now that I think about this, it was most likely a problem with the display attributed to extreme heat as no error code was shown and the display itself didn't seem to function correctly.
 
I noticed the shunt on the controller is a thin piece of metal, if i picked the silicon off the top and stuck a small bit of solder onto it would this be any way beneficial? I'm sure this has been done, I couldn't find anything searching so thought I'd ask here
 
Is anyone using the experimental high cadence mode successfully? With v1.9 no one could get it to operate correctly to my knowledge... Always motor shuddering, especially any power over 200w. Now I see you can pick experimental 36v OR experimental 48v in the motor type under settings in the newest releases. Has the code been modified then? Anyone try it?
 
eyebyesickle said:
Is anyone using the experimental high cadence mode successfully? With v1.9 no one could get it to operate correctly to my knowledge... Always motor shuddering, especially any power over 200w. Now I see you can pick experimental 36v OR experimental 48v in the motor type under settings in the newest releases. Has the code been modified then? Anyone try it?
The code hasn´t been modified. Simple, the 36 and 48V experimental modes were available on previous motor firmware version but the display were only shown one of that modes.
 
casainho said:
eyebyesickle said:
Is anyone using the experimental high cadence mode successfully? With v1.9 no one could get it to operate correctly to my knowledge... Always motor shuddering, especially any power over 200w. Now I see you can pick experimental 36v OR experimental 48v in the motor type under settings in the newest releases. Has the code been modified then? Anyone try it?
The code hasn´t been modified. Simple, the 36 and 48V experimental modes were available on previous motor firmware version but the display were only shown one of that modes.

Previously, it only said 'expert' and did not specify a voltage. Which voltage was it for?

Have these modes been tested yet with the new version? I will try when I can becuase we had no success with previous versions... It always made a very bad sound and little to no power... This feature is the difference in the motor being useable or not for alot of people who have higher cadence/bursts, or live in very hilly areas and have to use low gears and spin faster, or the motor will overheat.
 
eyebyesickle said:
casainho said:
eyebyesickle said:
Is anyone using the experimental high cadence mode successfully? With v1.9 no one could get it to operate correctly to my knowledge... Always motor shuddering, especially any power over 200w. Now I see you can pick experimental 36v OR experimental 48v in the motor type under settings in the newest releases. Has the code been modified then? Anyone try it?
The code hasn´t been modified. Simple, the 36 and 48V experimental modes were available on previous motor firmware version but the display were only shown one of that modes.

Previously, it only said 'expert' and did not specify a voltage. Which voltage was it for?

Have these modes been tested yet with the new version? I will try when I can becuase we had no success with previous versions... It always made a very bad sound and little to no power... This feature is the difference in the motor being useable or not for alot of people who have higher cadence/bursts, or live in very hilly areas and have to use low gears and spin faster, or the motor will overheat.

I am using it on my 2 48 Volt Motors but I'm using version 20. The only difference I can see is that I can pedal up to a max of113 rpm and my arms can pedal a consistent 97 rpm both with power assist, were before with standard 48 the power stopped right at 90 rpm.
 
eyebyesickle said:
Previously, it only said 'expert' and did not specify a voltage. Which voltage was it for?

Have these modes been tested yet with the new version? I will try when I can becuase we had no success with previous versions... It always made a very bad sound and little to no power... This feature is the difference in the motor being useable or not for alot of people who have higher cadence/bursts, or live in very hilly areas and have to use low gears and spin faster, or the motor will overheat.
What I know is that the values on firmware were the ones choosen and tested by Jabalat.
 
casainho said:
eyebyesickle said:
Previously, it only said 'expert' and did not specify a voltage. Which voltage was it for?.....
What I know is that the values on firmware were the ones choosen and tested by Jabalat.
Jbalat has tested the 36V values FOC angle 115 and MOTOR_OVER_SPEED_ERPS 700 for higher cadence the best settings.
maximusdm did tests for 48V and found FOC angle 220 and MOTOR_OVER_SPEED_ERPS 900 values are the best settings.
These last values haven't been added to the later releases, so eventually do this yourself. (motor.c and main.h)
 
Powerhour said:
I noticed the shunt on the controller is a thin piece of metal, if i picked the silicon off the top and stuck a small bit of solder onto it would this be any way beneficial? I'm sure this has been done, I couldn't find anything searching so thought I'd ask here
you can find general info in threads and posts about shunt mod / modding / modifications / soldering / etc.

but basically if the shunt value is not accurate, the controller has no way to protect itself or the motor or the battery from overloading, because it no longer knows what the actual current (or power) is anymore.

if the components are capable of handling the higher (but unknown) currents, then you get a boost out of the system (more power / etc).

but if they're right on the edge, or past it, with the higher currents, stuff fails (usually dramatically), and you get to buy new stuff. ;)
 
amberwolf said:
Powerhour said:
I noticed the shunt on the controller is a thin piece of metal, if i picked the silicon off the top and stuck a small bit of solder onto it would this be any way beneficial? I'm sure this has been done, I couldn't find anything searching so thought I'd ask here
you can find general info in threads and posts about shunt mod / modding / modifications / soldering / etc.

but basically if the shunt value is not accurate, the controller has no way to protect itself or the motor or the battery from overloading, because it no longer knows what the actual current (or power) is anymore.

if the components are capable of handling the higher (but unknown) currents, then you get a boost out of the system (more power / etc).

but if they're right on the edge, or past it, with the higher currents, stuff fails (usually dramatically), and you get to buy new stuff. ;)
Just use our OpenSource firmware were you can configure on the display any value for the battery current and motor phase current. And you will also get a motor with more torque and that uses less battery energy, meaning you can go higher distances with the same battery.
 
casainho said:
amberwolf said:
Powerhour said:
I noticed the shunt on the controller is a thin piece of metal, if i picked the silicon off the top and stuck a small bit of solder onto it would this be any way beneficial? I'm sure this has been done, I couldn't find anything searching so thought I'd ask here
you can find general info in threads and posts about shunt mod / modding / modifications / soldering / etc.

but basically if the shunt value is not accurate, the controller has no way to protect itself or the motor or the battery from overloading, because it no longer knows what the actual current (or power) is anymore.

if the components are capable of handling the higher (but unknown) currents, then you get a boost out of the system (more power / etc).

but if they're right on the edge, or past it, with the higher currents, stuff fails (usually dramatically), and you get to buy new stuff. ;)
Just use our OpenSource firmware were you can configure on the display any value for the battery current and motor phase current. And you will also get a motor with more torque and that uses less battery energy, meaning you can go higher distances with the same battery.

I have a question, if we know what the most efficient setting and vaues are then why not set them there and not make them a just able? Or publish them and give the explanation of how and why? Everyone can take advantage of the most efficient system!
 
jeff.page.rides said:
I have a question, if we know what the most efficient setting and vaues are then why not set them there and not make them a just able? Or publish them and give the explanation of how and why? Everyone can take advantage of the most efficient system!
I don´t understand you question and suggestion.

Our OpenSource firmware is the most efficient possible. Adjusting the battery and motor currents has nothing to do with the firmware being most efficiency possible.

There are a lot of reasons for user want to customize those currents but I should not explain here or I would be repeating and wasting my time, that way not being efficient - there are for sure a lot of information on internet for what reasons that currents can be configured.
 
I really can't figure out how to build the flashing cable.

I have bought a display cable extension, I cut it in half, and I'm using that from the USB-TTL to the display.

I have tried supplying the 30V on the purple cable, or on the orange cable. In any case, the display lights up when long pressing the power button (like you would on the bike.)

I have tried having RXD on the USB dongle connected to the green wire and TXD on the USB to the white wire. I have tried swapping these so the dongle RXD is on the white wire, and TXD on the green.

In every combination, the display turns on when I long press. But when I connect it to the Windows software and short press power to flash, nothing happens at all. The software keeps trying, and nothing ever gets flashed.

It's driving me nuts. What is the issue here?

bi9Adws.jpg
 
Yea it won't work without the groundpin connected, I overlooked that at first as well, when I flashed mine
 
Powerhour said:
Yea it won't work without the groundpin connected, I overlooked that at first as well, when I flashed mine

So GND in the usb is connected both to the power booster minus and to the black wire in the connector?
 
skestans said:
Powerhour said:
Yea it won't work without the groundpin connected, I overlooked that at first as well, when I flashed mine

So GND in the usb is connected both to the power booster minus and to the black wire in the connector?

YES
 
jeff.page.rides said:
casainho said:
amberwolf said:
Powerhour said:
I noticed the shunt on the controller is a thin piece of metal, if i picked the silicon off the top and stuck a small bit of solder onto it would this be any way beneficial? I'm sure this has been done, I couldn't find anything searching so thought I'd ask here
you can find general info in threads and posts about shunt mod / modding / modifications / soldering / etc.

but basically if the shunt value is not accurate, the controller has no way to protect itself or the motor or the battery from overloading, because it no longer knows what the actual current (or power) is anymore.

if the components are capable of handling the higher (but unknown) currents, then you get a boost out of the system (more power / etc).

but if they're right on the edge, or past it, with the higher currents, stuff fails (usually dramatically), and you get to buy new stuff. ;)

Good answer! Haha thanks. (I kinda already knew the truth as well..) but also the truth is with my first one I 'teched it till I wrecked it' got this one, and the first thing I did was rip it open to modify/upgrade it, and before even thinking about it I beefed up the shunt and then repotted the hell out of it..like it was second nature something, ugh. Jesus. If I measured the new shunt value is there anyway to enter it somehow? Or is the math just going to have to all be screwed up now?
Thanks
 
bikelpl said:
skestans said:
Powerhour said:
Yea it won't work without the groundpin connected, I overlooked that at first as well, when I flashed mine

So GND in the usb is connected both to the power booster minus and to the black wire in the connector?

YES

Yeah, I totally missed that one after using an external power supply... and didn’t rewire GND. Thanks, for it working now.
 
casainho said:
jeff.page.rides said:
I have a question, if we know what the most efficient setting and values are then why not set them there and not make them a just able? Or publish them and give an explanation of how and why? Everyone can take advantage of the most efficient system!
I don´t understand you question and suggestion.

Our OpenSource firmware is the most efficient possible. Adjusting the battery and motor currents has nothing to do with the firmware being most efficiency possible.

There are a lot of reasons for user want to customize those currents but I should not explain here or I would be repeating and wasting my time, that way not being efficient - there are for sure a lot of information on internet for what reasons that currents can be configured.

Sorry, I will try again to ask the question. If we know what the most efficient setting and values possible are then why not set them there and not make them adjustable? Or publish them and give an explanation of how and why we should set them at what they should be at to be at the most efficient levels? Everyone can take advantage of the most efficient system!
 
jeff.page.rides said:
Sorry, I will try again to ask the question. If we know what the most efficient setting and values possible are then why not set them there and not make them adjustable? Or publish them and give an explanation of how and why we should set them at what they should be at to be at the most efficient levels? Everyone can take advantage of the most efficient system!
There are no settings for "most efficient". The settings are mainly for adjust specifics of each ebike and user preferences, like for instance, configure which battery voltage (specific for each ebike) and motor current ramp value (user preference, like when my son had 8 years old, I did configure a low motor current ramp value since he was very small and light so could be dangerous a fast acceleration of the ebike).
 
Powerhour said:
If I measured the new shunt value is there anyway to enter it somehow? Or is the math just going to have to all be screwed up now?

you can certainly measure it, but i have no idea what this firmware has for options--you'll have to look that up in the documentation. (i don't have any of these systems that any of the osfw can be used on...i just pop in various threads whenever i see questions i can answer ;) ).
 
Hi all,
I don't know if it's of any interest, but I had a look at the source and the source of uGUI and noticed that the 850C has hardware accelerated block filling. So I modified the uGUI filled circle function to use that to fill the center of the circle. I haven't got a 850C to test with so not sure if there's any real speed benefits, but if someone would be interested in spiffing up the looks of the display a bit, say with a circular speedo, please try it out.

It might be possible to gain a few cycles by calling the hardware drivers directly, bypassing uGUI's wrapper. Also since there's only completely horizontal or vertical line drawing, the UG_FillFrame might be faster than the UG_DrawLine.

Code:
        void FillCircle(UG_S16 x0, UG_S16 y0, UG_S16 r, UG_COLOR c)
        {
            UG_S16 x,y,xd,yd,e;
			
	    xd = 1 - (r << 1);
            yd = 0;
            e = 0;
            x = r;
            y = 0;

            while (x >= y)
            {
                UG_DrawLine(x0 - x, y0 - y, x0 - x, y0 + y, c);
                UG_DrawLine(x0 + x, y0 - y, x0 + x, y0 + y, c);
                UG_DrawLine(x0 - y, y0 - x, x0 + y, y0 - x, c);
                UG_DrawLine(x0 - y, y0 + x, x0 + y, y0 + x, c);

                y++;
                e += yd;
                yd += 2;

                if (((e << 1) + xd) > 0)
                {
                    x--;
                    e += xd;
                    xd += 2;
                }
            }
            UG_FillFrame(x0 - x, y0 - y, x0 + x, y0 + y, c);
        }
 
ancan said:
Hi all,
I don't know if it's of any interest,
Make a pull request on github.
 
Back
Top