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

[plasmdude]

My bike was down for the last month after I blew the motor/controller. In the meantime I was riding my beast of a Cyclone 3000w. While that rig is fun, its not exactly reliable and likes to eat chainrings/chains for breakfast. I rebuilt my bike with new controller/motor/blue cog/860c/hydraulic breaks/chainring/wide range cassette/fresh mobile28 grease/thermal pad/thermal grease/temp sensor/bootloader hack for 860c.

After the suggestion casainho, I pushed my magnet / speed sensor down to the end of the spoke. That made all the difference, my bike is back in action. Still running the 1.0beta might try reverting to the 0.8.

Today mounted an assault on my favored mountain and all went great! It was nice to see the temp graph

Next plans:
- Try out the 0.8 version
- Calibrate the torque sensors
- My Cyclone bike need a solid overhaul its taken some abuse and been putting it off while rebuilding my tsdz bike.
- I have a second tsdz that is stock on my wife's bike. I am also planning on upgrading it with the osf and SW102.

 

[Geekb0rg]

Hi, I just found out that there is a TSDZ2 engine sold with a 850C screen.

Would it be possible that this motor uses the opensource firmware?

https://a.aliexpress.com/_d8Dvk6v

 

[Benoit]

Hi everyone !

I'm new here, but I'm reading your messages since a few weeks.
I just received my TSD2Z2 motor kit + battery + 860C display and I installed it on my old bike, temporarely. I have to buy an other bike now as the actual must have 20+ years and I'm 34, so it's way too small for me now :lol:

I already installed your firmware (last version : V1.0.0-beta.1) and this is awesome. It works flawlessly ! @casainho : you did an amazing job really !! 8) :thumb:

Maybe I can help you on the firmware developpment as I'm a developper, web developper to be precise, but I hope I'll can help you soon if you need it.
I saw you're talking about a ANT+ BLE project (I saw you did create a new thread), I'll see what I can do about it as I'm finding that project very interesting !

Anymore, I have a question. I read a few pages of this thread and the wiki but I didn't find the answer.
In the configuration menu, there is now an option named "Motor control" with choice between "torque" and "power".
What is the difference ? I'm not sure to undestand and the wiki "Features and configurations on display" does not yet mention it.
Is this to set how is calculated the current applied to the motor based on the human power ?
Or is it to calculate the torque ("torque mode") OR the power ("power mode") that the motor should deliver ?

Thanks !

 

[casainho]

I already installed your firmware (last version : V1.0.0-beta.1) and this is awesome. It works flawlessly ! @casainho : you did an amazing job really !! 8) :thumb:

Maybe I can help you on the firmware developpment as I'm a developper, web developper to be precise, but I hope I'll can help you soon if you need it.
I saw you're talking about a ANT+ BLE project (I saw you did create a new thread), I'll see what I can do about it as I'm finding that project very interesting !

Anymore, I have a question. I read a few pages of this thread and the wiki but I didn't find the answer.
In the configuration menu, there is now an option named "Motor control" with choice between "torque" and "power".
What is the difference ? I'm not sure to undestand and the wiki "Features and configurations on display" does not yet mention it.
Is this to set how is calculated the current applied to the motor based on the human power ?
Or is it to calculate the torque ("torque mode") OR the power ("power mode") that the motor should deliver ?

Maybe you can help on current display firmware. There things that need to be polished. Use it and then we can discuss here things you wish to improve and then you can make a pull request.

Torque mode uses only the torque measured on the pedals. The motor current is then pedals torque * assist level factor.

 

[Benoit]

Maybe you can help on current display firmware. There things that need to be polished. Use it and then we can discuss here things you wish to improve and then you can make a pull request.

Torque mode uses only the torque measured on the pedals. The motor current is then pedals torque * assist level factor.

Thanks for the reply ! For you, what is the better between torque and power mode ? I'll try it to feel the difference but you already have experience about the feeling it give.

What have to be polished ? I'll pay particurarly attention of thoose things on my future rides to see how I'll wish/can improve it.

As I'm french (sorry for my english by the way) I thought I could translate all the menus but I'm not sure it'll interest lot of people except me.

 

[James Broadhurst]

..... sold with a 850C screen

Not long ago I asked these people why buying from them meant that I’d have to ride around displaying their tree hugging “GREENPEDAL” logo. I declined their offer of getting rid of it if I bought enough of them.

 

[raw]

