Author Topic: Simblee vs Nordic nRF: Pros and Cons  (Read 2529 times)

JackN

  • RFduino Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Simblee vs Nordic nRF: Pros and Cons
« on: February 24, 2016, 06:42:09 AM »
Hello everyone, I'd like to start an objective discussion for which boards to use for prototyping and Version 1 product launch for a start-up project.

For prototyping, we're looking to modify existing app example to start with.
I like the Simblee, it's fairly straight forward. However having to code everything from the ground up is resource intensive.

In comparison, Nordic Semiconductors have a wide community for support, and their ready made app already have more functionalities.
For example:
nRF Temp app has data logging, graphing, and connections to multiple sensors.

What are your opinions guys?

tolson

  • Global Moderator
  • *****
  • Posts: 866
  • Karma: +20/-0
    • View Profile
    • Thomas Olson Consulting
Re: Simblee vs Nordic nRF: Pros and Cons
« Reply #1 on: February 24, 2016, 03:17:47 PM »
It depends, of course. If you are happy with basic widgets like buttons, sliders, text boxes, etc, typically seen with the Nordic and RFdigital examples, then the Simblee for Mobile is pretty easy to set up and 'eliminates' the need to create your own iOS/Android apps to go with it.

If you are looking to create your own characteristic UUIDs or BLE SIG Services defined characteristic UUIDs then the Nordic SDK or MBED is the way to go. Even so, the Simblee QFN module itself is fantastically smaller than anything in existance.

If you want really cool 2D/3D graphics and plots, then Evothings/Cordova is the way to go making it easier to create the needed iOS/Android apps to go with. This approach does require knowledge of HTML5, CSS3, and Javascript instead of knowing Java and Xcode and whatever else that entails.

Have fun with whatever approach you pick.



VLorz

  • RFduino Full Member
  • ***
  • Posts: 68
  • Karma: +2/-0
    • View Profile
Re: Simblee vs Nordic nRF: Pros and Cons
« Reply #2 on: March 24, 2016, 03:43:53 AM »
I was checking for simblee prices to include one of these modules in a new application and got surpriced, it almost doubles most competitor prices. My intention is using Nordic's SDK for this application.

I came across a module from Taiyo Yuden, the EYAGJNZXX, that includes one nRF51422, measures only 11.3 x 5.1 x 1.3 mm, and costs $12.34/unit in Mouser (ref: 963-EYAGJNZXX).

Have you had any experience with other modules like that one?
Regards, Victor

bsiever

  • RFduino Full Member
  • ***
  • Posts: 89
  • Karma: +4/-0
    • View Profile
Re: Simblee vs Nordic nRF: Pros and Cons
« Reply #3 on: March 24, 2016, 06:02:01 AM »
graphing

For what it's worth, I've made a primitive bar graph library for SimbleeForMobile.  A zip file that can be imported in the Arduino environment is available at: https://github.com/bsiever/SimbleeForMobile-BarGraph/blob/master/SimbleeForMobile-BarGraph.zip?raw=true. (And the GitHub Repo is at: https://github.com/bsiever/SimbleeForMobile-BarGraph)

In the next few days I'll try to post some links here in the forum to examples and demos showing how I've used the bar graph library.

For quick proof-of-concept projects I really like the Simblee, but it has limitations that can be overcome with lower level access.  The nRF has lots of examples, but it really does take quite a while to learn all the ins and outs of BLE, the Nordic APIs, and Mobile Development.  Depending on the project, I like this approach: 
  • Use SimbleeForMobile for a quick proof-of-concept of both the hardware and App
  • Migrate to SimbleBLE and continue using the Simblee for hardware, but use a higher quality app (native API or Cordova, etc.)
  • Replace the Simble hardware with an alternative using a comparable two-characteristic Service (communication protocol) to the Simblee
  • Refine the Service as needed

  Bill

Update:
Thanks to some feedback from Tom, I've updated the Bar Graph Library.  It should work a little better "out of the box".

There are still issues if you want to restore an existing graph on a new connection (rather than starting a new graph).  I need to do more review, but based on my initial tests this may be due to Simblee behavior rather than an error in the library.

« Last Edit: March 26, 2016, 04:12:18 PM by bsiever »