merging #BluetoothMesh into #SoftDevice ?

RE: merging #BluetoothMesh into #SoftDevice ?

endnode — Tue, 16 Jan 2018 10:39:57 GMT

Just because I've reacted to your original post and as long as you post it on open forum (there is closed support portal as well if you need) then I thought you deserve some feedback as well. I don't want to disturb any more your discussion, enjoy it.

RE: merging #BluetoothMesh into #SoftDevice ?

endnode — Tue, 16 Jan 2018 10:11:46 GMT

If you are stupid then only because you don't know who you are talking to and you mix the people here. Only some people work for Nordic, the rest are forum visitors like you. So I'm not working on Zephyr, I'm just curious what is preventing you to write such little feature to open source project if it is so important for you...

RE: merging #BluetoothMesh into #SoftDevice ?

endnode — Tue, 16 Jan 2018 08:08:32 GMT

You say it's so much better then nRF5 SDK and Nordic Soft Device but such simple thing like storing some configuration in the flash makes it unusable?:) If this is the only way missing and framework/API is so great that it should be one week of work... anything preventing you to write it?

RE: merging #BluetoothMesh into #SoftDevice ?

ovrebekk — Mon, 15 Jan 2018 12:42:25 GMT

Thanks for the feedback. We have a couple of engineers involved in the Zephyr project, contributing to the code base, but on the mesh side we have chosen to focus on our own solution.

Software engineers are a precious resource, and we have to pick our battles ;)

Best regards

RE: merging #BluetoothMesh into #SoftDevice ?

vikrant8051 — Fri, 12 Jan 2018 04:44:55 GMT

Hi Leonwj,

Thanks for the reply. I was not aware about it that Nordic Semiconductor team is also part of Zephyr Bluetooth development. Salute & congratulation to every developer behind it from Nordic Team. Really Great job & I apologies to ignore their contribution which was unintentional.

I think Mr.Johan Hedburg is currently working on adding feature of saving provisioning & configuration details of #BluetoothMesh on flash of nrf52. Once he succeed, Zephyr will be the first open-source project which has complete support for #BLEMesh with PB_ADV & PB-GATT.

Could you please accelerate this process from your side by adding further contribution ?

RE: merging #BluetoothMesh into #SoftDevice ?

leonwj — Thu, 11 Jan 2018 19:30:01 GMT

(3/3) Ultimately, I'm not aware of Nordic charging for the use of their softdevice and simply provide it as a way to utilize their SoCs (which is their core business) which based upon your previous posts, you appear to be using. So as mesh developers, we get to choose whether we want to utilize Nordic's softdevice architecture or the open-source Zephyr stack (and/or a hybrid approach). From Nordic's perspective, I would imagine that as long as we're doing so on their SoCs, this means a win-win for the nRF5x ecosystem.

RE: merging #BluetoothMesh into #SoftDevice ?

leonwj — Thu, 11 Jan 2018 19:29:08 GMT

(2/3) Furthermore, you as a proponent of Zephyr (and we also like the work done/progress being made by that team) would know (or at the very least should know) that the significant strides made in Zephyr Bluetooth support has come about in large part based on the work and contributions made by Nordic. This is alluded to and confirmed by Johan Hedberg in his Creating Bluetooth-based IoT Solutions with Zephyr Project presentation so I don't believe it's entirely fair to use Zephyr's progress as a stick to beat Nordic with.

RE: merging #BluetoothMesh into #SoftDevice ?

leonwj — Thu, 11 Jan 2018 19:27:40 GMT

Hello vikrant8051,

