Atmel Lightweight Mesh stack

Go To Last Post
566 posts / 0 new

Pages

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

Hi, Alex!
I'm trying to port our project to the lightweight stack.
But after examining Your sources I found out that there is no code in PHY part for managing TX_POWER for RFA1/RFR2.
I add code by myself, but I have one question:
Can I change TX_POWER at any time or only at time when there is no transmition... In the documentation nothing mentioned about this...
By default TX_POWER = 3dBm, but it is too much for our controller because we use LNA and its output power is 20 dBm with gain 20 dB...

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

You need to follow the same pattern as for the other parameters. Add a PHY_REQ_* flag, field in PhyIb_t and hangle the request in phyHandleSetRequests(). This will automatically make sure that the radio is in the correct state.

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!
Is it nesessary for You to get such patches of stack code?

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

Not really, at some point I'll add that code myself.

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 again Alex!
I now have peer2peer successfully running as a wireless UART, but am running into a slight inconvenience. The data seems to transmit in bursts. When downloading a file over the configuration, it is not a smooth fast download. It will quickly fill varying blocks, maybe 3-9% at a time, but then it pauses for around a second or more sometimes before doing the next block. I assume this is controlled by the HAL_UART_RX_FIFO_SIZE and TX values. I tried changing them to lower values, but that sometimes causes timeout errors.

Are these the right parameters I should be changing to solve this problem?
Is there any way to transmit the data as it is being received? (so basically just send byte by byte)

Thank you very much for any help you may provide!

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

One second delay is probably a missed ACKs and retries. You might decrease ack wait time in config.h, but you won't get totally smooth flow, sometimes frames get lost.

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

Although, I see that P2P does not use ACKs, so I have no idea where those delays come from. APP_FLUSH_TIMER_INTERVAL should be maximum buffering time.

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

Thank you for the speedy replies again!
I have tried a few different possibilities, but to no avail.
Am I correct in thinking that HAL_UART_RX_FIFO_SIZE in the config applies to the buffer to be filled before wireless transmission? For example, if I wanted a byte by byte transmission, sending each byte as it is received; I should just set both of these values to 1?

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

HAL_UART_RX_FIFO_SIZE is a very temporary buffer, it will rarely have more that 1-2 bytes. Data to be sent is stored in appUartBuffer, but it is flushed every APP_FLUSH_TIMER_INTERVAL ms.

If you want byte by byte transmission, then you'll have to change APP_BUFFER_SIZE, but it will make things much worse, it takes about 3-7 ms to send a frame, it will only be able to handle single key strokes.

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

Hm, OK. Thank you very much for your patience and help! I may have to see if I can figure out what is causing this. Again, thanks for the help!

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

I have a problem with the LightWeight Mesh stack hanging, please see this post for details:

https://www.avrfreaks.net/index.p...

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

