element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • Product Groups
  • Store
    Store
    • Visit Your Store
    • Choose Another Store
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
Arduino
  • Products
  • More
Arduino
Documents Winners Announcement: Auto Hacks and Beyond: Show Us How You Would Use the Arduino MKR WiFi 1010 Board and CAN Shield!
  • Blog
  • Forum
  • Documents
  • Events
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Arduino requires membership for participation - click to join
Actions
  • Share
  • More
  • Cancel
Engagement
  • Author Author: tariq.ahmad
  • Date Created: 2 Sep 2018 9:31 PM Date Created
  • Last Updated Last Updated: 6 Feb 2019 6:18 PM
  • Views 2594 views
  • Likes 20 likes
  • Comments 31 comments
Related
Recommended

Winners Announcement: Auto Hacks and Beyond: Show Us How You Would Use the Arduino MKR WiFi 1010 Board and CAN Shield!

image

Arduino Home

An Open-Source platform to create digital devices and interactive objects that sense and control physical devices.

Arduino Tutorials
Arduino Projects

 

Congratulations to vimarsh_ for Automating Industries !  You are the winner of the Arduino Engineering Kit!

 

We sent out MKR 1010 WiFi Boards and MKR CAN Shields to karthickiot , skd , contactdy14 ,  station240 , vimarsh_ , and palliser in order to demonstrate how engineers would !  We wanted you to show us what you could do with the MKR CAN shield or the MKR 1010 WiFi Board (you need a board to go along with the shield).

image

 

The Grand Prize, an Arduino Engineering Kit, was open for anyone who submitted a project in  Arduino Projects or on the element14 community using the tag MKR_Auto_Hacks!

 

Anyone that submits a completed Arduino MKR WAN 1300 project by the deadline can win the grand prize.

 

Finalists:

 

Automating Industries by vimarsh_:

 

Fires in Industries have the most devastating effects. Just due to a flammable gas and a spark, a fire can occur causing a huge damage.

Also now its necessary to monitor the status of the industry from anywhere. Be it home, for fire or police department or anywhere. I have an idea and that is to monitor the gases of these industries and also we can control exhaust or temperature to evacuate the gases or bring them to non-reactive state.

To get these readings from anywhere I plan to use MKR Wifi 1010 board which has WiFi as most of the industries nowadays do have a decent WiFi and so the data can be sent over to a server and also read. Also to control the exhaust fans and AC or any such atmosphere or something else I plan to use CAN shield. Although I don't know much about it  I had found out that most of the instruments in refining or manufacturing industries use CAN Interface only! We can also detect motion going on at some places and of course Temp, Humidity and Air pressure...

I also want the connected machines/devices to be controlled via web and the Conditions changing based on the phase of operation making it great and easy for automated operation of the machines...

 

 

Header 1Header 2
imageimage
imageimage

 

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

 

Vidor4000 CAN-Bus Project by alisterw :

 

Plug a CAN-Bus MKR Shield onto Arduino 4000 and read car's OBD-II data so it could be displayed on an HDMI screen in graphical form. What could be simpler, it should only take 10 minutes to bolt together one of the many CAN-bus examples to a graphical HDMI driver. The FPGA section could be used to scroll the graphical section of the screen horizontally, at high speed, in the same manner as done on an oscilloscope. So the graphs of engine speed, mass air flow, throttle position etc would be displayed in real time. Additionally an accelerometer could be added.

 

First problem to solve was to regenerate the FPGA file as required by TEXT-DEMO, so it could be modified. I used Quartus-II v18.1 on a Windows 10 PC. It would build the output file but that file would not run for some weird reason. After plenty of mucking about, I installed v18.0, and that generated a functional file, so I could run the TEXT-DEMO and get an HDMI text display on my HDMI monitor. Giacko also did some tests and had no problems using v18.0 and v18.1, but the subtle difference was his O.S. was Linux. Incidentally, some of the Vidor 4000 instructions state that a patch is required for v18.0, and that is supplied as shell scripts what Windows does not seem to like at all, so I didn't add these patches. I did try to run an old 32-bit laptop with Lubuntu to get round this problem, but many tools just don't play 32-bit mode any more, so I gave up on Linux.

 

As an experiment, it seemed a fun idea to use the FPGA's soft SPI ports, but I couldn't get any data from the MISO pin. Besides, the 'VidorPeripheral' FPGA code is not the same as the TEXT-DEMO FPGA code so I would have probably had to cut and paste some Verilog over. But the SAMD21's SPI port fired up immediately and I could get data in and out of the MKR CAN Shield. I tried the VidorPeripheral UART code as an experiment and that did work.

 

The next problem was that TEXT-DEMO now refused to display anything when the CAN Shield was plugged in. That was because both the MCP2515 CAN interface and FPGA text interface use the same SPI port and also some control lines e.g. INT and FPGA_CS (chip select) on the same pin. Because the Shield is hard-wired I had to move the FPGA_CS signal from Pin 7, to Pin 6, and that was very easy to do: in the Pin Assignment editor, change SPI_CS's pin from F16 to G16. The SPI port can talk to multiple devices provided chip selects are separated. To make debug easier, I soldered a 28-pin IC socket onto a piece of strip board and soldered in some pins on useful tracks viz. 0V, MISO, MOSI, SCLK and Pin 3 (CAN_CS). The switch was from a previous project! An HDMI converter is plugged in.

 

imageimage
imageimage

Experimenting with Arduino MKR WiFi 1010 and CAN shield. by station240 :

 

The software (and firmware) for the MKR Wifi 1010 and MKR CAN shield needs a lot more polishing and testing.

Several times the process of programming the device resulted in it vanishing or malfunctioning as a USB device.

Thus requiring unplugging the USB cable and sometimes the CAN shield to get it into a state which it would boot enough to be reprogrammed correctly.

The CAN libraries come with pitiful examples, which aren't complete enough to use in practical projects where errors and the process of getting data in and out of packets matter.

 

PCB on the MKR CAN shield needs some minor revision.

The top writing to label the CAN/power connections on the PCB is too small, and partially covered by the terminal block.

On the board I have, its clearly an earlier version where the text is even less clear, and also contradicts if you compare top and bottom.

MKR WiFi 1010 - Enable BLE Support by jomoenginer :

 

