text:
tag:blogger.com,1999:blog-41100288867672343942020-03-28T11:05:57.968+01:00Six Pine TreesBlog about coding and tinkeringMaciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-24306402529127865982015-04-16T19:40:00.000+02:002016-03-20T09:19:39.255+01:00Linux RPL Router - improvements
In my previous post I wrote about an experimental Linux RPL router running on RaspberryPi using RPL code from Joao Pedro Taveira's linux-rpl. I encountered some problems with using the router, and I would like to share some advice on solving these problems.

Status of current 802.15.4 development
Linux 802.15.4/6LoWPAN support has been moved again. Currently the development is happening in bluetooth-next repository. The name might be a little confusing - repo contains 6LoWPAN code for both Bluetooth and 802.15.4. In general everything that has been done in old linux-wpan-next repo still works, which is a good thing :)

I pulled RPL code from linux-wpan-next repo to a clone of bluetooth-next repo - you can download it at GitHub, branch feature-rpl. All instructions for compilation and running RPL are still valid.

Also Alex Aring gave a speech about 802.15.4 in Linux on FOSDEM in Bruxelles. You can check the video here.

Problems with ifplugd
After recent changes wpan0 interface is created automatically during system startup. If you are using RaspberryPi with Raspbian this might lead to a problem with ifplugd daemon. This program always keeps wpan0 interface up and it will prevent you from changing some interface parameters like PAN ID. To solve the problem you need to modify /etc/default/ifplugd file to look more or less like that:

# This file may be changed either manually or by running dpkg-reconfigure.
#
# N.B.: dpkg-reconfigure deletes everything from this file except for
# the assignments to variables INTERFACES, HOTPLUG_INTERFACES, ARGS and
# SUSPEND_ACTION. When run it uses the current values of those variables
# as their default values, thus preserving the administrator's changes.
#
# This file is sourced by both the init script /etc/init.d/ifplugd and
# the udev script /lib/udev/ifplugd.agent to give default values.
# The init script starts ifplugd for all interfaces listed in
# INTERFACES, and the udev script starts ifplugd for all interfaces
# listed in HOTPLUG_INTERFACES. The special value all starts one
# ifplugd for all interfaces being present.
INTERFACES="eth0"
HOTPLUG_INTERFACES="wlan0"
ARGS="-q -f -u0 -d10 -w -I"
SUSPEND_ACTION="stop"

Multihop problems with RPL router

I tested Linux RPL router with two Atmel AVR Raven nodes running recent Contiki OS. I noticed that when both nodes are connected directly to router everything worked fine. But when one Raven was connected to the router through the other Raven, the router wasn't able to ping the non-adjacent Raven. I expected that the problem was caused by missing support for RPL option for IPv6 Hop-by-Hop header in Linux RPL router. This option is critical - if receiving node doesn't understand the RPL option, it drops the entire packet. By default Contiki nodes insert RPL option to IPv6 Hop-by-Hop header to forwarded packets only - that explains why adjacent nodes could communicate.

Dummy RPL option handler

I decided to try adding dummy RPL option handler, and check if router starts accepting packets with RPL option for IPv6 Hop-by-Hop header. I added commit to my feature-rpl branch. I repeated tests with Contiki Raven nodes. This time I could ping nodes two hops away without problems. Yay!!!

Dummy RPL option handler is not a perfect solution - contents of RPL option are ignored, and it's not compliant with RFC6550. However for a simple operation as a DODAG root, dummy handler should be sufficient for testing purposes. DODAG root can't be a part of a routing loop in normal circumstances (it has no parrents), so skipping RPL option should be safe. Contiki nodes currently accept packets with no RPL option in IPv6 header.

Conclusions
The above paragraph presents a quick hack that overcomes the biggest limitation of current RPL Linux router - lack of multihop operation. There are other problems with implementation: rpl-ctl command doesn't produce useful output, and quantity of DIO packets sent is highly suspicious.Maciekhttp://email@example.comŚwidnik, Polska51.2168207 22.69142720000002151.1372527 22.530065700000019 51.2963887 22.852788700000023tag:blogger.com,1999:blog-4110028886767234394.post-33415030574813333052014-11-16T15:56:00.001+01:002016-03-20T09:18:56.885+01:00Linux RPL router
Recently there have been huge developments in Linux 6LoWPAN support. Old linux-zigbee was renamed to more appropriate linux-wpan. Openlabs released an excellent tutorial on running 6LoWPAN on RaspberryPi. With it you can get running 6LoWPAN Border Router, even if you never compiled Linux kernel before. Openlabs also released 802.15.4 module for RaspberryPi - it is very reasonably priced, works as advertised, and is currently best choice to quickly start development. Delivery with USPS seems fast too (12 days to Poland, Europe in my case).

Following my previous experiments with Grinch Border Router, I decided to try to take it one step further, and run RPL routing protocol on top of RaspberryPi with 6LoWPAN. My results below.
Linux branch

Following Openlabs advice, I decided to go with linux-wpan-next branch. I had one problem running this branch on RaspberryPi - Ethernet stopped working. I found solution on elinux.org - the bug was caused by missing USB config directives in kernel. Take extra care to enable both CONFIG_USB_DWC2_HOST and CONFIG_USB_DWC2_PLATFORM in your kernel config.

Fixing RPL implementation

After checking the Internet for existing Linux RPL implementations, I found three feasible candidates:

Unstrung

SimpleRPL

linux-rpl

After preliminary testing, I decided to go with linux-rpl, as it is a kernelspace implementation. Repository for linux-rpl contains code in a form of huge patches for Linux kernel 3.10, 3.11 and 3.12. After a few unsuccessful atempts to merge them I ported the 3.12 patch into linux-wpan-next branch manually. I left out patches related to XBee. My patched branch is available on Github

To run RPL you should clone my branch and then basically follow Openlabs tutorial:

Run make menuconfig and enable proper kernel options (remember to enable CONFIG_IPV6_RPL and CONFIG_IPV6_RPL_OF_OF0 and USB options mentioned above)

Build patched kernel

Patch the device tree to add AT86RF233 transceiver and rebuild .dtb file

Build U-Boot

Move kernel, device tree file and U-Boot to the SD card with new Raspbian installation

Boot up Raspberry and log-in using SSH (or keyboard/screen)

Build userspace lowpan tools

Configure wpan0 and lowpan0 interfaces

The steps above should give you working RaspberryPi with eth0 and lowpan0 interfaces.

Running RPL

First thing to do is to compile RPL userspace tools. Then you can enable RPL on chosen interface: for example lowpan0. You can run your RPi as a non-root RPL router. It will then search for a DODAG to join. To do that issue command:

sudo rpl-ctl enable lowpan0

You can also use sysctl:

sudo sysctl -w net.ipv6.conf.lowpan0.rpl_enabled=1

In most cases you will want your RPi to be DODAG root (it is useful when you plan to use your RPi to be a border router). As a DODAG root, your RPi will distribute address prefix for other RPL routers. To do that issue commands:

sudo sysctl -w net.ipv6.conf.lowpan0.rpl_dodag_root=1

sudo sysctl -w net.ipv6.conf.lowpan0.rpl_enabled=1

After that your RaspberryPi is be ready to communicate with RPL nodes. If you want to use your RPi as a Border Router there are other steps to take: enabling IPv6 forwarding, configuring IP address on eth0 interface, running radvd on eth0 interface, etc.
Communication with Contiki nodes

To determine which links should be used as a first choice, RPL protocol uses objective function (OF). All RPL nodes in a DODAG must use the same OF. The most basic objective function is OF0, and it is the only OF supported currently by Linux. Contiki OS 2.7 uses MRHOF objective function by default, but it supports OF0 too. To achieve communication between RaspberryPi with RPL, and Contiki, you need to compile Contiki with RPL using OF0 function. To do that add following line in your platform contiki-conf.h file:

#define RPL_CONF_OF rpl_of0

Remove other OF definitions if present. With this modification, your Contiki nodes should join DODAG formed by RaspberryPi.
Possible issues

I haven't throughly tested this setup, so bugs can be expected. Few remarks:

(Edit: 01 Feb 2015) Multihop doesn't work - probable cause is lack of hop-by-hop RPL option support

RPL userspace tools info commands (for example rpl-ctl list-neighbors) usually return nothing, it might be a bug

I noticed nodes are slow to rejoin DODAG after restart.

Further tests are necessary.

Conclusions

RPL for Linux is usable. Joao Pedro Taveira's implementation seems to work with Linux 3.17 and 6LoWPAN (after minimal patching). This is very surprising, that implementation is no longer developed. Linux box is a superior solution for Border Router than any embedded system. Open Source's inefficiency is sometimes amazing.
Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-80471424041433254782014-09-04T13:37:00.000+02:002016-03-20T09:19:11.556+01:00txThings improvements and newsI updated my txThings library and made some improvements:

1. txThings is now a proper Python package. It is available on PyPI. You can install txThings on most Python environments using command:

easy_install txthings

or

pip install txthings

These commands should automatically install txThings dependencies too - currently it's only Twisted. On Linux you need root privileges (sudo). You can also specify txThings as a dependency for your own application.

2. I added an example for Resource Directory. Resource Directory is based on draft-ietf-core-resource-directory-01 (it's already outdated but changes shouldn't be dramatic).

Also Christian Amsüss recently ported txThings to Python 3 and asyncio. Asyncio is a new Python 3 module, backed by Guido himself. It's an effort to partially unify many different Python asynchronous frameworks (make them run on a common event loop). I support this idea - it's Python's only chance against node.js. Twisted is actively being ported to Python 3 and is going to have bindings for asyncio, so one day it might be possible to just run the code and not worry about compatibility. Christian's library is called aiocoap. If you plan to develop apps for Python 3, you should strongly consider using aiocoap.Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-35310600124972155452014-03-08T13:35:00.000+01:002014-03-08T13:35:53.551+01:00Aneska - simple CoAP browser for AndroidWhen I started working on txThings CoAP library I needed to create some GUI tools for testing - simple client and server. I checked the existing Python GUI libraries and I wasn't really satisfied with the results of my search. GUI programming in Python is very fragmented, there are over 40 libraries, and it's hard to make an informed choice. I've finally decided to try Kivy framework - its webpage seemed nice. Kivy is a modern framework, with strong focus on multiple platform and touch screen support. It has some nice features:

