| Author |
Message |
|
|
 Posted: Oct 15, 2008 - 04:18 PM |
|
Joined: Mar 23, 2001
Posts: 2067
Location: Edinburgh, UK
|
|
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/uipv6-s ... lease.html
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... |
_________________
VA3 YHZ - http://www.newae.com
Last edited by c_oflynn on Oct 20, 2008 - 07:31 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 04:52 PM |
|
Joined: Apr 19, 2006
Posts: 59
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 05:00 PM |
|
Joined: Jul 18, 2005
Posts: 34381
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| Great offer - you have mail! |
_________________
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 05:31 PM |
|
Joined: Nov 22, 2002
Posts: 7346
Location: Tangent, OR, USA
|
|
Another PM. Thanks for the offer!
Jim Wagner |
_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 08:03 PM |
|
Joined: Dec 18, 2001
Posts: 3011
|
|
|
|
|
|
|
|
Posted: Oct 15, 2008 - 08:09 PM |
|
Joined: Dec 18, 2001
Posts: 3011
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 08:40 PM |
|
Joined: Oct 15, 2008
Posts: 1
|
|
I like the video, very cool!
I think there is a small sound problem in the last 15s though... |
|
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 09:08 PM |
|
Joined: Oct 15, 2008
Posts: 1
Location: Enschede
|
|
Thanks for the offer! You have a PM
It looks great. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 15, 2008 - 09:32 PM |
|
Joined: Apr 23, 2008
Posts: 5
|
|
Hi Stevech,
regarding routing, you can have a look at the ROLL working group (http://www.ietf.org/html.charters/roll-charter.html). 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 |
|
|
| |
|
|
|
|
|
|
Posted: Oct 16, 2008 - 02:00 AM |
|
Joined: Jul 02, 2005
Posts: 2632
Location: Melbourne, Australia
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Oct 16, 2008 - 03:46 AM |
|
Joined: Dec 18, 2001
Posts: 3011
|
|
|
jabeille wrote:
Hi Stevech,
regarding routing, you can have a look at the ROLL working group (http://www.ietf.org/html.charters/roll-charter.html). 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. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 16, 2008 - 11:01 AM |
|
Joined: Apr 19, 2006
Posts: 59
|
|
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/escb |
|
|
| |
|
|
|
|
|
|
Posted: Oct 16, 2008 - 04:28 PM |
|
Joined: Nov 10, 2005
Posts: 1520
Location: Spokane, WA
|
|
Your offer is very much appreciated. Thank you.
-Tom |
|
|
| |
|
|
|
|
|
|
Posted: Oct 16, 2008 - 06:27 PM |
|
Joined: Jul 27, 2006
Posts: 6
Location: San Francisco
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Oct 20, 2008 - 07:32 PM |
|
Joined: Mar 23, 2001
Posts: 2067
Location: Edinburgh, UK
|
|
|
|
|
|
|
|
Posted: Oct 24, 2008 - 04:27 PM |
|
Joined: Jun 15, 2008
Posts: 659
Location: North Carolina USA
|
|
|
|
|
|
|
|
Posted: Oct 24, 2008 - 09:43 PM |
|
Joined: Mar 23, 2001
Posts: 2067
Location: Edinburgh, UK
|
|
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. |
_________________
VA3 YHZ - http://www.newae.com
|
| |
|
|
|
|
|
|
Posted: Oct 27, 2008 - 12:44 PM |
|
Joined: Apr 23, 2008
Posts: 5
|
|
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 <ifindex> 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 |
|
|
| |
|
|
|
|
|
|
Posted: Oct 27, 2008 - 02:37 PM |
|
Joined: Jun 15, 2008
Posts: 659
Location: North Carolina USA
|
|
I ported the XP commands to vista using
http://technet.microsoft.com/en-us/libr ... 26950.aspx
(migrating commands from IPv6.exe to netsh)
They are
Code:
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
Code:
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. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 27, 2008 - 05:01 PM |
|
Joined: Mar 23, 2001
Posts: 2067
Location: Edinburgh, UK
|
|
|
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 |
_________________
VA3 YHZ - http://www.newae.com
|
| |
|
|
|
|
|
FAQ •
Search •
Register •
Log in to check your private messages
Log in
• 
Minimize
• 
RSS
