WSNDemo.c in Lightweight Mesh

Go To Last Post
143 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will try new batteries and check the solder.. because it doesn't make sense not working, because the first board has exactly the same configuration, just the adress was changed.. and it's working fine

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex, I don't know if you can help with this.. and I even don't know if it is the correct topic for it, but taking advantage that we were already talking about this, it is worth trying. The situation is.. I have the coordinator, it works fine.. appears on WSNMonitor, and I also have 3 boards that are configures as routers.. board 0x0001 0x0002 and 0x0003.. they have exactly the same hardware (including the coordinator).. So, when I put the battery.. board 3 connects just after plugin the battery... and the led keeps on, indicating connection was done and it also appear on WSNMonitor. The thing is, boards 1 and 2 just keep blinking and don't connect... I know it's a hard question but.. do you have any idea what's going on? the mcu and transceiver are communicating... and I used a spectrum analyzer to see if any RF signal are emitted by the boards.. and it's ok.. they are emitting. The only parts in the hardware are mcu, transceiver, the oscillator, and some capacitors that shows on AT86RF231 datasheet.... Thanks :D

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would say that you need a debugger and have a look at the status code returned in the appNwkDataConf() function. After that it should be possible to track back to the reason for that status code.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh.. I have a debugger.. I will try to do that and compare with the same status code returned on the board that works fine.. Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no need to compare. On the board that works fine the status is going to be SUCCESS (0). Just let me know what the status is on the board that is not working.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to use the search tool to find insert the break point (in Entire Solution) but AtmelStudio returned that no entry was found :(

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand what do you mean.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry I wrote wrong.. I searched the function appNwkDataConf on AtmelStudio search tool, to insert the break point to use the debbug.. but this function couldn't be found on the code, I don't know why

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't blindly use search, use logic. The function is called appDataConf() and located in the application, as name would suggest.

You always need to go back from the observed behavior. In your case it is "LED does not go steady". Then start looking for something that makes it blink. By doing so you will end up in that function.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes.. that's true.. I'm worried about time, I'm afraid I can't do this on time, that I couldn't see the logic.. I will work on it and post here what I find out.. thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry Alex, I can't run the debugger because the device is not reading the correct voltage of mcu... it's showing 1.1V but when I put the multimeter it shows 2.6V.. maybe it's a soldering problem, I will try to fix that .. thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I could run it.. I used watch on this var appState = APP_STATE_SENDING_DONE; and inserted a break point exactly on this line of code.. so I run the debug and before this line, the value of appState is APP_STATE_WAIT_CONF and after this part it becomes APP_STATE_SENDING_DONE .. I don't know if is this what you told me to do.. Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to check the value of req->status in the appDataConf().

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex.. I don't know if this is a good test, but in this part of code:

if (NWK_SUCCESS_STATUS == req->status)
{
if (!appNetworkStatus)
{
HAL_LedOn(LED_NETWORK);
SYS_TimerStop(&appNetworkStatusTimer);
appNetworkStatus = true;
}
}
else
{
if (appNetworkStatus)
{
HAL_LedOff(LED_NETWORK);
SYS_TimerStart(&appNetworkStatusTimer);
appNetworkStatus = false;
}
}

I have inserted a break point on the first if condition, what I think it is "if connection was successful, enter in the first if, if not, then execute the else command" right ?
So, I went step by step debugging, and on the board that works fine, the debug goes into the if condition if (!appNetworkStatus), so.. it's working.... But on the boards that are not connecting.. the debbug goes into the else.. so they are running different..

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And when watching the value of req->status:
On the board that works:
req->status = 0

On the board that doesn't works:
req->status = 17;

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

17 is NWK_NO_ROUTE_STATUS (0x11). What settings do you have in your configuration file?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The standard configuration.. I have just made this changes:
#define APP_ADDR 0x0001
and I also have uncommented this line

#define NWK_ENABLE_ROUTE_DISCOVERY

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

renanmrg wrote:
and I also have uncommented this line
#define NWK_ENABLE_ROUTE_DISCOVERY

Well, have you uncommented it on all other devices in the network?

All devices in the network must use the same route discovery mechanism.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I did that.. I first uploaded the code to the coordinator with this lines uncommented, and after that I programmed all boards just changing the address

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all, check if how it works without NWK_ENABLE_ROUTE_DISCOVERY.

Debugging AODV discovery without a sniffer might be hard.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I shall comment again this lines on the coordinator and the boards right? I will do this now

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Same thing, it didn't work.. I just don't understand why board 3 works fine.. And also the hardware of boards 1 and 2 seems to work fine.. I used a spectrum analyser.. and they are emitting RF signal... is possible to emit RF signal and the transceiver is not working? Thanks Alex

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does not matter if it works or not. What is the status code?

Also, can you show pictures of your boards, antennas, schematics.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When running the debugger with Route Discovery disabled, the code seems to be stucked somewhere, so I couldn't get the status code on the router, just on the coordinator and it was 16... Also.. I uploaded the hardware schematic and board:
Schematic: https://dl.dropboxusercontent.co...

Board: https://dl.dropboxusercontent.co...

Just a note.. on the schematic it's showing Mega128A.. but I have replaced by Atmega1281.. that's because it's and old schematic..
Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

renanmrg wrote:
When running the debugger with Route Discovery disabled, the code seems to be stucked somewhere, so I couldn't get the status code on the router,
Well, that's time to find out where. It will probably lead you to a reason.

renanmrg wrote:
just on the coordinator and it was 16...
Coordinator is not sending the data, it is impossible to get a status code on the coordinator.

As far as schematic goes, I don't think you need C3. And of course, it is always possible that antenna is not matched.

But you need to take care of that loop first.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wasn't responsible for the antenna development.. my friend did that, and a teacher helped him, I think it's not the ideal antenna but it works since board 3 can connect at a good distance.... Yes.. I will try to find out why board 3 is not stucked and works fine and board 1 and 2 are stucked.. I hope it works :D thanks a lot Alex

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Theoretical design of the antenna is just a start. After it is implemented, antenna has to be tuned and matched.For tuning a good design helps, but does not guarantee a success on a first try. Matching depends on the components used, quality of soldering and other external factors that cannot be predicted at design time.

But all this usually does not matter no short distances and won't cause device to freeze.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huum.. it must be hard to develop a good antenna.. but since I don't need a big distance, there's no problem if they work close to each other.. I just need to find out why some boards works and others don't.. Now I have 3 boards that can connect.. and 2 that can't..

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex, as you said.. on the boards that doesn't work, the req->status is 17, which I can see on the code that means NWK_NO_ROUTE_STATUS.. it means this board can't find the route? or can't "see" the coordinator.. or something like that? Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have read this on the manual:
Then node should create a new entry in the Route Discovery Table with parameters from the current data transmission
request. If the Route Discovery Table is full and a new entry cannot be added, then data transmission request should be
confirmed with NWK_NO_ROUTE_STATUS status.

So, maybe it is not creating and entry on the router discovery table, but I don't know why since there is only one board turned on. Maybe I should program the coordinator again with a bigger router discovery table ?

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On a high level, it can't find the route. This process consists of sending a request and receiving a response. Any of there can fail.

Without route discovery, device will send a broadcast request and wait for an ACK. This lets you check the system part by part. If C will receive the frame, it means that transmitter is working. If R won't receive an ACK, it means that receiver is broken.

If some error status code is returned, then it will tell exactly how any of them is broken.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huum.. Thanks, I will try to disable route discovery and try again to debug :D

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried to debbug with Route Discovery disabled, and the debbuger seems do be stucked in this part of the code:

appMsg.sensors.battery = rand() & 0xffff;
appMsg.sensors.temperature = rand() & 0x7f;
appMsg.sensors.light = rand() & 0xff;

I don't think it means the Tx has a problem, because I think before sending this random datas, the board sends another code to sink or something like that.. maybe I'm wrong

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah! It was the transceiver... Although it seems to work, I replaced it and now board 1 is working too :D

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no way to get stuck in this code even in theory. There is no loops here or in called rand() functions.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see.. but I clicked next step and the debugger does not advance to the next step.. but now that I changed the transceiver board 1 it's working.. I will try the same with board 2 :D

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now they are all working! Thanks Alex... I think they are working fine now. In the end it was a hardware problem. In WSNMonitor each node has this kind of lamp that when you click it turns yellow. Like in this print screen that I have taken: https://dl.dropboxusercontent.co... ..
what is this for? haha Thanks.. now I'm going to read all the SDK manual to learn how to develop my application..

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is lamp sends a command to the node and it blinks. In the current version of WSNDemo it is not supported. It is supported in the next version, which I just submitted for review, so it should hit the web within a week or two.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huum, since my board has only 1 led I think I cannot see it, but the code I will try to do involves sending a command to a node.. so maybe I can see how it works.. but it is for the next weeks.. firts I have to read the manual as I said.. thanks :D

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Alex.. I'm reading about the 2 routing algorithms.. Native and AODV, let just me ask you a opinion... which one you think is better for a small network? about 5 nodes? The only requirement is that the network has to be self organized.. Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For small node count (let's say less than 20) it does not really matter, they both will works almost the same. For larger networks AODV is better.

