Announcing Contiki uIPv6 on Atmel Raven

Go To Last Post
43 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally - a really cool use for your Raven boards ;-)

Atmel, Cisco, and SICS have been working together for the past months to bring the ability to run Internet Protocol over the Atmel Raven boards. You can read the official press release on Atmel's site among others.

You can see some more information right off of the Contiki Website.

Get the release at http://www.sics.se/contiki/news/...

Check out a video of it all working together at www.youtube.com/watch?v=yjztYx_F2Ko

Get the tutorial too for a great overview!

Currently the tutorial is written to work with the JTAG MK-II. If you don't have one there should be ways around using one, as it's just for programming! More on all that to come...

Last Edited: Mon. Oct 20, 2008 - 06:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Freaks,

I'd like to take this opportunity to offer a free RZRAVEN kit for those of you who want to try the uIPv6 and SICSlowpan implementation on the Raven boards.

Standard procedure applies :-)

Leave me a PM with your shipping details:
- Name
- Address
- Email address and telephone number
(Above information is mandatory for DHL to pick up the kits...).

First 25 PM's will receive their free kit shipped from the AVR Design Center in Trondheim/Norway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great offer - you have mail!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another PM. Thanks for the offer!

Jim Wagner

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

see also this prior post
https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But, but.. what is 6LowPAN and the IETF/RFC proposing to do for mesh routing in this? A small IPv6 frame and stack is great, but many low power sensor applications need self-forming meshes or at least static routes in a cluster tree. And battery powered FFD mesh routing (time-synch rendevous) - that is sadly missing in ZigBee PRO. But present in ISA 100.11a.

One cannot just drop OSPF or AODV or TBRPF into the small microprocessor because these don't do time-synch'd rendevous to enable "sleeping" router FFD nodes.

And, those 3 protocols don't look-down to layer 2 to choose routes based on LQI (RSSI). Traditional wired network routing is strictly based on lowest hop-count route, whereas wireless often needs to cull out routes where the LQI (SNR) is poor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like the video, very cool!
I think there is a small sound problem in the last 15s though...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the offer! You have a PM

It looks great.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Stevech,

