euxx Posted March 4, 2015 Share Posted March 4, 2015 I guess it depends on the device. For OS 5, it would not be an SDK fix. Google had changed it so that unless you were doing the exact right calls it was switching to the internal microphone instead of the BT headset. The only way you can tell what is going on with those non-working devices would be to dump the raw waveforms out and look at them. They should all be consistent (same amplitude and shape). For example on the Samsung S5's, you could clearly see that the longer the waveform was playing, the greater the amplitude of the waveform. We had to write a compressor/limiter to deal with that. My guess is that there are other scenario's that are also causing issues with some devices. Exactly my point. The SDK is supplied without the source code and unless you are deep into knowing exact communication protocol between timer and Android BT interface, you can't really do much. All my android devices are working just fine with all BT microphones I've tried, yet most of them having issues to communicate with SM timer. It all started after the changes in 3085 firmware and corresponding SDK changes when transmission rate was increased. So, after realizing that I'm spending more time trying to make communication with timer work than implementing user-facing features of my Android app, I dropped the project. It is just not worth it for me. PS: don't think any of that would have been an issue if timer used a real digital BT interface instead of trying to simulate it over audio aux. I am aware that it is practically the first device of this kind and it is not possible to use raw digital data over BT with Apple devices, yet obviously it is not working too well for Android devices... Link to comment Share on other sites More sharing options...
3djedi Posted March 4, 2015 Share Posted March 4, 2015 I using an LG G3..... I'll try rebooting......... I'll also try the "soft restart" of the SM Link to comment Share on other sites More sharing options...
AdamM Posted March 4, 2015 Share Posted March 4, 2015 I guess it depends on the device. For OS 5, it would not be an SDK fix. Google had changed it so that unless you were doing the exact right calls it was switching to the internal microphone instead of the BT headset. The only way you can tell what is going on with those non-working devices would be to dump the raw waveforms out and look at them. They should all be consistent (same amplitude and shape). For example on the Samsung S5's, you could clearly see that the longer the waveform was playing, the greater the amplitude of the waveform. We had to write a compressor/limiter to deal with that. My guess is that there are other scenario's that are also causing issues with some devices. Exactly my point. The SDK is supplied without the source code and unless you are deep into knowing exact communication protocol between timer and Android BT interface, you can't really do much. All my android devices are working just fine with all BT microphones I've tried, yet most of them having issues to communicate with SM timer. It all started after the changes in 3085 firmware and corresponding SDK changes when transmission rate was increased. So, after realizing that I'm spending more time trying to make communication with timer work than implementing user-facing features of my Android app, I dropped the project. It is just not worth it for me. PS: don't think any of that would have been an issue if timer used a real digital BT interface instead of trying to simulate it over audio aux. I am aware that it is practically the first device of this kind and it is not possible to use raw digital data over BT with Apple devices, yet obviously it is not working too well for Android devices... You can always do what we did. Take the Java libraries and disassemble them. That's how we based our iOS SDK. There is a big difference between what you "hear" with a BT device (mic) and what the waveforms actually *should* look like. Your ears will not be able to perceive some of the differences that will completely trash the waveform on these devices. Yes, it's a toss up with the new protocol. It certainly made it much faster. That really helps when transmitting "All" times. Unfortunately it does make it a bit less reliable, especially when the SM watch is further from the receiving Device. We wish it had a digital communication too. Unfortunately when you develop things you pretty much have to pick the best available hardware out there and go with it. Don't forget that the development started years before the product was available. I have a friend who makes professional quality video camera/recorders for race cars. It took him THREE years to finally get a chipset that actually worked. He spent over $100K in hardware development kits from various manufactures until finally one was "good". It's really tough being a small company and trying to develop hardware like this. It is possible to do digital with Apple devices, just not with some of the very old ones (which it doesn't even work with for Analog -- e.g. iPad I). Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now