All posts by alex

Reverse Engineering the Freesculpt (Myriwell) 3D printer: Making a Hacksculpt (2/2)

Introduction

In the following you find information which can help you to upgrade your Hacksculpt. Be warned, its a process that takes quite a lot of time and some electronics experience.

Upgrading the electronics gives you many opportunities, use the latest Slicer and Host software and run a decent firmware were the most important one for me. Secondly this allowed me to replace the extruder hot end with a better quality one, which would not have been possible with the original firmware as you would not be able to change settings such as E-steps.

After hacking the Freesculpt printer (which is just a relabeled Myriwell product), which was manufactured in the mid-2013, I must say that in some parts a very well designed product for a low price tag, then, when it comes to software, customization and failure rate is just very painful. This is also how I received the Myriwell: With broken electronics, and software which was a time travel experience with occasional smileys greeting me (“uploading file ^-^”).

Hacking the Microcontroller for custom firmware?

There is an JTAG port available on the main PCB which would possibly allow for reflashing a custom firmware, after figuring out all Pin definitions manually. However the uC itselfs is quite limited and could just about run a recent Reprap firmware without nice features such as display or SD card. Plus, if the board fails not clear how you can get replacement.

 

Internal Power supply:

24V, 15 A

Extruder Temperature sensor:

Type-K Thermocouple (read out by MAX6675)

Heated Bed:

Temperature sensor 15k NTC SMD (possibly Vishay NTCS0805E3…..T)

Heater cold resistance: 3.7 Ohms

Readouts are very good NTC with 15k and B=3700.

Electronics:

Custom controller board, custom SD/Pushkey board, Third-Party LCD Graphics display 12864G

ATmega64A (16 MHz, 64 kByte Flash,4 kB SRam)

Endstops:

5V Electrical Endstops, Normally Open (1-Open, 0-Closed)

General color coding:

Black – x

Green – Y

Yellow – Z

No Mark – Extruder

Belt /Pulleys (X/Y)

TB2 (2mm Pitch)

17-teeth

Leadscrew driven system (Z)

Leadscrew with multiround (4-rounds) with a pitch of 8mm/turn.

 

Stepper motors:

All 200 steps / revolution.

Stepper drivers:

A4988

Internal Harness Color Coding

Does not exist, the wire marks for all wires are arbitrary.

Maximum Moving distance:

X=290mm

Y=160mm

Z=150mm

 

 

Hacking a Freesculpt / Myriwell 3D Printer

Endstops: 1-GND, 2-VCC, 3-SIG (default as Sanguinololu, Different than RAMPS)

Motor Coding: 2B 2A 1A 1B (default as for Reprap)

 

Printer Settings: Calculation

These settings work very good for XYZ axis.

 

Result   Resolution          Teeth    Step angle          Stepping             Belt

94.12 steps/mm

10.624999999999998micron        17           1.8°        1/16th  2mm

 

Result   Leadscrew pitch              Step angle          Stepping             Gear ratio

400.00 steps/mm

8             1.8°        1/16th  1 : 1

 

Printer settings: Complete package (configuration.h, EEPROM, Printer size setting)

I have prepared a complete download of all my settings to help you reverse engineer. The configuration.h does not have the most recent settings such as extruder steps (which should be different for you) as well as print bed size and some settings.

http://space.planetsofa.de/files/freesculpt_settings_2016_04_10.zip

Reverse Engineering the Freesculpt (Myriwell) 3D printer (1/2)

After finishing this project I want to share some details on how to reverse engineer and upgrade a proprietary printer to an open source solution, and why you would want to do this.

The Myriwell printer (available as Freesculpt printer) is available for little money and offers a complete solution, which is both positive and negative. If something breaks, you can easily throw out the whole printer, although most parts are still OK. The Myriwell printer is in many parts very similar (might even say a clone) of a Makerbot 2, there are many similar design decisions such as the very particular X-Carriage. Some things are really not so great about this printer, for instance the fact that the extruder hot end as the most important part is basically a hot wire wrapped around some Kapton tape, which was charcoaled by the time I looked inside.