Maybe you can help on current display firmware. There things that need to be polished. Use it and then we can discuss here things you wish to improve and then you can make a pull request.

Torque mode uses only the torque measured on the pedals. The motor current is then pedals torque * assist level factor.

...
As I'm french (sorry for my english by the way) I thought I could translate all the menus but I'm not sure it'll interest lot of people except me.

adding translations is a nice to have, but it think it will also make things more complicated. there is not much point in translating the configuration menu because then the wiki (at least the configurations page) has to be translated too and should use the same terms as the translation. so the bike-builder that does the configuration needs to work in english now.

translating the home screen would be nice, because the end user may like it in his native language, i.e. if you are building bikes for your friends and families that do not mess with the configuration and just ride the bike.

while working with the Color_LCD firmware i noticed that

• it is pretty inconsistent in its code style, intents are made with tabs and spaces, the opening brace is sometimes on the same line as the if, sometimes on the next and so on. a official coding style would be nice.
• documenting comments are there (and very useful!), but mainly specific to some code lines. what lacks are documentation comments for functions (why are they here, what should they do). i noticed this especially in the screen.c while trying to figure out how the rendering works.
• i was also missing a toplevel developer documentation that explains some principles how everything works to allow a quicker start into the code.
• more important: an documentation for the UART protocol used would be nice (=> what each bit does). when developing for the display, you will currently need to read the motors sourcecode to get an idea what something does, which is also time consuming. this will especially useful for the TSDZ2 wireless project, as it would make maintaining the wireless firmware and android app more easy.

also, i develop on windows using the linux subsystem for windows for compiling. i did not plan to force-open the 860c so for flashing/testing i only have the windows bootloader software. i have tried compiling it native with windows, but was not able to get it to work without investing more time. so my workflow is: think hard about what the sourcecode does, make your changes, compile them with the subsystem, flash it with the windows bootloader app and look if it is working. if not start from the beginning. is there a better way?

is there an easy way to get some "debug console" like output on the display? so i.e. i can print some text when a specific part is reached?

also i noticed that the firmware goes into dev-mode when the voltage is below 14v. The wiki causes the impression that for flashing the display using the bootloader box a voltage of at least 27v is requied which not the case. i think it should be clarified, but i do not know what the actual recommended minimum voltage is.

 

[Geekb0rg]

..... sold with a 850C screen

Not long ago I asked these people why buying from them meant that I’d have to ride around displaying their tree hugging “GREENPEDAL” logo. I declined their offer of getting rid of it if I bought enough of them.

It's totally irrelevant.

I was just wondering what kind of firmware is used in their screen/motor.

 

[rcx194]

Can I ask, will a TSDZ2 48v motor with the open source firmware run ok on a 36v battery?

 

[vshitikov]

Can I ask, will a TSDZ2 48v motor with the open source firmware run ok on a 36v battery?

The opposite would work fine but 48 motor on the 36V battery will turn not give you enough power.
If you have a 48v motor you can keep original controller and buy a bare motor from aliexpress and swap it inside keeping original controller in place. But I guess it will cost almost as much as buying a new battery ~300$.

 

[vshitikov]

Can I ask, will a TSDZ2 48v motor with the open source firmware run ok on a 36v battery?

The opposite would work fine but 48 motor on the 36V battery will not give you enough power.
If you have a 48v motor you can keep original controller and buy a bare motor from aliexpress and swap it inside keeping original controller in place. But I guess it will cost almost as much as buying a new battery ~300$.

 

[casainho]

Can I ask, will a TSDZ2 48v motor with the open source firmware run ok on a 36v battery?

It may work somehow.

The Field Weakening feature on the firmware will make the motor run faster - maybe it will be enough for you to pedal at 80 RPM cadence - there is no feedback from users on this, using a 48V motor with a 36V battery. But there is feedback from an user running a 36V motor from a 24V battery and Field Weakening did improve a lot the motor speed / pedal cadence.

If I was you and I had already both battery and motor, I would try our firmware with Field Weakening before buying the 36V motor.

 

[devboy-greg]

Can I ask, will a TSDZ2 48v motor with the open source firmware run ok on a 36v battery?

I can offer some feedback on the older software (v0.20.0-beta.1) with experimental high cadence mode enabled, I used a 36v battery on my 48v MTB to get me to the start of an organised ride and then swapped to a 48v battery for the ride.

