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.
RFduinoBLE.h -> SimbleeBLE.h RFduinoBLE.advertisementInterval -> SimbleBLE.advertisementInterval RFduinoBLE.begin() -> SimbleeBLE.begin() RFduinoBLE_onReceive() -> SimbleeBLE_onReceive() etc.Same goes for the GZLL libraries.
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";This will create the 16 bit UUID for the Service UUID and the Characteristic UUIDs.
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 ExamplesDialSFM - Dial Indicator
SFM_KeyPAD - Numeric KeyPAD
Eddystone for Mobile - Eddystone Beacon
SFMmidi - BLE MIDI
SFMsocket - Simblee Socket
SFMnfc - NFC Near Field Communications
SFM ColorSensor - Rohm's BH1745 Color Sensor
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
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
Use it like this...
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.