I was lucky enough to get a MKR WiFi 1010  to add to my Robot ARM project I am modifying for the Arduino MKR Giveaway contest and the first thing I wanted to do was to get it connected to the local network. With the MKR1000 I have been using, I have used WiFi101 from the Arduino IDE for WiFi network examples.  However, I found with the MKR WiFI 1010, the WiFi101 library is not valid and the WiFiNINA libraries should be used when using this device.  In order to use the WiFiNINA libraries with the MKR WiFi 1010, the firmware on the board for the U-BLOX (ESP32) device has to be upgrade to a minimum of v1.2.0.   The main issue I found was that the current downloadable version of the Arduino IDE from the Arduino site does not have the proper tools to perform the firmware update on the MKR WiFi 1010.  After some further searching, I found this post on the Arduino MKRWIFI1010 forum site that describes how to perform the firmware update on this board.

 

 

imageimage



 

Released on Arduino Day 2018, Arduino MKR Wifi 1010 board provides low-power energy consumption and simplifies prototyping of WiFi based IoT applications.  It features a Microchip AT SAMD21, 48 Mhz 32 bit MO+ ARM Cortex low power processor. Its the same SAMD21 as the MKR 1000, MKR Zero, and Arduino/Genuino Zero boards. A unique feature of the SAMD21 chip is SERCOM, a set of six configurable serial interfaces.  These can be turned into either a UART, I2C master, I2C slave, SPI master, and SPI slave.  The MKR WiFi 1010 adds an ESP32 module by u-blox which is a notable improvement from the MKR1000 Wifi. The NINA-W102 Module provides low power 2.4 Ghz 802.11 b/g/n WiFi, dual-mode bluetooth v. 4.2, and RF communication through an internal PIFA antenna.  The ESP32-W10 module has applications for automotive, smart cities, autonomous vehicles, medical technology, home and building automation.  Another key feature of the MKR WiFi 1010 is that it has an integrated Cryptochip, Microchip ECC508, for secure communication using SHA 256 encryption. Finally, its Li-Po charging battery circuit allows it to run on battery power or an external 5V source.  When plugged into an external source, the LiPo battery will charge, and then switch from one source to the other automatically.

 

Arduino MKR WiFi 1010 Pinout, SAMD21 Pin Mapping, Tech Specs, EAGLE Files, Github, Schematics, Reference Links, FAQ, and More!

 

The Arduino MKR CAN shield uses a Microchip MCP2515 Chip to connect to a CAN bus through its SPI interface.  The chip is an industry standard, add this shield to any MKR board so that it can easily connect to a Controller Area Network (CAN).  Most people associate CAN with automotive, but it has a number of industries including aerospace, factory automation, networking solution companies, medical technology, and building automation.  These industries rely on it due to the fact that its a reliable and robust vehicle standard in automotive where safety and reliability is critical. It can also be used for drones, automomous cars, and smart vehicles.  The MKR CAN shield simplifies the connection between your MKR board and any number of industrial grade sensors, motors, and displays. This challenge allows you to combine multiple ways of connecting devices using a variety of technologies.  The first combination of boards and shields is the Arduino MKR Wifi Board and the Arduino MKR CAN Shield.

 

Auto Hacks and Beyond with the MKR WiFi 1010 Board and CAN Shield

Arduino MKR WiFi 1010 Board

Arduino MKR CAN Shield

imageimage
Buy NowBuy NowBuy NowBuy Now

The MKR WIFI 1010 is equipped with an ESP32 module from U-BLOX. It speeds up and simplifies prototyping of WiFi based IoT  It aims to speed up and simplify the prototyping of WiFi based IoT applications using the ESP32 module and low power consumption. The board is composed of three main blocks:

  • SAMD21 Cortex-M0+ 32bit Low Power ARM MCU;
  • U-BLOX NINA-W10 Series Low Power 2.4GHz IEEERegistered 802.11 b/g/n Wi-Fi
  • ECC508 Crypto Authentication

The MKR WIFI 1010 includes 32-bit computational power, a rich set of I/O interfaces, and low power Wi-Fi with a Cryptochip for secure communication using SHA-256 encryption.

 

The Arduino Software (IDE) simplifies code development and programming. Ideal for IoT battery-powered projects in a compact form.

 

Its USB port can be used to supply power (5V) to the board. It has a Li-Po charging circuit that allows the Arduino MKR WIFI 1010 to run on battery power or an external 5 volt source, charging the Li-Po battery while running on external power. Switching from one source to the other is done automatically.

With this shield you can easily connect to a CAN (Controller Area Network) Bus. Discover new possibilities of interaction between your Arduino MKR Board and the CAN ecosystem.

 

The MKR CAN shield can simplify the connection of the MKR boards with industrial systems and especially with automotive applications.

 

This shield opens a new set of possible applications like smart vehicles, autonomous cars and drones. A CAN connection also provides the possibility to connect a MKR board directly with several types of industrial grade sensors, motors and displays.

 

The MKR CAN shield allows a MKR board to connect to the CAN bus using the MCP2515 SPI to CAN chip.

 

The Arduino MKR CAN Shield uses the MCP2515 chip by Microchip. This chip is an industry standard.

 

The switch close to the CAN bus connector allows to enable or disable the termination resistor.

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

 

Arduino Library for Sending or Receiving data using CAN bus: https://github.com/sandeepmistry/arduino-CAN

 

MCP2525 Library on Github: https://github.com/coryjfowler/MCP_CAN_lib

 

Compatible with any shield or CAN interface that uses a MCP2525 protocol.

 

Did You Know?

 

The Americas lead the world in connected car IoT projects with 54% of them worldwide.

 

The Grand Prize

After all the the MKR boards and shields have been sent out we'll be awarding an Arduino Engineering Kit to the best project that shows how an engineer would use the MKR line to repurpose an existing project or a new project.

 

 

Arduino Engineering Kit - MATLAB/SIMULINK
imageimage
Buy NowBuy Now

Each Arduino Engineering Kit includes:

 

BOARDS
  • 1 Arduino MKR1000 Board
  • 1 Arduino MKR Motor Shield
  • 1 Arduino MKR IMU Shield

 

 

ELECTRICAL COMPONENTS

  • 1 DC Motor
  • 2 Geared DC Motors with Encoder
  • 1 Standard Micro Servo (180 degrees)
  • 1 Hall Sensor Module
  • 1 Ultrasonic Sensor Module
  • 1 Webcam
  • 1 LiPo Battery
  • 1 LiPo Battery Charger
  • 1 Micro USB Cable
  • 1 3-pin to 4-pin Tinkerkit Module Cable
  • 1 3-pin Tinkerkit Module Cable MECHANICAL

