Assembled my TiltAudio 2.8. I'll skip the issue with my aux power connector in my CFTBL (which for some reason did not want to play nice - took me a while to trace where it was coming from), it is now up and running, BUT I don't have sound...

Where I stand:
- TiltAudio WebUI is working, I can access it and I can access the log
- I have connected a headset directly to the jack output, for monitoring. At startup I hear the notice sound (in the headset, not in the speaker), and then nothing. If I try to hit "play" in the sounds menu, I get a message stating "playing sound xxx", but there's no sound, either in the headset or in the speaker
- With regards to the speaker, I did not change them yet. As it's a pre-DCS WPC, there are two speakers in //, and the cabinet speaker in series. What I have done is simply to solder a wire to the black/yellow plug of the right speaker, and insert that wire in the plug adjacent to the black wire, so I get yellow/black on the two leftmost pins of the backbox header on TiltAudio. In theory this 'should' work...

So... a few questions before I start debugging this further:
- What is the default Audio device to use for the onboard TiltAudio amplifiers ? Currently set to "equal-dac"
- Should the sound output to both the onboard amplifier and the line out jack ? From what I can understand of the schematics the answer should be yes ?
- why do I get a sound at boot but not afterward ?
- With regards to my speaker wiring, is there any indication this wiring is correct/incorrect ? I based it on WPC schematics wiring, available here: http://dziedzic.us/wpc_speaker_replacement.html

and more specifically the attached wiring diagram. I essentially wired a cable from the + pin of the left speaker to the Pin N°4 on the corresponding J504 female wire connector (so black is connected to Pin N°2 and yellow/black to Pin N°4). This should effectively route all signals from the left channel to all speakers.

Thanks for any guidance you can provide

pasted_image (resized).png

Just to be clear: they are connected accordingly to the silkscreen on the PCB. It's just that WPC original wiring is rather odd, so I have to adapt to connect correctly.

That said I resolved my issue. I had a mating issue between the male and female connectors for the speaker, so it was causing a no connection. This has been resolved (I changed the connector), and it's working fine.

Now on to fine-tuning the levels, but it's already a big improvement even with original speakers (I'll order replacement speakers later on).

It's super cool to be able to adjust the levels dynamically, way better than a Pinsound in that respect.

Just wondering though: what means exactly 'ducking by type' in the 'sound' tab?

The fuse rating seems a little bit on the low side, 1A on the 18VAC line, it burned after two weeks. Unless I have a fault somewhere, but the circuitry seems relatively simple and I checked all soldering and signals and it seems good.

Is this a fast blow or slow blow?

Exactly. It's way cheaper than a Pinsound

BUT, bear in mind, this is not PnP, you need to know how to solder, and potentially to debug. Be prepared for that. There's a reason Pinsound is more expensive, it's literally PnP, you have warranty, and it's a 10 min install

On the flip side, Tiltaudio capabilities are more extensive

That said, I'm using Tiltaudio

Damn, looks like the 12v regulator on my Tiltaudio is dead.

Anyone has experienced something similar? Any pointer to a quick to get replacement part?

Thanks

Thanks, I checked the schematics and found out that Amazon has both packs for the 12V regulator and the 5V regulator.

Now one additionnal question: is there any specific tips and tricks for the "upload sound package" functionality ?
Specifically, I downloaded the recently released altsound pack for Creature (available on vpinball), and when I try to use the "upload package", I get the following in the log file:

