Goliath Tear-Down Project




Starting today with the interior of a tower, just because that’s easy to do on my desk.

The PCB is a custom design.

Power is is a standard 18650 LiPo, looks like it has BMS inside the shrink wrap, and a 3-wire interface. 2 wires for power, third I assume to be temperature - that’s common in single cell LiPo batteries with 3 wires.

CPU is an Arm Cortex M4 with a whopping 64KB of flash memory. Specifically the STM32F302C8, it seems. 72mhz CPU with some floating point acceleration instructions and lots of peripheral support on the various pins.

Wireless is provided by an Olimex MOD-NRF24LR module. This is the interface to the Arm Cortex M4. 2.4ghz and up to about 2mbit/sec data transfer rates.

For the actual sensing, there’s a very well designed hardware reel with an encoder. The spring-loaded reel is nicely aligned by a geared guide that essentially keeps the cord evenly wrapped on the reel so you don’t end up with a tangled mess. This would also help with positioning accuracy as the cord is evenly wrapped consistently on the reel. Quite smart. I didn’t take mine apart enough to see what the encoder is, but the pin-out is marked on the solder mask.

DL1 and DL4 below the encoder appear to be LEDs for the mid-unit LED bar. One is mounted inverted across a hole so it shines out the back of the PCB. I’m sure that’s somewhat common, but I’ve never seen it before.

There’s a “standard looking” 5-pin 2mm (guess) pitch connector on the board, likely for flashing/UART.

Next to it is a smaller pitch set of 10 pins in a 2x5 array. I’d guess JTAG for that, for in-circuit debugging.

In my next tear-down post I’ll pop it under the microscope and try and get some chip IDs for some of the other ICs, so we know what’s doing what.

Some are certainly for power, charging, etc - but others will be supporting the encoder and wireless connection, possibly some external memory, etc.

Hy Troy, well, that post to inform us…about? Is the purpose to find the way to troubleshoot machine connection issues? If yes, please help us

I have no specific goals at the moment. This is step 1 of reverse engineering the system.

The purpose of this is to investigate how the machine works on an electronic (and physical) level, with PERHAPS the eventual goal to see how it could be used from open source software, standard g-code, etc.

For example, the tower - as I take it apart, I see the reel has a very nice mechanism for rolling up the wire… but this also means there’s a potential for the encoder “ticks” to not precisely match the wire length due to the pull of the wire mechanism across the face of the reel.

It’s a small variation… but it might be enough to cause some warp in the measurements depending on distance, which could lead to inaccuracy and a gradual but consistent warping of measurements - and that’s something I have seen.

This might be resolved in code by adjusting based on position - but I’d have no idea because the code is entirely closed source.

TO THE OWNERS OF THE GOLIATH PROJECT:

Please let us us help you. The machine is amazing and it deserves better than the state it’s in now.

Dump all the code on GitHub. Please. Open it up under a proper open source license.

Public the schematics. Publish the G-Code specs. Publish everything.

Please don’t let this project die and leave everyone stuck with a machine that doesn’t work as well as it clearly can.

2 Likes

Troy, wonderfull what you started.
I’m a programmer and I advocated already many times here and in the kickstarter forum for an open source project.
We can reverse engineer, although that would be a real pain for a lot of reasons.
We could work together with the (one man ?) software team, if they would only see the potential of open source for their business model.

At my end: everything is still in the original kickstarter box, unopened, because … no linux version.

1 Like

Some links I’ve collected for the Tower hardware:

The brains of the tower - the ARM Cortex M4 microcontroller. Floating point math unit, lots of other features that are irrelevant to the tower controller:

This is the rotary encoder manufacturer. It’s relative position encoder (think of an old-school mouse with a ball). Nothing special here, but looks like a quality company. I don’t know the exact encoder reader used, as I haven’t taken the Tower entirely apart.

This is the battery manager chip - I2C controlled, and has lots of cool features. Seems like an excellent choice. Also has a buck converter for powering the unit simultaneously with charging.

FTDI serial UART chip, also has USB charger detection. Also seems like a good choice for this project:

SPI flash memory chip - connected to the CPU for storage of likely the firmware as well as anything else needed, like firmware updates:

Another voltage step-down IC, not entirely sure where it’s used but generally to convert to a voltage needed for specific components:

The SPI wireless communication board used to make the tower units wireless. This is 2.4GHz and is a simple wireless communication protocol - there’s no actual WiFi in the towers themselves. Enables bidirectional comms between the towers and the Goliath, allows for firmware updates, sends positional data from the rotary encoder reel, etc:

Overall, a good selection of ICs and nothing that looks like cheap garbage.

So the basic function of the tower seems to be:

Button inputs
LED outputs
Read relative position of the reel
Wireless sending of button states to the Goliath
Wireless sending of the relative reel position to the Goliath
Wireless reception of LED states from the Goliath
Firmware update (USB mode via FTDI chip, maybe could be wireless too)
Manage USB charging of the 18650 battery, a single cell LiPo
Setting the battery charging settings via I2C to the BMS chip
Reading the battery charge state of the 18650 via I2C
Wireless sending of the battery state to the Goliath

…and maybe keeping track of the reel position internally, based on button logic and/or external Goliath commands to set it to an initial zero.

There is also likely internal code logic for the LED states, like wireless operation indicators, USB charging indicators, power conditions (low battery), etc.

Am I missing anything else?

the source code running on those chips :money_mouth_face:

Well, the source code isn’t really needed if you can define all the operations required and the protocols being spoken.

I’m not gonna say it’s “easy after that” but reverse engineering a tower to create a functional clone of a tower would be a good start, based entirely on open source code and hardware.

I likely would skip a lot of what’s in the tower in favor of an ESP32 dev board, for example, if I was looking to first clone the functionality of a tower. :slight_smile:

And then once that’s working, look at how to implement the code on the original tower hardware.

If you’re gonna avoid getting slapped with intellectual property legal stuff, it’s best to NOT see the source code. Clean-room the reversing of the implementation.