At the end of the project stands a 3d printer for little money with very good performance and open-source Repetier Firmware which gives all the options. It is even possible to reuse the hardware buttons and LCD display.

 

Lets take a look at the Pros and Cons of the Freesculpt printer:

 

+Good mechanical design

+Direct extruder

-Noisy (Plastic case increases vibrations)

-Not open source

-Propietary software (Pearl) which reportetly ceases some functions

-Low quality cables (reported cable braking)

-No control options during print

-Constant temperature for bed and extruder set on printer menu

 

For owner such printers, you can find the precise settings and everything about the printer in a separate post.

Building xephem on Ubuntu from trunk (04/2015)

 

 

Xephem is a very nice and elaborate tool which has many different features such as complex orbital position determination of celestial bodies, tracking of satellites, but also many other features such as images from celestial bodies and Earth phase.

For building it however requires many libraries which are not installed by default. The attached commands should install the basic libraries you need to get started.

 

Xephem Screenshot from 2015-04-07 11_01_57

Xephem Screenshot from 2015-04-07 11_02_49

 

sudo apt-get install lesstif2-dev
sudo apt-get install libc6-dev
sudo apt-get install libxmu-dev
sudo apt-get install libmotif3 libmotif-dev
sudo apt-get install make
sudo apt-get install libx11-dev libxmu-dev libxp-dev libxt-dev x11proto-print-dev
cd xephem-3.7.2/GUI/xephem
make MOTIF=/usr/lib

[1] http://ubuntuforums.org/archive/index.php/t-329396.html
[2] http://forum.ubuntuusers.de/topic/so-gehts-bei-mir%3A-astronomie-programm-xephem-/

Building Gpredict on Ubuntu from trunk (04/2015)

This instruction is written on Ubuntu 14.10 x86_64.

Get the required tools for building:

sudo apt-get install automake build-essential make

sudo apt-get install intltool libgoocanvas-dev
sudo apt-get install libgtk2.0-dev libcurl4-openssl-dev
sudo apt-get install intltool libgoocanvas-dev
sudo apt-get install libgtk2.0-dev libcurl4-openssl-dev

Get files from git and build:

git clone https://github.com/csete/gpredict.git
cd gpredict
./autogen.sh
make
sudo make install

[1] Gpredict Source

Cool projects: Satellite tracking/scanner from hacked maritime mobile earth station for Ku/L band

Travis has written on his blog how he repurposed an satellite dish from a naval vessel and his progress to track all kinds of satellites, including LEO, in the Ku/L band around 1.5 GHz ever since.

He uses an impressive setup between Beaglebone Black and fully automated tracking of known and scanning of unknown projects.

The SASA satellite dish setup

Video of a computer chaos congress in 2013:  Hillbilly Tracking of Low Earth Orbit: Repurposing an Inmarsat Dish (45 min).

 

Bugs when using rtl_tcp / Memory usage of rtl_tcp

Memory usage and buffers of rtl_tcp

The way rtl_tcp acquires memory and and how much memory it needs, depending on the parameters is very cryptic.

According to the man page the options are:

-b number of buffers (default: 15, set by library)
-n max number of linked list buffers to keep (default: 500)

This leaves the questions: how big is a buffer and linked list buffer? In short:

The linked list buffer will overflow only if tcp transport is not fast enough.

The buffers will overflow when you receive usb data faster than you can process it.

A linked list is a special kind of buffer which is very efficient for hunks of data of different size. It contains information of the next element and is allocated when needed.

Linked List

The buffers have a statically allocated size of 32kByte when called from rtl_tcp. Therefore initially there will be b x 32kBytes of memory reserved for asynchronous callback from the USB port. When these data return, they are copied in a linked list buffer. The linked list buffer is dynamically allocated, based on the actual size of the received data (which can be smaller than one buffer size). The maximum size of one linked list buffer is therefore about the size of one buffer. The total memory usage can therefore be estimated by:

