adunk

This is great reading for everyone who grew up watching Terminator 2 and was fascinated by the chase scene where the T-1000 terminator bursts through a bridge down into in the LA river.

This seems to be the bridge: https://goo.gl/maps/3v3LK6h75LqrzexSA

More info in their Mobicom paper: https://dl.acm.org/citation.cfm?id=3345436

Many years ago I picked up a nice idea on how to write abstracts that efficiently convey the idea of a paper. Unfortunately, I don't remember where I read it, so I can't give proper credit.

The idea is that you should write your (first version of the) abstract using only four sentences:

Sentence 1: State the problem

Sentence 2: State the consequences of the problem

Sentence 3: State your solution

Sentence 4: State the consequences of the solution

This makes a very to-the-point abstract. Sometimes these work right away and sometimes they have to be refined through multiple iterations. If they need further iterations, the four-sentence abstract is a great starting point.

Examples:

Most hamburgers are larger than what can be held with one hand. This makes them hard to eat. We present a new type of hamburger, called the Hand Burger, that is small enough to hold in one hand. Experimental results show that the Hand Burger increases eating speed by up to 150%.

The node_modules directory of Node JS applications often contain multiple copies of the exact same file. This increases the size of the node_modules directory and decreases application startup speed. We have developed a caching scheme for Node JS modules that maintains a single copy of each unique file. This mechanism reduces the size of the node_modules directory by 75% for the most commonly used Node JS applications and increases startup speed by 25% on average.

Horse-drawn carriages have a hard time moving on land because of vegetation. This makes travel slow, or outright impossible. We present a novel concept that we call roads. Our measurements show that roads decrease travel time from years to days to reach the 20 most popular destinations throughout the Roman Empire.

The full paper, which was published at MobiCom 2017, is available here: http://www.mit.edu/~fadel/papers/RFind-paper.pdf