COMPONENTS

  • 3 Sets of Assembly Pieces
  • 2 Wheels
  • 1 Caster Wheel
  • 1 Timing Belt
  • 2 Timing Pulley
  • 2 DC Motor Mounting Brackets
  • 1 Metal Shaft (90mm)
  • 2 Metal D Shafts (50mm)
  • 2 Sets of Distance Spacers (6mm, 17mm)
  • 2 Sets of M2 Bolts (10mm, 25mm)
  • 3 Sets of M3 Bolts (10mm, 15mm, 25mm)
  • 1 Set of M2 Nuts
  • 1 Set of M3 Nuts
  • 1 Set of M3 Lock Nuts with Nylon Insert
  • 3 Shaft Collars
  • 1 Propeller Adapter Screw
  • 2 Magnets Ø8 mm
  • 1 Thread 5m
  • 2 Whiteboard Pens
  • 1 Sticker for Vision Recognition

The Arduino Engineering Kit is the ideal solution for university students, providing a state-of-the-art, hands-on incorporation of Arduino technology in an educational setting.

 

The kit is primarily for three types of users:

  • Students learning about engineering at a university or at a vocational school (e.g., Introductory Engineering, Controls, Mechatronics courses);
  • Professors teaching engineering who also want practical resources to demonstrate engineering concepts;
  • Makers with an interest or background in engineering, either professionally or as a hobby.

The Arduino Engineering Kit covers fundamental engineering concepts, key aspects of mechatronics, and MATLAB and Simulink programming.Included projects challenges students intellectually and helps develop physical engineering skills — and they’re just fun to do.

  • Self-Balancing Motorcycle This motorcycle will maneuver on its own on various terrains and remain upright using a flywheel for balance. It’s very exciting to build and to see in action.
  • Mobile Rover This vehicle can navigate between given reference points, move objects with a forklift and much more. It’s very fun to make and use.
  • Whiteboard Drawing Robot This amazing robot can take a drawing it’s given and duplicate it on a whiteboard. It’s most impressive.

 

The kit is sold in a hard plastic, stackable tool box for storage and years of reuse. Inside the box is an easy-to-use Arduino MKR1000 board, several customized parts, and a complete set of electrical and mechanical components needed to assemble all three projects

 

 

 

 

 

Ask Questions to Arduino, during a Series of Livestreams on the Commercial uses of Arduino:

 

Massimo Banzi, co-founder of Arduino, and Dominic Pajak, a project person and retro computing geek from Arduino, will be giving a 5 part series of livestreams on the commercial uses of Arduino.  The next livestreams will be on October 26th and will cover Arduino MKR Vidor 4000 – Democratizing FPGA .  Be sure to tune in to ask Massimo any questions you have about commercial uses of Arduino!

 

Click on the "Enroll Now" buttons below to ask your questions and learn more:

 

Livestream DiscussionDate and TimeSign Up!
Commercial IoT Applications with Arduino MKR14th November 2018
13:00 (CDT)/19:00 (GMT)
Enroll Now
Industrial IoT Applications with Arduino MKR28th November 2018
13:00 (CDT)/19:00 (GMT)
Enroll Now

 

Previous Livestreams:

 

Recorded Live Stream: Massimo Banzi and Dominic Pajak: Arduino MKR: IoT Prototype to Production!

 

Recorded Live Stream: Massimo Banzi and Dominic Pajak: Arduino MKR and Wireless IoT Connectivity!

 

Recorded Live Stream: Arduino MKR VIDOR 4000 - Democratizing FPGA!

 

 

You're all familiar with WiFi and what it does.  Its omnipresent in our modern lives and used to stream data such as videos and music, interact with others anywhere in the world, instantly consume news and information with connect smart devices such as laptops, smart phones that we carry in our pockets, tablets, televisions, and game consoles. It's a technology that allows you to connect to the Internet.  But what exactly is it?  It's a protocol for transmitting data to a network.

 

While WiFi makes many of our devices "smarter", the Controller Area Network (CAN) in your car allows the all the electronic modules to listen for and send signals to one another in real time without a host controller. These electronics modules are known as electronic control units (ECU) and they are used for electronic control unit, transmission, airbags, power steering, power windows, cruise controls, and more.  There are as many as 70-80 electronic control units (ECU) in a modern vehicle and they can talk or listen to each other at anytime thanks to the Controller Area Network. Using this shield you can connect your MKR WiFi board to a number of sensors,  It's applications however extend far beyond automotive.  It is used in building automation, medical technology, aerospace, factory automation, and more.  It can also be used for drones, automomous cars, and smart vehicles.  The MKR CAN shield simplifies the connection between your MKR board and any number of industrial grade sensors, motors, and displays.  This makes CAN ideal for more than just auto hacks.

{tabbedtable} Tab LabelTab Content
What is CAN?

What is CAN (Control Area Network)?

 

CAN (Control Area Network), also referred to as CAN bus, is a communication protocol initially developed as a vehicle bus standard to allow MCUs to communicate with each other without the need for a host.

image

Although originally intended for automotive, CAN bus is used in a diverse number of industries due to its extreme reliability and robustness:

  • Building Automation
  • Aerospace (satellites)
  • Railways (trams, undergrounds, light railways, and long distance trains)
  • Medical (lights, tables, cameras, x-ray machines)
  • Lifts and escalators
  • Laboratory Equipment
  • Sports Cars
  • Automatic Doors
  • Telescopes
  • Gambling Machines

CAN is a message-based protocol that defines how data is transferred from one device to another in a network.  It was designed specifically for the automotive industry, where an increasing number of electronic devices used communication signals with more complex interrelations between them, making life difficult for the automobile engineers tasked with designing systems using point to point wiring.

 

Some of the benefits of CAN include:

  • Extreme Reliability and Robustness
  • No Message Collision
  • Very Low Resource Requirements
  • Low-Cost Implementation
  • Designed for Real-Time Applications
  • Short Error Recovery Time

 

You don't have permission to edit metadata of this video.
Edit media
x
image
Upload Preview
image

 

CAN facilitates multi-domain communication.  A domain is a set of technologies that have similar requirements.  Climate control, wipers, etc would form one domain while stereo, GPS, display, etc. would form another domain.  Every node, or electronic device, which needs to communicate through CAN protocol connects with one another through a common serial bus in order to transmit and receive messages.

 

For the data exchange to occur, each node must have the necessary hardware and software embedded in them.  In automobiles, these embedded systems are known as electronic control units (ECU).

Where Did It Come From?

Where Did CAN Come From?

