HINT: Anything you can do with RFduino you can do with Simblee! This is done by changing the RFduino Library calls to Simblee calls. And many of the examples have done just that.

For Example:

RFduinoBLE.h -> SimbleeBLE.h
RFduinoBLE.advertisementInterval -> SimbleBLE.advertisementInterval
RFduinoBLE.begin() -> SimbleeBLE.begin()
RFduinoBLE_onReceive() -> SimbleeBLE_onReceive()
etc.

RFduinoGZLL.h -> SimbleeGZLL.h
RFduinoGZLL.begin() -> SimbleeGZLL.begin()

The Simblee has new 16 bit BT SIG Service UUID (FE84) and 128 bit characteristics UUIDs. Several of the RFduino BLE examples(ColorWheel, Temp, Servo, LED Button) require a APP from the App store that don't exist. They do for the RFduino, so one more change can be done to utilize the RFduino App Store examples.

In the sketches setup() add this line...

SimbleeBLE.customUUID = "2220";

The Simblee includes many more features which are not backward compatible with RFduino.

The RFduino uses nRF51822 revision 1 silicon. The Simblee uses nRF51822 revision 3 silicon. So it has more hardware features that could be utilized.

The RFduino silicon can only be used as a peripheral device. The Simblee silicon can be used as a peripheral, central, or both.

It is yet to be seen how a Simblee Central device can communicate with a RFduino or any other peripheral devices.

The Simblee Library does not have support for Central. Use Nordic SDK, or MBED instead for that support.

The Simblee can embed APP code in the sketch to be excuted on a smart device. This new mode, "Simblee For Mobile" (SFM), uses yet another registered BT SIG UUID (FE85). This is similar to the way Evothings/Cordova works, except the UI (User Interface) code is stored in the sketch instead of on a remote filesystem. In both cases the technigue allows one to have ONE APP on the APP stores that becomes any of many APPs. No more cluttering the APP stores and smart devices with boocoo separate APPs. Basically, the concept is a APPs UI is stored in the BLE device and uploaded to the interpreting APP on the smart device when accessed.

Simblee for Mobile Examples

RFduino(2220) -> SimbleeBLE (fe84)
2220-0000-1000-8000-00805f9b34fb -> fe84-0000-1000-8000-00805f9b34fb

2221 -> 2d30c082-f39f-4ce6-923f-3484ea480596
2222 -> 2d30c083-f39f-4ce6-923f-3484ea480596
2223 -> 2d30c084-f39f-4ce6-923f-3484ea480596

SimbleeForMobile (fe85)
Hmmm! Different Primary again, but the 2221,2222,2223 equiv are same as SimbleeBLE.
2221 -> 2d30c082-f39f-4ce6-923f-3484ea480596
2222 -> 2d30c083-f39f-4ce6-923f-3484ea480596
2223 -> 2d30c084-f39f-4ce6-923f-3484ea480596

Using Custom UUIDs

The customUUID command can be used to create custom ServiceUUIDs. However the characteristic UUIDs can not be customised. Also multiple custom Service UUIDs can not be created.

When a custom Service UUID is created, the characteristic UUIDs are automatically created and seem to be created sequentially. The algorithm for this feature seems to be built into the chips firmware and not changable via the Arduino IDE.

To produce BT SIG BLE standard services one has to blow away the Simblee bootloader/firmware/SoftDevice and create the App using MBED or Nordic SDK/libraries.

Using TIMERS at low level is a good way to get signals that are independant of the Radio. However, there is perceived stability issue when the Radio is used. The issue arises from the SoftDevice changing the source of the system master clock from the 16Mhz HF crystal to the internal 32kHz crystal derived oscillator in an effort to lower total power drain. Unforntunately, the accuracy or precision of that oscillator is low and different than that of the HF crystal. The SoftDevice gives you the option to override this presumption, but the Simblee did not provide that call until version 1.1.0. Here are the new calls to insure your precision TIMER based routines are predictable regardless of the use of the radio.

SimbleeBLE_requestHFCLK();		// Force use of HF crystal
SimbleeBLE_checkHFCLK(&isRunning);	// Verify if HF crystal running

	
uint32_t isRunning = 0;

   SimbleeBLE.begin();		// Start Radio
   SimbleeBLE_requestHFCLK();	// Select HF crystal

   // Wait for Crystal
   while(!isRunning) SimbleeBLE_checkHFCLK(&isRunning);

   // Then proceed as normal

Simblee uses Nordics nRF51 generation 3 silicon. It has 2 SPI ports The default pin assignments for SPI are the same as for the RFduino.

#define SPI_INTERFACE        NRF_SPI0
#define PIN_SPI_SS           (6u)
#define PIN_SPI_MOSI         (5u)
#define PIN_SPI_MISO         (3u)
#define PIN_SPI_SCK          (4u)

#define SS    PIN_SPI_SS
#define MOSI  PIN_SPI_MOSI
#define MISO  PIN_SPI_MISO
#define SCK   PIN_SPI_SCK

The Simblee default pin assignments for SPI2 since it was made available in the library 1.0.3 through 1.1.0 are...

#define SPI_INTERFACE_2        NRF_SPI1
#define PIN_SPI_SS_2           (14u)
#define PIN_SPI_MOSI_2         (13u)
#define PIN_SPI_MISO_2         (20u)
#define PIN_SPI_SCK_2          (10u)

#define SS2    PIN_SPI_SS_2
#define MOSI2  PIN_SPI_MOSI_2
#define MISO2  PIN_SPI_MISO_2
#define SCK2   PIN_SPI_SCK_2

Warning! The Simblee default pin assignent for SPI2 changed with 1.1.1, 1.1.2, and 1.1.3. So you have to be aware of how your legacy boards are wired for SPI2.

#define SPI_INTERFACE_2        NRF_SPI1
#define PIN_SPI_SS_2           (20u)
#define PIN_SPI_MOSI_2         (23u)
#define PIN_SPI_MISO_2         (21u)
#define PIN_SPI_SCK_2          (24u)

#define SS2    PIN_SPI_SS_2
#define MOSI2  PIN_SPI_MOSI_2
#define MISO2  PIN_SPI_MISO_2
#define SCK2   PIN_SPI_SCK_2

It is probably easiest to change the values back in the variants.h file for your project.