Mine took 4 months to get here. Covid got all mail at a snails pace

I noticed there is a write up on how to test the tilt audio in WPC mode here:

https://tiltaudio.com/2020/11/13/test-a-tiltaudio-board/

Is there a similar version for testing the Tilt audio board in Data East mode?

Waiting for steve45 to have the time to chime in here, but maybe someone has experienced this problem and found a solution ?
Right now I have muted (or set gain to 1) for sound #186 and noticed that apparently other sounds are missing or erratic.

When I have a ball waiting in the shooter lane on my HS2 I only hear occasional motor sounds.
Music plays and repeats.
When the motor sound cuts out, sound #186 is played instead.

The weird thing is that this a constant error/problem.
It doesn't vary - maybe one out of 100 times another sound than #186 is triggered.

I have reflowed the board several times, tried different Pis etc. etc.
I have 74LVC* SMD chips presoldered on the board.

Has anyone experienced this - and found a solution ?
Is it all coming back to the SMD chips again ?

I had this exact issue on my Getaway with version 2.6f, this version PCB had missing GND to the ICs which I fixed but the issue remained so it made no difference if the SMD ICs worked or not !! steve45 has one fully working on his Getaway for years so it must work so there must be some difference between his Getaway and others ..... unfortunately after about 6 Months I gave up in the end and bought a Pinsound but I like the fact it can drive LEDs so I try to keep interest in the project.

Which ROM version do you have installed on your HS2 ?

lucky1 it's the latest, L5.

Mine is the L5 as well, Patched for non flickering LEDs.

nutty yep, tried both patched/unpatched, no difference unfortunately.

I also run L5 no ghosting ROM. Do you have a plasma display installed ? If yes could you please test with the power of the plasma unplugged if the false triggers still happen ? I´m just looking for a difference. Steve and I have a PIN2DMD installed.

lucky1 I understand, and this is the situation :

- I have 3 cards (actually 5, just 3 finished) - all version 3.0 from JLPCB with the 3 SMD chips presoldered (2 cards with 74LVC* and one where I have tried to replace the 74LVC00 and 74LVC138 with the LCX versions)
- I have 3 Raspberry Pi 3B+
- I use firmware 1.32
- I use the altsound sound sets

This is what I have done :

- I have tested all 3 cards in 3 machines : IJ, HS2 and TAF (I only used one brand new Pi3B+ for this)
- I have Pin2Dmd in all 3 machines
- I have tried disconnecting both power and ribbon cables from Pin2Dmd in HS2
- I have tried disconnecting the Fliptronic card from the ribbon cable
- I have tried a separate 12V PSU to drive the Tilt card
- I have checked with a multimeter that the connections from the ribbon plug to the resistors/resistor networks/SMD chips are ok
- I have tried to tie an extra ground cable from chassis to ground on the sound card
- I have reflowed the solder points from WPC connector inwards several times
- I have tried firmware 1.30
- I have tried patched antighosting and plain L5 ROM in HS2

The results are the same for all 3 cards.
On HS2 and TAF, sound #186 will be played almost every time a SFX is played.
About 1 in 100 times another wrong SFX will be played.
On TAF, I noticed the sound when pressing the flipper buttons in attract mode was wrong - #186 was played again.
On IJ, wrong music and wrong/missing samples are played - for example no plane sound when going over left ramp, "choose wisely" music playing during normal game, game music stopping early leaving silence with only sound FX.
On HS2 I noticed the supercharger sound effect doesn't stop when the ball leaves, it continues to play until the sound file ends.

All machines are running the latest ROMs from IPDB.
TAF and IJ have been running fine with original sound cards for months.

In HS2 I noticed that when entering the test menu, the "ding" sound is played for each button press as it should - but on top of this, sound #186 is played as well.
In sound test on HS2, all music and sounds are played correctly - but at the start of each sound/music part, sound #186 is also played.

In attract mode on HS2 (which should be quiet) I have #186 but also other sounds playing sporadically.

The "please register" message plays 3 times in succession with a short delay between each time.
This happens every ?? minutes, don't know if this is normal.

I have done the same tests with Pis that are registered, same result.

There might be other errors (music stopping early etc.), but I haven't had time to log this accurately.

I have sent log files of all this to Steve.

I have now ordered from LSC the exact same SMD chips as Steve delivers with his kits.
But looking at the data sheets I can't see what the difference would be between them and the ones I got from JLPBC.
The ones I have from JLPCB are :
74LVC574AD
74LVC00A
74LVC138A0 (may be AD instead of A0)

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 would say these are simply wrong settings in the soundset.
Even if it called original soundset, the categories of the different sounds have been assigned manually and therefore there is a good chance that someone chose the wrong category.

lucky1 Ok, these are straight, unaltered, directly downloaded from http://altsound.vpin24.com/ and directly extracted to the SD card which is freshly formatted/installed from the 1.32 firmware archive downloaded from TiltAudio.
I have not changed anything along the way - this is a pure stock installation.
I would be surprised if the altsound package was wrong and no one had noticed this before ?
Would anyone using TiltAudio and altsound package on IJ be able to comment on this ?

lucky1 I can of course test in all games if you or Steve have working soundsets you can send me if you believe that is the issue.

