06/20/2016 at 17:37 •
It's been some time since my last update, I was awaiting some parts in the mail. Those parts were.... *drumroll* radios with LoRa support! It might be reasonably obvious at this point, but the name of the project is play on the name of that modulation scheme. I started with the other radio modules as a PoC, as availability of the LoRa radios was sparse for some time.
First modules I got are the HopeRF RFM95W. They're about 3/4th the size of the RFM69 modules that I put in the original design, and the range should be much improved with LoRa. They fit right on my ESP8266 breakout boards, as the modules are of similar pitch and size. Thanks to this, I'll be able to pop them right on my test boards (with a little rewiring) and I'll be good to go.
Adafruit also sells the Feather board with a Atmel ATMega 32u4 and RFM95W, which is tempting to grab to develop a multi-node test rig.
Secondly, I bought some Microchip RN2903 modules, which fully integrate the radio and break out a UART for communication. They've also got a boatload of GPIO. These might be overkill for this application, but I'm going to run some tests anyway. I'm working on a breakout/testing board for these, which should arrive relatively soon.
05/26/2016 at 21:56 •
Made some good progress since last check in on the hardware prototype devices.
I received my ATAES132s, and I finished wiring the SubModule board! I threw some OLED test code on the Zero and ran I2C Scanner to verify everything is happy on I2C. Still have to verify that the HopeRF modules work on both the HAT prototype and the SubModule prototype, but I'm 95% of the way ready to start writing some software/firmware.
I plan on busting out my RTL-SDR module for some basic RF analysis, so I can get some insight into how well the prototypes are performing. I also put in an order for some Microchip RN2903 LoRa modules to start prototyping using those radios in place of the HopeRF RFM69-HW. I'm going to be running that effort in parallel, as it seems like the LoRa modules will have better overall range than the RFM69-HW modules, but I won't have my hands on any for another couple of weeks. Also, due to their size, I will have to re-evaluate some of my mechanical decisions, but for the most part not much should change.
05/24/2016 at 19:52 •
Today I uploaded the latest protocol specification. It's got a lot of the important bits laid out such as the Gateway database table layout, Packet format and specification, operational characteristics, and the transaction base for a Trusted Star network. There are some very important bits missing still, like the AES encryption details, public/private encryption details, and sync secret details. These will be added in the coming weeks, as I have more time to dive into the implementation details. I've got these planned out, but would rather keep them out of the specification until I've completed a thorough second pass. I'm also working on transaction flowcharts, which will be included in the next protocol specification.
I included the license for the Protocol (and entire project, really) in the Protocol Specification document. Yay, MIT License! The entire project will be open source. Board designs, protocol, code, etc. It going to be lots of fun.
Attached is a small diagram for a Star network. There's not much to it, but it's a helpful, if simple, visualization of how a Laura network would be physically setup in Star mode.
05/22/2016 at 17:51 •
I thought I would talk a bit about my strategy for testing and verifying the operation of the modules.
Firstly, I have two Moteino R4 boards with RFM69HW radio modules installed on them. By putting these modules into monitor mode (disabling the packet address checks), I can examine the packets that are traversing the network. I will attempt to attack the Nodes using a PC and Moteino, by maliciously crafting packets, attempting replay attacks, and exercising other protocol attack strategies.
I have written up a model for a protocol fuzzer/test suite, which will iterate through the possible transaction scenarios (i.e. Dropped ACK, Transmit failure, ACK receive failure, Out of range, Bad destination, etc...) to exercise all of the paths. It can be run from a Linux system, with a SubModule connected to it (for -> Gateway tests), or straight from the Gateway (for -> Node tests).
It should be possible to detect obnoxious style attacks, such as general packet flood, excessive malformed packets (fuzzing), failed replay attacks, etc. Notifications could be dispatched to a particular Node when these events occur. There's an absolute limit to the power available on the Nodes, so the network will always be somewhat vulnerable to DoS style attacks. But, these attacks will be included in the testing, regardless.
I also have an RTL-SDR setup that I can use for light RF analysis and deep packet decoding, if need be. For the time being, I don't think I will need this level of inspection. This will help when I perform absolute range tests.
05/19/2016 at 22:30 •
Some things have changed a little bit since last update. I dropped the SAMD20 Xplained Pro boards for an Arduino Zero (as this is an exact match for the chip I'm using, the SAMD21). There's only a couple small differences between these two chips, but I'm a stickler for equivalent prototypes. As far as the boards themselves go, they both use the Atmel EDBG, and should work similarly. I'm going to make the Zero wiring/bootleg shield I made modular, so I can plug the Handheld or Submodule test boards into it.
I ditched my initial Submodule prototype because of the above and below reasons, so that's back down to 20% hardware complete.
I had some good luck, and my ESP8266 breakout boards JUST reach the pins on the HopeRF modules. (They're a little short, but I made up the difference.) So, rather than running a ton of wires for the prototypes, I have clean, veroboard mount, and pluggable modules now. You can see them in the pictures. A couple of the pin names even matched. I also had RP-SMA Launch connectors laying around that fit my veroboard. So, I can use the antenna I intended to use, and perform some other experiments. I expect that the initial prototypes will have awful RF performance because of the breadboard/connectors/hand wired antenna connector, but they're only serving as PoC, so no worries.
I'm almost done wiring up the Gateway prototype, 90% of the way. You might notice something important is missing. The ATAES132? Yeah. I overnighted a batch from Digikey, so they should be arriving tomorrow. Once I get that on, I can write some sweet sweet Gateway code.
Way at the bottom is the progress on the Submodule test bits. Parts are soldered in place (into female headers, really), but not wired yet. I'll knock that out (hopefully) tomorrow when I have the AES chippies in hand.
05/13/2016 at 22:42 •
This is my first progress report after taking the wraps off of Laura. So far:
Establishing a working SubModule prototype using on-hand parts (SAMD20 Xplained Pro x2, HopeRF modules, ATAES132A on Breakout): 40% complete.
The remaining 60% is all firmware that must be developed for the SAM to exercise all of the hardware and perform point-to-point tests. Once those tests pass, I will build upon this firmware to bring it to Alpha level for testing on actual hardware prototype boards.
Esablishing a working Gateway prototype using on-hand parts (Raspberry Pi 2, HopeRF modules, ATAES132A on Breakout): 10% complete.
Completed research on proper device hookups, prototype plan and tests written, basic code skeleton established.
Laura HAT v1.0:
Second pass board design complete. Needs placement tweaks, alignment, stitching. Prototype verification needed in order to release third pass to fab once complete.
Laura SubModule v1.0:
Third pass board design complete. Full prototype verification needed in order to release third pass to fab.
Laura Handheld v1.0:
Second pass inspired me to rip up the entire layout and start from scratch. The mechanical outline has been established and preliminary component placement is set. So, back to zero passes for now. More to come.
Started tweaking the base Rasbian Jessie Lite image to meet the requirements for the security of the Gateway and for a read-only root partition. Defining list libraries and utilities that will need to be installed into the image to proceed.
PoC plan and tests written. Researching and shaking off some cobwebs for coding the routines necessary efficiently.