What is the value of TxPower in lwmesh

[umamaheswary]

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

[ataradov]

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.

[ataradov]

If you are measuring range "by eye", then you won't see much difference until you hit 10-15.

[ataradov]

corridor

So lots of reflections, and unpredictable multipath propagation.

routers far from coordinator is directly hopping to the coordinator.

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

The moving device is not picking the nearby routers quickly.Can we do anything in code to pick the nearby routers quickly

Any "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.

[ataradov]

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.

[ataradov]

We have set the APP_SENDING_INTERVAL to 1000.

So your minimal change delay will be 1 second + time necessary to discover a new route.

Can we do anything else in the configuration   to get the nearby parent address immediately?

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

[ataradov]

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

[ataradov]

What are the possible reasons for this ?

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

[ataradov]

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?

[ataradov]

The file attached below

I will have a look at it on Monday, since I don't have any of the tools at home.

yes all devices are in same network.As we posted earlier 2 or 3 routers are fixed in a corridor and have used one device to walk along the way where the routers placed.It was based on the assumption that when the device moves along the router path it picks up near by routers one by one along the path.

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

[ataradov]

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.

[ataradov]

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.

[ataradov]

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.

[ataradov]

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.

[ataradov]

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.

[ataradov]

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.

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.

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

[ataradov]

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.

[ataradov]

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: [Select]

if (rssi > 0)
  rssi = 0;
if (rssi < -50)
  rssi = -50;

lq = 255 - 5 * ind->rssi;


[ataradov]

Understood that this lq should be return from nwkRouteDiscoveryUpdateLq

No, 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.

[ataradov]

I'm not going to do your work for you.