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.
Related
I'm trying to understand how IoT could help the company that I'm working for. This company provides software and hardware to others - take, for example, printers.
We already build and deploy software on the printers which have the ability to report back information (somewhere) so that management can react to certain data points:
Printer ink levels
Printer status (working, jammed, off, on, etc)
Printer state (good, errored, etc)
What would an IoT solution do for this type of situation?
As I understand it, IoT is mainly all about data and how we can analyze the data coming in from a fleet of devices.
Some things I've thought might be beneficial:
Instead of sending just "Printer Ink Low" and "Printer Ink Empty", continuously send the raw printer ink levels somewhere where you can analyze the average rates of printer ink use. You can then use that data to preemptively refill the ink.
Separation of concerns - software around the printer ink or printing process should be separate from the reporting aspect of the printer ink levels.
Similar to #1, sending raw data to be processed/learned upon to somewhere else is beneficial, as processing the data is moved from the device (which should focus on printing) to somewhere else (the cloud, a local compute server).
This collected data can be used to analyze trends and make business decisions.
This collected data can be used to preemptively act on situations instead of reactively (increasing efficiency).
Other questions:
As I understand IoT, it is usually a physical device or sensor that can connect to the Internet (either itself or through another device) and send up data. It usually is a physical device, but can it be more of a software device? IE a docker module that monitors the system and reports data? Would that be considered an IoT solution/device?
Although, stackoverflow is not the right place for such open questions (I would suggest other fora, like, e.g., researchgate), in general, the answer to all your questions, is yes, you are on the right way.
Especially for your last question, you have to have some kind of hardware (e.g., an extra or existing ink level meter inside the printer). All those hardware devices that interact with the environment and monitor something (temp, humidity, salt in water) are the sensors. Behind the sensors, you can have any kind of software/cloud/program/other hardware (e.g., raspberry/arduino), to implement your specific needs.
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.
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.
For those not in the know, Spaceteam is a very popular and very fun multiplayer game for iOS.
It allows for real time gameplay among multiple devices on an ad-hoc Wifi network - how does it do this?
Are there published libraries describing how to build protocols on top of ad-hoc networking libraries? Is it iOS specific, or would it be possible to build a variety of applications across different platforms?
Quickly, answer before we hit the asteroid!
Specifically which aspect are you interested in? There's nothing particularly special about mobile devices or ad hoc Wi-Fi networks (except in an ad hoc network, not all devices may be able to communicate with each other, so some mesh networking can help but unnecessarily complicates matters for the normal case).
I'll answer the broader question first, because it's more interesting. In my experience, there are a handful of major considerations:
Server/client or peer-to-peer? By this I mean whether there's a "master" deciding the true state of the world and communicating this to all clients. Avara is the only game I know of that is "peer-to-peer" in this sense (peers sent commands to all other peers; this proved bandwidth-heavy for modem users on 6-player games). I am not aware of games using more sophisticated network topologies to communicate game state (e.g. only sending data to one client on each LAN).
What do you do about latency? Avara is the only game I know of which lags everyone locally by the "latency tolerance" in order to get a consistent state of the world, which was terrible if someone was on a modem (turning off compression helped a lot). There are various ways to do "latency compensation" (e.g. in Half-Life/CS), some of which could also work on peer-to-peer games.
Time sync? For client-server games, you at least need to worry about a changing RTT. For peer-to-peer games, I think you also want to agree on timing that minimizes the effective maximum latency.
What if clients disagree about the state of the world? Avara just lets peers decide on their own state of the world (and displays "reality fragmentation detected" if it senses a mismatch, which might happen due to dropped packets or a too-low "latency tolerance").
What if a player leaves? For a P2P game, you might have to agree on a consistent game state (e.g. if the player was disconnected after sending commands to a subset of other peers). For a client-server game, you might have to elect a new master.
And now, after watching the Spaceteam trailer:
I have no idea how it works, since I haven't reverse-engineered the protocol. However, it's pretty simple to make something that works well enough:
Use some sort of P2P discovery to find players (e.g. Bonjour; there should be plenty of docs and samples out there).
Communicate with peers. I've done this with GameKit circa iOS 3/4 (I'm not sure if it still works over Wi-Fi).
Elect a master. This can be as simple as whoever presses "ready" last attempts to be the master. In some edge cases you might have to handle failure.
Let the master decide everything. Spaceteam is not latency-sensitive; Wi-Fi latency tends to be at most a handful of milliseconds, and nobody's really going to notice if one device is slower by 100 ms (as long as the UI responds fast enough).
There is a library made by Spaceteam that does this for Unity games.
https://github.com/hengineer/CaptainsMess
The creator of Spaceteam also wrote an old blog post about Networking in Spaceteam
http://spaceteamadmirals.club/blog/the-spaceteam-networking-post/
There is an iOS only library that will connect nearby devices easily called MultipeerConnectivity https://developer.apple.com/documentation/multipeerconnectivity
If you want something that will work cross-platform I have an example app here: https://github.com/brendaninnis/LocalNetworkingApp, which I explain in great detail here: http://brendaninnis.ca/connect-nearby-devices-part-1.html
My and my fellow students are deciding on a choosing a simple microcontroller to do very basic image processing. We are basically trying to implement template matching to find a set of objects in specific portions of the image. We'd like to use a connect a webcam to the microcontroller to do the job take the pictures and look for the objects. We also require basic wireless communication (e.g. bluetooth or wifi).
I don't think we will have the luxury of using state-of-the-art microcontroller, but something thats been around for a while (due to budget and stuff). Could anyone please advise on which specs of the microcontrolelr would be the most relevant for the above task (e.g. CPU, MIPS, etc).
Thanks a lot!
For this kind of a task, I would say the amount of RAM is the most relevant spec.
A microcontroller with an external memory interface allows you to extend the data space with additional SRAM to hold your image data.
Also note, that memory is needed for any protocol stacks you need to implement (Bluetooth, TCP/IP even more so).
You probably want to have total RAM in tens of kilobytes, preferably 100+ kB.
It is also nice to have plenty of program memory available when learning and experimenting. Later on you can try to optimize and squeeze your code into a more confined device.
As for the architecture, choose something you can easily find development tools and examples for.ARM, AVR and PIC are all good candidates among others.
Also find out what interfaces you need to use to
control the camera (e.g. I2C or SPI)
read pixel data (e.g. parallel or analog)
Connecting directly to a webcam's USB interface would not be a straightforward task, as the microcontroller would need to act as a USB host.
Good luck with your project!
You may need a microcontroller with following features:
USB 2.0 Host controller
1.2MB of memory for buffer 640*480*2(bytes per pixel)*2(double buffer)
(you may use lower resolution if there are not enough memory)
Wifi controller
CPU power strong enough for your task
Ready open source code
It seems that broadcom controllers may be useful here.
Also, you can by off-the-shell Wifi router with usb port and use it for your project
(i.e. Linksys E3000 )