Assembly of rev 2.8 / 3.0

A few notes on the assembly of the latest boards rev 2.8 and 3.0

Fully populated board

The picture shows a fully populated board for both data east and WPC.

Same picture but highlighted in green what is data east (whitestar) only, highlighted in blue what is wpc only.

From the label on the PBC it should be clear, how to mount the parts. But for some there is different orientation possible or it is not clear where to place pin1.

Resistor networks / pin headers

RN1 / RN2: these are resistor networks used as pull up so there is a pin1 connected to 5v.

pin1 is marked with a dot.

Resistor network pin1 marking must match the orange arrows see picture below.

If you use double row header with polarization slot, be sure it point to the right direction (34 to edge of pcb, 20 to inner pcb, see arrows

pin1 markers for resistor networks, polarization slot for headers and gnd for the e-caps


Also note the gnd side (upper side in this picture) for the e-caps.

Last but not least the smd ICs all have their pin1 upper left. You will notice the small dot in the upper left corner (resp the notch for the 574)

DC DC converters

The dc dc power converter modules are sometimes with fixed voltage 12v / 5v sometimes adjustable. If you got the adjustable one, don’t worry I have already adjusted them to 5v or 12v resp. So no need to do anything on your side. If you accidentally push one of the trimmers, you need to carefully readjust to 5v or 12v to not risk to fry the raspberry pi or the amplifiers.

Optional OLED

Oled display with GND left

One more comment on the OLED display: you can always add one on your own if you did not include one in your order in the first place. Two type are supported: 0.96” with SSD1306 controller and 1.3” with SH1106 controller. Just be sure that you buy one with the power connectors starting with Gnd, Vcc, … from left to right. I’m mentioning this because you get different ones as well. Best fit would be for example: It has the Gnd connector on the left, so it will work fine.

Speaker WIRING for WPC (old mono)

Old wpc games only have a mono sound with 3 speakers wired like this:

Old style wiring with wpc, only mono / one channel

With TILT!Audio you get full stereo plus sub woofer channel for the cabinet speaker (2.1 sound). Therefore the speaker wiring needs to change:

Each speaker has its own pair of wires connected to J504 / 505

As the backbox right speaker in such games is only a tweeter, I would strongly recommend to also exchange speakers in the backbox.

KEYPINS molex connectors

3 of the molex connectors have a key pin (a pin that needs to be removed). It is easy to remove it before soldering. See images below which pin to remove:


Some general advice and hints:

  • dc dc converters must have the correct orientation (see picture above)
  • the raspberry pi header need some distance to leave enough room for a pi3 with all its USB / network connectors

Images courtesy of Mike L. Very much appreciated.

Creating a sd card

If you have a good linux experience it is easy to create a bootable sd card for TILT!Audio with arbitrary size.

For everybody else just use the standard method and flash the standard image with etcher.

Just use a normal micro sd card if size 8GB, 16GB or 32GB. These normally come with just one big fat32 formatted partition. TILT!Audio uses the fat32 partition not only for booting, but also as storage for sound packages.

What you need to do is create some space after the fat32 partition for the linux part. In Ubuntu you can just use parted or gparted to shrink the fat32 partition to a smaller size that leaves about 4GB unassigned space.

GParted after partition resize (and flushed filesystem)

After that use fdisk to create a second primary partition (linux type) that starts right after the fat32 partition. Just check the end block that fdisk displays for the first partition and add 1 block.

fdisk showing both partitions second starts right after the first

Such a prepared micro sd card then can be filled with data:

  • fat32 (boot) partition: just extract this zip
  • the linux partition can be “flashed” with dd using that image.

Creating your TILT!Audio sd card this way is much faster than flashing a 16GB image and you can choose what size of sd card to use.

Lua Reference

Important notes

Please make sure you did not switch lua off in the config otherwise it will not work.

Also if you already have a license make sure it includes the lua runtime. Check the logfile and look out init.lua gets searched and loaded and for your lua functions being called when you trigger tests.

See the lua example videos on my youtube channel: e.g.

Global variabels

config: all the main config parameters from the raspisound.ini file as lua table. That means you can access it like config.say_version.

version: the version of the TILT!Audion firmware as string. e.g. “1.29”

musicPlayingId: the number of the currently playing background music (or 0 if none).

effectiveVolume: the effectiveVolume (overall volume).


playSound(id, volume, index): play a sound effect (or background music) from sound pack.
id: the sound effect id.
volume (optional): if set (0-30) override the standard volume from sound pack and play with given volume.
index (optional): if set, use a specfic sound file for the effect. This is only relevant, when the sound pack defines more than one sound file for this effect.

getSound( id ): returns a lua table (or nil) for the sound effect with given id. the lua table contains the properties:
name: the name of the sound effect.
samples: number if sound files for the effect (normally 1).
type: 1-6 depending on sound type: music, voice, effect ..
command: string if the effect has an command attached

getCurrentSoundPack(): returns the current sound pack as lua table.

port( pinNumber, value): set port to high or low. pinNumber is one of the valid Raspberry Pi pins the can be used for output (basically the shaker pin) or 100-115 for port extender pins. value = 0 -> LOW output, value != 0 -> HIGH output.

portseq( pinNumber, time1, time2, … ): queue a sequence of HIGH, LOW changes for a GPIO pin. pinNumber see above. time1, time2 … define the intervals in milliseconds, that will make the output go HIGH-LOW-HIGH …

send( command ): send a string command to attached device (either serial or via TCP, depending on config). Can be used with the serial media server.

sendI2C( deviceAdress, reg, data): send a command to an attached i2c device. deviceAddress is 1 Byte device address on i2c bus. reg is 1 byte register number, data is one byte data to write to register.

sendI2CW( deviceAdress, reg, data): send a command to an attached i2c device. deviceAddress is 1 Byte device address on i2c bus. reg is 1 byte register number, data is two byte data to write to register.

readI2C( deviceAdress, reg): read data from an n I2C device and returns an int.

log( logLevel, message ): logs a message into main logfile. logLevel: 1=ERROR up to 4=DEBUG, message a string with log message. NOTE: normal print output will also go to the logfile if DEBUG is switched on.

setVolume( newVolume )

pauseMusic(): pause background music

resumeMusic( ms ): resume pause background music and fade back in ms = milli seconds

stopMusic(): stops background music

fadeMusic( milliSeconds ): fades background music in milliSeconds

fadeOutSfx( milliSeconds): fades out sfx sounds in milliSeconds

fadeOutVoice( milliSeconds): fades out voice sounds in milliSeconds

fadeOutAllEffects( milliSeconds): fades out both woice and sfx in milliSeconds

stopAllSamples(): stops all running sound effects other than background music

omx player commands (beta)

omxPause(): pause player playback

omxAction( action ): perform an action on player. action numbers see OMXControl.h

omxSetPos( pos ): set playback position absolute in milli seconds

omxStop(): stop player playback

omxPlay( file ): play a new file

omxGetPos(): get the current playing pos in milli seconds.

omxGetStatus(): return current player status: 0 = pause, 1 = playing

Handlers (beta)

There are two special lua functions in your script recognized at startup. They are called handlers. Just put a function named timer or eventHandler and it will be called like described:

timer( millis ): this function gets called every milli second (approximately). It is run in the main loop of TILT!Audio firmware (will be changed maybe), so don’t block anything and keep the function short and fast.

eventHander( stringMessage): it the event handler feature is enabled with TILT!Audio, every time the firmware receives an event, the function gets called.