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:Eric Arseneau (Eric@sun.com)
Date:Mar 2, 2009 8:00:56 pm
List:net.java.dev.spots.dev

Although I agree with the more testing, if the code passes the tests we have now, then we should go ahead and commit it. This is one of the major points of developer builds, to push the envelope. Getting it into as many willing guinea pigs as possible :) Mainly us. As I've stated before, the more public we make our development, the more feedback we have a chance of getting.

For example, in this case if we were having a dialog with the schools that have done some networking, maybe they could be running their own tests overnight and reporting back that its looking good, better or worse for their tests.

If we find that there are failures we did not account for, then we should add tests and go on to the next build.

On Mar 2, 2009, at 6:36 PM, Pete St. Pierre wrote:

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 --