runs on Windows, Linux and Android (with Python for Android)
looks more or less the same on each platform
supports Twisted integration
supports many touchscreen features like swiping, scrolling etc.
At first I wanted to create a very simple tool for testing txThings library on Linux and Windows, but out of curiosity I tried packaging the app for Android . The tutorial was well written, and everything went very smooth - after around 4 hours I had first working Android app. I was really amazed by the simplicity of the process. I decided to work a bit more on it, and gradually I got a very basic CoAP browser. It was quite usable, but not very polished. Then I took a decision to finish the job, and release the simple CoAP browser to the Play store.
GUI development

Kivy is a very nice framework, but many parts of it are still quite immature. Kivy uses its own Kv language to describe the layout. It works fine with simple widgets like buttons and labels. But many complex widgets like treeviews, spinners etc. are in reality compounds of simpler widgets. It is sometimes hard to access the properties of these "inner" widgets using Kv language. Occasionally it's necessary to overload existing widgets to achieve desired effects. Many times I had to browse the source code of some widgets to get things done (luckily after two years of dealing with Contiki OS, reading Python source code is a piece of cake :) ). On the other hand, some complicated stuff was very easy to achieve using Kivy - like swipe-to-close browsing cards, and animated screen transitions.

After finishing the communications layer and the GUI I decided to implement also some simple parser for RFC 6690 CoRE Link Format. I used link_header library from Asplake. I also added simple bookmarks support. After that I added icon and splash screen, and started working on the visuals. I discovered that designing a decent GUI for a mobile app is not that easy :) - maybe using a combination of blue and orange wasn't the best choice ;).

Double-stack support

Big problem in making the browser was IPv4/IPv6 double stack operation. CoAP is meant to be used mostly with IPv6, but it's adoption is still not very wide. IPv4 support is simply a must. Linux (and Android) IPv6 UDP sockets can send and receive IPv4 packets, provided that the address is passed as IPv4-mapped IPv6 address (::ffff:X.X.X.X). That doesn't work on Windows (bug in Windows Python 2.7 code). Another thing was the DNS support. I had no idea how to tackle that problem, but at the end of 2013, new version 13.2 of Twisted framework was released, that supported RFC 6555 "Happy Eyeballs" algorithm. This algorithm was designed for TCP-based, human-operated client apps, however I managed to adapt it to work with UDP-based application. I had to change some parts of txThings blockwise code to allow for callbacks after every block (this can be useful later to implement progress bars for blockwise transfers). Currently the "Happy Eyeballs" works fine with normal and blockwise requests. I'm not entirely sure about observe requests - the algorithm will accept the first response and send RST to all subsequent responses, but if the response is NON it might not always cancel the observation. Proactive observe cancellation is being discussed by IETF right now, so maybe it will solve the problem.

Conclusions:

The resulting application is more proof of concept than a perfect solution. Unfortunately the application starts quite slow on Android (around 2 seconds on my SGS3), probably because of Python interpreter. The download is rather big, because it's bundled with Python and its extensions. However the app does its job, runs on Linux and Windows, and at the time of writing it's the only CoAP browser for Android so it might be useful for researchers and testers. I used it successfully with CoAP test servers:

TZI Universitat Bremen: coap://coap.me
ETH Zurich: coap://vs0.inf.ethz.ch

I am planning to setup my own test server based on txThings and twistd.

Link to the app below:

Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-24268587090853796552013-10-13T21:00:00.004+02:002013-10-13T21:00:59.917+02:00Makers - how to win the IoT standards battleInternet of Things as a bussiness area is currently in a very interesting phase. There are multiple competing standards in both hardware and software. Last year it became obvious, that WiFi is going to be the most important hardware standard, complemented by more specialized standards in some areas (personally I would bet on Dash7 for ultra-low power and energy harvesting apps, and maybe BLE for smartphone apps). WiFi also secures IP domination in the network layer. However at transport layer and above the winner is not yet clear. There are standards like XMPP, MQTT and CoAP which are backed by serious industry players.

Meanwhile there are other interesting technological developments going on. One of the most interesting is the "Maker" culture - a community of programmers, engineers, hobbyists and professionals, who deploy new technologies in unique and inventive ways. Maker community is the rebranding of old DIY culture, but thanks to the Internet it is much more powerful.

I would like to propose a hypothesis: the Internet of Things standard widely accepted by "Arduino/RaspberryPi Maker Community" will become the leading IoT standard for the whole industry. My points:
1) IoT is often described as a solution waiting for a problem. Makers usually solve real-world problems, so it's a good test for a fledgling standard.
2) Maker community is a reservoir of creativity. Makers are developers of low-cost, or free solutions - an equivalent of an "app store for hardware".
3) Makers usually choose technologies which are well-supported, and easy but also powerful. With mass adoption, limits like bad documentation and technological weaknesses become obvious very fast.

It seems that big IoT players aren't doing much to attract Makers to their respective solutions. I think it is going to change in the next couple of months. First one who is able to convince Makers to their solution wins :)Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-43777849839451707362013-09-19T22:54:00.001+02:002016-03-20T09:20:16.606+01:00txThings - "Good enough" is good enough
Long time no see! Last update here was posted more than a year ago. There are multiple reasons for that, but the most important one is that I decided to pause embedded development for a while, and learn more about application layer, and user applications. For a start I decided to write a library for CoAP - new protocol for Internet of Things. I also decided to write it in Python, using Twisted framework. The development has been quite slow, but last month I accidentaly found pyvideo.org site with various Python related videos, and found a brilliant talk by Alex Martelli : "Good enough is good enough"

After watching the video, I decided to quickly finish the work on current features, and release the first version of library, with some features completed, and some missing. I hope to get some feedback from users, so that I can improve the library.

txThings - CoAP Python library
I've decided to call the library txThings - Twisted has a tradition of calling modules with plural nouns (also Coap LIbrary for Twisted gave really bad acronym ;) ).

txThings has the following features:

support for draft-ietf-core-coap-13 - including automatic piggyback/separate response handling. No caching support.

support for draft-ietf-core-block-12 (no support for server initiative though - waiting for the resolution)

limited support for RFC6690 (Core Link Format) - server only.
Other nice things:

txThings works nicely on RaspberryPi