"
2021-01-11 10:37:46.135 DEBUG MHD-sing [initPostProcessor] [httpservice.c:608] init post processor of type SOUNDSET_UPLOAD_POST
2021-01-11 10:37:46.135 DEBUG MHD-sing [initPostProcessor] [httpservice.c:621] post processor 679ff008
2021-01-11 10:37:46.143 DEBUG MHD-sing [requestHandler] [httpservice.c:1632] url: /soundsets, method: POST, version: HTTP/1.1, contentType: multipart/form-data; boundary=----WebKitFormBoundaryW4ZcBDAsB0s7T8yd, upload_data: 67b007ac, size: 1460, connCtx: 0x67b9bd60
2021-01-11 10:37:46.143 DEBUG MHD-sing [handleContextRequests] [httpservice.c:1592] POST req count 1, size 1460
2021-01-11 10:37:46.143 DEBUG MHD-sing [handleContextRequests] [httpservice.c:1612] calling post processor callback 0x679ff008
2021-01-11 10:37:46.143 DEBUG MHD-sing [uploadSoundsetPostCallback] [httpservice.c:289] connCtx: 0x67b9bd60, kind: 4, key: file, filename: , contentType: application/octet-stream, TransferEncoding: (null), data: 0x679ff070, off: 0, size: 0
2021-01-11 10:37:46.143 DEBUG MHD-sing [uploadSoundsetPostCallback] [httpservice.c:316] writing file /boot/data/sound/1.zip
2021-01-11 10:37:46.144 DEBUG MHD-sing [uploadSoundsetPostCallback] [httpservice.c:289] connCtx: 0x67b9bd60, kind: 4, key: options, filename: (null), contentType: (null), TransferEncoding: (null), data: 0x679ff070, off: 0, size: 2
2021-01-11 10:37:46.144 ERROR MHD-sing [uploadSoundsetPostCallback] [httpservice.c:307] no file key provided -> abort
2021-01-11 10:37:46.144 DEBUG MHD-sing [requestHandler] [httpservice.c:1632] url: /soundsets, method: POST, version: HTTP/1.1, contentType: multipart/form-data; boundary=----WebKitFormBoundaryW4ZcBDAsB0s7T8yd, upload_data: 67b007ac, size: 2920, connCtx: 0x67b9bd60
2021-01-11 10:37:46.144 DEBUG MHD-sing [handleContextRequests] [httpservice.c:1592] POST req count 2, size 2920
2021-01-11 10:37:46.144 DEBUG MHD-sing [handleContextRequests] [httpservice.c:1612] calling post processor callback 0x679ff008
2021-01-11 10:37:46.144 DEBUG MHD-sing [requestHandler] [httpservice.c:1632] url: /soundsets, method: POST, version: HTTP/1.1, contentType: multipart/form-data; boundary=----WebKitFormBoundaryW4ZcBDAsB0s7T8yd, upload_data: 67b007ac, size: 2920, connCtx: 0x67b9bd60
2021-01-11 10:37:46.144 DEBUG MHD-sing [handleContextRequests] [httpservice.c:1592] POST req count 3, size 2920
2021-01-11 10:37:46.144 DEBUG MHD-sing [handleContextRequests] [httpservice.c:1612] calling post processor callback 0x679ff008
"

followed by hundred of similar of lines, and it never stops, to the point that my log file gets bigger and bigger. I also don't see any progress bar, is there supposed to be one ?

The file is a zip file of the sound package folder (so one folder up)

Am I missing something ?

So in debugging my problem on the 12V regulator, it's behaviour is relatively odd:
- At 18V DC input it's working
- At 22V DC input it's not working at all

Turns out that I have 22V DC input (or output from the rectifier), which explains why it's not working when put in the pinball, but working when I power it from my lab power supply (which was set to 18V).

From the specs it should be able to accomodate up to 30V, so it seems to me it's dead.

Sidenote: am I right to assume the PIN2DMD connectors are to power a PIN2DMD from TiltAudio (instead of using an alternate connector on the power board, such as J118) ? If so, I would tend to think the power regulator is slightly under rated for the usage, as a PIN2DMD is about 10W peak, so 1A, leaving 2A for the amplifiers, which are powered at 12V, so 24W. Even without a PIN2DMD connected, that's only 36W for the amplifiers, that seems rather low ? Or am I misled and amplifier power consumption is way lower than 2A anyway ?

Unfortunately I could not find a much higher current DC-DC 12V regulator in a similar form factor, if anyone has a pointer that would be welcome

I did find much higher amp regulator (8A or 10A) though, but they use screw in connectors, and their footprint is slightly bigger. i'll take a look to see if I can adapt it

Thanks, that's what I suspected. I'm not powering Pin2DMD through Tilt Audio anyway, so that does not explain why my regulator broke

Feedback for steve45 , it would be nice if instead of using male header pins to connect the various additionnal PCBs (regulators, amplifiers and so one), you would use female headers similar to these on the attached picture, this would allow for much easier replacement in case of one component dying.

It's probably even possible as is, by using the pins headers and removing one of the pin since there is no hole), just need to supply them (come to think of it, I'll order a bunch)

Also, I worked around my issue for uploading the altsound sound package by adding it manually.

However I would have the following questions:

- I get a bunch of errors in the log file, such as " 2021-01-13 14:08:38.549 ERROR MHD-sing [getFileSize] [fileutil.c:412] stat call on /boot/data/sound/cftbl_l4/ok failed "

All failed files are in the jingles section. Yet they are accessible afterward through the WebUI, and can be played back.

- How does the "serial" command in the case of altsound package ? I bought the TiltAudio full media package for Creature, and when checking the file structure I see that there are serial.txt files in various folders, which are used to trigger multimedia command, but how would that work for an altsound package for which all files are in a common folder with a CSV file ?

