Using Serial instead SoftwareSerial don't works

[ghost]

First, congratulations for your work with BGLib for Arduino and your breakout board for BLE112 (I have one)

I'm not sure, but after a lot of test, I can't make it work using Serial instead SerialSoftware.

Using SerialSoftware all works like a charm, but using Serial (without DEBUG defined of course) ble_cmd_attributes_write command fails and my iOS app don't receives anything.

The rest like ble_cmd_gap_set_adv_parameters, ble_cmd_gap_set_mode and event handlers works.

Have you tried the same? Any ideas?

[jrowberg]

Hi @breakinglabs, if the events work and some of the commands work, I would assume for the moment that the API interface is working correctly. If it were a hardware vs. software serial problem, I would expect either nothing to work at all, or at best that the events/responses (RX) would work but commands (TX) would not.

Using attributes_write will only result in data being sent to an iOS app if that app has subscribed to notifications or indications on the BLE attribute. Do you know if this is the case? Can you test with the LightBlue app or the BLE Utility app (both free) to see if browsing to the attribute you want to receive data from and enabling notifications solves the problem?

[ghost]

I did all tests in the same scenario with SoftwareSerial and Serial.

Also tried with LightBlue with the same bad results.

All goes fine (really well) with softwareSerial but when I change to Serial, Arduino can start the module and receive commands but when use "ble_cmd_attributes_write" nothing (or junk) reaches my iOS app or LightBlue (Of course using notify).

FYI, I'm using a Arduino Pro mini 3,3v/8Mhz with a FTDI cable for programming the chip disconnecting it when try to use "Serial" with BLE module to avoid collisions.

[jrowberg]

Can you paste the portion of the code immediately before, including, and immediately after the ble_cmd_attributes_write command, along with an explanation of any variables used there?

[axmo]

@breakinglabs, I noticed similar problems and was wondering if you were/are using the sleep function of the BLE...

Hardware Serial write commands return immediately, which causes the BLE wake pin to be set low by onTXComplete() before TX is actually complete. In my case the symptom of this was a BLE unit that self-reset all the time while setting up advertising. A quick/dirty fix is to add a delay before setting the wake pin low... choose the delay length based on the longest bgapi packet you're planning to send, (edit: or use Serial.flush() for an 'elastic' delay)

It's a poor workaround, though, since the max BGAPI packet is 2048 + 4 = 2052 bytes * 10 bits per byte (including start and stop bit) 20520 bits long. at 115200 that's 179ms, which means blocking for almost 1/5th of a second...

I suppose some sort of elastic delay based on the actual length of the packet could be worked out... Or maybe a timer/interrupt method would be possible? @jrowberg, Your thoughts?

[jrowberg]

Hi @axmo and @breakinglabs,

I did learn recently that my implementation of the wake-up pin does jump the gun sometimes, if the last byte of the command packet hasn't been clocked into the BLE11x module attached. The most reliable solution for this, which I haven't implemented, is that the wake-up pin should be:

1. Asserted immediately before you begin sending the command
2. De-asserted as soon as you receive any data from the module

This guarantees that the module will be held awake as long as necessary--possibly a little bit longer, but not much. Maybe a millisecond.