atom feed33 messages in net.java.dev.spots.devRe: Re[4]: 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: Re[4]: radio update
From:Robert Taylor (das.@gmail.com)
Date:Mar 4, 2009 10:50:07 am
List:net.java.dev.spots.dev

Hi all,

While people are working on the drivers I had a few suggestions for improvements. Could the number of retries and the delay between retries be moved into RadioPacket so settings are per-packet rather than using a global setting. CTP for example, needs to disable link layer retries because packet success/failure statistics are fed directly into CTP's link estimator.

2009/3/4 Eric Arseneau <Eric@sun.com>:

John,

From what I've seen of other setups that use this "wired" radio approach, I think we should be able to test most cases.  The only one I don't completely understand is the case where the radio is not bidirectional.  There is a scenario I think I heard Pete talk about that goes something like this.  A hears B, but B does not hear A and goes through C to get to A.  I assume that testing these types of scenarios will require us to add capabilities on the software side to create topologies that we want.  So combining the "wired" connected radios and software configuration we should be able to test all scenarios?

On Mar 4, 2009, at 9:17 AM, John Daniels wrote:

Hi Arshan,

For a multihop test rig it's important to be able to create networks, whereas for Eric a simple one-to-one connection is enough. So I think the interconnect is quite complicated to build. In a simple 2 hop scenario (A to B to C), transmissions from A need to be heard by B and not C, but transmissions from B need to be heard by A and C.

--John

==== Original message From: Arshan Poursohi <Arsh@sun.com> Date: 04 March 2009 Time: 4:52:24 PM Subject: radio update

---- Think the original idea was to just connect the spots physically together with the coax, Eric asked Keith to do some work on spots for the regression harness last week. I dont know if this request was included in that though, Ill ask Keith to do so if its not.

-Arshan

On Mar 4, 2009, at 7:13 AM, John Daniels wrote:

Ron, I really think it's time to create a proper test rig that allows repeatable and consistent multihop testing. I discussed the idea with Pete and Bob more than a year ago, and Bob seemed ready to create a hardware set up with SPOTs connected via coax instead of aerials, so that the set of receivers can be accurately controlled. If you had, say, a matrix of 16 SPOTs with controllable pathways you'd be able to conduct some very meaningful experiments. A simpler form of that rig would be very useful for Eric, too, for the continuous test system.

--John

Cool idea, I guess each SPOT would be in a faraday cage. Coax between boxes, with a simple antenna from the coax to inside the box -- would let you simply drop the SPOT inside (?)

--Randy