I am willing to do a lot of testing to get these 5 boards going so the money I have invested doesn't all go to waste, so let me know what I can do/help with.
I am fairly comfortable on Linux and very used to using the command line, doing basic compiling, testing different configurations and doing software debugging.

I asked steve45 once to buy an SD card all setup for the Getaway cloned from his but he said it would make no difference so rejected the idea, I of course just wanted it working. To me random sounds playing is an input signal error to the Pi. It all worked correctly in the software until the pinball BUS was in control. Surely if it was the wrong soundset you would get sounds in the correct place but possible the wrong sound being played not random playing of sounds when the pi felt like it.

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.

Ashram56 Good to hear that the (to me strange) missing single sound may be normal.
My effort was to describe all issues as I experienced them - I believe that if the issue of sound #186 playing on both HS2 and TAF across 3 different Tilt cards is solved, the IJ sound package will fall into place as well.
I don't think that doing an exact comparision between stock altsound packages and stock IJ sound card is the way to go here, but if that is what is needed I will of course do that.

Did you doublecheck the orientation (dot) of the resistor arrays ?

Yes, I have double checked the 4k7 arrays - dots are oriented right way as indicated here : https://tiltaudio.com/2020/12/10/assembly-of-rev-2-8-3-0/

SMDs are pre-soldered by JLPCB and look to be right as far as I can see.
I used single 47 ohm resistors for the bus.
Capacitors are 100nF - on one board I have used the ones I had from 2.6d kit, on another board I have used new ones.

I also measured resistance from WPC contact -> other side of 47 ohm resistors and from 47 ohm resistors to +5V rail.
All values are as expected, no breaks.

I double checked the voltages from each regulator under load as well, all is as it should be.
Sound is playing fine, so I assume sound card and power amps are all ok.
1000uf are all 3 correctly orientated.

Very strange ! I tested a V3.0 board in my getaway today and did not have the problem with sound #186.
What I could reproduce is the issue with the supercharger sound not stopping and background music did also not stop at the end of the game,
but that is issue caused by the soundset and not the hardware.

Strange indeed, but good to know what is and what isn't normal.
I will hopefully try one of the boards in a friend's HS2 this week.
LSC will probably ship the new SMD chips tomorrow, so I hope to have them here in a couple of weeks.

I just ordered one of the latest V3.0 kits so I can try that in my Doctor Who.

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 Is WDEN polled or is it an interrupt ?
If WDEN "hangs", could it cause a double interrupt or be double polled so the isr_wpc thread reads another (faulty) command ?

@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

steve45 Thanks, I might take you up on the offer. Today I will test one of the cards in a friend's HS2. The exact same SMD chips you use are on their way, I will try to exchange these on one of the boards. If neither of these pan out, I will contact you.

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

Ashram56 i this something I should try too ?

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/

steve45 Ok, I tested card #1 in my friend's HS2, and it behaves exactly the same as in mine.
So I guess that rules out any possible problems with the machines.

I will try the RT kernel next.

Ashram56 steve45 RT kernel made no difference.

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

Yep, unfortunately - it would have been nice if it was a software fix.
Now it seems to boil down to the SMD chips again - unless my soldering skills are so bad that I messed up 3 boards the same way

Hi, I just made my first tilt audio and I have a problem. I have 3.1 PCB and my skill in electronic is not so bad. But, when I put my tilt audio in my addams, I switch on and CPU check rom. At this time, I have an error and if I go in settings, It's wrote " sound board interface error ". My tilt audio boot and I can play normally. All musics and sounds trigger are ok. I put in theater of magic... It's the same problem. So I think, it's a tilt audio problem. Can you show me the way to verify the good parts and wiring. My CMS parts are 74LVC574AD, LVC138A, 74LVC00AD and it's a full kit from go-dmd. Regards

IMG_8878 (resized).JPG

IMG_8879 (resized).JPG

Can you post hires photos of your sound board? I'd check for solder bridges on the surface mount chips. Get out the magnifying glasses! If you have a solder bridge those are usually easy to remove using a good quality solder wick.

Thanks, here some pictures. CMS parts seem to be correctly welded. I test continuity from connector to input of 3 74x.. So, I made a bridge. I think, I will remove connector, clean and reweld.

IMG_8883 (resized).JPG

IMG_8884 (resized).JPG

IMG_8885 (resized).JPG

IMG_8886 (resized).JPG

IMG_8887 (resized).JPG

It looks like there could be a solder bridge between two pins on IC2.

Tiberium It is normal to get "sound interface error" because the sound card boots slower than and (AFAIK) doesn't write back to the MPU.
If all sounds play normally during game and you have no extra/wrong/missing sounds I would say it is working as it should.
Is this the case ?

That error is normal with Tiltaudio because it currently does not respond to the soundboard check sent from the CPU. Just ignore.

Yup, unfortunately that is something you will have to live with. Hopefully Steve can eliminate that in later versions. The other brand figured it out, so hopefully Tiltaudio would be able to eliminate it as well.

What is the purpose of that bridge ? https://i1.pinside.com/2/62/2621429a0c66e5f5b28f70e985c6950191339698/resized/740/2621429a0c66e5f5b28f70e985c6950191339698.jpg

That pin 31 (RW) of the WPC connector should go to pin1 of LVC138 but you connected it to DataEast Strobe ???

Should not cause any trouble in WPC but why ??