Category: arduino/wiring

Posted on

MKR GSM 1400 Pre-flight Checklist

I’ve been getting to know the MKR GSM 1400 boards better the past few days, and in the process I’ve assembled a “pre-flight checklist” of things you’ll want to do first, in order to make sure everything is ready to go. It took a few errors and missteps to get here, so I’ll mention those along the way.

Make sure you have an antenna attached

I thought “I’ll be fine just to test, there’s good service in my city.” Wrong. Attach an antenna. You’ll need it to get a good signal even in a well-covered area. The GSM Antenna sold on the Arduino Store works well, though any GSM antenna with a SMA male connector should work.

Get a SIM card

I used Hologram.io, thanks to recommendations from the rest of the Arduino team and Don Coleman. Their Hologram Maker Edition service is affordable and easy to use. When you do set up an account, get a SIM card of course, and assign a phone number to it. That’s optional for their service, but needed if you want to send and receive SMS messages or phone calls.

You’ll also want to take note of the Device ID, APN info, and Device Key. You’ll need those later. When accessing GPRS services through the MKR 1400, the login is the Device ID and the password is the Device Key.

Download MKRGSM library

You can find this in the Arduino IDE’s LIbrary Manager. When you install it, you’ll get a new set of example sketches in the File Menu, Examples submenu called MKRGSM. You’ll need to have the right board chosen in the Tools menu (MKR 1400) in order for these examples to show up in the Examples submenu, though.

Run the TestModem Sketch

Click the File Menu, Examples submenu, MKRGSM submenu, Tools submenu to find the TestModem sketch. Upload this to your board and open the Serial Monitor. You should get the following output:

Starting modem test…

Then a slight delay, followed by:

modem.begin() succeeded
 Checking IMEI…Modem's IMEI: XXXXXXXXXXXXXXX
 Resetting modem…Modem is functoning properly

Your IMEI will be unique to your board, it’s the International Mobile Equipment Identifier. It’s written on the MKR1400, and encoded in the QR code there as well.

If you don’t get these messages, check that your SIM card is inserted properly, and that you’ve chosen the right board and serial port. Then upload the sketch again.

Run the BandManagement sketch

Click the File Menu, Examples submenu, MKRGSM submenu, Tools submenu to find the BandManagement sketch. Upload this to your board and open the Serial Monitor. You should get the following output:

Restarting modem…

Then a slight delay followed by:

Modem restarted.
 Current band:EGSM_DCS_MODE
 Want to change the band you’re on?
 Select band:
 1 : E-GSM(900)
 2 : DCS(1800)
 3 : PCS(1900)
 4 : E-GSM(900)+DCS(1800) ex: Europe
 5 : GSM(850)+PCS(1900) Ex: USA, South Am.
 6 : GSM(850)+E-GSM(900)+DCS(1800)+PCS(1900)

Choose the right band for your region of the world. If you pick the wrong region, the MKR1400 will never connect to a network. I puzzled over this for several minutes before I thought to check the band, as I was in the US and the board came from Europe. Type the correct number in the Serial Monitor’s input field, then hit enter. You should get:

Configuring band GSM850_PCS_MODE

Or whatever mode is appropriate to your region. Then after a few seconds:

Success

Run the ScanNetworks sketch

Click the File Menu, Examples submenu, MKRGSM submenu, Tools submenu to find the GsmScanNetworks sketch. If your SIM card requires a PIN, enter it in the arduino_secrets.h tab. Upload this to your board and open the Serial Monitor. You should get the following output:

GSM networks scanner

Then a longer delay followed by:

Modem IMEI: XXXXXXXXXXXXXXX
 Scanning available networks. May take some seconds.
 Current carrier: T-Mobile
 Signal Strength: 5 [0-31]
 Scanning available networks. May take some seconds.
 Current carrier: T-Mobile
 Signal Strength: 5 [0-31]
 Scanning available networks. May take some seconds.

This should be the first sketch that connects your MKR 1400 to the mobile network, so make sure you have an antenna attached. Your carrier name and signal strength will vary, of course. The scanning will run continually.

