SAMD21 LoRa development board with GPS

LoRaWAN_node_top

Michael Krumpus designed and built a SAMD21 development board with LoRa radio module and GPS receiver, that is available on GitHub:

I’ve been doing some LoRa projects lately in order to learn as much as I can about this exciting new radio technology (see this LoRa mesh networking project and this LoRa weather station). ATmega328-based Moteino modules work great for a lot of projects, but I wanted a LoRa node with more processing power, more memory, and an onboard GPS receiver. The ATmega328 is just too constrained with memory — I’ve outgrown it. I really wanted a LoRa board with an ARM Cortex microcontroller like the SAMD21. This is the microcontroller used on the Arduino Zero. So, my ideal board is a SAMD21 with LoRa radio module and GPS receiver, all programmable with the Arduino IDE.
But, where is such a board? I could not find one so I decided to design and make one myself.

More details on Project Lab.

ESP32 (27) – GPS

In today’s post I’ll show you how to interface the esp32 chip to a GPS receiver to receive the actual position, speed and more…

GPS receiver

On the Internet and in electronic stores you can find different GPS receivers… thanks to the spread of navigators, smartphones and multicopters you can now buy one for few euros. For this tutorial, I used a GPS receiver sold by Banggood and based on the u-blox NEO-M8 chip:

gps-010 gps-011

Almost all the GPS receivers offer a serial interface, you can therefore connect them to an esp32 chip using one of its UART controllers, as I explained in a previous article. Sometimes it’s not easy to identify the various pins and it may be necessary – as in my case – to open the plastic case that contains the chip to read the PCB silk screen:

gps-001 gps-002

From the photos above you can understand the pinout of my receiver:

  • GND (ground) -> black cable
  • VCC (power supply) -> red cable
  • TXD (transmit) -> green  cable
  • RXD (receive) -> yellow cable

I decided to use the UART1 controller of my esp32 chip, with pins 4 (TX) and 16 (RX). I therefore connected all the cables, paying attention to connect the TX pin of the receiver to the RX pin of the chip and viceversa:

gps-003

NMEA

GPS receivers send data following the NMEA 0183 standard (often called just NMEA).

NMEA is based on strings (sentences) composed by a maximum of 80 characters with an ending CRLF. Each string has the following format:

$PREFIX,data1,data2 ... dataN-1,datoN*CHECKSUM

The prefix (5 chars) defines the type of device (for GPS receiver is GP) and the type of sentence (the following 3 chars). Each sentence includes a checksum (XOR) that allows the receiver to validate the data received.

The NMEA standard defines many types of sentences and each manufacturer can add proprietary types to communicate specific data. A complete list of NMEA sentences is available at this website. Let’s analyze one GGA (Global Positioning System Fix Data) sentence:

$GPGGA,183619,3877.038,N,07702.110,W,1,08,0.9,545.4,M,46.9,M,,*47

The receiver is sending the actual position (latitude 38°77.038′ NORTH and longitude 77°02.110′ WEST), obtained at 18:36:19 thanks to 8 satellites. The fix (position) quality is GPS Fix (1).

To be able to get data from the GPS receiver your program must therefore “understand” the NMEA sentences it receives. I found a very good library, minmea, developed in C and able to parse the most important NMEA sentences.

You only need to copy the two source files (minmea.c e minmea.h) in a subfolder of the components folder of your project and to create a component.mk file as it follows:

gps-001

I had to add the highlighted flag because of the esp framework does not include the timegm() function and therefore, as explained also in the README of the library, you need to tell the compiler to use the more common mktime() instead.

Program

In my Github repository you can find the program I developed for this tutorial. Let’s analyse the most important pieces of code:

To use the minmea library, include its header file:

#include "minmea.h"

Read a line from the UART1 controller and pass it to the library to be parsed:

char *line = read_line(UART_NUM_1);
switch (minmea_sentence_id(line, false)) {
  case MINMEA_SENTENCE_RMC:
  [...]
  case MINMEA_SENTENCE_GGA:
  [...]
}

Finally verify if the new parameters are different from the ones already saved and, if so, print them on the screen:

