Bafang SW102 Bluetooth LCD - OpenSource firmware and mobile app

Zelenaar said:
Does somebody know to which GPIO the buttons are connected in the sw102 ?
Not yet but should be easy: connect the debugger while reading all GPIO inputs and see the GPIO inpit value to figure out which pin for each button.
 
Sure we do!
https://github.com/OpenSource-EBike-firmware/Color_LCD/wiki/Bafang-LCD-SW102#eagle-schematic

You look for SW_M, SW_DWN, SW_UP and SW_PWR. All but SW_PWR are active-low. SW_PWR is active-high.
 
DFU is working!

Normal Startup (SW102 advertising UART over BLE):
normal_start.png

Bootloader Mode (Hold Power + M for >5 seconds)
bootloader.png

Transfer of new firmware:
transfer.png
 
Nick said:
DFU is working!

Normal Startup (SW102 advertising UART over BLE):
normal_start.png

Bootloader Mode (Hold Power + M for >5 seconds)
bootloader.png

Transfer of new firmware:
transfer.png

Vervy very nice and good work Nick!! I hope to receive my sw102 in the upcoming days.
Hopefully i can help on some simple parts (no experience with embedded programming).

But very nice work :bigthumb:
 
Nick said:
DFU is working
Very nice Nick!

Finally I received my sw102.
I noticed that out of the box the dfu service is also available. Would this mean that users could flash our firmware (& bootloader) without the need of opening the sw102? (That would a huge advantage).
The coming days I will start to experiment with the android app
 
Hard to tell. It depends which bootloader is on the device. If it's based on the Nordic nrf5 bootloader, it requires a signed zip file. So without the private key you can't update anything. I assume this bootloader also accepts only signed packages. So for now you have to open the device and flash our own bootloader.

I updated the "How to open the SW102" wiki lately. My findings are that you should leave the keypads in place. If you have like 10 minutes and a bit of patience it is not that complicate to open the device and you can later
1) just clip it back on for easy removal or
2) glue it back on so it is water-resistant again (I recommend to wait with this until we have stable releases and bootloader).
 
Nick,
I opened the sw102 already this weekend based on you (previous) guideline and was able to connect the stlinkv2.
Didn't yet flash => maybe I could try the ootb DFU to flash your bootloader & app.
Do you have it in hex format so I can give it a try?
 
You can find the bootloader repository on my account as a start:
https://github.com/lowPerformer/SW102_Bootloader

But I'm afraid this is not as simple as flashing a hex. The bootloader needs also the Softdevice S130 v2.0.1 present. Don't know which Softdevice is on the original SW102. If you ask me, I would not spend too much time trying :wink:
 
Bluetooth license fee $4000

So, seems we have to pay a license fee of $4000 to use Bluetooth. Maybe this is the reason why cheap SW102 generic on sites like Ebay or AliExpress come with a firmware without Bluetooth?

What should we do? Pass this responsibility to user and use the Nordic Bluetooth id while doing the development?
 
casainho said:
Bluetooth license fee $4000

So, seems we have to pay a license fee of $4000 to use Bluetooth. Maybe this is the reason why cheap SW102 generic on sites like Ebay or AliExpress come with a firmware without Bluetooth?

What should we do? Pass this responsibility to user and use the Nordic Bluetooth id while doing the development?

Are you saying that Nordic BT id will work without license for end users also?
 
There are some topics on Nordic forum about this subject of Bluetooth license fees, see this question and answer as a clarification.

Well, does the original firmware implement Bluetooth DFU? If so, what is the company ID?? because that company had to pay to put this on the market and so since we bought this product SW102, for my understanding, we could use the same ID because we already paid the product and so the ability to use Bluetooth with it. But I think to be correct, we must have authorization from that company and I think that may not happen...

Q: Bluetooth licensing fees?
Is there a way to avoid fees, and still use BLE? Do I need to change UUIDs or leave them be?

If not can the nrf51822 be used to just use the pure 2.4 ghz protocol and DFU at the same time? Or is DFU BLE based? It is not crucial that we use BLE, just a wireless low power protocol with good range!

I just assumed it was free to use as long as I didn't want to have an official bluetooth logo or something like that! Isn't the bluetooth fee priced in the chip costs?


