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 ...
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.
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 ...
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.
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
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.
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164603_zps45a77db5.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164603_zps45a77db5.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164649_zps6fbbc00b.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164649_zps6fbbc00b.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164725_zpse5152883.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164725_zpse5152883.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164731_zps5b23f55b.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164731_zps5b23f55b.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164741_zpsd001b94b.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164741_zpsd001b94b.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164807_zps1776546a.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164807_zps1776546a.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164818_zpsb736decd.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164818_zpsb736decd.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164834_zps1e967023.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164834_zps1e967023.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164844_zpsf29453c0.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164844_zpsf29453c0.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164849_zpsc989486d.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164849_zpsc989486d.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164917_zps757d0384.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164917_zps757d0384.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164924_zps84ec3f60.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164924_zps84ec3f60.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164930_zpsb2fb732e.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164930_zpsb2fb732e.jpg.html)
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131018_164936_zps9589e8b0.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131018_164936_zps9589e8b0.jpg.html)
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
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 ...
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.
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.
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.
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?
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.
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.
(http://i5.photobucket.com/albums/y184/pk1802/crystals_zps7deddc1e.png) (http://s5.photobucket.com/user/pk1802/media/crystals_zps7deddc1e.png.html)
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 ?)
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.
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.
(http://i5.photobucket.com/albums/y184/pk1802/crystals_zps7deddc1e.png) (http://s5.photobucket.com/user/pk1802/media/crystals_zps7deddc1e.png.html)
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.
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.
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.
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).
can you get a picture of the atmel?
the atmels are much more approachable to reprogram, so there might be a solution here. you should definitely bust out your old scope and figure it out.
is there a crystal for the atmel? a ceramic resonator? if they are running the atmel off its internal RC timer, that can easily have a 10% drift, and would account for the error. that is fixable by recalibrating the internal RC timer, or putting a crystal on it. but both of those solutions require modifying the micro.
here is my guess as to how it works:
1. the atmel does all the dirty work - measures the tap rate, samples the knobs/buttons, makes leds blink, and writes data to the screen
2. the DSP does the DSP - it gets passed variables from the atmel which tells it what the current control settings are, and it just chunks through the data.
so what is probably happening, is that the atmel samples the footswitch for the delay time, and has its own internal timer it uses to blink the LED. so the LED matches what you tapped in. it also displays this value on the screen, but this is done in aboslute terms, which shows the wrong value because the atmel clock is off. it then sends this off value to the DSP, and the audio gets processed wrong. if you fix the clock on the atmel, you fix the problem.
just double checked the atmel datasheet. the internal RC oscillator is factory calibrated to +/-10%. so that definitely sounds like the issue. it can be recalibrated to +/-1%, which should probably be close enough. im suprised they didnt do that at the factory. but if you can get pictures, it might be that they used a cheap ceramic resonator, in which case replacing that would do the job as well.
Quote from: g_u_e_s_t on October 24, 2013, 05:44:06 PM
just double checked the atmel datasheet. the internal RC oscillator is factory calibrated to +/-10%. so that definitely sounds like the issue. it can be recalibrated to +/-1%, which should probably be close enough. im suprised they didnt do that at the factory. but if you can get pictures, it might be that they used a cheap ceramic resonator, in which case replacing that would do the job as well.
This is a picture of a close up of the amtel. I'm not seeing any ceramic resonators, but I am just looking for something with three pins that doesn't look like a transistor. I guess it would help to know off what pin of the amtel I would be looking for a resonator on. And what the resonator might look like? What is the typical silk screen code for a resonator? P1, S1, L1, U1 etc?
The transistor on the upper right (U2) of the picture is AF-BF-1
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131024_150735_zps82cf4f80.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131024_150735_zps82cf4f80.jpg.html)
the oscillator should be on pins 23 and 24, which have nothing connected. so they are using the internal RC oscillator. crystals and resonators are usually labeled X, or XTL
can you get a nice picture of the backside of the display board? im wondering if that connector to the right is the ISP header. it doesnt look like they pinned out the JTAG.
it looks like a 10p atmel ISP header, with one pin removed for keying. the pins follow the same convention, with power in the corner, and all the ones above it ground. the reset line is in the middle on the other row. you can pick up an ISP programmer for 20$, and reset the fuses. if they dont have the lockbits set you could have all sorts of fun in there.
Quote from: g_u_e_s_t on October 24, 2013, 07:11:17 PM
can you get a nice picture of the backside of the display board? im wondering if that connector to the right is the ISP header. it doesnt look like they pinned out the JTAG.
(http://i5.photobucket.com/albums/y184/pk1802/IMG_20131024_195347_zps984867a0.jpg) (http://s5.photobucket.com/user/pk1802/media/IMG_20131024_195347_zps984867a0.jpg.html)
Is this the JTAG?
(http://i5.photobucket.com/albums/y184/pk1802/1b102744-9d1c-454b-b199-6d79e992b7af_zpsfbf4d501.jpg) (http://s5.photobucket.com/user/pk1802/media/1b102744-9d1c-454b-b199-6d79e992b7af_zpsfbf4d501.jpg.html)
Besides these two headers, there are no others.
the one you marked is most likely the JTAG for the DSP chip.
the other one is an atmel ISP header, and pinned out correctly for their 10-pin headers. unfortunately the oscillator calibration byte is not a fuse which can be set, and needs to be programmed in the code. so if they have locked the microcontroller, there is no real fix which can be done. if they have not locked the microcontroller, then it can be easily fixed.
you should be able read the state of the fuses regardless of lock bit status.
Wow guys ...
I'm sorry and embarrassed that I'm not able to help much with the troubleshooting, despite being the original poster ... this is way out of my league ... :-(
But if you do find a solution, (and even if not) you will have earned my unconditional recognition towards you and your families for the coming 10 generations :-D
to those who have these malfunctioning pedals, i would highly reccomend asking around and seeing if anyone you know has an atmel isp programmer. its an easy task to check if the lock bits are set, and if they are not, its a pretty easy fix to put a crystal on (at least if you can solder smt stuff). mostly, im just really curious at this point.
Quote from: g_u_e_s_t on October 28, 2013, 04:47:33 PM
to those who have these malfunctioning pedals, i would highly reccomend asking around and seeing if anyone you know has an atmel isp programmer. its an easy task to check if the lock bits are set, and if they are not, its a pretty easy fix to put a crystal on (at least if you can solder smt stuff). mostly, im just really curious at this point.
hmm ... I just read in a thread a couple of days ago where pinkjimphoton says he has one that he loves. I will ask him about his :-)
I didn't notice before but I have just had a look at your pictures again and in the first picture just out of interest, there are some SPI programmer connections as well.
Quote from: drolo on October 28, 2013, 04:56:27 PM
Quote from: g_u_e_s_t on October 28, 2013, 04:47:33 PM
to those who have these malfunctioning pedals, i would highly reccomend asking around and seeing if anyone you know has an atmel isp programmer. its an easy task to check if the lock bits are set, and if they are not, its a pretty easy fix to put a crystal on (at least if you can solder smt stuff). mostly, im just really curious at this point.
hmm ... I just read in a thread a couple of days ago where pinkjimphoton says he has one that he loves. I will ask him about his :-)
I just realized i completely misunderstood your suggestion. Thought you were telling to find someone who has a working pedal and check that on his ... nevermind, ignore my comment then ...
I dont know any one who has such a programmer, but could there be any harm in trying to solder a crystal in there, without checking for the lock bits first?
Just soldering a crystal in won't do anything, you need to reprogram the configuration bits to tell the chip to use the crystal instead of its internal clock.
You can program ATmegas using a PC parallel port and freely available software, I don't know if this is an option in this case.
I have a MiniPro TL866cs USB programmer. From what I understand, I can open the case and add a ISP header. The only problem is that my new computer won't recognize the programmer.
I did finally get an email back from Nux:
QuoteI"m looking into it for you, stay tuned.
ron
I'll try to figure out the programmer and see what happens.
you should email NUX a link to this thread, or just tell them what the problem is. if youre actually emailing with an engineer at the company, im sure he/she would be very grateful and would be more inclined to help you out. it would also increase the chances that future pedals of theirs work properly. all they have to do is run a calibration sequence to fix the current ones.
Quote from: g_u_e_s_t on October 31, 2013, 02:02:59 PM
you should email NUX a link to this thread, or just tell them what the problem is. if youre actually emailing with an engineer at the company, im sure he/she would be very grateful and would be more inclined to help you out. it would also increase the chances that future pedals of theirs work properly. all they have to do is run a calibration sequence to fix the current ones.
Good idea, I just did that
any word from the company? any interest in checking the fuse bits?
Quote from: g_u_e_s_t on November 13, 2013, 01:52:28 AM
any word from the company? any interest in checking the fuse bits?
No word. I am interested in checking the fuse bits, but I have finals coming up and I am not going to have time to do it. Maybe I can get at it during the winter break.
Quote from: g_u_e_s_t on October 23, 2013, 03:40:37 PM
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.
The OP said that they get 133-135BPM when they tap 120bpm. That is very suspicious to me because 135/120 is exactly 1.125. 48/44.1 is only 1.088, so it doesn't provide a big enough effect to explain what we're seeing here.
Quote from: g_u_e_s_t on October 24, 2013, 05:44:06 PM
just double checked the atmel datasheet. the internal RC oscillator is factory calibrated to +/-10%. so that definitely sounds like the issue. it can be recalibrated to +/-1%, which should probably be close enough. im suprised they didnt do that at the factory. but if you can get pictures, it might be that they used a cheap ceramic resonator, in which case replacing that would do the job as well.
Highly unlikely in my view. I haven't used the Atmels but the PICs have a similar RC oscillator with a similar spec. In general they're extremely close to the stated value, and the +/-10% is just so they don't throw many anyway at QA. Furthermore the error reported is *more* than 10%, and seems to affect *all* units, if what's reported here is correct. That wouldn't happen if it was statistical variation between units within spec.
HTH,
Tom
Quote from: ElectricDruid on January 23, 2014, 10:07:41 AM
Quote from: g_u_e_s_t on October 23, 2013, 03:40:37 PM
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.
The OP said that they get 133-135BPM when they tap 120bpm. That is very suspicious to me because 135/120 is exactly 1.125. 48/44.1 is only 1.088, so it doesn't provide a big enough effect to explain what we're seeing here.
Quote from: g_u_e_s_t on October 24, 2013, 05:44:06 PM
just double checked the atmel datasheet. the internal RC oscillator is factory calibrated to +/-10%. so that definitely sounds like the issue. it can be recalibrated to +/-1%, which should probably be close enough. im suprised they didnt do that at the factory. but if you can get pictures, it might be that they used a cheap ceramic resonator, in which case replacing that would do the job as well.
Highly unlikely in my view. I haven't used the Atmels but the PICs have a similar RC oscillator with a similar spec. In general they're extremely close to the stated value, and the +/-10% is just so they don't throw many anyway at QA. Furthermore the error reported is *more* than 10%, and seems to affect *all* units, if what's reported here is correct. That wouldn't happen if it was statistical variation between units within spec.
HTH,
Tom
In that case it is just poor code. It is hard to believe that it hasn't been fixed in newer units though as they must be getting some poor feedback from customers.
Quote from: Ice-9 on January 23, 2014, 01:22:01 PM
In that case it is just poor code. It is hard to believe that it hasn't been fixed in newer units though as they must be getting some poor feedback from customers.
Worrying too much about "Time to market" ruins another potentially good product? When will the marketing department learn that a sh*te product hurts you far more than a late, brilliant product ever does?
2 cents,
T.
I totally agree. It's a shame as they have quite nice products, a bit different than the other stuff coming from China lately, which are just copies of other pedals.
Unfortunately inconsistencies like these, the fact that the products can only be purchased through some "shady" sellers on ebay and such plus the fact that they won't reply to any email makes it kind of a deal breaker. Too bad for them ...
did anyone ever read the fuse bits and lock bits off the atmega? im just curious whether a fix is possible.
Quote from: g_u_e_s_t on February 10, 2014, 06:19:54 PM
did anyone ever read the fuse bits and lock bits off the atmega? im just curious whether a fix is possible.
Nope, and don't know anyone who knows how to do that, I guess i will have to live with it ... or sell it :-(
Hi,
i am new here.
But i have also the delay problem.
But i have found some other bugs.
Can anybody please verify that?
Select the Stereo Delay, connect both output channels (stereo)
Turn the Delay Tail on, and the Bypass mode to FET.
Now feed a signal into the NUX Timeforce and tap a tempo with the tap tempo button.
Now the delay sound gets distorted on one outpuchannel.
If you now turn the time know the distortion (artefacts) are gone and the delay works normal ....
Taping again and you have instant a distorted delay sound.
Next bug is:
Revers delay.
Turn the effect on and turn on the delay tail.
then disable the delay effect by pressing on/off and you will hear a phased out sound.
If you turn of the delay tail it will sound normal.....
It would be very nice if someone could try this on your own time force.
b.t.w. i have an atmel ISP programmer and a bit knowledge in asm programming
i want to be shure that the bugs mentioned above are not an error of my very own device bevor i start soldering an isp connector
I have not noticed these issues as I have never tried to use it in stereo. I will give it a try if I find some time this weekend.
But speaking of other issues, do you also notice a lot of noise on the looped tracks? Like white noise that gets amplified every time you overdub the track ?
Quote from: BlueRed on February 11, 2014, 03:44:53 PM
b.t.w. i have an atmel ISP programmer and a bit knowledge in asm programming
i want to be shure that the bugs mentioned above are not an error of my very own device bevor i start soldering an isp connector
sorry to hear its not working well, but it is cool to hear you know asm. if the lock bits arent set, you can just read out the code and work with it. unfortunately, the problems you describe sound like they are on the DSP, although maybe there are some workarounds.
@drolo:
Please try it out i would be very happy to know if that is an issue of my model or a general problem of the dsp programming.
About the white noise, i also did notice it, but only if you drive the input to high.
On a lower input level it´s okay and i dont have any white noise.
About the stereo delay.
I would be realy happy to have a feedback about this.
If you check the stereo delay please connect it in stereo and use a headphone, because its easylie to hear on the right outputchannel.
The artefacts are only ocoure on the right outupt channel, the left channel is okay and they only are hearable if you use the TAP switch.
The aretefacts will vanish if you turn the time knob a little bit.
I think nux has messed up the controlling frontend (the atmel avr) for the DSP.
Quote from: BlueRed on February 12, 2014, 05:11:39 PM
@drolo:
Please try it out i would be very happy to know if that is an issue of my model or a general problem of the dsp programming.
About the white noise, i also did notice it, but only if you drive the input to high.
On a lower input level it´s okay and i dont have any white noise.
About the stereo delay.
I would be realy happy to have a feedback about this.
If you check the stereo delay please connect it in stereo and use a headphone, because its easylie to hear on the right outputchannel.
The artefacts are only ocoure on the right outupt channel, the left channel is okay and they only are hearable if you use the TAP switch.
The aretefacts will vanish if you turn the time knob a little bit.
I think nux has messed up the controlling frontend (the atmel avr) for the DSP.
I finally got to try this in stereo but I could not reproduce your issue.
Seems like not only they messed up the code but have very inconsistent quality control ... :-(
hi,
I write you from France, I just bought a nux time force; I ve put a bad power supply so it burned!
I m trying to fix it, but i need to have schematics...
or if someone can tell me what component is Q1, because it seems to have burned.
I ve just tried a few momnt with the battery and found the se problem on the tap tempo.
too bad!
thank you
Tristan
Salut Tristan,
Sorry no idea :( it's all too small for my poor eyes to identify anything.
how did you fry it? Perhaps follow the power line until you identify something thay could be damaged
good luck
thank you for your answer,
I just found the Q1 seems burned but I don t know what it is...
don t know what to do
could be a voltage regulator. can you read something on it? there is a pic showing Q1 a few answers back but its hard to read what it says, its too small
Hi,
I know it's an old post but yesterday I've bought one of that. Just opened because I would like to lower the volume output of the looper (no volume control, shame).
Take a look at the board that is very similar to the one photographed I saw different revision, mine is VER:8.0 2013-10-16. In the photo version seems to be 5.0. The other one is no yellow wire on the downside... I think this is the variation.
I've not checked with a metronome if Tempo it's right on mine, but it seems.
Under the display the Atmega still no have external resonator or quartz (the MCU version is 2.1) so I think for Tempo issue it's a software upgrade.
If I mod something I'll post on this thread.
Bye.
So yours taps with reasonable accuracy?
I've just checked now with the iphone metronome app and it's perfect also the BPM showed.
not to bump a zombie, but 10- 20 ms off isn't enough to even hear, so why worry about it?
mine works fine, never had any issue with it a reset didn't fix.
i mean... you can't tell the diff, and honestly, to be that critical isn't gonna get out of sync enough to matter when playing with other human beings. most people's time will wander faster and slower where that amount of time is so negligible it's totally overkill to worry about for most if not all uses.
sorry to be a buzzkill, but we're talking some pretty picayune differences in time that i would bet you couldn't tell if put to a blind test. and since you can dial in the EXACT time you want anyways, seems to me there's no harm/no foul involved.
i mean... tapping 4 times in a row it is gonna average out the taps to the closest tempo YOU input. it's not crazy to think between taps you could me that many milliseconds off. seriously.
if it works, don't sweat it. it's not a long enough "glitch" to matter. if it does at all. jmo, obviously your mileage may vary. most of the guitarists i've worked with, myself included, tend to think delays sound better slightly off time anyways.
there's nothing "human" about digital perfection. peace.
Now to sort out my taptation being completely out of time. :icon_confused:
Quote from: pinkjimiphoton on February 16, 2016, 09:31:29 PM
not to bump a zombie, but 10- 20 ms off isn't enough to even hear, so why worry about it?
Because if you're tapping out the delay as close as possible to a drum crack, or another loop, yo uwant to minimize drift. The less accurate the tap-tempo is, the more it'll drift with each loop of the delay. Yes you *will* hear a difference, at least in cases when you're syncing it with something else.
all good, i'll take the more organic approach, i still use an echoplex ;)
i have always found having everything hit "on beat " to end up just being kinda cacophanous and lacking actual feel, but that's me ;)
Quote from: trisbone0 on April 02, 2014, 09:03:47 AM
hi,
I write you from France, I just bought a nux time force; I ve put a bad power supply so it burned!
I m trying to fix it, but i need to have schematics...
or if someone can tell me what component is Q1, because it seems to have burned.
I ve just tried a few momnt with the battery and found the se problem on the tap tempo.
too bad!
thank you
Tristan
I know this thread is old, but after one of my dear friend plugged my time force to an AC/AC adaptor I had the same issue...
The solution was to replace a 220uf cap (It blowed up) on the upper side of the pcb with the jack connections, and to replace the Q1 transistor wich is a P channel MOSFET I belive. I'm currently waiting for my replacement part which is an AO3401 MOSFET in a sot-23 case (I have another time force, which my friend bought me in return of the ruined one, and the Q1 part had TRF7* written on it, which is a NTR4171p I think, and the AO3401 is the only equvivalent I could get my hands on). But I think I'm correct with the MOSFET because one the gate pin there is 0,9V voltage, and when I connected the drain and source with a diode, the pedal turned on and worked flawlessly. The way It works is, when you plug in your jack cable, de cable shorts the connection to the gate, which provides 0,9V voltage for it, so the mosfet can turn on, and power the pedal.
Of course you should clean your pcb with the proper solvent, to remove any stains from the damaged cap, to prevent further shorts.
Sorry for my bad english, but I thought I should post it, If anyone had the same issue.
Cheers!
I soldered in the mosfet, and the pedal works just fine again!
Hi friends.
I do have a NUX TIME FORCE like that about this post.
My pcb is VER:7.0 2013-04-09
I Really very need the U7 data content (firmware). U7 is ST39VF400A and it is the memory that holds the firmware.
My unit works good but sometimes suddenly crashes (when in Tube Echo mode). When it happens I must to power off and on again to unlock and reset all.
I worked hard for a month in the circuit and all the hardware is perfect, so I found that the only cause is a bad firmware code or a corrupted data.
I would ask please a friend that own an unit like that to read the firmware data and send me a file copy please, if possible. Or if there anybody that could tell me where to find it on internet.
Please sorry for my bad english.
Very thanks
Paul
Hi, can you tell me the part number of Q1 in this picture? A client connected an AC power supply and burned this transistor.
(https://i.postimg.cc/ftwMhkS0/IMG-20131018-164924-zps84ec3f60.jpg) (https://postimg.cc/ftwMhkS0)