Recently i am doing a test, trying to get the temperature of a Watchport/T sensor, but i met some problems.
In my test, I work in API mode, with a stardard XBee module 802.15.4(version 1084) as the coordinator, a Watchport/T sensor and its adapter(i don’t know the firmware version for the XBee module in the adapter, but i know it’s different from the one in the coordinator).
It seems to be no remote AT command in the coordinator for this version, so i tried to send AT 1S command in TX request which allow to get the temperature value, but i never got a response. Is it mandatory to use the remote AT command here to communicate the remote module? if not, what’s the other method? or it’s just because of the different versions firmware of two modules that they can’t communicate? Is it a way to get the Watchport/T adapter XBee module’s detail, such like address, channel, firmware?
What’s more, i’ve tested the communication between two 802.15.4 1084 version XBee modules, the TX request works but just return back the status of the command, to see the reponse i have to open another X-CTU with the end device.
That’s all that i’ve got, hope some of you can help me, lots of appreciation.
I think you should start by upgrading the firmware at both ends, to the same recent version. 1084 is quite old, and there have been a number of improvements in the newer versions. If you can reproduce the problems with the newer versions, you’re more likely to find people who can help.
Also, you mention the AT 1S command, with a digit ‘1’ before the ‘S’. There’s no 1S command, but there is an IS command (letter ‘I’) which I think is what you meant. But maybe that was just a typo in the posting.
For the TX request, what you describe is what I’d expect. The TX request appears on the receiver’s serial port as an RX packet, so unless there’s something on that port to catch the transmission and respond, you won’t see anything other than the returned status packet.
Still can’t work. I notice that when i used minicom, in its status bar, written disconnected(in a real linux machine).But when i tested under a ubuntu system in virtual machine, it works well.Something strange, is this a problem of configuration minicom or it’s a hardware issus, how can i know that?
hi,thank you very much johnf,
You really gave me the idea, I only upgraded the firmware in my coordinator to version 10CD, then it can communicate with the remote module by remote AT command, that’s exactly what I want: it returns not only the status but also the response.
As far as the AT command ‘1S’, I think I wrote the right one, I checked this again in both of the product manual of XBee and XBee Sensor. The IS command is used to force a read of all enabled DIO/ADC lines. The data is returned through the UART. But the remote AT 1S (retrieve sensor data) command through the XBee API and decodes the results.Unfortunately till now I haven’t worked it out.
Another question I found was very strange in my test, I sent a ‘ATND’ command in coordinator’s terminal and I got this:
and then I tried to verify these values by sending an assembly packet to the remote sensor adapter module. I got from SL : 40560BA8, but for SH i got 7D33A200, it seemed to be the right value because everytime I send a AT command, I noticed the source address in the response is like this, but why? I don’t understand why SH is 7D33A200 but not 13A200?
I’m glad the upgrade helped - it’s usually a good idea!
As for the ‘1S’ command, well, I’ve never met it but I assume it’s something special to the sensor. I’ll stop complaining about it anyway
The response to the ND command looks ok. The 7D33A200 address looks as though you’re using API mode 2 (AP parameter), which enables escape characters. In that mode, the byte value 13 is escaped to 7D33, because 13 is the XOFF character and is used in software flow control. The escape mode is described on pages 56 and 57 of the 1xCx product manual. If that doesn’t help, perhaps you could post the actual packets sent and received.
i clearly understand the SH things, and i’ve got what i espect, it’s terrific, thank you very much again your help, johnf
Till now it all works well in windows, but not in Ubuntu, there seems to be some thing wrong in Ubuntu. When i tried to send a AT command by minicom to a Xbee, i saw the green led blinks(means Xbee received the data from serial terminal), and the yellow one blinks too(means Xbee reponse), but i’ve never received a message in my terminal windows, it seems that the serial terminal is blocked, any idea?
My guess is that it has to do with the hardware signals. Linux is generally -clocal, so you’d need to assert Carried Detect (DCD) on the Linux serial port to be able to open it, or set clocal on the port instead (or force DCD if possible).
I’m not necessarily saying that’s what the problem is, its just my best guess.
For what it’s worth, my settings under Fedora are for 9600 baud, 8 data bits, no parity and 1 stop bit, with handshaking set to rtscts. It works for me…
I assume you’ve made sure the permissions on the device file allow you to access it - but then, I imagine minicom would complain if that weren’t the case.
You do have to make sure the Xbee is in AT mode by sending the “+++” sequence before the first command, and it will time out of AT mode after 10 seconds of inactivity (adjustable with the CT parameter). Does the +++ get echoed?
Message was edited by: johnf
unfortunly. no response for ‘+++’,even though i set the samething as you did, 9600 baud, 8 data bits, no parity and 1 stop bit, with handshaking set to rtscts.
Perhaps this is just a question of minicom settings. I’m not actually familiar with minicom itself, but if you have Kermit or can download it, here’s a cut and paste of a session that works for me.
[john@eccles ~]$ kermit -l /dev/ttyS0 -b 9600
C-Kermit 8.0.211, 10 Apr 2004, for Red Hat Linux 9.0
Copyright (C) 1985, 2004,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
(/home/john/) C-Kermit>set terminal cr-display crlf
(/home/john/) C-Kermit>set terminal newline-mode on
(/home/john/) C-Kermit>set terminal echo local
Connecting to /dev/ttyS0, speed 9600
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
The critical part here is the two lines of terminal settings: cr-display crlf, and newline-mode on.
If that works for you, then as admin suggested it would look like a minicom settings issue. If it doesn’t work, try posting whatever did happen.
When you say “still can’t work”, does that mean that you tried to reproduce my session using Kermit, and it failed? If so, it would help if you could post the whole session so that we can all see what Kermit said. Otherwise, I’m afraid you’re really not giving us a lot to work with.
Another question: you say you’ve tried this in a real linux machine and in a ubuntu virtual machine. Was the virtual machine running on the same box as the “real linux machine”?
hi,i’m sorry, this really troubles a lot, my virtual machine is not installed in the same machine as the real unix system machine, but finnaly i found it’s a hardware issue, the serial port didn’t work, i’ve already changed another machine for test, it seemd to work well. thanks a lot for your help, and i think this time i can close this question,lol.