Okej, But the PERR function that is right now implemented return a prob of zero when SNR is zero, and then very slowly increase when SNR is going towards negativity. And intuitively, there should not be this minimum point at 0db .
Just had a quick look at the your quoted paper, couldn't find references to the SNR or signal strength, they evaluate the packet reception rate according to the distance (and also density, #hops, etc..) Maybe it was in the 2004 sigcomm paper, but I am afraid I can't get a copy of that one. I understand that two nodes very far apart can have connectivity because of signal reflections, for example. But I am still convinced that a SNR of -50db (which should mean pure noise) should not deliver a packet with a 1% chance. Well, just something that needs to get improved, I guess. Thank you for answering, Alban . 2009/2/4 Philip Levis <[email protected]>: > > On Feb 2, 2009, at 7:16 AM, Alban Hessler wrote: > >> Hi, >> >> Digging deeper into CpmModelC, I think there is missing a safety >> statement in the shouldReceive function. >> >> I think many people use the link gain generator based on a topology >> file (see TOSSIM tutorial on the wiki). The tool output a link gain >> for every pair of nodes in the network, thus the SNR for some of these >> links is negative (for nodes that are very far apart). >> >> Alas, the CpmModelC file in TOSSIM does not check that, and even call >> the PER function for such a SNR, which obviously should never yield a >> successfully decoded packet (the receiver would not even sync on the >> preamble, since it's just noise..). >> >> The effect is that it creates wormholes, specially with extremly bad >> links. i.e. WIth a SNR of -50 db, the probability of passing the >> packet is 1 %. Here is an excerpt of the CpmModel output: >> >> DEBUG (33): SNR is 3.520000, PRR is 0.066555 >> DEBUG (29): SNR is 0.600000, PRR is 0.000001 >> DEBUG (27): SNR is -25.840000, PRR is 0.010087 >> DEBUG (26): SNR is 6.990000, PRR is 0.877191 >> DEBUG (28): SNR is 15.200000, PRR is 1.000000 >> DEBUG (32): SNR is -12.300000, PRR is 0.007021 >> DEBUG (31): SNR is -13.620000, PRR is 0.007780 >> >> Simple fix would be to check the SNR for positivity before calling the >> rather computationally expensive prr_estimate_from_snr() function. Any >> negative SNR should yield a probability of zero for receiving the >> packet. >> >> Please, can someone confirm what I just stated? > > Well, technically, it is not 0.... There are physical layers which can > receive packets with an SNR < 0dB. In very controlled conditions, for > example, 802.11 at 1Mbps. Take a look at the SIGCOMM 2005 Roofnet > measurement study. > > I am leery of putting in a special case. But if you have a better function, > then I'd be happy to replace what's in there now. I think it's safe to say > that efficiency was not a big concern when I implemented it. > > Phil > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
