Hey ShellDude!! Sorry for the delay, I've been busy catching up on life things the last couple weeks. After a solid year of CBT/Kickstarter the life stuff really piles up. :)

I was implementing separate BT filters but went back to just rate limiting the data going to the BT LE module over UART to avoid buffer overruns on the module. Try setting the filter using 0x03 just like you would over USB Serial.

Also checkout the new 0.4.5 firmware that was merged in yesterday. You'll have to flash it with arduino, I haven't build a binary yet. It has improvements for the BT LE UART.

Also something to keep in mind is the MCU will send packets out on the last used interface only. So if you sent a command on USB Serial it will only dump back to USB Serial, same goes for BT.

Let me know if that helps and how far you get, I'll be checking the forum more regularly now. I've been trying to find time to build the Android Wear BT CBT app. That should be a fun one!

Derek,

Thank you so much for the response! It's great to see that your project is still active. The convenience alone it adds is second to none... just need to work out a few more kinks.

With 0.4.4 I tried doing just that (setting an 03 filter) but while the filter worked fine when connected to USB I could never get it to return anything over BLE, ensuring that only Serial1 was connected (I noticed the interoperability between Serial and Serial1).

After spending some time reviewing all the sketch code I was left with the impression that it should just be working. I'll check out 0.4.5 today and report back.

Success!

It took some serious debugging but I figured it out. For some reason (Android only maybe?) LE chokes on processing the SerialCommand::logCommand() activeSerial->write(COMMAND_OK) operation. I'm guessing 0xFF is screwing up the stack somehow.

Anyway I replaced

<code>activeSerial->write(COMMAND_OK);</code>

with

<code>if (activeSerial && Serial) activeSerial->write(COMMAND_OK);</code>

in SerialCommand.h's logCommand() function and I can now filter to my heart's content over BTLE. This was the final barrier to wrapping up my proof of concept. Now the real coding begins!

I recall reading you accept bug reports via github... will head over there now.

So it stopped working again. Am I only person having BT filtering issues?

I suspected the 0xff thing was too good to be true and now I can't recreate the scenario where i got it to work.

Made some progress tonight. I'm not sure why but logCommand() is very touchy. If I even reference &Serial1 it stops streaming. If I do not provide a heartbeat, (with the btRateLimit enabled) it won't stream.

If I remove btRateLimit completely and ensure I have a filter that removes the bulk of the noise, it works fine.

https://www.youtube.com/watch?v=zlOBfZTUGQw&feature=youtu.be

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!