Jump to content
Brian Enos's Forums... Maku mozo!

New DD alpha ShotMaxx Timer


Ken_Bird

Recommended Posts

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

  • Replies 427
  • Created
  • Last Reply

Top Posters In This Topic

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...