Once you see this, you know you’re on the mobile network. Now the fun begins.

Run the SendSMS sketch

Click the File Menu, Examples submenu, MKRGSM submenu, to find the SendSMS sketch. If your SIM card requires a PIN, enter it in the arduino_secrets.h tab. Upload this to your board and open the Serial Monitor. You should get the following output:

SMS Messages Sender

Then a delay followed by:

GSM initialized
 Enter a mobile number:

Type your mobile phone number into the Serial Monitor’s input field, including the country code. For example, a typical US number would be +15551212. Then type enter. You should get the following output:

+15551212
 Now, enter SMS content:

Type a message, something like this:

I like aardvarks and okapi, don't you too?

You should get the following output:

Message:
 I like aardvarks and okapi, don't you too?

COMPLETE!

Enter a mobile number:

You should get the text on your phone number too, of course. Note that the sending phone number may not be the one associated with your SIM. This will depend on your carrier. Send a few more until you’ve exhausted that fun.

Run the ReceiveSMS sketch

Click the File Menu, Examples submenu, MKRGSM submenu, to find the ReceiveSMS sketch. If your SIM card requires a PIN, enter it in the arduino_secrets.h tab. Upload this to your board and open the Serial Monitor. You should get the following output:

SMS Messages Receiver

Then a delay followed by:

GSM initialized
 Waiting for messages

Send a text message from your mobile phone to the number associated with your SIM card. You should get the following output:

Message received from:
 +15551212
 Oh, and llamas and bonobos are quite nice too.
 END OF MESSAGE
 MESSAGE DELETED

Now you know you’re successfully sending and receiving messages from the mobile network. Finally, test GPRS connectivity:

Run the GsmSSLWebClient sketch

Click the File Menu, Examples submenu, MKRGSM submenu, to find the GsmSSLWebClient sketch. Click the arduino_secrets.h tab and enter your APN info, login, and password. From Hologram.io, you hologram for the APN, use the Device ID as login and generate a Device Key as password. Hologram SIMs do not require a PIN. Check with your mobile provider for details on your own SIM. Upload this to your board and open the Serial Monitor. You should get the following output:

Starting Arduino web client.

Then a longer delay followed by:

