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
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
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.
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
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.
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 :(
I don't understand what do you mean.
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
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.
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
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
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
You need to check the value of req->status in the appDataConf().
Hi Alex.. I don't know if this is a good test, but in this part of code:
if (NWK_SUCCESS_STATUS == req->status)
appNetworkStatus = true;
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..
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;
17 is NWK_NO_ROUTE_STATUS (0x11). What settings do you have in your configuration file?
The standard configuration.. I have just made this changes:
#define APP_ADDR 0x0001
and I also have uncommented this line
and I also have uncommented this line
Well, have you uncommented it on all other devices in the network?
All devices in the network must use the same route discovery mechanism.
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
First of all, check if how it works without NWK_ENABLE_ROUTE_DISCOVERY.
Debugging AODV discovery without a sniffer might be hard.
So I shall comment again this lines on the coordinator and the boards right? I will do this now
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
It does not matter if it works or not. What is the status code?
Also, can you show pictures of your boards, antennas, schematics.
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:
Just a note.. on the schematic it's showing Mega128A.. but I have replaced by Atmega1281.. that's because it's and old schematic..
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...
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.
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
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.
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..
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
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 ?
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.
Huum.. Thanks, I will try to disable route discovery and try again to debug :D
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
Ah! It was the transceiver... Although it seems to work, I replaced it and now board 1 is working too :D
There is no way to get stuck in this code even in theory. There is no loops here or in called rand() functions.
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
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..
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.
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
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
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.
Huum.. yes.. thanks :)
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
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
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
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.
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
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.
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.
Node 2 routes a Route Discovery Response for the route 0-1-2-4.
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.
is there one Route Discovery Table for each node or just one for the whole process of discovering ?
Huum, I think now I can understand everything.. Thanks
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.
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 ?
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 ?
© 2022 Microchip Technology Inc.