The 36v battery on the 48v motor was lacklustre to say the least, not something I would want to do for any great distance, cadence was also an issue (as expected).

 

[raw]

If I was you and I had already both battery and motor, I would try our firmware with Field Weakening before buying the 36V motor.

it may be better to buy a 48v battery because your 36v may be already some years old and will loose capacity over time - sooner or later you will have to replace it anyway. 48v motor is reported to heat less, so its the better overall choice. also, it should be easier to sell a plain 36v battery instead of a modded motor with a custom firmware and possibly cut-off cables

 

[raw]

Torque mode uses only the torque measured on the pedals. The motor current is then pedals torque * assist level factor.

ok, sounds easy. and power is human power * assist level factor or something like this?
the human power is not determined by the torque sensor? how is it calculated?

 

[Benoit]

Torque mode uses only the torque measured on the pedals. The motor current is then pedals torque * assist level factor.

ok, sounds easy. and power is human power * assist level factor or something like this?
the human power is not determined by the torque sensor? how is it calculated?

Human power is well determined by the torque sensor. You can find more information about it in the wiki ("Available information to show on display" section) :

Pedal human power. This is calculated using the following formulas:
1. torque sensor signal is linearized and the output ADC values are converted to weight is kgs
2. pedal torque in Nm is calculated as: pedal torque = weight Kgs on pedals * 9.81 (gravity) * 0.17 (0.17 is the arm cranks size)
3. pedal power in watts is calculated as: pedal power = (pedal torque * pedal cadence * 2 * pi) / 60

 

[Benoit]

adding translations is a nice to have, but it think it will also make things more complicated. there is not much point in translating the configuration menu because then the wiki (at least the configurations page) has to be translated too and should use the same terms as the translation. so the bike-builder that does the configuration needs to work in english now.

translating the home screen would be nice, because the end user may like it in his native language, i.e. if you are building bikes for your friends and families that do not mess with the configuration and just ride the bike.

I could translate in French as it's my native language, and I could translate the wiki too.
For other languages, I won't be able to do that :lol:

