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

g_u_e_s_t

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.

g_u_e_s_t

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.

pk1802

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

g_u_e_s_t

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

g_u_e_s_t

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.

g_u_e_s_t

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.

pk1802

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.



Is this the JTAG?


Besides these two headers, there are no others.

g_u_e_s_t

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.

drolo

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

g_u_e_s_t

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.

drolo

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 :-)

Ice-9

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.
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

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?

slacker

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.

pk1802

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.

g_u_e_s_t

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.

drolo

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

g_u_e_s_t

any word from the company?  any interest in checking the fuse bits?

pk1802

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.

ElectricDruid

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