- On the topic of the media player : any specific reason why both TiltAudio and multimedia playback for the video mod under the Creature window could not be combined into a single HW unit ? That would make it easier for installation (just need an HDMI cable from the RPI to the display)

pasted_image (resized).png

So just to be clear, you get sound and music and call outs, but there is a specific sound which is played at some point where it should not?

I have a 3.0 board I assembled myself, full kit acquired through Steve.

Installed in a CFTBL. I originally had a specific callout being played randomly, and music stopping, as if it was missing a command. But for some reason over the last few weeks it has been working flawlessly (can't remember the version though I'll check tomorrow).

The core of false detection is likely a bus detection issue, which could be cause by multiple reasons, such as signal integrity, code missing detection (RPI is not a real time system).

I'm using a RPI3 Model A+

So I don't know what made it work, but I'm glad it does

It's just kind of shame that Steve is not very active in supporting the project, although to his defense he's probably not making a lot of money to justify the engineering investment (unlike Pinsound who charges a fortune). Also Steve has been actively developping a new version of PIN2DMD Editor which brings 64 colors capability, and the capability to develop colorization for Stern SAM, so I assume he did not have much time to spend on TiltAudio. Maybe if his code was open source other contributors would start looking into it and debug it more actively. But I know of a few not happy individuals on the Facebook french group that tried the solution and could not make it work.

A few suggestions:
- Besides the SMD components, check that all resistors are soldered correctly, reflow all of the connections, including headers
- if you have a RPI4, just install it (hopefully Steve can transfer the licence without charging), it's higher speed might be beneficial for more reliable command detection (completely shooting in the dark here to be honest).

@steve45, if you're reading this thread, it would be good if you could comment and assist with some guidance based on the logs.

@steve45, I believe you have slightly misread my comment.

I did state specifically that you were not making a lot of money on this project, if at all. And I stated a few reasons as to why you might have been slow in responding, time being the main issue.

So if you understood that I was stating that you should support because you were making money, this was not my intention, apologies for that. We all fully understand this is an diy project, and you have other obligations.

I even advertised tiltaudio on some French Facebook groups, starting it was clearly for the experienced individuals, but worth it if you had the skills.

