News:

SMF for DIYStompboxes.com!

Main Menu

Tap Tempo Delay out of sync

Started by drolo, September 06, 2013, 06:40:52 AM

Previous topic - Next topic

drolo

Hi,

I just bought a chinese NUX Time Force Delay.
http://www.speedmusic.co.uk/NUX-Time-Force-DelayTime-Looper-Pedal-372.asp

While the sound quality and options are awesome, the looper very useful, the Tap Tempo function is a big disappointment.

The actual time displayed on the screen and also applied to the delay is always a bit faster than what was tapped in. For example if I tap to a 120bpm beat, the screen will show around 133-135bpm. Impossible to keep the delay in sync with anything like that.

I was going to return it but then noticed that all the online demos were showing the same issue, weird that nobody seems to have noticed ...

I had a quick peak inside hoping for a trimpot or anything. Naught..

(note: I am completely unexperienced in digital technology and my only knowledge about coding of any sort goes back to school time 20 years ago when we learned a prgramming language called logo with a little turtle that did ... stuff ..)


It is really a pitty if I can't make the TAP function work, this pedal would have replaced my TC Flashback with its useless "strum tempo" feature ...


I was just wondering if any of you wizards would have an idea for trick to workaround this issue?

I did not take it appart enough to see what kind of components are inside, but i might find the courage to crack it open if it could be of any use or if there is a slight hope ...


g_u_e_s_t

its most likely a problem with the code onboard, so a difficult one to fix.  have you tried emailing the company to see if this is a known issue with a workaround?

there is a small chance that they are using a really bad switch debounce circuit that has a huge delay in it.  if that was the case, then it might be fixable.

the only other solution i can think of, is an external tap switch, that closes the onboard tap switch for a shorter amount of time.

drolo

HI,

I will try emailing them, even if I doubt ever getting a reply from a "shady chinese company" :-)... you never know

The weird thing is the the tap tempo LED flashes correctly in sync to what i tapped, but the displayed rate and the rate applied to the delay is constantly 10% faster. So it seems like its not the debounce circuit but perhaps the code ...


Ice-9

Wow, that pedal offers a lot for the price, I found it on the net for £67. It's a shame it has this problem, If the LED flashed at the correct tempo but the display and sound are different it does indeed sound as G.U.E.S.T mentioned a firmware problem.

If you can post a picture of the PCB for people to see what chips are inside then maybe someone could spot a solution, but to be honest it could be that a firmware update is the only option.
www.stanleyfx.co.uk

Sanity: doing the same thing over and over again and expecting the same result. Mick Taylor

Please at least have 1 forum post before sending me a PM demanding something.

drolo

Yep, a pity they messed up the tap tempo feature ..

I emailed them but doubt i will ever hear from them.

I will see if I can find some time to take it apart and post pictures

pk1802

I've also noticed that the LED flashes in time with what you tap, but the delays are out of sync with that. In the hopes that someone can figure something out, I've taken my Time Force apart and snapped some pictures. I am going to leave the pedal stripped down for 2 weeks(until Nov 1) so if you need any more pictures, ask soon, that way I don't have to tear it down again.


































The big chips are as follows.

The chip with the big 3 written on it(some numbers rubbed off) - Texas Inst DSP TMS 300 320VC5501PGF? CA-27ALVLW G4
Chip above the DSP - Electrontech EM638165TS-6G Q258713BHE376 1-2
Chip adjacent to DSP - SST 39VF400A 70-4C-EKE  1225GY5-G

drolo

Thanks for the pics, I was scared to dismantle mine that much, when I saw the weird stuff like the big cap with glued wires going to the other side of the board ...

A pitty thay messed up with the tap tempo.. other than that, the unit is great. I love how easy you can engage the looper and go back to normal delay use, without ever needing to use anything else but your feet ...

Ice-9

#7
The chip with the big 3 written on it(some numbers rubbed off) - Texas Inst DSP TMS 300 320VC5501PGF? CA-27ALVLW G4

Chip above the DSP - Electrontech EM638165TS-6G Q258713BHE376 1-2 = This is a DRAM chip Most likely used for delay memory

