I’m having difficulties controlling a lynxmotion robotic arm using a couple of Digi Xbee PRO 900 and a SSC-32U controller. I’m using the Servo Sequencer Utility V. 2.0.3.3. This program will control the robot fine using the USB Cable but not with the Xbees.
XBEEs config:
The xbees modules communicate well with each other. I set the configuration for the Xbees with XCTU V 6.4.3. Both modules have default config. They are in the same Channel Mask (CM), same Network ID (NI), highest TX Power level, both were configured as Standar Routers [0], baud Rate 9600, no parity[0] for the UART, DOUT and DIN are enabled for UART
XbeeA:
Mac address: (13A200419A11C2), DH: 13A200, DL: 419A11C3
Transmit options 0xC0 (digimesh)
XbeeB:
Mac address: (13A200419A11C3), DH: 0, DL: FFFF (broadcasting)
Transmit options 0xC0 (digimesh)
When testing in the console of the XCTU program, XbeeB receives packets from XbeeA and viceversa.
SSC-32 servo Sequencer:
When using the XbeeA in COM6 on my laptop (windows) and the XbeeB on the SSC-32U board the RSSI LED shouws there’s signal when I’m trying to connect wit XbeeA, but the software sequencer would say “Timed out” after “found” with the baud rate set in 9600. The baud rate in SSC-32U is also set to 9600 by default. But bot LED green and Red are on showing it hasn’t received a proper packets (if I’m not wrong).
Bypass SSC-32 Sequencer:
Since the sequencer would work fine with usb cable I tried to bypass it by sending my own packet via XCTU connected through the USB cable, just to test if I’m sending the correct packets. I just opened the COM port and sent “#0 P1500 #1 P1500 #2 P1500 #3 P1500 T900” and it worked. If I try to send this same packet through XCTU and the Xbees, nothing wont happen. The SSC-32U won’t show any signal of receiving a proper packet to move the robot arm.
I’ll go over each part of your message and try and offer (hopefully) useful advice:
I’ll make a big assumption here and think of the robot as working fine for all intents and purposes (aside from the wireless communication issue).
How did you confirm this? I know this sounds like I’m digging too much, but any detail can be really helpful with this kind of situation.
The best here would be to either have both powered with one connected by a USB adapter and try and find the other (using XCTU) or have both connect by USB and see one echo the others transmissions.
Probably not the case here but be careful to always use the (roughly) minimum power needed for effective communication. Often people assume more power is better but at close range (often the case during prototyping) this can saturate receivers and actually prevent communications! If you are in the same room, with no obstructions and only a few feet/meters away I’d recommend to use a lower power level.
Very good! That is often something that is not noticed easily. I’ll assume the baud rate of your SSC-32U (9600 by default) is still set to 9600 (checked/verified; you can do so with the BAUD button when the board is powered). See the SSC-32U manual page 34 (lower half) for more details about baud rate settings.
The sequencer on connect sends a “VER” command to the SSC-32U which it will respond to with its firmware version. If no response shows up (or a wrong response) then the software assumes it didn’t not find the board. On AUTO mode it will cycle through each port trying to find a SSC-32/SSC-32U.
As mentioned above, confirm this with pressing the baud button while the SSC-32U is powered. Pressing the button once will have it show its current baud rate on LED A/B. A green LED blinking (no red) indicates a baud rate of 9600 (the default).
Indeed, this does indicate the board initialized properly but has not receive a packet yet (LEDs turn off after the first frame). If it receives an invalid frame (such as when the baud rate is wrong or there is noise in the signal) it would blink red. If it receives valid frames it would blink green.
Good idea! This definitely validates you are using the right packets/format/baud rate/etc.
Well, this obviously confirms that the XBee on the SSC-32U never sends anything through (by UART) to the SSC-32U that counts as a frame (valid or not) or that this communication is never seen by the SSC-32U. As you’ve mentioned above both LEDs stay on, indicating no frames received.
While doing tests with the XBee modules did you leave the USB cable connected to the SSC-32U? In case you did not know, the UART bus on the SSC-32U connects to three places:
The FTDI chip that is connected to the USB port. This serves as the USB <> TTL UART adapter.
The TTL UART pins available on the board (TX/RX/GND).
The XBee TX/RX/GND through a voltage shifter (5V DC <> 3.3 V DC).
The subtle - but important - piece of information is that only one of those can be connected at any one time otherwise it will cause interference. If the USB port is connected it will typically dominate the other two and most likely prevent them from working completely.
In theory, the SSC-32U can use any XBee-compatible boards, including many other variants for WiFi, LoRa, ZigBee, Bluetooth, etc. I’ve tested quite a few of those and had good results up to now.
That being said there is one limitation for the SSC-32U: the on-board 3.3 V DC LDO. It does have a current limit which you are most likely exceeding by setting your XBee-Pro XSC (the link you provided) at maximum output power. According to the manufacturer, the maximum transmit power is 265 mA (S3) / 215 mA (S3B). They also mention in some other part of the documentation that you can lower the transmit power to lower transmit current use. This can probably help out in this case and I’d recommend to try that first.
The SSC-32U uses a MCP1700T-3302B(E)-TT, which can provide up-to 250 mA @ 3.3 V DC. That being said there are other components connected to that 3.3 V DC source. Therefore, assume you can safely use at least 150 mA and you should have no issues on that front.
Let us know if reducing the transmit power on the XBee that is on the SSC-32U helps out.
Thank you very much Scharette for anwering so fast. I’m replying just know to let you know that it didn’t work.
I tried setting the transmission power at different levels.
I see that both Xbee transmitters communicate while using XCTU even in different computers and set in transparent mode as standar routers. It’s worth mentioning that XCTU changed their parameters a little bit and there’s almost no guide up to date (ate least I could find any) that also shows any example on hot to get them transmitting through Dout and Din to an Arduino, for example.
I think the problem is in that spefic Xbee Pro XSC 900 transmitter. I cannot get it working even with an Arduino UNO + Xbee shield.
I wanted to see if at least getting it taling to an arduino I could then use TxRx to communicate with SSC-32U board, which is the final goal here, in a wider range than bluetooth. The most I could get was having both Xbee communicating from a laptop and an Arduino UNo, BUT, first I had the remote xbee (the one on the arduino ) connected to XCTU in another laptop. Once the exchanged some messages, I connected the Xbee (hooked in the laptop) to the arduino (powered externally) using some jumpers for Dout, Din, and Gnd from a usb-xbee board.
Again, sorry for not replying sooner, I was trying to figure it out and testing different things before reaching you again. You seem to know about this stuff so can you please help me out here?
The main goal is to send the robotic arm commands “remotely” to the SSC-32U. You already know what we got for that: a couple of Xbee’s pro, antennas, Xbee-usb adapters, recently got two arduino UNO, xbee shields (which are new but also not working with those xbees, i.e. they are not transmitting through Rx, Tx to the Arduino microcontroller).
This is the most up to date XCTU guides: 1 and 2. And this didn’t get me too excited to contact Digi since ours are Xbees Pro S3B.
I was thinking of getting this Bluetooth instead because seems to be the one you guys tested but is limited in range. What else do you recommend?
No problem! I answered as soon as I was made aware of the post and had some time…
I’ll do my best!
That’s quite unfortunate. We at least know that your XBee modules work through UART (since that’s what the USB carrier boards use). For some reason, they just seem to not do that when placed on the SSC-32U.
Yeah, it seems like you are not the only one with such an issue.
Just a random thought from what I’ve read online, but have you checked if there are other firmware versions available for that model? It might simply be a buggy version and/or corrupted (rare/unlikely, but yeah… worth checking!)?
A noble goal! The first thing I did when testing my AL5D/SSC-32U was to use a bunch of Bee-socket compatible modules (ZigBee, XBee S1, Bluetooth, etc.) and see how far I could control the arm from!
After reading this article, I have a feeling that your XBee module on the SSC-32U might boot up in AT or API mode instead of “transparent mode” (where it acts like a virtual serial port adapter) like you expect it to be. Maybe there is a setting that needs changing for this? Since I do not have any S3B I can’t verify this at the moment but it is probably worth a look.
I’ve connected two XBee S1 I had from my tests (from like 3 years ago! ). It seems they were still setup properly (9600 baud, same network ID, etc.). It worked like a charm and I get a SSC-32U response when I send VER\r:
So, yeah, my first guess would be update the firmware of your modules. Second, make sure they do boot up in transparent mode (unsure on this one).
edit:
Also this article from Adafruit mentions the pro models for S3 & S3B have a different pinout! Maybe that’s your issue? I have a feeling that is totally your issue since the SSC-32U board does have a RSSI indicator! That must be what is messing up your XBee Pro S3B module!
I’ll check the SSC-32U schematic and get back to you with what could be done to help on that one.
Obviously, this will require a hardware modification so get your soldering iron and wick ready!
Thank you for the support. I’ll check those links and maybe downgrade the firmware, seems like I have the latest but not sure since the 3 available have different names and no version on it.
When connected to the SSC-32U the RSSI blinks.
I think it has something to do with the mode it is booting in, because seems like the remote xbee needs a message or something so it can start communicating through its Din and Dout. Those pins worked before with the Arduino, but I need to connect the transmitter first to XCTU.
That being said, it may boot in the proper mode but then get messed up by the RSSI pin!
For the SSC-32U the fix would be pretty simple: simply remove the LED.
I’ve checked the schematic and board design files and the connection is direct:
RSSI pin -> LED -> resistor -> GND
Therefore removing the RSSI red LED would sever the connection to that pin and hopefully remove one possible issue from your list of things to check!
). It seems they were still setup properly (9600 baud, same network ID, etc.). It worked like a charm and I get a SSC-32U response when I send VER\r: