What is the  value of TxPower in lwmesh - Page 1
Forum section: electronics / beginners

author: Unknown
author_rank: Unknown
timestamp: May 23, 2017, 04:09:00 am
content: HiWe are using the Lwmesh stack for avr-atemga256rfr2.Now we are in a requirement of decreasing the range by setting PHY_TxPower() to a vlaue.we have tested with values 0,1,2,3.but couldnt any changes has happened in range.We are getting the same range for all the above values.Can anybody please tell us what is the value to be set so that the range is minimum

author: ataradov
author_rank: Super Contributor
timestamp: May 23, 2017, 06:21:16 am
content: Just as developed guide says "The transmit power the node is set via the PHY_SetTxPower() function. This function takes radio-dependent value as a parameter. Refer to the datasheet for a specific PHY for complete description of the valid input values."It is a direct value of the PHY_TX_POWER register.

author: ataradov
author_rank: Super Contributor
timestamp: May 23, 2017, 06:22:56 am
content: If you are measuring range "by eye", then you won't see much difference until you hit 10-15.

author: ataradov
author_rank: Super Contributor
timestamp: May 23, 2017, 03:59:23 pm
content: Quote from: umamaheswary on May 23, 2017, 09:04:38 amSo lots of reflections, and unpredictable multipath propagation.Quote from: umamaheswary on May 23, 2017, 09:04:38 am200 meters is not that far, even with -16 dBm loss of power. You will probably observe corresponding loss of RSSI on the receiving node, but the received is more capable that this.Quote from: umamaheswary on May 23, 2017, 09:04:38 amAny "picking up" happens after route score goes to 0, so you can decrease NWK_ROUTE_DEFAULT_SCORE. But that will make static devices be more sensitive to randomly lost frames. If you have some devices that are mobile, and some that are static, then let this setting have a different value on different devices.

author: ataradov
author_rank: Super Contributor
timestamp: June 01, 2017, 04:26:29 pm
content: You need to debug.How often does your device send data? It will not try to search for the next node until there is connectivity with the previous one, and until at least one attempt already failed.NWK_RouteNextHop() just gets obective information from the internal table, it is purely informational, there is no way you can affect anything by changes to this function.You can just use proper attenuates.

author: ataradov
author_rank: Super Contributor
timestamp: June 02, 2017, 03:22:57 am
content: Quote from: umamaheswary on June 02, 2017, 03:20:19 amSo your minimal change delay will be 1 second + time necessary to discover a new route.Quote from: umamaheswary on June 02, 2017, 03:20:19 amNot unless you communicate more often there is no magical way for device to know that something has changed in the outside world. Either base statations of device itself need to send probing frames as often as you need to detect the change.

author: ataradov
author_rank: Super Contributor
timestamp: June 02, 2017, 03:36:34 am
content: "Track" is a relative term. You need to define numerical parameters of that tracking, and then see if there is a way to make it practical.

author: ataradov
author_rank: Super Contributor
timestamp: June 02, 2017, 04:50:15 am
content: Quote from: umamaheswary on June 02, 2017, 04:47:42 amLook in the sniffer and you will know exactly. Also, when this happens, what status codes are returned? You can't avoid collecting this information, this is like 80% of what wireless design is.

author: ataradov
author_rank: Super Contributor
timestamp: June 02, 2017, 03:48:36 pm
content: Can you actually attach the sniffer file? Not a poorly made picture of a screen.Also, I doubt anything substantial will happen in 4 frames, so you are clearly not capturing enough data. You need to capture full trace, starting from when device can communicate, to when it fully moves to the other end.And one more thing? Are we talking about the same network in both threads? If so, then what moving are we talking about? All device have to be within range for time-syncronized network to work?

author: ataradov
author_rank: Super Contributor
timestamp: June 03, 2017, 08:47:29 am
content: Quote from: umamaheswary on June 03, 2017, 08:44:14 amI will have a look at it on Monday, since I don't have any of the tools at home.Quote from: umamaheswary on June 03, 2017, 08:44:14 amBut this means that you will have to enable routing , which meant that all your attempts at making network be fast will not work.You either get fast or full mesh. You can't do both.

author: ataradov
author_rank: Super Contributor
timestamp: June 05, 2017, 06:33:54 pm
content: In this log, 0x1103 (device) talks to 0 (gateway) all the time. There is not a trace of any other device in this log. At the very end it looks like 0 was disabled, but otherwise it looks fine. There was a minor interruption somewhere in the middle of the log, and for that 0xffff was reported, otherwise 0 is reported as the parent (next hop actually) address.So your setup is not linear enough.EDIT: Also, get a real sniffer.

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2017, 04:11:36 pm
content: I understand the scenario, but in your case, the distance between the static devices is too short. Moving devices can always communicate directly, and they chose to do so.Right now the metric for switching is better LQI. You can change that to better RSSI, for example. This will probably help some. But you are basically trying to make the network worse overall. It selects a route with minimum number of hops, and better chance of delivery. You are making it go though a lot of routers, which is generally worse.

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2017, 04:35:23 pm
content: 300 m is enough for direct communication.Again, from a stack point of view there is no problem talking to to gateway directly. That's what it was designed to do.If you want it to talk though the closest router, you need to define what closest means, and then implement that as a link quality metric.

author: ataradov
author_rank: Super Contributor
timestamp: June 16, 2017, 04:48:10 pm
content: RSSI would be a good approximation. But you will also have to kill the discovered route and force route discovery after each frame. Basically it is easier to throw away stack routing, and implement your own.

author: ataradov
author_rank: Super Contributor
timestamp: June 17, 2017, 03:17:56 am
content: You need to change things inside nwkRouteDiscovery.c, specifically nwkRouteDiscoveryUpdateLq() function and the places it is called. You need to map RSSI into the range 0-255, 255 being the best.It will not be super easy without some knowledge of C and wireless networks.

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2017, 03:53:43 pm
content: This is nonsense. All you did is replace lqi with rssi everywhere. There is really no need to do this. "LQ" in the code is already an abstract link quality metric.QuoteRSSI is not mapped to the range of 0-255. So your nwkRouteDiscoveryUpdateLq() does noting useful.Since RSSI is a negative number most of the time, you will probably get something that works in some cases, but LQ of long paths will be a total garbage.

author: ataradov
author_rank: Super Contributor
timestamp: June 21, 2017, 05:17:58 pm
content: LQ is a generic indicator. It can be anything - LQI, RSSI, number of hops. It has values in the range 0-255, 0 is the worst, 255 is the best.nwkRouteDiscoveryUpdateLq() combines two LQ values into a new one. This function is dependent on the exact nature of the LQ. For example if you use a number of hops as a LQ, this function will just subtract 1 from the old value. And the starting value for the LQ must be 255. This way route with LQ 255 will be better than route with LQ 254.You need to understand what values RSSI can take and map them accordingly to LQ range. and also create a proper function that combines two LQ values in a meaningful way.

author: ataradov
author_rank: Super Contributor
timestamp: June 22, 2017, 04:12:45 am
content: There is no threshold to set. You need to define what values of RSSI you consider "good", and what values you consider "bad". And then implement a function that takes raw RSSI value and returns a value in the range 0-255.The most obvious one is something like:Code:if (rssi > 0)rssi = 0;if (rssi < -50)rssi = -50;lq = 255 - 5 * ind->rssi;

author: ataradov
author_rank: Super Contributor
timestamp: June 22, 2017, 04:34:46 am
content: Quote from: umamaheswary on June 22, 2017, 04:31:35 amNo, it is not.nwkRouteDiscoveryUpdateLq() combines two LQs making it possible to figure out LQ of a multi-hop route. In that case it would be unchanged, actually.I can't teach you programming or networking over the forum.If you want to understand what to do, you will have to spend time with a debugger stepping though the code.

author: ataradov
author_rank: Super Contributor
timestamp: June 22, 2017, 07:20:01 am
content: I'm not going to do your work for you.