When most people think of Controller Area Network (CAN), they think of what it was originally designed for,  allowing embedded systems, located throughout an automobile, to communicate over a network and work together for specific applications such as controlling emissions or deploying airbags. An embedded system is a programmed controlling and operating system designed for one or a few specific functions.  The system is embedded as part of a complete device including hardware and mechanical parts and they are used to control one or more electrical systems or subsystems within a vehicle. Examples of ECUs include the Engine Control Module (ECM), Powertrain Control Module (PCM), Transmission Control Module (TCM), Anti-Lock Braking Systems (ABS), Central Control Module (CCM), Central Timing Module (CTM), General Electronic Module (GEM), Body Control Module (BCM), Suspension Control Module (SCM), Speed Control Unit (SCU), and Electric Power Steering Control Unit (PSCU).

 

Before ECUs began appearing in automobiles in the 1970s, every component from the engine to the windows, steering, brakes, was a mechanical component, working on the principles of mechanics.  Mechanical systems have their inherent limitations and limited accuracy, not only causing undetected failures, but posing life threats to the consumer.

image

In 1968, Volkswagen became the first to use an embedded system in an automobile when it used an electronic fuel injection (EFI) system that was manufactured by Bosch. ECUs have become standard in most vehicles since the late 70s due to increasingly stringent emission standards. Before that time, it was possible to build your engine without microprocessors.  With the enactment of increasingly stricter emissions laws, sophisticated control schemes were needed to regulate the air/fuel mixture so that the catalytic converter could remove a lot of the pollution from the exhaust. Because controlling the engine is the most processor-intensive job on your car, and the engine control module (ECM) will be the most powerful computer on most cars. ECM uses a closed-loop control, a control scheme that monitors outputs of a system to control the inputs to a system, managing the emissions and fuel economy of the engine (as well as a host of other parameters). Gathering data from dozens of different sensors, the ECM knows everything from the coolant temperature to the amount of oxygen in the exhaust. With this data, it performs millions of calculations per second, performing complex calculations to find the best spark timing and determine how long to keep the fuel injector open. It does all of this to ensure the lowest emissions and best mileage.

 

Electronic control units (ECU) typically get their input from sensors (for speed, temperature, pressure, etc) which it then uses for computation. Various actuators are used to enforce applications determined by the ECU such as turning the cooling fan on or changing the gear. In order to perform these applications, ECU must exchange information amongst themselves during the normal operation of the vehicle. For example, the engine needs to tell the transmission what the engine speed is, and the transmission needs to tell other modules when a gear shift occurs. The development of the vehicle network arose from the need to exchange data between ECUs quickly and reliably. Point-to-point wiring was the only way to connect ECU to one another.  It had not only became increasingly complex, it required alterations depending on which modules were included with a vehicle. A car without Anti-Lock Braking Systems (ABS) would require different wiring then a car that included this module.

 

The need for a vehicular central network for automobiles became increasingly transparent due to the complex wiring of ECU, which would require alteration depending on what ECU were added or removed. A central network would allow you to simply plug an ECU into central network and any ECU that is added could talk to any other ECU that is part of the network. Such a design would be easily manufacturable, easier to maintain, and would not require altering the vehicle's entire wiring architecture every time an ECU was added or removed. Each ECU would be a node on the vehicle's network, controlling specific components related to its functions and communicating with other ECUs for shared applications, through a standard protocol over the vehicular network.

 

A central vehicular network required the following needs:

  • Low cost
  • Immunity from external noise
  • Ability to operate in harsh environments
  • Overall robustness and reliability

 

Before CAN bus, wire-to-wire harnessing could contain miles of harnessing, with bundles of 8 or more wires to carry various signals to interconnected systems.

image

In the early 80s, engineers at the Robert Bosch Gmbh, were evaluating using existing serial bus systems in vehicles. Because none of the available network protocols met the needs of a vehicular network, Uwe Kiencke started development of a new serial bus system in 1983.  The new bus protocol was intended to add new functionalities, reduction of wiring harnesses was a byproduct of the development of CAN.  Engineers from Mercedes-Benz were involved during the early specification phase of the new serial bus system, so too was Intel, as a potential main semiconductor vendor. A consultant, Professor Dr. Wolfhard Lawrenz from the University of Applied Science in Braunschweig-Wolfenbüttel, Germany, gave the network the name 'Controlled Area Network' In 1986, the protocol was officially released at the Society of Automotive Engineers (SAE) conference in Detroit, Michigan.

 

The multi-master network was introduced by Uwe Kiencke, Siegfried Dais, and Martin Litschel.  With no central bus master, it is based on a non-destructive arbitration mechanism, granting bus access to the message with highest priority without any delays. It implemented several error detection mechanisms such as automatic disconnection of faulty bus nodes in order to keep up communication between remaining nodes. Transmitted messages were not identified by the node address of the transmitter or the receiver of the message, unlike almost any other bus system, but rather their content. The identifier used to represent the content of the message specified the priority of the message within the system. In mid 1987, the first implementation of the CAN protocol in hardware was delivered by Intel, the 82526 CAN Controller chip. Philips Semiconductors introduced the 82C200 shortly after. Both CAN controllers had different methods of acceptance filtering and message handling. The FullCAN method used by Intel required less CPU load from connected microcontrollers but was limited regarding the number of messages that could be received. Today's CAN controllers use a mixture of both concepts of acceptance filtering and message handling.

image

In 1991, the Mercedes-Benz W140 became the first production vehicle to feature a CAN-based multiplex wiring system. Also in 1991, Bosch published the latest CAN specification, CAN 2.0. It consisted of two parts; part A is for the standard format with an 11-bit identifier, and part B is for the extended format with a 29-bit identifier. A CAN device that uses 11-bit identifiers is commonly called CAN 2.0A and a CAN device that uses 29-bit identifiers is commonly called CAN 2.0B. These standards are freely available from Bosch along with other specifications and white papers.

 

In 1993, the International Organization for Standardization (ISO) released the CAN standard ISO 11898 which was later restructured into two parts; ISO 11898-1 which covers the data link layer, and ISO 11898-2 which covers the CAN physical layer for high-speed CAN. ISO 11898-3 was released later and covers the CAN physical layer for low-speed, fault-tolerant CAN. The physical layer standards ISO 11898-2 and ISO 11898-3 are not part of the Bosch CAN 2.0 specification. These standards may be purchased from the ISO. Bosch is still active in extending the CAN standards. In 2012, Bosch released CAN FD 1.0 or CAN with Flexible Data-Rate. This specification uses a different frame format that allows a different data length as well as optionally switching to a faster bit rate after the arbitration is decided. CAN FD is compatible with existing CAN 2.0 networks so new CAN FD devices can coexist on the same network with existing CAN devices. CAN bus is one of five protocols used in the on-board diagnostics (OBD)-II vehicle diagnostics standard.

 

