For anyone else watching I committed a change to the repo that improved this and Shell is up and running. I'm still working on improving the BT LE stuff and working on some android connectivity.

Shell, I'm so jealous of your Android install. Totally awesome.

Hi Derek

I have been developing on a Nexus4 - Android 5. I can configure and get info back - for example I can get the system info, Dump the EEPROM, get the status of each Canbus returning. But it seems to intermittently cut out or drop the connection. If i get the CBT to dump the EEPROM, it gets about halfway through maybe (can't tell exactly, but there is no closing brace) and then won't respond to any other commands and sometimes needs a reboot before it shows up on scans again.

I am running the latest commit for the firmware (commit a7e063c)

What does it mean when the Blue light is on Solid? When this happens the CBT stops showing up on scans for devices. After that I need to reboot it sometimes before I can get it to show up again. Doesn't show up in LightBlue either when the blue light is solid.

Cheers

I should add my assumption was that the blue light indicated a bluetooth connection (and that would seem to make sense) However it seems to get stuck on even though no other devices can see it or communicate with it.

I've learned quite a bit about Android gatt over the past two weeks.

The various callbacks are not threadsafe. You want to do as little work as possible in them. Leave the heavy lifting to your UI thread and a handler/runnable.

Another possibility, or additional complication, is the amount of data you are trying to transfer.

Blindly forwarding from a 100kbps or greater can connection to BTLE is akin to pushing a watermelon through a garden hose.

Initially try filtering on one specific register... After you ensure you have lughtweight, synchronized if necessary, gatt callbacks.

Thanks Shelldude. At the moment I haven't connected to a can device, soon though :) I want to get reliable communication between my device and the CBT first. I seem to get intermittent behaviour, sometimes I can do consecutive EEPROM dumps (only using that as an example since it is a relatively large chunk of data) and all data comes through no problem and then other times the connection cuts out and then nothing until a reboot. It does seem like buffer issues between the Micro and BLE112 although at this point I am still looking at my code to ensure I am not doing anything stupid. Have you tried doing an EEPROM dump {0x01, 0x02} with yours and if so do you have any issues?

Cheers
Tom

I don't think Derek implemented throttling on the eeprom dump. Take a look inside SerialCommand.

Ah I see. Ok that makes sense then.

There is actually some rate limiting built into the eeprom dump. btDelay() which incorporates a delay of 20ms every 8 bytes.

Only thing is it doesn't work. As far as i can tell the byteCount is not ever incremented even though there is a 'byteCount++' I tried a bunch of different things but the condition (byteCount>8) is never triggered to cause a delay. I know this for sure because i set the delay to 1000 ms and I certainly did not see any delays happening. I reimplemented in a different way which solves the problem and I can reliably dump the Eeprom data. I want to roll a general solution for all writes and then I'll generate a pull request.

[Derek - So I can assign the byteCount variable (say to 10) and then the condition will trigger (as you would expect) but byteCount++ or byteCount +=1 or byteCount = byteCount + 1 don't appear to be working in that context. This makes no sense. Any ideas on that? I've not done any work with these before so maybe its some quirk I don't know about. I did notice that it is defined both as a class member variable and a global variable.]

PS. Its not that I am obsessed with dumping the eeprom data. Its just its an example of a chunk of data that is far larger than the 20 Byte BLE packet size imposed by BLE spec. If I 'button bash' the channelDebug or even the systemDebug commands I can quickly currupt the serial communication between the micro and the BLE module. I suspect this will also extend to messages from a canbus. The current rate limiting only discards packets that arrive too frequently (Derek am I correct saying that).

Sounds like you're past your initial hurdle.

Code like wind... Wait for no one!