Snappy Script Error : Exceed Maximum Packet Size

[rick87]

My snappy script fails to call my RPC on my Synapse Connect Application.
I believe the reason for this is my string argument is fairly large about 108 characters.The default I understand is 75.
So I decided to change the NV parameter (14) - The buffering threshold to the max value which is 123.However I am still getting this error here is what i amd doing on my snappy side

@setHook(HOOK_STARTUP)
def startupEvent():
.......
saveNvParam(14,123)

def someMethod():
mystr = ........ #total characters is 108
return mystr

The above method returns the callback to a function on synapse connect.

[ldnea]

There's a maximum packet size for RPC calls. I'm not quite sure the exact number, and it is longer for multicast vs unicast. I believe that this limit depends on the length of the remote method name, as well as the length of the arguments - I experimentally found that I can invoke a 4-character long method with 1 int argument and a 92-char string second argument max (unicast), and a 95-char string (multicast). I think this limit is mentioned somewhere in the documentation, but I could not tell you where.

[rick87]

Thanks for the reply. However i read that by changing the NV parameters we can extend size of the extended data. My question is why am I still getting this limit when transmitting the data ? Does changing the NV parameter 14 have no affect on the size limit of the packet.

[gvoce]

The entire frame is only 128 bytes long. So, the max you can transmit over-the-air is ~100 to 123 bytes per packet.

NV 14 is a UART setting and controls when the data in a buffer gets transmitted.


This value indicates the total packet size threshold used when sending packets of data. The size defaults to 75 bytes. If no timeout limit is reached first, this parameter will cause buffered data to be enqueued when there is sufficient data to cause the packet, including header, to be at least this many bytes long. At higher serial rates, this size can be overshot between SNAP checks of the packet size. There is no guarantee that packets will necessarily be precisely this size.

This value indicates the total packet size threshold used when sending packets of data. The size defaults to 75 bytes. If no timeout limit is reached first, this parameter will cause buffered data to be enqueued when there is sufficient data to cause the packet, including header, to be at least this many bytes long. At higher serial rates, this size can be overshot between SNAP checks of the packet size. There is no guarantee that packets will necessarily be precisely this size.

[ldnea]

The entire frame is only 128 bytes long. So, the max you can transmit over-the-air is ~100 to 123 bytes per packet.

NV 14 is a UART setting and controls when the data in a buffer gets transmitted.


This value indicates the total packet size threshold used when sending packets of data. The size defaults to 75 bytes. If no timeout limit is reached first, this parameter will cause buffered data to be enqueued when there is sufficient data to cause the packet, including header, to be at least this many bytes long. At higher serial rates, this size can be overshot between SNAP checks of the packet size. There is no guarantee that packets will necessarily be precisely this size.

Useful info. What determines the nominal polling rate of the serial buffers? When using the switchboard from DS_UARTn to DS_TRANSPARENT, is this same polling rate involved to move the buffered serial data to the tx buffer of the radios?

[Jon Wilder]

Useful info. What determines the nominal polling rate of the serial buffers? When using the switchboard from DS_UARTn to DS_TRANSPARENT, is this same polling rate involved to move the buffered serial data to the tx buffer of the radios?

I believe the serial receive handler is interrupt driven and not "polled". Something tells me that in the case of transparent serial mode, the receive interrupt handler just receives the data, then drops it right into the transmit buffer. Thus the frame is sent as each frame is received.

In regards to packet size limit, the 802.15.4 specification limits packet size to 127 octets (i.e. "bytes") This includes the packet header. The message type (whether it's a rpc, mcastRpc, dmcastRpc, etc) along with the name of the function dictates the size of the packet header. So if the packet header is say 25 bytes wide, this leaves a data field of 102 octets long.

A little tip...keep function names that will be called via RPC as short as possible to maximize the size of the data field. The longer the function name, the larger the packet header, and thus the narrower the data field.

As Greg mentioned above, NV13-NV15 pertain to the UART buffers only.

[kbanks]

I believe the serial receive handler is interrupt driven and not "polled".

It's actually a mix... reception of characters is interrupt driven, but the "forwarding" of the resulting packets is driven by a poll.