txThings is compatible with Kivy - brilliant new Python GUI library (I'll post some examples soon).

txThings is fully asynchronous (thanks to twisted framework)

txThings installation HowTo
txThings is posted on Github. The easiest way to get it is to clone the repository to your local machine using the command below:
git clone git://github.com/mwasilak/txThings.git
Library contains CoAP code (inside "iot" directory) and three examples:

server.py - CoAP server that starts on localhost, port 5683 and hosts several resources

client_GET.py - example client which performs GET request to localhost, port 5683

client_PUT.py - example client which performs PUT request to localhost, port 5683
Client_GET and client_PUT both use port 61616 - to use them simultaneously change port number in one of the clients. Server will send blockwise responses for default settings. To use txThings you need Python 2.7 with Twisted installed (I suggest using the latest Twisted version, but older releases also work - tested with 11.1).
Current work
Next step is to add Observe and full Core Link Format support to txThings. I am also planning to continue investigating Kivy library.

If you are interested in using txThings and have any questions, don't hesitate to contact me.Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-87626381229072526322012-05-25T22:11:00.000+02:002012-05-25T22:11:54.991+02:00World IPv6 Launch DayJune 6th, 2012 is World IPv6 Launch Day - a worldwide event for Internet providers, website owners and institutions. Every organisation is invited to participate - to join the event it needs to enable IPv6 for its products, websites and users.

The event is supposed to promote IPv6 transition, and hopefully, to start a chain reaction. I think that everything has been already said about IPv6 and its adoption process, but I'll repeat once more, that it has to be done. The sooner the better. There are many technologies waiting just around the corner, which can be developed only with larger address pool and end-to-end connectivity provided by IPv6.

The action has a very nice badge and catchphrase, but it doesn't describe the titanic amount of work that has to be done by network engineers, webmasters, programmers, and help-desk employees. The costs of this transition might be enormous. But still it has to be done.

Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-9053964303995210032011-11-17T21:54:00.000+01:002016-03-20T09:20:42.770+01:00Grinch Border Router - routing in LAN environments
Recently I've made some tests how to connect to 6LoWPAN nodes in home LAN environment, using ordinary PCs. I've been using Grinch Border Router described in previous entries. The main aim was to use no static routes to send traffic to wireless nodes - I've tried to use only Router Discovery.

In general, avoiding manual configuration of networks is a hot topic nowadays - not only in Wireless Sensor Networks. There are many problems to solve:

Prefix delegation

Service discovery

Interaction with sleeping or mobile nodes

The problems above are also present for the home LANs. The basic RFC4861 Neighbor Discovery is quite limited and it's hard to achieve a fully functional LAN with Internet connection using only that (without DHCP). However most new solutions are not supported by common everyday devices found in LANs (like PCs or smartphones). Grinch Border Router is no exception to that - it is a very basic device, and with 8kb of RAM it is not capable of any complicated techniques.

LAN physical setup

I've assembled a simple Home LAN as a testbed. Physical setup of the testbed is shown on a picture below - as you can see it is not very realistic (for a typical household) - as it includes a separate switch and wireless router - I'll explain that below:

The testbed contains two PCs, D-Link 5-port switch, Grinch Border Router, Atmel Raven board and a D-Link DIR-600 wireless router. Test LAN is based entirely on the switch. The wireless router is used only for IPv6 tunnel. At the beginning I planned to use the router for my LAN instead of switch (it would be a more realistic setup). However I decided to add a separate switch because of two reasons:

IPv4 traffic - wireless router is used for my primary IPv4 internet connection - and Grinch has no hardware packet filtering.

D-Link DIR-600 has some undocumented IPv6 ability. In theory it's IPv4 only, but it sends Router Advertisements, and I was concerned that it would disturb the experiment.

LAN logical setup

Logical setup of the testbed is shown on a picture below - it is much more realistic than the physical one:

LAN contains one host (one of the laptops) and two routers - one connected to the IPv6 Internet and one connected to Wireless Sensor Network. On the WSN side there is a single node with HTTP webserver (Raven) and RPL is used for routing. For the IPv6 Internet connection Freenet6 GoGo Client is used - I have no public IP therefore normal tunnel won't work. Through GoGo client /56 prefix is received. LAN uses the first /64 subnet in the prefix, WSN uses the second one.

Problem formulation

When aiming for a zero-configuration connection to WSN nodes in home LAN, one of the main problems is choosing the right router for outgoing transmissions. In LAN like above, a host gets Router Advertisements from both WSN and Internet routers, and saves their addresses in Default Router List. When IPv6-enabled host has more than one router in its Default Router List, it selects the router for outgoing traffic in round-robin fashion (RFC4861). In typical IPv6 operation it's not a problem - if host chooses non-optimal router, the router sends a Redirect message to the host. Redirect tells the host to use other router for that particular destination. Host saves this information in its Destination Cache and next time it sends the traffic to the correct router. Routers need to know about each other and about accessible routes to send Redirects. Normally routers use some kind of dynamic routing protocol to inform each other about known routes (e.g., RIPng).

Contiki OS (used by Grinch border router) doesn't support redirects, or any typical routing protocols. It's not a big technical problem, as the simplest routing protocol - RIPng can be certainly operated by a router like Grinch (maybe with 16kb of RAM). However it's not the only problem. Typical IPv4 home routers don't support any kind of routing protocol - they are simple gateways which send traffic to a default route. There are no "typical IPv6 home routers" on the market yet - only "IPv6 enabled routers", but existing guidelines for home routers don't contain routing protocol support as a mandatory functionality (RFC6024). Windows operating system also doesn't support any dynamic routing protocols in Home Edition. At the moment probably the only IPv6 home router solution with RIPng support are special OpenWRT and DD-WRT builds. It might in a couple of years lead to a situation where Internet of Things home deployment is hampered by lack of proper router functionality.

Partial solution - Route Information Options
I've decided to look for another solution and found a nice candidate. RFC4191 contains an extension of original Neighbor Discovery which allows adding Route Information Option to Router Advertisements. Router can use this option to inform hosts on a network about routes it knows about. However the router should not use Route Information Option to send its whole routing table to all hosts - it should only advertise specific, important routes. The WSN border router is exactly such case - it should include the route to the WSN in its RAs.

Advantages:

doesn't require any configuration on hosts

allows hosts to send traffic to the best router straight away, without waiting for a redirect.

no need for a dynamic routing protocol

Disadvantages

doesn't provide WSN-to-Internet connectivity (for that routing protocol is required)

not supported in most systems (see below)

Route Information Options for Grinch

Adding RFC4191 support to Grinch was quite trivial - the router only has to send Router Advertisements with an additional bit flag, and Route Information Option. The implementation is compatible with multiple interfaces extension added to Grinch earlier. I've added another structure that holds all information necessary for RIOs (uip_ds6_route_info). Because of that the code is not very well optimized for RAM usage. It is possible to implement a more efficient approach, that would use pointers to prefixes held in Prefix Table or Routing Table, but Routing Table doesn't contain lifetime necessary for the RIO, so still some kind of additional structure is necessary. Other solution is to change Contiki Routing Table to contain route lifetime - it's used by RPL anyway.

Modified code is available in Git repository::

RIO tests

I've run some tests with RFC4191 enabled Grinch. The border router was set to send Router Advertisements with Prefix Information Option containing LAN prefix, and Route Information Option containing WSN prefix. The LAN prefix was also advertised by the laptop running freenet6 client ("Internet router"). Grinch was tested with four kinds of devices - results below:

Laptop with Windows XP - IPv6 has to be enabled on the laptop before any experiments. Laptop receives modified Router Advertisements from Grinch correctly and adds a route to WSN to its routing table. It's immediately possible to ping Raven board after that. However Windows XP doesn't support IPv6 DNS, so it's impossible to connect to ipv6.google.com even after adding DNS server manually. Fail.

Laptop with Ubuntu 11.04 - Internet connectivity works after adding DNS manually. However there is no RFC4191 support in Ubuntu. Fail.
Update (April 3, 2012)
Ubuntu 11.10 has RFC4191 support in default build. Route Information Option support is disabled by default. To enable it you need to add two lines to your /etc/sysctl.conf:

net.ipv6.conf.eth0.accept_ra=1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 64

Android 2.2 - for that test I modified the LAN physical setup, and used wireless router instead of switch. Then I connected the phone to WLAN using WiFi. My phone received IPv6 address but it had no applications that could use IPv6 - even ping!!! Also it didn't support RFC4191. Android really needs better IPv6 support. Fail.

 Laptop with Windows 7 - Internet connectivity works after adding DNS manually. Also laptop receives Router Advertisements with RIO from Grinch correctly and adds a route to WSN to its routing table. However the network is not very stable - pings are sometimes lost for no reason.

Further tests with Windows 7

After playing with the network a bit more I've determined that two more details in Grinch software had to be changed:

Neighbor Advertisement Router Flag - in Grinch NAs it was set to zero (default for Contiki). That caused the laptop to remove all entries related to Grinch from the Routing Table. It caused periodic "flapping" of the routing table - sometimes pings worked, and a while later they didn't. After changing the Router Flag to 1, the flapping behavior disappeared.

Router Advertisement Router Lifetime - any non-zero value made Grinch to be added to Default Router List on the laptop. It sometimes caused the Internet traffic to be directed to Grinch (with no Redirect ability). This could totally break down Internet connectivity for the laptop. After changing Router Lifetime in Grinch RAs to zero, it is no longer considered a candidate for a Default Router, but Route Information Options still work.

With these changes the solution can be considered successful - I've tested it with my wife's new Windows 7 laptop (with vanilla OS), and it connected to Raven without any problems. Connection to ipv6.google.com required manual DNS setup. Both changes are included in the Git code above.
Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-76282619831496241662011-09-29T19:54:00.001+02:002011-09-29T19:54:41.391+02:00Grinch Border Router - routing HTTP traffic
In my last post devoted to Grinch Border Router I described how to forward pings through the router. However the router wasn't capable of sending much more than standard size pings. It wasn't possible to route any IPv6 packet larger than 152 bytes. I blamed it on Zigbit's limited memory, and decided to get a new module with Atmega128RFA1.

However in the meantime I had some problems with my DSLR and decided to try, and repair it myself. I failed miserably and damaged the power board of the camera, and had to send it to the professionaI support. I had to pay for the new power board, and had no cash for the RFA1 modules, so I decided to work on the Zigbit a little bit more :) . It quickly turned out, that Zigbit has enough memory for everything. I just had to turn off the webserver, and I managed to fit the full 1280-byte buffer for the packets. I also had to correct some bugs:

Debug comments - debug comments in AVR can be put either into flash memory, or RAM memory. RAM is faster, but very limited, so I was using primarily flash comments. This significantly slowed down the microcontroller, so that it was not possible to send 6lowpan fragmented packets. After turning off all debug comments the border has enough processing power to forward packets that need fragmentation.

ENC28J60 driver bug - the driver has a config parameter MAX_FRAMELEN which limits maximum packet size. In my first build it was set to 500 bytes. It made HTTP communication impossible.

In my first build the interrupts were turned off when receiving packets from ENC28J60. I changed it to turn off interrupts also when sending packets. The stability of the Grinch Border Router increased greatly (works for several hours without freezing).

After these changes the Grinch has become quite usable as a border router. It is possible to access Raven webserver from the PC almost every time. Also large 1232 byte pings are forwarded without problems. The router is still not ready for the deployment, but it's perfectly ready for testing of wireless sensor networks.

Next thing to do is the automatic discovery of Grinch in the network. For that Router Advertisements are needed. I still haven't modified this part of Contiki to support multiple interfaces, but it shouldn't be hard. I also plan to run some long tests of the router to see how stable it is.
Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-43644421903767383352011-06-08T21:33:00.035+02:002016-03-20T09:21:23.260+01:00Grinch - simple 6lowpan RPL border routerThe biggest advantage of IP based Wireless Sensor Networks is their ability to be seamlessly connected to the Internet. A device which passes data from the lowpan to ordinary network is called a "border router". Such a device must support at least two network interfaces: 802.15.4 for the lowpan, and 802.3 or 802.11 for the uplink.

Contiki OS does not currently support multiple interfaces, but it is possible to deploy a border router on Contiki with serial interface for uplink. Depending on the hardware platform it can be done in two ways: either with special software called tunslip6, or with RNDIS device driver. Both solutions need a running PC with Linux or Windows, which makes them inconvenient for simple home automation solutions.

Because of that I decided to develop a simple border router with Ethernet interface. After asking on Contiki mailing list I discovered that nobody is actively working on a multiple interfaces support, so I decided to add it myself. First results of ping tests are presented below - I wrote a simple tutorial in a spirit of Contiki Atmel Raven Tutorial.
Hardware
I assembled a quick prototype board with 15.4 and Ethernet interfaces. I called it "Grinch" (I did most of the soldering during last Christmas). The board is based on the Zigbit module. Zigbits contain Atmega 1281 microcontroller and AT86RF230 radio transceiver that communicate over SPI. For Ethernet I chose Microchip ENC28J60, very simple Ethernet controller with SPI interface.

Last year I designed and ordered some breakout boards for the Zigbits with goldpin connectors, and ENC28J60 is sold in DIP packages, so I chose not to use any SMD components in my project. I used simple prototype board with greenwire connections. I soldered the components ad-hoc without a schematic, but later I made some simple drawing in Eagle to document the project (link). Below is the photo of the board.  Zigbit has a serious drawback - it has only 8kb of RAM, and it limits the number of neighbors and routes that can be maintained. Also it leaves very little room for the webserver (which is very useful for debugging). Also 6lowpan fragmentation is not possible - there is no space for buffers. For any future border router projects I strongly recommend Redwire MC13224 or Dresden Elektronik Atmega128RFA1 modules.