The OBD-II standard has been mandatory for all cars and light trucks sold in the United States since 1996. The EOBD standard has been mandatory for all petrol vehicles sold in the European Union since 2001 and all diesel vehicles since 2004.

Automotive Applications

Automotive Applications

A modern automobile has as many as 70-80 electronic control units (ECU) for various subsystems, with the engine control unit having the biggest processor. ECUs are used for transmission, airbags, antilock braking/ABS, cruise control, electric power steering, audio systems, power windows, doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, etc. Some of these form independent subsystems, but communications among others are essential. The CAN standard allows these subsystems to control actuators or receive feedback from sensors.  Examples include:image

  • Auto/Start - Various sensor inputs from around the vehicle (speed sensors, steering angle, air conditioning on/off, engine temperature) are collated via the CAN bus to determine whether the engine can be shut down when stationary for improved fuel economy and emissions.
  • Electric park brakes: The "hill hold" functionality takes input from the vehicle's tilt sensor (also used by the burglar alarm) and the road speed sensors (also used by the ABS, engine control and traction control) via the CAN bus to determine if the vehicle is stopped on an incline. Similarly, inputs from seat belt sensors (part of the airbag controls) are fed from the CAN bus to determine if the seat belts are fastened, so that the parking brake will automatically release upon moving off.
  • Parking assist systems: when the driver engages reverse gear, the transmission control unit can send a signal via the CAN bus to activate both the parking sensor system and the door control module for the passenger side door mirror to tilt downward to show the position of the curb. The CAN bus also takes inputs from the rain sensor to trigger the rear windscreen wiper when reversing.
  • Auto lane assist/collision avoidance systems: The inputs from the parking sensors are also used by the CAN bus to feed outside proximity data to driver assist systems such as Lane Departure warning, and more recently, these signals travel through the CAN bus to actuate brake by wire in active collision avoidance systems.
  • Auto brake wiping: Input is taken from the rain sensor (used primarily for the automatic windscreen wipers) via the CAN bus to the ABS module to initiate an imperceptible application of the brakes whilst driving to clear moisture from the brake rotors. Some high performance Audi and BMW models incorporate this feature. Sensors can be placed at the most suitable place, and its data used by several ECU. For example outdoor temperature sensors (traditionally placed in the front) can be placed in the outside mirrors, avoiding heating by the engine, and data used by both the engine, the climate control and the driver display.

 

When an ECU in a car needs a signal, that is where the CAN comes in. The CAN bus network allows data from sensors and embedded systems to circulate around a car at all times. Each embedded system transmits all its system and programming information constantly, as many as 2000 signals are floating around the network at any time, whether they are being requested or not. With no central hub or routing system, every ECU in the network listens and plucks out what it needs to carry out its work, from a continuous flow of information.

 

CAN does not follow the master-slave architecture which means every nodes has the access to read and write data on the CAN bus. When the node is ready to send data, it checks availability of the bus and writes a CAN frame onto the network. A frame is defined structure, carrying meaningful sequence of bit or bytes of data within the network. CAN transmitted frame does have address neither of transmitting node or the receiving node.  CAN does not follow the master-slave architecture which means every nodes has the access to read and write data on the CAN bus. When the node is ready to send data, it checks availability of the bus and writes a CAN frame onto the network. A frame is defined structure, carrying meaningful sequence of bit or bytes of data within the network. CAN transmitted frame does have address neither of transmitting node or the receiving node.

 

In recent years, the LIN bus standard has been introduced to complement CAN for non-critical subsystems such as air-conditioning and infotainment, where data transmission speed and reliability are less critical.

 

Industrial Applications and Beyond

 

While effective for small, embedded applications and automotive, using CAN in many other applications such as industrial or medical technology requires a higher layer.  Higher-layer protocols exist that to software on top of the CAN physical layer.  Notably, CANopen for industrial automation and SAE J1938 for off-road vehicle.


CANopen

  • ideal for embedded, industrial applications
  • designed for motion control
  • developed and maintained by the CAN-in-Automation (CiA) User Group

SAE J1938

  • defines communication networks for trucks, buses, agricultural equipment, eic.
  • CAN of choice for machines in construction, material handling, forestry applications

 

Derivatives of SAE J138

  • NMEA 2000 for marine applications
  • ISOBUS (ISO 11783) for agricultural applications
  • MilCAN for military applications

 

{tabbedtable} Tab LabelTab Content
Manufacturing Automation

Can Bus in Manufacturing

 

CAN is one of the most reliable methods for transmitting real-time data. This is attractive in manufacturing where unreliable data communication can have a direct impact on production. Any breakdown in error communication can also mean errors go undetected. A minor maintenance issue such as a loose arm could turn into a much larger issue down the line such as damage to product or machinery. The reliability of CAN is further bolstered by the impossibility of message collision and short error recovery time which help mitigate the likelihood of large delays or damage to equipment.image

 

Some of the benefits of CAN include:

  • Extreme Reliability and Robustness
  • No Message Collision
  • Very Low Resource Requirements
  • Low-Cost Implementation
  • Designed for Real-Time Applications
  • Short Error Recovery Time

 

However, a major drawback to using CAN for industrial use is the protocol's limited bit rate in relation to the network. CAN communication can reach up to 1 megabit per second at a cable length of 40 meters.

 

Some of the disadvantages include

  • Limited network length
  • Limited baud rate of 1 MBit/sec
  • Limited Bandwidth

By comparison, industrial ethernet offers speeds of up to 100 megabits per second at higher network lengths. However, Ethernet is far less reliable.  CAN already has extensive use in legacy industrial automation, so it can also be very costly to retrofit existing systems with Ethernet.

 

Can Bus in Elevators

image

The low-cost and reliability of Can Bus is used in elevator technology, where safety is critical and cost-containment is an on-going concern.  Can Bus, due to its serial technology, allows you to significantly reduce the wire count in the traveling cable, machine room, and throughout the building. Less wiring and fewer terminations ease fire loading and troubleshooting.  Elevators that are used in commercial or multi-family occupancies must contend with large groups of people interacting with powerful machinery to lift them off the ground. Also, usage is spread around all times of the day, year round.

 