Hi, Alex!
Last two weeks I tried to make OTA service working, but with no success...
I fall back to Your WSNDemo, but... nothing...
I tried many things. Made modifications in PHY level, reverse engeneer PHY part of bitcoud stack (by the way, phySetState there doesn't uses FORCE_TRX_OFF state. It issues FORCE_PLL_ON, and according to the documentation this will improve performance of the channel), and so on... But nothing helps...
But the last day, I found in NWK level that data request made from Ind callback is places in NWK frames queue before the ACK frame, and though is sent BEFORE ACK frame...
I.e.: Server sent START_UPGRADE packet and is waiting for ACK, but receive START_UPGRADE_RESP packet, which is filtered put, as state of OTAUs sever is not yet OTA_SERVER_STATE_WAIT_START_RESP...
I think, that code of TX state machine is to be modified. ACK frames must be processed first...

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

Hi Alex,

I found a weird behavior of the stack and don’t know what causes it. I guess it is related to the routing. Let’s have one sender and one receiver. The sender sends a packet (127B) every 100ms, no LwMesh ACK is requested. Everything goes well at this point.

However, when I interrupt a power source for the sender very shortly (300ms, say), the sender starts sending broadcasts - searching for the route to the receiver but the receiver stops react always for the same time (3 sec.). During this 3 sec. time receiver doesn’t answer by LwMesh ACK. How may I avoid it please?

Full size capture at http://goo.gl/2e3J1

Attachment(s): 

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

sleepy_warmcat wrote:
I tried to make OTA service working, but with no success...
What have you tried apart from very low level modifications? OTA should work as is, so the problem is not in the low level code. So can you describe step by step what have you tried?

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

vladacr wrote:
How may I avoid it please?

It is duplicate rejection table at work, your sequence numbers are reset back to 0 and receiver thinks that it receives duplicates. Change NWK_DUPLICATE_REJECTION_TTL to a lower value, so records expire faster.

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 tried so many things, that I don't remember all of them...
But problem was very simple... NWK_MAX_ENDPOINTS_AMOUNT wasn't defined in config.h of OTAUServerDemo... :-)
But with modifications mentioned in previous post...

static inline void phyTrxSetState(uint8_t state)
{
  if (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus)
  {
    TRX_STATE_REG = TRX_CMD_FORCE_PLL_ON;
    while (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus);
  }
  if (state != TRX_CMD_PLL_ON && state != TRX_CMD_FORCE_PLL_ON)
  {
    TRX_STATE_REG = state;
    while (state != TRX_STATUS_REG_s.trxStatus);
  }
}

Of course, in that case we need to define timer with expiration time ~5min to initiate transition to TRX_OFF state
for recalibration to take place (according to documentation)
But I thing that it’s worth the cost as transition time from TRX_OFF state to TX_ARET_ON or RX_AACK_ON takes 110 us, but from PLL_ON to them only 1 us
and

    case PHY_STATE_RX_IND:
    {
      --- cut ---
      PHY_DataInd(&ind);

      while (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus);
      CSMA_SEED_1_REG_s.aackSetPd = 1;
      TRX_CTRL_2_REG_s.rxSafeMode = 0;
      TRX_CTRL_2_REG_s.rxSafeMode = 1;
      phySetRxState();
      phyState = PHY_STATE_IDLE;
    } break;

CSMA_SEED_1_REG_s.aackSetPd = 1;
there is from Bitcloud stack
TRX_CTRL_2_REG_s.rxSafeMode = 0;
TRX_CTRL_2_REG_s.rxSafeMode = 1;
From documentation... to release buffer and to set protection again...
In addition in PHY_Init I add
HAL_RfRxTxIndicatorOn()
which is defined in halPhy()

void HAL_RfRxTxIndicatorOn(void)
{
#ifdef HAL_RF_RX_TX_INDICATOR
  PHY_RxTxSwitcherOn();
#endif
}

and PHY_RxTxSwitcherOn()
in phy.c

void PHY_RxTxSwitcherOn(void)
{
        TRX_CTRL_1_REG_s.paExtEn = 1;
}

and modification in nwkTxTaskHandler to force SERVICE_ENDPOINT frames to send first.
I can send it to You if needed...

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

alexru wrote:
It is duplicate rejection table at work, your sequence numbers are reset back to 0 and receiver thinks that it receives duplicates. Change NWK_DUPLICATE_REJECTION_TTL to a lower value, so records expire faster.
Thank you very much for fast response Alex!
You are right that lower value helps, but I am still not sure about proper behavior or I am just missing something.

I enclosing shorten capture, where you can see that another broadcast (searching for a route) occurs after 7 sec. and even though NWK_DUPLICATE_REJECTION_TTL is set to default 3000ms receiver still suppress it. NWK_DUPLICATE_REJECTION_TABLE_SIZE is 10. Packets are sended every 60ms.

Moreover, even if there was only one Broadcast (seq.1) at the beginning the receiver later suppressing 48 other Broadcasts (seq.2 - 49) at this case.

Full size capture at: http://goo.gl/rBvCO

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

sleepy_warmcat wrote:
Oh! I tried so many things, that I don't remember all of them...

110 us is very small value compared to frame transmission time and other code executing. Do you really need this optimization?

I don't have time right now to go over the code, especially with modification. Have you tried to run stock code? Does it 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

vladacr wrote:
I enclosing shorten capture, where you can see that another broadcast (searching for a route) occurs after 7 sec. and even though NWK_DUPLICATE_REJECTION_TTL is set to default 3000ms receiver still suppress it. NWK_DUPLICATE_REJECTION_TABLE_SIZE is 10. Packets are sended every 60ms.

Duplicate Rejection Table is not only for broadcasts, it is applied to all frames to prevent loops. In this case Seq=1 is lower than Seq=125 that receiving device remembers, so it rejects the request.

In theory when your counter will reach 126 (within 3 second time) that frame will be received.

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 got the WSNDemo ported to work on a new project using ASF in AS 6.1 with STK-600. I am trying to use the ASF driver/service for the UART so I took out all of LwMesh UART code and place the ASF.
My problem is that there must be some collision with the clock handling of ASF because if I run the initialization nothing works, and if I just skip the "sysclk_init()" LwMesh works perfectly but of course the UART output is garbled (I am using usart_serial_putchar() instead of HAL_UartWriteByte())
The init function is like this:
void sysclk_init(void)
{
#if !MEGA_XX_UN0 && !MEGA_XX_UN1
uint8_t *reg = (uint8_t *)&(POWER_REG_ADD);
uint8_t i;
/* Turn off all peripheral clocks that can be turned off. */
for (i = 0; i < NUMBER_OF_POWER_REG; i++) {
*(reg++) = 0xFF;
}
#endif
#if !MEGA_UNSPECIFIED && !MEGA_XX
/* Set up system clock prescalers if different from defaults */
if ((CONFIG_SYSCLK_PSDIV != SYSCLK_PSDIV_8) ||
(SYSCLK_PSDIV_8 != CLKPR)) {
sysclk_set_prescalers(CONFIG_SYSCLK_PSDIV);
}
#endif
}
Could you please point me into what could be colliding?

Thanks,

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

Update:

I changed CONFIG_SYSCLK_PSDIV to SYSCLK_PSDIV_1 and commented the part about turning peripheral clocks off (I did not understand what it has to do with power regulators) and it worked. The funny part is that the function sysclk_set_prescalers(psdiv) does not take into account the sent parameter. It always sets the divider to whatever CONFIG_SYSCLK_PSDIV is set to.

Thanks,

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

alexru wrote:
In this case Seq=1 is lower than Seq=125 that receiving device remembers, so it rejects the request.
I've got it now. So it means that the size of Rejection table is related to the number of nodes in my range.

However, there are still cases when the last received packet was e.g. Seq= 136 and the receiver does answer the following broadcast with Seq=1. But according to your reply 1 < 136. Capture here http://goo.gl/adBg2

BTW: Dont you know, Alex, what value of Duplicate Rejection TTL uses BitCloud? I'd like to compare these two systems in practise.

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

vladacr wrote:
I've got it now. So it means that the size of Rejection table is related to the number of nodes in my range.
Yes, sort of. If they all are expected to sent at about the same time.

vladacr wrote:
However, there are still cases when the last received packet was e.g. Seq= 136 and the receiver does answer the following broadcast with Seq=1.
That is because 136 > 128 :). There is tricky signed integer arithmetic used to define what sequence numbers are just rollover (255->0) and what is actual difference. If you want to know what exactly happens, have a look at nwkRxRejectDuplicate() in nwkRx.c.

