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.
Related
I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)
There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.
I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.
I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.
However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.
I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).
Some constraints I'm working with:
The peripheral is battery powered.
The usual search and pair method must also still work.
My own half-baked ideas:
Make the peripheral able to be a central too, but then does that
introduce more nuances and complications?
Broadcast from the peripheral, "whoever has X mac address,
please connect to me"
Put a similar message in the advertising packet and increase advertising
rate.
Directed advertising similar to above?
You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?
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 currently working on a project for my university course. I am design a device which will be an intermediate interface between the computer and a USB flash drive, i.e. data go from computer->my device->USB drive.
One of the functions I want on this device is to be able to detect if there is any data activity going on, and send this information to the microcontroller. I don't need to know anything about the data itself, just whether there is data being transferred.
I've done some research online about how USB works, but I can't seem to find a good way of doing this. I have spoken to a tutor at uni. Apparently this is "very easy" to do, but I don't really know how. Can anyone suggest some ideas? Thanks very much.
In this case the simplest way is to use additional soft which can log USB protocol as well as a microcontroller, like USBlyzer (http://www.usblyzer.com/) or USB data capture (http://www.eltima.com/products/usb-capture/)
You need to insert your flash drive to device which is plugged to USB port in your computer. Then run USB data analyzer software and find the USB port. That's all! After that you can monitor and analyze all data between microcontroller and the app. Moreover, you can save and export captured data
Your tutor not quite right.
USB bus always have activity, even if no data transferred.
Carefully read USB specification (http://www.usb.org/developers/docs/), especially 'Protocol layer' section. Some basics you may read in 'USB in a nutshell' article.
Explore bus with oscilloscope.
Also you may use software analyzers like http://desowin.org/usbpcap/ or http://freeusbanalyzer.com/ to explore data on bus.
I think, will be enough to capture all packets on bus with external microcontroller, measure their duration and sort waste SOF packets and valuable data packets.
Sure, your microcontroller must be fast enough, to keep pace of USB 2.0 bus. Detection of activity of low-speed devices, like keyboard, will be much simplier, and may be done even with arduino.
You are trying to make a protocol analyzer like catc http://teledynelecroy.com/protocolanalyzer/protocolstandard.aspx?standardid=4
These is a device which is like man in middle for any network.
You would need your device to act as USB host(master) and USB device(slave) at same time. Also while copying data from one port to another you need to make a data copy for analysis. USB devices have critical timing requirements and operate at high data rate. So you might need good amount of processing power in your device. Also this makes such analyzers expensive.
If there is no requirement for analyzing USB protocol, you can have device that will analyze slower buses like uart,spi I2c etc.You can check hobby manufacturers like sparkfun for such tracing devices.
Best luck with your endeavor
I read a lot about WiFi sensors being used to track smart phones in Retail environment. The location triangulation is done on basis that a smart phone has its WiFi turned ON, be it in connected or unconnected state.
Case 1 : WiFi turned ON but unconnected
Why should a smart phone which has its WiFi turned ON need to transmit the packets, unless the user 'scans' for nearby WiFi networks?
Case 2 : WiFi turned ON and connected
Why should a smart phone transmit any packets, unless the user is browsing the net?
In both the above cases, there is a high chance that most of the time the WiFi device does not send any packet, which means none of the WiFi sensors detect it. If that is true, then the whole idea behind WiFi sensor based triangulation in Retail goes for toss, clearly with so many companies working on this, I must be wrong. Please answer with more than a yes or no, as to which packets are generally sent in both the above scenarios.
If wifi is turned on it will periodically search for new networks. This happens even if you are already connected to one, as it allows the device to connect to a 'better' network, if available.
Scanning/network discovery can be done in two ways. First is passive when a device listens to surrounding access point's (AP) beacon frames. These are basically advertisements for their network. The second method is called active. This is the most likely explanation of how the technology you mentioned works. Active scanning is when the device sends out a probe frame asking for available APs. These are generally ones that you have associated with previously, e.g. Your home network. These probes can be listened to from nearby 802.11 (wifi) devices, therefore tracking you.
Active and passive scanning
801.11 frames
As mentioned in #AndrewLeeming answer, one of the causes for data transmission data is scanning.
It's not necessary but normally it will be performed to find a network to connect to (or a better network in case of already connected). Active scanning can be turned off for power saving reasons. Passive scanning doesn't involve transmissions, so it's irrelevant to this question.
However, the most important reason for WiFi devices to transmit packets while connected is to let the AP know that the client is still available. Otherwise the AP will drop the link after a certain period of time without activity. Additionally, the clients might be in power save mode and instruct the AP not to transmit data to them. From time to time the client will inquire the AP to see if there are any pending packets for it.
Im writing application that communicate (via serial port) with electronic device which i designed myself.
When my PC application starts - it opens available COM ports one by one and it sends some string ("What are you?" for example).
My device is programmed, to reply to that "magic question" with own ID (for example: "I am evil device for supervising employees").
When my PC software receive that "magic reply" it starts working normally and its not searching other ports anymore.
Of course im not using stupid questions in data transmission, its just example.
Question is - can i send strings like on all (not busy) ports, to discover my device?
If I can - how that "question" string should look? Are there any normalized standards?
This is not first project like this on my desk, but now im developing solution for little industry and i need to pay more attention what my application is doing, because there may be other devices connected to COM ports and I do not know how they can react.
Im sorry, if i made some language mistakes, english is my third language.
Thanks in advance for replies.
After Alvin Wong confirmed my concerns I thought about it again and redesigned my device discovery functionality, because I don't want to abandon that idea.
I will send unique-complicated-ID every 1-5 seconds from device.
When my PC starts - it will try to open sequentially all available ports and will listen for that ID for few seconds.
If application receive that ID - it will be confirmation, that port number/name is correct and I my connection is established.
No, you wouldn't want to do that.
When you are using COM serial port, you have no idea what is plugged into the port. It could be nothing, your device, a modem, a mouse (though I believe nobody uses this anymore...) or whatever you can't even imagine.
Imagine if it is connected to another computer (probably a Linux/router), sending things may lead to execution of "that command", thus creating unexpected effects (though your program may not notice). Or if it is some badly-programmed device, it may trigger a bug in the firmware, thus failing the device and making it malfunction.
In short, in the worst case, you can cause a catastrophic event.
Serial (RS232 or UART I assume) communications don't have a designated transfer protocol (in contrast to USB which has one) to identify a device, so it isn't fail-safe. The user must make sure he selected the correct port. This is probably one of the reasons why hardware manufacturers choose USB, and one of the reasons why USB is so popular, even to computer idiots.