Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Tim

Pages: [1] 2
Support / Simblee MSL
« on: May 26, 2017, 06:50:09 PM »
Hi all,

Have been learning all about MSL (Moisture Sensitivity Level). Recently, distributors have been affixing MSL caution labels to the ESD bags Simblees are shipped in, stating level 3. I wrote and received word that Simblee is actually rated MSL 6. This means chips need to be baked (8-12 hours at 125°C) before mounting/reflowing, and following baking, the chips need to be mounted/reflowed within 6 hours.

We've never baked before mounting/reflowing. We've been hand assembling (using stencil to apply solder paste, hand placing components, including Simblee, then reflowing in reflow oven) and have been getting a failure rate of around 1 in 10. I'm waiting for reply from RF Digital with their opinion about the possibility that not baking Simblee before mounting/reflowing is contributing to the failure rate. Although we are not happy to learn about the baking requirement (which increases assembly time and cost), we'll be happy if baking prior to mounting/reflowing reduces our failure rate.

Any experience out there?

Many thanks,


Support / bad Simblee batch?
« on: April 23, 2017, 01:14:33 PM »
Hi ..

Trying to explain why we're getting a high failure rate on assembling our boards. We recently ordered from Mouser and received 30 Simblees packaged as in photo, which means someone handled them to take from factory packaging and place on foam. Also found a label on the anti-static bag containing the Mouser order that have never seen before (see attached photo). Wondering about possible ESD events during handling and shipping that damaged chips. Previously all Simblees came from DigiKey and in original factory packaging and we had a much higher success rate. Wondering if anyone has had issues with Simblees arriving defected from different suppliers.

Appreciate any thoughts, experience.


Simblee Libraries / Simblee library 1.1.1
« on: April 02, 2017, 08:28:19 AM »
Hi ...

I see that Simblee library 1.1.1 is available, but don't see any announcements about it. Anyone aware of details of the update? Release notes?



Support / Simblee assembly and pick'n place machines
« on: March 28, 2017, 11:59:21 AM »
Hi all ..

Currently we're hand assembling our boards. Our PCBs are manufactured by OSH Park. We use stainless steel stencils by OSH Stencil. We use lead-free solder paste by MG Chemicals. We use the Whizoo reflow oven. We're not yet at a quantity that makes automated assembly practical.

The problem is that for about one in 15 boards we hand assemble, the Simblee has an alignment issue or an invisible solder bridge and does not work. It's time consuming to fix.

We are considering desktop pick and place machines both to eliminate this issue and speed up assembly. Does anyone have experience with any of these:

Any others? Thanks for any thoughts, advice.


Support / Simblee assembly
« on: September 26, 2016, 10:14:40 PM »
Hi all,

Writing to share some experience and ask a question. For our product, we are hand-assembling the first 100 or so units. We get our PCBs from OSHPark. We use a stencil from OSHStencil and we're reflowing with a Whizoo reflow oven. Here are some links:

This is working very well except occasionally (1 of 10 boards), the Simblee shifts a bit during the reflow process. I've attached a few photos.

Any thoughts on why this is happening? Normally during reflow, parts will shift into place not out of place. The oven may not be precisely levelled. I wonder about the solder paste connecting the four ground pads under Simblee? When it reflows, could it cause the shifting? Maybe reduce the amount of paste on those pads?

Thanks for any thoughts, advice.


Support / Simblee - optimal GPIO pin selection
« on: May 25, 2016, 09:50:00 PM »
Hello ...

Our product will use Simblee and requires the following IO:

Analog input 1: connected to a phototransistor to read analog light value
Digital input 1: connected to comparator that changes phototransistor analog value to digital 0/1
Digital 2/3: connected to SDA/SCL pins of Maxim’s DS3231 (so DS3231 can be programmed via I2C)
Digital in 4: connected to SQW pin of Maxim’s DS3231 (which, in turn, increments TIMER1 as counter to count seconds)

GPIO 0 and 1 are reserved for programming Simblee (UART).

For SCL/SDA, best to use default GPIO pins 5 and 6?

For phototransistor analog input pin, use any of GPIO 2, 3 or 4?

For digital input pins for comparator output and DS3132 SQW output, use first digital in/out-only pins, GPIO 7 and 8?