If it does not make any difference for your application, use AODV, since it is better in theory.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huum.. yes.. thanks :)

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any place where I can find a graphical explanation of AODV, like the one for Native Routing on developer's guide? I'm trying to create one based on what I understood reading the AODV Routing, but I'm not sure my understading is correct. Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex, on AODV I'm not sure about something.. is there one Route Discovery Table for each node or just one for the whole process of discovering ? I have read the page many times and I still can't be sure... Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

renanmrg wrote:
Is there any place where I can find a graphical explanation of AODV, like the one for Native Routing on developer's guide?

Here you go.

Comments to slides about AODV:

Numbers on the links show LQI of a link
We will focus on the node 0, the rest of them behave similarly

Step 1:
Numbers on the arrows - /.
Route Discovery is a local broadcast frame, each node creates a new Route Request frame with updated LQ information.

Node 0 sends out a Route Discovery Request frame with LQ set to 255, since it is an original frame.
Nodes 1, 3 and 4 receive this frame and update LQ value based on the received LQ and LQI of the received frame.

Step 2:
Nodes 1 and 3 send a Route Discovery Request with updated LQ value
Node 4 sends a Route Discovery Response to the node 0 with a final LQ of the route 0-4.
Node 0 receives the response and updates Route Discovery Table

Step 3:
Node 2 send a Route Discovery Request with updated LQ value
Node 4 sends a Route Discovery Response to the node 3 with a final LQ of the route 0-3-4.

