I'm looking in to making a pH tester for my Android phone. I've found a pH electrode that will send a milliVolt signal which I can then use to convert into a pH reading (59.2 mV per pH unit # 25° C). The question I'm having is would it be possible to connect the electrode to the headphone jack and directly read the milliVolt reading or would I need to convert the analog signal to digital first and then plug it in via USB? I'm not a big electronics guy but I'm doing this project on the side and hoping to learn from it.
I was thinking perhaps getting the mV reading from the headphone jack would be possible with the GetMaxAmplitude function like from this thread here: Range of values for GetMaxAmplitude. Although, from what I understand the lowest reading possible with this function is 0 and there are negative mV values that can be read when testing for pH.
Any help is greatly appreciated, thanks!
This should be asked in the electrical engineering site. But the best way is to use a Bluetooth-to-serial converter, ($5 off ebay) and a PIC microcontroller with USART and A/D converter, ($1), you could program the PIC quite easily in C with the 'MPLAB' IDE and 'HI-TECH' C compiler. The tools you'll need are a PIC programmer ($20) and something with a serial port if you want to configure the Bluetooth-serial converter, like a desktop PC or a USB-serial converter. You might need an op-amp circuit to amplify the signal so it's readable by the PIC. You'd then use code from Google's BluetoothChat example to get your phone connecting to your bluetooth system, and receiving data from it.
Using a microphone for input would be tricky, for one reason, because it will be filtered to accept only AC. One way to get round that would be to modulate an oscillator's output so its amplitude is proportional to the DC signal you're measuring, then you could measure the magnitude by analysing the data from the microphone.
Interfacing with USB is more difficult than it sounds, it would be harder to build something which would interface with that and measure millivolts, than with bluetooth, because the PIC processor you use for analog to digital sampling and USB client would in fact have to either act as USB host or USB OTG on a phone, which is far more complicated than being a USB peripheral.
I think you would have the most consistent operation across a range of android devices if you built a circuit which uses the voltage from the sensor to control the frequency of an audio oscillator, and measures the frequency with software on the phone.
It's not impossible that a direct connection and reading the amplitude would work, but the two problems are that the signal path may not be good all the way down to DC - there may be a minimum frequency that it can pass making it unsuitable for measuring constant voltages. And second, that the gain of the input channel may not be consistent from device to device or even over time, temperature, etc. There are possible workarounds such as circuits which alternately send the voltage upright and inverted, effectively modulating it to overcome minimum frequency limitations, or even alternate the actual reading with a reference voltage to help model the input gain.
But I'd probably recommend either the frequency modulation approach, or using a $20 embedded bluetooth module and going wireless. Either way, the sensor system is going to need its own small battery pack.
You can extract some power from the headphone jack by telling android to make some sound (and, I suppose, rectifying the output and storing it in a capacitor) - I've seen a bunch of jack-powered things do this. I wonder if the 2 ideas could go together? What if you modulated some audio out through the headphone jacks, through the sensor, then back into the mic? The pH reading should mess with the received sound in some kind of measurable way I'd expect?
Related
I'm trying to see how gsm affects data on a phone call. Here is what I'm trying to do. One person will be talking on a phone and I will record his voice from phone's mic while he speaks and on the other phone I will get the data coming from gsm and compare them. I want to write an android application to get that data. Is that possible on android or can you suggest another way to achieve this?
Some background (you may know this already)...
When you make a GSM call, the analogue signal in the phone microphone corresponding to your speech is converted into a series of digital values and then encoded with a voice codec. This is basically a clever algorithm to capture as much of the speech as possible, in as little data as possible.
The idea is to maintain very good speech quality while saving on the amount of bandwidth needed for a call. Techniques used include not transmitting quite periods (when you are not speaking) and various compressions and predictive encoding algorithms. There have been and still are a number of codecs in use in GSM, but the latest and general preferred codec is called AMR-Narrowband.
Nearly all GSM deployments encrypt speech between the phone and the base station - while there are publicised weaknesses in the various encryption algorithms, I am assuming (hoping...) that decrypting is not what you are looking for.
Your question - 'I want to see that if there will be data loss or corruption when voice reaches over gsm'
Firstly, is it worth noting that speech is 'relatively' tolerant of small amounts of data loss and corruption, at least compared to data. It is quite common to have bursts of packet loss in VoIP networks and it may cause a temporary degradation in voice quality. Secondly, packet loss in a VoIP network will include delayed packets which can be confusing - if the packet arrives too late to be included in the 'sound' being played in the receivers speaker then it is effectively lost from the VoIP point of view, even though other measures may show that it simply arrived late.
To actually measure the loss between the GSM phone and the basestation you would need access to the data received at the basestation, which you will not usually have unless you are the operator.
If you do an end to end test, from one GSM to another, your speech path will traverse other network nodes also, so you will not know if any loss or corruption is happening over the GSM air interface or in one or more of the other nodes.
You would also need to be aware of handover from one cell to another and from 2G to 3G (GSM to UMTS) which may affect your tests (even stationary phones can handover in certain circumstances).
If your interest is purely academic then the easiest thing might be to create your own GSM base station and test on this - there exists several open source GSM 'network in a box' projects which should allow you do this. I have not used it myself, but this one looks the most actively supported at this time - check out the mailing list under the community tab for a good place to maybe follow up your investigations:
http://openbts.org
I am developing an android app for recording the sound. In my app i will display the SPL (Sound Pressure Level) in dB. As part of my search, i come across, mobile hardware can only record sounds up to <= 110 dB. The reason is, mobiles are designed for human voice recording and that falls under the range of 60 dB. So if i need to record the sounds which is more than 110 dB how the mobile hardware will respond to that? Do i need to depend upon external devices and not the mobiles? Please provide your comments.
Thanks & regards,
Siva.
Your question is in fact about the dynamic range of the audio input of a mobile phone - any value you record must be capable of being represented in the scale used to measure it.
There is an associated question of what the largest sound pressure level that a particular phone can record, but this is ultimately limited by the dynamic range and the design of transducer used. Any absolutely measure is relative a calibration point - which in digital audio systems is dB FSD (e.g. ratio sample to maximum), yielding negative values.
The dynamic range in dB of a ideal PCM system is limited by quantisation noise and is related directly to bit-depth (Q) of the sample:
SQNR = 20*log10(2 ^ Q) =~ 6.02Q
State-of-the-art ADCs used in pro-audio equipment typically have 24-bit sample depth giving a SQNR of 144dB. It's worth noting, that in silicon ADCs and DACs, the thermal noise floor of the analogue section of the converter is smaller than this, and the LSB might as well be random.
AFAIK, Android is using 16-bit PCM, which has a SQNR of 96dB. This is the same performance as the CD Audio standard. A SNR of 110dB wouldn't be bad for pro-audio equipment.
In practice, audio quality is rarely a headline feature of phones and most get nowhere near this. Most users use crappy headphones or the on-board speaker of their phone for voice calls and won't notice the difference. It's an obvious corner to cut from both a cost and power budget point of view for a phone manufacturer.
Additionally, good digital audio design is a black-art. Factors such as decoupling of digital signals from ground and physical proximity of analogue components come into play. You find that in tear-downs of Apple kit, they often place the codec right next to the headphone jack, and away from the main board of the system. Again, other cost-conscious manufactures don't do this, and it'll degrade the dynamic range of the system.
In order to get meaningful measurements from the audio input you will need to disable both automatic gain control (AGC) and probably the HFP (used to remove DC bias, and often set with Fc > 100Hz for voice calls).
If your intention is to record absolute SPL, you will need to calibrate the audio system of the device to a set-point. There is no standardisation of this between manufacturers (or even devices from any given manufacturer). Unless you fancy doing this for the devices on the market (of which there are a lot), you'll never provide universally accurate measurements.
I want to build a software which takes audio signals (from electric guitar jack cable) and transmits them to audio output.
At first, I guess I should make a program that transmits the sound, without changing it, to the output. And I guess this involves a Jack-To-USB adapter.
My aim is to change the signal, like its pitch, gain etc.
Any ideas how to do such a thing?
Thanks for any help :)
P.S.
I mean live. The signal should be transmitted as soon as it is received from the USB input.
Take a look at Android' MediaRecorder.
http://developer.android.com/guide/topics/media/audio-capture.html
If you mean low latency when saying live then there are issues, because on most Android devices you get delays between the input signal and the output signal of more than 50ms. But typically, people would accept a total latency of less than 20ms.
For your special purpose of pitch-changing the algorithmic latency additionally increases the total latency to an intolerably high value even for amateur use - as I said: on most Android devices.
If someone wants to write a android application that interacts with a physical device, specifically a reader using mobiles audio jack
(e.g. Like how Square Inc is doing ) how is this done?
Is there a api's to interact with the reader and get the cards data?
When a company creates a reader (physical device) does it provide relevant apis?
Are the physical details abstracted from the application programmer?
I have found the AudioRecord class which can record magnetic stripe data from audio jack
But I can't fiqure out how to capture the actual card swipe event and
to extract the meaningful data from RAW DATA
Can any one help me with this
Any input is highly welcome!
The way this usually works is by encoding the data signal sent out by the device, like the card reader, in such a way that is can be decoded on the other end. Sound is a wave, and different amplitudes correspond to different loudness, and different frequencies correspond to different pitches. Imagine you have a sine wave, that varies between a high and a low frequency that are sufficiently different from each other so as to be easily distinguishable. The device sending out binary data (0's and 1's) can translate this data into an audio signal that varies by frequency (an alternative is varying amplitude). The receiver, in this case the mobile device, decodes the signal back into 0's and 1's. This is called "Frequency-shift-keying" (check out more here: http://en.wikipedia.org/wiki/Frequency-shift_keying).
The simplest way to implement this is to try and find an open library that already does it. The device sending the data will also need to contain some kind of microcontroller that can perform the initial modulation. If you come across any good libraries, let me know, because I'm currently
looking.
To answer your question, companies do not generally provide APIs etc to perform this.
This may seem like a lot of extra work to convert a digital signal, into an audio signal, and back, and you're right. However, every mobile device has essentially the same headphone jack, whereas the USB port on an Android is drastically different from an iPhone's lighting connector, or the connector in previous iPhones. Sending wirelessly through a network or Bluetooth is also an option, but they have their disadvantages as well.
Now the mobile device must be using a special headphone jack that supports microphones, otherwise it cannot receive input, it can only output sound. Most smartphones can do this.
Radios work on this principle (FM = Frequency modulation, AM = amplitude modulation).
Old dial up modems used FSK, which is why you heard those weird noises each time it connected.
Hope that helps!
My quest is if anyone knows how to create an Android app that can send electric charge through the device's headphone jack, like in this video iPocket_LED. The video shows an app for iPhone that controls a LED plugged into the headphone jack.
I want to know how to access the device to send an electric signal.
Sorry about my English, is not my language, I hope some one understand me
Many consumer devices which accept an external microphone will provide "plug-in power". This is a small voltage typically from 1 to 5 volts across two of the contacts in the microphone connection.
Apple and (most) Android devices are no exception. Most use a 4-conductor TRRS connection with the following pin-out:
TIP = left headphone out
RING = right headphone out
RING = ground
SLEEVE = mic in + plug-in power
The plug-in power is usually around 2V on smartphones and is supplied as +2V on the microphone (sleeve) conductor. The phone will only supply it if it detects that a microphone is in place, which it does by testing the resistance across Mic to Ground to see if it's consistent with a microphone's impedance - something like 200 to 5000 ohms impedance, and I hear the iphones can be very fussy with this and need very close to 1600 ohms.
This means the maximum power you could draw from this and still seem like a microphone would be pretty small - around 1.25 milliamps. There are some low powered microcontrollers or other devices you may be able to power with this.
Note that plug-in power may be a similar concept to "phantom power" as used in pro audio gear but it's a different and incompatible standard. "plug-in power" is what causes the tiny electret microphones in smartphone headsets to work without needing their own small battery.
As for how to actually exert control over your attached device from an app, that's getting into much more complicated electronics. Presumably it is possible if you use the left and/or right headphone out lines to send signals to the device.
You'll need to play some audio. A small amount of current flows anytime audio plays, that's what moves the tiny little speakers in your headphones. The voltage will vary with the level of the audio. It is also AC current, such that the frequency of the sound (pitch) affects the frequency of the AC cycle.
It is going to be difficult to integrate with a device using this approach, especially because of the AC current. You can determine the appropriate pitch to send the voltage you want, but most "devices" are probably going to want a +3.3v or +5v DC signal. You'll probably need to do an AC to DC conversion to make that work.
I believe there is a means to integrate with an Android device via the USB interface. That would probably be far better and easier. You could get yourself an Arduino kit with a built-in USB shield/controller, and build your device on top of that.
See External USB devices to Android phones?
Yes using both at the same time is possible as this is how phones are designed to work. In fact depending on which specific device you have, overriding the volume limit will also give you a bit more power.
The best bet as far as lowest possible loss would be active rectification: at the null point have it switch over to +2V and the rest of the time whichever is the highest peak gets rectified. Simple enough to use two dual MOSFETs and this should get you enough power to at least initialize a phone though probably not charge it.