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

Pages: [1] 2
Support / Re: Simblee GZLL performs worse than RFduino GZLL?
« on: April 10, 2017, 05:11:07 AM »
Hi mjkuwp94,

Thanks for posting this, we'll take a look at the new data. Try something for me please, add SimbleeCOM.mode = LOW_LATENCY; in your setup() before you start SimbleeCOM, and let me know what you get for packet timings.

Support / Re: Simblee GZLL performs worse than RFduino GZLL
« on: April 07, 2017, 04:59:39 AM »
Engineering has taken a look at the sketch and we have a few questions:

1. How far apart are the two Simblee's? How far apart are the two RFduinos?
2. According to your results, the Simblee communication is much more stable than the RFduino in terms of jitter. What happens if you increase the packet timing? Every 10ms? 20ms? Does everything come across ok on both devices?
3. What is the cutoff timing that you're seeing? You said the RFduino seems to be able to do 3ms, do you have an excel sheet with results for that timing? How about on the Simblee?

SimbleeCOM is a highly-optimized protocol for sending data between many, many devices on a Simblee network. You could easily broadcast information with 3ms packet latency and 10us jitter to over 100 nodes, or more!

I see that you already have SimbleeCOM functionality built in to your sketch, have you tried this same demo using SimbleeCOM?

You said that you didn't want to go down that rabbit hole, but I highly recommend that you take a look. We would be happy to help in any way we can! There are videos on our YouTube channel (, and in this forum, along with code that shows how to utilize SimbleeCOM, and we have many knowledgable users that I'm sure would be willing to chime in as well!

Again, I'm sorry for the delay in response, I look forward to hearing back from you!

Support / Re: Simblee GZLL performs worse than RFduino GZLL
« on: April 07, 2017, 04:38:24 AM »
Hi mjkuwp94,

I apologize for the delay in response. Our Engineering team is taking a look at your example code (thanks!).

Hi tolson,

At the moment, SFM doesn't support pulling sensor data from the device, but it is something that we've been asked about, and are looking into support for this feature.

Simblee For Mobile / Re: Simblee with Android 7.0 failing
« on: March 28, 2017, 04:38:56 AM »
Hey everyone,

Thanks for your patience as we push a new release. As you have found, building a release that supports every device can be challenging. We currently have a new release in beta, and are working on fixing any bugs that appear. We could use the help of the community to test this on different devices with their own edge cases so that we can quickly and accurately squash bugs.

Please continue posting on the forum or send us an email if you find any behavior that seems "off". We'd be happy to take a look at it.

Again, thank you for your patience as we work through the Android update to bring you a quality, stable, and tested product!


Hi Wayne,

You can use an unlimited number of devices with SimbleeCOM. Here's a sample sketch that you could load on one of your devices to speak with the host when a button is pushed:

Code: [Select]
uint8_t buttonA = 5;
char node = 'A';

void setup() {
  pinMode(buttonA, INPUT);
  SimbleeCOM.mode = LOW_LATENCY;

void loop() {
  if (digitalRead(buttonA)) {
    SimbleeCOM.send(node, 1);

NOTE: This is an extremely simple sketch to simply show you the basics of using SimbleeCOM. Please also check out the SimbleeCOM examples in the Simblee package.

Getting Started / Re: RFDuino ULP comsumption
« on: March 23, 2017, 10:59:45 AM »
Hi ben,

Can you please attach a schematic?

Support / Re: Simblee GZLL performs worse than RFduino GZLL
« on: March 22, 2017, 08:07:22 AM »
Hi mjkuwp94,

Thanks for your interest in Simblee!

To help you further, can you post a copy of your sketch or send it to us at:

We'd be happy to take a look and help you out!

Hi Wayne,

Simblee is perfectly suited for this application! Simblee's Ultra-Low Power mode enables you to run for years on a single coin cell battery!

For this application, you could easily put the Simblee in ULP mode, and wait for a button press. The Simblee would then wake, send a packet via our low-latency ultra-fast SimbleeCOM protocol, and go back to sleep.

This application could easily run in the field for years!

Do you have any specific questions about how to implement this?

Videos/Guides/Tutorials / Simblee for Mobile and SimbleeCOM - Dual Mode
« on: January 12, 2017, 05:53:29 AM »
<a href="" target="_blank" class="new_win"></a>

BLE and Low Level Development / Re: Simblee soft device Nordic SDK
« on: November 18, 2016, 06:37:16 AM »
The Simblee uses the S110 stack.

Support / Re: clearing the screen of simblee app
« on: October 11, 2016, 06:23:25 AM »
Hi lovelyboy,

Please take a look at our Simblee For Mobile reference:

You'll need to use the ui_event() function to determine which segment was pressed, and perform actions from there.

Please take a look at the example sketches in the Arduino IDE after following our Quickstart Guide. Also, you'll find more information in our Videos/Guides/Tutorials section on this forum.

Support / Re: == 7 BUG??
« on: October 07, 2016, 02:38:52 PM »
Well put tolson. The object IDs are not globally unique, and may overlap when using multiple screens. In applications with many screens, maintaining a table of object ids for objects that may never exist or only exist for a short amount of time would be cumbersome.

So, in order to capture unique events, we recommend checking the current screen as well as the and event.type.

Support / Re: == 7 BUG??
« on: October 07, 2016, 09:10:47 AM »
I'm not exactly sure I'm understanding correctly. Even if you define different variables, the object ids may be the same. So then in your ui_event() function, you may be looking for an == 10 (ui_box2), and you may be currently on screen2, but ui_box may also still be 10, and you have that check first in your code. If this is the case, if ( == ui_box) would run instead of else if ( == ui_box2), and the code to update screen1 would run, even though those objects don't exist anymore.

Does that help?

Pages: [1] 2