A: To sell a BLE product you need to comply with the following:

FCC regulatory requirements

R&TTE regulatory requirements

IC regulatory requirements

Bluetooth compliance and certification

Please see the Regulatory and Compliance standards whitepaper, for more infomation about the Bluetooth compliance and certification, see this post as well as START B on the bluetooth SIG pages.

DFU is using our BLE stack, so it is not possible to utilize this service without using our SoftDevices. However it is possible to implement your own proprietary protocol that includes support for over-the-air firmware updates.

You can definitely create a proprietary protocol, and this would make you avoid the fees to Bluetooth SIG, however you still need to comply with the regulatory requirements.


See more here: https://devzone.nordicsemi.com/f/nordic-q-a/8304/bluetooth-licensing-fees
 
I did power on the SW102 I have here that I bought from PSWPower and has the original firmware. Bluetooth does work as seen on the NRFconnect app. Please see what you can find... can we find the company looking at the IDs on the screenshots??

The device name is "Tophmi_8904". Topology Human Machine Interface, since the company is Topology Tech?? -- I don't see it listed on Bluetooth site..... or maybe I didn't search correctly??















 
there is many way to use sw102
simple one is use it as a simple command without Bt and USB support, switching assist lvl and display some informations like power or voltage, it need to open it and flash it to use it .

for those who want advanced use, BT is necessary, soo, as said before may be it s possible to make a deal with a company that paid the rights to use bt bootloader, ask them to implemented your open source and the right ( encripted zip !? ) to modify !?

Create your own Bt protocol ( may be using existing open source BT library ? ) and bootloader and write it !?

Sorry it s far away for my understanding !
May be i said full of mistake !?

For the moment as i am always using a GPS ( like bryton or garmin ) on my ride, i only need to switch assit lvl and i would be happy to use a small display if it could also display voltage, i don t need real power or other things because my use is very simple, btw i m only a MTB user ...

i understand that it could be amazing to have the opportunity saving data like cadence, human power etc via BT and use it but not all ppl need it, and i m sure that some user would use a smaller display than the one avaiable actually .
 
casainho said:
The device name is "Tophmi_8904". Topology Human Machine Interface, since the company is Topology Tech?? -- I don't see it listed on Bluetooth site..... or maybe I didn't search correctly??

Mine has the device name "TOPHMI_A001" with DFU available.
I didn't see neither a characteristic containing the name of the corporation.

Does an opensource project like this need to pay the BT licence ?
I don't think we are intending to sell the 'naked' product with the OS firmware on it.
Our users are buying a SW102 with already the basic BT software on it => I would assume its the resposibility of the manifactor the pay for the BT licence
The opensource project is 'only' offering an 'improved' version of the ootb firmware...
Another issue could be that we are making use of the Nordic softdevice, I don't know exactly the Nordic licencing but I think I read somwhere it was free for non-commercial usage
 
Nick said:
You can find the bootloader repository on my account as a start:
https://github.com/lowPerformer/SW102_Bootloader

But I'm afraid this is not as simple as flashing a hex. The bootloader needs also the Softdevice S130 v2.0.1 present. Don't know which Softdevice is on the original SW102. If you ask me, I would not spend too much time trying :wink:

Nick,
Tried to flash your bootloader .hex with DFU, but failing because it is also requesting for the "extended init packet"Screenshot_20190507-190459_nRF Connect.jpg
 
casainho said:
Bluetooth license fee $4000
...
What should we do?...

1) Don't panic! :wink:

This project is open source none commercial. We are no company and do not sell any products. It will never happen that the Bluetooth SIG rings the door bell of end users to collect some license fees!
Those fees are for companies selling Bluetooth products and putting the official BLE Logo on those product (guess why SW102 device/packaging do not show any BT logo!).

What I maybe would not do is using some UUID of a company. This company then maybe hunts you down for using this without permission. But to be honest, this is a so tiny project it just isn't relevant!

What maybe would be a problem is (as already announced) someone sells "our" SW102+Bootloader to endusers commercially. This is A) Not the problem of this project but of the shop selling those devices and
B) we could develop a bootloader with UART only based on the Nordic bootloader structure. No Bluetooth, no risk. The Enduser can update this bootloader then with a Bluetooth ready version over the motor cable (just like the TSDZ2 motor) at home with light off and shutters down :D !