However, the fact remains that some people fail to make it work (that's not my case, it does work), and raised questions that are currently pending. I don't know the ratio of success VS failure though, so this might be that success ratio is higher than what we see on pinside.

Let's hope these questions get answered with a root cause identified so that everyone benefits from the knowledge

Regards

Very true. Although to my defense I did post publicly that is was working just fine for me (although I did have some unexplained behaviour at the beginning, which disappeared after I replaced my 12v regulator and I reflowed several solder points).

Anyway, as stated, apologize for the poor choice of words on my part.

Regards

Good morning/evening gentlemen,

I have a CFTBL, a PIN2DMD (replacing the original Plasma), and a v3.0 board (assembled by me, but components provided by Steve).

As it turns out, I stated above that I experienced glitches (music not playing sometimes, wrong callout being used, etc), which disappeared after I did a resolder. I assumed that I had a trace connection problem somewhere, story closed.

However the issue reappeared. Relatively often.

Now an earlier comment from Steve stated that clock speed was likely not an issue, as bus interface was relatively low compared to acquisition speed of the RPI.

In the case of bus acquisition, all data provided by a few users on this thread indicate there is a reasonably wide variety of HW configurations (different boards, different RPI, different pinball machines), and all exhibit failures in some form. True, we don't know whether this is widespread to other users, but if I take a look at what I experienced, I would probably not have raised the issue since it was random, unless I had been reading this thread.

All these failures lead to data acquisition failure, which could be caused by:
- Signal integrity (only way to know for sure is to hook up an oscilloscope at the input of the buffers - did not check what was used), not really practical for most people, and given the design very unlikely (there is no Y connection, it's a straight end to end with impedance matching from what I could see), unless there's noise on the power supply lines (which would be again unlikely since power for Tiltaudio is provided directly through a rectifier bridge taken from 20VAC, and it has it's own power rails)
- the RPI missing it's time slice for acquisition, or data input is garbled

Disclaimer: what follows is pure speculation on my side, however it is based on professional experience on the usage of SoC type devices for similar type of application (ie time sensitive).

I have a strong suspicion this is related to the notion of "Real Time OS", as in "Hard real time". This is not about speed (well sort of), it's about scheduling. With an RT-OS, scheduling can be set in such a way that no matter what, a specific thread/process will have it's allocated timeslot, whatever the timeslot is (within reason of course). Linux is not an RT OS, so even if you set priority of a specific thread to high, there is a chance that another thread will stall the scheduling, thus creating the critical thread to miss it's timeslot.

Also, if you have multiple inputs and read them into independent threads, there are chances that the aggregation of these inputs could be offset (so for example in the case of GPIO reading, you read GPIO1, then GPIO2, etc, then combine them into a single byte, but the timeslot of GPIO2 might be offset relative to GPIO1, resulting into a byte failure).

More information here:
https://www.guru99.com/real-time-operating-system.html

A real RT-OS is pretty hard to deal with for complex tasks, so the Linux kernel group has developed a set of "semi RT" patches, known as "preempt RT patches", which essentially are scheduler patches to provide some real time capabilities, within limits.

Details here:
https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch

and a link to a RPI Preempt RT patch documentation (rather old though):
https://lemariva.com/blog/2018/02/raspberry-pi-rt-preempt-tutorial-for-kernel-4-14-y

I don't know if the base BSP (OS) used by Steve for TiltAudio has those patches installed, but if it does not, adding these patches to the kernel could potentially increase reliability of the bus acquisition. It would require however some engineering investment, since you would need to recompile the kernel with the patches (should be straightforward), and probably implement change in the thread management of the application to define those that are critical to those that are not (probably less straightforward - although I can't comment, while I know the principle of operation I'm not a SW developer).

But IMO it's worth a shot.

I've had similar issues on ARM57/ARM53 type SoC, which when used in time critical environnement failed precisely because of that reason. In my case, as the constraints were severe (aero), they had to go the "hard" way by using a specific Linux BSP completely designed for Real time (for those interested, called Redhawk from Concurrent Technologies)

Note: increasing clock speed and CPU efficiency reduces the likelihood of this type of occurence, simply because everything runs faster so the chances of a thread blocking another thread to execute are smaller, however from the architecture standpoint it is not guaranteed. So replacing with a RPI4 might help in this case (coincidentally, this is also recommended by Steve for Bluetooth operation anyway)

Another alternative would be to look at CPU affinity, essentially locking all non critical processes to "general" cores, and lock the acquisition threads (or any time critical process) to the last available core, dedicated sorely for that purpose. This will however not necessarily improve if the thread stalling is happening because of internal bus contention within the SoC (in which case even if you have a CPU core completely available, if the GPIO block is used by another thread on another core, it could block access), but it's also worth a shot

So a path of investigations would be:
- Use a RPI4 just to decrease contention ratio: easily achievable by every user, at least for testing
- Implement CPU affinity (some details here: https://www.xmodulo.com/run-program-process-specific-cpu-cores-linux.html ). Probably need a little bit of guidance from Steve to identify the processes that we would want to pin to a specific CPU (and use all others for the other processes).

Some details here: https://www.xmodulo.com/run-program-process-specific-cpu-cores-linux.html

- Implement Preempt RT patches if they are not already enabled, and if they are check how the SW is defining priority for the data acquisition thread. Significant investment on Steve side, so to use only as a last resort (and assuming this issue is more widespread than originally thought)

Apologies if what I'm writing above has already been considered and implemented, in which case this idea is completely moot.

On my side anyway I wanted to upgrade to a RPI4, at least for Bluetooth range, so I'll test it anyway (when I receive my RPI4)

Regards

I tested on my virtual pinball the Indiana Jones altsound package, and I did not experience issues with missing music and odd sounds.

As for the plane sound (left ramp) , for me I can only get the machine gun sound to play, regardless of the package (pinsound or altsound), except the first shot in the ramp where I hear the plane engine roar. But this happens with the stock sound rom as well, so not sure if there's an issue or if it's expected behavior.

Thanks for these useful feedbacks. You are right, timing issues should not cause a ghost command like x186 sound being played (what would 186 correspond to in terms of bus data anyway ?)

With regards to RTPatch, I'll take a look. As mentioned I'm not a SW developer so my programming skills are rusty beyond any measure, but I did compile Linux kernel to add some modules in the past, so hopefully I can make that work

Regards

@steve45, Dietpi at first launch allows you to specify a lot of options for your installation, I started with the minimal image. Did you add any specific components that would have a kernel impact (I've seen in the log file that there is a script overwriting the first kernel used to boot, so I assume they adapt the kernel based on installation)

uname -r results into 5.4.83-v7+

[EDIT] Unfortunately, the last maintained branch for RT patches on a RPI kernel is 4.19. Adding the RT patches to a more recent branch is doable, but if not maintained by the RPI community is probably not a good approach.

Since kernel transition from 4.x to 5.x took place in August 2020, would it be fine to start from an earlier DietPi build, and if so which one is a good starting point ?

[EDIT2] indeed the preempt RT patches do not seem to work on kernel 5.x and RPI3 (it does on RPI4, but only 64b kernel has been tested), and it has not been a focus of the kernel dev, so I don't expect it will be resolved

Thanks, I'll run a test on my CFTBL (once it's back up and running) to compare the logs

Absolutely. My CFTBL sometimes exhibit the behaviour, but sometimes works very well, while on yours the failure is consistent. So if you can try it that would give a data point

[EDIT] As of course, now that I want to run a test, it's working flawlessly... So I can't really compare behaviour.
[EDIT2] There is an interesting read on WiringPi, priority and interrupt management : http://wiringpi.com/reference/priority-interrupts-and-threads/

Crap, that was a good hypothesis, but unfortunately proved wrong.

Just for reference, I'm Tiberium contact, and indeed on my CFTBL I don't see any sound error or sound check.

But I use a modified rom (from http://vpuniverse.com/forums/files/file/4173-creature-from-the-black-lagoon-l-4c-competition-mod/), not sure if they disabled something

Robotworkshop

One suggestion I would have to determine whether TiltAudio interprets things differently with regards to altsound format parsing is simply to run VPX with the same table, with PinMame sound mode set to 1 (if I recall correctly, might be set to 2).

If it's identical you can then proceed to look at Pinmame source code

Robotworkshop

Altsound format was originally developer for VPX and Pinmame, it's not emulating TiltAudio. However the format itself is identical, so by reading you can understand what parameters are taken into account and how.

To adress your concern about implementation discrepancy (and there could be), as a starting point you could look at whether you encounter the same issues with VPX+Pinmame (if I recall not honoring some parameters in the CSV file ?).

If you do find the same behaviour, your starting point can therefore indeed be PinMame source to understand the limitations
If you don't, then this means indeed there is a different implementation/parsing in TiltAudio firmware, which would give a reference point

Regards

With regards to this issue, has anyone identified how the check is being done (using a Logic analyzer or such), ie which signals are being used and how ?

Cool, good to know, thanks. I was otherwise going to work on a version using a CPLD replacing the logic blocks between the header and the RPI, but since you're already on it.

Cheers

Is this another mix for Dr Who ? I seem to recall there are some already existing sound package on altsound.

Dr Who is definitely one of those that require an alternate sound pack, the original sound is... well... something.

To be fair, this is a legal grey area , since the original sound pack authors do not own the rights in the first place anyway... So authorization is not theirs to give, unless it's their media (and for that matter, strictly speaking, it's unlikely they have the right either, it's just that everyone is closing their eyes - guess that's why these soundpacks are on a community website... )

ah indeed. On a sidenote I had not realized that you could extract that info from the scrambled package, that's good news indeed

Superb

And using Docker on top of it is the ice on the cake, no dependency issue, no messing up existing installation.

Cheers

Good afternoon,

Probably known by many, but I discovered the following repository from Steve:
https://github.com/sker65/tiltaudio-extensions

Basically simple code that allows you to control external HW mods with an arduino for example based on sound commands, using LUA scripts which send commands over I2C, which are then monitored by an Arduino to react upon.

Game driven Pinstadium anyone ?

Now I need to go out and buy a few ledstrips... and a shaker... And create a package based on this to control those toys.

I must admit I have a bad habit. I tend to jump in first before reading the manual... So... I had seen that many months ago, then forgot about it, then thought about this idea, which of course did not trigger any memory because I'm getting old, so started digging into it, and stumbled thanks to google search on your github...

Oh well, at least I did not ask a stupid question on this thread.

It's a pretty cool setup truth be told. And I have yet to play around with the WebUI, seems I can do a lot of things in it without having to go through LUA if I understand correctly.

I'll quickly prototype something using WS2812 ledstrip and an arduino, plenty of potential here (and very little time...)

Cheers

To clarify, my point was not about not_ asking permission to the sound pack author (out of courtesy as you point out), but on the fact that just because they give their permission does not, strictly speaking, cover the rights to use it, since they don't own the rights in the first place.

http://altsound.vpin24.com/

Regards

Has anyone developed a small PCB board for Arduino to interface on the Tiltaudio expansion port and drive different toys (shaker, leds, etc)?

I know it's super easy to do on a breadboard, but I thought it would be nice to have something clean.

If no one did it I'll quickly whip up something

And on that note, I understand that for Stern Whitestar you need an adapter PCB/cable. Anyone would have a pointer to this adapter?

OK, found the adapter on Steve website.

I was also told that Pinsound adapter does work, and since I have a Pinsound in my LOTR I already have the cable.

So next question is: as I intend to replace Pinsound with TiltAudio in my LOTR (primarily because P...d is completely closed and does not allow to hook up on their expansion port, despite the fact it's present, that they are using community orchestration for Shakers - so called shakerization - but obfuscate them and integrate them into their firmware without giving credit to the original authors, etc), I already have the cable so don't need an extra one.

So which kit can I order to get Whitestar support ? I'm assuming WPC ?

Nice work,

What's cool with this module approach is that you can use headers instead of soldering directly, which means you can easily replace one module if needs be

Ah that's a cookie on the local machine, that explains why it does not stick for me either. I believe I have a reinforced security setting enabled by default for cookies, will have to check (if I can recall where in the world this is located)

For reference and anyone interested, I found this nice shield:

https://fr.aliexpress.com/item/1005002091633431.html?spm=a2g0s.9042311.0.0.7e0c6c37c7xgdb

(see block diagram below)

Which would make a very nice shield for a shaker/ledstrip interface (from TiltAudio to Seeedstudio Xiao)

You of course need to add a Seeedstudio Xiao to it (super small), and a motor controller should you need to add a shaker.

pasted_image (resized).png

I would assume there are some spare GPIOs on the RPI, right ? So conceptually it should be possible to hook up one of the switch, probably needs to add a little bit of logic glue in between (similar to what PinLightShield does, using the two switch signals and some flip-flop).

EasyEDA is indeed super cool.

One question though before I start making mistakes... When editing in EasyEDA, when saving I get the option of saving for "everyone", or just for "me". Just for the sake of clarification, your design should be read only, right ? (in any case I'll only save for me, but just want to make sure a mistake hitting the wrong button will cause a problem)

I also do have two additionnal questions:

- I can't figure how to select the symbol for the OLED display. I can click on all other symbols used (and get their pinout), but whenever I click on the DISPLAY-OLED, well nothing happens, I can't select it. Which means I can't duplicate it (wanted to duplicate to use the same connector and just rotate it - alternatively I could create another symbol with an identical pinout but that would be odd). Am I missing something ? Did you add the vias manually directly in the gerber ?

- I can't figure out where the GND signals in the gerber display has gone. For ex if I move the switch button connector and run DRC check I can see conflict with GND, but where in the world is the GND plane display... Granted it's an EasyEDA feature, I'll dig into the documentation (as it's probably something obvious), just raising it for everyone benefit

Regards

Farnell nor RS have them for some reason (at least could not find them

For what it's worth 3A+ works fine on Wpc89 with 1.35. Not what you asked, I know

I must be completely dense, but... looking at the oshwlab version, I see no GND traces/planes anywhere. All GND nets appear as unconnected on the gerber file. Likewise, when viewing the gerber file through an external gerber file viewer (after generation by Easy EDA), I see no connection between the GND nets

Am I missing something ?

On a sidenote, same applies to older revision, like TA 3.0, which is why I'm super puzzled

Thanks, now that's better indeed, this was driving me crazy. I had not thought of checking the GND plane visibility itself

Also indeed it's present regardless of the setting in the Gerber, I misinterpreted the viewer data

I've been looking at the schematics and gerber, trying to implement Robotworkshop suggestions (to at least contribute a little bit)

Unfortunately, it seems that I'm missing something. There is a lot of missing symbols (OLED display for ex, but not only) where the net connects visually on the schematics to a pin, but this pin is not tied to a symbol (so can't be edited, moved, copied).

Also, I can't "import changes" (which is how changes in schematics are reflected into the layout), it's missing a lot of component footprint (about 50), and it can't make the association.

It would seem the schematics and layout are imported from another tool, and this import essentially broke several symbols and component associations.

Am I correct in my assumption ?

If so, this means that practically for anyone to contribute (such as implementing Robotworkshop suggestions), we would first need to find a way to either ensure the import allows for proper component association, or work from the original design files in the original toolchain

If not, well I'm baffled, as I can't see how the layout was generated in the first place with Easy EDA.

I'm going to build a TiltAudio 3.5 board (just received the PCB - waiting on a few more components), will take some pictures as I progress in the soldering to provide to the wiki.

Note: I'll use headers where I can as it's more convenient when swapping (except maybe the 12V and 5V regulators)
Note 2 : I'll use the DSP

Any area you would like to get extra pictures during the assembly process ?

I believe nobody tested with a PiZero. We have tested various flavors (especially RPI 3 Model A+), but Pi Zero seems vastly underpowered, so I would advise against using it

As for WebUI, no it should not go away. By default it operates in hotspot mode, which you can modify and configure to your home network, but it should always be operational

As for speaker impedance, you should be fine. You don't need to add a filter if you are using the DSP.

Regards

In the /boot/data folder (if my memory is correct), there is a tiltaudio.xml and tiltaudio2.xml. The second one need to replace the first (backup the first, rename the second), and you will get access to specific filter frequencies configuration in the config tab.

The xml file is actually generated using the Sigma DSP application, which truth be told I have yet to install and test

sidenote, there is a slack channel to discuss using messenger type application - you can ask Steve for the link

Are you using 1.37 ?

There is an elusive bug that Steve is chasing which could be related to what you're seeing (although symptoms are different).

In any case, for the sake of testing, I would recommend to start from scratch, ie burn a brand new image using Etcher and put it directly in your RPI3B+. I've had issues in the past where the TA SW would be stuck and nothing would allow to come back operational.

Also, are you using a 3.5 board or a 3.0 ?

Right now I'm only using stock speaker. TA alone is a massive improvement in sound quality. Of course upgraded speakers would be nice, that's next in line.

If you're using a 3.0, you have the option to use an older revision. 1.32 is a good starting point, as it has the new DietPi image, and it is before the addition of 3.5 board support (for which there might be outstanding issues still).

https://tiltaudio.com/changelog/

Go down to 1.32, you have a link to the update file and a link to the full image

Well if the fuse blows regularly, that's not good news.

So, questions:
1/ Did you connect anything on the board, especially on the so called PIN2DMD or 12V connector (for example to power your PIN2DMD) ? If so, please disconnect, this is not designed for that
2/ are your fuse slow blow or fast blow ? If Fast Blow, this would indicate you have a transient, if slow blow this would more indicate you're drawing too much current in average
3/ do you see any damage on the 12V regulator -the one with the blue PCB and the small variable resistor) ?

Can you check if you have a residual resistance between 12V and ground ?

I think the flow that Zigzagzag describes is the following:
- Put a fresh TA install sdcard in a system, boot
- System flashes STM32, rename file to .done if flash is successful, all is good

- Move SD card to NEW TA, with unprogrammed STM32

In this case, since the flash did take place on first board, the .done file is present, so TA SW does not detect that STM32 is not programmed on the second board

Based on the picture here: https://www.pinwiki.com/wiki/images/8/86/De_boardset.jpg
It looks like the audio board is rotated counter clockwise (ribbon cable at the bottom, speaker connector on the left)

Anyone would know of a 2 channels or even 4 channels bluetooth mixing table (ie mixing sound from four different bluetooth sources).

That would be awesome, with TA bluetoot capabilities, you could connect multiple pinball machines to a single subwoofer in your line up.
Alternatively adding bluetooth audio adapters, but it's not as integrated and clean

It does not precisely adress your question, but turn on one at a time, connect, then go into the config page to connect Tilt Audio to your home wifi network (you can also change the device name in the config, such as TiltAudio_Indy for example). That way you can easily access them all the time, especially useful for uploading packs. IMO a better alternative than having TA each acting as an access point.

Regards

There is a bug which prevents using Rpi3a+, for now you need to use rpi3b+

However your description would tend to indicate a power issue, does the rpi green led turns on?

If not, check the voltage level at the output of each regulator, one should read 5v, the other 12v

(edit) well I should have read more thoroughly. Looks like your rpi does not boot although it's powerd on, check the voltage levels though just in case, reflash the microsd card with another card

Are you using a RPI3a+? As noted earlier, there is a bug and your symptoms are similar to what I have seen

Otherwise, autodetection is not working, you need to manually set to the correct machine (wpc or otherwise)

One of the reason why on my TiltAudio pretty much everything is on socket...

There was some work done by a contributor, but he stopped as he did not want to spend time on a closed source SW. Unfortunately he did not provide his changes... You can save a one or two seconds, but preloading is what takes the most time (at least in my case)

From the slack channel, one of the recommendation was to use this sub: rockwood ydd-200. Super cheap, and it has a dual coil, so you can actually add more power output by wiring the secondary coil to the secondary output of the cabinet amp (requires a custom wire, but easy to implement on the board itself).

With regards to backbox speaker, I've been using recommendation from this page:
http://www.dziedzic.us/wpc_speaker_sound_info.html

Note that if you use the DSP, you do not need the speaker filter, the DSP will do that for you.

Sidenote: are you the author of the Hawkhole mix for LOTR ?

Did you connect the horizontal 4 pins header at the bottom of the blackpill board ?
What is the status of the blackpill led at boot, and during operation ?
Did you check continuity after your rework ? There is a schematics of the board showing the connections to help you check the board status

Seems to me the 4 pin header is OK (it's shown with pins and solder, so I assume it's connected below).

Some of your solder points on the vertical headers however seem dubious (hard to say with the picture quality), can you reflow them and add a small piece of solder ? Likewise, your resistor array do not look very well soldered...

Schematics can be found here: https://oshwlab.com/steve45/tiltaudio (although I get a 504 error right now)

With regards to the led, I don't recall exactly, but if my memory is correct the led should flash at boot at least, but need to check

Can you hear sound/music when triggering them manually with the webui?

Can you check the log to see if Tiltaudio detects sound commands?

And lastly... Which board révision is this?

Regards

Gut feeling, impédance matching.

Gut feeling ? Signal integrity and impedance matching.

That could be caused by a number of factors: ribbon cable, connectors, etc. I would reflow the solder on all connectors, and try a new cable. Pay especially attention to the ground signal (I don't recall though if the original ribbon cable has a ground wire between each signal wire to prevent crosstalk).

Try setting manually in the advanced config panel the machine type.

Autodetection never worked for me on WPC and WPC-DCS.

Sidenote, which Pi are you using in your TA boards?

Well I have a logic analyzer, but all my TAs are working

Joke aside, I'm curious : would it be possible to use a special debug program on the blackpill that would actually do just that, ie record data from the bus?

Data storage might be a problem though, but if possible that would make it easier for debug.

I'm really not familiar with the this STM part though, so it might be a completely bonker idea

I did ask on the Slack channel a while ago, and Steve was not involved at all. They do not seem to use TiltAudio SW. So it looks to be a custom CPU board, heavily derived from TiltAudio

I think it actually acts as the main CPU/sound board when running TOTAN2.0 code.

See cable f ? I'm pretty sure this is the audio cable, I2S. It's directly connected to the DAC.

Using the retro pinball platform, it looks like you can get by without a sound card in the first place, provided you have an amplifier board.

My understanding is that when using the original TOTAN code:
- original code runs on the FAST CPU board
- audio is routed to this "Tilt Audio" clone through a dedicated I2S cable
- DMD is replaced by a PIN2DMD, USB connection to the RPI, acting in Virtual Pinball configuration, with DMD data sent by the FAST CPU board to the RPI (which means the RPI translates the DMD information from the Fast board ). That's the "i" cable

When running TOTAN2.0 code:
- RPI act as the main controller: it's connected to the FAST board through a USB interface, connected to a Teensy (that's the small green vertical module). I presume that all IOs for switch/coils/GI/inserts are managed through that link
- RPI drives directly PIN2DMD and sound
- FAST Retro board acts as an interface to the power board and the switches

Unfortunately that retro board is not very well explained in terms of IOs and capabilities, there is no documentation on FAST website. Looks like it can't be ordered separately

Note that the same board was used on Funhouse 2.0, but they also used the new Pinsound board on top of it

With regards to the black pill, yes the 4 pin header need to be soldered to the main PCB. This is used to program the blackpill

As for the DAC, I'm not using it (using the DSP) except on an older board, and I don't recall not soldering one pin. But it has been a while, and I don't have the board anymore to check

Anyone reading this thread has experience on the DSP implementation in TiltAudio ?

Well for me I had a perfectly working unit in my Indy, which I transferred for testing in a Dr Who, all fine was working.

Built a second board, installed in Dr Who, bunch of issues (sounds playing back at wrong time, even when adjusting volume, etc). Checked decoder mode, all was fine. Reinstalled previously working board.... Failure, same symptoms.

Reflashed blackpills, reimage sd card, still not working....

Just an update, since some might have tried to update the TiltAudio image, the above steps needed some adjustments to work

SSH into your RPI, login/password are pi/pi, then type the following commands, one by one (the date need to be adjusted for the sync to work correctly, does not have to be accurate to the minute though)

From a working RPI with TA SD card:

sudo bash
date -s '22 Feb 2024 18:11'
apt-get update --allow-releaseinfo-change
dietpi-backup 1
sed -i 's/stretch/buster/g' /etc/apt/sources.list{,.d/*.list}
rm -f /etc/apt/sources.list.d/dietpi-php.list
rm -f /etc/apt/trusted.gpg.d/dietpi-php.gpg
rm -f /etc/apt/preferences.d/dietpi-{php,openssl,xrdp}
rm -f /etc/mysql/mariadb.conf.d/97-dietpi.cnf
/boot/dietpi/func/dietpi-set_software apt-cache clean
apt update
apt upgrade
apt full-upgrade
apt autopurge
/boot/dietpi/func/dietpi-obtain_hw_model
. /boot/dietpi/func/dietpi-globals

We will post a complete SD card image

One question, I was planning to add one in my Addams Family, but I seem to recall there's an issue with TiltAudio and TAF ?

Regards

and that works with a Pinsound ?

Thanks, I'll check it out

That said, I do wonder if there's a good mix for TAF anyway