Discussion thread for future enhancements of the SSC32U board
Acigan International has had private discussions with RobotShop members regarding possible future enhancements to both the Atmel firmware and the board hardware, in order to provide users with even more functionality to an already great board.
This thread topic was now opened to move away from the private conversations and bring the topic matter more into the open in order to gain additional feedback for any future enhancements the board may see in its future.
To begin such, one enhancement that is now purposed is a simple hardware change to two trace lines. That of the TX and RX traces between the Atmel, leading up to the existing TX and RX pins already present on the board.
The change would include two additional pin headers right along side the existing TX/RX pins and a jumper header. If a jumper is installed, the pins function as currently designed, and route any signals from the USB/XBee/TxRx pins thru the jumper and into the Atmel. This then supports the prior versions of the hardware.
However, if the jumper is removed, the TX and RX pins can be routed to an externally mounted microcontroller that can then intercept the signals, process them and then send its own TTL signal back into the Atmel which the board can then process as is.
Here is the design concept behind this simple circuit trace cut/jump.
If the XBee is used for remote communications, currently is only can route SSC32U only commands into the Atmel to process. However, if the trace is cut and controlled with a jumper after the existing TX and RX pins, the signal can be rerouted to an onboard micro processor that can then use the XBee device as a full fledged communication port and process signals that are not just SSC32U specific, but entire communication streams. Then in turn, if necessary, it can transmit its own commands out of its Rx pin and into the Atmel side of the TX jumper port.
When a jumper is installed. the board functions as currently designed. When the jumper is removed and replaced with a microprocessor the XBee serves as the send/receive port to the uProcessor and the installed uProcessor then is able to control the Atmel, locally.
This then expands the board into both a servo controller and a remote transceiver to an onboard micro processor that is able to issue SSC commands locally while still being in communication with its Host using protocols other then just the SSC commands.
This jumper port could also then be used for “Daisy Chaining” multiple boards together, where the signal is rerouted via the trace out of the existing pins, into adjoining boards and all the chained SSC boards then perform the commands together, or if a sight coding change is also implemented in the firmware, to perform a command upon only one of the daisy chained board in the line, using something such as “@03” command prefix, to only have the third board in the chain execute the command instead of all of them (@00 or no prefix = all chained boards). This could be managed by the Atmel firmware or by the additional uProcessor described above as it issues its own commands based on the communications signal it.
Either way, a Daisy Chain concept could be implemented. But to do so, the trace BETWEEN the existing Tx/Rx pins and the Atmel, would require a cut and additional header pins. Oh, and a jumper preinstalled if existing functionality is to be maintained. Jumper removed for enhanced or expanded functionality.
Acigan International currently implements such a concept by way of a stacked XBee footprint breakout PCB inserted into the XBee socket on the SSC32U and then the Bluetooth Bee proper, inserted into the breakout PCB. This was done so the TX and RX signals could be rerouted from the XBee and preprocessed via an onboard uProcessor before the uProcessor then transmits the SSC only commands back onto the SSC32U board and into the TxRX socket holes at the XBee socket. The SSC board is unaware a full communications protocol is happening at the XBee between the Host and the onboard uProcessor.
A simple circuit cut and pin header/jumper installed between the Atmel and Tx/Rx existing pins, would perform the same function, using only a jumper and not a custom XBee PCB. Doing so there instead of at the XBee socket, then would allow all three methods of signals to be intercepted via an on board uProcessor (from USB/XBee/TTL) for existing designs that are using methods other then the XBee for localized issuing of Atmel commands.
Acigan International
Design Division
To further detail what the proposed board modification would allow, here is how the SSC32U boards are used by Acigan International in the AIUnit platforms.
First off, the platform units are autonomous. This means that processing is localized to the unit itself. This is managed by an onboard ESP32 WRover B microprocessor and other supporting devices such as TF/SD card readers, LCDs, chronometers just to name a few. These platforms run the AIU operating system which is the focus of the Project, but Autonomous Interface Units (platforms) were required in order to fully design and test such an operating system.
Under Revision A of development, the AIUos was ported down from mainframe environments to function within the microprocessor realms. Under Revision B, the entire OS was rewritten using Python and MicroPython for more robust and quicker functionality. This functionality allows for Remote Host Level Commands such as “move forward 3 meters” and other interactions that are used by humans at the Host Console. These high level commands are then transmitted to the AIUnits where the onboard processors parse them and determine locally what is required, based on the installed hardware, in order to complete the Host command.
It is here where the SSC32U with an installed BlueTooth Bee comes into play. Using the Bee, the Host transmits the command from the Console, to the remote AIUnit. The onboard Bee receives the high level command, and the TX and RX pins from the Bee are then redirected not to the SSC32U using the existing headers, but thru a breakout PCB that is plugged into the Bee Slot and the Bee is then plugged into the breakout. This is so that the Bee does not directly route the data at the RX and TX Bee pins into the SSC32U. Instead the transmission is redirected to the ESP WRover B and parsed for execution. The Bee is transceiver for the complete AIU protocol, and not limited to strictly instructions for the SSC32U Atmel. Using other onboard devices the AIUnit ranges and computes the three meters from its current position, performs lookups from its onboard data bases that hold SSC instructions and issues the actual Instructions out of its own TX pin and back into the redirected RX pin of the Bee, which is then connected to the SSC32U as if the Bee was sitting in the slot instead of the breakout PCB with Bee on top.
The SSC32U and Atmel then see only the actual commands to instruct the onboard sequencer and servos to physically fire up. At the same time, the WRover B MCU is ranging and recomputing and issuing out telemetry data back to the Host via the Bee and also transmitting any new Atmel Instructions into the SSC32U.
Since the the board only responds to Atmel instructions the current design (without a redirect point in the TxRx traces) current uses of the SSC32U is limited to only full onboard processors connected to the TTL pins or full control applications at a Host to perform every computation. But by simply allowing for the redirecting of TX and RX to be done AFTER the actual TTL pins and not at the Bee slot, full transceiver type functions can be implemented by removing a jumper and inserting an uProcessor onboard, that then sends in actual Atmel commands while also being in direct and full communications with a Host located elsewhere.
The previous AIUnit prototypes under Revision A of the AIUos, used the original SSC32 board which were not equipped with the XBee slot, and had separate dedicated transceivers wired up to perform the same functionality. Since the SSC32U comes with an onboard XBee slot built in, there is no longer a need for a localized uProcessor to have dedicated transceivers and a waste of processor pins to manage them. Simply by redirecting the XBee TxRx signal into a uProcessor and then back out to the SSC32U the same functionality can be achieved with less hardware.
If the SSC32U change proposed is then implemented and the trace is cut and a header/jumper installed after the TTL TxRx pins but before the Atmel, that same functionality would exist not only at the XBee slot but after all three communication ports the board contains, USB/XBee/TTL and the Atmel would never see full communication protocols, it would only see its on instructions that are issued by the inserted uProcessor.
Prior to the simple PCB breakout board in place on a prototype unit here at Acigan, Development used ordinary thru-header sockets inserted into the XBee slot, with the TX and RX pins bent out 90 degrees so that they did not come in contact with the XBee slots. a BT Bee was then inserted into these headers and breadboard jumper wires and a few diode used on the bent pins to perform the interface redirect and manage the voltage level required, from the WRover B 5v down to 3v to and from the XBee. Once the concept was proven in this manor, a PCB was drafted up in CAD and etched for a better appearance then the thru-headers and jumper wires.
However, this method only functions at the XBee port on the SSC32U. The USB port and TTL pins can not be redirected in this manor without cutting the existing traces to severe the signal after the TTL pins but before the Atmel. If this were to be done in a later board revision and done so right next to the TTL pins, a simple jumper can then be used to reconnect the trace to function as is.
Acigan International
Development Division
Testing Division
REVISION PROPOSAL 20221105
ABSTRACT
The SSC32U controller contains XBee headers onboard to allow for XBee devices to be inserted and used for communications in lieu of hardwire connections such as USB or TTL. When an XBee device is inserted by a User (not factory installed/shipped) there exists configuration issues when baud rates higher then the default 9600 baud that is present on the SSC32U and Users desire to increase the baud rates to higher values.
When an XBee device is used as the SSC31U interface the Baud Button on the controller is covered up by the inserted XBee module. The XBee must be removed in order to modify the controller baud rate via the button interface.
TESTED.
Part Number RB-Tys-01, BLUETOOTH BEE
Part Number RB-Lyn-850, LYNXMOTION SSC32U USB SERVO CONTROLLER
TEST PERFORMED
Modification of the default baud rates from factory shipped settings:
Shipped settings SSC32U 9600 baud, Bluetooth Bee ships at 9600 baud for normal communications and 38400 baud for XBee configuration settings. Desired settings for testing, 38400 across all three UART ports.
XBee SW-1 to ON and placed into a XBee breakout adaptor with a USB port attachment. USB port connected to PC. Serial Terminal app used at Host to issue the AT configuration commands for the modification of the XBee configuration parameters. XBee runtime baud rate set to 38400 from the default 9600. XBee device name modified from default also, since multiple platforms use the same XBee device name. Device renamed to differentiate XBee devices between multiple test platforms. XBee powered down, SW-1 set to OFF and XBee inserted into the SSC32U and the SSC32U powered up. XBee active. Host and XBee communicate at 38400. SSC32U does not.
Herein lies the issue –
In order to change the SSC32U to now use the 38400 baud rate, the Tester/User must press the Baud Button on the SSC32U and hold it for about three seconds. However, the XBee in the slot, covers the button completely and it can not be accessed. The SSC32U was powered down, the XBee removed from the slot, the SSC32U was repowered and the button was pressed to indicate current baud rate (Green, 9600) and then the button was pressed and held to enter baud configuration mode, at the alternating LEDs (Red/Green) the button was pressed repeatedly until the solid Red LED (SSC32U at 38400 baud). After configuration write to EEPROM, the controller was shutdown, the XBee reinserted into the XBee slot and the board repowered.
NOW, all three UARTs involved communicate at 38400 with the Host at that baud rate and the controller responds thru the XBee, back to the Host.
PROPOSED RESOLUTION
In the next hardware revision of the SSC32U, the positions of the Timing Crystal and the Baud Rate Button be swapped and the traces rerouted accordingly. Since the Timing Crystal canister will fit under the raised headers of the XBee slot, AND the canister is not a User Interactive component of the board as the Baud Button is, that the two components swap places and the Baud Button would then be accessible without the removal of the XBee from the slot, to reconfigure a baud rate.
It is a known that a Host could also send the new baud rate via a connection in lieu of the interface button, but for the fastest method for setting or resetting a baud rate is the Baud Button.
ADDITION TO USER MANUAL
Based on the above testing, there should be a section added to the SSC32U User Manual under the Baud Rate section currently present. The manual should reflect that if baud rates other then the default factory settings are to be used AND an XBee is already installed in the XBee Headers, or is going to be installed, that the SSC32U Baud Button will be covered by the XBee and no longer accessible without the removal of the XBee device from the Header.
If the XBee is not currently installed, the SSC32U baud rate should be set to the desired rate setting via the Baud Button prior to an XBee device being placed into the Header.
Although one could use an instrument of some type to reach under an inserted XBee and attempt to press or hold the baud button for configurations, this method would be ill advised since circuit damage or Shorts may occur to an XBee device traces on the underside of the XBee device or to the traces on the top side of the SSC32U, if such an instrument were to slip off of the Baud Button when it is to be held down.
As to why Acigan International elected to use the 38400 baud setting is for a matter of later convenience down the road, when developing further using the SSC32U. Most uProcessors support the 38400 speed and it is a stable robust speed in which to transmit and receive data without the use of CRC algorithms, Hashing, or check digits. If the Baud Button is swapped with the Timing Crystal canister, this will then give easier access to the baud configurations when a platform is remote and a direct link to a host can not be performed. The User Interface (baud Button) should not be covered by electronics. Doing so introduces chances of Human Error and Damage since hardware has to be removed and reinserted to access the interface.
ACIGAN INTERNATIONAL
Testing Division
Quality Assurance Division
An alternative to the component swap of the Timing Crystal canister and the Baud Button, would be to keep the existing circuit traces as is, and relocate only the Baud Button and its LEDs interface components to the under side of the controller, using the same trace positions and thru-vias to the bottom of the PCB. If the PCB is a multilayer PCB, the vias would only need a clearing of any traces currently running in the multilayers between the top and bottom of the PCB. This solution may be easier to implement at the trace level then the component swap only at the top layer.
Many cards and boards use this type of dual side component placement. Doing so on this controller would allow an SSC32U to be mounted into a case where all servo cabling is contained and a small window or hole at the bottom of the case to permit a User to access the Baud Button thru the hole and also view the status LEDs , without opening a case and disturbing any cabling on the board within.
ACIGAN INTERNATIONAL
Design Division
Appreciate the insights! Honestly not sure there will still be a button to change the baud rate though, but if there is, it will be in a more suitable position.
1 Like
Without an onboard method? Interesting.
Best implementation for that method would be to use Auto Sense on the pins that match whatever the Host setting is configured at.
That way it is a foolproof configuration at the controller and if the Host has configured the baud rate incorrectly, well, that would be on them (User) and not any type of board issue of the controller. Great way to reduce Support Tickets about incorrect baud settings.
1 Like
REVISION PROPOSAL 20221114
ABSTRACT
Currently the SSC32U Controller has the A thru H pins layout positions as follows:
G 5
o o o A
o o o B
o o o C
o o o D
o o o E
o o o F
o o o G
o o o H
Where the Ground and Voltage pins are next to each other and the logic pins are next to the voltage pins. This positional layout prevents Jumper Shunts to be used to tie the logic pins to ground. Without any connections, the Logic pins read as “1” when the A/F instructions are issued to the controller. This would be the equivalent as a shunt across the 5 and logic pin. With the G pins location as is, no standard 2-pin shunt can be used to tie the logic pin to ground, making a clean board configuration. If shunt connections are to be used to tie to ground, jumper wires have to be used instead, to air gap over the 5 pins to tie the Logics to Ground. This makes for a very messy setup when the Input Pins are to be used for on-board Addressing Configurations, by reading the A/F pins together to arrive at a binary number, 0b00000000 to 0b00111111.
PROPOSAL
5 L G
o o o A
o o o B
o o o C
o o o D
o o o E
o o o F
o o o G
o o o H
The Logic Input Pins bank be swapped with the voltage bank. This layout would place the logic pins in the center, between the G and 5 pins, and achieve a two-fold purpose.
1 - Standard 2-Pin Shunt Jumpers can be used to tie the Logic pins to either HIGH or LOW and result in digital pin reads across pins A thru F, to produce a binary number when the reads for these ports are then combined and used for Addressing Schemes.
2 - Having the 5 and G pins directly next to each other currently, is a mishap waiting to occur. Since these pins could be jumped with a standard shunt, as is, this would result in an Electrical No No since there would be no Load between the connections… Positioning the Logic pins in between the G and 5 would increase the distance between these two pins and prevent any close encountered shorts between the two pins using shunts. This would give an additional safety feature from accidental shorts.
Here at Acigan, there are times when the controller is configured in this manor, using the A/F pins as a board Hardware Address, using Jumpers Wires instead of Shunts, since a standard shunt can not reach to the G pins.
This technique of using the port as an Address, allows Clients with multiple boards, to configure unique Addresses of each board in this manor. Under the Proposal, the use of Shunts would also replace the small and messy looking air gap jumper wires currently used to jump over the 5 and tie a pin to G in order to produce a hardware binary zero.
Development here has come up with some unique ways of making some shunts at times with one method being two standard Null shunts super glued end to end and then driving a construction staple down into the top of the dual-shunt. This allows the shunt sit on all three pins but to span the 5 pin if needed and tie to ground. Standard 2-Pin Shunts are used to tie the 5 to the Logic pin, even though this is not actually necessary and the logic pin can float and be a 1 when digitally input.
Doing so with a shunt allows for a visual confirmation of the binary address, when the port is used as such. Users should not have to resort to such makeshift work arounds with shunts, when Standard 2-Position Shunts are so readily available by the hundreds and would give the board a professional appearance when used.
An in house standard here at Acigan is that if the A-F port has no shunts present, the port is not being used as an Address Scheme. If shunts are present, the board has a hardware address. If the port is connected to anything else, it is reading that connection as HIGH or LOW.
The pins are very useful in a generic sort of way. They are just positioned in a manor that makes Hardware Address Schemes a little messy to look at unless one gets creative in their shunt constructions, when air gap wires just wont cut it, visually.
ADDITIONS TO USER MANUAL
There is also no mention of the pins being internally tied HIGH in the manual. A statement to this should be included in the DIGITAL INPUTS section of the manual so that Users become aware of the internal tie to HIGH whenever one of the pins is floating and without a connection. An attached device to any of these pins would be pulling the input HIGH or LOW, but if a pin is floating, it returns HIGH with a Digital Read and to tie the Float to LOW with a standard shunt can not currently be done.
ACIGAN INTERNATIONAL
Design Division
Quality Assurance Division
An after thought regarding the port itself would be to use a Female Header instead of the Male Pins.
Not only would the port visually indicate, INPUT, by the insertion of a pin into the header, but would allow the existing PCB layout to remain, and if a shunt to G is desired, using a low ohm resister with leads, inserted into the header would produce the desired tie while also providing a very small load between the logic pins and the 5 or G headers themselves.
To clarify regarding the pullup in the manual:
There is a statement that the inputs are pulled up when used as Digital Inputs. What needs to be clarified in that paragraph is for the less informed of electronics type User, and a statement or two added that because of the internal pullups, a reading will return the ‘1’ and not a ‘0’ if a pin is left to float.
Users that have very little electronics experience and obtain the controller to build their first hobby type device, may not even understand why they are always getting 1’s back from the reads, when they logically think that because there is no connection, the read result should be a ‘0’. They may not even know what an internal pull up is.
Which is why that port is tied to 5 or G here, in house. Because many Clients do not understood even basic electronics.
ACIGAN INTERNATIONAL
Design Division
Hi Acigan_International,
Thanks for all the feedback, however the SSC-32U is a hobby grade piece of electronics that we do not plan on updating the design in the near future (due to resources, other priorities and part availability). It’s been as it is for almost 8 years and at least for the moment serves the functions needed in Lynxmotion robotic applications. We will certainly retain your suggestions for when we look into a redesign / update.
All the best,
1 Like
It is already understood the board is not scheduled for any type of revision in the near future.
The posts are being placed here as possible suggestions to be consider, if and when it comes due for one, since there is always ways to improve, even if something is a great Product.
2 Likes
@Acigan_International
Just for completeness, I’d like to mention the SSC-32U’s baud rate can be change through serial commands, too. You can read more about it on pages 34/35 of the SSC-32U manual (PDF). You can read more about reading & writing registers on page 37 of the same document.
3 Likes
Yes. That is a known.
The post was not about actually changing baud rate, it was in regards to the blocked baud button at the hardware level when xbee devices are installed in the xbee slot, and a future change to relocate the button out from under the xbee, when one is installed.
When a User is being instructed manually via a remote Service Engineer, because of a baud rate issue, the user cant communicate to the Atmel onboard anyway, to issue a software baud instruction, because their locally attached host is sending in one speed and the board is receiving at another. So software bauds are useless in that case. So an SE can instruct the User via a phone call to set their host device to a baud, then to press the baud button (per the manual’s steps) to the corresponding baud rate. The issue then arises that the User can not see or reach the baud button without the removal of the xbee, or using some type of method to reach under the xbee to press and hold the button, raising a possible issue of shorting out the board or the xbee or both. Probably the xbee since it functions at 3v and would fry before a 5v short would.
It is understood that a Technical Person could remove the xbee and then reseat it again. But lets assume the User is not Technical and is even afraid to touch the xbee or pull it from the headers, and for that matter, is even afraid to poke around with something (even if non-conductive) and reach under the xbee with it.
In this scenario, the User doesnt understand electronics at all, and thinks its almost voodoo magic that the platform communicates without wires (via a bluetooth xbee) to the host monitoring device, and that the SSC even has shielding and covers over it on the platform, but there is a small access hole to insert a rod into, in order to press the baud button.
The button and the crystal canister should swap places on the PCB so the button is assessable when xbee devices are also equipped, thats all.
The general belief here at Acigan is that both the button and the LED indicator lamp for it be relocated to the bottom of the board, so when its mounted into a housing, the housing can have a small access hole on its underside, for example, so it can be accessed, without cover removals and the wiring of the SCC stays completely under protective housings.
To fully understand the scope of the issue, install a mock pcb with an xbee footprint, into the SSC. Set your host to one baud rate and the SSC to another. Now issue communications. None. The baud rates are not the same so a software baud change can not occur. Either the host moves the rate up or down and pings the SSC with each value until a connection is made, or the SSC is changed manually to match the host value (under the assumption the host value is the correct baud rate since it can be viewed), so that means the SSC has the incorrect setting, so it requires a manual change at the baud button. Now the User opens the housing after being instructed by the Engineer over the phone on how to open it, and peers down at the SSC. " Press the Baud Button", “I dont see any Button”, “It is a black button with a silver case around it.”…“All I see is a silver case thingy, but when I press on it, it doesnt move” “No, not that, that is the timing crystal can, next to it, the button is next to it.”,…“I dont see any type of button, just lights” … The User is correct. The xbee is covering the button,
That is what the initial post was regarding. The relocation of the Baud Button out from under the xbee headers because you cant access it in a normal manor when xbee devices are in the header, and you cant issue a software baud change via communications because the baud rate is not set correctly, but you cant access the baud button to set the rate (without risk of shorts, damage to the pcbs, or removal and reinserting of the xbee again.)
ACIGAN INTERNATIONAL
Quality Assurance Division
1 Like