Hi, Let me start by saying that this one is a real stumper, because my custom device with my service is working pretty much everywhere with one exception.
So here is my situation:
我有一个定制的设备设计,它使用the Murata LBCA2HNZYZ chip (this is actually just a Dialog DA14580 that has been put into a package that contains an antenna). FYI, the Murata chip is a great solution for speeding your design through the hurdles of FCC/CE certification because it has already been stamped with an approval. Anyway, what this device does is not so relevant, but suffice it to say that it connects to a smartphone app that I also wrote (both iOS and Android). Both the apps work fine, I can connect to my custom device and send/receive data without any problems, and I have tested using a variety of devices. For iOS my devices are iPad2, iPhone4S, iphone6, running OS's from 7.1 to 9. In Android, my test devices are Samsung and Motorola, running OS's 4.4, 5.1, and 6.0. So I am feeling pretty good about my app's/device's readiness for the open market. Until yesterday, ha.
There is one Android device that have found that I cannot get to connect to my custom device. Right away I want to blame the Android device or possibly my app, but here is why I cannot:
(This is hard to follow, I kept thinking that I had pinpointed the source of the problem only to have it disproven, so maybe before you jump to a conclusion too, read through it twice)
- I have access to several of this same Android device runing OS 5.1 and they all respond the same (no BLE device found when I scan). So it's not a single 'bad' unit, it's consistent on this Android Model. So is it my app? No, because;
——在任何these Android devices I can use the free Android App 'Bluetooth LE Scanner' and it also does NOT see my device. So is it this Model of Android device or its 'flavor' of OS 5.1? No, because;
- If I turn my custom device off, then connect the DA14580 Dev kit to my PC, then start a debugging session, NOW I CAN SEE MY SERVICE on any of those Android devices, using the 'Bluetooth LE Scanner app'. So this would seem to eliminate the Android device as the source of the problem. Is it the Murata chip that I am using? No, bacause;
- If I disconnect the DA14580 Dev kit, and now connect my Murata Dev kit (P2ML3078) and start a debug session, I CAN AGAIN SEE MY SERVICE. This is significant because it eliminates the Murata chip itself and any possible modifications to OTP that Murata may have made to the DA14580 chip. So is it something in my firmware? I don't think so, because;
- Keep in mind that all the debug sessions above are using the SAME project firmware that I am running on my custom device. The only difference is that for my custom device, I am actually booting from an external flash chip. So my device uses a bootloader to get the firmware from the flash chip, but the code that it is running once it does this is the same. And remember-- the firmware is doing what it should because I can scan/connect to it with a variety of other smartphones.
- One last thing; the log for a FAILED scan (when my device doesn't show up in the Bluetooth LE Scanner) is virtually identical to the log for a SUCCEEDED scan (device does show up). If it helps then I can include the logs here but I really don't think they reveal anything.
So I think that I have arrived at the fact that it must be something that is happening only when the firmware is running on my custom device. So the question becomes, if its something in my device, then why might it only be affecting this particular Android Model with its flavor of the Android OS?
Any insight (or even wild guesses) that anybody might have is absolutely welcome, especially if I have overlooked something obvious. Let me know if there is
Thanks- klim
Hi klim9531,
I dont see any logical explanation behind this or why the hw should affect the services of your device on that particular android phone running that specific fw, allow me to recap in order to get this straight, the problem only occurs (the device is not visible at all) when using:
What troubles me the most is the fact that when the service is enabled the device isn't scannable at all from that phone, have i understood correctly ?
What i would do, is to focus on any differences between the data emmited from the dev kits and the custom device (any data that are set on the dev kits but not on your custom board), for example, have you tried using a different bd address (as far as i know the Murata modules have their OTP header burned with the device id field, it should not affect anything but you can give it a try - wild guess you said). Also i understand that the debugging procedure that you have described here is quite long so mistakes can easily occur, so i will state the obvious, since the android caches the data from the services and characteristics, have you tried to wipe out the android cache on the phone that has the issue ? Also a sniffer log from the discovery procedure would help in order to check what is happening.
Thanks MT_dialog
Hi MT_Dialog,
Thanks for the help, I really appreciate even the 'wild guesses'. Your key points above are all exactly correct. You gave me a great idea with item number 2--- I have integrated the SUOTA service into my design and it is currently working (due largely to your help several months ago-- thank you again!). So I am going to download the Dialog SUOTA app onto the phone under test and see if its able to see my device running that service. I will report the results back here.
I don't know of any data that gets set in the Murata dev kit that would be different from that on my custom PCBs. The Murata dev kit P2ML3078 has several daughter cards that can be purchased, these daughter cards are nothing much more than an easy way to swap out the various Murata package variants of the Dialog DA14580. Its possible that the Murata chip on my daughter card is not emitting the same data as the Murata chips that they actually sell, but that would seem unlikely. The BD Address is burned into the Murata OTP header so that would be different, but that should not matter.
我明白了Android操作系统的工作方式,鲍威ring off the device will clear any cached data regarding BLE devices. I don't know of any other way to 'clear the cache' duing OS runtime. And because I am just using a 3rd party app (Bluetooth LE Scanner) to scan for any devices, that should return any resulting advertisements. And it does do that when I use the Dialog or Murata dev kit.
i will see if I can find out how to put together a sniffer log, I don't have a BLE packet sniffer but it seems like I looked at the sniffer devices a while back and they were pretty cheap. I just never had an actual need for one of them.
Thanks, klim
Hi MT_Dialog,
I have an update, I think that I found the problem:
--I downloaded the SUOTA app and ran it, I first tested that I was able to see the SUOTA service when I ran my firmware on the DA-14580 dev kit. Yes, I was able to see it (so far things are just as I had described earlier).
--So now I connected a battery to my custom device and turned it on, then ran the SUOTA app again and pressed "Scan'. I was surprised to see my service appear, and picked up my custom device to press the button on it. In my custom service pressing a button normally changes the Advertising data briefly, this is what I use to connect my app to this specific device/BD Address-- pressing the button should not matter for the SUOTA service, but I was experimenting. Anyway, as I picked up my custom PCB, I happened to bring it within about 6 inches of the Android test device. Suddenly, ANOTHER instance of my device name appeared in the scan list of the SUOTA app. They had different BD Addresses, and It took me a moment to realize that I had NOT DISCONNECTED the DA_14580 Dev kit from my PC-- it was still running from the last test. So that was why I was seeing 2 instances of the my device.
--But the significant thing was that I was now seeing MY CUSTOM DEVICE appear on the Android test device!
So I stopped the SUOTA app, depowered both the custom devices, and tried to repeat the procedure. After not having any success for a bit, I came to discover that the key was 'picking up' my custom device and holding it in a certain orientation at a certain distance from the Android test device. After being able to somewhat consistently reproduce the behavior, I was able to piece together what must be happening.
1. These Android test devices have an extremely short transmission/reception range, where all other Android/iOS devices I have tested can perform bi-directional communication at ranges of approximately 100M.
2. My custom device also has a shorter-than-ideal transmit/receive range, less than that of the Dev kits. Murata's docs for my chip claim the 'theoretical range' as 30M, however, during testing with my custom deicve, I found its range to be about 5-10M.
3. The extremely short range of this Android test device , coupled with the fact that my custom device had a shorter range than the DA-14580DK and the Murata Dev kit, resulted in my device simply not being seen unless I held it literally RIGHT NEXT TO THE ANDROID TEST DEVICE.
Thanks for your help MT_Dialog, I now have my answer. --klim
Hi klim9531,
Glad you found it, thanks for letting us know.
Best Regards MT_dialog