So if you ask me: Just go on with development!
 
Nick said:
casainho said:
Bluetooth license fee $4000
...
What should we do?...

1) Don't panic! :wink:

This project is open source none commercial. We are no company and do not sell any products. It will never happen that the Bluetooth SIG rings the door bell of end users to collect some license fees!
Those fees are for companies selling Bluetooth products and putting the official BLE Logo on those product (guess why SW102 device/packaging do not show any BT logo!).

What I maybe would not do is using some UUID of a company. This company then maybe hunts you down for using this without permission. But to be honest, this is a so tiny project it just isn't relevant!

What maybe would be a problem is (as already announced) someone sells "our" SW102+Bootloader to endusers commercially. This is A) Not the problem of this project but of the shop selling those devices and
B) we could develop a bootloader with UART only based on the Nordic bootloader structure. No Bluetooth, no risk. The Enduser can update this bootloader then with a Bluetooth ready version over the motor cable (just like the TSDZ2 motor) at home with light off and shutters down :D !

So if you ask me: Just go on with development!

I did some researching on the internet and come to the same conclusion as Niek.
For point A) not the problem of this project but of the shop selling those devices --> the best way would to explore the possibilities with Topologie. But as Nick mentioned I think they already explored this and made a decision to not show the BT logo etc.
For point B) update bootloader lcd with uart over the motor cable. You mean we add this "bluetooth ready bootloader" to the program for the TSDZ2 motor and then send it by uart from the TSDZ2 motor to the LCD?
 
I mean we could develop a UART only Bootloader for SW102 and a Bluetooth Bootloader (which we already have).
Someone who is interested in selling this but fears the Bluetooth SIG can sell the UART only SW102 and enduser can flash the BT Bootloader and firmware (once over UART) at home without opening the device.
But this is only of interest for commercial use, we (the open source community) dont have to worry. We also have to implement a UART module for the current Bootloader because this builds upon the nrf5 SDK example which doesn't support UART interface but it is modular and you can add your own features.
 
Nick, I was looking on your instructions for how to setup Eclipse but I am on Linux. Can you please explain why/what are the advantages to have the Series -> nrf_DeviceFamilyPack??

The way I setup debug tools on Eclipse is kind of old. I just use the makefile and call it on command line (although can easily be called with CTRL + B). I Use an old plugin to Eclipse (http://opensource.zylin.com/embeddedcdt.html) to support debug with OpenOCD that forces me to stay on an old version of Eclipse. Although, the setup is short.

I would like to try the GNU MCU Eclipse like you wrote, I just wounder why the nrf_DeviceFamilyPack.
 
The Device Pack is for debugging view only. If you install the pack, you can easily select peripheral registers like ADC, GPIO, ... and when halted you get a extra view of those registers:
Unbenannt.jpg
 
Nick said:
The Device Pack is for debugging view only. If you install the pack, you can easily select peripheral registers like ADC, GPIO, ... and when halted you get a extra view of those registers:
Unbenannt.jpg
Ok, thanks. That is a good value!!
 
casainho said:
The way I setup debug tools on Eclipse is kind of old. I just use the makefile and call it on command line (although can easily be called with CTRL + B)...

Our SW102 firmware and bootloader are based on the nrf5 SDK, so all the build is done by Makefile too and is not managed by Eclipse. You can also call make on the command line but I create Build Targets in Eclipse, so I can start the Makefile targets I need just with a click:
buildtargets.jpg

Main purpose of the GNU MCU package is the easy setup of openOCD debugging.
 
Nick said:
casainho said:
The way I setup debug tools on Eclipse is kind of old. I just use the makefile and call it on command line (although can easily be called with CTRL + B)...

Our SW102 firmware and bootloader are based on the nrf5 SDK, so all the build is done by Makefile too and is not managed by Eclipse. You can also call make on the command line but I create Build Targets in Eclipse, so I can start the Makefile targets I need just with a click:
buildtargets.jpg

Main purpose of the GNU MCU package is the easy setup of openOCD debugging.
You did very well, I must say. I never went to a so detailed way to debug and I never written a so good instructions!!

I want to focus myself on 850C display but it is hard to not want test what you guys had being doing!!
 
Back
Top