Your engineers are not experts in RF so you buy a proprietary wireless mesh network module.  It costs significantly more than the entire sensor but it’s got to be worth it.  Right?

You need a microprocessor to read and process the sensor data for transmission.  The radio module has a microprocessor but you aren’t allowed to access it because it’s “vendor-locked” so you purchase an additional single board computer to run your code.

The mesh radio module doesn’t have power so it requires an external power source.  The power used by the RF module FAR exceeds any power estimates you had for your sensor.  You also have to power the single board computer you just added.

Now you will need to create a rechargeable battery circuit.  In order to know how many batteries you will need, to meet your battery-life requirements, you will need to perform detailed tests on the power usage of the new system.

We are ready for the enclosure.  You will need to get all these things to fit inside a small light-weight container that meets your customer’s size requirements which just seem impossible at this point.

You’re exhausted and running out of time so you spend a fortune manufacturing a custom enclosure. The sensor “system” is finally done.

Let’s say the wireless mesh network isn’t performing as advertised or you find a cheaper product.  If you change it then you will have to change everything.  You’re stuck.

Your sophisticated sensor is now a complex, awkward, expensive, power hungry system that can never be modified.  How did you even get here?

Radio module manufactures are extremely secretive and refuse to share any information they deem proprietary.  They purposefully create black box modules that remain shrouded in mystery.  This design creates redundancy and ultimately increases the cost, size, weight and power-usage of any system in which it is integrated. If engineers were allowed to use their microprocessor then the entire system would immediately shrink in power, size and cost.

What radio manufactures don’t want you to know is that wireless mesh technologies have been around for years and include many open source routing protocols.  “The Better Approach To Mobile Ad-hoc Networking” (B.A.T.M.A.N.) is an example of an open-source routing protocol for multi-hop wireless mesh networks.  My company, TELEGRID, has even stopped developing a proprietary wireless mesh routing protocol due to the remarkable performance of B.A.T.M.A.N.  Our uMesh wireless network allows system manufacturers to select specific components they need and MOST IMPORTANTLY write code on the same microprocessor as the wireless mesh network.

System manufacturers need to break-free from the wireless mesh network black-box conspiracy.  It is the only way to cut costs and size so that mesh-networked devices can finally permeate the marketplace and the world.

Want more information on how to add wireless mesh networking to your product just call me at 973-994-4440 and ask for Beth!

The post THE B-HIVE: Why Can’t System Developers Use the Wireless Mesh Network Processor? appeared first on TELEGRID.

In ROS a process is called a node and every node is responsible for one task. Nodes communicate with each other using messages passed through logical channels known as topics. Nodes can send or receive data from another node using by publishing or subscribing to a topic.Nodes and topics. Image adapted from a tutorial from Justin Huang.

In order to start learning ROS you will need a robot.  For beginners, the best place to start is with a good affordable robot called the Turtlebot.  Turtlebot is the most affordable advanced ROS robot on the market.   It uses off-the-shelf consumer electronics like the Orbbec Astra Pro sensor, a standard netbook and a robot base built from a repurposed robot vacuum cleaner to keep costs low.

TurtleBot is a low-cost, personal robot kit with open-source software.  Turtlebot was designed in collaboration with the original makers of ROS, Willow Garage in 2010 and has since become the go-to software platform for roboticists around the world.

A TurtleBot allows you to build a custom robot that can drive around as well as see in 3D.  You can create amazing applications and learn more about ROS.  As an entry level mobile robotics platform, TurtleBot has many of the same capabilities of the company’s larger robotics p

latforms, like PR2.

Still want to learn ROS without buying a robot?  Easy – robot simulation.  A robotics simulator is used to create applications for a physical robot without depending on the actual machine which saves time and money. In most cases these applications can be transferred onto the physical robot without modifications.

The Open Source Robotics Foundation (OSRF) provides a free and open source robot simulator called Gazebo.  Gazebo

is an open source robot simulation application.  Used by both hobbyists an

d professionals alike, one can build models that act like real robots and move in their own world, ruled by its four, state of the art, physics engines the default being ODE Open Dynamics Engine.

The ROS Foundation provides a free Turtlebot Simulator which allows you to learn ROS and write code that can be moved to a real Turtlebot robot.  You can be up and running in 15 minutes!

To learn more check out these links:

www.ros.org 

gazebosim.org/

www.turtlebot.com

wiki.ros.org/turtlebot_gazebo

B

The post Getting Started with the Robot Operating System (ROS) appeared first on TELEGRID.

What we didn’t know then was that those kids were on the forefront of wireless communications which will become so important in the future.  They were communicating far and wide before cell phones were even a dream.