Chip adjacent to DSP - SST 39VF400A 70-4C-EKE  1225GY5-G = This is a 48TSOP Eeprom Most likely this one holds the program code.

There looks to be some Jtag points on the PCB that could be used to read/program the Eeprom but not really of any use to alter the code.
www.stanleyfx.co.uk

Sanity: doing the same thing over and over again and expecting the same result. Mick Taylor

Please at least have 1 forum post before sending me a PM demanding something.

slacker

It's not something as simple as the LED flashes at the time you tapped in, and the actual delay is in some division of this, eg: you tap in 1/4 notes and the delay does dotted 1/8s or something.

pk1802

Quote from: drolo on October 21, 2013, 05:50:16 AM
Thanks for the pics, I was scared to dismantle mine that much, when I saw the weird stuff like the big cap with glued wires going to the other side of the board ...

A pitty thay messed up with the tap tempo.. other than that, the unit is great. I love how easy you can engage the looper and go back to normal delay use, without ever needing to use anything else but your feet ...

My pleasure. This community has helped me learn so much, I look for any opportunity I can to help out.

Quote from: slacker on October 22, 2013, 02:21:25 PM
It's not something as simple as the LED flashes at the time you tapped in, and the actual delay is in some division of this, eg: you tap in 1/4 notes and the delay does dotted 1/8s or something.

I wish it were that simple. The delay comes out about 5%-10% off. And it is the same with any delay division. I've tapped the tempo along with a 100bpm metronome, and the LED flashes at the right speed, but the readout says 107bpm and the delay is reflected by what is on screen. It seems that whatever the readout on the screen says, is the actual bmp of the delayed signal. I used the knob to set the tempo at 100bpm, and the delays matched the metronome perfectly (The LED did not).

I've been calling the US Nux support line, and finally got a hold of someone today. She barely spoke English, but gave me the phone number for technical questions. I've gotten no answer at that number, and the voicemail box is full.

Ice-9

Just a shot in the dark here but could it be something as simple as the clock frequency for the DSP is a bit off from the recommended spec?
www.stanleyfx.co.uk

Sanity: doing the same thing over and over again and expecting the same result. Mick Taylor

Please at least have 1 forum post before sending me a PM demanding something.

slacker

I was wondering that as well. That could be it, especially given Pk1802's comments about the LED not matching if you set the time manually. Might be worth replacing the crystals with higher prescision ones or maybe they used the wrong speed ones. Can't read the writing on them unfortunately.

pk1802

Quote from: slacker on October 22, 2013, 05:50:23 PM
I was wondering that as well. That could be it, especially given Pk1802's comments about the LED not matching if you set the time manually. Might be worth replacing the crystals with higher prescision ones or maybe they used the wrong speed ones. Can't read the writing on them unfortunately.

Just so I am checking the right components, are these the crystals? I've never messed around much in the digital domain of effects. If these are them, I can get you the info on them soon.

drolo

Quote from: slacker on October 22, 2013, 05:50:23 PM
I was wondering that as well. That could be it, especially given Pk1802's comments about the LED not matching if you set the time manually. Might be worth replacing the crystals with higher prescision ones or maybe they used the wrong speed ones. Can't read the writing on them unfortunately.

Are there different tolerances in crystals? Or would we try to replace the existing one with one that has a frequency 10% smaller (or higher ?)

Ice-9

Quote from: drolo on October 23, 2013, 04:41:52 AM
Quote from: slacker on October 22, 2013, 05:50:23 PM
I was wondering that as well. That could be it, especially given Pk1802's comments about the LED not matching if you set the time manually. Might be worth replacing the crystals with higher prescision ones or maybe they used the wrong speed ones. Can't read the writing on them unfortunately.

Are there different tolerances in crystals? Or would we try to replace the existing one with one that has a frequency 10% smaller (or higher ?)

Its quite likely that those two crystals are different values, which clock the DSP at one frequency while the other is clocking other parts of the circuit at a different freq. What are the smaller chips near the right side crystal, could it be an Atmel or PIC chip being clocked by this xtal.
There will be an acceptable tolerance on clock rate for the chips/xtals which will allow the chips to run correctly.
www.stanleyfx.co.uk

