atom feed33 messages in net.java.dev.spots.devRe: radio update
FromSent OnAttachments
Ron GoldmanMar 2, 2009 5:06 pm 
Eric ArseneauMar 2, 2009 6:09 pm 
Pete St. PierreMar 2, 2009 6:35 pm 
Eric ArseneauMar 2, 2009 8:00 pm 
John DanielsMar 2, 2009 11:43 pm 
Pete St. PierreMar 3, 2009 8:41 am 
Ron GoldmanMar 4, 2009 3:14 am 
John DanielsMar 4, 2009 7:12 am 
Markus BestehornMar 4, 2009 7:57 am 
Randy SmithMar 4, 2009 8:20 am 
John DanielsMar 4, 2009 8:51 am 
Arshan PoursohiMar 4, 2009 8:51 am 
Randy SmithMar 4, 2009 8:51 am 
John DanielsMar 4, 2009 9:16 am 
John DanielsMar 4, 2009 9:24 am 
Eric ArseneauMar 4, 2009 9:28 am 
Eric ArseneauMar 4, 2009 9:31 am 
Markus BestehornMar 4, 2009 10:03 am 
Robert TaylorMar 4, 2009 10:50 am 
John DanielsMar 4, 2009 11:24 am 
Ron GoldmanMar 4, 2009 11:27 am 
John DanielsMar 4, 2009 11:30 am 
John DanielsMar 4, 2009 11:37 am 
Eric ArseneauMar 4, 2009 11:38 am 
Eric ArseneauMar 4, 2009 11:39 am 
Dave ClealMar 4, 2009 12:22 pm 
Eric ArseneauMar 4, 2009 12:43 pm 
Randy SmithMar 4, 2009 3:43 pm 
John DanielsMar 4, 2009 10:54 pm 
John DanielsMar 5, 2009 8:16 am 
Markus BestehornMar 5, 2009 10:43 am 
Markus BestehornMar 6, 2009 9:19 am.jpg
Markus BestehornMar 11, 2009 6:26 am 
Subject:Re: radio update
From:Pete St. Pierre (Pete@sun.com)
Date:Mar 2, 2009 6:35:42 pm
List:net.java.dev.spots.dev

Eric - I've asked Ron to run a few tests on a full SPOTnet deployment before committing since the changes have a profound impact on pretty much *anything* using the radio. The work looks VERY promising, but we definitely want to be sure of these put-backs when they go in.

You are welcome to do a build anytime, including the LQRP library as described in a separate e-mail to the team. I'm pretty sure Arshan, Poorna and the rest of the team are waiting for it.

Thanks! ...Pete

On Mar 2, 2009, at 6:10 PM, Eric Arseneau wrote:

If it commited I am willing to do a build.

On Mar 2, 2009, at 5:07 PM, Ron Goldman <Ron.@sun.com> wrote:

I've been looking at the radio stack and trying to make it more reliable for OTA commands. So far I've decreased some timeouts (MAC- layer retry if no ack, radiostream retry if no end-to-end ack), added some delays (between lowpan packets) & improved the error handling in the OTA code. These changes have drastically cut down the number of radio receive buffer (FIFO) overruns, channel access failures (i.e. starting to send, but detecting that another transmission is in progress), collisions, etc., and the code now handles the errors more robustly.

The result is that I can now reliably get information about a SPOT via OTA over 6 hops and deploy over 5 hops (6 hops is about 50% successful). This is using the MAC-layer filtering to create a chain with the SPOTs only seeing messages from their "neighbor" (packets from other SPOTs are filtered). So for my test setup the number of channel access failures & collisions is probably much greater than if the SPOTs were spread out and could not each hear all the other SPOTs.

Hopefully this will be added to a new developer release in the next week or so.

-- Ron --