LW mesh stack in  atmega256rfr2 data missing - Page 1
Forum section: electronics / beginners

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 06:17:21 am
content: HI ,I have configured lwmesh for atmega256rfr2 MCU.I tried out with peer to peer application and it works fine.Now I modified the peer to peer code to read data from 4 devices and sends it to a central device(lets call it as a coordinator).The 4 devices gets its data from uart and sends it to coordinator in 1sec delay.The coordinator also reads uart and send some commands to any of these four devices(address specified in the destination address field).I could implement the basic scenario.But I am missing data from any of the devices mean while its running and after 1 or 2 sec it will start sending itself.The baud rate am using is 9600please help to solve it...............

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 06:49:01 am
content: You really need to give more details. What changes have you made to support this 4 device configuration? What does this "But I am missing data from any of the devices mean while its running and after 1 or 2 sec it will start sending itself." mean?

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 07:00:36 am
content: I am attaching the code for coordinator(Peer2Peer_C) and other devices(Peer2Peer_R) also config file

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 07:09:19 am
content: This is a textbook example of unreadable code. I'm not going to waste my time trying to parse this.Code:int flag=0;j=0;for(i=0;i<appUartBufferPtr;i++){if(appUartBuffer==0x40||appUartBuffer==0x4e)flag=1;if(appUartBuffer==0x4d)a=5;else if(appUartBuffer==0x50)a=6;else if(appUartBuffer==0x4e)a=0xffff;if(flag==1){appDataReqBuffer=appUartBuffer;j++;}if(appUartBuffer==0x23||appUartBuffer==0x44)break;//flag=0;}//}int k=j;appUartBufferPtr=k;Also, your addition of appSendDiscoverData() completely broke appDataReqBusy logic, so your appDataReq is not protected agains double use.And you have not answered my other question.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 07:17:45 am
content: Each device sends data from sensors in regular interval. At coordinator level some time stamp data is not received . Let say devices are numbered as 1,2 ,3,4 . At coordinator may get 1 or 2 at a time or 3 or 4 and sometimes 1,2,3 .that y i mentioned data missing ..The appSendDiscoverData () not used now..Also what changes i need to make in configuration to accommodate 4 devices.

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 07:25:59 am
content: What are those regular intervals? You need to start giving information.You may want to increase APP_FLUSH_TIMER_INTERVAL , since you are essentially relying on it for data integrity. Then you need to check if your updates even get into the device. May be you have some UART problem. Then check what status code is returned in the appDataConf().Are you sure that your hardware is working properly?You really need to design application logic properly. Your logic is substantially different from P2P application.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 07:30:11 am
content: Time interval is every one second . Means every one second the devices get data from sensor. Hardware part is working properly . we checked with Xbee modules

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 07:32:27 am
content: Quote from: vishal on March 01, 2017, 07:30:11 amAgain, you have not answered any of my questions ans raised new ones.What was the method of checking? I don't see what Xbee has to do with ATmega256RFR2.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 07:35:28 am
content: sorry .....we think hardware is working because it misses data occasionally.

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 07:37:50 am
content: I've seen plenty of hardware that misses data occasionally. Radio is not a binary thing, signal level can be marginal.You have not said what your hardware is anyway. Is this some standard module or something you designed yourself.And again, do all that debugging I asked you. You won't hear anything new until you do that.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 07:38:17 am
content: Quote from: ataradov on March 01, 2017, 07:25:59 amthe devices get data in 1 sec delay from sensor..then it sends to coordinator...

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 07:49:47 am
content: Quote from: ataradov on March 01, 2017, 07:37:50 amwe did the hardware with reference to atmega256rfr2 altium design provided by atmel. we only doing communication with Tx and Rx pin. We did 4 layer board according to the standard design and also provided 50 ohm matching in rf line. We didn't put 32.786 crystal to TIMER2 pins.

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 07:57:28 am
content: Quote from: vishal on March 01, 2017, 07:49:47 amOk, so it is custom hardware.When you say that stock P2P works fine - what was the method of verification? Have you tried to send a few mgabytes of data and verify it on the other end, or just typed a few characters into a terminal?On a new hardware, even if you don't want to go into proper hardware verification, you need to do some basic stuff. Like check ind->lqi and ind->rssi values in the appDataInd() on the Coordinator, and req->status in the appDataConf() on the devices.Also, change addresses from 0x8zzz to something without highest bit set.If you are expecting some magical solution, there is none, you'll have to debug stuff.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 08:03:50 am
content: Quote from: ataradov on March 01, 2017, 07:57:28 amwe sent a few megabytes of data and verify it on the other end.Quote from: ataradov on March 01, 2017, 07:57:28 amcan you give an example for the address

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 08:05:06 am
content: Quote from: vishal on March 01, 2017, 08:03:50 amI don't understand the question. 1, 2, 3, 4, 5 will work.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 08:08:38 am
content: sorry I got it . I will do necessary changes you have mentioned and try to debug. May I change APP_FLUSH_TIMER_INTERVAL from 20 to 10 ?

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 08:10:52 am
content: You need to understand the logic of this interval. You need to increase it, if anything.There is no way you will make anything work without actually trying to methodically understand and purposefully design things.

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 08:16:35 am
content: sorry for my misunderstanding

