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.


Messages - Tim

Pages: [1] 2 3 ... 9
1
Support / Re: OTA upload hang with IOS-Pods-DFU-Library
« on: August 29, 2017, 04:09:38 PM »
Found the culprit. For normal operation, our Simblee app uses RTC1 and it is normally in the stopped state. It responds to two different GPIO events to start/stop and accurately measure time between the events. OTA DFU must rely on RTC1 and seems it expects it to be started. If just prior to initiating OTA DFU, sketch starts RTC1 (NRF_RTC1->TASKS_START = 1;), all works okay.

Thanks,

Tim

2
Support / Re: OTA upload hang with IOS-Pods-DFU-Library
« on: August 29, 2017, 08:47:55 AM »
Hi ...

I think I found the issue. The larger sketch B uses TIMER1, TIMER2, RTC1 and PPI for precise timing functions. (Sketch A does the same but does not use as many PPI channels.) If I comment out the code that configures this, OTA upload works. Looks like our iOS app will have to send a message to Simblee to deconfigure timers and PPI prior to initiating OTA upload. I assumed that booting the OTA bootloader would reset Simblee. Perhaps not the case.

Will post more detail once discovered.

Tim


3
Support / Re: OTA upload hang with IOS-Pods-DFU-Library
« on: August 28, 2017, 06:39:13 PM »
Thanks Wayne. That was a copy/paste typo on my part. Order of those lines is the same for both compile logs. Thanks for pointing out though. Hoping to hear something from RF Digital support.

Cheers,

Tim

4
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

5
Thanks Nelson. I posted additional info in this thread:

http://forum.rfduino.com/index.php?topic=1782.msg6407#msg6407

Might be helpful to others.

Tim

6
Support / Re: dualMode for BLE+COM
« on: July 19, 2017, 11:15:56 PM »
I have clarity on this, thanks for replies from RF Digital support. This supplements info at:

http://forum.rfduino.com/index.php?topic=1357.0

When Simblee is connected to a BLE central and is in dualMode, it gives 10 ms slices of time to COM. This is enough time to send a COM message in LOW_LATENCY mode (3 ms latency) and receive an immediate reply from a receiving Simblee. Therefore, dualMode works only for LOW_LATENCY COM.

The only configuration of Simblees that dualMode works for is where you have one Simblee acting as a gateway, and one or more as nodes. The gateway can be connected to a BLE central and, via dualMode, also do COM messaging with one or more nodes. The nodes must use straight COM; they cannot maintain BLE connection. AND, while a COM message sent from the gateway (in between calls to its SimbleeBLE_onDualModeStart() and SimbleeBLE_onDualModeStop() routines) is broadcast to all nearby Simblees with COM stack started, only a single node can reply to the gateway, and it must do so immediately so the reply message reaches the gateway before the end of the 10 ms COM slice in which the original message was sent from the gateway.

This limits the use cases for Simblee's dualMode, but I can imagine there are many where it is very useful.

Hope helpful ...

Tim

7
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

8
Hi all ...

Seeing the how-to video spark more hope that dual mode might be helpful for our project. I can get COM<->COM working, no problem. But BLE+dualMode <-> 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

9
You can also set the device name before starting BLE:

Code: [Select]
  SimbleeBLE.deviceName = "myName";
  SimbleeBLE.begin();
(We use Simblee, but works the same with RFduino.)

In our product, we actually allow the user to set the device name. It defaults to a generic name (using method above), then once connected to our iOS app, the app presents UI allowing the user to change the name. Then the iOS app sends message to device with new name and sketch writes the new name to flash, disconnects, then restarts BLE. The next time a central (iOS app) connects, Simblee advertises using the new name.

Hope helpful ...

Tim

10
Support / Re: Simblee MSL
« on: June 17, 2017, 10:06:18 PM »
A quick update ... We've now hand assembled 21 boards with 0% failure. These boards do not have pads for unused Simblee pins. We also assembled 3 boards that have pads for all Simblee pins with 0% failure. It's starting to look clear that moisture (i.e. not pre-baking before reflowing) has been the cause of our high failure rate. What a relief to have solved the mystery.

It's not clear to me if there's an advantage either way to keeping or removing pads on board for unused Simblee pins.

Thanks all for your contributions to this thread.

Tim

11
Support / Re: Simblee MSL
« on: June 09, 2017, 09:07:46 AM »
Hi Wayne,

We're in Alberta, Canada. Definitely dry in the winter. Interestingly, as spring approached, our failure rate increased significantly - more evidence that moisture has been our issue.

We hand assemble our boards. We use oshpark.com as our board fab, oshstencil.com for stainless steel stencils. We apply solder paste, hand place SMD parts (including Simblee) then reflow in whizoo.com reflow oven. We use a USB microscope to be sure Simblee is accurately placed on pads. We've added copper registration marks for Simblee on our PCB to aid in positioning because silkscreen is not always precisely positioned relative to the copper pads.

RF Digital support is stressing bake before use as per MSL 6.

Hope helpful ...

Tim

12
Support / Re: Simblee MSL
« on: June 08, 2017, 05:14:09 PM »
Thanks Patty. I've read in some of your other posts that life at Simblee/RF/Heptagon/... has been rather busy, so I understand it taking time to get to certain things. I'll quickly point out that:

- Your current data sheet says MSL rating is TBD.

- Your distributors are classifying Simblee as MSL 3.

If moisture is in fact the cause of our assembly failures, we could have saved a lot of money (20-30 Simblees damaged as a result) had we known Simblee is MSL 6 at the start.

Glad we've likely found the culprit in our process. Thank you for your confirmation.

Tim

13
Support / Re: Simblee MSL
« on: June 05, 2017, 08:37:29 PM »
A bit of new information. We recently assembled 10 boards containing Simblee with 0% fail rate. Two things were different:

1) We used PCBs with pads for unused Simblee pins removed (less chance of solder bridging).

2) We pre-baked Simblees for 8 hours at 125°C.

We speculate that pre-baking is the change that brought improvement. Next we will assemble some boards with all Simblee pads and, again, pre-bake prior to reflow. If success, then more evidence that pre-baking is essential.

14
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

15
Support / Re: hand soldering Simblee module?
« on: May 25, 2017, 08:16:00 AM »
Hi Anthony,

You might find this thread helpful:

http://forum.rfduino.com/index.php?topic=1735.0

Cheers,

Tim

Pages: [1] 2 3 ... 9