Any advantage of using non-adjacent pins? Any other considerations?

Many thanks,


Simblee Libraries / SimbleeBLE affects TIMER1/2 accuracy
« on: May 17, 2016, 06:37:04 PM »
Hi all ...

I've narrowed down a TIMER accuracy issue to BLE. The code below starts and stops TIMER1 (16 bit, prescaler=9) on low-to-hi and hi-to-low, respectively, of a GPIO pin. I'm driving the GPIO pin with a function generator configured to send a 1 second pulse with a period of 2 seconds. An interrupt is called on hi-to-low to print out the counter value.

Given TIMER1 prescaler of 9 (Ftimer = 31250), I should be getting counter values of 31250. This is the case if I comment out the SimbleeBLE.begin() line. But if SimbleeBLE.begin() executes, I see counter values of around 31589 ±3. Same behaviour if I use TIMER2.

I thought TIMER peripherals were not impacted by other system resources. Is there a way to use a different clock source for TIMER1/2 to eliminate the impact of BLE? Any other possibilities to get accurate timers with BLE use?

Code is here:
Code: [Select]
#include <SimbleeBLE.h>

int functionGeneratorPin = 6;

void setup() {
  // Configure TIMER1 as timer
  NRF_TIMER1->TASKS_STOP = 1; // Stop timer
  NRF_TIMER1->MODE = TIMER_MODE_MODE_Timer;  // Set to timer mode
  NRF_TIMER1->PRESCALER = 9;  // overflow is every 2.097152 seconds
  NRF_TIMER1->TASKS_CLEAR = 1;  // Clear the timer
  // Configure GPIOTE channel 0 as event that occurs when functionGeneratorPin pin changes from digital
  // low to high.
              | (functionGeneratorPin << GPIOTE_CONFIG_PSEL_Pos)
              | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);
  // Configure GPIOTE channel 1 as event that occurs when functionGeneratorPin pin changes from digital
  // high to low.
              | (functionGeneratorPin << GPIOTE_CONFIG_PSEL_Pos)
              | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);
  // Interrupt only on high to low.
  // Clear all events.
  // Attach interrupt handler.
  dynamic_attachInterrupt(GPIOTE_IRQn, reportTime);
  // Configure PPI channel 0 to start TIMER1 on low to high.
  simblee_ppi_channel_assign(0, &NRF_GPIOTE->EVENTS_IN[0], &NRF_TIMER1->TASKS_START);
  // Configure PPI channel 1 to stop TIMER1 on high to low.
  simblee_ppi_channel_assign(1, &NRF_GPIOTE->EVENTS_IN[1], &NRF_TIMER1->TASKS_STOP);