author: vishal
author_rank: Regular Contributor
timestamp: March 01, 2017, 10:59:22 am
content: Hi...I Started from the begining..I dowloaded Lwmesh code once again and starts from peer2peer app.Now I just modified APP_FLUSH_INTERVAL_TIME to 50 and has assigned 1,2,3,4 for each of the 4 devices and 0 for the coordinator.Nothing has changed in the peer2peer.c file.The devices now just read uart and send it to coordinator.The devices get data from uart in 1sec delay .Now also it misses data at coordinator side.I contacted hardware team they are confident with hardware.Can I use peer2peer app for reading data from multiple devices??

author: ataradov
author_rank: Super Contributor
timestamp: March 01, 2017, 05:19:01 pm
content: I will ask you one more time to provide me this information:QuoteYou can't just guess, you need to debug.

author: Anu
author_rank: Newbie
timestamp: November 30, 2021, 09:45:03 am
content: Hi,I am using tags which push data to the router and router ushes it to the wifi backbone.There is no coordinator at this setup.The ON time now getting is 70 milli seconds and because of which the battery is only lasting for 6 months.I need to optimize the the process during ON state and reduce it to micro seconds. How can I reduce the time?Thanks

author: ataradov
author_rank: Super Contributor
timestamp: November 30, 2021, 07:30:36 pm
content: All of this is so application-dependent that it is impossible to say anything useful. Have you tried to debug and see what it is doing for those 70 ms?

author: Anu
author_rank: Newbie
timestamp: December 21, 2021, 09:39:22 am
content: Hi,I would like to know how we send packets to xbee module from this stack?Thanks

author: ataradov
author_rank: Super Contributor
timestamp: December 21, 2021, 05:26:13 pm
content: It is impossible to use LwMesh to communicate with XBee modules. They use completely different protocols.

author: Anu
author_rank: Newbie
timestamp: December 29, 2021, 12:31:44 pm
content: when device wake up only calls for route discovery,route update and appsend data functions are executed.I toggle PD6 pin in APP_STATE from wake up to sleep,then captures the pin in oscilloscope and getting 10ms long.Please correct, Iam on the right way to reduce ON time?

author: ataradov
author_rank: Super Contributor
timestamp: December 29, 2021, 07:44:43 pm
content: You need to do more granular measurements. Move the GPIO toggle around the stack and see what takes this long.But also, why does it need route discovery? Normally device will have the route saved from the first wake up. So it is likely that your receiving device does not send an ACK, which would make sending device wait for it.

author: Anu
author_rank: Newbie
timestamp: January 14, 2022, 05:40:28 am
content: Quote from: ataradov on December 21, 2021, 05:26:13 pmThanks.

author: Anu
author_rank: Newbie
timestamp: January 14, 2022, 05:44:43 am
content: Hi,Can we burn the LWMesh to the following controller.https://in.element14.com/microchip/at86rf233-zu/rf-transceiver-2-4ghz-3-6v-vqfn/dp/2775051?st=AT86RF233Thanks

author: ataradov
author_rank: Super Contributor
timestamp: January 14, 2022, 05:48:18 am
content: This is just the radio. It has no processing power or memories, there is nothing to "burn". LwMesh does support that radio, but it needs to run on some microcontroller.