Arduino on Nordic BLE nRF51822

st is fighting back market with BlueNRG-1
http://www.st.com/en/wireless-connectiv … tId=SC1898
http://www.st.com/content/st_com/en/pro … nrg-1.html

hopefully we could get those boards soon in mass market too
for now st seem to have this dev board for BlueNRG at a pretty hefty price tag though, hopefully the ‘nucleo’ & common dev board versions would be out soon
http://www.st.com/content/st_com/en/pro … 007v1.html
oops/oh found another, the ‘nucleo’ board with BlueNRG
http://www.st.com/content/st_com/en/pro … b04a1.html

it seemed BLE is cooking up a storm as BLE connects to any android phones/devices > 4.3, recent iphones & windows > 8

Yep.

Those boards are made by Wireless-tag.

I have some of the larger ones, but they were more expensive when I bought them last year.

The one thing they lack is the 32khz crystal oscillator which means they do not keep time very well when sleeping.

Initially the repo I used / modified from RBL didnt work with them because it needed the 32 khz crystal, but my newer repo ( also a hacked version of RBLs) does now support them.

But I now recommend that people use Sandeep’s repo as its much better than the RBL one.

What I think will also increase the use of BLE is the Web BLE API that Google have added to Chrome in the last month.
On Android it needs Marshmallow ( Android 6) and none of my devices currently have this, but over time most users will have this and be able to simply write HTML and Javascript to interact with their BLE devices.

At the moment I am using Cordova to write my Android apps, and it works fine and is very simple to install and use, even on windows.

e.g. I just plug jn my phone , goto the directory with the project files in it and type “cordova run android” and a few seconds later the changes I made to the app have been compiled and the app is running on my Android phone.

I am currently designing a new bluetooth board , which will use the new nordic chip , the nRF52840, which will have a similar form factor to the Blue Pill.
The nRF52840 is 64MHz cortex M4F and has 256k RAM and 1M flash, and supports BLE 5 including the long range / high power transmission modes.

Unfortunately the nRF52840 wont be available in commercial quantities until Q4 this year. But thats only 6 months away and ai have a lot of design and prototyping before then

i’m actually pretty recently a noob / newbie to bluetooth & its technologies, just in the immediate recent did a ‘deep dive’ into bluetooth (& ble) and is confounded by a very complex protocol stack (bluetooth that is), as it turns out in the low level link layer stack it defines a rather simplified link layer states
https://zpcat.blogspot.sg/2013/10/how-b … layer.html
– scanning
– standby
– advertising
– initiating
– connection

full Bluetooth specs:
https://www.bluetooth.com/specification … ifications
https://www.bluetooth.org/DocMan/handle … _id=286439
————–
however the truth is that there are many other protocol stack layers on top of this BLE link layer
e.g. L2CAP (this manages the ‘connections’ and multiplexing to the various endpoints e.g. ATT/GATT, service discovery etc
GAP, service discovery, security (e.g. paring / autentication and encryption negotiation), ATT, GATT (services) themselves etc

while i’ve not gone further, my guess is that these mcu (and the vendor distributed protocol stack) with such extreme limited ram memory e.g. 8k, 16k, 20k most likely only make do with the only basic BLE ‘link layer’ (i.e. the above states) and leaving aside all other protocol stack layers e.g. L2CAP, GAP, etc

this could literally mean that for a lot of BLE devices implemented on such low resources devices possibly make do with little or no security (e.g. no pairing, no encryption (or propriety encryption) etc. i’d think some actual device developers simply ‘hard code’ the PIN lol

Security costs.

I totally agree with bennyboy. Security costs… But a lot of companies dont care about security. They just sell a cheap product, make a fast buck, and then vanish.
I have had to decline to work for several companies, as they did not take security seriously, and it would come back to bite me as I am an independent contractor, and these sorts of companies tend to blame everyone else for their problems.

I would not worry about the internals of bluetooth. It just works, and can be secure if you use the API correctly.

The nRF51822QFAA and QFAB versions only have 16k RAM but are still relatively secure in terms of comms

The Nordic “Softdevice”, which handles the BLE takes about 8k of RAM, and around 128k of flash code space.

Luckily flash is now cheap, so using the QFAA varient, which has 256k flash, still leaves loads of application space, though having only 8k of remaining RAM for the application code, can be restructive.

The QFAC version has 32k RAM, and the newer generation nRF52832 has loads of Ram ( I think it may be 256k)

I am currently using the nRF51 in legacy designs, but will move to the nRF52 for new designs, especially the new nRF52840 which is BLE 5 compliant

actually with our ‘arduino’ kind of custom developments, it is possible to build rudimentary ‘out-of-band’ security e.g. to upload a shared password into the board which can be changed each upload. but i’d imagine that it’s very hard to achieve for mass products except for raising the costs

i think some of the developers resort to pairing ‘when nobody else is around’ methodology that would at least ensure some kind of security as a compromise, sometimes known as ‘just works’ pairing, but i’d think that may add the need for a ‘hard’ reset button