regarding routing, you can have a look at the ROLL working group (http://www.ietf.org/html.charter...). It was formed a few months ago, initial charter is to
- define routing requirements for sensor networks in the smart cities, building automation, home automation and industrial verticals
- define the metrics needed for routing (including L1/2 and device specific metrics like power state)
- issue a study of the existing routing protocols (and whether they match these requirements)

The group was extremely fast and all these documents should be in last call to be RFCs around next IETF meeting late November. If none of the studied protocols is considered suitable for sensor networks (likely to happen), the group will recharter and start working on a solution.

IETF generally is in favor of such a routing approach, as opposed to a layer 2 mesh approach.

Regarding the low power aspect, in 6lowpan a new header compression scheme, more powerfull than the current one, is being worked on, as well as neighbor discovery extensions to avoid IP multicast. With this extension, no more than 1 multicast packet should be sent in all the device life.

Cheers,
Julien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mdurvy wrote:
I like the video, very cool!
I think there is a small sound problem in the last 15s though...

More than a small sound problem. The sound stops completely in the last 15 seconds or so ... pity.

Cheers,

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jabeille wrote:
Hi Stevech,

regarding routing, you can have a look at the ROLL working group (http://www.ietf.org/html.charter...). It was formed a few months ago, initial charter is to
- define routing requirements for sensor networks in the smart cities, building automation, home automation and industrial verticals
- define the metrics needed for routing (including L1/2 and device specific metrics like power state)
- issue a study of the existing routing protocols (and whether they match these requirements)

The group was extremely fast and all these documents should be in last call to be RFCs around next IETF meeting late November. If none of the studied protocols is considered suitable for sensor networks (likely to happen), the group will recharter and start working on a solution.

IETF generally is in favor of such a routing approach, as opposed to a layer 2 mesh approach.

Regarding the low power aspect, in 6lowpan a new header compression scheme, more powerfull than the current one, is being worked on, as well as neighbor discovery extensions to avoid IP multicast. With this extension, no more than 1 multicast packet should be sent in all the device life.

Cheers,
Julien

Do we now have the new
ROLL group (IETF, 1st cousin of IEEE), and
IEEE 802.11s (languishing), and
ISA SP100a, and
IEEE 802.5.4 new draft for '09

all working on the same meshing challenges?

meanwhile dating back to the original 802.15.5 w/ZigBee, and in 802.11, we STILL don't have a standard for meshes nor "sleeping" routers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Friends,

I have now received 30 requests for a free RZRAVEN kit and the offer for free Ravens is closed for now.

We expect these kits to start shipping Tuesday Oct 21st.

Next opportunity to catch a free Raven will be to see us at the Embedded Systems Conference in Boston Oct 26-30; http://www.cmp-egevents.com/web/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your offer is very much appreciated. Thank you.

-Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
But, but.. what is 6LowPAN and the IETF/RFC proposing to do for mesh routing in this? A small IPv6 frame and stack is great, but many low power sensor applications need self-forming meshes or at least static routes in a cluster tree. And battery powered FFD mesh routing (time-synch rendevous) - that is sadly missing in ZigBee PRO. But present in ISA 100.11a.

One cannot just drop OSPF or AODV or TBRPF into the small microprocessor because these don't do time-synch'd rendevous to enable "sleeping" router FFD nodes.

And, those 3 protocols don't look-down to layer 2 to choose routes based on LQI (RSSI). Traditional wired network routing is strictly based on lowest hop-count route, whereas wireless often needs to cull out routes where the LQI (SNR) is poor.

Hi Stevech,

The Arch Rock 6LoWPAN Software Distribution CD inside the Raven Kit provides a kernel library supporting TCP/UDP/IP traffics over low-power multihop topologies for the Raven nodes.

The self-organizing meshing protocol is layer 3 rather than layer 2 meshing. That is, each node can be both an IP host and an IP router running only with batteries. The meshing algorithm also incorporates layer 2 and layer 3 parameters in selecting reliable routes. The algorithm has been in Arch Rock products for more than two years.

The beta release for the Raven has been out for half a year and there is a forum for the user community to post issues and share their experience. If you don't have the Raven Kit yet, you can still download the distribution and participate in the forum at the link below. The distribution also provides white papers explaining the underlying networking technology.

http://asdsupport.archrock.com/

Thanks,

alec

Alec Woo
Arch Rock Corporation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The actual source in .zip form was released today too, see http://www.sics.se/contiki/news/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can any gurus look at
http://dakx.com/raven/vistaraven...

and tell me why the raven isn't connecting to the USB stick on my Toshiba/Vista laptop?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I don't see any packet's marked as RX'd. To check this, I'd do the following:

-Unplug everything (to get a fresh start)
-Plug in USB stick
-Connect wireshark to USB stick once it settles and shows up in wireshark
-Turn on the Raven board. You should see one or two neighbour advertisement packets, and some 802.15.4 traffic. The 802.15.4 stuff is with the "Ethernet II 0x809a". If you have a suitable version of wireshark* it will be decoded as 802.15.4.

Regards,

-Colin

*See "Jackdaw" documentation, aka RavenUSB in Contiki.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi dak664,

looking at your trace I see the packets from the RAVEN board are correctly received (one neighbor solicitation, 3 router solicitations). Can you confirm that the MAC of the RAVEN board is 02:11:22:ff:fe:33:44:55?

If this is correct, seems that the PC does not reply to the RS. It probably means it does not consider itself a router. To confirm this, i would need to see the packets sent by the PC at interface initialization. You can probably achieve this by having wireshark capture on the "any" interface, then plug in the usb stick and type the commands in the tutorial

Note that to have an easy to read capture, you can put the "ipv6" filter in the capture filter box.

On XP, the command ipv6 ifc advertises sets the interface as an advertising interface, meaning it will send RAs. I will check on Vista how it is supposed to be configured.

Regards,
Julien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ported the XP commands to vista using
http://technet.microsoft.com/en-...
(migrating commands from IPv6.exe to netsh)

They are

netsh interface ipv6 set interface interface="interface index" forwarding=enabled advertise=enabled
netsh interface ipv6 add address interface="interface index" address=aaaa::1
netsh interface ipv6 add route prefix=::/0 interface="ethernet interface index" publish=yes
netsh interface ipv6 add route prefix=aaaa::/64 interface="interface index" publish=yes

I also did

netsh interface ipv6 set global randomizeidentifiers=disabled

to make the USB ip6 link-local the same as for XP.

It works! For a few minutes at a time only. I think the problem is in the wireless router advertisements and neighbor solicitations from the stick, they all have random lengths and bad FCS. But when I power up a Raven it sends it own neighbor advertisement and the stick responds correctly. The same was true for XP but (I am guessing) XP remembers the route for a longer time. I have wireshark dumps, if anyone wants to see them, PM me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I think the problem is in the wireless router advertisements and neighbor solicitations from the stick, they all have random lengths and bad FCS.

Per the docs, the FCS that appears on packets sent from the computer Wireshark is running on are invalid. This is because Wireshark is sniffing the traffic sent to the USB stick, and not the traffic over the air. The FCS gets added at the radio, and hence the actual FCS is fine, the reported one is invalid.

Not sure on the lengths though. Are they all totally different, or is there some pattern?

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

111 mostly, but 135, 134, 89, 83, 93 ...
The long ones seem to contain strings from random memory. See

http://dakx.com/raven/vistawires...

Maybe I need to reprogram the stick, I am using RZRAVEN USB DEMO 1.0.0 .elf from the development snapshot

http://www.sics.se/%7Eadam/conti...

I am still reading the index in the docs :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey,

Attached is a compile from CVS.

Also that problem about some serial emulators not working should be fixed! Let me know what you see...

-Colin

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, PuTTY will now connect to the serial interface.

Your ravenusbstick.elf is on the stick and the Raven is connected to the laptop. Will see how long that lasts.

I don't see a connect to "any" interface in wireshark. That would indeed be useful. I am using version 1.1.2-SVN-26512

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Raven has landed in Texas.
Received the kit on 10/28/08.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another 15-20 Ravens are about to take off from Trondheim/Norway.

DHL tracking numbers are beeing e-mailed out to everyone of you as they take off...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The newest Jackdaw firmware had the same behavior with my Vista as before, disconnecting after 30-60 minutes.

I think it happens when Vista issues ws-discovery and llmnr UDP packets, which generate a burst of ~25 802 broadcasts. After that no more 802 packets are sent, although still received from the Raven. A clue I should have noticed earlier, the Jackdaw red and green LEDs stay on at this point. Normally just the blue one is on and the others flash.

Hopefully there is a less blunt way to do this, but I enabled the firewall for the Jackdaw and Ethernet interfaces, and disallowed the exception for Network Discovery. Voila, no more UDP packets, and the link to the Raven has been up for 3 hours now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Quote:

A clue I should have noticed earlier, the Jackdaw red and green LEDs stay on at this point. Normally just the blue one is on and the others flash.

Ahh... yes that is bad! If any lights besides the blue one are on solid something has gone wrong. Generally the more lights "stuck" the more it's broken ;-)

I don't think that's a vista-specific problem, vista might just 'encourages' it. I'll look into trying to see a better way to recreate this and fix the Jackdaw code.

There can be problems if a ton of packets are sent at once - mainly stemming from the fact the 802.15.4 link is a low-rate single-duplex link, unlike the ethernet it's replacing.

I saw similar problems for example on Linux if I sent a bunch of ping requests with too short a period between ping requests.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So mesh networking does not exist in this contiki ipv6 codebase? If not, I'd be bummed.

I'm working on a home brew home automation project. I need mesh routing for it work well. ZigBee would be nice (since mesh routing is defined), but expensive as no free stacks exist. I know about the Xbee modules, but using those things would double the cost of each device I plan to build. Besides, it seems silly to pay $20 for a module than drop another $4 for an external avr to control the module. Alas, the xbees use a ember chipset and compilers for that chip cost lots of $$$$$.

I guess I should read up more on the ArchRock 6lowpan stack.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the Jackdaw running pretty reliably now, after some playing around with the Vista advanced firewall settings manager to block all but router advertisements and TCP/IP (Teredo packets were the last culprit). If you want to give the Raven some exercise, check out http://dakx.com:8080 :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Very very cool! The webservers work for me.

Also btw there was a recent commit to the Contiki CVS that fixed some issues with certain applications running on Contiki. This includes the webserver application, so if you see flakey performance you might look to update that...

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:

Also btw there was a recent commit to the Contiki CVS that fixed some issues with certain applications running on Contiki. This includes the webserver application, so if you see flakey performance you might look to update that...

The link worked for 10 hours, then the Jackdaw stopped sending RF packets (see pic). This time no LED's stayed on. Replugging the stick made it work again. Is there a way to reset the stick through the debug interface without reloading the Vista driver as well? That might help to identify where the problem is.

Edgar http://dakx.com:8081 and Lenore http://dakx.com:8082 are both on line now, Lenore is from today's CVS tarball. Try loading both pages at once!

Does the recent commit affect the Jackdaw firmware?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Edgar http://dakx.com:8081 and Lenore http://dakx.com:8082 are both on line now, Lenore is from today's CVS tarball. Try loading both pages at once!

I must be unlucky but everytime I try they aren't responding.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great job.

i will try on my Raven boards.

tks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They were up for 5 hours, then the Jackdaw went into the usual mode of not converting outbound ethernet packets to RF. This time LEDs stayed on.
It happened when pages were being requested from both Ravens, Lenore's was the long style sheet and the transfer was never completed. In the midst of all this activity a UDP llmnr packet was issued from port 57085, which caused a couple of RF packets before transmission stopped. I thought I firewalled all the llmnrs, will have to track this one down.

Fifteen minutes later Edgar sent 1000 neighbor solicitations over 60 seconds, then the battery went below 3.2 volts which shut down the RF. Maybe the low battery had something to do with the stick freezing.

Edgar and Lenore are up again and they need some more exercise. Copious wireshark captures are available for those interested :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

magnusp wrote:
Freaks,

I'd like to take this opportunity to offer a free RZRAVEN kit for those of you who want to try the uIPv6 and SICSlowpan implementation on the Raven boards.

Standard procedure applies :-)

Leave me a PM with your shipping details:
- Name
- Address
- Email address and telephone number
(Above information is mandatory for DHL to pick up the kits...).

First 25 PM's will receive their free kit shipped from the AVR Design Center in Trondheim/Norway.


---------------
Hi-G-Tek, 16 Hachroshet st. Or-Yeuda Israel
Tel: 972-54-4807927 (yossi Barkan)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dak664 wrote:
...then the battery went below 3.2 volts which shut down the RF. Maybe the low battery had something to do with the stick freezing.

Hello all, i'm curently trying to get my ravens working. It seems you're right concerning low battery problems. I was not able to establish any connection unless i used an external power supply. And my usb device was also freezing.

Best regards,
Sascha.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is what I am using to monitor power consumption and also charge from the USB port. The diode is there to keep the old laptop Lion cell voltage below 4.2 volts, and I wouldn't leave it unattended. The 1284/radio draws 25 ma and the 3290/LCD 5 ma. So sleeping the 3290 doesn't save much at this point.

If you don't have an old suppressor grid meter lying around you could probably get something digital to work :)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

finally got it going ...
cant stop reading the temp :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congratulations!
Hopefully contiki 2.4 about to be released will make it easier to get the Ravens going with Windows.

By the way I can't recommend using Windows portproxy ip4 to ip6 to get to the Raven webserver, hackers are constantly scanning ipv4 ports and seem particularly fascinated when the Raven responds. Haven't had such problems yet with radvd routing through an ipv6 tunnel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone know if it is possible to flash a stock AVR-RAVENUSB stick with Contiki-based Jackdaw without using JTAG? Is there a way using ISP or USB(DFU/FLIP)?

Trying to avoid paying an extra $60 for an AVR Dragon board...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rquattle wrote:
Anyone know if it is possible to flash a stock AVR-RAVENUSB stick with Contiki-based Jackdaw without using JTAG? Is there a way using ISP or USB(DFU/FLIP)?

Trying to avoid paying an extra $60 for an AVR Dragon board...

I quick scan of the AT90USB1287 datasheet does not mention ISP as a programming option. Looks like only JTAG is supported. The hardware looks to support a USB bootloader, but I'm pretty sure there isn't a usb bootloader programed in by Atmel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I quick scan of the AT90USB1287 datasheet does not mention ISP as a programming option. Looks like only JTAG is supported.

Not true. See 29.7

The ways to program an AT90USB are:

1) JTAG
2) ISP
3) via FLIP/DFU bootloader
4) HV parallel programming

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I'm guessing the chip supports ISP, but since there is no ISP header I would need solder some wires directly to the chip? Is there any way to do ISP thru the pins in the JTAG header?