Is sending more than 19 bytes of data possible with the EZ430 Chronos?

From MRFI_RADIO_MAX_PKTLEN in mrfi_radio.c we can see that the maximum packet size for this radio is 61 bytes.

Given that the currently specified maximum Simpliciti packet is just 31 bytes (confirmed with sniffer using 19 byte app payload - made up of 1(length)+8(2*address)+19(App Payload)+3(Non secure Network header), there are still 30 bytes free?

I tested the end to end communication (AP and Chronos) with the Maximum Application Payload set to 18 bytes rather than 19 bytes and it worked fine... so there must be some unseen limit at 19 bytes??? Any input welcome :-)

I suspect the problem lies with the EZ430 Chronos SimpliciTI radio receiving stack as I am able to send packets much larger than 19 bytes (40 went fine at the last test) without any problems from the AP. Does anyone have any feedback as to why SimpliciTI seems to restrict receiving packets app payload to 19 bytes?

I never tried Simpliciti since I rolled my own but did you check the packet length settings of both sides? The packet length modes are in the PKTCTRL0 register, bit 1:0. If it's fixed (00), then the PKTLEN register contains the actual packet length. If the packet length is set to variable (01) then the first byte of the payload sets the packet length. Just an idea...

SimpliciTI should allow you up to 50 bytes of application payload data on the CC430 device.  Have you re-compiled the SimpliciTI library code included in the Chronos project?  Note that the SimpliciTI stack is pre-compiled into a library and then included into the Chronos project.  If this library was compiled with a limit of 19 bytes then the dynamic check of your packet being smaller than the size of the output buffer will fail and you will not be allowed to send the packet.

Jim Noxon

Many thanks for the feedback Greg and Jim

Greg, unfortunately I don't think St. Feuillien is in luck as PKTCTRL0, bit 1:0 is set to (01) in all configurations, i.e. variable packet length... hmmm.

Jim, I am sucesfully building the "Unrestricted IAR Workbench" versions of the AP and Chronos projects which, as I understand it, do re-compile the SimpliciTI stack along with ones own code (unlike the "Limited IAR Kickstart" versions).

But, perhaps this assuption was wrong. If so, how does one go about recompiling the SimpliciTI project? There are no other workspace files in the Chronos release so I presume Id have to download some other full version and integrate it... but how?

Thanks again, have a great day, Mike

Nope, Ive double checked that in the "Unrestricted IAR Workbench" project versions, the SimpliciTI code is definately completely rebuilt (I even removed the origional CC430_End_Device_868MHz.r43 library just to be sure). Likewise, other changes Ive made to the SImpliciTI stack (independantly tested) ARE being included and are modifying behaviour correctly.

Interestingly, I am able to transmit greater than 19 byte app payloads from the AP, confirmed with the sniffer (which must ALSO be reading the greater than 19 bytes to display them!) they just arent being recieved by the EZ430 Chronos stack.

Perhaps someone could try simply modifying -DMAX_APP_PAYLOAD=19 to -DMAX_APP_PAYLOAD=20 on their AP and Chronos to see if you encounter the same bahaviour..

Correct, in the unrestricted form, SimpliciTI is completely rebuilt each time you compile.  Note that if you make changes to the .dat files, i.e. change the MAX_APP_PAYLOAD macro, you need to do a rebuild all as the .dat files do not alway properly trigger the correct dependencies in the project build operation.

In the chronos implementation there are two additional macros to manage.

BM_SYNC_DATA_LENGTH which is set to 19 bytes.  This value is used during the sync process and is sent at regular intervals until a link is established.

SIMPLICITI_MAX_PAYLOAD_LENGTH which is set to 32 bytes.  This value is only used when declaring the data buffer array.

There are only three places in the chronos code where calls to SMPL_SendOpt are made,

1. In the sync process (described with BM_SYNC_DATA_LENGTH above)
2. A short 2 byte packet early in the sync process to tickle the access point
3. While in the TX only mode where button and accelerometer data are sent when requested by the AP

If you by chance copied the line from the code using the BM_SYNC_DATA_LENGTH macro for the amount of information to send, then you will always be sending 19 bytes of information.

Your calls to SMPL_Send(Opt) should include the size of your particular message either by using a dynamic variable or the sizeof operator.

Jim Noxon

Thanks Jim

I can confirm that I do clean and rebuild the whole project each time I make a change to the configuration files. - just to be on the safe side.

