Hi,
I have an ED and an AP device communicating to each other. Both can send and receive messages. When I use SMPL_SendOpt(..., SMPL_TXOPTION_ACKREQ) to request an acknowledge the message is send and also received on the other side but the return-message for auto-acknowledge is not received. The call always returns SMPL_NO_ACK.
What I'am doing wrong?
Marcel de Jong,
JP Systems.
Marcel,
One basic issue would be not compiling both devices with the APP_AUTO_ACK compiler switch defined. However, you should be seeing a SMPL_BAD_PARAM response when trying to tranmsit if this is the case. Here are the other options that I can think of which would create the symptoms you are describing.
1) You are handling incoming packets using the call back function supplied to SMPL_Init. In this case, if you return a non-zero value from the call back function, the receive routine assumes you have taken whatever steps were required from receiving this packet and it is no longer needed. In this case, if an acknowledge frame is required you would have to send it yourself by calling nwk_sendAckReply.
2) the timeout value sReplyDelayScaler is too small. If this is the case, you may need manually tweak the value of this variable. It is calculated in MRFI_Init. I've seen some traffic in this forum claiming the value gets calculated too small but I've never run into issues with it. Another way this could be too short is if you have modified the clock frequency of the processor without adjusting the macro which defines it. This is usually an issue with RF front ends or the CC430 configurations as those processors run quite a bit slower than the 8051 SoC parts. The calculation needs to know the processor clock rate to properly calculate this value.
3) Sending packets via the SMPL_IOCTL function with IOCTL_OBJ_RAW_IO for the object and IOCTL_ACT_WRITE for the action. Using this approach for sending packets does not incorporate the auto-ack feature regardless of it being on at compile time. I don't think this is your issue though since you are calling SMPL_SendOpt to transmit your packets.
4) The end device is a store and forward device (i.e. RX_POLLS is enabled). In this case, the packets are expected to be held on the AP until the S&F device wakes up to receive it. For these devices auto-acknowledges are turned off even if the packet is sent with them enabled. This is by design as acknowledgements are sent by the targeted device and not by any intermediate hops along the way. Thus, if it is an S&F device, it is most likely sleeping so we don't expect a reply any time soon, besides, if we are an end device it is likely we will be sleeping when the target device wakes up and polls for messages so we won't see the reply anyway.
5) The most likely issue is if you send data via the SMPL_LINKID_USER_UUD link ID. This is a connectionless link ID intended for use by the user to gather information about the network or other open ended types of querries. By definition, this link ID resolves to the broad cast address and broadcast messages are never acknowledged. Although your system may only be using two devices, the general form of this message is to communicate to all devices on the network so we really don't know how many acknowledges we should be waiting for. For this reason, SimpliciTI does not acknowledge packets sent to the SMPL_LINKID_USER_UUD link ID. To correct this, you will need to link the two applications via calls to SMPL_Link and SMPL_LinkListen to get a link ID which will resolve between two devices thus enabling acknowledges.
Let me know if this helps,
Jim
If this post has answered your question, even if not the way you wanted, please indicate so by clicking the Verify Answer button on this post.Please start a new thread if your question is not closely aligned with the original post in this thread as it makes searches more effective.If responding to a post please click the Reply button on the post you are responding to rather than merely defaulting to the bottom post.
Jim,
Tnx for your answer. I tried and checked some.
Both devices are compiled with APP_AUTO_ACK activated and I receive SMPL_NO_ACK as result of the SendOpt(...).
1) Yes incomming packets are handled by the call back function. The return from this function is zero. So the receive routine should handle the record and perform the acknowledge.
2) I think that timing settings are possibly the problem. I tried a lot already before to get it right, but none will help to get it better.
3) I don't use the IOCTL_OBJ interface
4) Compiler switch RX_POLLS is not activate on neither side.
5) I checked the LinkID. The LinkID = 0x01 and the two application link to each other through SMPL_Link and SMPL_LinkListen. I don't think this will be the problem.
I think timing is the problem. The sending device sends a message and than waits for the ACK. When no ACK is received it resends the packet fro a number of retries. In the past I had seen the acknowledge but after some changes to the application level there is no acknowledge anymore.
Sometimes even receiving a message is difficult, but several minutes later this will resolve itselfs. Could I have a problem with the RF channel that is in use? On the other hand JOIN and LINK is always working direct.
Marcel de Jong, JP Systems
One last option would be to turn the radio on manally via the following call
SMPL_Ioctl( IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_RXON, (void*)0 );
You should place this on both devices just before entering your normal main loop sections. This will make sure the radio is not turned off between communications. You may need to scrub your code a bit to make sure it is not turned off in other places.
If the above fixes the problem, then you appear correct in the idea timing is an issue. If it doesn't fix the problem then we need to do some more investigation
If it doesn't fis the problem then it appears we need to do some more investigation. Do you have a sniffer setup to watch the traffic in the system? If so, can you verify if the sniffer is seeing the ack reply?
Hopefully you have access to the systems and can connect a debugger to them. In this case, I would first make sure the nwk_sendAckReply function is being entered by placing a break point in it. Then send a message from the other system and see if you are entering this function. You may need to preface the break point with an if statement that counts a certain number of times to get through any initialization communications like link and link listen etc.
If you are entering the nwk_sendAckReply function, then try setting an I/O bit high in the Mrfi_RxModeOn function and set the same I/O bit low in the Mrfi_RxModeOff function. On the tranmsitting device, set an I/O pin high when you enter the mrfi_Transmit function and set it low when you leave it. Then compare these two signals on a scope. The one for the RxModeOn/Off functions should be high whenever the one from the Transmit function on the other device is high. Note the RxModeOn/Off bit could toggle signficantly more than the Transmit function one does but any thime the Transmit function runs, the RxModeOn/Off bit needs to be high. If it is not, then the radio is not in receive mode when the ack is transmitted.
Happy hunting!
Let me know the results,
I already checked yesterday if the nwk_sendAckReply is entered, This funtion is entered thus software in the Receiver is doing what it should do on a receive of the message. I think your are right that I have to check now if real transmitting is happening and on the same time the sending radio is really in RxMode by toggling some I/O. It has worked in the past thus there must be some strange software issue.
I have no sniffer setup available to watch the trafic, but I think its wurthfull to get one.
I keep you informed. Tnx so far.
I have just got a Packet Sniffer configuration and did some tests with it. The ACK record is really sended 2230 us after receiving the packet, but never received in the firmware. So you must be right that after TX the CC2500 is not retrurning to RX state. After some research of the register settings I find out that the MCSM1 register is initialized by SimpliciTI with 0x3C (see MRFI_Radio.c). I changed this initial value to 0x3F (setting: go to RX after TX instead of go to IDLE after TX) and the ACK records are now received. I'am shore that I never changed this setting before but this works!
Is this solution OK? Or can I expect other strange behaviour now?
Other people should have same trouble when using AUTO ACK or not?
Good detective work here!
Your solution could leave the radio on for an extended period of time in the RX state. If you turn off the radio after your call to SMPL_SendOpt then you will probably be OK but I can't know for sure without running a whole suite of regression tests. A safer option that I can stand behind is to add a small delay in the nwk_sendAckReply function in the nwk_frame.c file. The last thing this function does before returning is to call mrfi_transmit. If you were to add the following line of code just before the call to mrfi_transmit
NWK_DELAY( 1 );
it should delay the system long enough to make things work. You can play with the number if you need to for additional margin. It will count about a ms for each count.
It sounds like the processor on the access point may be running significantly faster than the one on the end device. Either that or the data rate you are using for transmissions is very high and/or possibly you have a very short preamble. It certainly seems like the transmission is starting before the radio gets ready to hear it. Normally we test these systems with comparable processors on both ends, but a significant difference in processing speed could cause this. Also, the radio is configured to go through a calibration cycle each time it is strobed into TX or RX. This time should be symmetric on both radios as it is a function of the crystal frequency driving the radio, not the processor speed so both should be delayed approximately the same amount of time when switching modes.
Can you tell me a little more about your setup on both ends with regards to the procesors?
The only other thing I can think of is could other interrupts be causing additional latencies on the end device?
At this point, my best suggestion regarding the smallest impact on code functionality would be the delay described above. It should at least get you operating and we can continue to disect the problem from there.
Regards,
Sorry for digging this post from its grave. :D
But, I am facing the same problem in my project. I need to talk my computer to talk to a robot. I am using ez430-rf2500T as my access point and end device. My code was built on the example code provided by TI for SimpliciTI. My robot uses the interrupts from its encoders (Answering Jim's previous post). I am using SMPL_SendOpt() with auto-ack feature enabled. I have tried all the solutions provided in this post but I am not able to increase my accuracy. Currently, if I send around 50 packets from my computer, generally around 10-15 packets and sometimes even up to 30 packets fail to reach the bot (The return from SMPL_SendOpt() is SMPL_NO_ACK). Others reach the bot in perfect health. I have two queries:
1. Is this to be expected or can I do something to improve the accuracy?
2. There are occasional cases where my robot receives the packet correctly but my computer doesn't receive the acknowledgment. The bot starts processing the packet and my computer continues to re-send the packet. This creates confusion and loss of time. I can come out of this with a convoluted loop at application level but is there something I can do about this too?
Regards and thanks in advance,
Abraham