A case in point is elevator technology, which continues each decade to write the book on reliability and safety all the while with a view on initial and on-going cost containment. CAN Bus, because of its serial technology, makes possible significantly reduced wire count in the traveling cable, machine room and throughout the building. Fire loading and troubleshooting difficulties are eased with less wiring and fewer terminations. Phone-style connectors allow easy field expansion.

 

An essential element in elevators as used in commercial and multifamily occupancies is that humans in large numbers and often including children and disabled or infirm individuals are interacting with powerful machinery that lifts them off the ground. This happens day and night, year round, and in the fullness of time there is the potential for equipment failure and injury to the interacting individuals. This hazard is greatly mitigated by means of the reliability that is built into CAN Bus technology.

 

Think of all the things that could go wrong in elevators used in large high-rise buildings!  You could have many elevator cabs going in motion at the same time, traveling in opposite directions, either reducing speed as they prepare to stop at a floor or accelerating after making a complete stop, all the while doors are opening and closing as needed.

 

The elevator cab responds in a pre-programmed, prioritized manner to call buttons that are pressed on many different floors, as well as, buttons pressed inside the cab. The simple, yet highly effective system of message management within the Can Bus is what makes this all possible. Every node is connected to one another through a two-wire bus. Each node requires a (local) central processing unit to determine which messages get transmitted. These messages are received by sensors, actuators, and control devices that are connected to the CAN bus. The CAN controller stores the received bits that are sent from the bus until the message is complete and it is made available to the host processor.

 

Using CAN, all nodes are available to receive messages but this can not happen simultaneously.  Data transmission for Can bus attains content resolution through means of arbitration. Binary bits values are termed dominant and recessive bits with "0" being dominant and "1" being recessive. The dominant bit always overwrites the recessive bit. Each message, packet of data that is exchanged between the nodes, has a unique identification number.  Because the identification number is unique to all nodes within the network, when a transmitting node places data on the network, it checks the unique id to pass the message through the filter and the rest are ignored. Messages in CAN are sent in a format called frames, a defined structure that carries a meaningful sequence of bits or bytes of data within a network. A Standard CAN frame is 11 bit identifier field while an extended CAN frame has a 29 bit identifier field.

 

Arbitration is the means by which conflict is resolved when two or more nodes receive a message at the same time. Whenever a bus is free, any unit can transmit a message. .During arbitration every transmitter compares the value of transmitted bit with the bit value on the bus. If the bit value is same, the node continues to send the bits. But at any time, if the transmitted bit value is different from bus value, the dominant bit overwrites the recessive bits. The arbitration field of the CAN message consists of an 11- or 29-bit identifier and a remote transmission (RTR) bit. The identifier having lowest numerical value has the highest priority.  CAN bus therefore realizes real-time prioritization using a system of dominant (logic level 0) and recessive (logic level 1) messaging. Neither information nor time is lost using the process of arbitration.

 

When arbitration takes place, the lower priority message is not obliterated, as is the case in some other types of serial transmissions. The message survives and is retransmitted after an appropriate time interval. This is why CAN bus succeeds in real time prioritization for complex automotive, elevator and particle collider applications, and more.

Elevators and Lifts

Can Bus in Elevators

image

The low-cost and reliability of Can Bus is used in elevator technology, where safety is critical and cost-containment is an on-going concern.  Can Bus, due to its serial technology, allows you to significantly reduce the wire count in the traveling cable, machine room, and throughout the building. Less wiring and fewer terminations ease fire loading and troubleshooting.  Elevators that are used in commercial or multi-family occupancies must contend with large groups of people interacting with powerful machinery to lift them off the ground. Also, usage is spread around all times of the day, year round.

 

A case in point is elevator technology, which continues each decade to write the book on reliability and safety all the while with a view on initial and on-going cost containment. CAN Bus, because of its serial technology, makes possible significantly reduced wire count in the traveling cable, machine room and throughout the building. Fire loading and troubleshooting difficulties are eased with less wiring and fewer terminations. Phone-style connectors allow easy field expansion.

 

An essential element in elevators as used in commercial and multifamily occupancies is that humans in large numbers and often including children and disabled or infirm individuals are interacting with powerful machinery that lifts them off the ground. This happens day and night, year round, and in the fullness of time there is the potential for equipment failure and injury to the interacting individuals. This hazard is greatly mitigated by means of the reliability that is built into CAN Bus technology.

 

Think of all the things that could go wrong in elevators used in large high-rise buildings!  You could have many elevator cabs going in motion at the same time, traveling in opposite directions, either reducing speed as they prepare to stop at a floor or accelerating after making a complete stop, all the while doors are opening and closing as needed.

 

The elevator cab responds in a pre-programmed, prioritized manner to call buttons that are pressed on many different floors, as well as, buttons pressed inside the cab. The simple, yet highly effective system of message management within the Can Bus is what makes this all possible. Every node is connected to one another through a two-wire bus. Each node requires a (local) central processing unit to determine which messages get transmitted. These messages are received by sensors, actuators, and control devices that are connected to the CAN bus. The CAN controller stores the received bits that are sent from the bus until the message is complete and it is made available to the host processor.

 

Using CAN, all nodes are available to receive messages but this can not happen simultaneously.  Data transmission for Can bus attains content resolution through means of arbitration. Binary bits values are termed dominant and recessive bits with "0" being dominant and "1" being recessive. The dominant bit always overwrites the recessive bit. Each message, packet of data that is exchanged between the nodes, has a unique identification number.  Because the identification number is unique to all nodes within the network, when a transmitting node places data on the network, it checks the unique id to pass the message through the filter and the rest are ignored. Messages in CAN are sent in a format called frames, a defined structure that carries a meaningful sequence of bits or bytes of data within a network. A Standard CAN frame is 11 bit identifier field while an extended CAN frame has a 29 bit identifier field.

 

Arbitration is the means by which conflict is resolved when two or more nodes receive a message at the same time. Whenever a bus is free, any unit can transmit a message. .During arbitration every transmitter compares the value of transmitted bit with the bit value on the bus. If the bit value is same, the node continues to send the bits. But at any time, if the transmitted bit value is different from bus value, the dominant bit overwrites the recessive bits. The arbitration field of the CAN message consists of an 11- or 29-bit identifier and a remote transmission (RTR) bit. The identifier having lowest numerical value has the highest priority.  CAN bus therefore realizes real-time prioritization using a system of dominant (logic level 0) and recessive (logic level 1) messaging. Neither information nor time is lost using the process of arbitration.

 

