we want to route the call to ip network instead of GSM network. for that purpose first we are connecting our mobile phone to a PC through bluetooth. So we want to transfer the real time audio data to that PC over bluetooth. Could you please help..
If you can trick the mobile phone to function as a bluetooth headeset [profile] -- which I doubt any phones would support because phones are, well, the consumers of such headset devices -- then you could use it like any other "headset" device. (It would be much more feasible to just purchase a headset or plug in a microphone.)
As far as "where the real time audio data is stored?" -- well, that just won't go anywhere. The "data" (perhaps already in an encoded/delta form) is briefly (like milliseconds!) "stored" in a few small buffers / integrated circuits in the radio circuitry. This circuity will vary based upon phone/radio module used and is not accessible from a PC.
Happy doing productive things.
Related
I have to write a BLE application on an embedded device and there are some features where I'm not sure if BLE supports that or whether I've to create some wrapper around everything or if it's maybe not possible at all. The gerenal descriptions of Bluetooth and BLE I found around the internet usually only cover the overall functionality but don't go in too much detail. If this post gets too complex I'll split it up into different smaller ones.
I use the STM32 BlueNRG-MS chip
1. Discoverability (resolved)
The user has to be able to disable the BLE function in case there are several devices in reach. I see that there are functions aci_gap_set_discoverable() or aci_gap_set_non_discoverable() but altough I set it to not discoverable I can still see it in the LightBlue App on my mobile. How would I correctly disable the BLE functionality of a device to make sure no one can see it or connect to it?
Update: Okay that has been a mistake from my end, if I call the aci_gap_set_non_discoverable() function it is actually undiscoverable. So that's fine.
2. Only accept connections of paired devices
I'd like to achieve a behavior such that, if you have an unpaired phone you have to set the BLE device into a pairing mode in order to connect. If the phone has already been paired, the BLE device shall accept the connection request regardless of whether it's currently in pairing mode or not. Is this what the whitelist should be there for or do I have to do this manually by saving the address of the device after successful pairing? If whitelist is the right approach, I read that newer phones cause issues with whitelisting because they change their address on a regular basis, how can I handle this? That's actually where I thought I'm gonna work with the "discoverability".
3. Automatically reconnect
I'm not sure if this topic has to be handled on the BLE device or on the mobile phone. E.g. my phone is paired with my car's radio, so whenever the phone is in the car it automatically connects - how is this done? It's still the phone that acts as central device I assume?
To test bluetooth scalability, I want the same device (a Raspberry Pi or a laptop) to emit several BLE advertisements. So far, I have tried using bleno (NodeJS), hcitool and CoreBluetooth for OSX, but I can not setup more than one.
Is this a hardware/system/bluetooth limitation? Has somebody managed to do this?
Different bluetooth devices have different maximum advertising rates. These typically range from 10Hz to 40Hz. Some bluetooth devices have the ability to spoof their MAC address so different advertisements appear to come from different physical devices. This is often important for scalability testing, because some receivers keep track of unique devices by MAC address.
As #Emil says in his answer, it is possible to "interleave" advertisements such that you change the advertisement (and ideally the MAC address) every few hundred milliseconds so it appears by receiving devices that there are multiple advertisers around. I have done this with both Raspberry Pi and iOS transmitters, but in neither case could I alter the MAC address.
It is important to understand, though, that the actual number of packets received when you do this does not change. So while you may be testing scalability of unique advertisements detected, you will not be doing the same thing as testing with multiple physical advertisers.
That's not possible by the Bluetooth specification. However you can start off with one data then set a timer in your app that stops advertising. Then you start off again with the next data. And so on.
I want to find a solution to broadcast voice over WiFi for the people in a march. Since Android and IPhone is the most popular devices among the people in the march, it would be great if i can find a solution for audio broadcast over wifi with limited budget.
I know that people in occupy movement use different app on their cell, but it is not suitable in a march in my city. As the authority in my country may temporarily shutdown the data over mobile network to disable the app.
If i can develop an app to gather the broadcast message (SSID) from a powerful wifi AP with a long-length directional antenna, I should able to deliver message among the people in the march. Is it a possible solution?
Also, is it possible to modify the AP to allow any device to join the AP without further acknowledgment and broadcast message to all devices in that network?
Any idea or opinion is welcome.
Many Thanks.
This will be difficult, especially with a large number of users. Since you only need to send audio in one direction, that will at least be a bit easier.
First, you're going to want to put that AP in the middle of the crowd with an omnidirectional antenna. Perhaps, in a backpack or something. Each phone on that network needs to "hear" when other phones are transmitting, or it will be a mess. Even though your application is one-way, 802.11 isn't.
Now, when you write your application, use UDP packets sent to the broadcast address. No need for TCP packets, as they will clog up your network anyway.
Use a simple voice codec, such as AMR. The codecs available vary from platform to platform. See this document for a list on Android: http://developer.android.com/guide/appendix/media-formats.html
Honestly, the easiest solution would be to go buy a small FM transmitter, since many phones have receivers in them anyway.
Every communication that is made without cable, everybody can listen but not everybody can understand. So, when I call someone with my phone, or send a sms my cellp phone send information, I want that my pc know this (I know that both have to the same frequency). Or some site or material to start with it. I have an android.
It's like make a operator communication, just that is my cell phone with my pc and not my cell phone with the operator
Please have a look at OpenBTS. It is an (experimental) open source implementation of a BTS (base transceiver station), the network node that handles the radio communication. Similar OpenBSC.
What you want to do is huge. You will need special hardware.
I have a client that would like a small PIC board that plugs into a PC's USB as a dongle in HID mode. It would basically just transfer small amounts of data over RF to another device across the room.
They would like the data to come from the web. ie. user clicks a link in their browser which wakes up the PIC board and begins a download to the PIC device without the need for another application to visibly popup in front of the user.
I would think this can't be done without the setting up the browser preferences and assigning a custom application to recognize the data file. The security issues with a link initiating this kind of flow of events must be too great unless I'm missing something.
Has anyone done something like what I described above?
You could write a small piece of software that runs in the background on the PC (e.g. a Windows service), and:
Interfaces to the PIC device via USB
Provides a web interface on port 80 or probably some other port, which the browser can then connect to.
If the PIC device is network connected (e.g. has an Ethernet connection, and its own IP address on the network) then the PIC device could provide a web interface to control it. I don't know how feasible it is to fit a small web server onto a PIC though--that would be a tight fit.
Yeah that sequence of events doesn't seem too kosher. Perhaps a browser plugin or a program running on the PC that handles communication between the PIC and web would be better?