Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new

Pages

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

alexru wrote:
If there is no ACK, then confirmation handler will be called in NWK_ACK_WAIT_TIME ms. You should always rely on the confirmation handler, not on some side timer.

I am but what should the wait time be set to? And as network size increase would duration also increase.

At moment it set to 5000ms.

Thanks

Regards

DJ

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

What do you mean "wait time"? Just wait until confirmation handler is called.

LE: Oh, you meant the parameter value? 1 second should be more than enough.

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

Sorry if this a silly question.

I am going to use the following functions to set the reg as shown in the RF233 datasheet for Testing a Psudo randon binary pattern.


uint8_t phyReadRegister_Test(uint8_t reg)
{
return phyReadRegisterInline(reg);
}

void phyWriteRegister_Test(uint8_t reg, uint8_t value)
{
phyWriteRegisterInline(reg, value);
}

Can these be called from anywhere in the main, does the


SYS_Init();
SYS_TaskHandler();

Need to be running.

How can i insure I am getting into test mode,before I actually go into a lab. Can I read an confirmation flag reg?

Thanks

Regards

DJ

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

You need to do that anywhere after SYS_Init().

There is no single register setting that will indicate that device is transmitting CW. The easiest way to check without using special equipment is to configure some other device to send frames on the same channel. If there is CW, device will always get CHANNEL_ACCESS_FAILURE status.

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

That sound good.