When arbitration takes place, the lower priority message is not obliterated, as is the case in some other types of serial transmissions. The message survives and is retransmitted after an appropriate time interval. This is why CAN bus succeeds in real time prioritization for complex automotive, elevator and particle collider applications, and more.

Medical Technology

Can Bus in Medical Technology

 

Because medical devices have become more sophisticated, manufacturers are sourcing parts from third parties in order to reduce development costs and meet their time-to-market requirements.  Third parties use open standards to simplify third party integration and to substitute products with alternatives from another manufacturer.  One such technology that has been used by several manufacturers is the use of the serial Controller Area Network (CAN) bus system as an embedded network for real-time control.  For most medical devices, the CANopen device profiles define a device finite state automaton (FSA). An FSA specifies device states, corresponding internal and external device behaviour and the events that cause a certain state transition.image

 

So far, a device profile for X-ray collimators (CiA 412-2) has been developed jointly by GE Healthcare, Philips Medical Systems and Siemens Medical Solutions, under the CiA umbrella. The main task of an X-ray collimator is to limit the X-ray beam to a defined format. The device profile supports several functions for focusing the X-ray beam, such as rectangular or circular collimation. Furthermore, the specification makes it possible to support the use of filters for influencing the spectral characteristics of the X-ray beam. The visual simulation of the X-ray beam is functionally incorporated into this device profile too.

 

Philips Medical Systems has used CAN and CANopen as the command data communication technology in user interfaces, image detection, X-ray generation, X-ray collimation and the control of the mechanical moving parts of the X-ray system.  Dose measurement systems are another CANopen device profile. The dose measurement system is used to measure the X-ray dose, the dose area product, the entrance / skin dose and the corresponding dose rates in an X-ray machine. It also measures the irradiation time and factors that influence dose measurement, such as chamber temperature and air pressure. The CANopen device profile defines how the field values (actual measured values) are converted to the desired process values (desired measured value). Standards for a new class of device profiles for medical diagnostic add-on modules, such as contrast media injectors and Electro-Cardiograms (ECG), are being developed. The application profile for contrast media injectors covers devices used in angiography and those used with CT scanners. The profile also supports multi-piston injectors. The scanner or image-processing device always provides CANopen Manager functionality. The injector device functions as CANopen NMT slave device.

 

CANopen networks are now used in many medical and healthcare fields: in laboratory analysis equipment, for example. CANopen is also used in several automated Operating Rooms (OR) for endoscope surgery. Besides OR lighting, light projectors, cameras, insufflators (CO2) and HF scalpels have been equipped with CANopen interfaces. Device profiles for these have not yet been standardised, but CiA will do this when the market asks it to. Several manufacturers of patient beds for intensive care and OR tables are using CANopen as an embedded network to control various drives and human-machine interfaces. A standardized CANopen interface for beds that will facilitate communication with other intensive care devices as well as OR devices is under discussion.

 

 

 

 

{tabbedtable} Tab LabelTab Content
Aerospace and UAS

Can Bus in Aerospace and Unmanned Air Systems (UAS)


Until recently, CAN was primarily implemented with proprietary protocols in the aerospace field.  The acceptance of CAN technology by Airbus, an international pioneer in the aerospace industry, and Boeing has led to ARINC 825, a standard for Control Area Network bus protocol for airborne use to take off.  ARINC 825, a higher-level protocol for addressing  provides addressing mechanisms, communication mechanisms, profile descriptions, service structure, and more. It is also the basis o fa number of application specific protocols such as ARINC 810 and 812 which specify communication between modules in the galley with a focus on power management.  ARINC 826, a protocol for avionic data loading over a Controller Area Network bus, specifies Software Data Loading over CAN.image

 

Controllers that are connected to the CAN bus transmit data to the bus and receive data from the bus.  Data collisions on the bus are avoided by using the CSMA/AMP (Carrier Sense Multiple Access with Arbitration on Message Priority) technique. This is a means of prioritizing messages whereby a transmitter broadcasts a message to all CAN nodes whereupon a each node decides, based on the identifier received, whether to process the message or not. The identifier is also used to determine the priority the message is given to access the bus.  While there is no theoretical limit to the number of terminals that can be connected to the bus, it is normally limited to 32 to avoid data delay.

 

 

CAN bus in order to reduce the number of interconnecting wires from the control panel in the flight deck to system computers in the avionics compartment. The typical overhead panel may have 14 to 15 switches and indicators, with each switch having six wires, for a total of at least 90 wires running from the flight deck to the avionics compartment just for one control panel. By connecting all switches and indicators on a panel to a CAN bus controller, data is only transmitted with two wires.  Integrated Control Panels (ICP) connect to I/O modules using CAN data buses.  I/O modules transmit data to the Avionics Data Communication Netowrk using the highly reliable Avionics Full Duplex Ethernet Bus (AFDX) and it goes to computer LRUs to perform the intended action.  This approach reduces wiring, improves maintenance, and reduces unnecessary aircraft weight.

 

Implications for UAS

 

