There are some bugs on the 0.19.0 beta 6. Such as the new button logic. Am still waiting for it to be resolved by j0bro as I wish not to interfere with his development and mess something up. As soon as he solves that I will test the Cruise function as promised to thineight. Will have more time for development in a couple of days and if not resolved by then I will see if I can help. As well with the other bugs in the motor controller firmware.
TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
- Thread starter casainho
- Start date
Thanks Buba.
I'm currently with the beta5 after the unsuccessful try of the beta6.
I set up the 1st assistance level to 0.1, and I noticed that the motor does not kicks in for a little while, until I reach about 100w of human power (motor gives 10w). I conclude that the minimum power unit from the motor is 10w, correct?
Can this be reduced to, say, 5w? This would result in quicker response from the motor at low assistance levels.
Thanks!!
I'm currently with the beta5 after the unsuccessful try of the beta6.
I set up the 1st assistance level to 0.1, and I noticed that the motor does not kicks in for a little while, until I reach about 100w of human power (motor gives 10w). I conclude that the minimum power unit from the motor is 10w, correct?
Can this be reduced to, say, 5w? This would result in quicker response from the motor at low assistance levels.
Thanks!!
Hi. I dont quite understand how boost works exactly in code or more specifically in what units boost level is measured (should be same factor as assist level?).
As I understand assist level is stored x10 value multiplied by pedal power x10 value or pedal torque x10 value (if no cadence rpm) and then divided by 100.
On other hand boost level is also multiplied by pedal torque x10 value but then divided only by 10.
Does this mean boost level is not stored x10 value (seems like it is though according to LCD UART communication protocol) or it is intended behavior to multiply by x28 not by x2.8 (for instance for default boost level 9)?
Or I am missing something? Sorry for bothering, thanks in advance.
UPDATE:
After some tinkering with code I can guess boost level is intentionally x10 times more then assist level because it is using pedal torque instead of pedal power.
In that case shouldnt be assist level also only divided by 10 in case of no cadence rpm and motor assistance startup without pedal rotation flag set? (lines 234-235 at ebike_app.c).
Unless it is intended as well to give x10 times less assist when no cadence?
So for instance with torque value 10 (not sure what actual values) and cadence 100 and factor of 1 -
boost will give 100W, assist from pedal power 66W, and assist from torque 10W? Is this correct?
Sorry again for long posts, just trying to get my head around it.
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/blob/e0a72cd83fc915532314ff53a19cb9d2eb0178c1/src/controller/ebike_app.c#L196-L249
As I understand assist level is stored x10 value multiplied by pedal power x10 value or pedal torque x10 value (if no cadence rpm) and then divided by 100.
On other hand boost level is also multiplied by pedal torque x10 value but then divided only by 10.
Does this mean boost level is not stored x10 value (seems like it is though according to LCD UART communication protocol) or it is intended behavior to multiply by x28 not by x2.8 (for instance for default boost level 9)?
Or I am missing something? Sorry for bothering, thanks in advance.
UPDATE:
After some tinkering with code I can guess boost level is intentionally x10 times more then assist level because it is using pedal torque instead of pedal power.
In that case shouldnt be assist level also only divided by 10 in case of no cadence rpm and motor assistance startup without pedal rotation flag set? (lines 234-235 at ebike_app.c).
Unless it is intended as well to give x10 times less assist when no cadence?
So for instance with torque value 10 (not sure what actual values) and cadence 100 and factor of 1 -
boost will give 100W, assist from pedal power 66W, and assist from torque 10W? Is this correct?
Sorry again for long posts, just trying to get my head around it.
Code:
// controller works with no less than 15V so calculate the target current only for higher voltages
if(ui16_battery_voltage_filtered > 15)
{
// 1.6 = 1 / 0.625 (each adc step for current)
// 25 * 1.6 = 40
// 40 * 4 = 160
if(m_configuration_variables.ui8_startup_motor_power_boost_assist_level > 0)
{
ui32_temp = (uint32_t) ui16_pedal_torque_x10 * (uint32_t) m_configuration_variables.ui8_startup_motor_power_boost_assist_level;
ui32_temp /= 10;
// 1.6 = 1 / 0.625 (each adc step for current)
// 1.6 * 8 = ~13
ui32_temp = (ui32_temp * 13) / ((uint32_t) ui16_battery_voltage_filtered);
ui8_adc_max_battery_current_boost_state = ui32_temp >> 3;
ui8_limit_max(&ui8_adc_max_battery_current_boost_state, 255);
}
else
{
// nothing
}
if(m_configuration_variables.ui8_assist_level_factor_x10 > 0)
{
if(m_configuration_variables.ui8_motor_assistance_startup_without_pedal_rotation == 0)
{
ui32_temp = (uint32_t) ui16_pedal_power_x10 * (uint32_t) m_configuration_variables.ui8_assist_level_factor_x10;
ui32_temp /= 100;
}
else
{
if(ui8_pas_cadence_rpm)
{
ui32_temp = (uint32_t) ui16_pedal_power_x10 * (uint32_t) m_configuration_variables.ui8_assist_level_factor_x10;
ui32_temp /= 100;
}
else
{
ui32_temp = (uint32_t) ui16_pedal_torque_x10 * (uint32_t) m_configuration_variables.ui8_assist_level_factor_x10;
ui32_temp /= 100;
}
}
// 1.6 = 1 / 0.625 (each adc step for current)
// 1.6 * 8 = ~13
ui32_temp = (ui32_temp * 13) / ((uint32_t) ui16_battery_voltage_filtered);
ui8_adc_max_battery_current = ui32_temp >> 3;
ui8_limit_max(&ui8_adc_max_battery_current, 255);
ui8_m_adc_battery_target_current = ui8_adc_max_battery_current;
}
else
{
// nothing
}cnrd said:
Hello cnrd,
I don't know where else to order this 1 to 4 female cable. In the past I ordered some cables from: https://www.e-bike-technologies.de/...rbinder-signal/steckverbinder-higo-z812-serie
and soldered it together except the brakes but still have to do that
Here some info and pictures about the wiring and soldering : https://endless-sphere.com/forums/viewtopic.php?f=28&t=79788&hilit=bart1006&start=3300#p1406309
varga.d said:
If you go here
https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2programmingfromscratch
You can re configure your motor controler fimware to change the battery voltage and max amps. Its very simple to do.
I used this method to use a 48v battery on a 36v motor.
Then i moved on and got a kt lcd3 and the open source firmware wich makes things even better.
perryscope
100 W
- Joined
- Jan 6, 2019
- Messages
- 122
casainho said:
Thanks Casainho for your comments on this. Sorry for the delay in my reply. I have had to wait a little while to get the trike back from its inital testing. The rider is getting a bit more used to it but has noticed the hunting issue remains.
I think this issue actually appears to relate more to a low cadence rather than the uneven torque applied. anything under 30rpm and the motor is cutting out quite quickly. Is there a Low limit on the cadence value for any assist?
I swapped back to a stock setup when testing and there does not appear to be such a distinct cut off at low cadence. I would say its closer to 20rpm but even then its a slower drop in power if torque is applied.
I am wondering if this is the underlying issue?
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
So, I asked that questions because could be that original firmware does things in a different way.perryscope said:
On our firmware, we sample the torque signal and calculate new motor current value every 100ms. This means 10 times a second. For like the 30 RPM as you say, that means 30/60 = 0.5 -- half rotation of pedals. Means that after 30 RPM the torque signal starts to be averaged and the system can't see the fast changes on it... maybe original firmware uses lower sample time like 200 or 250ms, so it may not detect very well the fast changes on torque signal.
I think an ideal solution would be to have like an assist level for each crank/leg. For that, the hardware would need to detect the start of each crank side rotation and TSDZ2 does not do that. Maybe adding an extra cheap ebike PAS sensor and 1 magnet to detect start of one side and then count the TSDZ2 PAS pulses to detect the start of other side. I think there are available 2 digital lines on TSDZ2 controller, enough for like 2 PAS but in this case just one would be needed.
But there is the issue of that high pass filtering, as cadence increases, the assist level for both legs/cranks tend to be equal... so maybe a linear function that reduces the difference between each legs assist levels over the increase of pedal cadence.
I think this way user would feel that system real feels and reacts to his different legs force and that should be a powerful sensation. I can't forget the senstation I had when learning and then driving the electric unicycles, when the electric unicycle detects and reacts to very small and fast changes in my body, letting the system accelerate or brake when I lean my body forward or backward!!! I want to do this on my future "eLegs / Exoskeleton", I want the eLegs to quickly react to my body/muscles micro motion and do it differently for each leg, as I may have some limitations on a specific leg like a limitation on a knee and that will not let me make the same force as the other leg.
perryscope
100 W
- Joined
- Jan 6, 2019
- Messages
- 122
buba said:
Thanks or your coments Buba
I have actually managed to get sdcc working correctly now under windows 10 which is great!. For some reason the 32bit version would not compile on my windows 10 32bit install, but i swapped to another pc with window10 pro 64bit and used sdcc-3.8.0-x64-setup.exe specifically i had issue with later versions of sdcc.
I can compile v0.18.2 release without error and i have been testing the resulting hex files. I am having issues compiling 0.19.6 beta. this might be due to changes in the src. Unfortunatly throttle support does not appear to be working in the 0.19.x betas so i am testing with 0.18.2 for now.
I would be very interested in a PAS option. As you say this may interest other people if they have issues with the torque sensor or simple prefer the response of PAS.
One of my next projects is a electric assisted hand trike and this may also not play well with torque control due to the cranks being in line not offset by 180 degrees and PAS is likly a better option.
perryscope
100 W
- Joined
- Jan 6, 2019
- Messages
- 122
I guess one way to test this would be to move the Speed Sensor to the downtube and put a magnet on one crank ,in effect like a cadence sensor setup. You then know the top position for each rotation, of cource it would sacrifice wheel speed for this test but it would not require and physical changes to the controller board initially to tap into any additional digital I/O pins.
I was wondering if it was possible to the crank position and workout which pedal was being pushed for the half stroke, but as you confirmed that this would require additional hardware to detect the position there are no built in sensors that know the position only the sped of rotation of the crank.
However I did wonder if you actually need to know which crank was being pushed left or right, or rather simply detect which torque curve related to a specific crank crank A or Crank B?
If you compare the cadence with the peak values of torque could you match a peak torque value to a specific crank?
For example lets call them Crank A and Crank B if you know how quick the cranks are rotating and you measure the peak value at the top of each curve you see you would know the rough time window to expect the next curve based on the cadence, so you could relate each torque curve reading to either Crank A or Crank B. Granted you don't know if crank A is left or right, but do you need to actually know that?
If you know that the last crank A peak values are say 20% of crank B, you could add a gain to crank A value in the future to match A? in effect dynamically calculating the mismatch of power between cranks? a floating dynamic gain factor?
I may be over simplifying things
And I want to know more about your 'eLegs / Exoskeleton' project that sounds amazing!
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
I think is a good idea to use the speed sensor for a prof of concept.perryscope said:I guess one way to test this would be to move the Speed Sensor to the downtube and put a magnet on one crank ,in effect like a cadence sensor setup. You then know the top position for each rotation, of cource it would sacrifice wheel speed for this test but it would not require and physical changes to the controller board initially to tap into any additional digital I/O pins.
I was wondering if it was possible to the crank position and workout which pedal was being pushed for the half stroke, but as you confirmed that this would require additional hardware to detect the position there are no built in sensors that know the position only the sped of rotation of the crank.
However I did wonder if you actually need to know which crank was being pushed left or right, or rather simply detect which torque curve related to a specific crank crank A or Crank B?
If you compare the cadence with the peak values of torque could you match a peak torque value to a specific crank?
For example lets call them Crank A and Crank B if you know how quick the cranks are rotating and you measure the peak value at the top of each curve you see you would know the rough time window to expect the next curve based on the cadence, so you could relate each torque curve reading to either Crank A or Crank B. Granted you don't know if crank A is left or right, but do you need to actually know that?
If you know that the last crank A peak values are say 20% of crank B, you could add a gain to crank A value in the future to match A? in effect dynamically calculating the mismatch of power between cranks? a floating dynamic gain factor?
I may be over simplifying things
And I want to know more about your 'eLegs / Exoskeleton' project that sounds amazing!
I also think it is easier to use hardware than try to rely on software filter/algorithms that are hard to debug.
Adding the sensor, I would send 2 variables to LCD3 to debug/validate: crank side: 0 to left and 1 to right; number of PAS pulses for each side: 0 to 20 as 1 cadence = 40 pulses on TSDZ2 PAS (I think).
After having crank_side variable working, would be a matter to multiply the correct assist_level_left or assist_level_right. Finally, add the linear ramp to converge assist_level_left and assist_level_right to same value as pedal cadence value increases.
eLegs project is something that may take at least 5 years. Right now exoskeleton technology is mainly on military industry, you see, the Chinese do not sell them(yet!!) (the hardware) for final users like us, like they do on ebike DIY kits. If I have eLegs in 5, 10 or 15 years, will be great as I will be older and I will value much more of what I value I do now!!
Dirkro
10 W
Hi,
Regarding Blinking 1,
I see the use of it , but also feel the problem in traffic light, or when you just stop and talk with friends,
My saddle is quite high, so my foot is restng on the pedal when I stop.
I am wondering if it is possible to
- have a threshhold for torque before it reacts So it can be possible to rest the foot on the pedal (Value 12.3 50 may a good starting point)
- maybe have rhe timeout at 10 s and the cominng back 2 s?
Should I ask for it in Github?
Regarding Blinking 1,
I see the use of it , but also feel the problem in traffic light, or when you just stop and talk with friends,
My saddle is quite high, so my foot is restng on the pedal when I stop.
I am wondering if it is possible to
- have a threshhold for torque before it reacts So it can be possible to rest the foot on the pedal (Value 12.3 50 may a good starting point)
- maybe have rhe timeout at 10 s and the cominng back 2 s?
Should I ask for it in Github?
Thanks for the reply! What kind of 36V motor do you suggest (250w, 350w or 500w) considering that I will lose torque (due to switching to a 48v battery)?
Do you have any idea, of witch (...Ah) 48V battery would fit for me (normal urban usage, 50-60km)?
Do you have any idea, of witch (...Ah) 48V battery would fit for me (normal urban usage, 50-60km)?
la8rat said:
varga.d said:
As btslo already said there are no different versions of the 36 volt motor and the motor controller. Even though they sell them at different power levels.
See Casainho´s wiki: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/FAQ
But regarding the torque with a higher voltage battery: the torque does not decrease with a higher voltage. It will increase. There are several upsides with using the 36 volt motor and a higher source voltage. Simply put, you will get a more powerful and faster motor.
The torque is proportional to the current. With a higher voltage we get higher currents. With higher currents we get more torque. More torque with the same or higher rotational speed will equal more power.
elem
100 W
if torque is proportional to current, using highter voltage don t give more torque .
often if you use highter voltage, current decrease for same power ( than with less voltage ) .
i m using 12S batt with a 36v motor, but i have not noticed highter cadence ( may be it s necessary to active experimental cadence ) .
using highter voltage is usefull for getting less current and preserve motor ( less current mean less temp )
often if you use highter voltage, current decrease for same power ( than with less voltage ) .
i m using 12S batt with a 36v motor, but i have not noticed highter cadence ( may be it s necessary to active experimental cadence ) .
using highter voltage is usefull for getting less current and preserve motor ( less current mean less temp )
Good morning.
Any news about the v0.19? We had beta6 with some bugs fixed but configuration issues due to the new menu logic.
Can we temporarily leave aside the menu logic (if the author is not currently available) and compile a beta7 with the issues already sorted in beta6 in place?
Question for the developers: in case I compile the code myself under Windows, is the resulting .ihx equivalent to the .hex normally distributed? Can this be uploaded to the motor the same way as .hex?
Thanks! :thumb:
Any news about the v0.19? We had beta6 with some bugs fixed but configuration issues due to the new menu logic.
Can we temporarily leave aside the menu logic (if the author is not currently available) and compile a beta7 with the issues already sorted in beta6 in place?
Question for the developers: in case I compile the code myself under Windows, is the resulting .ihx equivalent to the .hex normally distributed? Can this be uploaded to the motor the same way as .hex?
Thanks! :thumb:
elem said:
What I tried to explain was that the torque would not decrease with a higher voltage battery. It could only increase. It being limited by the TSDZ2 controller to the same current regardless battery is something entirely different. The TSDZ2 current limit will effectively set the maximum torque to be the same regardless of battery. But the motor can and does give more torque with higher voltages. The no-load-speed increases and at higher speeds more current flows compared to lower battery voltages => faster bike.
elem said:
Completely true and this is always the case for the same power level.
elem said:
Whenever I have tried the 36 volt motor I always feel it is the better one. Mainly due to the higher speeds available :wink:
elem said:
That is a very good point I forgot to mention! Thanks for adding to the discussion!
thineight said:
Morning! Think there will be a new beta 7 with fixes.
Am not sure if you can use the .ihx directly with ST Visual Programmer but the resulting main.ihx is the equivalent to the .hex that is normally distributed. If you want you can convert it to a .hex with packihx.
------------------------------------------
* When you have built the source code, put the main.ihx in a directory, for instance the desktop
* Open the terminal and the type cd desktop
* Then type packihx main.ihx > SOME_NAME.hex, replace SOME_NAME with whatever you want
* You will now have a SOME_NAME.hex in the desktop or whatever directory you are working in
------------------------------------------
Good luck!
perryscope
100 W
- Joined
- Jan 6, 2019
- Messages
- 122
buba said:
Interesting I have been using the release.bat batch file from within the src code zip files here https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases to compile the display and controller source into .ihx files and the batch file it simply copied them into .HEX fires using a simple file copy and rename, so the resulting files were smaller than the released .HEX files. that explains things!
I updated my release.bat file so changed the lines...
COPY .\src\controller\main.ihx %release_folder%\TSDZ2-v%new_version%.hex
to ...
packihx .\src\controller\main.ihx > %release_folder%\TSDZ2-v%new_version%.hex
and
COPY .\src\display\KT-LCD3\main.ihx %release_folder%\KT-LCD3-v%new_version%.hex
packihx .\src\display\KT-LCD3\main.ihx > %release_folder%\KT-LCD3-v%new_version%.hex
Now they are converted using packihx and are the correct size.
Do you think the release.bat file should do this, or does it really not matter?
Like I say the existing smaller ihx files renamed to .hex files flashed fine using ST Visual Programmer
Hi buba,
i have one request for next release(s) which i find interesting for all users - trial/emtb mode like on bikes with brose or bosch motors. It is described here:
https://ebike-mtb.com/en/emtb-mode-bosch-cx-review/
To use trial mode user needs to set assist to factor >10 on one of assist levels and in the code on motor controller side it will look like this
if(m_configuration_variables.ui8_assist_level_factor_x10 > 9) then ->trial mode where
ui16_pedal_power_x10 <10% -> ui8_assist_level_factor_x10 = 0.3
10% < ui16_pedal_power_x10 <15% -> ui8_assist_level_factor_x10 = 0.5
15% < ui16_pedal_power_x10 <20% -> ui8_assist_level_factor_x10 = 0.7
and so on
This way this mode can be set up freely under one of assist level from 1-9 and final setup could looks like this:
assist level 1 - eco mode- let's say factor 0.3 for assistance,
than assist level 2 - trial where assistance depends on pedal power and varies between 0.3-3.2x
and assist level 3 - boost mode - 3.0x,
assist level 4 - 3.5x
and so on
For brose motors assistance in trial mode looks like on the screen (Eingabe - torque/pedal power and Leistung - % of motor assistance level which is our power motor factor )
In every review of bikes with this motor one of best thing that is always mentioned is the ride feeling that is very smooth and natural in this mode So having this feature make our bikes closer to this 5000 USD and up machines
i have one request for next release(s) which i find interesting for all users - trial/emtb mode like on bikes with brose or bosch motors. It is described here:
https://ebike-mtb.com/en/emtb-mode-bosch-cx-review/
To use trial mode user needs to set assist to factor >10 on one of assist levels and in the code on motor controller side it will look like this
if(m_configuration_variables.ui8_assist_level_factor_x10 > 9) then ->trial mode where
ui16_pedal_power_x10 <10% -> ui8_assist_level_factor_x10 = 0.3
10% < ui16_pedal_power_x10 <15% -> ui8_assist_level_factor_x10 = 0.5
15% < ui16_pedal_power_x10 <20% -> ui8_assist_level_factor_x10 = 0.7
and so on
This way this mode can be set up freely under one of assist level from 1-9 and final setup could looks like this:
assist level 1 - eco mode- let's say factor 0.3 for assistance,
than assist level 2 - trial where assistance depends on pedal power and varies between 0.3-3.2x
and assist level 3 - boost mode - 3.0x,
assist level 4 - 3.5x
and so on
For brose motors assistance in trial mode looks like on the screen (Eingabe - torque/pedal power and Leistung - % of motor assistance level which is our power motor factor )
In every review of bikes with this motor one of best thing that is always mentioned is the ride feeling that is very smooth and natural in this mode So having this feature make our bikes closer to this 5000 USD and up machines
Attachments
bart594 said:Hi buba,
i have one request for next release(s) which i find interesting for all users - trial/emtb mode like on bikes with brose or bosch motors. It is described here:
https://ebike-mtb.com/en/emtb-mode-bosch-cx-review/
To use trial mode user needs to set assist to factor >10 on one of assist levels and in the code on motor controller side it will look like this
if(m_configuration_variables.ui8_assist_level_factor_x10 > 9) then ->trial mode where
ui16_pedal_power_x10 <10% -> ui8_assist_level_factor_x10 = 0.3
10% < ui16_pedal_power_x10 <15% -> ui8_assist_level_factor_x10 = 0.5
15% < ui16_pedal_power_x10 <20% -> ui8_assist_level_factor_x10 = 0.7
and so on
This way this mode can be set up freely under one of assist level from 1-9 and final setup could looks like this:
assist level 1 - eco mode- let's say factor 0.3 for assistance,
than assist level 2 - trial where assistance depends on pedal power and varies between 0.3-3.2x
and assist level 3 - boost mode - 3.0x,
assist level 4 - 3.5x
and so on
For brose motors assistance in trial mode looks like on the screen (Eingabe - torque/pedal power and Leistung - % of motor assistance level which is our power motor factor )
In every review of bikes with this motor one of best thing that is always mentioned is the ride feeling that is very smooth and natural in this mode So having this feature make our bikes closer to this 5000 USD and up machines
Could be an interesting feature, see what the gurus say about spare memory of the controller.
Reading the article I conclude that this mode is helpful to save battery for whose using constantly the turbo mode, whereas the others would expect less battery duration.
Moreover during a climb the human power would result in a constant turbo assistance anyway...
I just want to ask you if you really manage to work with those assistance levels in v0.19 betas, as I get quite strong assistance even at lower percentage (compared to v.18.
I had to set the following assistance for my riding style: 0.1/0.2/0.4/0.7/1.2 for my 36v motor.
Dirkro
10 W
elfnino said:Dirkro said:
Can you please explain what is the practical use of the “Blinking 1” ? Is there a nonstop re-calibration ongoing which needs it ? To me is the most annoying feature of v19
As I understand it, it is a safty feature for-
-Saving the blue gear , specaly on high volltage , one may damage the gear when standing on the pedal and holding the bike with the brakes
- when you have a crash, and a pedal may hang somewhere and the motor is pushing against this hanging pedal, a driver in between .
right?
Both issues would be solved with a solution above in my opinion.
For my setup with a relative weak 36V batterie , I cannot see the use of this feature.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Yes, that feature is to protect against possible unintentional locking of the pedals.Dirkro said:elfnino said:Dirkro said:
Can you please explain what is the practical use of the “Blinking 1” ? Is there a nonstop re-calibration ongoing which needs it ? To me is the most annoying feature of v19
As I understand it, it is a safty feature for-
-Saving the blue gear , specaly on high volltage , one may damage the gear when standing on the pedal and holding the bike with the brakes
- when you have a crash, and a pedal may hang somewhere and the motor is pushing against this hanging pedal, a driver in between .
right?
Both issues would be solved with a solution above in my opinion.
For my setup with a relative weak 36V batterie , I cannot see the use of this feature.
The feature was working well before but on last beta version has an issue. For the ones that can't live with this issue, please use the latest stable version until this is corrected.
Similar threads