(1/3) Just to add... whilst I appreciate your enthusiasm, I believe that you're letting it get ahead of the logical side of things. As endnode and Torbjørn have pointed out, there are many Nordic BLE developers who would not like to see the extra 'bloat' of mesh added to the softdevice. Inversely, there will be some proponents of the SIG 'flooding' mesh who will feel that they don't need the full softdevice stack and could call for a slimmed down version of that. Given that the Bluetooth SIG have not ruled out a possible 'routing' mesh standard in the future, I believe that Nordic have struck the right balance. i.e. provide the softdevice 'as is' and run the current implementation of Bluetooth mesh on top of that. This also enables the future possibility of running other mesh stack implementations. And do all this, whilst providing 'best-of-breed' SoCs to run them on.

RE: merging #BluetoothMesh into #SoftDevice ?

vikrant8051 — Thu, 11 Jan 2018 17:37:31 GMT

Yes, because of this personally I don't like Nordic APIs for GATT based peripheral as well as Bluetooth Mesh development. Currently I'm working on Zephyr only. Wonderful work done by Zephyr Team. Very simple APIs.

Once Zephyr release support for flash to save provising and configuration, no one will go with Nordic Mesh SDK

RE: merging #BluetoothMesh into #SoftDevice ?

endnode — Thu, 11 Jan 2018 16:43:07 GMT

(2/2) ...is obviously making this longer and more expensive. So what looks much more possible is that one day Nordic Soft Device won't be so widely used because open source projects like Zephyr - which btw. has big support from Nordic already - will take over. So I guess that's the way for you right now in 2018: rather ask Zephyr people on their forum when BT SIG mesh network will be implemented and integrated inside. Sounds like better way to me.

RE: merging #BluetoothMesh into #SoftDevice ?

endnode — Thu, 11 Jan 2018 16:39:40 GMT

It's definitely not possible today as Nordic do not supply their stack in source code but just binaries and API. So what you propose is kind of in contradiction with whole business strategy of Nordic Soft Device:) Which I'm not saying is the right one, they already changed approach once because originally it looked that the biggest IP and selling point of Low Power radio chips will be chip + stack so SD was originally pre-loaded and normal developer should never see it. However today it lives routinely in binary form out there so maybe one day they will throw away everything including source code. But I doubt that would be now and because of integration with BT SIG mesh to let the developers messing up with stack through ton of global defines. Also having the stack pre-qualified is important value for many users, merging it with more features and making it openly configurable is... (1/2)

RE: merging #BluetoothMesh into #SoftDevice ?

vikrant8051 — Thu, 11 Jan 2018 15:33:12 GMT

I think it is 100% possible. If you can add BLE core under Blackbox same way you can do it with Mesh. Means whatever mentioned as standards by Bluetooth_SIG will be get covered under that black box.

You should give facility to app developer to rebuild SoftDevice as per his requirements after configuring it.

So please re-think over it. Take view from both team members.

Thank You !!

RE: merging #BluetoothMesh into #SoftDevice ?

ovrebekk — Thu, 11 Jan 2018 14:12:05 GMT

We don't have any plans to merge the mesh library with the SoftDevice.

One problem with this, as endnode commented, is that it would increase the size of the SoftDevice. Since the SoftDevice is a pre-compiled and pre-linked library, you are not able to optimize out functionality that you don't use.

As it is today it is relatively little work to remove the link to the SoftDevice completely, so that you can use Bluetooth mesh and get away with a considerably lower flash requirement.

Another drawback of putting it into the SoftDevice is that the Bluetooth mesh would be held back by the SoftDevice release schedule. Today Bluetooth mesh is developed by a separate team, and can be updated independently of the SoftDevice.

In regards to putting models or services into the stack itself, this is not the way Bluetooth low energy is intended to work. The idea with BLE is that you can easily redefine or add new models/services in the application space, without having to wait for the stack provider to include new models/services.

Best regards
Torbjørn Øvrebekk

RE: merging #BluetoothMesh into #SoftDevice ?

endnode — Thu, 11 Jan 2018 12:49:28 GMT

I'm afraid there would be big group of Nordic stack users which don't need (stupid) mesh network and thus would be very unhappy to have much bigger stack loaded with unused functionality...