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 ... 8
1
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

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

4
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

5
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

6
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

7
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

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

9
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

10
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

11
Support / Re: Simblee assembly and pick'n place machines
« on: May 25, 2017, 08:08:03 AM »
Some new information to share ...

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. I'm waiting for reply from RF Digital with their opinion about this possibly contributing to the failure rate we are experiencing. 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

12
Support / Re: Simblee assembly and pick'n place machines
« on: May 14, 2017, 01:49:45 PM »
Thanks Tom.

Another change in our process is to attach the programming header to the board before applying power to the USB shield. I understand damage can occur if I/O pins are connected before power is applied. The theory is beyond me, but I've learned this from a trusted source.

Tim

13
Support / Re: Simblee assembly and pick'n place machines
« on: May 14, 2017, 08:54:20 AM »
Some additional ideas in attempt to improve our hand assembly yield.

1) Change I/O pin assignment to reduce number of adjacent pins in use.

2) Remove from PCB any pads for Simblee pins not in use.

Reasonable?

Also, we've cleaned up our handling procedures to eliminate ESD events that could damage chips.

Thanks,

Tim

14
Support / Re: bad Simblee batch?
« on: April 24, 2017, 02:21:25 PM »
We'll be receiving more Simblees from DigiKey tomorrow and will be assembling. Results will be revealing. I also noticed different colour, but that could be because of rework. These are chips that were removed from boards after failure.

We recently ordered from Mouser because they were $3 cheaper. It could be coincidental that we started having assembly issues with this batch. Will post more here as we learn.

Thanks!

15
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

Pages: [1] 2 3 ... 8
anything