float new_latitude = minmea_tocoord(&frame.latitude);
if((new_latitude != NAN) && (abs(new_latitude - latitude) > 0.001)) {
  latitude = new_latitude;
  printf("New latitude: %f\n", latitude);
}

I added a threshold value (0.001) to avoid printing a lot of small updates, due to disturbances or oscillations on received data.

Here’s the program running on my laptop:

gps-010

Taking First Place at IMAV 2016 Drone Competition

The IMAV (International Micro Air Vehicle) conference and competition is a yearly flying robotics competition hosted by a different University every year. AKAMAV – a university student group at TU Braunschweig in Germany – have written up a fascinating and detailed account of what it was like to compete (and take first place) in 2016’s eleven-mission event hosted by the Beijing Institute of Technology.

AKAMAV’s debrief of IMAV 2016 is well-written and insightful. It covers not only the five outdoor and six indoor missions, but also details what it was like to prepare for and compete in such an intensive event. In their words, “If you share even a remote interest in flying robots and don’t mind the occasional spectacular crash, this place was Disney Land on steroids.”

indoor-missions

The eleven missions were inspired by a hypothetical oil spill on an oil platform. They included:

Outdoor Missions:

  1. Takeoff from a moving and rocking platform
  2. Live mapping of a mission area to identify targets of interest
  3. Precise delivery of a life buoy / life-preserver
  4. Collection and delivery of a water sample
  5. Landing on the same moving and rocking platform

Indoor Missions:

  1. Takeoff from a moving platform
  2. Enter a target building from doorway, chimney, or window
  3. Map the inside of the building
  4. Pickup and release of specific objects (i.e. find specific objects and move them to designated locations)
  5. Exit the building
  6. Land on a moving platform

Multiple drones could be used but teams scored better the smaller the drones were, the more missions were done in a single flight, and the higher the difficulty of the challenges (i.e. choosing to land on a moving versus stationary platform.) Human piloting was a permitted option for the indoor missions, but for the outdoor missions flight had to be autonomous. Overall the less humans were involved, the better the team’s score.

drones-for-imav2016

For the outdoor missions, AKAMAV used two identical 550mm quads with 600g payloads. Flight controller was a pixhawk with APM:Copter and an onboard companion PC for other tasks, plus other components as needed. the indoor missions were 60mm Tiny Whoop quads for the starting, entering, and landing portions. The indoor mapping and pickup-and-release missions were handled by a modified 250mm racer using a 360 degree camera combined with Pix4D software.

The entire after-action report is worth a read but in particular their approach for the live mapping of an outdoor area is interesting. AKAMAV stated that there is no plug-and-play solution for live mapping an outdoor area, so they focused on that and were confident they could pull a win over their competition. They planned a hybrid approach of balancing on-board processing with off-board processing to use the strengths of each. In this they were not completely successful, but still happy with their results. “We succeeded somehow with a not so beautiful, yet real-time stitched map. […] In the end 5 out of 6 targets can be recognized, making us one of few teams solving the live mapping mission at IMAV 2016.” Check out their published conference paper: Towards a Real-Time Image Mosaicing Solution.

Embedded below is an early video of AKAMAV’s maiden test flight carrying their chosen 360-degree camera (a Ricoh Theta S) which they would later use to generate the 3D point cloud for indoor mapping at IMAV 2016. If you’re not familiar with these videos, pan around by clicking and dragging.

Other recent innovations from people in the drone scene include a successful autonomous battery swap as well as flight via wireless powerIMAV 2017 will be held in Toulouse, France – so start your planning now.

 


Filed under: drone hacks

Micro Radio Time Station Keeps Watch in Sync

The US National Institute of Standards and Technology (NIST) broadcasts atomic clock time signals from Fort Collins, Colorado on various frequencies. The WWVB signal on 60 kHz blasts out 70,000 watts that theoretically should reach the entire continental US. Unfortunately for [Anish Athalye], the signals do not reach his Massachusetts dorm, so he built this GPS to WWVB converter to keep his Casio G-Shock self-setting watch on track.

