The Altlibary is great at detection! One thing we noticed with testing is if we have an app doing both transmitting and receiving we are not picking up the other phones at times. (Very sporadic) With real devices like ibeacons we are constantly able to pick them up.
My question is how do we control the frequency of the transmitter vs the frequency of the scanning (recieving) so that we can both do transmission and detection at the same time?
My goal is to achieve the best of both worlds scanning and transmitting, is that even possible.
https://altbeacon.github.io/android-beacon-library/beacon-transmitter.html
By default, the Android Beacon Library's BeaconTransmitter uses the highest power and frequency allowed by the underlying APIs in the Android operating system. Here are the settings, showing the defaults:
beaconTransmitter.setAdvertiseTxPowerLevel(
AdvertiseSettings.ADVERTISE_TX_POWER_HIGH);
beaconTransmitter.setAdvertiseMode(
AdvertiseSettings.ADVERTISE_MODE_LOW_LATENCY);
While the settings are configurable, presumably you already want the fastest and strongest advertising for you use case. And that is exactly what the library does with no extra configuration. (Note: there is very little reason to lower the transmit power or frequency, because tests show that transmitters use negligible battery. See my blog post here: http://www.davidgyoungtech.com/2015/11/12/battery-friendly-beacon-transmission)
If you are seeing that hardware beacons are reliable, but some phone models' transmitters are not detected infrequently, then the issue may be hardware issues with those phones themselves. You may wish to characterize which ones are problematic.
I can confirm that I see very strong transmissions from the Pixel 3a, Moto G7, Samsung Galaxy S10 and Huawei P9 Lite I have handy.
Related
What is the most efficient industry-strength encryption method/library for mobile devices? Ideally, I would like it to be endorsed by the US government for transmitting sensitive data.
I have a number of mass-produced mobile devices, and I want to start encrypting
their satellite and GSM communication. The firmware is in C. My concern is that the battery won't last once I start encrypting.
Many thanks.
Way to platform specific...
Many ARM architectures have native, instruction level support for cryptography.
However, you should understand that you may be able to encrypt the message, but most of the message passing infrastructure is in-the-clear. Second, the standard recommendation for cryptography is NOT to implement it yourself-your implementation WILL be the part that fails first.
In the interest of academic study, I will ask you to consider All the AES You Need on Cortex-M3 and M4 by Peter Schwabe and Ko Stoffelen
As for power concerns, the display and cellular modem are by far the largest factors.
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.
Can we broadcast Music using wifi broadcast and listen to thhe same on devices supporting monitor mode.
I would like to listen on monitor mode because I expect the number of devices getting connected is too high for wifi to work properly using IP-protocol.
I want the wifi device to act as a FM broadcast where every device recieves every packets and stream the music.
Are you talking about this Wifibroadcast , here?
If so: well yes, monitor mode is the underlying technology, as can be seen here.
Now, if this is about doing a commercial product, sadly, you cannot expect any kind of interoperability from this.
Streaming audio/video over Wi-Fi is a business, and the the power in charge (Wi-Fi Alliance aka WFA) as some view on it, including certification programs. Have a look at Miracast, using Wi-Fi Direct.
As for multicast / broadcast, it is even more of a business and the realm of proprietary technologies for now (example here - and no, this is not limited to automobile). This is quite complicated, to start with because of the synchronization problem across receivers: you don't want 2 radio receivers in the same room to play with a 1 seconds delay, this would be cacophony.
EDIT:
Meaning, be it with the Wifibroadcast OSS project or with the proprietary industry about it, since there is not yet an open protocol for this (as "publicly available standard specification", I don't even go about implementation, FLOSS or not), you will have to provide a specific application for every receiver to match your broadcaster protocol, and vice versa. And that is the state of the industry today. That is what the company I mentioned above, or this other one more well know, or these are doing. And so, they do not interoperate. This will be your problem: provide a receiver app for Windows, Mac OS, Android and iOS (where you may not even have access to sub-layer 3 API) that will match your radio broadcaster protocol. And Linux too, please.
Though, this is the direction of history because this is what the user wants: stream A/V to/from device/application X from brand A to device/application Y from brand B.
And so people have been working on this, on layer 2, because layer 3 and above have unsolvable challenges with it, at IEEE since 2004 with Ethernet AVB, which is a set of protocols. You can download some of its standards for free, others for a moderate fee depending on how old they are. There is a SIG taking care of certification(http://avnu.org/certified-products/) to guarantee interoperability.
It is for 802.3 (aka wired Ethernet), but there is some work done to bring this to 802.11 Wi-Fi. Because again, that's what the user wants, the market is here, no question about that. It will take a long time. Even more to get consumer electronic grade devices or applications of the shelves. But they will interoperate out of the box, that's the goal.
There's even been work done on moving this to layer 3/IP as well BTW, with some performance sacrifice.
So come back in a few years, and all should be setup. Or, if you have lots of time and money and no urge to deliver, implement a solution based on these standards?
PS:
Link to AVnu (Ethernet AVB SIG) page about use cases for consumer electronics audio streaming, wired or wireless:
http://avnu.org/consumer/
...and its 10 pages white paper at the bottom of the page.
I am making an android application that requires me to detect the user's motion.
My application also requires me to use an external sensor, which is a Bluetooth smart sensor, for some other purposes.
Now I have two options:
to use the accelerometer and gyrometer of the android phone
fetch motion information from the bluetooth smart sensor.
I understand that Bluetooth Smart (ble) is more energy efficient than Bluetooth sensors.
However, I am confused as to which of the above options will provide me a more energy efficient solution on the Android device. EDIT: I am presently not concerned with the energy efficiency of the bluetooth device.
Also, please see that I want this comparison only because I don't want to detect accurate user motion, otherwise an external device(bluetooth low energy device) would have been better hands down.
The accelerometer and gyrometer will take roughly the same amount of power whether it's on the phone or the external device. The difference is the external device has to transmit that information over a radio signal to the phone. It makes more sense to just use the Phone's existing information if that's sufficient because it won't require any radio transmissions and will require less power. Also, the phone will have a much larger battery.
The sensors on the phone have nothing to do with Bluetooth... they're incorporated right into the hardware.
EDIT: The difference between Bluetooth and BLE is that BLE uses the radio much more sparingly. Radio transmissions take a good chunk of power. So, using on-board sensors is going to (most likely) take far less power than using a radio to communicate with an external sensor. Also, I have a feeling that the accelerometers are always on on the cellphone so getting readings from those is going to take no more power than is already being used, too.
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.