Archive for the ‘Uncategorized’ Category

LoRaWAN Networking Part 2: Using End Devices

In part 1 of this series I showed how to set up a simple LoRaWAN gateway, and in a previous article described a simple but powerful LoRaWAN-capable end device that I designed. Now I’ll show how these devices can be used in a real LoRaWAN application.

LoRaWAN Application on The Things Network

The Things Network (TTN) is the Internet infrastructure that allows us to use end devices to do something useful on the Internet. End devices (sometimes called nodes) talk to a nearby gateway, which is connected to the Things Network infrastructure. An application is anything you can imagine on the Internet that does something with the data provided by the end devices. The Things Network bridges the radio technology to Internet technology. The communication does not need to be one-way; applications can downlink data to end devices, too. A common example of an application is a Cayenne dashboard which is an easy way to visualize data from your devices. You can also read data from TTN using Node-RED, a common tool for building IoT solutions.

In part 1 I showed how a gateway is registered to TTN. To connect end device nodes, we also have to define an application in TTN, even if the real functionality of our application is implemented elsewhere on the Internet. An application has a name and a unique ID called a Application EUI. It also creates an Application Access Key that you use to integrate other services like Cayenne or Node-RED to your application. I won’t go into the integration details because there is plenty of info available about that.

After creating a TTN application, you need to add devices to the application so that your code on the devices can talk to TTN. There are 2 ways for a device to authenticate with TTN. The recommended and more secure way is called over-the-air-activation, or OTAA. This is the default mechanism when you create a device in TTN. With OTAA, a device negotiates with the network to establish a network session key and an application session key. The other mechanism is activation-by-personalization, or ABP. With ABP, the keys needed to communicate with the network are hard-coded in the device ahead of time. This makes it much easier and quick to connect, but is less secure.

Before we go any further with details about OTAA and ABP, let’s define the many types of IDs and keys associated with LoRaWAN applications and devices. It can be very confusing, because some of them have very similar names!

Gateway ID: A uniquie identifer for your gateway. You specify this when you register a gateway with TTN.

Application EUI: A unique identifier for an application. It is provided by TTN when you create an application.

Device ID: A name that you assign to a device when you register it in TTN.

Device EUI: A unique identifier for an end device. This may be provided by your hardware so that you can specifiy it when registering a device in TTN. OR, you can have TTN generate one for you.

Device Address: An idenfier for an end device that is used during communication between device and TTN. This is assigned dyamically when using OTAA, but is hard-coded when using ABP.

Application Key: A value that is used for secure communication between device and TTN. This is generated when a device is registered with a TTN application. Each device has a different Application Key.

Network Session Key: A value that is used for secure communication between device and TTN. This is assigned dynamically for a session when using OTAA, but is hard-coded when using ABP.

Application Session Key: A value that is used for secure communication between device and TTN. This is assigned dynamically for a session when using OTAA, but is hard-coded when using ABP.

Is everything clear now? I didn’t think so. Let’s break it down in terms of what information you need for the two approaches, OTAA and ABP.

Over-the-Air Activation (OTAA)

After defining an application in TTN and registering a device, the device code needs some of important information in order to connect to the network successfully via a gateway. OTAA requires 3 pieces of information: Application EUI, Device EUI, and Application Key. The other information — Device Address, Network Session Key, and Application Session Key — will be determined dynamically during the activation process.

See the OTAA example on GitHub. Note the library dependencies required for the examples to work.

Although this method is secure and recommended, connecting to the network can take several minutes or more. The negotiation of session keys requires that the network communicate back down to to the end device during precisely timed receive windows, which can be tricky.

Activation-by-Personalization (ABP)

Using the ABP approach, the device code needs different information in order to connect to the network. ABP requires 3 pieces of information: Device Address, Network Session Key, and Application Session Key. This method of connecting is much faster and reliable, but for a number of reasons is less secure.

See the ABP example on GitHub. Note the library dependencies required for the examples to work.

When using an ABP device, it’s important to disable the frame counter checks in the device settings on TTN. This is one of the things making it less secure.

Range Testing

By driving around with an end device node in my car, I’ve tried to determine my communication range with my gateway. I’ve been a bit disappointed, but there are many things that affect signal propagation. First, despite having an 10-foot antenna mast, my antenna is still not even close to being higher than my house. And I’m hardly an RF engineer when it comes to designing my custom end devices.

They have a simple wire antenna, but my prior experimentation led me to think that this was just as good as any other LoRa antenna I’ve tried. In one test, my son and I each strapped a LiPo battery powered end device to our bikes and went for a long ride, having each node send GPS data every minute to my gateway (I realize that this test used far more duty cycle than one should in a real application). A Cayenne dashboard mapped the received data from each device. The smooth path on the map is the actually path as measured by GPS in my son’s phone. Superimposed on this are two non-smooth paths defined by blue points at which the gateway “heard” the GPS data reported from the end-device. The gateway is in the southwest are of the map, and you can clearly see that it did not receive much data when we are on the northernmost part of our bike ride. The maximum distance for a received signal was about 1.2 miles.

I also experimented between using confirmed vs. unconfirmed messages. Confirmed message get an acknowledgement from the gateway, whereas unconfirmed are more like “fire and forget”. Counterintuitively, it seemed like confirmed messages were more reliable and had better range. Nonetheless, I will continue to do more range testing to try to improve the situation.

Node-RED Integration

An online service like Cayenne makes it super easy to integrate with TTN, but you can also integrate with your own software via MQTT. Data uplinked from your devices to your TTN application are published to MQTT topics that you can connect to in your own application. I love using Node-RED for all sorts of IoT fun. You can use MQTT nodes (here “nodes” refers to Node-RED components, not end devices) to receive the data published by TTN. To make it even easier, TTN has even written custom nodes for TTN integration. If you are a Node-RED junkie like me, I strongly recommend you look into this type of integration so that you can build just about anything based on data from LoRaWAN end devices.