Working Grinch Border Router is shown on a picture below:  After assembling the board it is good to test it using some simple IPv4 AVR software unrelated to Contiki. Tuxgraphics is a very good page with test examples.
Software
The mod contains the following additions to the github contiki-mirror repo:

ENC28J60 driver for AVR microcontrollers

Multiple interfaces support
ENC28J60 driver is based on driver by Guido Socher and wrapped with a modified template from Contiki Docs - example-packet-drv.c . The only significant change from Guido's code is that first 14 bytes of every received frame are copied into the different buffer than the rest. This way no intermediate processing is necessary before submitting a packet to uip stack. ENC28J60 driver switches the interrupts off for the duration of the read - otherwise if RF230 interrupts launch during ENC read, it can crash the system for good. Contiki is a non-preemptive system, so ENC28J60 and RF230 drivers can peacefully coexist and share SPI interface - as long as interrupts are taken care of and both drivers properly set the Chip Select (CS) pin after using the interface. ENC28J60 driver works fairly well, and was tested with IPv4 and IPv6 Contiki - it can be used in projects totally unrelated to Wireless Sensor Networks. Multiple interfaces support is implemented in a very straightforward way - all interface-describing structures defined in /core/net/uip-ds6.h are changed into arrays of structures instead. All functions are modified to get along with this change. The modification is not very complicated, but code needs to be fixed in numerous places. Most code changes are located in the /core/net directory. The more serious code changes are:

Initialization - contiki-conf has to be changed to support two interfaces

Link-layer Address Option construction - Ethernet and 802.15.4 link-layer addresses have different length

Periodic processing - to keep the code simple single timer is used for all interfaces
For proper functioning of uIP stack, every function needs to operate on correct interface. This is done by a combination of these two methods:

Common functions operate on the interface, which id is saved in a uip_last_active_interface variable (current name is not very good). The value of this variable is changed whenever a packet is received or meant to be sent. For example ping reply is always sent to the interface where the request came from.

Interface specific functions operate on hardcoded interface identifiers - for example RPL packets are always sent to IF_RADIO interface, and ENC28J60 driver operates only on IF_FALLBACK interface.
This part of mod has to be considered experimental - there is no guarantee that any Contiki tools or apps will run with it (for example Cooja). Git repository with the mod is accessible at Github: firstname.lastname@example.com:mwasilak/contiki-mirror.git branch: multiple-netif
Test overview
This demo is based entirely on pings - with no application data transfer. I tried a simple test with HTTP, but it failed completely - the reason for that is probably the limited capability of Zigbit to fragment IPv6 HTTP communications (they are normally too big). I plan to use CoAP later but I have no working code for Raven yet. However the ping test can verify most of the properties of the new multiple interfaces capability.
Compiling the code
Binaries can be compiled using the following commands: cd c:/contiki-mirror/examples/webserver-ipv6-raven make cd c:/contiki-mirror/platform/avr-ravenlcd make cd c:/contiki-mirror/examples/ipv6/rpl-border-router-eth make All examples have proper Makefile.target files - there is no need to specify target from command line. Note that AVR Raven is also compiled with multiple interfaces support, but number of interfaces is set to 1. Installing the software on Raven is shown in the Contiki Atmel Raven Tutorial. Installing the software on Grinch is similar - but it is dependent on the physical layout of the board.
Addressing and Windows setup
The example uses RPL routing on the 802.15.4 side and static routes on the Ethernet side. Ethernet IPv6 prefix and RPL prefix are both hard-coded inside rpl-border-router-eth.c file. Handling of these two prefixes is different - IPv6 prefix makes the node assume, that all addresses with the same prefix are on link. Because of that, this type of prefix doesn't work well for radio links, where some nodes with a matching address can be out of range. Inside rpl-border-router-eth.c file there is a quick hack which adds the IPv6 prefix only for IF_FALLBACK interface. To run the test it's necessary to add a Global IPv6 Address for the PC Ethernet interface (otherwise pings from Raven to PC won't work), and to add a static route to Raven. Here are the necessary commands for Windows 7: First you have to find the name of the Ethernet interface on a PC. It can be checked under Network->Properties->Network connections:  As you can see on my PC there are two network interfaces - one of them is WiFi and the other one is Ethernet. The name of Ethernet interface is "Połączenie lokalne" (I have a Polish version of Windows 7 - don't worry your name will be normal :) ). Now it's good to right-click the Ethernet connection and uncheck all fields except IPv6:

Next you can close Network Properties and open Command Line as an administrator. Type: ipconfig Windows displays the information about interfaces. The result below:  As you can see, "Połączenie lokalne" has no IPv4 addresses and one IPv6 address fe80::21e:33ff:feae:63a8%11 . This is a link-local address, and it's not enough for the test. We have to add a Global IPv6 Address. We will use a prefix aaaa::/64 and host address the same like the link local interface. You can use a different address but you will have to set it in: c:/contiki-mirror/platform/avr-raven/apps/raven-lcd-interface/raven-lcd.c in a next line after #elif MULTIPLE_INTERFACES_TEST_PING_PC (otherwise you won't be able to ping PC from Raven). To add an address we will issue a command: netsh interface ipv6 add address interface="Połączenie lokalne" aaaa::21e:33ff:feae:63a8 After address is added we can use ipconfig once again to verify the address. Next we have to add a route - otherwise the PC won't know that it can reach Raven through border router. We will use a following command: netsh interface ipv6 add route interface="Połączenie lokalne" aaaa:0:0:1::/64 fe80::aa:bbff:fecc:ddee By using this command we inform our PC that to send packets to all addresses with aaaa:0:0:1::/64 prefix, it needs to send packets to a MAC address which matches the link-local address fe80::aa:bbff:fecc:ddee (it is a link-local address of the Grinch). To resolve the MAC address, PC automatically sends Neighbor Solicitation packet (it's part of IPv6 stack). The outcome of the add operation can be verified with the command: netsh interface ipv6 show route Output below:
Running the test

CMD Files
Windows command line throughly sucks. It doesn't remember previous commands like in Linux, and it's tedious to enter all the commands from keyboard each time. To speed up the testing I suggest saving individual commands in text files with .cmd extension (for example pngr.cmd), inside your user directory. This way after your command line starts up, you are in your user directory, and you just have to type the name of the file, not the full command.
Pinging the Grinch from PC
You can ping both global and link-local address of the Grinch - it should reply in both cases. Plug in the power and Ethernet cable and type: ping -6 fe80::aa:bbff:fecc:ddee ping -6 aaaa::aa:bbff:fecc:ddee My typical response time is 4ms. First ping almost always hits timeout - during this time PC performs address resolution.
Pinging the Raven from the PC
After powering the Raven up it will play some tune - funny, but not when you're coding at 2AM :) . To succesfully ping the Raven we need to know, that Grinch has an RPL route to it. The route should be established in 15-20 seconds after starting the Raven. We can check it using webserver on Grinch. Open your web browser and type in address of the Grinch, like on the picture below.  If the route exists it will be displayed on the webpage. After that you can issue a ping command: ping -6 aaaa::1:1:2:3:4 The Raven will cheerfully beep after receiving ping, so you will immediately know if you're successful. My typical response time is 17ms.
Pinging PC from the Raven
To ping the PC from the Raven we also need an RPL route to Grinch. Ping is initialized from Raven LCD menu - basically you have to click the little joystick switch twice to the right. Successful pings will also be confirmed with a beep.
Known Bugs

DAD packets for Ethernet interface are not really sent, because Ethernet link needs a second to initialize, therefore uIP always considers DAD as successful. I don't have a good idea yet how to fix this bug, but it's almost harmless. DAD for 802.15.4 are sent properly

Some comments don't include interface ID - it's not really a bug, just an inconvenience when using RS232 debug.

When Grinch Border Router is turned off and turned on again, it doesn't register a route to Raven - it is some RPL issue and not a purpose of this tutorial. Remember to power up both Grinch and Raven simultanously before running the test.
Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-77093663573914870672011-03-29T18:20:00.001+02:002011-03-29T18:20:45.247+02:00IETF Tutorial in PragueOn Saturday, March 26th, I've attended IETF Tutorial on Interconnecting Smart Objects with the Internet in Prague. Not being actively involved in any organized research I was waiting for the tutorial with much anticipation. The event comprised several lectures by the most active Internet of Things researchers. Here are some comments.

First lecture was given by Carsten Bormann, a co-author of "6LowPAN The Wireless Embedded Internet". The presentation contained many slides from that book actually. Prof. Bormann briefly explained the 6LowPAN Header Compression, Packet Fragmentation and Neighbor Discovery. These techniques are essential for running IP over 802.15.4. There are still substantial changes going on in these areas - for example early methods of Header Compression (described in the book) were obsoleted because of inability to compress global prefixes (the biggest part of the network traffic).

Second lecture was on routing in low-power and lossy networks (LLNs). It was delivered by JP Vasseur, the chair of IETF Roll group. The main topic was RPL protocol - new, specially designed protocol for routing in WSNs. The protocol looks completed at the moment, with no bigger issues to resolve. However the relationship between the RPL and normal 6LowPAN Neighbor Discovery looks very shady to me - both techniques seem to overlap in great deal. Even now Contiki RPL implementations run with ND switched off.

Third lecture, by Zach Shelby was devoted to Constrained Application Protocol. CoAP also slightly evolved since I first learned about it in Finland. For example SUBSCRIBE method was changed into an optional observation mechanism. What surprised me the most was the lack of enthusiasm of some of the participants (presumably other IETF members) about introducing a new protocol. It seems that IETF "rough consensus" is really rough sometimes.

Fourth lecture was done by Apple researcher Stuart Cheshire. He was talking about IP networks used to replace other short range connections (like USB) with no configuration necessary (service discovery performed through new technique - multicast DNS). The lecture included simple technological demo, that clearly shown Apple's philosophy in design: it worked instantly, with no user configuration.