vladacr wrote:
BTW: Dont you know, Alex, what value of Duplicate Rejection TTL uses BitCloud? I'd like to compare these two systems in practise.
BitCloud uses different methods for rejecting duplicate broadcasts and unicasts.

For broadcasts it is calculated using a lot of parameters, but for 2.4 GHz range and default network depth it comes to around 500 ms.

For unicasts there is no timeout, records just don't expire. But you don't normally notice it, because if you power of the device it actively rejoins (possibly with a different address), which creates a new record with seq=0.

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,
Now I am trying to setup Lightweight Mesh with RS-485 (Half Duplex). I am using an RS-485 breakout board to achieve this, but it must be triggered to let it know when to transmit or receive. I believe I must use a TXc (transmit complete) interrupt, to trigger from transmit back to receive. I do not know where I would put the other trigger, or if this will even work with how the Lightweight Mesh is setup. Any help would be greatly appreciated.
Thanks!

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

I've never worked with RS-485, but I'm assuming that you need to look at halUart.c file.

LwMesh is a wireless communications stack, it really has nothing to do with serial interfaces.

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

sofakingdom wrote:
Hello Alex,
Now I am trying to setup Lightweight Mesh with RS-485 (Half Duplex). I am using an RS-485 breakout board to achieve this, but it must be triggered to let it know when to transmit or receive. I believe I must use a TXc (transmit complete) interrupt, to trigger from transmit back to receive. I do not know where I would put the other trigger, or if this will even work with how the Lightweight Mesh is setup. Any help would be greatly appreciated.
Thanks!