I don't know if it's hard to add a new menu item to select the desired language (and what about the memory ? I'm not yet aware of the 850/860C hardware limits).
Or simply compile different versions of the firmware, one for each language.

while working with the Color_LCD firmware i noticed that

• it is pretty inconsistent in its code style, intents are made with tabs and spaces, the opening brace is sometimes on the same line as the if, sometimes on the next and so on. a official coding style would be nice.
• documenting comments are there (and very useful!), but mainly specific to some code lines. what lacks are documentation comments for functions (why are they here, what should they do). i noticed this especially in the screen.c while trying to figure out how the rendering works.
• i was also missing a toplevel developer documentation that explains some principles how everything works to allow a quicker start into the code.
• more important: an documentation for the UART protocol used would be nice (=> what each bit does). when developing for the display, you will currently need to read the motors sourcecode to get an idea what something does, which is also time consuming. this will especially useful for the TSDZ2 wireless project, as it would make maintaining the wireless firmware and android app more easy.

• I could take care of it, but we have to determine a official coding style first
• I don't know if I can, for now, help for the second point as this kind of firmware development is far away of my everyday work (ASP.NET web applications).
• Same as previous point, I need some informations on how the firmware works
• I already read some parts of the code, and saw briefly how you transfer data between display and motor. I think I can write a documentation about the UART protocol, as variable names are pretty explicit.
  Maybe I can start with that point, it will also help me to understand how the firmware works.

I see you encounter the same "problem" as me in your development ^^ (documentation is not a fun part in a developping process...)

also, i develop on windows using the linux subsystem for windows for compiling. i did not plan to force-open the 860c so for flashing/testing i only have the windows bootloader software. i have tried compiling it native with windows, but was not able to get it to work without investing more time. so my workflow is: think hard about what the sourcecode does, make your changes, compile them with the subsystem, flash it with the windows bootloader app and look if it is working. if not start from the beginning. is there a better way?

is there an easy way to get some "debug console" like output on the display? so i.e. i can print some text when a specific part is reached?

It was one of my next questions : how do you proceed to debug. I see it's not easy.
For a "debug console", I think about 3 options :

• splitting the display : one part for what is currently displayed and the other part for debug
• new menu item to enter in a debug console (good option if we don't need to use the commands/display while debuging)
• with a PC, intercepting data over UART, and filter "debug information" (which would be displayed on the PC screen) and "display informations" which obviously would be displayed on the display.
  With some Arduino boards (like Mega or Due, Due is better as it works under 3.3V for I/O pins so no need of a voltage divider), it could be possible as they have several serial ports (3 for Mega and Due).
  (I personnaly used a Arduino Due as a serial<->usb converter to flash the 860C)

also i noticed that the firmware goes into dev-mode when the voltage is below 14v. The wiki causes the impression that for flashing the display using the bootloader box a voltage of at least 27v is requied which not the case. i think it should be clarified, but i do not know what the actual recommended minimum voltage is.

What is dev-mode of the firmware ?
About the voltage, maybe I could test what is the actual minimum voltage. When doing it (for the first time, two days ago, after receiving the TSDZ2 one day before), I used a external adjustable power supply at 25V (it can't go over 27-28V).
So I can confirm flashing the display at 25V is possible.
But I had to flash it a second time as the first try stopped during flashing, I thought the dislay wad "dead" as it stayed black after.
I don't know if it was because of this "low" voltage or because I used a particular flashing configuration : Windows XP virtual machine on a MacBook Air (as I did not have a Windows 10 laptop and this VM was already on my Mac).
But it worked on the second try !

 

[AZUR]

Hi,

I forgot to mention it in the last post, but the Garmin Remote doesn't always work well. I do not know why.
I use it mainly to change the Garmin screen, as the Garmin touch screen doesn't work very well with gloves.
Sometimes I have to press the Remote key more than once to be able to change the screen.

Sorry, i have the same Garmin Remote to change screens on my Edge 1000. It works fine! Without problems.

Thanks Mallesepp , Good to know. I´ll we seen how can I solve the problem.

 

[pgwguk]

Torque mode uses only the torque measured on the pedals. The motor current is then pedals torque * assist level factor.

ok, sounds easy. and power is human power * assist level factor or something like this?
the human power is not determined by the torque sensor? how is it calculated?

Human power is well determined by the torque sensor. You can find more information about it in the wiki ("Available information to show on display" section) :

Pedal human power. This is calculated using the following formulas:
1. torque sensor signal is linearized and the output ADC values are converted to weight is kgs
2. pedal torque in Nm is calculated as: pedal torque = weight Kgs on pedals * 9.81 (gravity) * 0.17 (0.17 is the arm cranks size)
3. pedal power in watts is calculated as: pedal power = (pedal torque * pedal cadence * 2 * pi) / 60

Is it possible to set the crank length as a user adjustable value?
I personally use 145mm unicycle cranks on my TSDZ2 setup, shorter cranks tend to work better on a recumbent.
If we're planning to expose power details via Bluetooth / ANT+, it makes sense to get it as accurate as possible.

 

[raw]

I don't know if it's hard to add a new menu item to select the desired language (and what about the memory ? I'm not yet aware of the 850/860C hardware limits).

Adding menu items is easy, but i have no idea how much memory and storage is left on the display i started messing around with it 3 weeks ago, so im almost at the same point as you.

while working with the Color_LCD firmware i noticed that

• it is pretty inconsistent in its code style, intents are made with tabs and spaces, the opening brace is sometimes on the same line as the if, sometimes on the next and so on. a official coding style would be nice.
• documenting comments are there (and very useful!), but mainly specific to some code lines. what lacks are documentation comments for functions (why are they here, what should they do). i noticed this especially in the screen.c while trying to figure out how the rendering works.
• i was also missing a toplevel developer documentation that explains some principles how everything works to allow a quicker start into the code.
• more important: an documentation for the UART protocol used would be nice (=> what each bit does). when developing for the display, you will currently need to read the motors sourcecode to get an idea what something does, which is also time consuming. this will especially useful for the TSDZ2 wireless project, as it would make maintaining the wireless firmware and android app more easy.

• I could take care of it, but we have to determine a official coding style first
• I don't know if I can, for now, help for the second point as this kind of firmware development is far away of my everyday work (ASP.NET web applications).
• Same as previous point, I need some informations on how the firmware works
• I already read some parts of the code, and saw briefly how you transfer data between display and motor. I think I can write a documentation about the UART protocol, as variable names are pretty explicit.
  Maybe I can start with that point, it will also help me to understand how the firmware works.

well casainho would be the most qualified person to add more documentation, i just did not want to ask him directly as he has already done so much. :wink:

also, i develop on windows using the linux subsystem for windows for compiling. i did not plan to force-open the 860c so for flashing/testing i only have the windows bootloader software. i have tried compiling it native with windows, but was not able to get it to work without investing more time. so my workflow is: think hard about what the sourcecode does, make your changes, compile them with the subsystem, flash it with the windows bootloader app and look if it is working. if not start from the beginning. is there a better way?

is there an easy way to get some "debug console" like output on the display? so i.e. i can print some text when a specific part is reached?

It was one of my next questions : how do you proceed to debug. I see it's not easy.
For a "debug console", I think about 3 options :

• splitting the display : one part for what is currently displayed and the other part for debug
• new menu item to enter in a debug console (good option if we don't need to use the commands/display while debuging)
• with a PC, intercepting data over UART, and filter "debug information" (which would be displayed on the PC screen) and "display informations" which obviously would be displayed on the display.
  With some Arduino boards (like Mega or Due, Due is better as it works under 3.3V for I/O pins so no need of a voltage divider), it could be possible as they have several serial ports (3 for Mega and Due).
  (I personnaly used a Arduino Due as a serial<->usb converter to flash the 860C)

hm, it should be possible to use the same connection that was used for flashing for debugging .. or some kind of serial console.

also i noticed that the firmware goes into dev-mode when the voltage is below 14v. The wiki causes the impression that for flashing the display using the bootloader box a voltage of at least 27v is requied which not the case. i think it should be clarified, but i do not know what the actual recommended minimum voltage is.

What is dev-mode of the firmware ?

in state.c:

#define MIN_VOLTAGE_10X 140 // If our measured bat voltage (using ADC in the display) is lower than this, we assume we are running on a developers desk

if the display measures a input voltage below 14V it goes into simulation mode that simulates an motor connected and cycles the values. useful for testing changes where you do not need to have the motor running as you can just leave the flash cable connected and do not need to change plugs. you can raise this value if your power supply cant go below 14v.

About the voltage, maybe I could test what is the actual minimum voltage. When doing it (for the first time, two days ago, after receiving the TSDZ2 one day before), I used a external adjustable power supply at 25V (it can't go over 27-28V).
So I can confirm flashing the display at 25V is possible.
But I had to flash it a second time as the first try stopped during flashing, I thought the dislay wad "dead" as it stayed black after.
I don't know if it was because of this "low" voltage or because I used a particular flashing configuration : Windows XP virtual machine on a MacBook Air (as I did not have a Windows 10 laptop and this VM was already on my Mac).
But it worked on the second try !

Flashing with 13v works well. i just did not try to go lower yet.

what is your motivation to start developing on this project?

@casainho is it possible to accidentally brick the display by flasing a errorous or incomplete firmware to the point that it is not recoverable by the bootloader method?

 

[casainho]

adding translations is a nice to have, but it think it will also make things more complicated. there is not much point in translating the configuration menu because then the wiki (at least the configurations page) has to be translated too and should use the same terms as the translation. so the bike-builder that does the configuration needs to work in english now.

translating the home screen would be nice, because the end user may like it in his native language, i.e. if you are building bikes for your friends and families that do not mess with the configuration and just ride the bike.

I like the idea of translating only the main screen, but, it is also to much to translate: main screen strings, all custom fields strings and error strings. Also there is no support for chars like ç á ê , etc, so, I would not translate anything. For friends and family, would be good to make harder to enter configurations and make sure it would leave automatically after some time. Also configuration for 1, 2, or 3 main screens and then set to only 1. The data on that only 1 main screen can be easy to understand, on the 4 fields, choose trip time, trip distance and others that are intuitive to understand.

Are there are many others things to do that I think have higher priority:
- solve SW102 lock issues on configurations menu
- solve lights issue
- automatic shutdown does not work
- Trip (with quick reset): time, distance, Wh
- Short Trip: time, distance, Wh
- kms range estimation, based on Wh used of current short trip, last 5 or 10 minutes
- disable sensors: brake, cadence and torque

while working with the Color_LCD firmware i noticed that

• it is pretty inconsistent in its code style, intents are made with tabs and spaces, the opening brace is sometimes on the same line as the if, sometimes on the next and so on. a official coding style would be nice.
• documenting comments are there (and very useful!), but mainly specific to some code lines. what lacks are documentation comments for functions (why are they here, what should they do). i noticed this especially in the screen.c while trying to figure out how the rendering works.
• i was also missing a toplevel developer documentation that explains some principles how everything works to allow a quicker start into the code.
• more important: an documentation for the UART protocol used would be nice (=> what each bit does). when developing for the display, you will currently need to read the motors sourcecode to get an idea what something does, which is also time consuming. this will especially useful for the TSDZ2 wireless project, as it would make maintaining the wireless firmware and android app more easy.

The code for displays, was structured by other developer much more experienced than me. Lately I am not having much time so I am not putting much comments...

is there an easy way to get some "debug console" like output on the display? so i.e. i can print some text when a specific part is reached?

If you think you will be able to really develop, then maybe you could buy the cheap as possible 850C because it is easy to open without damage and it is almost the same hardware as 850C - and use the JTAG debug, that is what I do, way faster to develop!!

I could translate in French as it's my native language, and I could translate the wiki too.

Please don't, instead let's have only 1 version and strong!! you can focus on improving current version.

Is it possible to set the crank length as a user adjustable value?
I personally use 145mm unicycle cranks on my TSDZ2 setup, shorter cranks tend to work better on a recumbent.
If we're planning to expose power details via Bluetooth / ANT+, it makes sense to get it as accurate as possible.

Would be nice to have that as configurations. I wish other developers could develop, test and send a pull request.

@casainho is it possible to accidentally brick the display by flasing a errorous or incomplete firmware to the point that it is not recoverable by the bootloader method?

I am pretty sure not. Only bootloader should be able to write on bootloader flash section, so, app should not be able to overwrite the bootloader.

 

[Benoit]

Are there are many others things to do that I think have higher priority:
- solve SW102 lock issues on configurations menu
- solve lights issue
- automatic shutdown does not work
- Trip (with quick reset): time, distance, Wh
- Short Trip: time, distance, Wh
- kms range estimation, based on Wh used of current short trip, last 5 or 10 minutes
- disable sensors: brake, cadence and torque

Maybe I can start to work on the trip features. It's something I could easily test and verify. Is that ok for you ?

Please don't, instead let's have only 1 version and strong!! you can focus on improving current version.

No problem, translation is not a priority, it was just something I could easily do to start. But you're right, features above are way important than translation !

@casainho is it possible to accidentally brick the display by flasing a errorous or incomplete firmware to the point that it is not recoverable by the bootloader method?

I am pretty sure not. Only bootloader should be able to write on bootloader flash section, so, app should not be able to overwrite the bootloader.

That's what happened to me ! First flash stopped at about 50-60% progress.
But I then successefuly flash it after retrying !

 

[casainho]

Are there are many others things to do that I think have higher priority:
- solve SW102 lock issues on configurations menu
- solve lights issue
- automatic shutdown does not work
- Trip (with quick reset): time, distance, Wh
- Short Trip: time, distance, Wh
- kms range estimation, based on Wh used of current short trip, last 5 or 10 minutes
- disable sensors: brake, cadence and torque

Maybe I can start to work on the trip features. It's something I could easily test and verify. Is that ok for you ?

Yes, please.

On LCD3 is TM for time time and TTM for trip time, maybe could be for us "time" and "trip time", as also "distance" and "trip distance".

The trip values time, distance, and Wh will not be available for graphs, only for custom fields.
To quick reset it, user should, first quick change the field variable and then quick edit - just the same as changing graph scale but here will reset all the trip variables.

On 860C/850C, should be a configuration for amount of hours in steps of 2h, for automatic reset (check only at startup, user may want to automatically reset after 10h, this will include sleeping time so trip values would be reset very day automatically and user would see the trip values for the day. For long rides, user could put like 48h to make sure will never reset.

Well, should we invest time to develop all this little details?? I don't known... I would instead invest my time on the wireless new version as for long rides, that type of users will value more using a Garmin Edge device that already implements this features and they are implemented already in conjunction with other important trip data and fitness, and recorded on the cloud.

Well, is up to you to decide in which project you prefer to invest more.

 

[rcx194]

Please go ahead and put a warning on the wiki, maybe on the firmware installation page.

As per request I've added a warning to the Wiki. Feel free to edit/improve what I've written.

 

[casainho]

Please go ahead and put a warning on the wiki, maybe on the firmware installation page.

As per request I've added a warning to the Wiki. Feel free to edit/improve what I've written.

Note that is valid for also SW102, so, I think that information should be in upper level of the instructions.