Likewise, I have already increased these two defines to correspond with the increase in payload... i.e when I tested by increasing the application payload by 5 bytes I made -DMAX_APP_PAYLOAD=24, BM_SYNC_DATA_LENGTH=24 and SIMPLICITI_MAX_PAYLOAD_LENGTH=37. (I also experimented with the MRFI __mrfi_MAX_PAYLOAD_SIZE__ defines but its clear that these are not used when -DMAX_APP_PAYLOAD is specified.

Interestingly, I have just tested that I am able to SEND packets with an App Payload of 24 bytes (i.e. 5 more than 19 default) from the Chronos to the AP where they ARE received and processed correctly.

It is only when I send 24 byte app payload packets from the AP (to which I have made identical stack changes) to the Chronos that they are NOT received... hmm.

TX of well formatted 24 byte app payload packets in both directions has been verified with the sniffer.

I think it may be something in the Radio drivers as I suspect that the incoming packets might not vector correctly into MRFI_RadioIsr().. and hence dont appear in the INQ (queue) and ultimately to the application layer. Any thoughts welcome?

In the access point project, in the simpliciti_main function in the Main_AP_BM.c file, the received packet lengths are explicitly tested against 2, 4, and 19 bytes of length.  Any packets not of these lengths are discarded.  Note that these values are magic numbers and not tied to any macro definitions.

Also, the access point will automatically overwrite the current Link ID if another link is attempted by toggling power on the watch, restarting the watch when attached to the debugging dongle, or if another SimpliciTI node attempts to link with the same Link Token.  The code will handle this quite fine until the number of ports available for a given address runs out which will be somewhere around 30 links from the same address even though there are an additional 220+ Link ID's left to allocate.  Make sure you reset the access point every time you reset the watch to keep your debugging consistent.

Finally, the watch tends to turn off the SimpliciTI stack after many operations and if the ISR sees the stack is shut down, it will not vector to the SimpliciTI stack any packets received.  Search for SIMPLICITI_OFF to find the places where this occurs.

Jim Noxon

Thanks Jon - you are 100% on the ball but alas, none of these excellent thoughts point to the solution... yet... we just need to keep narrowing it down. 

1) My mods to the AP firmware already include the addition of my own incoming packet size magic number (i.e. 24 for now) and this is working fine.

2) I do reset the AP regularly, but as I only see this behaviour with >19 byte packets, I suspect the LinkID list is not key here,

3) I have confimed that the code around the SIMPLICITI_OFF checks is definately not being called inadvertently and as above, because the failure behaviour is only for >19 bytes packets - its unlikely to be the cause.

To summarise the behaviour, following the above detailed changes to the packet size defines, with some standard test Application Layer software and the necessary magic number changes:

<=19 byte packets are being TXd and RXd by both the AP and Chronos without any problems :-)

>19 byte packets are being successfully TXd by both the AP and Chronos, and are being RXd and processed in the AP, but NOT in the Chronos :-(

So, during operation, from observing the Packet Sniffer, in both conditions the bidirectional Join and Link negotiations work fine, then the Chronos starts sending short R2R packets every 2 seconds - no problem. The AP recognises these and transmits a response BUT >19 byte packets are never vectored into the SimpliciTI stack from the radio, whereas <=19 byte packets are correctly received and the application runs fine!

Furthermore, my Chronos Applciation code times out after 30 seconds if no messages are received from the AP, causing the stack to reset and restart. This works fine for both <=19 and >19 byte packets and both the bidirectional reJoin and reLink stages work perfectly, time and time again.... but this gets us back to the condition where the if the AP sends <=19 byte packets there is no problem, but >19 bye packets simply dont appear in the Chronos SimpliciTI stack...and it restarts after 30s again.

As such, I suspect there is SOMETHING in the Radio code causing the mischief, but I cant find it. So... umm.. if you are extremely bored and sufficiently inquisitive, please could you, or someone else, try simply increasing the packet size in the Chronos & AP code to see if you get the same behaviour :-) Best wishes :-)

Have you commented out the calls to the BlueRobin code in the ISR?  You should change this code to simply call the MRFI_RadioIsr function to verify wheter or not the packet is received as expected.

Do you need to keep the BlueRobbin stack in the code?  Are you still trying to keep the GUI operational?  If your final application is ONLY SimpliciTI based, you should download the normal SimpliciTI stack and work from there.  That way you will eliminate all the extraneous stuff not needed.  You can always pull in the driver code for the peripherals and such.

Jim Noxon

Hello Mike,

 I am actually working on the same functionality!

I can help you to debug the code, do you have it on a github repository so I can test it?

I have the IAR workbench 8.11 with CCDEbugger and can flash and debug the CC1111EMK as well as the CC1111 Chronos dongle.

Fee free to get in contact with me.

Regards.

I was able to do so without much hassle. I modified the buffer lengths and simplicity configs to 50 bytes and it is working. I am using the latest version (the white pcb kit).