Ham radios communicate on a variety of radio frequencies that are allocated by the FCC for amateur use.  No License is required to purchase the equipment or to receive (listen), however, an FCC License is required to transmit on Amateur Radio frequencies in the USA.

Ham radios may operate from just above the AM broadcast band (1605 to 1705 kHz) to the microwave region in the GHz range with many ham bands found above the AM band to just above the citizens band (27 MHz). These bands are often referred to as short-wave bands which “bounce” off the ionosphere from the transmitter to the receiver’s antenna. The higher the frequency the “shorter” the wavelength.  This is different than FM radio and TV stations which use line-of-sight frequencies and are limited to 40 or 50 miles.

As a kid, I asked my Dad what it would take to get started in amateur radio and his response, money.

The equipment or “gear” for ham radio is expensive.  Radio components such as modulators, demodulators and tuners are traditionally implemented in hardware components which are expensive.

All that changed with the advent of modern computing and analog to digital converters which allowed most of these traditionally hardware-based components to be implemented in software.  This led to the creation of  what is now known as Software Defined Radio (SDR) which enables easy signal processing and the production of inexpensive wideband scanner radios.

The introduction of SDR was originally limited mostly to military organizations but SDR was transformed with the introduction of the RTL-SDR (www.rtl-sdr.com), a $25 SDR USB dongle.

The RTL-SDR operates in the 500 kHz – 1766 MHz frequency range and connects to a PC or laptop via USB.  The open source software application SDR# can be used to display the measurable frequency spectrum and even demodulate FM radio so you can hear music.