static: 32kB * ( b )
dynamic: 32kB * (n )

As you can see it is totally of none importance if these numbers are even or odd. With the default settings, the theoretical maximum memory usage should be:

32kB(15+500) = 16’480 kByte.

If there are problems with your linked list buffer, e.g. the linked list adds or removes elements (because the data is not transferred in time) you will get such  messages when running rtl_tcp in command line:

ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7
ll-, now 0

Which basically just show you that you could not handle to send out the tcp packages fast enough, but instead had to create a new linked list buffer. ll+ means a new element is added, ll- an element is removed from the buffered list. Ideally for “live” streaming you dont want such messages at all. However, as long as you dont hit your max number of linked list buffer (-n) you will not lose packages.

However the practical memory usage is way higher, because of the underlying libusb transport layer that also allocates memory. The minimum memory usage on MIPS32 (WR703N with OpenWRT) with -b 1 and -n 0 is around 5700 kBytes with one client

Further I have observed that on MIPS32 the asynchronous transport only used one of the offered buffers in rtl_tcp, possibly because the only operation after a callback is to copy the buffer into a linked list. I think therefore that it is safe to use a small number of buffers, and a number of linked-list as can be conveniently used on the given device.

Bugs using rtl_tcp with SDR#

A very nice tool for windows is SDR#, which is now developed in closed source. There is a nice article over at hamradioscience that describes how to set up rtl_tcp with SDR#.  It still is my favorite tool when using the rtl-sdr directly connected over USB. However there are many reports of problems with “ringing” and a garbage signal, which can be recognized by this characteristic signal spectrum, which is also described on reddit. I have had this problems with the latest SDR# rev. 1337 too.

SDR# failing with rtl_tcp

 

I have analyzed the packages with wireshark, transmitted test packages and taken a glance at old SDR# code. In conclusion, rtl_tcp works just fine without any package loss. SDR# is not fast enough to process the received data synchronously.

Solution? Since SDR# is closed source none yet. You can give other open-source software a try, such as  the very extensive GnuRadio.

 

Crash of rtl_tcp when disconnecting/connecting a client

This problem has been reported most significantly on Raspberry Pi. It is caused by an old version of libusb (1.0.11) shipped still with the latest Raspbian image (03/2015). The issue does not occur with a newer libusb1.0.19.

As a workaround, enable the testing sources and update the libusb1.0.0 package.

  1. Login as root Open file /etc/apt/sources.list in your favourite editor

    gedit /etc/apt/sources.list

  2. Adding the testing repo. Add the below line.

    deb http://http.us.debian.org/debian/ testing non-free contrib main

  3. sudo apt-get update
  4. sudo apt-get install libusb1.0.0

Compiling custom OpenWRT firmware / packages

OpenWRT is a nifty thing. However, if you want to test some custom or self written programs it can be tricky.

For most instances, e.g. on a Raspberry or other embedded device, you can install a compile toolchain to just configure and make your project. Due to space constraints this is often not necessary. Cross-compiling for these embedded devices (for instance WR703N is MIPS32) is quite tricky. The easiest way therefore is to use the OpenWRT build root to compile these packages (and complete OpenWrt firmares).

I will not go into detail how to get, configure and build OpenWRT, you can find detailled instructions at the OpenWRT Wiki, and in addition how you can compile only a single package.

Assuming you have configured your OpenWRT install, you can build and include custom packages by editing the corresponding Makefiles.
For instance rtl-sdr you can find in the feeds directory:
openwrt/package/feeds/packages/rtl-sdr
Or the hamlib
openwrt/package/feeds/packages/hamlib

Everytime you install and compile the package, the source files will be downloaded newly from the internet and compiled. Therefore the easiest way is to provide a repository and commit where is the newer version.

So for instance, replacing the rtl-sdr/Makefile with this content can receive my custom version of rtl-sdr.

#
# Copyright (C) 2013 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.

include $(TOPDIR)/rules.mk

