I have seen several projects now which derive novel spatial information from radio data collected from a typical wireless router:
http://wisee.cs.washington.edu/
http://www.extremetech.com/extreme/133936-using-wifi-to-see-through-walls
The idea of using a wireless router as a sort of passive radar is fantastic.
I am very interested in experimenting with data collected from a wireless router myself, but there is little information on how to go about actually interfacing with a wireless router and getting a raw stream of information collected by the device. Similar questions have been asked on here before, but I am yet to see a satisfactory answer.
I don't have the rep points necessary to link to the other questions but see:
'Capture Raw Signal from WiFi card as You Would a Sound Card'
'raw wifi “signal data” access'
I am looking for a solution that would let me use a low-cost device such as the oh so common WRT54G wireless router. If your answer involves custom radio hardware, you needn't bother posting.
As far as I know, the only option using a commodity hardware is to use Intel 5300 Wifi card. You can get the complex CSI (amplitude and phase info therein) from the three antenna on it from a sample of subcarriers (OFDM). You can take a look at this site:
http://dhalperi.github.io/linux-80211n-csitool/
If you read the wisee research paper you will find the platform they use for the system, it is USRP N210 from Ettus plus GNU radio software.
So it is not your usual WiFi AP they are using but the SDR solution this question also hints about.
WiFi devices are build to handle physical layer in silicon and the monitor mode is the best thing you can get without going the SDR path. You can get quite a lot of information from it - the radiotap header contains for example received signal strength and receiving antenna information. But if you really want to explore physical layer of WiFi then commodity hardware is not going to cut it.
Related
Background
I'm very new to electronics/IoT dev. I'm trying to create a solution to be able to read my wife's Car's CAN Bus signal (messages) and store it to an SD card. I hope to analyze the data and build a dashboard based on the car's telemetry.
This specific question is in relation to a chip (STM32F1) on an IoT board (MXChip AZ3166) I already own, which I hope to incorporate into my overall solution as the data acquisition layer.
For reference the:
Chips is the: STMicroelectronics STM32F103C8T6, 32bit ARM Cortex M3 Microcontroller
and the IoT board is the: (MXChip AZ3166 IoT DevKit)
Reading the MXChip AZ3166 board's spec and after doing some research, I have found out that the MXChip AZ3166 comprises two main chipsets:
Vendor
Part Number
Ref Link
STMicroelectronics
STM32F103C8T6
https://uk.rs-online.com/web/p/microcontrollers/1023545
MXChip
EMW3166
https://www.mxchip.com/en/products/module/54
Main Question
The product specification mentions the STM32F1 features Comprising of motor control peripherals plus CAN and USB full speed interfaces, it also states it has 1x CAN Channel. Does that mean I can interface the MXChip AZ3166 board featuring this chip via the GPIO pins to the CAB bus in my wife's car and receive the CAN Bus signals (I presume adhering to the
ISO 11898-1 CAN data communication protocol).
How would I find out which pins to connect to the CAN Hi & CAN low connections on the cars CAN Bus?
Concerning power, how would I determine that the CAN signal received doesn't fry the MXChip Board with a stated max Operation voltage of 3.3v?
Yes you'll want an MCU with a built-in CAN controller for communicating on a CAN bus. However, the CAN standard only covers the physical and data link layers. You need to know the application layer in order to meaningfully interact with a bus.
The application layer on a car may or may not be proprietary. It may even be encrypted. If you don't know what protocol is uses, then no can do. Reverse-engineering CAN protocols is hackish, hard and dangerous. Plugging into a CAN bus where you have no clue about timing considerations etc is also very dangerous.
But cars usually have an "on-board diagnostics" (OBD) port used for service purposes, with standardized application layers, through which you may have access to various parts of the car. There's lots of different standards for OBD and older ones didn't even use CAN. It depends on the car model.
In case of the OBD port the pinouts are standardized and you can find them on the Internet. Otherwise it is very simple to find out which signal that's CANH and CANL with an oscilloscope. CANH goes 2.5V +1V and CANL 2.5V -1V. A more hacky solution is to measure this with a multimeter, but it's perfectly possible since one signal with be slightly above 2.5V and the other slightly below.
CAN is standardized so if you have a CAN bus on the board, you connect there. In some cases there may be 12V supply wired together with the signal and that's the only one which could fry something.
Overall, please note that the project you describe here is very difficult and not a beginner task. It sounds as you have next to no experience of electronics/embedded systems, so I would recommend picking a far simpler project.
Furthermore, modifying car electronics or installing your own electronics in a car is illegal in most parts of the world. Third party type approvals with EMC tests are mandatory (and very expensive). If your car is involved in an accident and they find custom electronics without type approval in it, you could be facing serious legal consequences.
I am new to ESP8266 and started just building basic devices using it. However I am using USB 5V wall adapter as nodeMCU has USB UART converter to 3.3V.
If I want to make it battery powered what is simple , small ( in volume so that it can fit along with nodemcu and sensors in a small case) and economical approach that keeps my nodemcu still safe?
-One option I can think of is to connect a Li-ion battery of 3.7V to VIN.
-Another one is to use bigger voltage and use a converter to convert it down to around 5V and then use that to connect to VIN.
Please let me know if this works ? else if there is any better option please do suggest. Also if you are referring to any items/products please help give the exact model numbers so that I can search on internet to consider buying them.
Lastly I am not much aware of electric circuits & terminology yet ( learning them), so please help explain me in basic terms possible.
Ps: this question was seen on stackoverflow some times but I couldnt find one single consolidated answer and am confused by it. Appreciate your understanding.
Thanks,
Sridhar.
This really would be better suited for the electronics sister site or a esp8266.com forum but for what it's wort here's my input.
IMHO the most convenient option you have is to buy a devkit with a LiPo connector. I recommend a WeMOS D1 mini plus a fitting battery shield. An alternative is the Adafruit Feather HUZZAH.
It can sometimes be a bit of a challenge to find the right connectors for those boards. Gotcha! different revisions of those boards might use different connectors. Currently the WeMOS battery shield uses a 2 pin JST PH 2.0mm.
No, you cannot power a NodeMCU using a 3.7v li-ion battery directly. A fully charged Li-ion battery outputs a voltage of 4.2v. The NodeMCU board has a (5v and above) vin slot along with two 3.6v slots. If you directly connect the battery to the 3.6v, it may fry the NodeMCU board. So typically, there are 3 ways you can connect the battery without frying your board in this scenario:
You can use a boost converter to convert the 4.2v output to 5v. Then connect it to vin. This will draw more current and battery discharges quickly (eg: MT3608 step up boost converter).
You can use a buck converter to convert the 4.2v to a steady 3.6v (eg: LM2596 step down converter).
Finally, the most efficient way is to connect a 3.3v LDO in middle. The difference between using a buck and LDO is, buck provides a constant and steady 3.6v output, where as LDO's output depends on the input voltage from battery (eg: S111733PI).
Is it possible to associate single wireless network interface controller (WNIC) with multiple Wireless Access Points (WAP) at a time? If not: why?
I've never heard about such a feature, so I assume it's technically impossible or fairly difficult and rarely implemented. Is it really that difficult/impossible to implement driver providing such a feature? Is it software or hardware difficulty?
I assume that TCP/IP protocols' specifications doesn't limit us at all because if I attach multiple WNICs to my computer, I can easily connect to multiple APs.
If it's software difficulty, than what's the actual problem? Does Linux/Windows kernel or WNIC's drivers limits it? Or maybe system libraries (like libc on GNU/Linux systems)?
If it's hardware difficulty, what actually limits us? Antennas? Using single radio frequency at a time? If yes, than why can't we implement frequency hopping (like Kismet does)? Because of lost packets during time spent on other channels? If yes, than can we associate WNIC with multiple routers working on the same channel (I know that channel overlapping is bad)?
Note: I'm not talking about dual band routers. I assume that we consider most common WNIC and AP which both work on 2.4GHz channels. If I have to put my question into OS context, than I choose GNU/Linux context.
Yes. The basic technique is that the client tells AP 'A' that it is going to sleep and then talks to AP 'B' while A is buffering frames for it.
Microsoft research worked this out a while ago:
http://research.microsoft.com/en-us/um/redmond/projects/virtualwifi/
Many low-level drivers support Wi-Fi interface virtualization (e.g. the BRCM wl command has options which support this).
Apple's AirDrop and MultiPeer features for OS X and iOS use a similar technique, but instead of talking to a 2nd AP they talk to a peer device.
As a final school-graduation project I try to develop a kind of spying-car. Which means there is an iPhone placed on a little LEGO-car and an iPad used as a "steering wheel" for the car. Also it is planned to transmit Audio and Video from the iPhone's microphone/camera to the iPad (more than the steering data vice versa).
In the first place the connection from iOS to iOS should be established over a local WiFi network and later - if possible - over 3G (by using the iOS devices network-IP and a DNS server to deal with frequently changing addresses).
My question is: which technology do you recommend using? I read about GameKit, peer-to-peer and so on, but I think these technologies are too abstract for later being able to communicate over 3G. I guess I need to go a little deeper into the low levels of the communication progress. Any suggestion that could bring me a step forward is highly appreciated! (also regarding other parts of my project)
One more thing: Some user suggested using a third party service and to route the sent (video) data over an external server. If possible, I'd rather not use any "middle man". It should just be a basic server-client communication where the iPad is the server and the iPhone the client.
It is kind of an open ended question, but interesting.
First of all, GameKit do have 3g p2p support, see here:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/GameKit_Guide/Matchmaking/Matchmaking.html
It will handle the peer-to-peer addressing and establisment of the socket. It can also handle voice chat, but I personally never tried this feature so I can't say if it is feasible in your case.
One idea is to leverage existing video-chat services. This will give you a low-latency audio/video channel with peer-to-peer addressing (well, likely using a central server).
Apple's FaceTime is such a service, but there is no public API to it (AFAIK). Same goes for Skype and Google.
There are some paid services that look like they have nice iOS APIs:
http://tokbox.com/platform
http://docs.weemo.com/sdk/ios/
You have to figure out a way to transmit control commands to the peer iPhone, I did not see if the services above had any possibility of sending text messages/arbitrary data.
Tokbox has a free trial so you could try it out and see if it works for you.
I would go for GameKit if this is a hobby project on a budget and there is time for hacking, and probably look into a more high-level API if there is a deadline...
sorry for writing this as an answer, but i don't have enough rep to comment...
i'm working on a similar project and i currently don't have any advice regrading video-streaming, however, from what i read (extensively) i came to the conclusion that i need to use p2p connection between devices for better performance and use socket programming in order to achieve this (although not the most easy to implement choice).
I considered using GameKit which i think will probably answer most of your needs as Krumelur pointed out. but in my case, eventually the app will be cross platform so i had to use low level network programming. you can check out my question here to see the sources i used to try and make the connection between 2 peers, hopefully you'll have better luck than me...
I'd like to have an iPhone and an Arduino-based device talk to each other. Here are the requirements:
I want to fully rely on iPhone's built-in components without any peripherals (for example, HiJack).
The less configuration before the two can communicate, the better. This means a WiFi-based is not desirable, because we'll need to set up Wi-Fi credentials for the Arduino beforehand.
Bitrate is not important. Only a few bytes are exchanged.
As cheap as possible.
I see that Bluetooth 4.0 LE (for example, Stack Overflow question iPhone - Any examples of communicating with an Arduino board using Bluetooth?) meets my requirements, but are there any cheaper solutions?
One thing that came into my mind is sound - the way Chirp used to share data between two iOS devices, but I don't know if is feasible on Arduino and, if it is, how much it would be. Any other solutions?
I can think of a few options:
Bluetooth, you can get a cheap one from eBay for about $10
Wi-Fi using Electric Imp (cost around $30), which is very easy to setup using the brilliant BlinkUp technique. See the project ElectricImp, control central heating via iPhone for an example.
Chirp is a brilliant idea as well. From a hardware prospective I see it is feasible to do in Arduino; you just need a MIC circuit ($8) and speaker.
However, the real challenge is the software side, i.e., the algorithm that you will use to encode data as sound and vice versa. If such algorithm requires intensive calculation, you might not be able to do it in Arduino, and you can consider using an ARM-based microcontroller.