What about the main loop application and SYS_TaskHandler(?

I am not using CW but PRBS, am I correct the same would also happen?

To get the CHANNEL_ACCESS_FAILURE status am I correct a message needs to be sent from the lighweight application in normal run mode and confirmation interrupt would inform me this?

Thanks

Regards

DJ

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

djoshi wrote:
What about the main loop application and SYS_TaskHandler(?
After transmission started application must not use the radio, so you might just stay in a while (1) loop after it has started.

djoshi wrote:
I am not using CW but PRBS, am I correct the same would also happen?
Yes.

djoshi wrote:
To get the CHANNEL_ACCESS_FAILURE status am I correct a message needs to be sent from the lighweight application in normal run mode and confirmation interrupt would inform me this?
Correct.

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

Thanks, it helps a lot

What must i do in step 12 shown in datasheet for testing, page 207? There is no indication what I must do what value or reg to use.

Thanks

Regards

DJ

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

Hi Alex

I think I have got something working.

I am using WSNMonitor to see if nodes appear on the network while a test transmission takes places on in the same freq channel, and this is proven to be successful as NO nodes are able to even appear on the network while test RF233 is powered.

But I have got some questions based on what the datasheet mentioned.

This is my code

unsigned read_test_reg=0;
void RFTesting(void)
{
	DDRB |=(1 <<1);
	PORTB &=~(1 <<1);
	PORTB |=(1 <<1);
	phyWriteRegister_Test(0x0E,0x01);
	phyWriteRegister_Test(0x04,0x00);
	phyWriteRegister_Test(0x02,0x03);
	phyWriteRegister_Test(0x03,0x01);
	phyWriteRegister_Test(0x08,0x0F);//Select channel
	phyWriteRegister_Test(0x05,0x00);//Select power
	read_test_reg=phyReadRegister_Test(0x01);//needs to be 8
	phyWriteRegister_Test(0x36,0x0F);//enable continuous tx
	phyWriteRegister_Test(0xff,0x01);//frame buffer	
	phyWriteRegister_Test(0x1C,0x54);
	phyWriteRegister_Test(0x1C,0x46);
	phyWriteRegister_Test(0x02,0x09);
	read_test_reg=0;
	//while (read_test_reg!=0x01)
	{
	read_test_reg=phyReadRegister_Test(0x0F);//needs to be 1	
	}	
	phyWriteRegister_Test(0x02,0x02);
	
	while(1)
	{
		
	}
}

1. The datasheet mentioned setting the frequency channel to 19 which its shows as 0x33, which I think is wrong? As 0x33 in the reg does not exist.

2. How to do I fill up my frame buffer with random bytes, in the correct way. Currently I am doing. This function sets reg but not sends data, please advise me on this?

 phyWriteRegister_Test(0xff,0x01);//frame buffer

Or would I use the following ?

HAL_PhySpiSelect();
  for (uint8_t i = 0; i < 127; i++)
{
   HAL_PhySpiWriteByte(data[i]);
}
 HAL_PhySpiDeselect();

3. I have commented out

 //while (read_test_reg!=0x01)

As datasheet says

Quote:
Wait for IRQ_0 (PLL_LOCK)
The value should be set to 1, which it never does.

But something is working as nodes on the same frequency cannot do much

I have also noticed if I go one channel up, my message do get to the cord as I see them on WSNMonitor but my reply acks for nodes get effected.

Any advice?

Thanks

Regards

DJ

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

In step 12 you need to write data to a frame buffer to a frame buffer (see how PHY_DataReq() does it). Values to write are listed in the table Table A-0-2.

1. 0x33 is a value of the entire register, it contains other settings, not only a channel number.
2. Something like this (not tested):


HAL_PhySpiSelect();
HAL_PhySpiWriteByte(RF_CMD_FRAME_W);
HAL_PhySpiWriteByte(127);
for (uint8_t i = 0; i < 127; i++)
HAL_PhySpiWriteByte(rand());
HAL_PhySpiDeselect();

3. I never wait for this bit, so I have no idea. It locks pretty fast anyway.

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

Thanks

I will make the changes.

Even though I made an error on my code, it some how blocked the frequency . Does the RF233 have default data pattern stored?

rand(), I presume is from standard libary and not from RF233 in built feature.

Thanks

Regards

DJ

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

djoshi wrote:
Does the RF233 have default data pattern stored?
It is a regular data buffer. I don't know what it has by default, most likely all zeros.

djoshi wrote:
rand(), I presume is from standard libary and not from RF233 in built feature.
Any random function will do.

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 have searched RF233 datasheet, but could not find how or what duty cycle of TX packet or frame is. Would you be able to give me indication on duty cycle of a TX.

Thanks

Thanks

Regards

DJ

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

That depends on the application, not the chip.

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 am using the WSNDemo, is there someform of formula that if X bytes are used then duty cycle will be y?

Thanks

Regards

DJ

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

Duty cycle is a ratio of how much time you are spending sending frames to the entire time.

You are likely need this for certification, and if so I'm sorry. There is no real way to estimate duty cycle for a mesh network, because device can send other frames as well, not only its own. You just need to do your best effort estimate.

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

Thanks

How would i do this calculation? Or estimate it?

Would it be in the ms or us range?

Thanks

Regards

DJ

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

Duty cycle is measured in percent.

You can do rough calculation:
1. Take full frame as 5 ms transmission (T).
2. Calculate how many frames you send in 100 ms (N).
3. Duty cycle D = T*N/100 ms.

FCC specifies test duration of 100 ms, if I'm not mistaken. You may chose longer interval, of course.

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

5ms is that max tranmission time? How would I calculate T for my app?

Thanks

Regards

DJ

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

5 ms is a time it takes to send a frame with a maximum payload. Start with that number as a worst case scenario. And if you don't fit into regulatory requirements, then start adjusting it to an actual value.

Exact transmit time of a single byte is 32 us. You also need to add synchronization 5 bytes to a full length of your frame (including all headers and CRC).

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

Thanks,

Thanks

Regards

DJ

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

Hi Alex

As a network increase it size for example a two nodes going through two sets of routers, do I need to keep any setting in mind to insure a good connection/ performance, such as ACK wait time, would this be increased? Anything I need to keep in mind to insure frames do not get lost or get timed out?

Thanks

Regards

DJ

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

If you had reasonably big timeouts (default 1 second is big enough) in a first place, then you don't need to worry about anything.

You really need to try and fix if something does not work, or at least provide your current configuration.

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 have enabled security in my app but it doesn't work properly. My stack is 1.2

The listener and broadcasters are set with

in config.h
#define NWK_ENABLE_SECURITY
#define SYS_SECURITY_MODE                   1
	
in appInit
#ifdef NWK_ENABLE_SECURITY
	NWK_SetSecurityKey((uint8_t *)APP_SECURITY_KEY);
#endif

in appSendData
appDataReq.options = NWK_OPT_ACK_REQUEST | NWK_OPT_ENABLE_SECURITY;

However, there's two issues:
1. The listener is still reading from non-encrypted devices it should not, how can I avoid the listener to read from devices which do not have security enabled and the same APP_SECURITY_KEY?
2. The listener doesn't read from the secured broadcasters. Did I miss anything or set something wrong here? I also tried with SYS_SECURITY_MODE 0 but still doesn't work.

Could you please help?
Thanks

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

srapvn wrote:
1. The listener is still reading from non-encrypted devices it should not, how can I avoid the listener to read from devices which do not have security enabled and the same APP_SECURITY_KEY?
In the data indication callback you need to check that frame was received securely:

static bool appDataInd(NWK_DataInd_t *ind)
{
  if (ind->options & NWK_IND_OPT_SECURED)
  {
    // The message was received securely
  }
}

srapvn wrote:
2. The listener doesn't read from the secured broadcasters. Did I miss anything or set something wrong here?
How do you initialize the request for broadcasts?

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

This is the appInit in broadcaster.cpp

NWK_SetAddr(g_rfAddress);
NWK_SetPanId(g_rfPAN_Id);
PHY_SetBand(0x02);	//CC_BAND 857 to 882.5 MHz
PHY_SetChannel(0x7D);	//Freq = 857.0 MHz + (0.1 * CC_NUMBER)
PHY_SetModulation(0x00);	// added 0x00-BPSK-20, 0x08-OQPSK100
PHY_SetRxState(true);
#ifdef NWK_ENABLE_SECURITY
NWK_SetSecurityKey((uint8_t *)APP_SECURITY_KEY);
#endif
NWK_OpenEndpoint(APP_ENDPOINT, appDataInd);

and appSendData for broadcasters

appDataReq.dstAddr = g_rfListenerAddr;
appDataReq.dstEndpoint = APP_ENDPOINT;
appDataReq.srcEndpoint = APP_ENDPOINT;
appDataReq.options = NWK_OPT_ACK_REQUEST | NWK_OPT_ENABLE_SECURITY;
appDataReq.data = appDataReqBuffer;
appDataReq.size = size;
appDataReq.confirm = appDataConf;
NWK_DataReq(&appDataReq);
appDataReqBusy = true;

I didn't mean to broadcast the messages, broadcasters send data normaly to a listener address.

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

I don't understand. If g_rfListenerAddr is 0xffff, then you should not include NWK_OPT_ACK_REQUEST.

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

g_rfListenerAddr = 0 indeed.
If I lift the NWK_SECURITY_ENABLE out, everything works normally, listener 0x0000 reads from the broadcasters. But if I enabled this option, the listener doesn't receive anything from the broadcaster, nor could I send anything to the broadcaster.

And sometimes, the listener reads corrupted messages that has some correct information in the payload and other information is totally wrong.

Last Edited: Tue. Aug 12, 2014 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what does not work in the second case?

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 security mode is enabled, they can't receive messages on both sides.

And sometimes, the listener reads corrupted messages that has some correct information in the payload and other information is totally wrong.--> This only happens when SYS_SECURITY_MODE = 1 (xtec software mode) even if the listener has a different key than broadcasters.

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

But in item 1 you've mentioned that device receives both secured and unsecured messages.

Something is seriously wrong there. I will need more details of the application. How many devices, what addresses do they have, etc. Share a complete project, if you can.

Also, try stock applications on your hardware and see if they work.

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 made clarification to this item 1.
1. The listener is only reading from non-encrypted devices it should not. (this is before having NWK_IND_OPT_SECURED check in ind->options)

I'm currently testing with only 1 listener 0x0000 and 1 broadcaster 0x0008, both on PAN 4567. The devices are working with Atmel 1284p and at86rf212/b. Broadcaster sends a message every 3 seconds or so.

I tested again and with SYS_SECURITY_MODE 1, listener receives corrupted messages that actually pass through the NWK_IND_OPT_SECURED check (even not with the same security key, one is AKey and one is AKey***).

SYS_SECURITY_MODE 0 doesn't cause receiving corrupted messages though neither can I read anything from both sides.

I'll try to check with the stock application and let you know.
I send you a private message for the application zip file.

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

Quote:
one is AKey and one is AKey***
What do you mean here? The key must be a 16-byte array (string).

I'll have a look at the code later.

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

Many thanks alexru, :mrgreen:

So the key has to be exact 16 bytes string to work. Now it works.

However the corruption is still there with 2 different keys such as:
OneHardKeyToPass
TestSecurityKey0
with SYS_SECURITY_MODE 1

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

I'd use security mode 0 for performance reasons, if possible.

But if you want to make SM=1 work, then you'll have to reproduce the result on on of the standard applications.

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

Hello Alex,

I send you pm on the stock app demo,

Some questions related to the watchdog. My app has a periodic restart timer that calls a while(true){} loop to trigger the watchdog. Sometimes the atmel lightweight mesh gets stuck, it doesn't send nor receive any data, when it gets stuck, either the watchdog interrupt is disabled or the periodic restart timer is disabled. I couldn't yet identify where in the code is the bug as this happens like 1 or 2 devices in an installation of 30-40 devices at our customers' offices so I can't put a debugger for all for them.

So is it possible that the lightweight mesh messed up with my periodicTimer or the watchdog interrupt?
Should I use the avr\wdt.h or LwMesh\sys\inc\sysTypes.h, are they different, which is the enhanced watchdog?
What is the safest way to ensure a periodic restart no matter what happens? Can I trust SYS_Timer_t in this situation?

Many thanks!

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

srapvn wrote:
I send you pm on the stock app demo,
Thanks, I'll look into that.

srapvn wrote:
My app has a periodic restart timer that calls a while(true){} loop to trigger the watchdog.
What is the intent of this restart?

srapvn wrote:
So is it possible that the lightweight mesh messed up with my periodicTimer or the watchdog interrupt?
The timers run in the same scheduling loop, so if "nothing works, it is likely that timers don't work either.

srapvn wrote:
Should I use the avr\wdt.h or LwMesh\sys\inc\sysTypes.h, are they different, which is the enhanced watchdog?
sysTypes.h provides WDT functions for IAR compiler with the same APIs as avr-libc. They are the same as far as functionality goes.

srapvn wrote:
What is the safest way to ensure a periodic restart no matter what happens? Can I trust SYS_Timer_t in this situation?
If you use WDT timer it is intended to be used - as a watchdog, then it will detect "hanging". If you still need to reset periodically for some reason, then use application timer as you do it now in addition to the normal WDT.

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

Quote:
What is the intent of this restart?

Some devices get stuck after several days, not able to send or receive any data, only re-plugging power would restart the device to work normally again. So I did this as a fail-safe attempt. Though when it gets stuck, this periodic restart timer doesn't trigger neither. (or it did restart but didn't send nor receive still).

static void periodicHandler(SYS_Timer_t *timer)
{
	periodicCount++;
	if (periodicCount >= periodicRestartTimerCountMin)
	{
		if(AP_PowerMeterIsEmpty() || (periodicCount >= periodicRestartTimerCountMin + 10 )) // + 10 more minutes
		{
			periodicCount = 0;
			// Trigger the watchdog restart
			while (1) {}
		}
	}
		
	(void)timer;
}

This timer is called every 60s, and count for 120 times = 2 hours, then trigger the watchdog restart. Is there any possible faults in this code you can tell?

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

I don't have time right now to read through your code. One common mistake people make is calling NWK_DataReq() on the same request structure without waiting for the confirmation from the previsions request. This will cause an infinite loop.

The point of WD timer is that you configure how long it should wait to reset the device if it is not "kicked". And then you reset (kick) it periodically, for example from the main loop. You don't need software timers for that.

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

Am I correct in saying that the WDT timer is used by the stack?

I would like to implement as WDT timer that RST my AVR for certain condition(if my app gets into some loop).

I have noticed that when i executed a WDT timer my AVR hangs, and i need to physical power cycle my device.

Till i find the bug that cause my device to loop somewhere i need a WDT.

I did think about using the timers, but i noticed a problem recently . I have a LED that flashes when device is awake, this led was just ON and not flashing. I think my device was in some loop and the timer interrupts were not active as if they were i would see LED flash.

Please advice me.

Thanks

Regards

DJ

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

djoshi wrote:
Am I correct in saying that the WDT timer is used by the stack?
No, what makes you think so?

djoshi wrote:
I would like to implement as WDT timer that RST my AVR for certain condition(if my app gets into some loop).
Feel free to do that.

djoshi wrote:
I have noticed that when i executed a WDT timer my AVR hangs, and i need to physical power cycle my device.
You are probably doing something wrong.

Please create new topics for separate issues, and nor reuse this one.

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

Quote:
No, what makes you think so?

When application task handler function is commented out, i see the wdt rst firing and my debugger going to the first break point. But if application task is not commented out, the rst does happen but i don't go the first break point. If I pause and look under assembler window i see i am stuck on 0000.

I will look into this more,and start a new post if i have no luck.

This is my main function.

int main(void)
{
   wdt_reset();    
   cli();  
   MCUSR &= ~(1<<WDRF);    
   WDTCSR |= (1<<WDCE) | (1<<WDE); 
   WDTCSR = 0x00; 
   sei(); 

   OSCCAL_Calibrate();  
   SYS_Init();

  wdt_enable(WDTO_8S);



  #if APP_COORDINATOR     
  HAL_UartInit(38400);
  #endif
  
  #ifdef APP_ENABLE_OTA
  OTA_ClientInit();
  #endif
  set();

#if RF_TEST
RFTesting();
#else
  while (1)
  {
    SYS_TaskHandler();
    HAL_UartTaskHandler();
#ifdef APP_ENABLE_OTA
    OTA_ClientTaskHandler();
#endif
	
	
APP_TaskHandler();
	
#if APP_COORDINATOR     	
	uart_inbox();
	other_messages();
#endif

  }
#endif  
}

I am doing a small test, where i start the wdt and in 8 seconds i expect a rst. I know for my real application i must add various wdt resets in my code.

Thanks

Regards

DJ

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

The doc said

Quote:
If the frame was sent successfully, the entry score is set to NWK_ROUTE_DEFAULT_SCORE.
Otherwise the entry score is decreased. If the entry score drops to 0, the entry is removed from the Routing Table

Does it mean if NWK_ROUTE_DEFAULT_SCORE is 4 and I send a frame each 5s, if the frame keeps failing, the entry will be removed after 4 * 5 = 20 seconds? (or the entry would be removed right after the first 5s, because of some retry mechanism that keeps decreasing the score anyway?)

Last Edited: Thu. Aug 21, 2014 - 12:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

20 seconds is correct answer. There are no reties in the stack.

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 have 80 devices, each sends a frame per 160s, so ideally the network distributes themselves after a while so each device would have a slot of 2s to send the frame. All are all within 5m of the receiver. Now all of them are plugged in at the same time and start sending to the receiver, however, it takes the receiver a very long time much as 1-2 hours to finally see every one of the devices. What could be wrong with my setup or it is a limitation of the stack as too many route finding broadcasting frames blocks the signal in the beginning?

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

Broadcast frame is re-broadcasted by every device, so it is not one frame every 160 seconds, it is up to 80 frames (realistically not every device will re-broadcast). Use unicasts as much as possible. Or, if all your devices are close, use local broadcasts.

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 for confusion, they all unicast to the receiver, there's no broadcasting. I keep using incorrectly the verb 'broadcast' for 'send/unicast' :p

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

In unicast, initial route discovery still happens through broadcasts. It may be a good idea to stagger the device power on or sending the first frame so that they have a bit more room to discover the route. And then again, if you know that all your devices are within one hop, just use link-local requests.

Also, what are your stack settings?

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, link-local requests are really nice feature, I will try, this is to simulate a situation when there's a power down and up at the installation site.

Stack setting for:

Receiver

#define NWK_ENABLE_SECURITY
#define SYS_SECURITY_MODE                   0
#define NWK_BUFFERS_AMOUNT                  15
#define NWK_MAX_ENDPOINTS_AMOUNT            3
#define NWK_DUPLICATE_REJECTION_TABLE_SIZE  20
#define NWK_DUPLICATE_REJECTION_TTL         3000 
#define NWK_ROUTE_TABLE_SIZE                200	
#define NWK_ROUTE_DEFAULT_SCORE             4
#define NWK_ACK_WAIT_TIME                   1000
#define NWK_ENABLE_ROUTING					
#define NWK_ENABLE_ROUTE_DISCOVERY	
#define NWK_ROUTE_DISCOVERY_TABLE_SIZE		5	
#define NWK_ROUTE_DISCOVERY_TIMEOUT		1500

Devices

#define NWK_ENABLE_SECURITY
#define SYS_SECURITY_MODE                   0
#define NWK_BUFFERS_AMOUNT                  15	
#define NWK_MAX_ENDPOINTS_AMOUNT            3
#define NWK_DUPLICATE_REJECTION_TABLE_SIZE  20	
#define NWK_DUPLICATE_REJECTION_TTL         3000 
#define NWK_ROUTE_TABLE_SIZE                30
#define NWK_ROUTE_DEFAULT_SCORE             5
#define NWK_ROUTE_LISTENER_INIT_SCORE       3
#define NWK_ACK_WAIT_TIME                   1000
#define NWK_ENABLE_ROUTING
#define NWK_ENABLE_ROUTE_DISCOVERY	
#define NWK_ROUTE_DISCOVERY_TABLE_SIZE		15	
#define NWK_ROUTE_DISCOVERY_TIMEOUT			1500

My other idea is to setup a direct link in the beginning to the receiver: So no matter if it fails, it would help at least half of the devices to established a route without needing to broadcast route finding frames. Such as below:

static void createListenerRoute(void) {
	NWK_RouteTableEntry_t *entry;
	entry = NWK_RouteNewEntry();
	entry->fixed = 0;
	entry->score = NWK_ROUTE_LISTENER_INIT_SCORE;
	entry->dstAddr = g_rfListenerAddr;
	entry->nextHopAddr = g_rfListenerAddr;
	entry->lqi = 254;
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In compact networks you can probably do without NWK_ENABLE_ROUTE_DISCOVERY. And creating the route in advance is a great idea.

In any case, I would distribute the initial request randomly over some period of time. Because even if route is know, 80 devices trying to send a message at the same exact time is not the best situation.

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

Thanks Alex, what would be the optimal random interval per devices that they can be safely avoid broadcasting congestion? I use BPSK-20 so each 128bytes frame would take 50ms for a one-way trip.

Pages