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
1
Support / OTA upload hang with IOS-Pods-DFU-Library
« on: August 27, 2017, 12:59:34 PM »
Hi all,

I've implemented OTA sketch updates for our product using Nordic's iOS library IOS-Pods-DFU-Library (See http://forum.rfduino.com/index.php?topic=1273.msg5793#msg5793 ).

I'm concerned that I may have encountered a sketch size limit that breaks OTA uploading. Consider two different sketches. Sketch A compiles to 34424 bytes of program storage space. End of Arduino log when compiling is:

Code: [Select]
Using library Wire in folder: /Users/timsenger/Library/Arduino15/packages/Simblee/hardware/Simblee/1.1.3/libraries/Wire (legacy)
Using library SimbleeBLE in folder: /Users/timsenger/Library/Arduino15/packages/Simblee/hardware/Simblee/1.1.3/libraries/SimbleeBLE (legacy)
Sketch uses 34424 bytes (26%) of program storage space. Maximum is 131072 bytes.
Global variables use 2668 bytes of dynamic memory.

Sketch B compiles to 38224 bytes of program storage. End of compile log:

Code: [Select]
Using library SimbleeBLE in folder: /Users/timsenger/Library/Arduino15/packages/Simblee/hardware/Simblee/1.1.3/libraries/SimbleeBLE (legacy)
Using library Wire in folder: /Users/timsenger/Library/Arduino15/packages/Simblee/hardware/Simblee/1.1.3/libraries/Wire (legacy)
Sketch uses 38224 bytes (29%) of program storage space. Maximum is 131072 bytes.
Global variables use 2732 bytes of dynamic memory.

If Simblee has sketch A loaded and running, OTA upload works. Log generated by DFU library is:

Code: [Select]
2017-08-27 13:20:30.116 rockhawk[2123:786109] logWith: Connected to simblee
2017-08-27 13:20:30.119 rockhawk[2123:786109] logWith: Discovering services...
2017-08-27 13:20:30.120 rockhawk[2123:786109] logWith: peripheral.discoverServices(nil)
2017-08-27 13:20:30.125 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateConnecting
2017-08-27 13:20:30.126 rockhawk[2123:786109] logWith: Services discovered
2017-08-27 13:20:30.126 rockhawk[2123:786109] logWith: Starting Legacy DFU...
2017-08-27 13:20:30.128 rockhawk[2123:786109] logWith: Connected to simblee
2017-08-27 13:20:30.129 rockhawk[2123:786109] logWith: Services discovered
2017-08-27 13:20:30.130 rockhawk[2123:786109] logWith: Legacy DFU Service found
2017-08-27 13:20:30.131 rockhawk[2123:786109] logWith: Discovering characteristics in DFU Service...
2017-08-27 13:20:30.131 rockhawk[2123:786109] logWith: peripheral.discoverCharacteristics(nil, for: 00001530-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:20:30.374 rockhawk[2123:786109] logWith: DFU characteristics discovered
2017-08-27 13:20:30.375 rockhawk[2123:786109] logWith: Reading DFU Version number...
2017-08-27 13:20:30.376 rockhawk[2123:786109] logWith: peripheral.readValue(00001534-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:20:30.435 rockhawk[2123:786109] logWith: Read Response received from 00001534-1212-EFDE-1523-785FEABCD123, value (0x): 0100
2017-08-27 13:20:30.435 rockhawk[2123:786109] logWith: Version number read: 0.1
2017-08-27 13:20:30.435 rockhawk[2123:786109] logWith: Enabling notifications for 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:30.435 rockhawk[2123:786109] logWith: peripheral.setNotifyValue(true, for: 00001531-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:20:30.436 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateStarting
2017-08-27 13:20:30.554 rockhawk[2123:786109] logWith: Notifications enabled for 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:30.554 rockhawk[2123:786109] logWith: DFU Control Point notifications enabled
2017-08-27 13:20:30.554 rockhawk[2123:786109] logWith: Application with buttonless update found
2017-08-27 13:20:30.555 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:30.555 rockhawk[2123:786109] logWith: peripheral.writeValue(0x0104, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:30.556 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateEnablingDfuMode
2017-08-27 13:20:30.614 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:30.614 rockhawk[2123:786109] logWith: Jump to bootloader (Op Code = 1, Upload Mode = 4) request sent
2017-08-27 13:20:30.826 rockhawk[2123:786109] logWith: [Callback] Central Manager did disconnect peripheral
2017-08-27 13:20:30.826 rockhawk[2123:786109] logWith: Disconnected by the remote device
2017-08-27 13:20:30.827 rockhawk[2123:786109] logWith: Connecting to simblee...
2017-08-27 13:20:30.827 rockhawk[2123:786109] logWith: centralManager.connect(peripheral, options:nil)
2017-08-27 13:20:31.120 rockhawk[2123:786109] logWith: [Callback] Central Manager did connect peripheral
2017-08-27 13:20:31.121 rockhawk[2123:786109] logWith: Connected to simblee
2017-08-27 13:20:31.121 rockhawk[2123:786109] logWith: Discovering services...
2017-08-27 13:20:31.121 rockhawk[2123:786109] logWith: peripheral.discoverServices([00001530-1212-EFDE-1523-785FEABCD123])
2017-08-27 13:20:31.529 rockhawk[2123:786109] logWith: Services discovered
2017-08-27 13:20:31.529 rockhawk[2123:786109] logWith: Legacy DFU Service found
2017-08-27 13:20:31.530 rockhawk[2123:786109] logWith: Discovering characteristics in DFU Service...
2017-08-27 13:20:31.530 rockhawk[2123:786109] logWith: peripheral.discoverCharacteristics(nil, for: 00001530-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:20:31.769 rockhawk[2123:786109] logWith: DFU characteristics discovered
2017-08-27 13:20:31.770 rockhawk[2123:786109] logWith: Reading DFU Version number...
2017-08-27 13:20:31.770 rockhawk[2123:786109] logWith: peripheral.readValue(00001534-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:20:31.829 rockhawk[2123:786109] logWith: Read Response received from 00001534-1212-EFDE-1523-785FEABCD123, value (0x): 0600
2017-08-27 13:20:31.830 rockhawk[2123:786109] logWith: Version number read: 0.6
2017-08-27 13:20:31.830 rockhawk[2123:786109] logWith: Enabling notifications for 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:31.830 rockhawk[2123:786109] logWith: peripheral.setNotifyValue(true, for: 00001531-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:20:31.830 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateStarting
2017-08-27 13:20:31.979 rockhawk[2123:786109] logWith: Notifications enabled for 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:31.979 rockhawk[2123:786109] logWith: DFU Control Point notifications enabled
2017-08-27 13:20:31.980 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:31.980 rockhawk[2123:786109] logWith: peripheral.writeValue(0x0104, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:31.982 rockhawk[2123:786109] logWith: Writing image sizes (0b, 0b, 34376b) to characteristic 00001532-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:31.982 rockhawk[2123:786109] logWith: peripheral.writeValue(0x000000000000000048860000, for: 00001532-1212-EFDE-1523-785FEABCD123, type: .withoutResponse)
2017-08-27 13:20:32.039 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:32.040 rockhawk[2123:786109] logWith: Start DFU (Op Code = 1, Upload Mode = 4) request sent
2017-08-27 13:20:33.809 rockhawk[2123:786109] logWith: Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100101
2017-08-27 13:20:33.809 rockhawk[2123:786109] logWith: Response (Op Code = 1, Status = 1) received
2017-08-27 13:20:33.810 rockhawk[2123:786109] logWith: Writing Initialize DFU Parameters...
2017-08-27 13:20:33.810 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:33.810 rockhawk[2123:786109] logWith: peripheral.writeValue(0x0200, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:33.811 rockhawk[2123:786109] logWith: Writing to characteristic 00001532-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:33.811 rockhawk[2123:786109] logWith: peripheral.writeValue(0xffffffffffff00000100feff0cc0, for: 00001532-1212-EFDE-1523-785FEABCD123, type: .withoutResponse)
2017-08-27 13:20:33.812 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:33.812 rockhawk[2123:786109] logWith: peripheral.writeValue(0x0201, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:33.869 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:33.929 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:33.929 rockhawk[2123:786109] logWith: Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100201
2017-08-27 13:20:33.930 rockhawk[2123:786109] logWith: Response (Op Code = 2, Status = 1) received
2017-08-27 13:20:33.930 rockhawk[2123:786109] logWith: Initialize DFU Parameters completed
2017-08-27 13:20:33.930 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:33.931 rockhawk[2123:786109] logWith: peripheral.writeValue(0x080c00, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:33.931 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateUploading
2017-08-27 13:20:33.989 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:33.989 rockhawk[2123:786109] logWith: Packet Receipt Notif Req (Op Code = 8, Value = 12) request sent
2017-08-27 13:20:33.989 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:33.990 rockhawk[2123:786109] logWith: peripheral.writeValue(0x03, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:34.049 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:34.049 rockhawk[2123:786109] logWith: Uploading firmware...
2017-08-27 13:20:34.049 rockhawk[2123:786109] logWith: Sending firmware DFU Packet characteristic...

2017-08-27 13:20:34.052 rockhawk[2123:786109] dfuProgressDidChangeFor: called repeatedly as sketch uploaded ...

2017-08-27 13:20:47.220 rockhawk[2123:786109] logWith: Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100301
2017-08-27 13:20:47.221 rockhawk[2123:786109] logWith: Response (Op Code = 3, Status = 1) received
2017-08-27 13:20:47.221 rockhawk[2123:786109] logWith: Upload completed in 13.17 seconds
2017-08-27 13:20:47.222 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:47.222 rockhawk[2123:786109] logWith: peripheral.writeValue(0x04, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:47.223 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateValidating
2017-08-27 13:20:47.280 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:47.280 rockhawk[2123:786109] logWith: Validate Firmware (Op Code = 4) request sent
2017-08-27 13:20:47.310 rockhawk[2123:786109] logWith: Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100401
2017-08-27 13:20:47.311 rockhawk[2123:786109] logWith: Response (Op Code = 4, Status = 1) received
2017-08-27 13:20:47.311 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:20:47.312 rockhawk[2123:786109] logWith: peripheral.writeValue(0x05, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:20:47.312 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateDisconnecting
2017-08-27 13:20:47.370 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:20:47.370 rockhawk[2123:786109] logWith: Activate and Reset (Op Code = 5) request sent
2017-08-27 13:20:47.579 rockhawk[2123:786109] logWith: [Callback] Central Manager did disconnect peripheral
2017-08-27 13:20:47.579 rockhawk[2123:786109] logWith: Disconnected by the remote device
2017-08-27 13:20:47.580 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateCompleted

But if Simblee has sketch B loaded and running, OTA upload hangs on a call to connect to the peripheral:

Code: [Select]
2017-08-27 13:28:33.390 rockhawk[2123:786109] logWith: Connected to simblee
2017-08-27 13:28:33.391 rockhawk[2123:786109] logWith: Discovering services...
2017-08-27 13:28:33.391 rockhawk[2123:786109] logWith: peripheral.discoverServices(nil)
2017-08-27 13:28:33.394 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateConnecting
2017-08-27 13:28:33.395 rockhawk[2123:786109] logWith: Services discovered
2017-08-27 13:28:33.396 rockhawk[2123:786109] logWith: Starting Legacy DFU...
2017-08-27 13:28:33.396 rockhawk[2123:786109] logWith: Connected to simblee
2017-08-27 13:28:33.397 rockhawk[2123:786109] logWith: Services discovered
2017-08-27 13:28:33.397 rockhawk[2123:786109] logWith: Legacy DFU Service found
2017-08-27 13:28:33.397 rockhawk[2123:786109] logWith: Discovering characteristics in DFU Service...
2017-08-27 13:28:33.398 rockhawk[2123:786109] logWith: peripheral.discoverCharacteristics(nil, for: 00001530-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:28:33.641 rockhawk[2123:786109] logWith: DFU characteristics discovered
2017-08-27 13:28:33.642 rockhawk[2123:786109] logWith: Reading DFU Version number...
2017-08-27 13:28:33.642 rockhawk[2123:786109] logWith: peripheral.readValue(00001534-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:28:33.701 rockhawk[2123:786109] logWith: Read Response received from 00001534-1212-EFDE-1523-785FEABCD123, value (0x): 0100
2017-08-27 13:28:33.702 rockhawk[2123:786109] logWith: Version number read: 0.1
2017-08-27 13:28:33.702 rockhawk[2123:786109] logWith: Enabling notifications for 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:28:33.702 rockhawk[2123:786109] logWith: peripheral.setNotifyValue(true, for: 00001531-1212-EFDE-1523-785FEABCD123)
2017-08-27 13:28:33.703 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateStarting
2017-08-27 13:28:33.821 rockhawk[2123:786109] logWith: Notifications enabled for 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:28:33.821 rockhawk[2123:786109] logWith: DFU Control Point notifications enabled
2017-08-27 13:28:33.822 rockhawk[2123:786109] logWith: Application with buttonless update found
2017-08-27 13:28:33.822 rockhawk[2123:786109] logWith: Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
2017-08-27 13:28:33.823 rockhawk[2123:786109] logWith: peripheral.writeValue(0x0104, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
2017-08-27 13:28:33.823 rockhawk[2123:786109] dfuStateDidChangeTo: DFUStateEnablingDfuMode
2017-08-27 13:28:33.881 rockhawk[2123:786109] logWith: Data written to 00001531-1212-EFDE-1523-785FEABCD123
2017-08-27 13:28:33.882 rockhawk[2123:786109] logWith: Jump to bootloader (Op Code = 1, Upload Mode = 4) request sent
2017-08-27 13:28:34.095 rockhawk[2123:786109] logWith: [Callback] Central Manager did disconnect peripheral
2017-08-27 13:28:34.095 rockhawk[2123:786109] logWith: Disconnected by the remote device
2017-08-27 13:28:34.096 rockhawk[2123:786109] logWith: Connecting to simblee...
2017-08-27 13:28:34.096 rockhawk[2123:786109] logWith: centralManager.connect(peripheral, options:nil)

It doesn't seem to matter which sketch is being uploaded (A or B). When Simblee has sketch A loaded and running, my app can upload either A or B via OTA. When Simblee has sketch B loaded and running, app hangs (as above) when attempting to upload either A or B via OTA. In fact, when Simblee has sketch B loaded and running, app fails to upload OTA the following minimal sketch:

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

void setup() {
  // put your setup code here, to run once:
  SimbleeBLE.begin();
}

void loop() {
  // put your main code here, to run repeatedly:

}


There are many differences in the sketches A and B, besides size, but I'd like to first rule out the possibility that I've hit the sketch upper size limit before investigating further.

Any experiences, insights?

Many thanks,

Tim

2
Support / dualMode for BLE+COM
« on: July 15, 2017, 05:36:14 PM »
Hi all ...

RDF_Nelson posted a video tutorial on using dual mode on January 12th in the Videos/Guides/Tutorials section and I posted this as a reply there. Thought more of you might see it here though. Hope it's okay to post here also.

Seeing the video sparked some hope that dual mode might be helpful for our project. I can get COM<->COM working, no problem. But BLE+dualMode+COM <-> COM, as shown in the video, appears not to work.

I created very simple sketches to test: Once (sender) sends a COM message every second. The other (replier) sends a reply COM message half a second after receiving a COM message. The replier is straight COM. If the sender is straight COM, all works well. Here are the sender and replier sketches:

Sender - straight COM:

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

void setup() {
  Serial.begin(9600);
  SimbleeCOM.mode = LONG_RANGE;
  SimbleeCOM.begin();
}

void loop() {
  delay(1000);
  SimbleeCOM.send("ABC", 4);
  Serial.println("sent ABC");
}

void SimbleeCOM_onReceive(unsigned int esn, const char *payload, int len, int rssi) {
  Serial.print("received ");
  Serial.println(payload);
}

The replier - straight COM:

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

volatile bool sendAReply = false;

void setup() {
  Serial.begin(9600);
  SimbleeCOM.mode = LONG_RANGE;
  SimbleeCOM.begin();
}

void loop() {
  if (sendAReply) {
    sendAReply = false;
    // Wait half a second before sending reply.
    delay(500);
    SimbleeCOM.send("DEF", 4);
    Serial.println("sent DEF");
  }
}

void SimbleeCOM_onReceive(unsigned int esn, const char *payload, int len, int rssi)
{
  Serial.print("received ");
  Serial.println(payload);
  // Send a reply in loop().
  sendAReply = true;
}

If I replace the sender (straight COM) with a sender that uses BLE plus dualMode COM, the replier does not receive any COM messages from the sender. I've also verified that the sender (BLE+dualMode COM) does not receive COM messages.

Sender - BLE+dualMode:

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

volatile bool sendAMessage = false;

void setup() {
  Serial.begin(9600);
  SimbleeCOM.mode = LONG_RANGE;
  SimbleeBLE.begin();
}


void loop() {
  // Send a message every second.
  delay(1000);
  sendAMessage = true;
}


void SimbleeBLE_onConnect() {
 
  // Once connected to BLE central, start dual mode.
  // SimbleeBLE_onDualModeStart() / SimbleeBLE_onDualModeStop() will be called
  // repeatedly. Only inside SimbleeBLE_onDualModeStart() is it safe to send
  // a COM message (my understanding).
 
  SimbleeBLE.dualModeBegin();
  Serial.println("dual mode started");
}


void SimbleeBLE_onDisconnect() {

  // When disconnected from BLE central, stop dual mode.
  SimbleeBLE.dualModeEnd();
  Serial.println("dual mode ended");
}


void SimbleeBLE_onDualModeStart() {
  // SimbleeBLE_onDualModeStart is called frequently. Send a message only
  // when sendAMessage is true (once a second, see loop()).
  if (sendAMessage) {
    sendAMessage = false;
    SimbleeCOM.send("ABC", 4);
    Serial.println("sent ABC");
  }
}


void SimbleeCOM_onReceive(unsigned int esn, const char *payload, int len, int rssi) {
  Serial.print("received ");
  Serial.println(payload);
}

As you can see, when using dualMode, SimbleeCOM.send() can be only in the SimbleeBLE_onDualModeStart() routine.

Anyone have any better luck? I will send this to RF Digital support.

The ideal for our project would be:

- A single BLE central (iOS app) connects to 3 Simblees and uses BLE to communicate with them.
- Periodically, one of the Simblees, while still connected to BLE central, sends low latency COM message to other two Simblees, also while still connected to BLE central.

Currently when periodic COM messaging is needed, Simblees are disconnected from BLE central, COM messaging occurs, then all 3 Simblees are reconnected to BLE central. Unfortunately the reconnection process can take a while so that the whole process (disconnect, COM messaging, reconnect) takes as long as 10-15 seconds, sometimes longer.

We choose Simblee on the bases that simultaneous BLE+COM messaging was supported. The how-to video posted by RFD_Nelson gives me hope that it actually might work.

Thanks for any insights.

Cheers,

Tim

3
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 support@rfdigital.com 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,

Tim

4
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.

Tim

5
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?

Thx,

Tim

6
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:

https://www.botfactory.co
http://www.liteplacer.com
http://visionbot.net
https://www.manncorp.com/component-placement-and-handling/manual-pick-and-place

Any others? Thanks for any thoughts, advice.

Tim

7
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:

https://oshpark.com
https://www.oshstencils.com
http://www.whizoo.com

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.

Tim

8
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,

Tim

9
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() {
 
  Serial.begin(9600);
 
  delay(1000);
 
  pinMode(functionGeneratorPin,INPUT);
 
  // 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
  NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_16Bit;  // Set to 16 bit
 
  // Configure GPIOTE channel 0 as event that occurs when functionGeneratorPin pin changes from digital
  // low to high.
  NRF_GPIOTE->CONFIG[0] =  (GPIOTE_CONFIG_POLARITY_LoToHi << GPIOTE_CONFIG_POLARITY_Pos)
              | (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.
  NRF_GPIOTE->CONFIG[1] =  (GPIOTE_CONFIG_POLARITY_HiToLo << GPIOTE_CONFIG_POLARITY_Pos)
              | (functionGeneratorPin << GPIOTE_CONFIG_PSEL_Pos)
              | (GPIOTE_CONFIG_MODE_Event << GPIOTE_CONFIG_MODE_Pos);
 
  // Interrupt only on high to low.
  NRF_GPIOTE->INTENCLR = GPIOTE_INTENSET_IN0_Msk;
  NRF_GPIOTE->INTENSET = GPIOTE_INTENSET_IN1_Msk;
 
  // Clear all events.
  NRF_GPIOTE->EVENTS_IN[0] = 0;
  NRF_GPIOTE->EVENTS_IN[1] = 0;
  NRF_GPIOTE->EVENTS_IN[2] = 0;
  NRF_GPIOTE->EVENTS_IN[3] = 0;
 
  // 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);

  SimbleeBLE.begin();
}


void loop() {
 
}



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

    // clear event
    NRF_GPIOTE->EVENTS_IN[1] = 0;

    // timer has been stopped, capture value
    NRF_TIMER1->TASKS_CAPTURE[0] = 1;

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

    // clear timer for next cycle
    NRF_TIMER1->TASKS_CLEAR = 1;
   
    Serial.println(timerValue);
   
  }
}

Thanks for any thoughts, feedback.

Tim

10
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]
  lowPowerClockSource(LPCS_XTAL);

  // Configure TIMER1 as counter for seconds
  NRF_TIMER1->TASKS_STOP = 1;
  NRF_TIMER1->MODE = TIMER_MODE_MODE_Counter;
  NRF_TIMER1->TASKS_CLEAR = 1;
  NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_16Bit;
  NRF_TIMER1->TASKS_START = 1;

  // Configure TIMER2 as free running timer for time between seconds
  NRF_TIMER2->TASKS_STOP = 1;
  NRF_TIMER2->MODE = TIMER_MODE_MODE_Timer;
  NRF_TIMER2->BITMODE = TIMER_BITMODE_BITMODE_16Bit;
  NRF_TIMER2->PRESCALER = 9;
  NRF_TIMER2->TASKS_CLEAR = 1;
  NRF_TIMER2->TASKS_START = 1;
 
  // DS3231SQWPin is pulsed every second. Will use PPI to increment TIMER1 (counting seconds)
  // and clear TIMER2 (counting ticks between seconds).
  NRF_GPIOTE->CONFIG[0] =  (GPIOTE_CONFIG_POLARITY_LoToHi << GPIOTE_CONFIG_POLARITY_Pos)
              | (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);
Thanks,

Tim

11
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,

Tim

12
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() { 
  Serial.begin(9600);
  SimbleeBLE.begin();
}

void loop() {
}

void SimbleeBLE_onConnect() {
  SimbleeBLE.dualModeBegin();
}

void SimbleeBLE_onDisconnect() {
  SimbleeBLE.dualModeEnd();
}

void SimbleeBLE_onReceive(char *data, int len) {
}

void SimbleeBLE_onDualModeStart() {
  Serial.println("1");
}

void SimbleeBLE_onDualModeStop() {
  Serial.println("0");
}

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.

Tim

13
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,

Tim

14
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,

Tim

15
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.

Thx,

Tim

Pages: [1] 2
anything