5 ms·

It doesn't work with android because of the wide variety of speakers and microphones on android vs the very few for ios. Many android phones can't even emit or

It doesn't work with android because of the wide variety of speakers and microphones on android vs the very few for ios. Many android phones can't even emit or record ultrasound.

ishields 10y ago
I've worked with ultrasound on the receiving end on android before, using the built in mic to capture ultrasound data. We never came across a device that was unable to hear the data, and we tested on what I would consider a pretty large variety of phones. As far as transmitting goes you're probably right though, and seeing as the dash button is the receiver in this scenario it makes sense
NateyJay 10y ago
I wonder why they didn't just fall back to audible sound. WiFi is okay, but having to manually connect to the button's access point is fiddly, and disconnects you from the real network. Another solution is Electric Imp's BlinkUp, which encodes the WiFi information in flashing light from the screen. Patented.
- grogenaut 10y ago
  http://arstechnica.com/uncategorized/2003/09/2886-2/ http://arstechnica.com/uncategorized/2003/09/2886-2/ "Eight weeks later, the first public demonstration was given to the class by using a simple ping packet. With a blinding 2bps speed, the class sat patiently as the packet was received in roughly 140 seconds. " That's why. Sound is a pretty slow wavelength. Low end is 60hz, lets call it 600hz tones in this bongo (I don't actually know). However ultra sound is at 20 kHz and above. Eg 33 times faster. 33x the data. Eg 140 seconds now takes 4.25 seconds. Lets assume the bongo was 10 too long. Now we're down to 14 seconds in audible and .42 seconds in ultrasound. you can see the benefit. and that's without actually doing a real data rate calculation becuase I don't have a good number on how many waveforms you have to have on sound to pick up a real signal. Somthing somthing nyquest criterion somthing somthing.
arcticbull 10y ago
There's all sorts of funky stuff with Android audio recording and playback. Some Android devices can only record 8kHz audio and then upsample without telling you (where iOS hardware native is 44.1kHz). Some also apply filters you wouldn't expect at the input stage. There's also automatic gain control (AGC) which varies dramatically across manufacturers and phones. Similarly for output: filtering, sample rates, speaker quality, etc. Then taking into account the immense matrix of testing, the problem becomes non-trivial very quickly on Android in ways that are not an issue on iOS. Their choice of ASK complicates things further as amplitude modulation is more prone to transmission error afaik. As someone who's spent way, way too long playing back and recording audio on mobile devices as a mechanism of communications, let me assure you, it's hugely harder on Android than it is on iOS. I would have made the same decision if I were them. Surprised they didn't use BLE, honestly... [edit] Very cool approach though!

It doesn't work with android because of the wide variety of speakers and microphones on android vs the very few for ios. Many android phones can't even emit or record ultrasound.

ishields 10y ago

I've worked with ultrasound on the receiving end on android before, using the built in mic to capture ultrasound data. We never came across a device that was unable to hear the data, and we tested on what I would consider a pretty large variety of phones. As far as transmitting goes you're probably right though, and seeing as the dash button is the receiver in this scenario it makes sense

NateyJay 10y ago

I wonder why they didn't just fall back to audible sound. WiFi is okay, but having to manually connect to the button's access point is fiddly, and disconnects you from the real network. Another solution is Electric Imp's BlinkUp, which encodes the WiFi information in flashing light from the screen. Patented.

grogenaut 10y ago
http://arstechnica.com/uncategorized/2003/09/2886-2/ http://arstechnica.com/uncategorized/2003/09/2886-2/ "Eight weeks later, the first public demonstration was given to the class by using a simple ping packet. With a blinding 2bps speed, the class sat patiently as the packet was received in roughly 140 seconds. " That's why. Sound is a pretty slow wavelength. Low end is 60hz, lets call it 600hz tones in this bongo (I don't actually know). However ultra sound is at 20 kHz and above. Eg 33 times faster. 33x the data. Eg 140 seconds now takes 4.25 seconds. Lets assume the bongo was 10 too long. Now we're down to 14 seconds in audible and .42 seconds in ultrasound. you can see the benefit. and that's without actually doing a real data rate calculation becuase I don't have a good number on how many waveforms you have to have on sound to pick up a real signal. Somthing somthing nyquest criterion somthing somthing.

arcticbull 10y ago

There's all sorts of funky stuff with Android audio recording and playback. Some Android devices can only record 8kHz audio and then upsample without telling you (where iOS hardware native is 44.1kHz). Some also apply filters you wouldn't expect at the input stage. There's also automatic gain control (AGC) which varies dramatically across manufacturers and phones. Similarly for output: filtering, sample rates, speaker quality, etc. Then taking into account the immense matrix of testing, the problem becomes non-trivial very quickly on Android in ways that are not an issue on iOS. Their choice of ASK complicates things further as amplitude modulation is more prone to transmission error afaik. As someone who's spent way, way too long playing back and recording audio on mobile devices as a mechanism of communications, let me assure you, it's hugely harder on Android than it is on iOS. I would have made the same decision if I were them. Surprised they didn't use BLE, honestly... [edit] Very cool approach though!