Fifth lecture was given by Adam Dunkels from SICS. Adam explained some Contiki concepts - protothreads, and Contiki MAC, and he did it in great style. It was fascinating to listen about the operating principle of protothreads (almost as if it wasn't some high level C concept).

The last lecture was presented by Robert Cragie - ZigBee Alliance researcher. It was really interesting, as the ZigBee Alliance was recently forced (by some US energy related department) to adopt IP in its design. To accomplish that, ZigBee Alliance plans to develop new ZigBee IP "superstandard" based on 6LowPAN, RPL, and other IoT related technologies. Cragie pointed out current weaknesses of that approach - such as overlapping standards, and lots of optional parameters, that can prevent two devices from different vendors from communicating with each other. ZigBee Alliance wants to address these problems by describing exactly which standards and options to use. In my opinion, by developing a uniform IP-based communication stack ZigBee IP can become a real leader in the area in a couple of years.

The meeting was my first opportunity to see how IETF works (although the real IETF 80 meeting started on Monday). Some of the IETF members are true geeks, who remember some long lost Internet technologies, and dispute about every detail and usecase of the protocols. In today's money driven world, this organization seems strangely out of place. But I think that because of that the future of the Internet is in good hands.Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-28494289876049805732010-09-12T17:44:00.000+02:002010-09-12T17:44:45.553+02:00RoguelikeDuring last 3 years I spent some of my time trying to learn how to write a roguelike. Roguelikes are cRPG games with no graphical mode, where environment is represented with ASCII characters (for example @ is player character). I discovered my first roguelike - ADOM when I was around 13 and I have always wanted to code one. I decided to write a post about developing a roguelike, because it's a way to summarize some things (and if I won't write it down it will rot on my hard drive for infinity).

I started by reading tutorials about writing games. In general it's very hard to find a good tutorial about game writing. Game development, like any other technical activity is about layers of knowledge - you begin with some simple functions that do only one thing, but you organize them into bigger structures that can provide complicated results. Most tutorials contain only the basic steps, but tell you nothing about the upper layers. The best tutorial about game writing I found is Philip Hanna's CSC207. It's a university course, and contains many good examples, as well as the game engine written in Java. The engine is written in a very generic way. It allows you to start your own project, but it's never optimized for it - so sooner or later it forces you to write your own engine - but at that time you already know what you want and how to achieve it. Very good teaching trick Mr Hanna!

I started my game using Philip Hanna's engine. At the beginning I really liked writing in Java. It was much faster to write than in C or C++. But after a while I became fed up with it - I had to create getter/setter methods for every variable, and the code was hard to change or read. Later I learned some tricks in the Eclipse IDE which helped a lot - automated refactoring and getter/setter creators. But I still wasn't happy with it. Then I found Python.

Python is probably the best language for hobbyists out there - it's fun to use, reasonably fast (at least I think so), and with quite good support. At the beginning Python webpage scared me off because there is some new version of Python 3.0 coming out, and no library works with it. But then I realised that nobody uses it yet, and everything works with Python 2.6 (it's a risky idea to make language backward incompatible).

I decided to start with Pygame - a library which is basically a binding to SDL library written in C. I read some basic tutorials, and started to port my earlier Java code to Python - mostly that meant holding DEL button for a long, long time. Python code is much shorter and easier to read than Java code (however some things are longer - like always including "self" as the first argument to a class method).

Below is a main class of my game - its temporary nickname is Towers :) :

#File: game.py

#Author: MW

import pygame, sys,os

from pygame.locals import *

from map import Map

from input import Input

# Uncomment the lines below to enable profiling

#import profile

#import pstats

if not pygame.font: print 'Warning, fonts disabled'

if not pygame.mixer: print 'Warning, sound disabled'

class Game:

 def __init__(self,width=800,height=600):

 self._running = True

 self.screen = None

 self.screen_width = width

 self.screen_height = height

 def game_init(self):

 pygame.init()

 self.screen = pygame.display.set_mode((self.screen_width, self.screen_height))

 pygame.key.set_repeat(200,50)

 pygame.display.set_caption('Game')

 self.input = Input()

 self.map = Map(self,self.input,100,100)

 self.clock = pygame.time.Clock()

 def game_input(self):

 self.input.set_events(pygame.event.get())

 if self.input.get_event(QUIT):

 sys.exit()

 def game_update(self):

 self.map.update()

 def game_render(self):

 self.map.render()

 pygame.display.update()

 def main_loop(self):

 self.game_init()

 while True:

 self.time_passed = self.clock.tick(60)

 self.game_input()

 self.game_update()

 self.game_render()

if __name__ == "__main__":

 towers = Game()

 towers.main_loop()

 # Comment 1 line above and uncomment the lines below to enable profiling

 #profile.run('import game; towers.main_loop()', 'profile.tmp')

 #p = pstats.Stats('profile.tmp')

 #p.sort_stats('cumulative').print_stats(10)

Python allows for both object-oriented and procedure-oriented programming, but my code is rather oo-way. The object of the Game class is created in the if statement at the end of the file. After that the main_loop method is called. At first it calls game_init method and initializes Pygame objects: display and clock. It also creates input object which is a wrapping over Pygame's event module, and map object which contains the rest of the game. Then it loops infinitely through three methods: game_input, game_update and game_render. Such design separates game logic (game_update) from gathering player input and displaying the game on the screen.

So much writing and code still does nothing, but that's the beauty of the OOP - you don't need to know what's inside the object (the implementation) to write a proper code.Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-31870622092443035572010-06-13T22:45:00.005+02:002010-09-12T17:54:05.304+02:00UBI Summer SchoolLast week I attended 1st UBI Summer School in Oulu, Finland. It was organized as a part of Ubiquitous Oulu Project. Its main topic was ubiquitous and urban computing. The School comprised of six workshops. I took part in workshop E - "IP-based sensor networks" by Zach Shelby. It was the most geeky and technical workshop of all - other workshops were much more human and application oriented.

The main focus of the IP-based WSN workshop wasn't 6LoWPAN (as one could expect), but CoAP - Constrained Application Protocol. CoAP is an application protocol (ISO OSI layer 7) designed for WSN operation - it's RESTful, it features subscribe/notify mechanism and service discovery and it has a very small header. HTTP has neither of these. CoAP is still only an IETF draft, but taking into consideration the absence of open standards in the area it might really catch on.

I've got to admit that two weeks ago I didn't know what REST really was, but I like the RESTful approach very much - it's not based on some complicated messages, but rather on availability and state of resources. I find this philosophy coherent with Unix/Linux systems, where every device, or process is represented by a file in a system tree.

Other features of CoAP: subscription and discovery are even more interesting. Subscription is a must for communication with WSN nodes that are asleep most of the time. Service discovery makes application deployment for such nodes much easier - and it also makes maintenance and network expansion a lot more simple (maybe someday google will start to index your WSN nodes too :) ).

According to other participants of the UBI school the REST way is the only way for WSN (except one guy who did research into SOAP and EXI, but stupid airlines lost his luggage, and he was forced to leave the school before he could show us the results). But some of the people weren't convinced that new protocol is really necessary - people will still use old and clumsy (but more diverse and supported) protocols, and not a specialized thing like CoAP. Being more of a hardware guy I still can't present my own opinion in the area. Time will tell.Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-28914830621618095502010-05-16T12:22:00.003+02:002010-05-16T17:40:22.926+02:00Breakout boards - first testYesterday my wife went binge drinking (bachelorette party) so I finally had some time to assemble my Meshnetics breakout boards. They contain only five elements each, but assembling them is a real PITA because of the Meshnetics modules. I soldered them with normal soldering iron and used solder wick to remove any jumpers. Afer soldering I tested the boards with a multimeter set to beep. For the power supply I used two AA NiMH batteries in nice battery holder with a switch (sadly it has no place for screws). I measured the output voltage of the battery packs - it was around 2.6V for each. Meshnetics need between 1.8V and 3.6V to work properly. After assembling I connected the modules to the AVR Dragon JTAG programmer, and tried to read their signatures using AVR Studio. It worked perfectly - photo:

Breakout boards can be programmed and tested without any additional hardware, so they can be used as a very primitive WSN nodes. I didn't include any sensors and actuators on them - even LEDs or microswitches - so using them in such way would be really painful. However for a single module I can use AVR Dragon for fake I/O so it should be possible to run some software tests without designing and building target boards.

In the meantime I've also been thinking about some name for my devices. In my opinion name is a very important thing - human brain needs names to process data, and a bad name might be harmful to entire project. I'm not a native English speaker so inventing a good name is not so easy. At first I thought about "smartlets" - like smart droplets :). However it has already been taken up by Apple - from a totally different angle - smart outlets. I need to think a bit more.

Now the coffee for my wife...Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-13094380000476333322010-05-07T22:15:00.003+02:002010-05-07T22:22:26.891+02:00WSN-intro and Meshnetics breakout boardsA couple of years ago, first news about Wireless Sensor Networks started to appear on the Web. At the beginning there were scattered pieces of information, but slowly it became a recognizable and popular research direction. I really like the idea of wireless sensor networks - tiny, simple devices called "motes" with limited sensing abilities, and processing power are used to collect data about physical and social phenomenons. Single mote has very little usefulness, but a network of them can support really innovative projects. It really sparks up imagination.

The most popular standard in the WSN area nowadays is the Zigbee. It is supported by Zigbee Alliance - association of many international companies (among them Cisco, Atmel, TI and many other). However there are many other standards around - both open and proprietary. I recently became interested in 6LoWPAN - it's a collection of standards maintained by IETF - an international non-profit organization, that also maintains IP, and other Internet-related standards. 6LoWPAN makes it possible to use IP (only v6) on low-power radio links used in WSN.

After doing some research I determined that probably the easiest way to start doing some 6LoWPAN research is to use Contiki OS - operating system for embedded devices from SICS. Contiki already supports many 6LoWPAN concepts and many other are being actively developed. Contiki is available for many different platforms, but I think that MSP430-based devices are best supported. Contiki is equipped with java-based network simulator Cooja - so it's possible to start doing research without actually having any motes. I am getting ready to test that approach - I already installed Ubuntu Linux, and I hope to start some tests soon.