Sanity: doing the same thing over and over again and expecting the same result. Mick Taylor

Please at least have 1 forum post before sending me a PM demanding something.

pk1802

Quote from: Ice-9 on October 23, 2013, 05:28:01 AM
Quote from: drolo on October 23, 2013, 04:41:52 AM
Quote from: slacker on October 22, 2013, 05:50:23 PM
I was wondering that as well. That could be it, especially given Pk1802's comments about the LED not matching if you set the time manually. Might be worth replacing the crystals with higher prescision ones or maybe they used the wrong speed ones. Can't read the writing on them unfortunately.

Are there different tolerances in crystals? Or would we try to replace the existing one with one that has a frequency 10% smaller (or higher ?)

Its quite likely that those two crystals are different values, which clock the DSP at one frequency while the other is clocking other parts of the circuit at a different freq. What are the smaller chips near the right side crystal, could it be an Atmel or PIC chip being clocked by this xtal.
There will be an acceptable tolerance on clock rate for the chips/xtals which will allow the chips to run correctly.

I didn't even think to check for any microcontrollers. I'll check on that tonight. I've got the codes from the crystals though. In the picture below the crystal above the DSP is 20.00JS20. The crystal to the right is 11.28HS20.


free electron

The 20MHz crystal is used to clock the DSP and the 2nd, 11.28MHz is most likely used to clock the codec chip or AD/DA converters (11.28MHz / 256 = ~44kHz). The issue looks like a firmware bug. One possible DIY workaround would be to determine if the difference between the tapped and actual delay time is constant and if that's the case, use a small 8pin microcontroller to read the tap footswitch, correct the the time and "tap" the original circuit with the new value.

g_u_e_s_t

11.28MHz is a standard crystal for codecs, and the 20MHZ is probably for the DSP, with an internal PLL to scale it up to whatever i runs at.  the fact that the LED is out of time is curious, and does suggest that there might be a microcontroller somewhere else on the board (which there usually is, as the DSP spends all its time on the audio, and there is a display to run on this thing).  what does the led control line run back to?

crystals tend to be within less than 1% tolerance at the worst case, so its probably not a bad part, although it wouldnt hurt to measure the frequency if you have an oscilloscope.

g_u_e_s_t

the 11.28MHz crystals are designed for 44.1ksps playback.  if the original design was for 48ksps, and then they changed it down the line and didnt fix all the code, it could cause a frequency shift (if the codec is in master mode).  this would give a 10% frequency shift, although it would slow the BPM down, rather than speed it up.

pk1802

Quote from: g_u_e_s_t on October 23, 2013, 03:37:00 PM
11.28MHz is a standard crystal for codecs, and the 20MHZ is probably for the DSP, with an internal PLL to scale it up to whatever i runs at.  the fact that the LED is out of time is curious, and does suggest that there might be a microcontroller somewhere else on the board (which there usually is, as the DSP spends all its time on the audio, and there is a display to run on this thing).  what does the led control line run back to?

crystals tend to be within less than 1% tolerance at the worst case, so its probably not a bad part, although it wouldnt hurt to measure the frequency if you have an oscilloscope.

I found an Amtel ATMEGA64A AU1224 hiding under the display. Didn't think to look there before. http://www.atmel.com/images/atmel-8160-8-bit-avr-microcontroller-atmega64a-datasheet.pdf (Big PDF)

I don't see any other controllers. I did find the A/D and D/A converters though.
1. AKM 5358AET 4E217 - A/D converter. http://pdf1.alldatasheet.com/datasheet-pdf/view/206772/AKM/AK5358AET.html
2. AKM4388ET 2E207 - D/A converter. http://www.datasheetarchive.com/dl/Datasheets-IS5/DSA0081424.pdf

The LED control line is hard to trace, it runs under some switches, but as far as topography goes, it stays on the Board with the screen and heads in the direction of the ATMEGA. It's close enough to the ribbon cable that travels between boards, that if it was going to jump ship, I assume it would head that way first.

I do have an oscope, but it was grandpa's and it is old, and I have no idea how to use it (or if it even works).