MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Dervish: 12HP FV-1 euro FX
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page Previous  1, 2, 3 ... 28, 29, 30 [all]
Author Dervish: 12HP FV-1 euro FX
gbiz
aragorn23 have a look at the "Audio testing & debugging" section in the uD build guide (p.25 for the current doc).
gbiz
I've put a zipfile with external feedback src & binaries here.

There's also a bank that has a selection of the programs.

For the programs that aren't in that bank file, if you're going to use the binary & need to know the pot functions, look at towards the top of the source file, there's a "; potX foo bar" comment.
gbiz
da6353 wrote:

Any shared mono source/binaries would be greatly appreciated, with many thanks in advance.

Done. See my previous post.

da6353 wrote:

Forgot to mention, I substituted in OPA2132PA opamps, in my build.


I built one of mine up with a "nicer" op-amp in the audio path. I didn't notice any difference in the audio quality, just an extra ~10mA current draw, so i've stuck with 074's since.
The ADC's for the CVs in the fv-1 are only 9-bit, so an 074 is good enough for those.

da6353 wrote:

Looking at implementing the following hardware mods:

• Feedback per drolo:
http://www.davidrolo.com/Build%20Docs/MDD%20build%20doc%201.2.pdf


I looked at several ways to implement some form of h/w feedback when i was prototyping dervish. Everything i tried, with excessive feedback, i got the fv-1 to emit a loud chirp/squawk & then lock up, requiring a power cycle to reset it. I decided it wasn't for dervish. I know others implement h/w feedback, so YMMV.

da6353 wrote:

• Eeprom expansion (low tech), as implemented on my build of the arachnid, see my post in diysb.


I don't have an issue with doing that with a "regular" fv-1 design that would otherwise have a single bank 4kbit eeprom. But I personally struggle to find enough programs to fill a 512kbit eeprom, so i don't really see the point of that with dervish.

Be aware that the 3.3 attiny code caches the bank names (it speeds up scrolling through the bank select screen), so these will be invalid once you switch to the other eeprom. You can force a cache flush by pressing either of the up/down buttons when in the debug screen.
The older 3.2 code read each bank name from eeprom as it was displayed so you could go back to using that, but with the slower bank screen scrolling & you won't get the other updates/fixes included in 3.3.

A cleaner method if you need extra programs would be to add native support for 1Mbit eeproms. But that's not a trivial piece of work.

da6353 wrote:

• 1.3" oled display


Others have done that. It's really dependent on the display you use. You'll probably have more success with the current 3.3 attiny code as that assumes you're using a more generic ssd1306 oled controller.
aragorn23
gbiz wrote:
aragorn23 have a look at the "Audio testing & debugging" section in the uD build guide (p.25 for the current doc).


Thanks gbiz. All the voltages seem fine so far. Could a damaged crystal be causing issues like this?

Also, Just to double-check, I got my kit from a third party and I'm not 100% sure the EEPROM was programmed. It has a little 'C' drawn on the chip, which means it has been, right? Would there be a sure-fire way to know whether or not the EEPROM is programmed?
gbiz
Rotate the board to the left, that C becomes a U, which indicates it's programmed with the uDervish image. (A dervish eeprom would have D). If the eeprom wasn't programmed the clip led would be permanently on.

You can easily isolate the eeprom. Short the two pins of j1 (int/ext) on the dsp board. The FV-1 will now load it's programs from it's internal eeprom. You can still select the program number from the up/down buttons & the program number on the led is still valid.
If you select program 5, that's a passthrough test mode. The code will read from the adc & write to the dac. There's a very slight delay, so you want to switch between 100% wet & dry when using this. (It does add some modulation, controlled by one of the cv's, so have all pots at ccw & remove any cables from the cv jacks).

I doubt it's the crystal. If that was faulty, the clip led would be permanently on. It sounds to me like the fv-1 is responding to signal level.

Assuming all the voltages are ok (including all the ones at the 074 & fv-1 as detailed in the build doc), i'd check for audio signals on the input & output pins of the fv-1 (1 & 2, 27 & 28).

As the build doc says, it's best to use 2 unique input signals with a true stereo program when you're debugging a fault like this. The normalisation & input summing on the mono in programs can mask the origin of the fault. (That internal passthrough program 5 is true stereo, so that can be used here).
aragorn23
Okay, so I've shorted the pins and done the pass-through test (program 5) I'm experiencing the same issue. If I check audio signal directly on the FV-1 pins I'm also hearing the same thing: dry signal is fine, wet signal (27 and 28) is a very noisy hiss with a bit of the input signal and a vague semblance of whichever effect I've chosen.

Does this mean my FV-1 is faulty?
aragorn23
[EDIT: ignore the below - voltages are correct on U7 and U8]

Hang on... I've just noticed there are some dubious voltages on U7 and U8. Instead of +12 and -12 on pins 4 and 11 respectively, I'm getting around +8 and -14. I'm assuming there's something seriously wrong here...
gbiz
Obviously you can't rule out it being the fv-1. But i can't think of another one that's been faulty in all the dervish/udervish builds, it'd be the first. It sounds like it's basically working if the wet signal has some semblance of the effect you're expecting.
Aside from being masked by white noise, with internal program 5 & a simple tone from an oscillator does the output signal sound like it's the same frequency as the input signal ?.

When others have had issues like this it's been down to bad soldering on one of the pins on the fv-1 or the components around the reference supply pins. Check the voltages down the fv-1. As detailed in the table in the the build guide. you should have

3.3V on pins 6, 8, 23, 26
0V on pins 4, 7, 11, 12, 19, 24, 25
1.65V on pins 3, 1, 2, 27, 28

Pin 3 is “MID” & should be half of the supply voltage (ie half of 3.3V) 1.65V.

If you have a scope, check that the voltage on those pins is stable with minimal noise on it.

Check the soldering on R17/C21/C22. Check the value of R17 is about 100R.
Check R17 & C13 are parallel to the fv-1 & not perpendicular to it. (Someone did that).

Definitely try swapping the crystal, though it's basically working if you can hear the effect. If you pick a simple delay (eeprom bank 4 prog 0), you should get about 1sec delay repeats with pot0 fully clockwise. If the crystal isn't at 32kHz, the repeat time will be longer/shorter depending on whether the crystal is running faster/slower.
aragorn23
Fixed! Embarrassingly, the mistake was as simple as a 100K soldered to R17 instead of 100R! very frustrating

It's sounding lush now! Thanks so much for the generous troubleshooting assistance gbiz.
gbiz
Phew hihi

I recall someone had a build with a similar noisy output issue that was caused by a bad solder joint on R17. But in that case the voltage on pin 26 wasn't 3V, so it was easy to find.

No problem if you can't, but out of curiosity, can you remember what voltage you had on pin 26 (REFP) of the FV-1 with that 100k in there ?.
aragorn23
gbiz wrote:
No problem if you can't, but out of curiosity, can you remember what voltage you had on pin 26 (REFP) of the FV-1 with that 100k in there ?.


I think pin 26 was fine if I remember correctly, although pin 19 was showing around 1V and either 27 or 28 was at around 3.3V instead of 1.65V.
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page Previous  1, 2, 3 ... 28, 29, 30 [all]
Page 30 of 30
Powered by phpBB © phpBB Group