Other inexpensive SDR followed including the HackRF (https://greatscottgadgets.com/hackrf/) which can operate up to 6GHz.  It is considerably more expensive at $300 but higher frequencies require more expensive components.

Now anyone on a budget, including hobbyists (like me) can access the radio spectrum. This type of scanner capability would have cost hundreds or even thousands of dollars just a few years ago.

So what can you do with SDR?  This list is just few ideas from the rtl-sdr blog:

So what is TELEGRID doing with them? We are creating exciting solutions for the US Military using this technology.  We just and can’t talk about it here.  If you want more information or have a new, exciting idea that requires a custom RF solution, please give us a call at 973 994-4440 – we love to talk about RF!

Want to learn more.  Click on the following links:

http://www.arrl.org/clubs

https://www.rtl-sdr.com

https://greatscottgadgets.com/hackrf/

https://electronics.howstuffworks.com/ham-radio2.htm

B

The post THE B-HIVE: Cheap Software Defined Radio (SDR) Changes Everything! appeared first on TELEGRID.

I thought so too until I watched a 2014 video of Charlie Miller and Chris Valasek forcing a Jeep Cherokee to go off the highway into a ditch at full speed.  What’s the big deal?  THEY WEREN’T IN THE CAR!  They were driving behind the Jeep and were able to control it remotely. Scary.

How did they do it?  First, they hacked into the vehicle through an unsecure Wi-Fi connection – easy, unfortunately.

But how did they control the car?  By hacking the vehicle control network – the CAN Bus.

As cars became more advanced and offered more features the need for a common communication protocol emerged.   In 1983, a team at Bosch started developing the Controller Area Network (CAN) Bus to solve this complex problem.  New features including airbags, power steering, acceleration, braking, cruise control, audio components, power windows & doors now had a standard way to communicate with each other.  These components connect directly to the CAN Bus through Electronic Control Units (ECUs) which primarily consist of microprocessors and sensors.  In simplest terms, the CAN bus is a network where any system in the car can send and receive commands, kind of like an electronic command center.

The original CAN Bus was designed at a time when the thought of hacking vehicle software or any software was a far-off thought.  It was so incredibly difficult to even write custom embedded code that the idea of someone hacking it was just crazy.  Well, here we are at crazy.

The implementation of the CAN bus also allowed car manufacturers to move forward with the On-Board Diagnostics (OBD) protocol standard currently OBD-II. OBD-II offers a set of problem codes that can be easily interpreted by mechanics when trying to diagnose a problem. You can find the typeical OBD port under the steering column.

All you need to buy is a CAN bus module – here’s one from Sparkfun.com (https://www.sparkfun.com/products/13262).

Hook it up to your car’s OBD connector and a laptop and you can see all the information being transmitted on your cars CAN bus.  Cool right?  But wait – Did it ask you to login?

Nope … and that’s where our problem begins.

The CAN Bus has no security measures, period.  Messages are transmitted on the bus with only unique identifiers.  The lower the numerical value of the ID, the higher the message priority.  The problem is that there is no origination or destination indication transmitted with the message.  In a world of TCP/IP the idea that a message can be transmitted without knowing the sender is nuts!  This allows ANYONE to transmit messages on the bus with any ID at any time.

Lack of security leaves the CAN Bus susceptible to many different attack scenarios.  The easiest attack is a brute force attack where a hacker simply has to transmit high priority messages on the bus at such a high rate that the other messages can’t get through.  This will eventually immobilize the car and the driver.

The real danger, however,  is when a sophisticated hacker deciphers valid CAN Bus messages and is able to retransmit them at will which allows a hacker to gain control of the vehicle.  (This is also how self-driving cars work – but we will talk about that another time).

So what are we to do?  Many ideas have come up about how to implement security.  One method calls for adding authentication or encryption to the bus.  The issue with these types of methods is that they can introduce latency on the bus which will affect vehicle performance.  These methods also call for a network connection to a remote Certificate Authority (CA) and a central powerful processor which do not exist today.  These solutions probably will not happen without a complete vehicle network redesign which is a big deal.

Other methods include using Artificial Intelligence (AI) to identify “normal” CAN Bus behavior and then perform anomaly detection.  Again, this is a good method but requires a great deal of training to produce a behavioral model.  That means countless hours driving different “control” vehicles with different drivers in order to produce unique patterns.

My team at TELEGRID has a different approach that can identify a CAN Bus attacker without affecting the vehicle performance or long training periods.  We are currently working on this solution for US military vehicles and can’t discuss it here so give us a call (973.994.4440) for more information.

Apparently one sure security method available today involves ensuring that the external Wi-Fi connections to the vehicle are secure.  After the initial Jeep hack, Chrysler secured the Wi-Fi connection that made the hack possible and issued a recall for all at-risk vehicles.  Problem solved?  Well, no, because a few years later Charlie and Chris were again able to hack into a Jeep vehicle even after the recall through a different open connection.  Sigh.

In the meantime, all we can do is hope that car manufacturers will put as much emphasis on vehicle security as they do on heated and cooled seats.

Want to learn more?  Check out these links:

http://illmatics.com/carhacking.html

https://www.wired.com/2016/08/jeep-hackers-return-high-speed-steering-acceleration-hacks/

https://medium.freecodecamp.org/hacking-cars-a-guide-tutorial-on-how-to-hack-a-car-5eafcfbbb7ec

Thank you to the TELEGRID team for spending countless hours in the car listening to my country music and to Charlie Miller and Chris Valasek – not all super heroes wear capes.

Thanks for reading and that’s the buzz from the B-hive.

B

The post THE B-HIVE: Hacking the CAN Bus appeared first on TELEGRID.

As an embedded software developer I can go on and on about the many benefits of LINUX.  I can easily list hundreds of benefits.  What I believe is the greatest though is the LINUX repository.

The LINUX repository is an online archive of open source and proprietary software packages that programmers use for development or maintenance.  There is a repository for every LINUX distribution with compiled packages for a multitude of hardware configurations.  Software developers can create upgrades or security patches and upload them to the LINUX repository where they can be easily downloaded by users.

Click to Subscribe

Unfortunately, new security risks are forcing system administrators to limit connectivity between secure networks and the internet.   You can’t be hacked if a hacker can’t get in. While a closed network is ideal for security, it is a big problem for software maintenance.

Since the LINUX repository is online, the software upgrades are inaccessible on a secure network.  For years defense contractors, like TELEGRID, have had to go to great lengths to deploy software upgrades on secure networks.  This leads to delays in the deployment of security patches and seemingly endless upgrade cycles.

To resolve these issues we recommend replicating the LINUX repository inside secure networks with an offline LINUX repository.  But how do we update the LINUX repository if it is offline? One solution is to deploy a cross domain solution that straddles the secure and unsecure networks.  Another solution is compressing repository updates and sending them to a system administrator who can upload them into the offline LINUX repository.

While secure networks are important we must not forget that the main goal is functional, bug-free and secure code.  An offline LINUX repository will make it easier to maintain code on secure networks and apply needed security patches.  It seems the President agrees.

Beth Flippo is Vice President of Embedded Software at TELEGRID.  TELEGRID has unique expertise in secure embedded systems, secure authentication, PKI, and Multi-Factor Authentication (MFA).

Click to Subscribe

Disclaimer: The opinions expressed here do not represent those of TELEGRID Technologies, Inc.  The Company will not be held liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use.  All information is provided on an as-is basis.

The post Does President Trump Want an Offline LINUX Repository? appeared first on TELEGRID.