OK thanks! yeah - I was getting that feeling, so I'll probably use the nRF8001 for prototyping purposes and then switch to another module at a later date. So far things are working well with the nRF8001 but we will definitely need a BLE module that is FCC certified...

Thanks!

Hi All!

I just wanted to give a little update that I have successfully built out the prototype that I've been working on for the last few weeks (the first version was with a standard Arduino Uno, RedBearLab BLE Shield and a Hall Effect Sensor, and now I'm using TinyDuino (with LiPoly battery)/TinyShield nRF8001/Protoboard/Reed Switch).

There's still more to do, but the basic functionality is there and I'm able to get data back and forth from the TinyDuino/TinyShield BLE device to my iOS app that I'm using to test and it's working GREAT!

Thanks to Ben and all others who have been answering my newbie questions. The answers have all been very helpful and each one has helped move me a little bit forward each time.

Like I said, I still have some more to do (possibly real-time clock and datalogging stuff), but this is the first step!

Thanks Again!

Does the nRF8001 BLE Shield have a 20-byte limit per transmission? I thought I saw that in the code but just wanted to verify that.

If that's the case, are there good (or just commonly-used) strategies for breaking up data to send to a Central device if we need to send more than the 20-byte limit will handle?

Thanks!

-Evan

OK thanks, Ben!

Hi!

I noticed that the TinyShield BLE example uses:

Code Select Expand

SPI.setBitOrder(LSBFIRST);
// Do some stuff...
SPI.setBitOrder(MSBFIRST);

Please pardon my ignorance and lack of knowledge in this area (I'm trying to come up to speed, really!!! ), but is there a general rule of thumb as to when this toggling should be done? Are there times at which it should NOT be done?

Thanks in advance!!!

-Evan

Thanks! I'll check it out!

Hi!

I've been working with the TinyShield_NRF8001_BLE_Example project to learn how the TinyShield nRF8001 communicates and I noticed the following comment:

Code Select Expand

//when using this project in the Arduino IDE, delete the following include and rename UART.h to UART.ino


...and I just had some questions:

• Is the intent of the comment to advise us to rename UART.h to UART.ino, and then use that as the basis of future Arduino projects?
• Is there a problem with using TinyShield_NRF8001_BLE_Example.ino as a template for future work?

I was building off the TinyShield_NRF8001_BLE_Example.ino and finally read that comment and I got to wondering, so any advice on that will be appreciated.

Thanks in advance!

-Evan

Hi Ben!

Yeah - after using LightBlue and looking at the Nordic example code I came to that conclusion, and thank you for confirming it!

Is the XML file that was created in nRFgo to define the UUIDs for the UART functionality in the TinyShield NRF8001 BLE available somewhere?

Or are those UUIDs (for services and characteristics) at least documented somewhere?

I think I may have answered my own question. I unplugged my device from my computer and disconnected the battery, then plugged it back into the USB and I now have a name and UUID that I can track.

I basically added a call to lib_aci_set_local_data() into UART.h in the same location that RBL does it in their version of the nRF8001 library code and it seems to have worked.

I have a very simple iOS app that I wrote that is giving me the UUID and the device name.

The next step is to see if I can get an iOS app to communicate with it...

When one uses the basic demo (https://codebender.cc/sketch:91073#TinyShield_NRF8001_BLE_Example.ino) with the TinyShield Nordic, what Service UUIDs does it advertise and are those UUIDs documented anywhere?

Are there default Service and Characteristics that the device is set up with?

I'm using LightBlue on iOS to try to detect the device and I can't really tell if it's in the list.

Additionally, can we use lib_aci_set_local_data() to set/change the name of the device?

Thanks!

Hi!

I just wanted to add something to the collective knowledgebase.

I went through the exercise of updating the UART.h file in the TinyDuino's sample project per the Github diffs:

Line 78:

Code Select Expand

static const hal_aci_data_t setup_msgs[NB_SETUP_MESSAGES] PROGMEM = SETUP_MESSAGES_CONTENT;

Line 153:

Code Select Expand

aci_state.aci_setup_info.setup_msgs         = (hal_aci_data_t*)setup_msgs;

...and one by one the errors went away. Hooray!

But then I still had one more compile error that I didn't expect to have:

Code Select Expand

/Users/username_here/Documents/Arduino/libraries/ble-sdk-arduino-RBL/src/bootloader_setup.cpp:2:20: fatal error: EEPROM.h: No such file or directory
#include <EEPROM.h>
                    ^
compilation terminated.
Error compiling.

So I thought I should share how I fixed it in my case.

The compiler error message was really odd at first, because it was picking up a file that (or so I thought) shouldn't be included. However, it occurred to me that this was probably due to the compiler's search path and a file from one of my libraries was being included.

I have been doing some experimentation with the nordic and RedBearLab BLE shields with my Arduino Uno, so I had some of those libraries in my folder.

Sure enough, when I moved those temporarily out of the libraries folder, the compilation error went away.

A little inconvenient, but totally fine for now...

Hope this helps someone else in the future who might run into this!

Sorry to dig this one up, but what are the implications of using a Nordic shield that is not FCC certified? Should we be concerned if we are developing a product/prototype with the Nordic shield vs. the BlueGiga?

This is an interesting question and topic -- one I hadn't thought of since I've never really developed and produced a hardware product like the one we're embarking on.

I guess this is just for prototyping purposes so when we get down to production we'll probably have a separate set of issues, correct? What does one typically do in this scenario?

Thanks!

I just ran into this, being new to TinyCircuits/TinyDuino and thought I would post this just for anyone coming along that might have the same problem...

Basically, I attempted to follow the Getting Started steps (including installing the VCP drivers) and upload the Blink sketch and received a "programmer is not responding... not in sync... problem uploading to board" error:

Arduino: 1.6.3 (Mac OS X), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"

Sketch uses 1,030 bytes (3%) of program storage space. Maximum is 30,720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2,039 bytes for local variables. Maximum is 2,048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
...

However after a quick email exchange with support, they pointed out that there is a tiny ON/OFF switch on the main microcontroller board, and to toggle it back and forth. (I noticed that mine was actually set to "OFF" which probably didn't help matters.  )

But anyway, after flipping the switch a couple times and leaving it in the ON position, the upload worked just fine -- and I now have a functioning blinking TinyDuino! 

Thanks to the awesome support folks at TinyCircuits!