Atmel Lightweight Mesh-wrong lenght packet

[bigsotos1]

Hi there.
 
  I am using two customs boards with atmega128rfa1 and wsndemo from LwMesh_1_1_1 (because i want to use the OTAServerDemo from the same package ).
  I have write a terminal-like program to read the incoming data-bytes.
  One board is the coordinator and the other one is the router.The lenght of the package from coordinator to pc is 60 bytes.For router,the same.

 My problem is:
As i wrote before,the normal lenght of the packet from coordinator (on UART) to pc is 60 bytes.
But ,some times cordinator sending 61 or 59 or 58 or less  bytes to pc.After this , the terminal program is stop responding.

Also i  have another problem too.
The first time,coordinator sending to pc its packet and after some time -lets say 100 ms-coordinator sending router's packet.
Second time , coordinator sending its packet and after 90 ms,coordinator sending router's packet.
Third  time , coordinator sending its packet and after 80 ms,coordinator sending router's packet and so on.
Finally, coordinator sending its packet and after 0ms,coordinator sending router's packet ,all  as one (lenght packet  becames 120 bytes).
After this, coordinator stop sending data to pc, but i can still send commands-data to router with out problems.
I have try to change the baudrate (9600 or 600) but the some problem .
Also i have try to change  APP_SENDING_INTERVAL from 2000 ms to 4000ms or more ,but the same thing.
I know that the problem is not on the terminal program because i have test it with another board (Arduino Uno).
I have the same problem with smaller packets  of 10 or 20 bytes.

OTAServerDemo is working ,without problems,for both boards.The distance between boards  is about 10 cm.

Can anyone tell me what the problem might be or what i have to look for?
Why is this happening?

Any ideas are welcome.

Thanks in advance.

[ataradov]

What application are you talking about? If this is WSNDemo and its standard protocol, then it is not a fixed length encoding. You can't just read a fixed number of bytes, you need a state machine that looks for frame start, frame end, and byte stuffing characters.

[bigsotos1]

Thank you Alex for your reply (that was fast!!!).
 I am using the   wsndemo.c   from your post at  http://www.avrfreaks.net/forum/sending-data-coordinator-routers-and-end-devices  , post #10.
I am reading the bytes as hex.

[ataradov]

That code still uses byte-stuffing protocol. You need a state machine to parse this protocol. The encoding happens in the function appSendMessage().

Your options are to either remove the encoding, but then you will not know where frames start and stop in case you lose one byte. A better option (the only one for actual long running applications) is to use a state machine and parse the incoming stream and remove byte-stuffing. This way you will be able to safely discard frames that are incomplete. Somewhere on AVRFreaks I posted a Python code example for such a state machine. I'll post it here if I find it.

Here is the code:

Code: [Select]

global parseWSNDemoData
def parseWSNDemoData(buf):
  import struct
  def get(d):
    d.reverse()
    res = 0L
    for i in d:
      res = (res << 8) | i
    return res

  res = {}
  res['messageType']     = buf[0]
  res['nodeType']        = buf[1]
  res['extAddr']         = get(buf[2:9])
  res['shortAddr']       = get(buf[10:11])
  res['softVersion']     = get(buf[12:15])
  res['channelMask']     = get(buf[16:19])
  res['panID']           = get(buf[20:21])
  res['workingChannel']  = buf[22]
  res['parentShortAddr'] = get(buf[23:24])
  res['lqi']             = buf[25]
  res['rssi']            = struct.unpack('b', chr(buf[26]))[0]
  res['boardType']       = buf[27]
  res['sensorsSize']     = buf[28]
  res['battery']         = get(buf[29:32])
  res['temperature']     = get(buf[33:36])
  res['light']           = get(buf[37:40])
  return res

# WSNDemo protocol state machine. Must be caled on every received byte.
# If correct (length and check summ) frame received data (decoded)
# returned, otherwise Null returned.
global smState, fullData, dataBuffer
smState = 0
def WSNDemoProtocolSM(c):
  global smState, fullData, dataBuffer
  IDLE_STATE       = 0
  IDLE_CMD_STATE   = 1
  RCV_STATE        = 2
  RCV_CMD_STATE    = 3
  RCV_CSUMM_STATE  = 4

  if smState == IDLE_STATE:
    fullData = []
    dataBuffer = []

  fullData += [c]

  if smState == IDLE_STATE:
    if c == 0x10:
      smState = IDLE_CMD_STATE

  elif smState == IDLE_CMD_STATE:
    if c == 0x02:
      smState = RCV_STATE
    else:
      smState = IDLE_STATE

  elif smState == RCV_STATE:
    if c == 0x10:
      smState = RCV_CMD_STATE
    else:
      if len(dataBuffer) == 41:
        smState = IDLE_STATE
      else:
        dataBuffer += [c]

  elif smState == RCV_CMD_STATE:
    if c == 0x10:
      dataBuffer += [c]
      smState = RCV_STATE
    elif c == 0x03:
      smState = RCV_CSUMM_STATE
    else:
      smState = IDLE_CMD_STATE

  elif smState == RCV_CSUMM_STATE:
    smState = IDLE_STATE;

    if (len(dataBuffer) == 41) and (c == ((sum(fullData)-c) & 0xff)):
     return parseWSNDemoData(dataBuffer)

  return None

You need to call  WSNDemoProtocolSM() on each received byte, and it will return a decoded packet as soon as it sees a full valid frame. You can rewrite this to any language, of course.

[bigsotos1]

Thank you Alex .

I had read this code ,even before i start to write my own program in Visual C#,because i don't know how to run this Python code.
Anyway i will try to fit (translate to Visual C#)  your code to my program.

Thank you again.

[ataradov]

In any case, you need to look at what appSendMessage() does, and write the code that can revere its effect.

The main idea here is to have { 0x10, 0x02 } as a message start sequence, { 0x10, 0x03 } as the end of the message (followed by the check sum). And all occurrences of 0x10 in the message are replaced with 0x10, 0x10. This way, when you see 0x10, you can look at the next byte and see what it means.

[bigsotos1]

In my proggram ,i can read all the data (PAN_ID,analog_values,MAC_Address.working channel)from the the incoming frames,based on start ,stop  and crc bit.

My problem is that i can not handle the invalid frames (yet).

I  will read your Python code again and i will try to translate to C#.

But any ideas why i have this time  slide that i am writing to my first post?

Why coordinator stops to send data to  pc?

[ataradov]

In my proggram ,i can read all the data (PAN_ID,analog_values,MAC_Address)from the the incoming frames.

If you are just reading fixed values, then you are doing it incorrectly, just try to set your device address to 0x1055 and your thing will break.

But any ideas why i have this time  slide that i am writing to my first post?

Because different frames may have different number of 0x10 bytes in them, so they would be encoded into a different length stream.

Why coordinator stops to send data to  pc?

That is something you will have to debug, I have no idea.

[bigsotos1]

Now i got it!!

Thanks again.