Hey, I am also using RS-485 in my project with LightWeight Mesh. I would recommend to copy the UART library source used by LightWeight Mesh and modify that to make the flow control work with your RS485 driver.

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

Alex, I have a new issue with the LightWeight Mesh stack getting stuck again, just my luck :-). It is quite random, but it can run fine for a few thousand packet transmissions, then it gets stuck in the while loop of the function:

static inline void phyTrxSetState(uint8_t state)
{
TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
TRX_STATE_REG = state;
while (state != TRX_STATUS_REG_s.trxStatus);
}

The state is 22 (TRX_CMD_RX_AACK_ON), and I believe the function is being originally called via phySetRxState() in the state PHY_STATE_RX_IND of PHY_TaskHandler().

I have no idea what the problem is, I tried atomically protecting that section of code because TRX_STATUS_REG_s is being modified in an ISR, but it did not help. Any insight would be appreciated.

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

Going through the stack, it's not clear where the variable TRX_STATUS_REG_s is being assigned? It's used in conditional statements in a few places, but I can't find where it's assigned any values, is it memory mapped?

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

You should check what is the value of TRX_STATUS_REG_s.trxStatus when it gets stuck.

TRX_STATUS_REG_s is a memory mapped register defined in atmega128rfa1.h.

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, TRX_STATUS_REG_s.trxStatus is set to 9 (TRX_STATUS_PLL_ON?) when it's stuck in the while loop.

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

What frequency your MCU is running at?

I'd start from checking that FORCE_TRX_OFF has finished:

TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
while (TRX_STATUS_TRX_OFF != TRX_STATUS_REG_s.trxStatus); 
TRX_STATE_REG = state;
while (state != TRX_STATUS_REG_s.trxStatus); 

If it does not, I don't even know what to do. This is the first time I'm seeing something like this.

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. The frequency is 8 MHz, I'm running off the internal RC clock for the CPU. One thing to note is that I have several ISRs running in addition to the stack, Timer1, Timer3 and UART0/1 TX and RX. There are a lot of instances in code where I block interrupts (for short durations). Also, the ISR for Timer 3 takes about 500 uS to complete and is called every 2 ms, so significant CPU time is dedicated to it.

I will look into the FORCE_TRX_OFF issue and get back to you.

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

I don't think any of the ISRs should matter for this particular code, transceiver operates in its own clock domain and it is never blocked by anything CPU does. T3 ISR might affect overall radio performance, but in a form of lost frames, not hanging up.

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 makes sense. I'm wondering if my application code is causing this, but as you say, you've never seen this problem before. What's interesting is I'm running a similar application code for the RF on my "master" LightWeight Mesh node, and it has no issues. I'm also debugging a very simple network, just one master and the slave that's hanging. Could noise issues on the transceiver clock be responsible for something like this? I'm not too familiar with how the PLL works.

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

alexru wrote:
What frequency your MCU is running at?

I'd start from checking that FORCE_TRX_OFF has finished:

TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
while (TRX_STATUS_TRX_OFF != TRX_STATUS_REG_s.trxStatus); 
TRX_STATE_REG = state;
while (state != TRX_STATUS_REG_s.trxStatus); 

If it does not, I don't even know what to do. This is the first time I'm seeing something like this.

Hi Alex, I added this code to check FORCE_TRX_OFF, the problem still persists and is getting stuck.

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

In what place? On the first check or on the second one?

16 MHz clock might be a problem here, since only radio uses it by default, the rest of the system will appear to work fine.

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

It hangs in the same spot, the second check.

Can you clarify what you mean by the 16 MHz clock? Are you saying if there are noise issues on that clock the system will appear to run fine even if the RF part has issues. I will try running the MCU clock off the transceiver clock and see how it performs.

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