I hope you found these posts about LoRaWAN useful. The learning curve is significant but it’s exciting when a technology is so new.

Published by Michael, on October 28th, 2018 at 11:27 am. Filed under: Uncategorized. | No Comments |

Using a Relay Trigger with the Defusable Clock

Many of our Defusable Clock customers use the device in Airsoft competitions where participants must find the device and defuse it before the timer expires. A great thing to do in these games is to trigger a loud siren or smoke grenade when the timer reaches 00:00. The new version V2 of the clock has a connections for such a trigger and we are now selling relay modules in the nootropic design store.

Below is a picture that shows how to connect a relay. The red wire is 5V and if you have an older kit it needs to be soldered to the output pin of the voltage regulator. It then connects to the 5V red wire on the relay module. The 5V output is the rightmost pin of the voltage regulator when looking at the front of the board. The green wire is the trigger connection and goes to the green wire on the relay module. The trigger ground connection is the black wire going to the relay module.

Relay connections

UPDATE: there is now a 5V pad next to the trigger and ground pads that you can use:

To send 9V to your destination device like a siren or smoke grenade, connect a wire to the + connection near the power connector, and a ground wire to the – connection. These are shown as yellow and black wires in the picture. This assumes you have a 9V input voltage to the clock. If you are using a different voltage like 12V or a 7.4V lipo battery, that’s fine. This is the voltage available on the + connection.

The black ground wire connects directly to your device. The positive voltage (yellow wire) connects to the relay module terminal marked “COM” (for “common”). The gray wire in the picture is connected to the relay terminal marked “NO” (for “normally open”) and this wire is the positive voltage to your siren or smoke grenade or whatever.

When the countdown reaches 00:00, the trigger voltage (green wire) will cause the relay to close and connect the 9V yellow wire to the gray wire, thus providing 9V to your external device for a duration of about 2.5 seconds while the clock goes through the “detonation” sequence. If you want power to be disconnected when the countdown reaches 00:00, connect the gray wire to the terminal marked “NC” (“normally closed”) instead.

Have fun, and as always, stay out of trouble!

Published by Michael, on October 28th, 2014 at 11:14 am. Filed under: Uncategorized. | 11 Comments |

Watching the Feds Watch Me

I recently showed my Defusable Clock project on this blog. It got a lot of attention on the usual techie/hacker blogs, and the reaction was generally positive. I plan on selling an electronics kit so people can build their own, but I had reservations about doing so because some people might do something stupid with it. Writing about the project allowed me to get feedback about whether it was a good or bad idea. I concluded it was probably not a bad idea as long as I didn’t sell it pre-assembled, and didn’t sell anything that looked like explosives. I really don’t want to do anything wrong or enable anyone to do anything wrong. Just electronics fun.

A few days later, on Friday September 9, I noticed an interesting lurker in my online store. The domain name of the potential customer caught my eye: Was this someone at the Department of Homeland Security? Specifically, the Transportation Security Administration?

Who's this shopping in my store?

I used an IP lookup tool to check the IP address for Sure enough, it was Homeland Security. That was easy.

IP address lookup confirms that the shopper is from DHS

This isn’t the kind of attention I want. I decided to check my Google Analytics console to see if I could learn anything about who was visiting my site that day. One of the things you can look at is the service providers that your visitors are coming from. This isn’t usually very interesting, because it’s just Comcast, Verizon, etc. But this day was different. I was absolutely shocked to find that over 5% of my traffic was coming from one location.

Over 5% of my visitors on Sept. 9 were from Department of Homeland Security

That’s right — dozens of distinct visitors were from Homeland Security, and the number was rising steadily. By mid-day over 100 people at Homeland Security had hit my site.

Uh oh.

I had not done anything wrong, but I really didn’t want a personal visit from Homeland Security, the FBI, or SEAL Team Six. In late morning, my wife called me at the office from home — I was sure that gentlemen in dark suits were at the door, but it was a false alarm. I was feeling paranoid.

Could the government really be that interested in me? Maybe looking at a map of my U.S. visitors would make me feel better…


The statistics indicated that the visitors were not spending more than a minute on average on the site. They were taking a quick look, then leaving. My theory is that maybe a link to my Defusable Clock was included in some morning briefing or something, and a bunch of people checked it out. What do you think?

Nonetheless, I felt compelled to add this paragraph to the clock project post, hoping it might defuse the situation (pun intended):

Dear friends at the U.S. Department of Homeland Security:
I can see from my logs that you are very interested in my project, but I assure you that this is just a clock. There is nothing dangerous in these photographs; just wooden dowels and clay. I sell DIY electronic kits for customers to assemble themselves, and plan to sell the electronic components for this clock as a kit. It is no more dangerous than any other alarm clock. I would never sell or ship anything that looks like a dangerous substance or device as shown in the photos below. I’m on your side. So, we’re cool, right?

The hits from DHS came to a stop around 4:30pm EDT as government employees headed home for the weekend, so I started to feel better. Their visits declined over the 9/11 weekend and were a mere trickle this week. I successfully flew to NYC yesterday (Thursday the 15th) to attend World Maker Faire this weekend. If you see me at Maker Faire, make sure to come up and say “glad you made it!”. I’ll be wearing this shirt with an image of my Video Experimenter board design. See you there (hopefully)!

Published by Michael, on September 16th, 2011 at 7:17 am. Filed under: Uncategorized. | 5 Comments |