Yes, this is an interesting topic! And even if you can make the hardware survive for a long time, even in harsh conditions (something like this comes to mind: https://sploid.gizmodo.com/this-old-ass-commodore-64-is-stil... ), the surrounding software ecosystem will still be an issue. Everything from compilers for building the firmware to the server side software will have progressed/aged in those decades.

The Cooja simulator runs nicely on a regular laptop and could then run up to some 50 nodes at real time speed. For larger networks, a larger computer is needed. Alternatively, the simulation speed can be reduced. The simulation detail level also affects the speed. With a highly detailed simulation, with device microprocessor and radio transceiver emulation, a normal laptop can handle some 10 nodes before it starts to slow down.

Each device does have a unique MAC address. But the protocols are designed to work even if that MAC address happens to not be unique. The IPv6 address assignment procedure first attempts to claim an IPv6-address based on its MAC address, but before finally assigning the address, the device will test if the address is already taken. If another device in the same network happens to have the same MAC address, that device will have claimed the same IPv6 address already and that device will defend its address. The new device will then choose a new IPv6 address to avoid collisions.

(Adam, Thingsquare CEO here)

The routing protocol is called RPL (pronounced "ripple") and is designed to create a directed acyclic graph to route IPv6 packets in networks where the nodes are severely memory-constrained. It is defined by RFC6550. There is more information in http://www.thingsquare.com/docs/mesh/ and https://tools.ietf.org/html/rfc6550

There is no hard limit to the number of nodes in a RPL network. The protocol is defined so that every node can reach the root of the network, but requires additional work to reach nodes inside the network. The mode of operation that we are using in the Thingsquare system is called storing mode and requires all nodes on a path between two nodes to maintain information about the route. This does not scale to large number of nodes. But this is needed only when setting up a TLS connection, to exchange security secrets, which is normally only done once per node. When the TLS connection goes down, the route is torn down, which allows for another route to take its place.

(Adam, Thingsquare CEO here)

Yes, the 100 nodes in close proximity is quite a bit different from 100 nodes spread out across a larger geographical area. Even if we can play tricks with routing tables to make the testbed act more like a real deployment, there is much more congestion in the testbed because all can hear each other. Also, there are many wireless effects in play in a real-world situation, such as the capture effect, that has several implications for how the distribution and routing protocols operate.

By default, the simulation does not try to replicate the testbed setup, but rather the real-world deployments. But we can tweak the simulation to behave more like the testbed if we want to inspect behavior we see in the testbed that we don't see in real-world deployments.

(As it happens, this was pretty much the topic of the PhD thesis of Thingsquare CTO Fredrik a few years back: http://uu.diva-portal.org/smash/get/diva2:447343/FULLTEXT01....)

For this level of time synchronization it is enough to send a few extra bytes with synchronization information in each packet. If you'd be down at microsecond-level synchronization, you probably need to do temperature compensation - particularly in outdoor deployments where there can be a 40 C / 100 F difference between two nodes on a sunny winter day.

Transmit-only mechanisms are definitely the best way to go to reach the extreme minimum in low power levels. The problem with transmit-only systems is that they are difficult to use in most real-world situations. Once you have deployed a transmit-only sensor, you are stuck with the configuration that was hard-coded into it. There is no way to change how often you want the sensor to report, how and when it should trigger, and any other parameters and requirements that may change as the project develops - encryption keys being one example.

The mesh nodes have to run either in always-on mode (which makes perfect sense if they are powered by, say, a wall socket, which they often are) or in a sampled listening mode. Sampled listening shaves some 98% off from the radio duty cycle compared to always-on mode, but still is not enough for the mesh nodes to run on coin cell batteries. Give them a larger pack of batteries and they'll run for months though.

To send data to a node in sampled listening mode, the sender sends a string of smaller wake-up packets that indicate when the sender intends to send the real data packet. When the receiver picks up the wake-up packet, it knows when it should wake up again to receive the data packet, so it can safely go back to sleep again for a while. And if the sender knows that the receiver is in always-on mode, because it is powered by a wall-socket, the sender can skip sending those wake-up packets, saving a bit of power.

This requires clocks to be synchronized, but only loosely - millisecond synchronization is enough. The trick is to strike the right balance between communication responsiveness and power consumption.

It is possible to react at any time because of an external hardware event, such as a button press or a hardware sensor that triggers. Depending on the sensor or external hardware, those events can be very cheap in terms of power consumption. For example, a button switch can be completely passive and consume power only when it triggers. Once it triggers, the microprocessor wakes up and can decide to handle the event, potentially by using the radio to send a message. Sending the message will consume much more power than just turning on the microprocessor, so depending on the application logic the microprocessor can simply choose to ignore the event and go back to sleep.

"Waking up" in the context of the article should be taken as "waking up an turning on the radio to check if anything happens that I should be aware of". This involves power-consuming activities, such as turning on and using the radio, and cannot be completely passive. That's why it pays off to not do this too often.

That Phenomena demo in the youtube video that you linked to is actually a very clever display of the infinite bob trick. It is just so convincing that it is, still, difficult to spot it.

Although this is pretty far away from the Arduino-style boards, you may want to have a look at the Sensortag from Texas Instruments: http://www.ti.com/sensortag

It is based on a single-chip wireless microcontroller that has both support for both BLE and IEEE 802.15.4 (6lowpan/ZigBee). It is supported by the Contiki OS (http://www.contiki-os.org/). The learning curve is probably quite a bit steeper than that of an Ardiuno, but the board and the chip can be readily included in commercial products. There are reference designs with design files, BOMs, schematics available from TI.

Since it has both BLE and 6lowpan support, you can do some pretty nice things with it, such as providing both quick discovery via smartphones and secure remote access: http://www.thingsquare.com/blog/articles/proximity-control/

A couple of years ago Contiki had a lot of rough parts that were in dire need of a bit of love - something we've worked hard to fix in the past few versions. Version 3.0 is by far the most solid Contiki thus far. Maybe you got stuck in the middle of this

Not sure about Coffee in particular though, simply because file systems isn't really the focus of Contiki. Unlike server and desktop OSes, where the file system really is a core item, embedded OSes like Contiki don't depend on them and they are only used by a small subset of applications.

The trick is as always to know what you are looking for and find the tool with the strengths in the right places. As with any system, Contiki has its strengths and weaknesses. The Coffee file system does its job well for what it was intended for (storing simple files on an on-board serial flash chip), but it seems like it didn't match what you were looking for. Filesystems certainly wasn't a design goal of Contiki, there may be better places to look.

If you're looking for a lightweight OS that does low-power IP networking with built-in support for self-healing wireless meshing, I think it is difficult to find an OS that beats Contiki. Take this from someone who has in fact built a business on top of Contiki :)

Quickly checked out the report - very cool simulation scenarios of London and New York!

The Cooja simulator is an integral part of the Contiki distribution: all the automated regression tests are run in Cooja. Cooja is actually very reliable, but because it runs user code in the same process as the simulator in the most high-performance mode (for performance reasons) it is not uncommon for user code to crash the simulator. My guess is that this was the problem in your case, particularly if this was your first significant C project.

It is possible to run Cooja in an emulation mode too (but only for the MSP430 microcontroller) where the user and OS code is completely isolated from the simulator process - much more reliable and easier to find bugs that break the user code, but much, much slower.

The 6502-based ports (Commodore 64/128, Apple II, etc) are actually still all being built by our regression test framework for every commit we make. The 6502 C compiler is a little harsher on following the C specifications so has saved us on more than a few occasions from making changes that would potentially break on other platforms.

Not sure the market really is moving towards WiFi/BLE - there is a lot of talk about BLE meshing right now, but so far haven't really amounted to much it seems.

The strongest part of 6lowpan meshes right now is that it supports sub-GHz communication, which has much longer range and less interference than 2.4 Ghz.

In the end though it doesn't really matter which radio technology is being used, as long as it gets stable Internet connectivity. Once you're there, the backend is easy to reach.

Adam, Thingsquare CEO here.

We could expose a device API, and might do so in the future, but exposing an API means that we'd have to maintain that API for the foreseeable future. We do have an API for connecting apps and server-side software, but devices currently have to connect using our Thingsquare client firmware.

Adam, Thingsquare CEO here.

The Thingsquare platform connects products with smartphone apps, which is similar to what many other platforms do, including HomeKit, Brillo, and Parse's IoT platform. Unlike other platforms though, Thingsquare allow secure remote access even for products that aren't always in range of WiFi or BLE. We're using a self-healing wireless mesh so that products can cover large installations and work nicely even in places with poor WiFi.

The web site hosted by a web server running on the Homebrew CPU seems to be offline. Here is a cached version: https://web.archive.org/web/20051103083029/http://magic-1.or...

I can't speak for the creators of Flutter, but I can definitely attest to that TCP/IP with full mesh routing should be doable with the Flutter hardware. We (Thingsquare) have the CC1101 as one of our supported hardware platforms and use it to run full TCP/IPv6 networking over a self-forming mesh. The system is used in a number of commercial products and systems. The chip-level firmware is open source so I guess the creators or backers of the Flutter system might even be able use it pretty much out of the box: http://thingsquare.com/tech/

One of the things needed to get full IP routing working is to do channel switching over the sub-GHz connection. Both the FCC and ETSI regulations let you transmit at a higher power and with longer bursts if you switch channels with a regular interval and if you back off if you find other transmissions in your channel.

That said, TCP/IP routing over a sub-GHz CC1101 link isn't going to be very fast. It is suitable for automated devices but not a general purpose replacement for WiFi connectivity. For IEEE 802.15.4g-compliance, the raw bit rate is 50 kbit/s which isn't a lot. The CC1101 can be run in faster, non-802.15.4g compliant, modes though.

This discovery may not seem like much to the world, but it really is a milestone for those that are intimately familiar with hardcore graphics programming of the Commodore 64. The Commodore 64 had numerous glitches and undocumented behavior that made it possible to do seemingly impossible things, such as displaying graphics on parts of the screen where it was not intended to be displayed. In the mid 1980s, a subculture formed with people who wanted to find those tricks and glitches in order to impress each other with stunning displays of hardcore hackery that produced graphical effects that everyone, up to that point, had thought would be impossible.

Since all Commodore 64 computers were essentially exact copies of each other in terms of hardware, with (almost) all the same glitches, it was possible to write code that took advantage advantage of them and still worked for everyone. Except for this VSP trick, which annoyingly enough seemed to cause random crashes on a large percentage of machines.

This VSP trick made it possible to scroll graphics across the screen in unbelievable speed. If you had ever tried writing a super-optimized machine code routine for scrolling graphics, you'd be absolutely shocked the first time you'd see the speed at which this VSP trick was able to move graphics. And it was extensible in many different ways: it could not only be used to move graphics but also to trick the graphics chip to give more cycles to the CPU, so that you could produce even more stunning and seemingly impossible tricks. So people used VSP, even though it could cause random crashes.

But now, finally, we have an explanation for something that has been bugging a small number of hardcore hackers for decades. And the discovery is by itself the same kind of stunning display of hardcore hackery that made the bug so widespread in the first place.

Just a few quick pointers from the top of my head:

Nice starting point to get a feeling for power/throughput trade-offs in low-power wireless networking: http://sing.stanford.edu/pubs/sing-08-00.pdf

Sensys 2008 paper about web services for tiny IoT systems: http://research.microsoft.com/en-us/um/people/zhao/pubs/tws0...

Proceedings of the IEEE 2010 article on IPv6 for low-power wireless: http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ieeeproc112010.p...

Sensys 2011 papers on trade-offs and interoperability of RPL mesh routing for low-power IPv6 and on TCP for low-power wireless: http://dunkels.com/adam/ko11beyond.pdf http://dunkels.com/adam/duquennoy11lossy.pdf

There are also two books on the subject and a bunch of relevant papers on the Contiki website: http://6lowpan.net/the-book/ http://www.thenextinternet.org/ http://www.contiki-os.org/support.html

(Full disclosure: I'm a co-author on a bunch of those last pointers.)

Author of miniweb and uIP here. uIP is a real IPv4 stack, with all the needed bells and whistles, but miniweb really is only a super-specific proof-of-concept that is not particularly useful for anything else than demonstrating that it can be done.

While something like uIP definitely can be used (and is being used) for IoT applications, uIP only is an IPv4 endpoint. Most IoT applications have a wireless communication medium which by its nature is fluctuating and unpredictable, so you'll typically want to have support for a self-healing wireless mesh network. Such a mesh network adds a bit of complexity, code footprint, and memory usage. And since existing low-power meshing standards like IETF RPL are defined for IPv6 and not IPv4, you need to have support for IPv6 as well. So in the end, the nice and small footprint of uIP will have grown. Also, the footprint for uIP given on the Rowley page are for the stack alone, and does not include things like radio drivers or an OS scheduler.

For a full-mesh low-power IPv6 IoT system, a more realistic figure is what we have in Thingsquare Mist (http://thingsquare.com/mist/), where mesh nodes with a full Contiki OS and IPv6 support have a code footprint closer to 50k than 12k. That said, we have successfully been running Thingsquare Mist on devices with 32k flash and 4k RAM, like the KL02 ARM device in the article. But this has been for non-mesh fringe nodes that only used UDP/IPv6 multicasts to communicate with its immediate neighbors, and no mesh networking.

A few weeks ago I watched the pilot episode of Lewis, a British TV detective/crime drama that is set in the surroundings of Oxford university, UK. One of the characters in the episode was a PhD student in mathematics and the key to the mystery could be found in one of the papers for his PhD dissertation. The detectives found the paper in question on the character's computer and opened it up for the viewers to see. Lo and behold, the paper was clearly typeset in LaTeX. Someone apparently went out of their way to make this little detail look just right!

Maybe its just me, but it seems like movies are getting better and better in getting those tiny but ever so important technical details right.

Creator of protothreads here. Protothreads are not a hack.

Protothreads revolve around the concept of local continuations. Unlike traditional continuations, a local continuation only captures the state of execution within the local function in which they are created. I.e., a local continuation does not contain the call stack. This makes it possible to do things like invoking protothreads from multiple call paths.

The "hack" you refer to is just one possible implementation of the protothread concept, in which the local continuations are implemented by a switch statement in the spirit of Duff's device. This implementation technique allows the protothreads library to be implemented in only 7 lines of code (!) but it has a bunch of drawbacks, such as not recording the state of local variables. In fact, because of these drawbacks, the switch-based implementation arguably does not provide a fully functional version of protothreads.

There are other ways to implement protothreads. The original protothreads library contains an implementation where the local continuations are done using gotos and gcc's labels-as-values feature. This does remove some of the problems with the switch statement, but still does not record local variables. Others have implemented protothreads in C++, where a class object is used to store local variables, and by adding a C2C wrapper compiler that produces C code that stores and restores the local variables.

Protothreads were created to explore some of the finer points in the twilight zone between multithreading/coroutines and events/state machines. The intent was never to emulate continuations, coroutines, or threads but to find a less expensive way to achieve linear code flow. With protothreads, linear code flow can be achieved without having to store multiple thread stacks, which is important in many of the systems for which protothreads were originally intended. The switch-based implementation also has the added benefit of being possible use with any C compiler, which has been very useful as we have ported Contiki to a bunch of different platforms and C compilers.

But, yeah, the switch-based implementation of the protothreads concept can definitely be labelled as a hack. But - admit it - a beautiful hack! :)