1 Reply Latest reply on Aug 12, 2015 10:40 AM by mifo

    Optimizing for speed... lots of weird behavior in anaren BLE module

    sivanov

      I have the MSDB kind of working for my UART application, but my packet transfer is pretty slow. I apologise in advance for the lenghty post.

      I'm using the PUART to connect to a serial device. Inside atmosphere, I have two embedded functions: one that accepts an input string, formats a packet/payload, and writes to the UART. I have another function that simply starts the read process, checks for some error conditions, processes the payload, and returns a string. Speed issue #1: For some reason, I cannot send the data to the PUART and read the response within the same function and have to return for data to be sent (TX interrupts are disabled inside functions or TX transmits in the superloop). I had to break it up into two functions, which is slower since now I have to call two things with attr write... Weird behavior issue #1: if I use prepare write, my function receives data several times (ex: sending 50 bytes results in the function being called with 18 bytes of data, then 36, then 50. I have to return and ignore the data the first two packets and only process on the third time). Speed issue #2: Setting the return type for the attribute to JSON doesn't work for sending binary data, no matter what formatting I try. I have to be able to send NULL bytes so I ended up converting my data to ASCII hex string, which is 4 bits/byte. Weird behavior issue #2: Atmosphere allows me to set the return size to larger than 128, but if I do that, it tramples the RAM. I saw that 128 was hardcoded as the limit for JSON parsing, but I don't know how to override this. In binary mode, I would need to return 256bytes. In ASCII hex, I would need 512 to avoid having to call the function repeatedly to send me the data. Long read works at least...

      Essentially, my calls looks like: [prepare write (for TX), wait for complete] x n, execute write, wait for complete, attr write (for RX), wait for complete, read long (for RX), wait for complete. Any ideas on shortening this up?

      Speed issue #3: I connect the anaren module with min=7 max=15 interval, 100ms timeout, 0ms latency and I'm watching the packets come in. Even on a long read, it seems to take 500ms between packets, which is terrible. I'm using the default demo project which runs AIR_POWER_SetMode(AIR_POWER_NOSLEEP).

      Weird behavior issues #3: Out of reset, the module advertises pretty fast, but after the first connection, it slows down to 500ms. I wonder if this is related to why my packets are coming in so slowly.

      We are shooting for something reasonable like 9600baud, but we currently see 2.5s for 50 bytes which comes to a grand total of 160baud...

      I'm using a bluegiga dongle on the PC side. When I use the demo app to play with the data, it seems to respond pretty slowly as well.

      Any help would be appreciated here.

      -Stan