Step 4:
Node 4 sends a Route Discovery Response to the node 2 with a final LQ of the route 0-1-2-4.
Node 3 routes a Route Discovery Response for the route 0-3-4.
Node 0 receives this response and updates its Route Discovery Table since LQ in the response is higher than LQ in the table.

Step 5:
Node 2 routes a Route Discovery Response for the route 0-1-2-4.

Step 6:
Node 2 routes a Route Discovery Response for the route 0-1-2-4.
Node 0 receives this response and does not update its Route Discovery Table since LQ in the response is lower than LQ in the table.
Route discovery is complete. Route 0-3-4 was selected as the most optimal.
Information from the Route Discovery Response is transferred into the Routing Table.

Attachment(s): 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

renanmrg wrote:
is there one Route Discovery Table for each node or just one for the whole process of discovering ?
There is one RD Table on each node. It contains a number of records, one for each new discovery process.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huum, I think now I can understand everything.. Thanks

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, AODV is not specific to LwMesh. It is a well-described protocol - see RFC 3561. Frame formats are obviously different, but the idea is the same.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So... it means in AODV once the best route is selected it never changes right? So, let's say the nodes change their physical location, is better to use native routing algorithm right ?

Renan Margon

Computer Engineer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

renanmrg wrote:
So... it means in AODV once the best route is selected it never changes right?
It never changes if there is no need to, so it is not "optimized".

renanmrg wrote:
So, let's say the nodes change their physical location, is better to use native routing algorithm right ?
Both algorithms will behave them in this case - they will wait until route is declared dead and perform a new discovery.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Pages