Hi, im having problems with the transmit request API with a 64bit address.
The documentation states that when transmission of a packet is successfully completed a transmit status packet is sent back to the transmitter. However this doesn’t seem to be happening.
I might be clutching at straws here but i heard somewhere that broadcast mode doesn’t send ACK packets. Is my understanding about broadcast mode correct in that if you suggest a 64 bit address other than 0x000000000000FFFF then the message will be sent in unicast mode and therefore i should receive an ACK?
or is there a setting i must use to set the module in unicast mode ??
I’ve looked at your packet based on my understanding of the documentation, and it seems sane and sensible. I’ve also calculated the checksum, and I agree with your figure of 0x5c. You have a non-zero value for the frame id (packet no), so I’d agree with you that an ACK should be expected.
A helpful answer to your question would then go on to say “Try this next…”.
Unfortunately I don’t have such a helpful answer available. Maybe try this though: assume for the sake of argument that I’m right, and the packet is correct. What else could be causing the problem?
I cant figure it out. Is there any settings on the module i may have set incorrectly???
Im using exactly the same programming method as i would to send the ND - which works fine. but the receive buffer doesn’t seem to fill up at all after this packet is sent. i have even extended the waiting time before looking at the buffer to 10secs and still no reply.
oh btw im using linux if that makes any difference.
if someone out there is good with java could you please have a browse over my code? thanks
Well, I’ve had a quick look at the code and I had a few thoughts.
The transmit_data method will fail if the data count is above 100 bytes (confusion, I think, over whether i is a byte counter or a block counter). Instead of calculating noOfPackets inside the loop, I’d put something like this before the loop header and before the declaration of byte100:
int noOfPackets = int(Data.length() / 100);
if (Data.length() % 100) {
// Need a final smaller packet.
noOfPackets++;
}
Also in transmit_data, after it sends the packet it will wait for a packet to be received (within the timeout) and then exit. You are expecting two packets - the ACK and the plug response - but only the first will be seen.
I’m not convinced that the node_discover method is actually doing what you expect. If there’s more than one node out there, you’re going to receive more than one packet in the 5-second timeout period - yet the code seems to assume just one packet. In fact, even with just one node you’ll receive two packets - one for the node and the second to indicate the end of the scan. Hmm. Could this be the problem? If that second packet is still in the receive buffer, then that’s what transmit_data will see - and it will ignore it.
Unrelated, but I mention it because I noticed it: in plug_response there are two consecutive assignments to the same variable (plug.instantPower). Harmless but presumably not intended.
As well as looking at the transmit_data issue, I’d be inclined to add some diagnostic code to the dataAvailable method, to print all data bytes as they are received. That will tell you whether there’s stuff coming in that the rest of the code is ignoring. Maybe print them in brackets as (7e) (00) (03) etc, so that they’re clearly distinguished from the rest of the diagnostic printout.
Have a go at that lot, and let us know how you get on.
I have done the points mentioned. My code is attached. I also added code to the dataavailable func to output every piece of input data and only the ND responses ever get input to the program and no ACK packets from transmit request.
I believe you’re right about broadcast mode and ACKs. But you’re giving an explicit destination address, so it ought to be using unicast. I don’t know of any other special setting.
A few more comments on the new code, though.
In node_discover, you’re determining the number of response packets by counting the number of 7e bytes. That’s risky, because 7e can also occur as part of the packet payload or as a checksum. I reckon you need to get a bit more complicated and parse the packet length too.
Also in node_discover, you ignore the first received packet as far as the node[] array is concerned. Since nodes might be reported in any order, I can’t see how that makes sense.
Again in node_discover, you’re using an iterator i1. In the loop where you iterate through the nodes, it looks as though you want to compare each node with all the plugs. To do that, you’ll need to reset the iterator each time round the loop. Moving its declaration to the start of the loop would be one way to achieve that.
You’ve changed transmit_data, but not enough I fear! The line “if (i > 100)” doesn’t make sense: i will get to be greater than 100 only if there are more than 100 packets. And two lines further, the condition “if (i != noOfPackets)” will always be true because the for loop header guarantees it. I think you need to delete that whole “if…else” construct, and in the line “cmdData.append(Data)” use the value of i to select the substring from Data that you need for this packet.
Then in transmit_data we have the loop starting “if (!flagack && !flagresponse)”. These two variables are never written to within the loop, so the condition will never trigger. And should that be “||” rather than “&&”?
Regarding that loop, I don’t think the overall logic hangs together too well. If the data to be transmitted is more than 100 bytes, you’re presumably going to expect an ACK for each packet, and then a response from the plug only when it has received the last packet. Maybe that’s a wrong assumption on my part, but if it’s true then the code won’t behave as expected.
And within the loop, when one packet type is detected and decoded you’ll need to remove the packet from the buffer because otherwise you’ll never see the other packet.
Another thing (which I should have spotted before): there are no checks in your code to make sure the whole of a packet has been received before you start decoding it. That seems like a recipe for trouble.
Of course, if the dataAvailable code is really saying that nothing is coming in, then all this is a bit pointless. Maybe you could post that modified code too.
HTH
PS. Does the amount of data to be transmitted in fact exceed 100 bytes? If so, then have a look at the topic “Exceeding the 100-byte limit”. If the data does exceed 100 bytes, you’re definitely going to need to fix transmit_data.
I have done the modifications suggested. however in regards to your points:
2, im only losing the last packet and assuming its the ack. Is that safe ?
6, That loop is more for testing than anything else. at the moment there will be no reply from the receiver of the packet apart from the ack. When i have sorted the receiver i will set the ack to be off completely.
The data is merely a test char to try and get an ack. The data is the char “D” and therefore no greater than 100bytes.
Still dataAvailable is not receiving anything after the transmit request.
Ok, I’m fast running out of ideas here. Here’s another batch of comments on the new code (which otherwise looks good), but since dataAvailable doesn’t report anything coming in I don’t think these comments will be of direct help:
In node_discover you’re now checking the packet length, which is fine. The code should really multiply the MSB by 256 before adding the LSB, but since currently no packet can be as long as 256 bytes the MSB will always be 0 anyway. Just think of it as a suggestion for future-proofing.
In correct_check_sum there are two errors: you need to AND the sum with 0xff, and (presumably as a development workround) after testing the checksum the method returns true whether or not the test passed.
In transmit_data you break a long message into packets, repeating the operation for every packet sent. That code could be moved outside the loop, but I don’t think it’s doing any actual harm. Certainly it’s doing no harm while you’re only sending a single byte of data!
When you check that the packet you’re about to examine has been fully received, you check that rx.length() is the expected length of the packet. Since another packet could by then be sitting in the buffer after it, the test would be better as “>=” rather than “==”.
In transmit_data, after parsing a packet you set rx.length(0), thus losing any further packet that may be in the buffer. You’ll need to just remove the packet itself.
Getting correct_check_sum right may reveal other issues, but apart from that none of these comments will help with the original problem of nothing coming back at all, as proved by the debugging code in dataAvailable().
Final thought: looking back over this discussion, I see we never established what firmware version you’re using. I should have asked that, so I’ll ask it now. If you’re using the latest (10CD I believe) try dropping back to 10C8 to see whether anything changes. And if you’re using earlier firmware, try upgrading to the latest.
Have a look at the new topic “Xbee Initialization”, where the poster is seeing a 10-second gap between the TX and the ACK. Your code gives up after 4 seconds. Could that be it?
i have just looked into how to update the firmware and all methods i can find use XCTU which is a windows only program. is there a method for linux boxes ??
just tried it. The program works but there is no option to select the correct comm ports for Linux. Therefore XCTU does NOT work. I use minicom to send AT commands.
Did you try just selecting COM1? I don’t know much about the available emulators, but (perhaps naively) I’d have expected the emulator to map that to /dev/ttyS0.
If you’re running 10C8, that’s turned out to be pretty stable for me. I admit to not having tried TX on it, but if I can I’ll try to set it up as an experiment. Please don’t hold your breath though.