Hi Alex, I switched the CPU clock to run off the transceiver clock, and I tried a different PCB for the device getting stuck.

The problem still persists, it transmits several hundred packets successfully, then gets stuck while waiting for state 22.

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

Something is wrong here. Your code confirms that it was in PLL_OFF and then it is in PLL_ON while waiting for AACK_ON. I'd check if any of the interrupt routines is writing something to the memory locations it is not supposed to.

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

Alex, in this ISR in the stack:

ISR(TRX24_RX_END_vect)
{
TRX_STATE_REG = TRX_CMD_PLL_ON; // Don't wait for this to complete
phyRxRssi = (int8_t)PHY_ED_LEVEL_REG;
phyRxSize = TST_RX_LENGTH_REG;
phyState = PHY_STATE_RX_IND;
}

The state is set to TRX_CMD_PLL_ON. Isn't there a possibility that this interrupt changes the state while in the phyTrxSetState(uint8_t state) function is running (waiting in while loop)? The state is being modified in both the regular stack code and in the ISR without any protection between the two from what I can see.

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

It looks like there is a problem. But in your case state is set to TRX_CMD_RX_AACK_ON, which means that radio is currently in a state where it can't receive data.

But I see where things might go wrong here. I'll look at it closer.

Can you describe your application, or even give complete source so I could reproduce this on my side?

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

And also, you are confirming that radio is in TRX_OFF state, where it can't receive anything.

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, here is a fix I have for now, it seems to be working but I need to run the test over the course of several hours to make sure it's completely stable:


static inline void phyTrxSetState(uint8_t state)
{ 
  TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
  while (TRX_STATUS_TRX_OFF != TRX_STATUS_REG_s.trxStatus);

  TRX_STATE_REG = TRX_CMD_PLL_ON;
  while (TRX_STATUS_PLL_ON != TRX_STATUS_REG_s.trxStatus);
 
  SREG &= ~(1 << 7);
  TRX_STATE_REG = state;
  while (state != TRX_STATUS_REG_s.trxStatus);
  SREG |= (1 << 7);
}

What I think may be happening is that because I have some CPU-intesive ISRs, things get backed up and the Trasceiver RX/TX ISRs may fire late (they are lowest priority after all). This may create a condition where TRX_CMD_PLL_ON even after TRX_OFF state. But on a more fundamental level, registers changed in the stack code and the ISR should be protected from each other.

I can send you my application code, just let me know how, you can e-mail me at gregor.simeonov@ardapower.com.

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

This "solution" is just a temporary hack, but it seems to do the trick.

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

There is no reason to transition through PLL_ON state. This code will do the same, but better:

static inline void phyTrxSetState(uint8_t state)
{
  ATOMIC_SECTION_ENTER
    TRX_STATE_REG = TRX_CMD_FORCE_TRX_OFF;
    TRX_STATE_REG = state;
    while (state != TRX_STATUS_REG_s.trxStatus);
  ATOMIC_SECTION_LEAVE
}

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

TRX_CMD_FORCE_TRX_OFF is the brute force way. Keep in mind that any ongoing transmit or receive actions are canceled immediately. Normal state changes are queued, that means
ongoing transactions are finished and after that the new
state is entered.

Depending on the transceiver (e.g. RF230) a transition over PLL_ON is necessarry before entering RX_AACK_ON or TX_ARET_ON.

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

Hi!

For those who don't know Atmel made some changes to ATZB-A24-UFLB module.

Does anyone know if this module is going to be supported by Lightweight Mesh?

Regards !

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

What changes you are talking about?

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

alexru wrote:
What changes you are talking about?

I'm thinking about hardware changes, new PA (March 2013).

This module hasn't changed (hardware) for at least 4-5 years(6/2009).

I don't have any samples of this new modules, so how do these change(s) affect considering BitCloud ?

And question from previous post:

xtal_88 wrote:
is this module going to be supported by Lightweight Mesh?

Thnx Alex !

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

PA is just from a different manufacturer, but they all have the same interface. BitCloud will work on it as is.

In LwMesh it is easier to enable PA manually in PHY_Init() than wait for a release that will support it.

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

Pages