Not a repeater but a micro-WWVB transmitter, [Anish]’s build consists of a GPS receiver module and an ultra low-power 60kHz transmitter based on an ATtiny44a microcontroller’s hardware PWM driving a ferrite rod antenna. It’s not much of a transmitter, but it doesn’t need to be since the watch is only a few inches away. That also serves to keep the build in compliance with FCC regulations regarding low-power transmissions. Heavy wizardry is invoked by the software needed to pull time data off the GPS module and convert it to WWVB time code format, with the necessary time zone and Daylight Savings Time corrections. Housed in an attractive case, the watch stand takes about three minutes to sync the watch every night.

[Anish] offers some ideas for improving the accuracy, but we think he did just fine with this build. We covered a WWVB signal spoofer before, but this build is far more polished and practical.


Filed under: clock hacks, radio hacks

A Beacon Suitable for Tracking Santa’s sleigh?

High-altitude ballooning is becoming a popular activity for many universities, schools and hacker spaces. The balloons, which can climb up to 40 km in the stratosphere, usually have recovery parachutes to help get the payload, with its precious data, back to solid ground safely. But when you live in areas where the balloon is likely to be flying over the sea most of the time, recovery of the payload becomes tricky business. [Paul Clark] and his team from Durham University’s Centre for Advanced Instrumentation are working on building a small, autonomous glider – essentially a flying hard drive – to navigate from 30 km up in the stratosphere to a drop zone somewhere near a major road. An important element of such a system is the locator beacon to help find it. They have now shared their design for an “Iridium 9603 Beacon” — a small Arduino-compatible unit which can transmit its location and other data from anywhere via the Iridium satellite network.

The beacon uses the Short Burst Data service which sends email to a designated mail box with its date, time, location, altitude, speed, heading, temperature, pressure and battery voltage. To do all of this, it incorporates a SAMD21G18 M0 processor; FGPMMOPA6H GPS module; MPL3115A2 altitude sensor; Iridium 9603 Short Burst Data module + antenna and an LTC3225 supercapacitor charger. Including the batteries and antenna, the whole thing weighs in at 72.6 g, making it perfectly suited for high altitude ballooning. The whole package is powered by three ‘AAA’ Energizer Ultimate Lithium batteries which ought to be able to withstand the -56° C encountered during the flight. The supercapacitors are required to provide the high current needed when the beacon transmits data.

The team have tested individual components up to 35 km on a balloon flight from NASA’s Columbia Scientific Balloon Facility and the first production unit will be flown on a much smaller balloon, launched from the UK around Christmas. The GitHub repository contains detailed information about the project along with the EagleCAD hardware files and the Arduino code. Now, if only Santa carried this on his Sleigh, it would be easy for NORAD to track his progress in real time.


Filed under: gps hacks, hardware

Creepy Wireless Stalking Made Easy

In a slight twist on the august pursuit of warwalking, [Mehdi] took a Raspberry Pi armed with a GPS, WiFi, and a Bluetooth sniffer around Bordeaux with him for six months and logged all the data he could find. The result isn’t entirely surprising, but it’s still a little bit creepy.

If your WiFi sends out probe requests for its home access points, [Mehdi] logged it. If your Bluetooth devices leak information about what they are, [Mehdi] logged it. In the end, he got nearly 30,000 WiFis logged, including 120,000 probes. Each reading is timestamped and geolocated, and [Mehdi] presents a few of the results from querying the resulting database.

For instance, one person who shared a train commute with [Mehdi] got on at Meriadek and got off at Lycee Dagin on July 14th, and was never seen again. Another fellow train rider’s WiFi sent out probes for a Dominos pizza WiFi BSSID. [Mehdi] points out that you could even figure out which riders knew each other because they often connect to devices with unique IDs, which could be used to correlate them.

Now, all of this is actually more telling about [Mehdi] than anyone else he meets. You can easily tell which train lines he rides and when. But if there were a network of these sniffers scattered around the city, especially if they were made cheaper out of something like an ESP8266 or a used cell phone, one could play NSA on a human-scale budget. (Local laws allowing.)

Is this horrible, creepy, illegal, or yesterday’s news? Hash it out in the comments!


Filed under: wireless hacks

Custom Data Writer Board For 1996 Plane’s GPS