Regardless of the simulator I plan to do some test with real motes. For my development platform I chose Atmel/Meshnetics Zigbit ATZB-24-A2 modules. They are quite cheap, available in Poland and contain a microcontroller, a transceiver and an on-chip antenna. I found a very good French site which contains many useful comments about these modules. My first step was to design a breakout board for the Zigbit modules. Zigbits are quite difficult to solder without hot-air station. I don't have such a station, so I plan to solder the modules once and for good to these breakout boards, and connect the boards to other devices with simple pin headers. My breakout boards will also contain JTAG and power-supply connectors - so I should be able to do some simple programming and debugging only with breakout boards. Here is the picture of the finished board next to a Zigbit module:

I made some rookie mistakes with the design - I got the description printed over the pads, but in general it looks just like I wanted :) . Now I'll have to come up with an idea how to solder it right. Any suggestions?Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-24425896255464557632010-03-04T17:26:00.001+01:002010-03-04T17:28:51.681+01:00Project #1 - PCB DesignWith electronic schematic ready I created a PCB from it. The process was rather straightforward - Eagle created the PCB project automatically ("Board" button). Then I had to set my PCB size, and place all the elements on the board. I also had to use "Mirror" command on every SMD component to transfer them to the bottom side of the board - so that all the connections are on one side of the board (blue color is default for connections on the bottom).

I decided not to use autorouter, so routing was a rather lengthy process - like a huge jigsaw. At first I wanted to conform to placement and routing rules in Atmel AVR042 Note (place decoupling capacitor as close to μC as possible, etc.) and in DS1307 RTC datasheet (do not route any wires under DS1307 RTC circuit). But eventually I gave up on these precautions - I wasn't sure if they really matter with home-made PCBs. Also I lacked some Eagle skills to implement them properly (for example how to create ground planes). I'll try to learn these things next time.

One more thing to check when developing non-professional PCB is route spacing, and element pad size. Narrow routes placed near to each other may cause problems with etching. Small element pads are more prone to damage from drilling. I know no easy way to change size of pads in Eagle - probably the only way is to modify the symbol of the element.

The result is below - as you can see I already took into consideration dimensions of casing that I am going to use - that's why there is a hole in the middle.

Board file.Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-49908610025769588002010-02-01T21:17:00.001+01:002010-02-01T21:24:01.878+01:00Project #1 - circuit diagramI finished doing the circuit diagram for my thermostat. Screenshot below:

Full schematic here (for Eagle 5.6).

I eventually chose Atmega16 for my CPU. It has enough memory and processing power for my needs (at least I hope so). Power is supplied from +5V 1.2A switching-mode power supply connected to SV3. Such power supply is noisy so to stabilize input voltage I use C1 and C12 capacitors (one tantalum 10uF and one simple ceramic 100nF). Q2 crystal together with C10 and C11 caps are used to generate clock signal and SV1 is used to program Atmega in ISP mode.

On the diagram there are two ICs, which perform the functions needed by a thermostat. IC1 is DS1307, a Real-Time Clock chip. It will be used to keep track of the time flow. The other IC is DS1721, a Digital Thermometer. It will be used to monitor the temperature in the room. Both chips communicate with Atmega16 by TWI (Two-Wire Interface).

Jumpers JP3 to JP6 are necessary to connect buttons. I will put buttons on the separate board, to make it easier to attach them to the casing. JP2 is used to connect standard 2x16 LCD with Hitachi HD44780 controller. Buttons and LCD Display together form user interface of the thermostat.

I added MAX3232 to the schematic. I don't plan to use it now, but it's very easy to implement some basic communication in RS232 standard, so it might come in handy in the future. I also added SV2 jumper for 1-wire, so I'll be able to plug in additional digital thermometer later (DS1820).

Finally there is K1 - electromechanical relay. It is the only output of my thermostat, and it will be used to control the boiler. T1 transistor is protected against voltage spikes by D2 diode.Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-14292416434062418772010-01-18T20:01:00.000+01:002010-01-18T20:01:41.096+01:00Project #1 - input voltageIt seems that sometimes your experience in some subject is your worst enemy. I started drawing my schematic, and because ARM microcontrollers need +3.3V input voltage I automatically assumed that AVR need it too. So I put inside LM1117 voltage regulator and other unnecessary components. Today my colleague told me, that AVR works fine with +5V. I scrapped 50% of the schematic and started again.

Immediately I discovered that +5V circuits are cheaper than +3.3V (for example when you compare MAX232 and MAX3232). Later I found also that AVR may work faster on +5V - 16MHz. On +3.3V it may work with 8MHz only. Not that I need 16MHz anyway for my PRT (Programmable Room Thermostat).Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-18634597467553511572010-01-17T15:34:00.000+01:002010-01-17T15:34:36.601+01:00Project #1 - electronic CADTo make a simple PCB by etching, I don't need any software, or special equipment - just some good chemical solvent (for cleaning the copper) and permanent marker (for drawing connections). But it's extremely hard to make anything more complicated that way - it's a medieval-book-writing-monk type of work.

Using specialist CAD software helps a great deal. What does PCB CAD essentially do? It connects the logical design of the circuit with physical design of the PCB. First I make an electronic schematic of my circuit - using logical symbols like resistors, capacitors, ICs and connectors. Every time I need to use a part I open part database, choose a suitable element, and place its symbol onto the schematic. Then I connect the parts using wires (lines). When I'm done, I click "PCB Design", and the program opens another window, where once again I place symbols of my components. But this time I place physical parts - with proper dimensions, pinouts and packages - the program automatically assigns physical symbol to every logical symbol. After that I route wires between the symbols and it's done. Optionally I may generate CAM files used to manufacture my PCB on CNC machine.

There are many free PCB CAD programs on the web. These are often connected to some big part suppliers. This is probably the most complete list available. For my project I chose a program called Eagle by German company CADSoft. It's free for hobbyists, and has some limitations, but they are not important in small projects. Eagle was fully independent software some time ago, but it has been purchased by Farnell - big part supplier. I expect some new version of Eagle with integrated Farnell part base to appear. However Farnell is quite expensive when buying small quantities of parts (ex. single ICs), so a hobbyist like myself won't be using this kind of integration much. It's quite sad, because integrated part base would make my life much easier. Maybe in a country like US people may put any part they want into their projects, but here in PL I have to carefully check availability of every part. Otherwise I'll either wait 2 months to get it, or pay 2 times the price, sometimes both.

