Nordic BLE Transmission issues

Bullwinkle

  • Full Member
  • ***
    • Posts: 14
    • View Profile
I've had a lot of problems with "Pipe Errors (0x91)" despite the fact that I am testing
the "credits" available before sending data.
My code basically uses:
aci_state_t* _aci_state;
_aci_state = BLESetup();
...
// in the "send" operation:
   if (clientConnected && lib_aci_is_pipe_available(_aci_state, PIPE_UART_OVER_BTLE_UART_TX_TX) &&
      (_aci_state->data_credit_available >= 1))
    {
      if (!lib_aci_send_data(PIPE_UART_OVER_BTLE_UART_TX_TX, (uint8_t*)msg, sendLength))
      {
        SerialMonitorInterface.println(F("TX dropped!"));
        ...
      }
    }
-- is there some other approach I should be using for data transmission?
+++ MODIFIED! +++
(Dunno why it always happens, but as soon as I ask a question, I often get to
answer it myself!!!!)
-- I found that I'm "poking the bear" at too low a level: calling lib_aci_send_data
requires that "I" maintain the "credits" counter!  Didn't realize that; replacing with
a call to "uart_tx" seems to reliably solve the problem!   Sometimes hard to see
what level of an API you're supposed to be dealing with!
---------------- but the remainder of my question still stands: does the ST version
of the module offer better [reliability/ease-of-use/performance/features/etc]?
.............
I've been using the Nordic BLE module for a while now, with "some" success.
I just noticed that you folks are replacing that with an "ST"-based module, that's
supposed to be "drop in compatible" but also allows Arduino sketch to muck with
connection parameters.
   Do I assume correctly that this uses different library code?  Would the ST module
give me a better shot at getting past these silly (what appear to be) data-overrun
issues?
  Thanks for any help you can offer!
« Last Edit: September 16, 2017, 05:43:16 PM by Bullwinkle »


ABRKTimothy

  • Newbie
  • *
    • Posts: 1
    • View Profile
    • whoagirls
If you do happen to find the answer, please post back. I'm curious to know.


 

SMF spam blocked by CleanTalk