[Dmitry Grinberg] recently bought a Cessna 150 that contained an old IFR-certified GPS from 1996, the KLN89B. The GPS unit contains a database which by law has to be kept up-to-date for IFR flight. The problem was that, while Honeywell still supplied the data in electronic form, [Dmitry] had no way to update the GPS. The original ways for doing it are either no longer supported, too expensive and a pain to do, or not available to him due to the way his GPS was installed.

Two of those ways involved removing a data card which can legally be slid out of the GPS’s front panel. The data card is what stores all the data but it’s a proprietary card and there’s no reader for it. [Dmitry]’s solution was therefore to make his own reader/writer board.

Reading the card using the STM32F411 dev board
Reading the card using the STM32F411 dev board

Examining the card, and another he’d bought off of ebay, he was able to use the datasheets for the components to work out the card connector’s pinout. Starting from there he wired it up to an STM32 development board and proved that he could reliably read the card’s contents.

Having done that, he next designed his reader/writer board around the 5V AT90USB646 Atmel 8-bit AVR RISC-based microcontroller. Also on the board is a 12V boost converter and a connector for plugging in the card.

While his board was being manufactured he turned his attention to the data itself. Honeywell still supplied updated data in digital form as a Windows EXE file. A quick examination showed it to contain a ZIP file, and in no time he had the database itself. But it wasn’t as simple as that. Most of it turned out to be encrypted, and from more experimenting, he’d learned that the data was supposed to be decrypted before being written to the card. However, [Dmitry] was up to the challenge and after a few days hard work, found that the encryption was fairly simple and based on applying CRCs starting with a key that was in the data itself. After a remaining troublesome 8 bytes, he had the proper updated data for writing to the card.

Once his manufactured board arrived, he added the microcontroller and other components and had it reading, writing and erasing the card in no time. While he has made the schematic and all software available on his website he also gives plenty of disclaimers, understandable, since this is for a GPS in a plane. But even if you’ve no need to use it, you’ll also find on his website [Dmitry]’s very detailed write-up of this project.

KLN89B GPS data card reader writer schematic
KLN89B GPS data card reader writer schematic

[Dmitry]’s also no stranger here on Hackaday. His projects have ranged from an encrypted USB bootloader for AVRs to a greeting card made from a CD case that plays full songs to an 8×8 matrix LED pendent encased in epoxy.


Filed under: gps hacks

Barely-There GSM GPS Tracker

What’s the most un-intrusive GPS you’ve ever seen? How about for a bike? Redditor [Fyodel] has built a Teensy-based GPS/GSM tracker that slides into your bike’s handlebars and really is out of sight.

The tracker operates on T-Mobile’s 2G service band — which will enable the device to work until about 2020 — since AT/T is phasing out their service come January. Since each positioning message averages 60 bytes, an IoT data plan is sufficient for moderate usage, with plans to switch over to a narrow-band LTE service when it becomes more affordable. [Fyodel] admits that battery life isn’t ideal at the moment, but plans to make it more efficient by using a motion sensor to ensure it’s only on when it needs to be.

GSM GPS Tracker ThumbThis isn’t [Fyodel’s] first rodeo, he has a previous revision of the tracker up on his Tindie store. But there are some real challenges with the new concept. The rounded PCB handlebar mounts look great, giving an almost futuristic design profile that you won’t really see. The board fits inside the metal handlebar tube, and signal issues haven’t been completely cleared up — an antenna will likely be the primary resolution. Otherwise, replacing the handlebars with carbon fiber is a safe bet.

Combine this tracker with a heads-down display and you’ll have a tidy little setup for your next cycling adventure.


Filed under: gps hacks, transportation hacks

GPS Disciplined Oscillator review and teardown

inside-allAndy Brown did a teardown of a GPS Disciplined Oscillator:

The design did actually surprise me. I was expecting to see an OCXO pulled from something else together with a modern GPS unit and an MCU to co-ordinate the synchronisation all mounted on a custom PCB. What we’ve actually got is an entire Symmetricom GPSDO pulled from some other device and mounted on to a trivial minimal PCB that does nothing more than break out connections to the front panel.

More details at Andys Workshop blog.

Check out the video after the break.