About Eagle - it has some pros and cons - I'll describe them briefly:
(+)

 Has decent database (I usually find what I'm looking for) and user-made libraries

 Easy to use (it has a command line for hard-core users)

 Many resources on the web

(-)

 Pathethic database searching (it's 2010 now, everybody has autocompletion and search-as-you-type in their programs, and here I have to type name in little window and press Enter)

 Shortcut - not Windows compatible

 Tediousness - for example as a hobbyist I want electrical pads in my projects a bit larger than default - I don't know how to achieve it without modifying every single symbol

With this post I finished the introduction to my project. The information contained here is obvious for most people, but I felt that it's necessary to describe it, as it's part of the project too. With the next post I hope to move on to some technical details.Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-49043992709845010482010-01-10T20:52:00.000+01:002010-01-10T20:52:40.732+01:00Project #1 - choosing microcontrollerIn every project there are some decisions to make at the beginning which influence all further steps. In small embedded project probably the most important choice is about the microcontroller. At first I wanted to use ARM microcontroller, more specifically Atmel SAM7X. I have experience in programming these μCs in C, they are reliable, powerful, not very expensive, and you don't need any external programmer to program them (thanks to SAM-BA). I have a minimodule based on SAM7X256 I bought to play with it, but never made anything useful of it, so I thought I'd put it into the thermostat. But on Friday evening I checked everything up once again, and I totally changed my mind. Atmel SAM7X256 is at least 20 times too powerful for a simple project like mine - it would be stupid to waste it to click a relay two times a day.

My natural second choice was Atmel AVR. These μCs are extremely popular in PL among hobbyists. Professionals also widely use them - in commercial applications engineers usually have to cut their costs and use reliable solutions. There are tons of code and resources for AVR on the web, and also official application notes on Atmel's webpage. I did one little project with AVR Atmega8 about six years ago - it was a basic mobile robot. I used very cheap LPT programmer, and coded robot behaviour in BASCOM - simple BASIC-like language for beginners. Nowadays LPT port is quite uncommon. Luckily I have an ISP programmer, which I bought to play with some other stuff, but never made anything useful of it (there seems to be some pattern here). I'm also not going to use BASCOM anymore - I feel that C has the right power to ease of use ratio for me.

After choosing μC I decided that I'll be making my circuit board from scratch by etching. I always did my circuits on protoboards using greenwire (kynar) to make point-to-point connections. It's great for prototyping, but it's slower and less reliable. Using a protoboard is also bad psychologically - I want to finish my thermostat fast, not prototype it forever.

The next step is to choose some CAD software for PCB design, and get to some real work.Maciekhttp://firstname.lastname@example.com:blogger.com,1999:blog-4110028886767234394.post-85924105039105880202010-01-05T22:12:00.000+01:002010-01-05T22:12:07.923+01:00Project #1 - controlling the boilerAt the beginning of the project I need to make some important decisions how to build the thermostat, and what components to use. The first problem is how to control the boiler. I checked the manual of my boiler, and I found a schematic (version in Spanish, but quite obvious):

On the schematic there is a jumper P1 which connects terminals 6 and 9. The boiler was supplied with the jumper in place. Removing the jumper turns off the heating circuit of the combi-boiler, even if heating is enabled on control panel (and domestic water works normally). That's very good news, because the only thing I need to do is to replace the P1 jumper with a relay, and I don't have to care about electrical compatibility of my thermostat and the boiler. Well I just have to choose a relay big enough for the voltage and current present in the circuit.

I measured the voltage between terminals 6 and 9, and my ancient multimeter shows 28V. Quite strange value, but it doesn't matter - 125V or 250V relay will work perfectly.Maciekhttp://email@example.com:blogger.com,1999:blog-4110028886767234394.post-4491933152551267492010-01-02T18:41:00.001+01:002010-01-02T18:43:40.709+01:00Project #1 - programmable thermostatMy first project is a programmable thermostat for a boiler mounted in my apartment. In a town where I live there is a small CHP power station (combined heat and power). It was built long ago to support the industry with hot water for technical processes, and actually generates very little electricity (6MW in winter, during other seasons even less). The station supplies almost all apartment and commercial buildings in the area with hot water for heating and washing purposes. My building is probably the only exception. Such solution is both blessing and curse, as it gives me better control over heating, but is not forgiving of any mistakes ($$$).

The boiler is 24kW Nike Mini from Italian company Immergas, not the latest model, but still quite new. It is a combi-boiler - it produces hot water for both heating and domestic uses. The boiler can be set to provide domestic water only, or both heating and domestic water. Domestic water flows through heat exchanger and then directly to taps. Water for heating flows in a closed circuit and it's moved by electrical pump. The temperature of the heating water is measured by a sensor, and when it's too low, the boiler ignites itself and works for some time (it's either fixed time or until the temperature raises to acceptable value - I don't know).

The problem is that the boiler doesn't measure the temperature inside the apartment, so it doesn't switch off even if the temperature reaches preferred value. It also has no means of time-related programming, so it runs all the time, even when nobody's home. That's why the programmable thermostat is necessary. This device switches the boiler on only when the current temperature in the apartment (precisely in one of the rooms) is lower than value set in thermostat's memory.

Of course Immergas sells all kinds of thermostats for its boilers. Small electronic companies and workshops also sell thermostats which can easily be adapted to control my boiler. But by making it I hope to learn some new skills and test some solutions which might be useful later.Maciekhttp://firstname.lastname@example.com

subset: commoncrawl


text:
20 item limit in trademark alert collections too restrictive
Users with 20 or less matters have little need for these. I have over a thousand and I operate just a one-man firm. 50 collections of twenty items each is too cumbersome to be of practical use.
19 up votes
1 down votes


text:
The BB series truck toolboxes are engineered for full size trucks. This bed box has weather tight storage that allows for optimal usage of your truck bed. The BB Series fits between the wheel wells of the truck bed and spans from headboard to tailgate. This truck toolbox is ideal for sportsmen, property maintenance trucks, contractors, campers and tradesmen, to transport and store valuable tools, equipment, fishing rods, and skis and to safely store guns and ammo. The height of the toolbox allows you full use of the width of the truck bed. You are no longer restricted by the width between the wheel wells. In you truck bed the BB Series safely secures your valuables out of sight of any would be thieves.
Load your BB Series box full of stuff. It can take it. The rugged design of the truck box can carry the entire payload of the truck, centered on a skid. The full-length drawers slide on Teflon. Arrange, sort and store tools, equipment, and parts with the available dividers. The drawers seal for a tight fit weather proof fit with the locking compression T handles. You can even pressure wash it and not worry about water intrusion. The lock integrated in the handle secures your equipment and allows you to padlock the "T" in the closed position. Any would be thieves will not even be able to get his hands on the handle. The BB series truck bed box can even help prevent back injuries. The raised platform that the bed box provides allow for easier and safer loading and unloading of anything you put in your truck bed.
The BB series truck bed box is constructed of 1/8 diamond tread aluminum. It can handle a full 1000lbs of weight on a 4 skid. The tread plate looks great and helps keep loads from sliding and shifting. The drawers are .080 inch aluminum and the welded seams of the drawers and compression sealing drawer keep this bed box watertight. The locks, and slides are warranted for 10 years. The Bed Box is mounted and secured with aluminum clips to either the vehicle bed or headboard, through a bed liner, or directly to the truck.


text:
We love everything books, library and grammar themed at Fly Paper Products! This is one of our best selling coffee mugs, made into a stylish book bag!
We make EVERYTHING in our Ann Arbor, Michigan studios. Each tote bag is hand pressed so the colors may vary on each one. Each tote bag has a custom made 'distressed' look due to the heavy weight cotton material.
-Made from heavy weight 12 oz. cotton canvas with black web handles and a gusseted bottom.
-Reinforced at stress points.
-Bag measures 15"Wide x 15"High x 3"Deep
We ship USPS primarily because of the low cost and efficiency. If you prefer UPS or FedEx, please contact us for a quote.
Just a reminder, when buying several items the shipping charges can add up fast, but many times beyond what the actual shipping charges would be. Don't worry...WE REFUND ALL SHIPPING OVERAGES!
But please contact me if you have any problems with your order.


text:
Beloit: 608-365-6771
Wausau: 715-675-6771
Call us today
Laser therapy uses light rays to penetrate and heal damaged tissue and restore it to normal function. Our lasers decrease inflammation, increase circulation, and regenerate cartilage and soft tissue. The treatment is completely painless, and is especially useful for patients who don't like needles. We have worked with laser companies and engineers to develop the most effective cold lasers available, allowing our patients access to the most advanced lasers in the U.S. for better faster results. Laser therapy is a completely safe and painless procedure. It treats a wide variety of conditions, and can be used effectively with adults and children.
Red shows the inflammation of tennis elbow; the worst spot is dark red. After four minutes of treatment with our cold laser the inflammation has decreased considerably, showing a normal green color. The inflammation decreased for a longer period after each treatment until it eventually resolved completely.
The inflammation of shin splints shows red on this thermography picture. Laser therapy on a weekly basis eliminated the uncomfortable condition completely.
(Kidney Stone Removal Trauma)
The top of this picture shows the women's breast and an oblique angle of her abdomen. She had a bad kidney stone that was removed surgically. A guide tube ran up the urethra to the kidney where some complication left the kidney injured. The thermographic image shows the inflammation in dark red with specks of white. Our laser was able to help heal the kidney tissue quickly so the inflammation did not cause permanent damage.
Midwest Acupuncture and Pain Treatment Center - Beloit, Wisconsin
3005 Riverside Dr. Beloit, Wisconsin 53511 Phone: 608-365-6771
Midwest Acupuncture and Pain Treatment Center - Wausau, Wisconsin
3000 Emery Dr. & Hwy K Wausau, Wisconsin 54401 Phone: 715-675-6771


text:
Nail Essentials
11 N. Main St ~ Hartford Wisconsin
How do I remove Shellac at home?
1. Lightly etch the top coat with a nail file. This breaks the top seal of polish. Do not file through the polish.
2. Use either a cotton pad cut into fourths or small cotton balls. Saturate each pad with acetone polish remover (not acetate-check the first ingredient on the label)
3. Place a saturated cotton pad on top of the nail and wrap with a piece of aluminium foil. Repeat on other nails.
4. Apply a warm towel, heating pad or even your other hand on top of the wrapped nails. Wait 8 to 10 minutes.
5. Remove the foil and pads. The shellac will be curling up like a sticker. Gently scrap off with your finger nail or orangewood stick.
If you have any questions, please call us!


text:
If you're like me, you've had a career as a professional coach, consultant or trainer. But what's the difference between these and your work as a Mastermind Group Facilitator – and can you use all your skills and talents in your Facilitator role? Watch this 3-minute video tutorial and get the inside scoop!
Then read this blog post: Adapt Your Style: Coaching, Consulting, or Facilitating
And sign up for my free video tutorial on how to start a mastermind group of your own.
I know you're curious and have questions! Here's the answers to some of the most frequently asked questions I get about mastermind groups:


text:
Advice When Hiring Web Designing Services
People find it rare to forget about the website when using the internet. It is known for websites to be internet platforms for doing several jobs. It is known for websites to be majorly used when it comes to marketing. Businessmen rely on the website when it comes to marketing their brands.
It is found of traders to use pictures, videos, and texts when advertising their brands. In the current world, a lot of customers are found to love checking products and services using pictures and videos.
It has been known for websites to have been introduced through the flourishing in technology. Marketing websites have led into attraction of several buyers in the trading sector. It has therefore been known for people to make a lot of profit by selling their products and services. The website can be opened by small scale and large scale businessmen.
It is possible for a website to be efficient by various things. Marketers can have efficient websites by putting quality photos and videos.
It is found for the use of quality photos and videos to win a lot of users who turn to be eligible buyers. Speed is another thing that should be looked at on a website. Expect leads to love browsing speedy websites. One should think of designing their website all times. The process of improving the look of a website is called website designing. It is possible to improve the look of a website by using different colors and working on its application features.
Expect browsers to be won by attractive sites. One can find it challenging to design website on their own. One should therefore look for designers for the task. Website designers always offer quality services to their customers. It is found to exist several website designers in the globe. You should find it important to hire the best website designers all times.
One should consider some factors when hiring website designing services. It is good to plan for website designing project by making a budget.
One needs to keep some dollars for transport and cost of services when designing their website. It should be your goal to do a thorough research so as to get the best website designers. One should look for website designers in reputable designing companies. One should focus on visiting the reviews so as to get website designers who offer acceptable services to their customers. You should hire website designers who are advanced with technology. You should look for professional and experienced website designers. One should look for the affordable website designing services. One should find it crucial to hire website designers who are in a position to design your website according to your choice.
3 Developers Tips from Someone With Experience


text:
Located in Brockley conservation area, Tate Brockley on-street installation housed artwork created by members of the public at Grand Bazaart, an event held at Tate Modern in celebration of world mental health day.
The exhibition was featured in local publication by the Brockley Society.
Check out it's Micro Library Neighbour.
Many Thanks
Tate Modern | Brockley Society | All who contributed work


text:
Results 1 to 1 of 1
Thread: HSP xstr pro stops working
- Join Date
- Sep 2018
- Posts
- 2
- Rep Power
- 0
HSP xstr pro stops working
hello everybody!
my name is Franz and I have absolutely little clue about RC cars at all...
I bought it to my son several years ago, now we found it again in our cellar and we were going to use it again.
We could start it and it works, but after a little while it stops working... the steering works anyway. I first thought it was the batteries, but both the controller and the car are fully charged...
If I restart the car it will work again for a little while, like one minute and then stop again... everything looks fine and the fan is on, so I have no clue about what it could be... any idea? thank you
Similar Threads
Bad transmitter range on hsp xstr proBy Alex00 in forum Buggies - ElectricReplies: 2Last Post: 02-01-2015, 08:31 PM
Replacing 2S with 3S LiPo in HSP XSTR ProBy mjolnir in forum General Talk - R/CReplies: 2Last Post: 29-12-2014, 01:46 PM
hsp xstr proBy wayno in forum Buggies - ElectricReplies: 14Last Post: 24-01-2013, 02:17 PM
HSP xstr pro Car problems.... Help?By beamo23 in forum General Talk - R/CReplies: 20Last Post: 29-01-2012, 05:36 PM
Please help: Traxxas Stampede FWD/REV stops working but steering okayBy Tim Pede VXL B/less in forum General Talk - R/CReplies: 10Last Post: 31-10-2010, 01:54 PM


text:
When Siri Takes Over Your Phone
One morning earlier this week, I came down early and was working in our family room/kitchen area. My oldest daughter was charging her iPhone in the kitchen and it was randomly playing music. I would get up, turn off the music, and then a few minutes later, it would start again. Eventually I turned off the phone.
A bit later, when my daugher came down, she was in shock, her phone had randomly called dozens of her contacts on its own over the night.
So I took a look at her phone and it seemed that voice control had taken over her phone. I googled around to see what could be done and came up with this support forum thread. It explained that we could turn off voice dialing which we did, so that she would stop randomly dialing her contacts. But we were not able to turn off voice control entirely.
She's in Park City this week so when she gets back to NYC, she will take the phone into the genius bar and get it fixed. But until then, Siri is controlling her phone. Randomly playing music when she doesn't want it. Randonly facetiming people she doesn't want to talk to. It's a glimpse of the future to when AI goes haywire on us. It is not pleasant.


text:
Short Bio
Sandra Marie Humby is an Energy Alchemist and Contemporary Mystic with a lifetime's immersion in the activation and empowerment of the authentic voice and presence of the Sacred Feminine within.
She is the author and creator of Rose Alchemy: Rose Oracle for the Heart, the Rose Alchemy Healing program and beautiful energy supporting products. Sandy brings the knowledge of the Ancient Way of Light through the Sisters and Brothers of the Rose and Master Teachers. Her work is to illuminate a Heart healing pathway to lasting Inner Peace, Connection, Joy and Abundance and truly coming Home to Self, to Love.
Sandy has a rich and varied background of over 35 years immersed in the world of Wellbeing, Design and Metaphysics and is an experienced Pranic Healer, Pranic Psychotherapist and House Whisperer. She is a natural intuitive and empath with an enduring passion for the Sacred, Alchemical and Mystical in life. All of which she weaves through her work with the Rose and in consultations with clients and their homes.
Sandy shares her teachings through inspirational seminars, retreats, classes and personal consultations in the UK, Europe and USA.
The Story
My work and curiosity even from my early days as a couture Wedding Dress Designer was focussed around relationships and energy. As I listened and interpreted the dreams and vision of the bride who found her way to my shop door I heard her story, how she had met her beloved and other aspects of her life were revealed as we created the dress. I often saw the dynamic between bride and mother and her family and saw how they had influenced her life and choices…
I also worked with colour and form and how they affected her radiance. So alongside my design business (82 – 99) I was drawn to study practical Philosophy, Meditation, Colour Healing and various energy therapy modalities including Reiki and Sekhem.
As my own journey developed I found Pranic Healing and sought out teachers to develop my skills and understanding. This also led on to studying several Counselling modalities, Food Energetics and Holistic Health Coaching and an exploration of Vedic and 9* ki Astrology and the more esoteric aspects of the Alchemical path.
I began to notice that the spaces we live and work in have a profound effect on our well-being and by the late 1990's my design work had orientated itself towards Interior Design and Decoration and I headed off to KLC School of Design in Chelsea Harbour, London. I was interested from an energetic point of view, how the effect of layout, colour and content in our rooms and how our homes also tell a story and reflect just where we are in our lives, illuminating our blocks and patterns of reaction or response to life and where we are stuck.
I was a finalist in the Design Awards, Bathroom Designer of the Year 2003
Seen here in London with Sir Terence Conran and Kevin McCloud
My journey then took me deep on an exploration of self, of revealing patterns and how we attract by resonance people, experiences, opportunities and even our homes, really seeing and experiencing the magnetics of the heart and the effect of our belief systems on what we manifest in life. It was during this time (2005) I met and partnered with Christian Kyriacou to co-create House Whispering, together creating a unique language and approach to 'space clearing' and 'Feng Shui' from a soul evolution and healing perspective. Ultimately guiding clients home to themselves at an ever deeper level. I was fortunate through the hundreds of consultations in the UK, Europe and USA, to work with some wonderful clients and their amazing spaces, revealing and releasing old stories and patterns, optimising good health, joy, abundance and a sense of at last coming home to themselves.
Early in 2010 another new journey opened up for me, I followed a strong calling to visit The Alhambra in Granada, Spain which reconnected me back to an ancient lineage of light which I knew deep in every fibre of my being. It was in the exquisite gardens of The Alhambra that the Roses called me back to the path of LOVE and the Alchemical and heart healing properties of the geometry and frequency of the Rose.
The Way of The Rose is the path of Love and weaves together my personal story and journey for this and many other lifetimes. In 2014 I published Rose Alchemy: Rose Oracle for the heart. The sum total of 4 years of my developmental work with the Rose frequencies that brought together all of my learnings and study through my life. That led of course to the natural connection with silk and the printing of the Rose energies onto scarves and Rose Power Mats to bring beauty and healing into our daily lives.
2019 brings yet another turn of the wheel of my life and I sense that the Roses are taking me on an ever deeper quest.
Truly powerful times!


text:
RM74 is the solo project of Swiss musician Reto Mäder who lives and works in Bern. His atmospheric electro-acoustic cosmos builds on an infinite and wide open dialogue between fragile instrumental figures, amplified guitar drones, slow-growing melodies and cinematic textures. While his sound sources like guitar, piano, percussion, kalimba, electronics and field recordings drift with a sense of togetherness, Mäder creates a foggy and cryptic world of sounds and emotions.
Beside his work as RM74, Reto Mäder explores his love and interest for the heavy side of music with his bands Sum of R and Ural Umbo, moving in a wide space from ritualistic doom to dark ambient.
He also collaborated with Ralph Wehowsky (RLW) for the label Crouton and produced albums for musicians like Rhys Chatham and Herpes Ö DeLuxe. 2006 Reto Mäder founded together with Roger Ziegler Hinterzimmer Records.
RM74 – Two Angles of a Triangle (2xCD, Utech Records, USA, 2013)
RM74 – Reflex (CD, Utech Records, USA, 2010)
RM74 – Fireproof in 8 Parts (2xCD, Hinterzimmer Records, SUI, 2007)
RM74/RLW –Pirouetten (CD, Crouton, USA, 2007)
RM74 - Exkursion (CD, dOc, A/GER, 2005)
RM74 - Instabil (Domizil, SUI, 2002)
RM74 - Mikrosport (Domizil, SUI, 2000)
Sum of R – Lights on Water (LP, CD, DL, Utech Records, USA, 2014)
Sum of R – Ride out the Waves (EP LP, Storm as he walks, IT, 2012)
Ural Umbo – II (EP CASS, Merz Tapes, USA, 2012)
Ural Umbo – Delusion of Hope (LP & CD, Utech Records, USA, 2011)
Pendulum Nisum – S/T (LP, Hinterzimmer Records, SUI, 2011)
Ural Umbo – Latent Defects (EP CASS, Utech Records, 2010)
Ural Umbo – S/T (CD, Utech Records, USA, 2010)
Rhys Chatham – The Bern Project > as producer & guest musician (CD, Hinterzimmer Records, SUI, 2009)
Sum of R – S/T (CD, Utech Records, USA, 2008)
Sum of R – EPI (EP CD-R, Hinterzimmer Edition, SUI, 2008)
Herpes Ö DeLuxe – Kielholen > as producer & guest musician (CD, Hinterzimmer Records, SUI, 2007)
Ohne - Ohne 1 (CD, Ohne/Mego, A, 2002)


text:
Creative minds on display and a huge enthusiastic crowd on the streets of our good old Toronto. Loved it all. The shared adventures of discovering art at night, the wonder in people's eyes, the revelry ... it was so much fun.
Ai Weiwei's Bicycles Forever
Balls? Look closer. It's an optical illusion created from the balance of shadow and light and the angle from which I took the photo. These are carton tubes stacked on a truck. Can't remember the artist or title of the project and can't find it on Nuit Blanche site but love the visual effect. It reinforces the fact that art is everywhere around us if we attune our eyes and imagination to see beyond the mundane.


text:
You always have the possibility of getting to know which informations we keep about you. All you have to do is to send us an e-mail with your name and adress. Then you will within 10 days recieve a mail with the informations. If you wan´t us to delete these informations, you need to make this claer in the mail.
We do not give these informations to others. The data that you give us when you shop in Customski, is considered as confidential and is under no circumstances being given to others.
This OpenBizBox e-trading system uses so-called cookies. It is to ensure that you can shop comfortable in this shop. When you add an article to your shopping card, this information is hidden in a cookie on your own computer.
If your browser cannot handle cookies or if you have switched them off, it is unfortunately not possible for you to shop in our web-shop. But you are welcome to look at our website and make your order via e-mail.
A cookie is a little data-file, that is placed on your computers harddisk. A cookie is not a program, and cannot read or destroy data from your computer. A cookie cannot be used by virus or the like to damage your computer. You can read more about cookies at www.cookiecentral.com
Customski.dk uses log statistics. A statistics system gathers information, that gives us a statistics simile of how many vistiters the webpage have had, where they come from, which part of the webpage they use etc. In our shop the log statistics are only used in the purpose of optimizing the website and its functionalism. Log statistics is also used to make the website more user-friendly.
As usual the log informations is saved for two years. This is to create a picture of the shops development over time.