PKG_NAME:=rtl-sdr
PKG_VERSION:=2014-10-21
PKG_RELEASE:=$(PKG_SOURCE_VERSION)

PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://github.com/satnogs/rtl-sdr.git
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE_VERSION:=b72ab8fc83efbc2ec112154b9d1cbe2d85b1e258
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
CMAKE_INSTALL:=1

Building hamlib on Ubuntu from trunk (04/2015)

This instruction is written on Ubuntu 14.10 x86_64.

Get the required tools for building:

sudo apt-get install automake libtool build-essential make texinfo

Get files from git

git clone https://github.com/N0NB/hamlib.git
cd hamlib
chmod +x autogen.sh
./autogen
./configure
make

This instruction is for hamlib-1.2.15.3. The readme and Install file specify to use ./configure, but in the latest official github that file is renamed to ./autogen.sh. If you instead use autogen.sh it will work just fine then.
This will take time for a cup of tea.

Then you can install (and uninstall) witht his command:

sudo make install

If you encounter this error:

libhamlib.so.2: cannot open shared object file: No such file or directory

This is what fixed it:

sudo apt-get install --reinstall libhamlib2

Building a SatNOGS groundstation: Buying components I (mechanical)

1) Trackingbox case:

– Dimensions: 310x240x110mm (approx.)
– Sealing: IP55 (or above)

(A) ABB box

However it may be hard to find from some locations. You have to drill your own holes anyway so you can prefer a box without pre-drilled side holes!

Ideally you are looking for these MPN:

1SL0828A00(*)  / with pre-drilled wholes

1SL0858A00(*)  / without pre-drilled holes

1SL0878A00(*) / without pre-drilled holes, acrylic front

RS-Online: 20-30 € Ships worlwide, from EU
Walker Industries: 12.60$ Ships from US

 

(PDF) ABB low voltage enclosers overview (schematics page 11)

(PDF) ABB IP44 and IP55 junction boxes in thermoplastic material with press-on lid

00828c

00828a

00828b

(Copyright by ABB SACE)

 

(B) Alternatives

Based on discussions in the SatNOGS forum, here some other possibilities to source similar boxes.

  • Bud Industries NBF-32022 (Digikey): Inside 135mm sufficient, however needs to add spacer.
  • Ebay Noname 310mmx230mmx110mm: Inner dimension is 5 mm shorter, and requires adjustment.

 2) Stepper motors NEMA17

Stepper motor sizes are with 1.7 x 1.7 inch (43.2 x 43.2 mm) faceplate, which is NEMA17 size.

Shaft type: Single
Body Length: 47mm
Shaft Diameter: Φ5mm
Shaft Length: 19.5mm

Possible partnumber: 17HS19-2004S, 17HS6002-27B

The stepper motors provide 0.59 Nm (84 ounce inch).

After the gear 1:60 the total torque is 35.4 Nm.

1 Newton meter ≈ 141.61 ounce inch

1 Kilogram meter ≈ 0.1 Newton meter

Building a SatNOGS groundstation: Grounding and lightning protection

Dealing with grounding and lightning protection is obligatory when setting up a roof antenna. Bad grounding might cause not only damage to your antenna and equipment but even your complete home electronics or ignite fire.

Lightning is dangerous for two reasons. Direct lightning conduction can cause impulse voltages of higher than 20 Megavolts, whileas induced voltages can also reach up to 10 Kilovolts. Very interesting I found also this quote [1]:

A lightning has  an impulse voltage of > 20 Megavolts and an impulse current above 100.00 Ampere. Multiplying both numbers, the resulting yields a power that would instantaneosly vaporize any conductor. It does not, because the condctor does not actually conduct the energy of the lightning. The a cable with a diameter of 10mm alumium or 8mm copper only lays out a path, through which the surrounding air gets ionized, through which the actual charge surge current flows. This ionized stream will has a diameter of 2-5 cm and will not ignite anything, as the grounding conductor has a resistance <3 ohms.

Continue reading Building a SatNOGS groundstation: Grounding and lightning protection