connecting…
 connected
 HTTP/1.1 200 OK
 Server: nginx
 Date: Tue, 19 Mar 2019 13:48:40 GMT
 Content-Type: text/plain
 Content-Length: 2263
 Last-Modified: Wed, 02 Oct 2013 13:46:47 GMT
 Connection: close
 Vary: Accept-Encoding
 ETag: "524c23c7-8d7"
 Accept-Ranges: bytes
        `:;;;,`                      .:;;:.                .;;;;;;;;;;;`                :;;;;;;;;;;:     TM    `;;;;;;;;;;;;;;;`            :;;;;;;;;;;;;;;;        :;;;;;;;;;;;;;;;;;;         `;;;;;;;;;;;;;;;;;;      ;;;;;;;;;;;;;;;;;;;;;       .;;;;;;;;;;;;;;;;;;;;    
 ;;;;;;;;:;;;;;;;;;     ,;;;;;;;;..;;;;;;;;      .;;;;;;,         :;;;;;;;   .;;;;;;;          ;;;;;;;     ;;;;;;             ;;;;;;;  ;;;;;;,            ;;;;;;.   ,;;;;;               ;;;;;;.;;;;;;              ;;;;;; 
  ;;;;;.                ;;;;;;;;;;;```       ;;;;;
  ;;;;;                  ;;;;;;;;;,       ;;;       .;;;;;
 ;;;;:;;;;;;;;        ;;;        ;;;;;
 ,;;;;,,,,,,,,      ;;;;;;;      .,,;;;,,,     ;;;;;
 :;;;;.;;;;;;;;       ;;;;;,      :;;;;;;;;     ;;;;; :;;;;    .;;;;;;;;      ;;;;;;      :;;;;;;;;     ;;;;; .;;;;.                   ;;;;;;;.        ;;;        ;;;;;  ;;;;;                  ;;;;;;;;;        ;;;        ;;;;;  ;;;;;                 .;;;;;;;;;;       ;;;       ;;;;;,  ;;;;;;;;;;;;;;;;;;                ;;;;; 
  ;;;;;,             .;;;;;; ;;;;;;;              ;;;;;;    ;;;;;;:           :;;;;;;.  ;;;;;;;            ;;;;;;      ;;;;;;;       .;;;;;;;,    ;;;;;;;;        ;;;;;;;:  
     ;;;;;;;;;:,:;;;;;;;;;:      ;;;;;;;;;;:,;;;;;;;;;;   
     ;;;;;;;;;;;;;;;;;;;.        ;;;;;;;;;;;;;;;;;;;;           ;;;;;;;;;;;;;;;;;           :;;;;;;;;;;;;;;;;:             ,;;;;;;;;;;;;;,              ;;;;;;;;;;;;;;                 .;;;;;;;;;                  ,;;;;;;;;:         
 ;;;   ;;;;;`  ;;;;:  .;;  ;; ,;;;;;, ;;. `;,  ;;;;    ;;;   ;;:;;;  ;;;;;; .;;  ;; ,;;;;;: ;;; `;, ;;;:;;  
 ,;:;   ;;  ;;  ;;  ;; .;;  ;;   ,;,   ;;;,;, ;;  ;;      ;; ;:  ;;  ;;  ;;  ;; .;;  ;;   ,;,   ;;;;;, ;;  ;;. 
    ;: ;;  ;;;;;:  ;;  ;; .;;  ;;   ,;,   ;;;;;, ;;  ;; 
   ,;;;;;  ;;;;   ;;  ;; .;;  ;;   ,;,   ;; ;;;, ;;  ;;     ;;  ,;, ;; .;;  ;;;;;:  ;;;;;: ,;;;;;: ;;  ;;, ;;;;;;     ;;   ;; ;;  ;; ;;;;.   `;;;:  ,;;;;;, ;;  ;;,  ;;;;   
 disconnecting.

That text will appear as the ASCII-encoded Arduino logo in your Serial Monitor. Now you know you’ve got GPRS working, and should have enough functionality to proceed with your own sketches.

The MKRGSM library is based on similar principles as the WiFi101 and WiFiNINA libraries. Once you connect to the network, you use a variety of classes to do your business. The SMS class functions a bit like the Serial class, in that it’s based on the Stream class, so you can do things like see how many bytes are available(), you can read() and write(), and so forth. The GSMClient and GSMSSLClient classes function just like the TCP client classes in the WiFi libraries. Check the MKRGSM library documentation for more detail.

Posted on

What is “Real-Time”, Anyway?

Recently, a colleague of mine was working on a project with an Arduino Yún that involved reading a lot of sensor data using the Yún’s Arduino processor and writing it to the microSD card via the board’s Linux processor to be served to other devices via HTTP. She found that it took anywhere from 20 milliseconds  to several seconds to get the data from the sensors written to the SD card. “Why is it not real-time?” she asked me.

Welcome to the world of embedded operating systems. They are not realtime. “Realtime” can mean many things. In automotive systems, for example, your car’s braking system had better react in “realtime” or you’re dead. That might mean only a couple of milliseconds. When measuring high-speed rotation, it might even mean microseconds.

My colleague was measuring her function’s response time in tens to hundreds of milliseconds. That function read one controller’s analog input pin, sent the result via asynchronous serial to another controller, and then stored the result on an SD card. I haven’t measured it, but I’d wager you’ll see the same response times on a BeagleBone or Raspberry Pi, or any embedded Linux board.  Here’s why:

All computers run programs. In a microcontroller like the Arduino, there’s only one program running. That program is made up of instructions stored in memory, in a particular order. The computer moves through those instructions one at a time. Sometimes it jumps around in the

At the electrical level, all computers are made up of transistors, so in computing, the fastest version of “realtime” means “how fast can you read and act on a changing voltage on a transistor?” Some of the input/output pins of a microcontroller are usually hardware interrupt pins, meaning that they can be programmed such that if there’s a change on that pin, the program running on the controller is immediately interrupted and a special function is run. This function, called an interrupt service routine or ISR, is typically very short. Normally an ISR simply stores the result of the interrupt in a variable. Then the processor returns to the main program.  

Operating systems, both on small boards like this and on servers and personal computers, do not guarantee a minimum response time to physical I/O. They are written to optimize processor sharing between programs, so the scheduler, a core part of the operating system, doles out processor time to each program. Even before the programs you run get time, there are OS tasks that take time.  Disk writing is one of the most time-intensive tasks. Perhaps the only longer task is a network transaction, because the data is going through many computers, each with its own operating system.

In systems that have to have real-time response, you typically use one of two options:

1) no operating system. Your processor runs one program only. Like Arduino

2) a “realtime operating system” or RTOS. RTOSes are stripped-down operating systems that leave many core functions out. As of yet, all RTOSes are custom packages, not very user friendly, though there has been some work lately on realtime linux. I haven’t seen one running on any of the hobbyist boards, but i wouldn’t be surprised if we don’t see one in the next year or so.

When we designed the Yun, we decided we’d give users the benefits of both real-time and an operating system. What you do on the 32U4 (the Arduino processor) is real-time because there is no operating system. What you do on the linino side is not, because it’s running linux, an operating system. The typical approach to a networked project (whether a Yun or other system) is to do all the real-time operations on a non-OS micro controller, then send the results to an operating system computer in non-real-time, after the action has happened.

Here’s a use case that illustrates the use of real-time and an operating system together:

Let’s say you’re using a rotary encoder to measure the speed of a wheel on a remote control vehicle. You want to display the speed on a dashboard screen that’s networked to the vehicle over Wifi.

Rotary encoders measure rotation by counting pulses generated by a rotating shaft. When the rotation is fast, the pulses happen VERY fast, and you need real-time to catch them. On a micro controller, this is typically sensed using hardware interrupts. These are sub-circuits of the micro controller that can interrupt the program flow when a change happens on a given I/O pin. They force the program to jump to a function to handle the interrupt. You usually want that function to be very short — typically all it does it to increment or decrement a variable counting the changes. The Arduino Uno has two hardware interrupts, and Paul Stoffregen’s encoder library allows you to use them for reading encoders.

The way you’d build this app is to have the rotary encoder attached to the hardware interrupts of a micro controller. This controller is your physical I/O controller. You’d write a program for the micro controller that calculates the speed based on the pulse rate and sends that serially to another controller connected to a display. One function counts the pulses. That’d be done by the function called by the interrupt (these are called Interrupt service routines, or ISRs). Another function calculates a running speed based on the changing count. A third function might control the movement of the vehicle’s steering based on the value. A fourth function sends the calculated value over a serial connection to the display computer.

The serial connection of the physical controller be connected to a networked modem like the Wifi shield or a Bluetooth radio, but that modem is just another single-function controller. That transmission takes time, and you don’t want to take processor time away from counting the pulses, so your physical I/O controller doesn’t handle this transmission, it only counts pulses and sends the value on. The radio controller handles the network connection. It transmits the data on to a display computer or a server. That server is typically running an operating system, and not working in real time, but that’s okay, because humans aren’t going to react in more than a half-second or so most of the time.   What you see onscreen is typically a report of the sensor readings, but it’s an average or aggregated reading, not the raw, realtime reading.  The delay depends on the transmission time of the data. Perhaps you have a virtual steering wheel onscreen that then directs the card, but this is not real-time either. The user gets to steer the car, but what she’s really doing is affecting the gross movement of the steering, not the fine control over the axle. She’s changing the overall balance, but the physical I/o controller is the only part acting in real-time to the sensors.

It is possible for a controller that’s running an operating system to have hardware interrupts, and for it to have interrupt service routines. But those are typically part of the operating system kernel, not part of the user programs. You have to write custom kernel routines and restart the OS in order to use them. So unless you’re a kernel programmer, you typically won’t use these on BeagleBone, Raspberry Pi, or Arduino Yun. This is why there are many projects that combine the Pi or the Bone with an Arduino or other non-OS controller to do real-time sensing, and it’s why the Yun has a separate processor for that as well.

A typical personal computer is made up of several controllers, in fact. There’s normally a CPU, a network controller, a controller inside any disk drive (if it’s a drive with a motor), a graphics processor, a hardware bus controller, and more. These are usually tied together with synchronous serial communication like SPI or I2C or some other means of communication. The dedicated controllers handle their subsystems in realtime, and report back to the CPU, which reports in user time (not real time).

Posted on

Using REST as a command protocol for web-to-serial applications

Updated 19 Jan 2014

The address you type into your browser’s address bar is often the location of a particular document on a server. For example, http://tigoe.net/index.html refers to an HTML document living in the main directory of my server, tigoe.net. But URLs can be used to represent more than a file address. They can also be used to set or get the state of web-based application. For example, http://www.mystore.com/item/3045/price could be used to tell the application you want the price of item 3045. If you want the set the price, you could use http://www.mystore.com/item/3045/price/4.99. Web frameworks like Sinatra (for Ruby), Flask (for Python) and Express (for JavaScript through node.js) make it possible for you to build a web server that uses Representational State Transfer, or REST, as the control protocol for your application.

REST is a style of formatting URLs such that the URL itself describes the state of the thing it’s addressing. In the store example above, the URL is a representation of the item in the store (http://www.mystore.com/item/3045/price).  To change the state of the item, you use another URL to represent that change (http://www.mystore.com/item/3045/price/4.99).  At its simplest, REST means organizing your web application so that the URLs provide clear, sensible meaning as to what’s going on. For a more detailed explanation, see Understanding REST or Building Web Services the REST way. In this post, you’ll learn how to use a RESTian scheme as a communications protocol between a microcontroller and a web page using node.js and a little client-side JavaScript in the middle.

Continue reading “Using REST as a command protocol for web-to-serial applications”

Posted on

Serial to JSON in Node.js and Arduino

Node.js is great for making web services, and node-serialport makes it very easy to connect to serial devices on your computer. In my last post, I showed how to connect an Arduino microcontroller application to a web page using Node.  This post expands on that, introducing how to use JavaScript Object Notation (JSON) from Arduino all the way through to your HTML page.

The beauty of node is that it’s JavaScript, so you get to use everything Javacript gives you, including its wonderful lightweight data format, JSON, or JavaScript Object Notation. JSON describes data objects using arrays of key-value pairs separated by colons. If you want to add more properties to an object, just add another array element. the value of an element can be a JSON object itself. When you’ve got an application that uses JavaScript on the server side and on the client side, it makes sense to use JSON to describe your data all the way through, so you can just pass it around without a lot of conversion.

Arduino doesn’t speak JSON natively. There are a couple JSON parser libraries out there for Arduino, but I haven’t seen one that I like yet. All of the ones I’ve seen expect more pointer knowledge from the user than I’d like.  So for this example you’ll assemble your own JSON string using Arduino’s String class, and letting node.js turn it into a JSON object.

To make this happen you’ll need:

This post assumes you understand:

  • How to use Arduino, including how to send serial data
  • How to write a web page, and what a server is
  • A little about JavaScript
  • A little about the command line
  • Beginning experience with node.js.  For my brief intro, see this post.

Continue reading “Serial to JSON in Node.js and Arduino”

Posted on

STP16C596 Shift Register

This tutorial will show how to control multiple LED outputs from a microcontroller using an STP16C596 shift register. The STP16C596 is similar to the popular 74HC595 shift register, but it’s nicer because it can sink a constant current to the LEDs it’s driving. It works slightly differently, however, so this code won’t work exactly for the ‘595.

This is a stub. More explanation will follow, but for now, here are schematics and code for Arduino.

Parts you’ll need:

  • STP16C596 shift register
  • Arduino microcontroller
  • LEDs
  • 1-kilohm resistor

Continue reading “STP16C596 Shift Register”

Posted on

A Tale of Two (three) Pongs

Created 2 April 2009, updated 1 Nov 2020

When I start learning a new  platform, I have a simple rule: If you don’t know what to do with it, make pong. What I love about pong is that it’s a simple rule set, easy to understand, and implementable on just about anything with a pixel display.  You can generally implement it in a day or less on any platform. And it’s a great example of engaging interaction.  People understand what’s going on right away, and, when implemented well, it’s just challenging enough to keep you engaged for several minutes at least.  That’s good interaction, to me.

I’m a big believer in starting with the application rather than the platform.  I think you do better work when the tools serve the need rather than the other way around.  But sometimes you get stuck with the assignment to learn a particular platform or tool, and you have to make up a project on the spot.  When that happens, make pong.

As an example of this, I built pong for two platforms yesterday [1 April 2009]: an Arduino Mega with 2 8×8 LED matrices (based on my earlier post), and Processing.  Since Arduino’s programming syntax was based closely on Processing’s, I figured it should be possible to port the code from one to the other pretty quickly. It took about ten minutes to go from Arduino to Processing.  In 2020, I updated this exercise to write the program in p5.js as well. Following, I’ll describe the thought process of putting the game together for all three, as a hopeful aid to beginning programmers.

Continue reading “A Tale of Two (three) Pongs”
Posted on

8×8 LED matrix control on an Arduino Mega

Created 31 March 2009, edited 1 Nov 2020

Once you’ve mastered microcontroller programming, you might be tempted to control a lot of LEDs.  Lots of people have this desire once they master the basics. Many microcontrollers have a limited number of output pins, however, so you might think that limits how many LEDs you can control.  I’ve written about a few different methods around this before in chapter 14 of Physical Computing and in this blog.

By matrixing your LEDs, you can control many more than the number of pins you have.  For example, with the Arduino Uno and earlier models, you had up to 20 digital outputs (13 labeled digital I/O 0 through 13, plus the six analog outputs, which double as digital I/O 14 through 19).  With 16 of those, you can control an 8×8 matrix of LEDs.  That’s 64 LEDs.  With the Arduino Mega, you have 54 digital I/O pins, so you can control a lot more.  This example uses 32 of them to control 2 8×8 matrices, for a total of 128 LEDs from one controller.

To make this example, you’ll need:

  • Arduino Mega
  • Breadboard or prototyping shield. 
  • 8×8 LED matrix.  I got mine in a surplus shop in China, but you can also get them from most electronics retailers
  • male pin headers
  • female pin headers
  • Wires

Step 1: Figure out the LED Matrix pins

Continue reading “8×8 LED matrix control on an Arduino Mega”
Posted on

RFID to Web Interface

This tutorial introduces a Processing interface sketch provides a GUI for the command-line interface written into the Arduino RFID example. You should read that tutorial first. The sketch shown here also allows you to upload tags it reads to O’Reilly’s Emerging Technology Conference attendee portal, and retrieves the resulting profile. The API for this was written by Edd Dumbill. The Processing sketch retrieves RFID tags from the Arduino reader serially, then  passes the tag via a HTTP request to a PHP script on a remote server, shown below,  that adds an authorized login to the O’Reilly site.

Caveat: this tutorial was written specifically for the RFID workshop at Etech 2009.  If you’re doing this on your own, the uploader won’t work because your tags won’t be associated with records in the O’Reilly database, and the PHP script that it calls probably won’t be active on my site anymore.  But you could build your own version on your own server. The PHP code that follows below gives you a start on that process, and the Processing code below can make a HTTP call to any web address you give it.

The entire sketch can be downloaded here:

rfid_uploader_0002

Continue reading “RFID to Web Interface”

Posted on

Arduino-based RFID reader

This tutorial shows how to make an Arduino-based RFID reader that reads Mifare tags and stores them in EEPROM. It is a modification of Alex Zivanovic‘s code on Tinker.it. Thanks to Alex and Massimo Banzi for the reference. Once you’ve got it running, go on to the RFID to Web example, which provides a Processing interface sketch provides a GUI for the command-line interface written into the Arduino code.

The entire sketch can be downloaded here:

arduino_rfid_reader_0001

Continue reading “Arduino-based RFID reader”