Thanks to the adoption of CAN by the aerospace industry for many years, the technology is finding its way into the UAS industry.  You can now transfer information from the flight controller to the ESC (Electronic Speed Controller) and back from the the ESC to the flight contorller via a serial bus. The flight controller can not only manage the throttle of the ESC, the ESC can report back to the flight controller (reporting the temperature, voltage, amperage, warning signals, etc. via live telemetry.  This provides safe monitoring of all proulsion equipment, allowing the pilot to monitor the full system for safe operation and can be customized through live-programming.

 

CAN significantly increases the reliability and information sent to the ground. Because the CAN bus protocol is PWM, its more immune to noise than the current method of throttle control used for the industry.  The digital CAN multiplex serial-bus control is currently being implemented in upcoming UAS to allow for direct motor control and live-telemetry feedback to the flight controller.

Building Automation

Canbus in Building Automation


Building automation involves using a control system to monitor and command the mechanical, lighting, security control, and fire alarm systems of a commercial building.  This smart network allows you to keep the building temperature within a specific range, control lighting, monitor system performance, and send out alarm signals to maintenance engineers and administrators should failure occur. Building automation systems include HVAC, lighting, electricity, hot water, fire, access, security/surveillance, vehicle parking , plumbing, lifts, and elevator.

 

Using CAN for lower layer networks has advantages over RS485 in the field of automation due to its multimaster architecture.  Compared to common bus networks such as Ethernet or networks based on network passing, CAN provides real-time features and ease of implementation at a lower cost.

 

Here is how implementation of a CAN node connected to Ethernet might look like in successful building automation:

  • Lighting Control
    • Motion/Occupancy Sensor - it easily identifies whether a particular room is occupied so that ambiance can be improved.
    • Timer controlling ambiance - After getting output from the sensor a timer is started, the ambiance of the room is improved, and a timer tracks how much time elapses until the ambiance should change
  • Fire prevention - this functionality is implemented by setting the fire alarms to go off as soon as there is fire detected using a heat sensor.
  • Security - Video and audio monitoring system are used because an operator is not available. A user can be notified through a system to the system or mobile, pager etc. Security cameras can also be used.
  • Smoke detection - a smoke alarm when smoke is detected. The valves (plates) are turned off to stop air entering in case of smoke alarm and exhaust is started.
  • Temperature control and Air conditioning - a temperature sensor is used to detect the temperature at any point in time and turn ventilation on and off, as well as, air conditioning system.

 

 

 

Do you have an idea for a project that uses the Arduino MKR Board and MKR Arduino CAN Shield?

 

You're Free to Repurpose an Existing Project or Propose something new!  We'll send out a board and shield for the best ideas so you can get started on your project!

 

The goal of this giveaway is to demonstrate the commercial uses of Arduino.

 

Directions:

Step 1:  Log in or register on element14, it's easy and free.

Step 2: Post in the comments section: Show Arduino How You would use the Arduino MKR Line.

 

Videos, pictures and text are all welcomed forms of submission.

 

Step 3: Post Your Project: After you receive your board and shield you'll have a month to post your project anywhere on the community using the MKR_giveaway_projects tag or post it in Arduino Projects !

 

You have until October 18th, 11:59AM (noon) CDT to enter.

Attachments:
imageAutoHacksBeyond_TermsandConditions.pdf
  • cia
  • scm
  • displays
  • pulse width
  • electronic control unit
  • wifi
  • abs
  • fsa
  • control devices
  • tcm
  • afdx
  • flexible-data rate
  • home automation
  • bcm
  • arduino mkr 1010
  • integrated control panels
  • arduino can shield
  • automobiles
  • body control module
  • UAS
  • control industrial automation
  • unmanned air systems
  • pwm
  • robotics
  • controller area network
  • timer controller ambiance
  • building automation
  • past_contest
  • canopen
  • arduino_projects
  • multi-master system
  • occupancy sensor
  • transmission control module
  • multi-domain communication
  • powertrain control module
  • pcm
  • motion sensor
  • pulse width modulation
  • can fd
  • message based protocol
  • mkr_auto_hacks
  • cyptoauthentication
  • industrial grade sensors
  • cc508 crypto authentication
  • samd21 cortex-m0+ 32bit low power arm mcu
  • bosch
  • arduino_mkr_giveaway
  • anti-lock breaking system
  • gps
  • avionics full duplex ethernet bus
  • finite state automaton
  • emu
  • suspension control module
  • mcp2515
  • iso 11898-2
  • ecu
  • drones
  • canbus
  • ccm
  • central control module
  • auto hacks
  • Share
  • History
  • More
  • Cancel
  • Sign in to reply

Top Comments

  • fmilburn
    fmilburn over 4 years ago +5
    I have to be careful not to overextend myself, and I am not really a car guy, but here is an idea for anyone who wants to make it their own. Set up a smart phone as a mobile hotspot. Connect MKR WIFI 1010…
  • dougw
    dougw over 4 years ago +5
    Congratulations to the kit winners! It will be interesting to see your projects.
  • station240
    station240 over 4 years ago in reply to dougw +5
    Already working on mine, can write some of the code without the hardware itself.
  • dixonselvan
    dixonselvan over 4 years ago

    Congratulation winner vimarsh_  and participants!

     

    karthickiot , skd , contactdy14 ,  station240 , vimarsh_ , and palliser

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • jomoenginer
    jomoenginer over 4 years ago in reply to vimarsh_

    Nice job vimarsh_.   Nice mix of Node-RED and MQTT.  

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • vimarsh_
    vimarsh_ over 4 years ago

    Thank you for selecting me as the winner.

    I thank this community and all the people who have contributed to the community as I learned a lot from it and got the help I needed in every way..

     

     

    Thank you.    

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • dougw
    dougw over 4 years ago

    Congratulations vimarsh_

    Interesting project.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • tariq.ahmad
    tariq.ahmad over 4 years ago in reply to jomoenginer

    Football is where I’m off to now.   Enjoy the game.   (Not a fan of either team and from St. Louis where we lost the Rams to LA)  Email me on Monday.   Tuesday is the earliest we will do an announcement.   I reached out to @topmembers for assistance with judging.  Smarter World was super competitive.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • jomoenginer
    jomoenginer over 4 years ago

    Oh, I see I got referenced for enabling BLE on the MKR 1010, so I appreciate that tariq.ahmad.  I had added the Relay board to the mix and created some interfaces for the board, but was a bit distracted by other activities.  I'll see about getting something posted this evening after that little Football game being aired today.

     

    Thanks

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • station240
    station240 over 4 years ago in reply to tariq.ahmad

    Still having problems with my CAN setup, I think the MKR hardware works, but without anything to talk to it it's hard to know 100%.

     

    The TI devboard I have now has a second CAN transceiver so it can talk to itself, it doesn't like that idea either.

    It's hard to figure out what is going wrong without suitable test gear, as I also found the step by step debugger upsets the timing too much.

     

    I can draw up a diagram of MKR 1010 + MKR can shield + 2x16 LCD and wiring, plus the code I have for it.

    Perhaps it would work for others.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • tariq.ahmad
    tariq.ahmad over 4 years ago in reply to vimarsh_

    Yeah,  been going through the comments and seems there is a lot of learning going on with the tech for these comments.  Also,  some unforeseen shipping issues.  In the end if we get great projects makes a lot of sense to extend sooner rather than later.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • vimarsh_
    vimarsh_ over 4 years ago

    Thank you very much for extending the deadline.

    The CAN problem of mine will be resolved, by then.

    otherwise, the whole project is complete!

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • station240
    station240 over 4 years ago

    MKR Wifi 1010 and CAN shield arrived in the mail today.

    Only gotten as far as unpacking, finding a suitable USB cable, and throwing the switch to enable the CANBUS termination resistors.

     

    Impressively small compared to my ATMEGA2560 and even the LCD screen I'll be using.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2023 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • Facebook
  • Twitter
  • linkedin
  • YouTube