I’m using the XBee Pro 802.15.4 development kits. I’m attaching the USB XBee to my laptop while the other XBee RS232 module is connected to a camera module called the CMUCam3 (cmucam.org), I’ve set all baud rates to be at 115200 including the laptop port settings. The camera module can communicate with my laptop when connected directly and both XBee modules successfully ran the range test at 115200. I’ve tried to connect the camera module to the RS232 XBee module via the camera module’s UART and also tried the TTL connectors, it seems that the RS232 successfully receives the command from the laptop connected USB XBee to grab image files and I can see that RS232 XBee module green LEDs are turned on and presumeably trying to send out the grabbed image/frame but it doesn’t arrive at the USB XBee laptop side. In the camera software, it shows an error message saying “Frame Grab Comm. Error” in its dialog box. Please help. Thanks.
At 115200 baud you’ll need to configure the laptop to send two stop bits in its transmissions to the XBee. You may also need to configure the camera to send two stop bits, depending on its clock speed. The XBees themselves can be left transmitting one stop bit.
I’m assuming you haven’t tried this because your X-CTU screen shot shows the serial setting as 115200-N-1.
As a quick experiment, you could try reducing the baud rates to (say) 28800. I know that’s a low rate for a camera, but if you get reliable transmission at that speed then it’s a sign that the two-stop-bit solution is all that’s needed at 115200.
If you want more detail on why this works, look for earlier posts in this forum with 115200 in the title.
BTW, thanks for the cmucam pointer - that’s an interesting gadget!
Hi John,
Thanks for the suggestions, i really appreciate ur advice and i still need ur help/advice on tis topic
I’ve set the pc ports to have two stop bits as well as the xbee radios and i’ve also tried interfacing at lower speeds (from 115200 at different intervals down to around 9600) but still no good news. The digi technical support ask me to upgrade to the latest firmware version (10CD) which i did and also said that i might need to use a level shifter (3.3V interface board) between the xbee and the camera (5v cmos). It was recommended to me that i enable hardware flow control.
Hmm. Well, the Digi advice sounds good - did you implement the level shifter and hardware flow control?
I don’t quite understand the reference to 3.3V regarding the level shifter, since the camera is connected to the RS-232 development board according to the photo you supplied. There is a level shifter on the development board, so the camera sees whatever levels that produces.
Perhaps you could post the XBee settings for inspection. I know you provided them in your original post as a screen dump from X-CTU, but it would be easier to process them if you could use X-CTU to save them as .pro files, and attach those files to your post.
I also notice in the screen shots that the NB parameter isn’t shown. If it doesn’t appear in the .pro file, could you check the value by hand (ATNB from the X-CTU terminal window) and post it? Thanks.
Meanwhile, it might be worth checking the communication by attaching the camera XBee to a PC and making sure the two PCs communicate successfully. That should help to isolate the problem.
I’ve managed to establish hardware flow control to the Xbee radios and the port settings but i can’t do that for the RS232 XBee module in the “PC Settings” tab in X-CTU, but i managed to set all XBee radio values to have RTS flow control at D6.
I’ve tried connecting the camera and the XBee via the RS232 connection as well as the TTL connection from the camera to the XBee but both connections don’t work. In fact, it seems that there’s no communication when it’s connected via RS232 (no green LEDs) but there’s some sort of a communication when it’s done over TTL (green LEDs on), but still no data is being transferred from the camera connected XBee to the PC connected XBee. I received a reply from another person sayin that the XBee is TTL and the RS232 connection won’t work with the camera module, so perhaps after all there’s really a need for a level shifter between the camera’s (5V) TTL port and the XBee (3.3V)?
I’ve tried connecting the camera directly (Uart port) to my laptop (RS232) and it works seamlessly over any baud rate.
If you connect the XBee directly to the camera (ie without using a development board) then you will need a 3.3V to 5V level shifter and the one you reference would be suitable.
If you want to use the RS-232 development board, you’ll need a level shifter between that and the camera which will convert between RS-232 levels (±12V) and the camera’s 5V signals. Ah, but see below.
So you’ll ideally need a level shifter either way, but which one depends on whether you use the development board.
There is a pullup resistor in the XBee on the UART data in line. Disabling that may make a difference: set the PR parameter to 0x7f to do that.
The fact that the camera works ok when connected to the laptop implies two things:
The laptop serial port is happy to work with the 5V signal from the camera, and the camera didn’t blow up when connected to the laptop port. So the 5V levels do appear to interwork with RS-232.
The laptop and camera have compatible baud rates. That means you will want to set the camera to generate two stop bits. Have you tried that?
I recently discovered that the camera itself has a level shifter via the serial bypass jumper (page 7 & 9 of pdf camera datasheet, tried to attach the file but it’s 1.97mb —> http://www.cmucam.org/wiki/Documentation ).
I’ve removed the jumper but still no positive result
Actually when the camera was directly connected to the laptop port via RS232, it was not powered from the laptop. Instead it’s powered separately from 4 AA batteries in series.
Another observation: in your .pro files the RO parameter is set to zero. That’s likely to slow the communication down because RF transmission will consist of many small packets. The default value of RO is 3, which would probably give better results.
Sorry for the late reply John… Ya, i did tried to set to 2 stop bits but it doesn’t work. Another fren of mine says that i should set the RO value to 0 as it transmit each byte immediately without waiting for more characters. Anyhow, i’ll give RO=3 a try
Thanks for the pointers