void loop() {

void reportTime(void) {
  if (NRF_GPIOTE->EVENTS_IN[1] != 0) {

    // clear event

    // timer has been stopped, capture value

    // get timer value
    unsigned long timerValue = NRF_TIMER1->CC[0];

    // clear timer for next cycle

Thanks for any thoughts, feedback.


Support / accuracy of TIMER1 TIMER2
« on: May 16, 2016, 08:47:00 PM »
Hi all ...

My product uses multiple BLE peripherals (Simblee) communicating with a common BLE central to time events detected via sensors on the different devices. My circuit has a DS3231 (Maxim) to get required accuracy (+/-2ppm). The DS3231 resolution is only 1 Hz, so I'm using its square wave output to drive a GPIO pin, and I use TIMER1 and TIMER2 to implement my own RTC.

TIMER1 is configured as a counter to count seconds, TIMER2 as a free running timer to time time between seconds (prescaler 9). Using GPIOTE and PPI, each time the GPIO pin goes hi (on each pulse from the DS3231):

TIMER1 increments
TIMER2 clears

When an event occurs, I simply capture the timer values. TIMER1 will be current seconds, TIMER2 will be current ticks since last second pulse. With prescaler 9 I divide ticks by 31250 to get seconds and add to the second count to get actual time.

Here's the issue: I'm actually getting 31708 ticks per second from TIMER2 instead of the expected 31250, so I'm trying to determine the accuracy of the timers, with hope that there's a way to increase it.

Here's the code for configuring the timers, PPI, GPIOTE, etc.

Code: [Select]

  // Configure TIMER1 as counter for seconds

  // Configure TIMER2 as free running timer for time between seconds
  // DS3231SQWPin is pulsed every second. Will use PPI to increment TIMER1 (counting seconds)
  // and clear TIMER2 (counting ticks between seconds).
              | (DS3231SQWPin << GPIOTE_CONFIG_PSEL_Pos)
              | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);
  // Configure PPI channel 0 to increment TIMER1 when second pulse takes DS3231SQWPin from low to hi.
  simblee_ppi_channel_assign(0, &NRF_GPIOTE->EVENTS_IN[0], &NRF_TIMER1->TASKS_COUNT);
  // Configure PPI channel 1 to clear TIMER2 when second pulse takes DS3231SQWPin from low to hi.
  simblee_ppi_channel_assign(1, &NRF_GPIOTE->EVENTS_IN[0], &NRF_TIMER2->TASKS_CLEAR);


Support / Simblee getting input voltage
« on: May 16, 2016, 12:49:48 PM »
Hi ..

The Simblee datasheet lists "Battery/Supply voltage monitoring" as a feature. I haven't seen documentation to describe implementing it. For RFduino, we implemented battery level with this code:

Code: [Select]
    unsigned long batteryLevel;
    analogSelection(VDD_1_3_PS);  //Selects VDD with 1/3 prescaling as the analog source
    delay(100);  // Might help with stability of next analogRead
    int sensorValue = analogRead(1); // the pin has no meaning, it uses VDD pin
    float batteryVoltage = sensorValue * (3.6 / 1023.0); // convert value to voltage
    analogSelection(AIN_1_3_PS); // Selects the ananlog inputs with 1/3 prescaling as the analog source
    delay(100);  // Might help with stability of next analogRead
    batteryLevel = batteryVoltage * 1000; // millivolts

This method is not always accurate. Hoping Simblee offers a better solution. We're powering Simblee with 2 AA batteries.

Any experience with this?

Many thanks,


Simblee Libraries / Simblee dual mode (BLE & COM)
« on: April 13, 2016, 04:51:27 PM »
Hi all ..

Does anyone have experience with Simblee's dual mode capability. I simplified the SimbleeBLE/DualMode/Gateway sketch to this:

Code: [Select]
#include <SimbleeBLE.h>

void setup() { 

void loop() {

void SimbleeBLE_onConnect() {

void SimbleeBLE_onDisconnect() {

void SimbleeBLE_onReceive(char *data, int len) {

void SimbleeBLE_onDualModeStart() {

void SimbleeBLE_onDualModeStop() {

void SimbleeCOM_onReceive(unsigned int esn, const char *payload, int len, int rssi) {
  printf("%s\n", payload);

I upload and run the sketch and this happens:

- When an iOS app connects to the Simblee via BLE, the callback SimbleeBLE_onConnect() is called. This callback starts dual mode by calling SimbleeBLE.dualModeBegin().

- This results in the SimbleeBLE_onDualModeStart() callback being called, which prints “1” to the console.

- Unexpectedly, SimbleBLE.onDualModeStop() is called, which prints “0” to the console.

- SimbleeBLE.onDualModeStart() and SimbleeBLE.onDualModeStop() are called again and again, repeatedly, until the iOS app disconnects from the Simblee (and SimbleeBLE_onDisconnect() calls SimbleeBLE.dualModeEnd()).

Furthermore, when I first tried integrating dual mode into our product sketch (which resulted in the same above behaviour), when the sketch attempted to send a message via SimbleeCOM, the SimbleeBLE connection with the iOS app was dropped.

Dual mode is vital to using Simblee in our product. Hopeful for a solution.

Thanks for any insights.


Support / Simblee, GPIO, OTA weirdness
« on: April 13, 2016, 12:13:12 PM »
Hi ...

I'm implementing OTA sketch updates for our Simblee-based product. All is working well, but have experienced some weirdness that I'd like to understand/explain.

Our circuit is simple: a phototransistor reads light input. Output of phototransistor goes directly to Simblee GPIO pin 3 and to the input of a comparator. The comparator output goes to Simblee GPIO pin 2. Our sketch does an analog read of pin 3 to get the analog light value, and it uses GPIOTE, PPI to fire an interrupt when pin 2 goes from low to hi. Our sketch sets both pins to INPUT:

Code: [Select]
const unsigned int photoTransistorPin = 2;      // comparator output pin (for digital read)
const unsigned int photoTransistorAnalogPin = 3;  // phototransistor pin (for analog read)

pinMode(photoTransistorPin, INPUT);
pinMode(photoTransistorAnalogPin, INPUT);

Our sketch includes both SimbleeBLE.h and ota_bootloader.h for OTA sketch updates.

Code: [Select]
#include <SimbleeBLE.h>
#include <ota_bootloader.h>

Our sketch is written so that the only way to put Simblee into DFU target mode (so an OTA update can occur) is by our iOS app sending a specific message to Simblee via SimbleeBLE. So after our app connects to Simblee via SimbleeBLE, the user taps a button to initiate OTA update, which results in our app sending a specific message to Simblee. In our sketch, when that message is received, it calls SimbleeBLE.end() and then ota_bootloader_start(). Simblee then starts advertising as a DFU target. Our iOS app connects and performs the OTA update.

Lastly, I'm using the RFD77201 for testing.

That's the summary of operation. Here's the weirdness. When the comparator out is connected to GPIO pin 5 (and photoTransistorPin is set to 5), Simblee always runs the ota_bootloader when it starts up (unexpected behaviour). Connect the comparator out to GPIO pin 2 or 4 and Simblee runs our sketch when powered up (normal behaviour).

Any explanation?

Many thanks,


Support / Simblee, OTA and flash
« on: April 08, 2016, 07:56:48 PM »
Hi ...

I'm upgrading from RFduino to Simblee in our product with hopes of using a couple new features, including OTA sketch updates. I have it sort of working except running into this problem:

My sketch writes some user specified application data to a flash page (currently page 251). If I comment out that code, all works well. (I'm testing for button-press in the setup routine and, if pressed, call ota_bootloader_start(). If not pressed, execute my app normally, which involves calling SimbleeBLE.begin(), etc.)

Feedback from RFDigital says the following:

"The larger your sketch is, the larger the flash needed to do a ota bootloader, as the way it is set up, is that it saves a copy of the current sketch in flash, and then transfers the new sketch and verifies that it is okay, before deleting the sketch copy.

I would try a page from 124 to 251, as those are available for user data."

So it appears possible that when my sketch writes data to flash page 251, it's overwriting part of the ota boot loader, even though RFDigial says pages 124-251 are for user data. Rather than just trying different flash pages in hopes of finding one that does not conflict, I'm hoping to learn exactly where my sketch (31,152 bytes) and the ota boot loader (its size?) are written so I can be sure I choose a safe page.

Any thoughts?

Many thanks,


Support / can't set value of RTC1?
« on: March 25, 2016, 03:39:33 PM »
Hi ...

In the Nordic docs I see tasks to start, stop and clear RTC1, but none to set its value. Would like to confirm this is not possible.



Support / hand soldering Simblee module?
« on: March 24, 2016, 10:48:23 AM »
Hi ..

I've been hand soldering our product boards, including an RFD22301 with no problems. We're considering switching to Simblee which has much smaller pins.

We will eventually move to automated assembly, but will want to hand solder initially. Any experiences hand soldering the Simblee module? I've been soldering surface mount resistors, caps, etc. using a hot air gun. Works well. Then I'd use a soldering iron with solder paste and flux to solder the RFD22301. See tolson's post here:

Is the Simblee module heat resistant? Can I use hot air or hot plate?

We would consider using the RFD77201 DIP version but it's an extra $20 and occupies more space.

Thanks for any thoughts.


Support / Simblee dual mode
« on: March 24, 2016, 10:36:41 AM »

We're considering upgrading our product to use Simblee instead of RFduino. A key requirement is simultaneous use of both BLE and COMM. We use BLE for communication with an iOS device and we will use COMM for syncing the RTCs on multiple Simblees. (It's a timing product, requiring 1/100th second accuracy.)

Does anyone have any experience with Simblee dual mode, besides floor in this post:

We need low and consistent latency on node communications (COMM) for clock syncing. Inconsistent latency is not an issue for the BLE connection.

Typically 3 Simblees will be used at max separation of around 130 feet.

I will be ordering a few Simblees to test/develop but thought to seek any relevant experiences before doing so.

Many thanks.


Pages: [1] 2