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

[Build] Dervish - SMT Spin FV-1 DSP fx module
MUFF WIGGLER Forum Index -> Music Tech DIY  
Author [Build] Dervish - SMT Spin FV-1 DSP fx module
gbiz
Dervish: fx module based on the Spin Semiconductors FV-1 DSP.

(If you're looking for the 8HP µDervish thread, click here)

OLED control/display & DSP boards:


Gloss black PCB panel with acrylic window in cutout:



Docs:
See this doc for links to all the docs, BOMs.

Schematics will be emailed to you when you purchase boards.
FPD & pdf dims files are available for people who want to create their own metal panels


Audio:
The hardware offers stereo in, stereo out. Level and mix control on both channels. The right hand input is normalised to the left hand input for mono in/stereo out (this configuration still provides independent level/mix adjustment for each channel).
Full stereo depends on the program running. A few are stereo in, stereo out. Many are mono in, stereo out. Some are mono in, mono out.
Suggested 32KHz crystal provides max 1sec delay times at ~15KHz bandwidth.

See the next post for example sound clips.

CV control:
The FV-1 provides three control voltage inputs. Dervish provides summed pot & external CV for each of these. External CV range is +/-5V with the corresponding pot centred.

Programs:
11 banks of 8 programs. The FV-1 can address a single bank of 8 effects/programs stored in an external i2c EEPROM. Dervish expands support to 11 banks of 8 effects (binary + text) by using a larger EEPROM & storing the extra banks above the 4KB addressed by the FV-1. An ATTiny MCU provides the ability to switch banks by copying the new bank into the FV-1's addressable space. A 4-pin connector exposing the i2c bus is provided so you can customise the content of the EEPROM.
I provide an EEPROM image that you can use immediately containing compiled versions of the algorithms available from Spin Semiconductor under their open reverb license.

Current bank number, program number, display brightness & timeout settings are persistent across power cycles


Display:
0.96" 7-pin SPI OLED display. The main runtime display shows the current effect's bank name, effect name, labels for the three CV's function (see image above). A menu provides options to select new effect bank, set optional display screensaver timeout & change display brightness.


Physical:
Width: Display board is 12HP, DSP is 8HP.
Depth behind panel: 35mm. (Could be reduced by 5mm with lower profile headers)
Current draw (measured with a long reverb program running): -12V: 26mA. +12V: 100mA with display at full brightness, most characters displaying, 92mA with display blank. Varies by a few mA depending on the program running, reverbs seem to be worst.


Component sourcing:
I can supply: PCBs; PCB panel + window ; OLED + mounting hardware ; FV-1 DSP ; Tall Trimpots ; pre-programmed ATTiny & EEPROM.
See "Ordering" section at bottom of this post for details on pricing, shipping etc.

Thonk or your favourite local equivalent: Alpha pots, Thonkiconns, Davies knobs

Mouser carts for the rest of the components.


Build:
Build guides & BOMs are available for all the boards.

All the ICs are SOIC, so easy enough to solder. The passive components are 0603 SMT. Anyone who's successfully built one of the Mutable boards shouldn't have any difficulty with this.


Programming:
I have pre-programmed ATTiny & EEPROM available if you want to avoid flashing these devices. With these once the module is built & working, thats it, it's a working module. You don't need to do any programming unless you want to do some customisation of the program banks etc.

Alternatively, for those willing to do the programming themselves, i provide binaries for both the ATTiny & the EEPROM image, along with full source code.
I supply a "programmer shield" PCB as part of the PCB set that converts a standard Teensy3 into a programmer suitable for programming both the ATTiny & the EEPROM. I also provide the binaries of the sketches for this. If you don't plan to do much programming with Dervish, you can re-use the Teensy3 once you're done for something else like o_C, Orgone Accumulator, Radio Music.

The control/display board has a standard 6 pin ICSP header to upload code to the ATTiny. You'll need a suitable programmer (I use an Olimex AVR-ISP MK2). If you don't have one, the i2c EEPROM programmer shield provided as part of the PCB set can be used. Just load the Teensy with the supplied ArduinoISP sketch first.

The DSP board has an i2c header that you use to program the EEPROM. This i2c bus is also connected to the FV-1 & the ATTiny. The FV-1 isn't tolerant of voltages above 3.3V on it's i2c pins, so any i2c programmer you use must provide 3.3V signals else you'll kill the DSP. Code to interface into this EEPROM programmer from your desktop is provided for Linux & MacOS. Windows users are recommended to use a Linux image running in Vagrant and use the Linux code.


Customisation:
I've written a progamming environment that when used in conjunction with the Teensy "eeprom programmer" shield & companion sketch, allows you to upload/download EEPROM images, program banks or individual program binaries into Dervish. This environment is written using standard Unix tools, so whilst it runs on MacOSX and Linux, it cannot be easily ported to run natively on MS Windows. Windows users are recommended to use Linux hosted in Vagrant (this is easier than it sounds, i have a basic doc on how to set this up).

I also provide a simple assembler that means you can use this environment as an FV-1 development system.

The programming environment has a full users guide, and for those unfamiliar with the command line interface, an installer script.


Expansion:
2 expander boards are available:

I2C & 3x attenuverters (4HP): Useful if you do a lot of FV-1 programming. Keep the Dervish in the rack. Plug the EEPROM programmer into this module. The i2c from this module plugs into Dervish.

UpDownTap (2HP): Provides external control of program up/down, and a basic pushbutton for use with tap tempo programs.


Ordering:
See this page for prices, options etc.

Built modules are occasionally available from me, free time permitting. Please PM or email me for details. There are other builders who can also provide built modules for customers.
gbiz
Links to example sound clips, videos ...

Links on my soundcloud ...
* Nein-oh-nein kick through reverse reverb and
* through various reverbs
* Elements with various reverbs, no Elements builtin reverb used.
* Radio Music into MS50-ish filter into Dervish with 2:1 clock sync pingpong (2:1 means pong is half the delay time of ping)
* pitch shifter w/feedback
* Shimmer based on Dattorro reverb
* various drv103 programs (drv103 is my attempt on a tape delay)
* clocksync 2:1 drv103 used in a demo of my System100 filter

Other examples by builders posted in this & the µDervish threads...

* Awesome youtube video tutorial (in Russian). By temaniak
* 'huge reverb wash'. By TimoRozendal
* Reverb. By toneburst
* jam using 3 x µDervish. By ImportJingles


(I know i could use the embedded soundcloud & yt options, it takes too long to load IMO).
Altitude909
Yay! Build thread!

Let me kick it off:

for the USians:

http://smallbear-electronics.mybigcommerce.com/ic-spin-semi-fv-1/
Dogma
theres a guy around who said he had cooked up a bunch of fv1-spin programs - he might be good to get in contact with as he said hes put a lot of work in but is a bit afraid to show his work....
a set for me please
oberkorn
looking good! I'll take a set when available.
(if anyone in Europe is ordering from OSHpark i'll join in)
SoundPool
interested for the future, but will hold off for now due to huge backlog. but given how many folks seem interested right off the bat I would suggest looking into getting your PCBs done somewhere other than OSHPark. its great for small runs and proto, but if you are going to bother doing larger batch production rather than just sharing project files you could probably get much better pricing per-unit from somewhere else.
gbiz
SoundPool wrote:
interested for the future, but will hold off for now due to huge backlog. but given how many folks seem interested right off the bat I would suggest looking into getting your PCBs done somewhere other than OSHPark. its great for small runs and proto, but if you are going to bother doing larger batch production rather than just sharing project files you could probably get much better pricing per-unit from somewhere else.


My reason for sticking with OSHPark, i'd know the boards would be same as ones i've tested. But others have suggested the same as you, so i'm looking at alternatives.
Altitude909
Just for reference, OSHpark are ENIG (aka immersion gold) plated. Decent for leaded or unleaded solder. Avoid the silver stuff (IAg), tarnishes quickly and hard to solder to.

I like leaded HASL if that's permitted for you (easiest to solder), I'd say avoid unleaded HASL
lamouette/rck
Add me to the list !
anto32
Awesome project!

The calibration for external cv is located into the code?

thanks
gbiz
anto32 wrote:

The calibration for external cv is located into the code?


I'm not sure what you mean by calibration ?.
gbiz
Altitude909 wrote:
Just for reference, OSHpark are ENIG (aka immersion gold) plated. Decent for leaded or unleaded solder. Avoid the silver stuff (IAg), tarnishes quickly and hard to solder to.

I like leaded HASL if that's permitted for you (easiest to solder), I'd say avoid unleaded HASL


I have no objections to lead.

Looks like PCBWay are trialling ENIG. They had an option for it, supplied at their discretion, with HASL if you don't get it.
sammy123
Add me to the list please.
mothertongue
I'll jump on the list too!
horstronic
I'm in for one!
Nice project!
d.simon
I am interest for one set
Eloc
I'd be down for a PCB set, and panel probably too.

gbiz wrote:


I have no objections to lead.

Looks like PCBWay are trialling ENIG. They had an option for it, supplied at their discretion, with HASL if you don't get it.


I've had ENIG done by PCBWay for Panels. In fact I didn't ask for it on one design to save money and they mistakenly did it gold anyway... I didn't complain...
gbiz
Ah yes. Panel. Not something i've ever really done properly for my own designs before. Cost of decent metal panels from FPE/Schaffer coupled with a likely hit for UK import duty always put me off. I've never been a massive fan of acrylic or PCB panels. I can live with a rough looking DIY panel that i've done. But i suppose this one should be done properly.

I already have .dwg & .svg files that i used as drill templates to create the panels i'm using now. And i've put together a PCB layout for a PCB panel, though that needs some graphics for the text. So most of the hard work is done. I'll include both in the upload to github.
BARE BONES
do you have a link to your github please?
grizzle
I'm in for PCB's and a panel if it gets offered!
gbiz
I'll upload to github once i'm happy the current gerbers don't require rework. I'll add a link to it in the OP then. When that happens depends on when i get my latest prototype PCBs back from OSHPark.
woodster
So happy to see this is happening, Good skills gbiz !
applause
anto32
Quote:
I'm not sure what you mean by calibration ?


Ah sorry! I want to use the cv inputs with a 0/10v signal. So maybe i could shift the -5/+5v?
gbiz
anto32 wrote:
Quote:
I'm not sure what you mean by calibration ?


Ah sorry! I want to use the cv inputs with a 0/10v signal. So maybe i could shift the -5/+5v?


Ah, i see what you mean. (I had visions of you wanting to calibrate it to a nicely linear 1V/Oct hihi ).

The +/-5V CV input provides full voltage swing at the FV-1 POT input with the corresponding control pot centered. You can get a similar full swing with a 0-10V CV with the control pot fully counter-clockwise, but then you lose the ability to set a offset with the control pot & drive the POT input in a negative direction with the CV. Theres no way round that in the module unfortunately, at least without some rework. You'd need external voltage processing of your CV.

Attenuverters & level shifters work well with these CV inputs. I did think about adding them. But the panel would have ended up at 16-20HP. There's probably the case for a 8HP companion module for this that provides attenuverters, level adjusters for the CVs, input mixers that make it easier to add feedback etc.
jhulk
im in for pcbs put me on list please
cereyanlimusiki
Add me for PCB and Panel
woodster
Put me down for a set
BARE BONES
1 set please
SkoPe
I'm in for PCB/panel please. Thanks.
jamsk
Up for 1 please.
BARE BONES
1 set of pcbs please smile
anto32
Quote:

The +/-5V CV input provides full voltage swing at the FV-1 POT input with the corresponding control pot centered. You can get a similar full swing with a 0-10V CV with the control pot fully counter-clockwise, but then you lose the ability to set a offset with the control pot & drive the POT input in a negative direction with the CV.



Thanks for explanations, i'll add cv tools to switch the offset!
gbiz
I just put a few sound examples up in the first post.
spneca
I'm in for a set.
edwinm
PCB and panel please!
insula
woah woah

i want 2 pcbs + panel
bezier
Interested, depending on final price though - not sure how funds will allow for another project
Digital Larry
For anyone concerned about "where" to get algorithms, my suggestion for reverb algorithms would be to get them from the Spin "free programs" area.

For a way to build your own algorithms without needing to write DSP code, check out:

http://holycityaudio.com/spincad-designer-2/

This program is free to download and is open source.

There are a few reverb blocks in this program, but it's not optimized towards creating the best reverb. It can, however, create a lot of other stuff.
woodster
I'd like to up my order to 3 please thumbs up
Just had the pleasure of using one for a few hours today, mind=blown.
Monster good skills gbiz !
Wes Grayscale needs to do a panel for this...
Swann
Add me to the list please SlayerBadger!
j_p_higgins
those demos love

and for UK people looking for the spin FV-1

http://www.profusionplc.com/parts/SPN1001-FV1

If enough people are interested we could sort a group buy?
mckenic
Dammit!

I was gonna wait until the 1st builds were out there and I could see how difficult these were... and although Ive not used it yet, I have a Bus Pirate -

If I could do the programming with this, Id be in for a PCB. Otherwise I'd have to rely on someone flashing the Attiny for me.

Thoughts of a group buy pushing me over the edge hihi
thumbs up
gbiz
j_p_higgins wrote:
those demos love

and for UK people looking for the spin FV-1

http://www.profusionplc.com/parts/SPN1001-FV1

If enough people are interested we could sort a group buy?


Profusion is where i've got mine from. No problems buying from them. IIRC their delivery was next day or so. No annoying wait for a week or so.

I was going to suggest a UK group buy. I'd happily organise it but i'm a bit busy sorting out PCBs & panels for this thing hihi If someone else wants to do it i'll take 2 or 3. I'd have thought we could hit the 10+ price break.

I just checked a previous invoice & their p+p was £3.50 +vat, so a GB would save quite a bit for people just wanting one assuming whoever organises this ships them on using 1st class letter post.
Dogma
Digital Larry wrote:
For anyone concerned about "where" to get algorithms, my suggestion for reverb algorithms would be to get them from the Spin "free programs" area.

For a way to build your own algorithms without needing to write DSP code, check out:

http://holycityaudio.com/spincad-designer-2/

This program is free to download and is open source.

There are a few reverb blocks in this program, but it's not optimized towards creating the best reverb. It can, however, create a lot of other stuff.


Digital Larry werent you cooking up some Spin programs you mentioned in a z-dsp discussion?
gbiz
mckenic wrote:
Dammit!

I was gonna wait until the 1st builds were out there and I could see how difficult these were... and although Ive not used it yet, I have a Bus Pirate -

If I could do the programming with this, Id be in for a PCB. Otherwise I'd have to rely on someone flashing the Attiny for me.

Thoughts of a group buy pushing me over the edge hihi
thumbs up


It looks like the Bus Pirate would program both the ATTiny (using the 2x3 ISP header) and according to it's 24LC1024 example*, also supports the I2C interface at 3.3V. For the latter, you'd just need to upload each bank's binary & description text to the correct locations in the EEPROM, which i'm sure is doable.

Hmm. Maybe i should add an ISP interface to the Teensy I2C programmer i use, then it could be used to initially flash the ATTiny, & then manage the EEPROM. That would be easy to do.

Unfortunately there's no easy way i can provide a pre-programmed ATTiny for this SMT version. (I have thought about doing a through hole or partly through hole Dervish, & that could have a pre-programmed DIP version. But that would be a long way off & only once the SMT one is all done).

*http://hackaday.com/2008/11/19/how-to-the-bus-pirate-universal-serial -interface/#EEPROM
gbiz
Digital Larry wrote:
For anyone concerned about "where" to get algorithms, my suggestion for reverb algorithms would be to get them from the Spin "free programs" area.

For a way to build your own algorithms without needing to write DSP code, check out:

http://holycityaudio.com/spincad-designer-2/

This program is free to download and is open source.

There are a few reverb blocks in this program, but it's not optimized towards creating the best reverb. It can, however, create a lot of other stuff.


As you say, there's plenty of good reverbs out there.

A lot of the other FV-1 programs out there seem to be written for guitar pedals, which is totally understandable as i guess that's been the target market. All the chorus & flange fx have built in LFO with rate/depth controlled on the POT cv's. One of the many items on my todo list is to go through one or two of them & look at replacing the internal LFO with external CV. I'd love to have a chorus or flange controlled by a complex LFO from something like Tides or E350.

What i really miss is a decent multi-tap delay similar to the one TipTop ship with the Z-DSP.
Altitude909
gbiz wrote:
..
Unfortunately there's no easy way i can provide a pre-programmed ATTiny for this SMT version. ..


Viola:

http://www.ebay.com/itm/250670041374?_trksid=p2060353.m1438.l2649&ssPa geName=STRK%3AMEBIDX%3AIT

Digital Larry
gbiz wrote:
Digital Larry wrote:

For a way to build your own algorithms without needing to write DSP code, check out:

http://holycityaudio.com/spincad-designer-2/

This program is free to download and is open source.


As you say, there's plenty of good reverbs out there.

A lot of the other FV-1 programs out there seem to be written for guitar pedals, which is totally understandable as i guess that's been the target market. All the chorus & flange fx have built in LFO with rate/depth controlled on the POT cv's. One of the many items on my todo list is to go through one or two of them & look at replacing the internal LFO with external CV. I'd love to have a chorus or flange controlled by a complex LFO from something like Tides or E350.

What i really miss is a decent multi-tap delay similar to the one TipTop ship with the Z-DSP.

The FV-1's instruction set includes super efficient ways to make LFO-based chorus. SpinCAD also features a "servo delay" block which is about 1/8th of a second long and can take an arbitrary control input. These blocks are based on the RAMP LFO, but they do not move anywhere unless you move them and I have used these with random LFO and what I guess is called "slewing" - a low pass filter set to a very low frequency - to great effect. It's very easy to make a through-zero flanger.

In addition, there are several multi-tap delay blocks.
One emulates the tap spacing on an old MN3011 BBD reverb chip, although you'd have to add distortion, aliasing, and reduced frequency response explicitly - for that ever-important "emulating the undesirable aspects of vintage crap" vibe. Otherwise it's just a clean multi-tap with fixed delay spacing, time control input (moves all taps together) and individual settings for tap level (which are not pot controllable).

There is a 6-tap delay for which you can set the times of each tap. My goal was to make this stereo pannable per tap but I didn't get there yet.

My favorite is the 3-tap delay with individual control times per tap.

Also there is an 8-tap delay with equal spacing.

I can build new multi-tap blocks pretty easily. I had a ten-tap block for awhile but I never used it and I don't think anyone else did either. So I removed it.

DL
Digital Larry
Dogma wrote:

Digital Larry werent you cooking up some Spin programs you mentioned in a z-dsp discussion?


Yes, I have tons of programs laying around. The main reason for that is that SpinCAD makes it really easy to build FV-1 algorithms, although you do have to understand some aspects of the FV-1 to get the most out of it.

However, recently I have started to do FX design work for hire. I've got 4 customers at this point in time. So I'm a little less geared towards flinging stuff up here for laughs. However the SpinCAD program I wrote and use for a lot of things is freely available for you to use. I try to help people as much as I can if they ask a question on my forum.

DL
didahdrieghe
One PCB and panel please!
j_p_higgins
gbiz wrote:


I was going to suggest a UK group buy. I'd happily organise it but i'm a bit busy sorting out PCBs & panels for this thing hihi If someone else wants to do it i'll take 2 or 3. I'd have thought we could hit the 10+ price break.

I just checked a previous invoice & their p+p was £3.50 +vat, so a GB would save quite a bit for people just wanting one assuming whoever organises this ships them on using 1st class letter post.


I'd be more than happy to organise a UK group buy but as I don't have many posts on here I won't be offended if people would rather someone else did it.

Saying that, shoving my username into google will probably come up with every social media account I have so its not like I can easily disappear.
hi0b
i am in for 1 set please
spotta
set for me cheers.
koerby
+1 for me please
gbiz
j_p_higgins wrote:
gbiz wrote:


I was going to suggest a UK group buy. I'd happily organise it but i'm a bit busy sorting out PCBs & panels for this thing hihi If someone else wants to do it i'll take 2 or 3. I'd have thought we could hit the 10+ price break.

I just checked a previous invoice & their p+p was £3.50 +vat, so a GB would save quite a bit for people just wanting one assuming whoever organises this ships them on using 1st class letter post.


I'd be more than happy to organise a UK group buy but as I don't have many posts on here I won't be offended if people would rather someone else did it.

Saying that, shoving my username into google will probably come up with every social media account I have so its not like I can easily disappear.


Thinking about it, it probably makes sense if i do it. I can ship the ICs out with the PCBs. It'll save people a bit on the p+p. And I'll have to do the trip to the post office anyway.
allears62
+1 to be added for a pcb and I'm also interested in UK group buy

I can vouch for j_p_higgins as well we're good mates and he hasn't screwed me over.... not yet anyways Drinking
sixty_n
I said I'd like a set in the other thread but would like this to go in the UK group buy
gbiz
I thought i'd take a look at getting the host side of my I2C eeprom programmer code compiled for Windows. As i said in the first post, it works fine for Linux & OSX, & wasn't sure about Windows. Not having ever worked on Windows, i'd assumed it would compile fine, after all it's all Posix calls. Oh how wrong i was. It relies on termios which Windows doesn't have & theres no easy way to get. very frustrating

Having spent an hour or so investigating this, it looks like the options for anyone who wants to use my eeprom programmer on windows are:
(a) use an alternative method to upload banks to the eeprom. There's plenty of I2C eeprom programmers out there that can do this. You'd need matching hardware. Pick one & try it. Just ensure whatever hardware you use runs the I2C bus at 3.3V.
(b) the host side of my I2C eeprom programmer is ported to use the Windows serial API. I don't have a Windows box here to do this, or test it on. I'm not sure how much work it'd be, having never worked with the Windows serial API. TBH this is at the bottom of the priority pile for me, i want/need to get other stuff done like the docs wink (If anyone can help do this, please PM me).
(c) install Cygwin on your Windows system, which does provide termios. It should compile fine under Cygwin.
(d) use a Linux VM hosted on your windows box. A vagrant image such as the Mutable one would work. You just need to set up a vagrant rule to pass through the Teensy USB device to the VM, & then a udev rule to create the tty node in the image.

Not exactly show stoppers, but none are pretty.

Sigh.
Altitude909
well, if it was easy, it wouldnt be too much fun now would it.

Just so I have this straight:

ATtiny : Control code <- ISP programmer
EEPROM : Sketch data\banks <- I2C programmer
FV1 : DSP binary <- ?

I am windows but am somewhat ok on cygwin or a linux VM so we should be able to sort this out. Maybe an arduino sketch for a teensy? That works fine on windows
gbiz
Altitude909 wrote:
well, if it was easy, it wouldnt be too much fun now would it.


Indeed smile

Altitude909 wrote:

Just so I have this straight:

ATtiny : Control code <- ISP programmer
EEPROM : Sketch data\banks <- I2C programmer
FV1 : DSP binary <- ?


Thats pretty much it.

The binaries for the FV-1's 8 DSP programs are in the first 4KB of the EEPROM. It wasn't designed to address more than 4K, so i use the next 60KB of the EEPROM to store the additional binaries & descriptive text. When you select a different program bank on the display, the ATTiny just copies that bank's 5KB (4K binary + 1K text) from wherever it resides in the EEPROM into the first 5KB. Banks are stored sequentially in the EEPROM, 4KB binary + 1KB text.

Altitude909 wrote:

I am windows but am somewhat ok on cygwin or a linux VM so we should be able to sort this out. Maybe an arduino sketch for a teensy? That works fine on windows


Theres already an arduino sketch running on the teensy, thats the target half of the I2C upload tool. Thats not the problem. It's the host/desktop portion of the code that's the issue, it uses the standard Unix terminal I/O library which isn't available on Windows. As i say the whole I2C upload method could be replaced with some other combination of I2C programmer hardware & host code that runs natively on Windows. Ideally it needs to support loading a file into a specified offset in the EEPROM, as my code does. That way you can upload just one bank of 8 programs binary & text, (5KB in size) into a specific location in the EEPROM & not have to upload the whole 64KB EEPROM each time (and then have to find some way to manage creating those 64KB images).

The build doc has diags & pictures of how all this fits together, how the EEPROM is laid out etc.

Here's the block diagram from it.

Altitude909
Something like this?

http://www.ebay.com/itm/281920556383
gbiz
The hardware looks OK. Supports 3.3V @ 400KHz. You don't need the Vcc wire, the EEPROM is powered by the module.

I don't see any program in the zipfile that would do a file upload for you though. Looks like they provide code snippets there that you could use to write something.
Altitude909
I2CTool_Cn.exe?

It's in chinese
Rowan
I'd like a PCB set and panel if it becomes available. I'd also be up for being in A UK group by for the FV-1.
gbiz
Altitude909 wrote:
I2CTool_Cn.exe?

It's in chinese


I didn't see any source for that, so i'm not sure.

There's mention of "i2crw" in one of the batch files. That looks like it writes one byte at a time. That would take forever. The 24lc512 works with 128 byte pages. You have to wait for 5ms after each page write for the device to flush the page, else you get data corruption. Ideally you want to fill a full page with data before flushing it to get the maximum throughput. Writing one byte to the page then flushing it still needs a 5ms delay & is horribly wasteful.
Altitude909
This looks a bit more capable:

http://www.embeddedcomputers.net/products/FlashcatUSB/

does 24lc = 24c for compatibility?
gbiz
That looks better. You can read/write a file on the disk. You can specify offset in the EEPROM & number of bytes. The only thing it doesn't do that my Teensy based tool does is fill the EEPROM with a specific byte value, though it does have an erase option which would probably suffice if erase means writing zeros. Assuming you can pass CLI arguments to windows batch files like you can with the Unix shell (i honestly have no idea hihi), you could write a batch file script that uploads binary & text files to a specified bank location. That's getting close to the scripts i have for OSX/Linux.

You won't need the pullups shown on p14. The EEPROM will be powered by the module, not the programmer & the FV-1 has inbuilt pullups. And you don't need Vcc, you only need 3 wires, 0V, SDA & SCL.

I don't see why it wouldn't work. The doc does state it supports all I2C EEPROM devices. But it probably wouldn't hurt to email them & ask if it supports programming a 24LC512 at 3.3V.

According to the docs, with those Microchip EEPROMs, the middle letter denotes the minimum supply voltage. 24C is 4.5-6.5V, LC is 2.4V AA is 1.8V. See http://www.farnell.com/datasheets/1669373.pdf
Altitude909
EC confirmed that's it's compatible with all 24 series EEPROMs so I ordered one. Looks like a handy device
mr.sibs
PCB and panel please if I am not too late!
gbiz
mr.sibs, no, not too late.
n167tx
i am IN for a pcb/panel aswell.
hope its not too late
gbiz
No, you're good n167tx. There will be a UK group buy for the FV-1 if you're interested in that ?.
n167tx
yes, completely.
thanks
gbiz
An update on where i am with this.

I reckon theres another couple of weeks before i have to finalise rough numbers.

My final test PCBs arrived from OSHPark & they work fine. No rework required, so I finally managed to get around to ordering some test PCBs today of what i hope will be the production gerbers from a fab in China. I guess they'll be here in 10 days or so. Once i know those are good i'll chase up who wants how many, panels, shipping to where etc. etc.

Along with DSP & display PCBs, i've also ordered some black PCB panels. I also got some PCBs for use with a teensy3 for the EEPROM programmer. I added a ICSP header to this so that could also be used to flash the ATTiny for people that don't have an AVR programmer. I know i said the EEPROM programmer could be done on stripboard, (it still can), but this thing is 50mm x 30mm so it'll probably be cheaper than the time it takes to make a stripboard one. Obviously the panel & programmer are optional, if you only want the DSP & display PCBs thats fine.

It's too early to say how much the PCB sets will be, no doubt those wonderful people at UK customs will want their share, bless 'em.

The BOMs are all done. I'll make those available when i start taking orders for the PCBs. I've also put together Mouser carts for the parts that can be sourced from there for the DSP & display boards.

I got a panel laid out in FPD. With basic text it works out to about €33 from Schaeffer, add shipping to the UK, & a one off was over €40. I baulked at ordering one. Black PCB panels for me. But the FPD file will be there for anyone who wants it.
mckenic
thumbs up

Thanks gbiz mate!
dirkwiggler
I'm in for a PCB and Panel set too please gbiz ! hyper
sicpaul
I'd like to be in for a pcb set as well. depending on the prize maybe two hihi
loopt
I'm in for a PCB set and one EEPROM programmer pcb. thumbs up
cereyanlimusiki
Any news ?
gbiz
Sorry for the lack of update, i've got loads of things going on & i'm trying to get some bits & pieces finshed off on it as & when i can. Whilst the build is relatively straightforward, i want to try & make it as easy as possible for people to get some algorithms into it. And document the ways to do this.

I got a batch of the "production" PCBs in, built a couple up & they work as expected. The EEPROM programmer PCB works both to program I2C EEPROMs & as an ICSP (i've discovered you can use a eurorack power cable for the ICSP cable, so that's one less cable to source hihi). The only issue was the PCB fab decided to print a batch # on the front of the PCB panel. Annoying as they don't document they'd add this, some fabs do, so i hadn't allowed for it. Obviously any future batch won't have it, but it means I'll have a few very cheap PCB panels for people who are willing to put up with the batch number on the front :(

One bit of good news, the Spin Semiconductor open reverb license allows for providing binaries of the free programs they publish on their site, so i've put together an EEPROM image people can use immediately use with something like 8 banks of algorithms in it. That'll hopefully make post-build testing much easier.

Display & DSP PCB pair will be £10. PCB panel (without batch # printed on the silk) £5. Now I just need to work out shipping costs Dead Banana

To give you some idea of complete kit cost in GBP, besides the PCBs etc, the Mouser cart for the other components comes to about £15, but that's buying 0603 passives at silly one-off prices.
£6 for the OLED (cheapest i've found one for).
About £9 for the FV-1.
About £15 for the Thonk sourced bits.
About £1 worth of inter-board headers from Tayda (more if you buy from Mouser/Farnell etc).

If you want a EEPROM programmer PCB, they'll be £1. You only need one. The only parts you need for that are 1x4 & 2x3 male headers & two 1x14 female headers, plus a Teensy3. And an interface cable.


Display PCB with annoying batch # printed on silk:


Teensy + EEPROM programmer PCB being used to program Dervish (built using production PCBs), over I2C.
loopt
Good news. SlayerBadger!
sammy123
Awesome! I'd take one of the PCB panels with the batch numbers. Along with all the PCBs and eeprom PCB. SlayerBadger!
j_p_higgins
Looks great, can't wait to get my hands on one. Me and allears62 would be down for a panel each with the batch numbers on if you're looking to shift them.
allears62
In addition to what j_p_higgins said about panels we'd be down for an eeprom pcb between us in addition to the normal main pcbs just chuck it on one of our orders we'll sort it out between us.
gbiz
I've probably got about 15 of those panels to get rid of, i'll do them at £2 each. First come first served. (4 gone already wink

I tried removing the paint will all sorts of cleaners & paint strippers & it won't budge. Understandable given it's designed to withstand PCB cleaners. It scrapes off but that looks messy. The PCB fab suggested painting over it with black paint, which would probably work. Permanent marker seems to work best.
cereyanlimusiki
Hello gbiz

I am also up for one of these limited edition smile PCB Panel together with Display & DSP PCB set and EEPROM Programmer pcb with shipping to Switzerland.

you can send me a PM for payment details
masterofstuff124
I'm in for the whole set including one of the messed up pcb panels.

Is the teensy board necessary can it not be done with arduino? or is the breakout board thing just endlessly easier?

Buying the spin fv1 chip in bulk might be wise.

Looking forward to this build.

It just jumped to the top of my build list because of panel. I can get rocking immediately I love builds like that.
cereyanlimusiki
Sounds like smart idea



masterofstuff124 wrote:


Buying the spin fv1 chip in bulk might be wise.

lamouette/rck
Me too, i am in for a whole set, with shipping to Canada !
gbiz
cereyanlimusiki wrote:
Hello gbiz

I am also up for one of these limited edition smile PCB Panel ...


Damn, i should have charged extra for these ltd edition ones smile

masterofstuff124 wrote:

Is the teensy board necessary can it not be done with arduino? or is the breakout board thing just endlessly easier?


It's endlessly easier. You could do it with an arduino & roll your own shield on stripboard, but an arduino will run it's outputs at at 5v, so you'll need to level convert to 3.3v or you'll kill the FV-1 (there are arduino shields out there that will do this (Sparkfun have one iirc)). My sketch for the teensy on the eeprom programmer uses the fast i2c library, so you'd need to port the code back to the stock arduino i2c routines. It's trivial to do but it'd need doing. Anyway, with a teensy once you're done programming, you can re-purpose it for something useful like one of mxmxmx's cool projects, or an Orgone Accumulator.

There's other I2C programmers out there that will do the job - the one that Altitude909 found for example that will run on windows (i'll emphasise this again, mine is OSX & Linux only). But they'll cost just as much as a teensy & my breakout board, & you can't run a dedicated one as a synth module afterwards smile

masterofstuff124 wrote:

Buying the spin fv1 chip in bulk might be wise.


I did offer to do a UK group buy further back. Profusion charge £3.50 for p+p, so you'd save more on p+p than on the saving going from 1x to 10x pricing if i bundled the FV-1 in with the PCBs.

Edit: US folks might want to look at organising a GB from Smallbear
cereyanlimusiki
gbiz

In this case I am up for

limited edition hihi PCB Panel
Display & DSP PCB set with FV-1 IC
EEPROM Programmer pcb with shipping to Switzerland.

Quote:


I did offer to do a UK group buy further back. Profusion charge £3.50 for p+p, so you'd save more on p+p than on the saving going from 1x to 10x pricing if i bundled the FV-1 in with the PCBs.

Edit: US folks might want to look at organising a GB from Smallbear
gbiz
I just ordered 10 FV-1's from Profusion. P+P from them for 10 is the same as for 1, so those work out at £9 each.
didahdrieghe
I'm still in for 1 of everything gbiz, and a messed up panel is fine for me as well!
cereyanlimusiki
gbiz

which teensy that I need to order; PJRC website has Teensy 3.2. Is this OK?
gbiz
3.2 should be fine, i have one here, let me check before you order. I'm only using a 3.0 as i had one spare.
gbiz
I've uploaded xlsx BOMs for the display & DSP boards & the current user/build guide here.

The BOMs contain a link to the respective Mouser cart at the top. I hope they're right, i've not tried ordering with them. Sorry UK'ers, i've not done a Farnell project yet, but at least you have their SKUs.

There's also a doc & BOM for the programmer here

If anyone has trouble opening xlsx (they're created with libre office), i'll export to csv. I didn't export to pdf, with the comments the formatting gets screwed & the rows are spread across multiple pages.

The BOMs contain tips on what i've used. Hope they're useful. Let me know if there's anything i should add/amend/delete.

The one tricky component is the OLED. Both the display board BOM & the guide contain details on what to buy. I've bought a few of these from various ebay now. You order what is described as a 27.8mm x 27.3mm, 7-pin, SPI, 0.96" OLED with SH1106 controller, you get a 4-pin, or a 27.8 x 31. When things are not as described they'll refund, but it's an annoying 2 week wait from another vendor. Most of these displays can be I2C & SPI & just need some resistors swapping on the back, but there's not much you can do about the wrong number of pins or physical display size. My last order was from "kiss_buy", one of the cheaper vendors. First batch she sent were fine. Second batch were the wrong size. After some ebay pm's & some pics she eventually sent the right displays. She assures me that anyone who buys from her shop now will get the right thing. Up to you guys !!!.


The guides are a work in progress, so treat them as such.
cereyanlimusiki
Waiting for your command Houston help
gbiz wrote:
3.2 should be fine, i have one here, let me check before you order. I'm only using a 3.0 as i had one spare.
mothertongue
I'll take one of the limited edition panels, and all other PCBs please!
gbiz
cereyanlimusiki wrote:
Waiting for your command Houston help
gbiz wrote:
3.2 should be fine, i have one here, let me check before you order. I'm only using a 3.0 as i had one spare.


Yeah go for it. I used an OSHPark teensy3.2 & no problems.
cereyanlimusiki
Is this the right one

http://www.ebay.com/itm/1-3-SPI-Serial-128X64-OLED-LCD-Display-Module- for-3-3v-5v-Arduino-UNO-R3-51-/281960701174

gbiz wrote:

The one tricky component is the OLED. Both the display board BOM & the guide contain details on what to buy. I've bought a few of these from various ebay now. You order what is described as a 27.8mm x 27.3mm, 7-pin, SPI, 0.96" OLED with SH1106 controller, you get a 4-pin, or a 27.8 x 31. When things are not as described they'll refund, but it's an annoying 2 week wait from another vendor. Most of these displays can be I2C & SPI & just need some resistors swapping on the back, but there's not much you can do about the wrong number of pins or physical display size. My last order was from "kiss_buy", one of the cheaper vendors. First batch she sent were fine. Second batch were the wrong size. After some ebay pm's & some pics she eventually sent the right displays. She assures me that anyone who buys from her shop now will get the right thing. Up to you guys !!!.
gbiz
cereyanlimusiki wrote:
Is this the right one

http://www.ebay.com/itm/1-3-SPI-Serial-128X64-OLED-LCD-Display-Module- for-3-3v-5v-Arduino-UNO-R3-51-/281960701174

gbiz wrote:

The one tricky component is the OLED. Both the display board BOM & the guide contain details on what to buy. I've bought a few of these from various ebay now. You order what is described as a 27.8mm x 27.3mm, 7-pin, SPI, 0.96" OLED with SH1106 controller, you get a 4-pin, or a 27.8 x 31. When things are not as described they'll refund, but it's an annoying 2 week wait from another vendor. Most of these displays can be I2C & SPI & just need some resistors swapping on the back, but there's not much you can do about the wrong number of pins or physical display size. My last order was from "kiss_buy", one of the cheaper vendors. First batch she sent were fine. Second batch were the wrong size. After some ebay pm's & some pics she eventually sent the right displays. She assures me that anyone who buys from her shop now will get the right thing. Up to you guys !!!.


Nope. That's a 1.3" display, you want 0.96" (27.8mm x 27.3mm). Something like this

http://www.ebay.com/itm/Blue-3-3v-5v-0-96-SPI-Serial-128X64-OLED-LCD-D isplay-Module-for-Arduino-stm32-/272038236843
cereyanlimusiki
Oled ordered from the link
Teensy ordered from local supplier

w00t

gbiz wrote:
cereyanlimusiki wrote:
Is this the right one

http://www.ebay.com/itm/1-3-SPI-Serial-128X64-OLED-LCD-Display-Module- for-3-3v-5v-Arduino-UNO-R3-51-/281960701174

gbiz wrote:

The one tricky component is the OLED. Both the display board BOM & the guide contain details on what to buy. I've bought a few of these from various ebay now. You order what is described as a 27.8mm x 27.3mm, 7-pin, SPI, 0.96" OLED with SH1106 controller, you get a 4-pin, or a 27.8 x 31. When things are not as described they'll refund, but it's an annoying 2 week wait from another vendor. Most of these displays can be I2C & SPI & just need some resistors swapping on the back, but there's not much you can do about the wrong number of pins or physical display size. My last order was from "kiss_buy", one of the cheaper vendors. First batch she sent were fine. Second batch were the wrong size. After some ebay pm's & some pics she eventually sent the right displays. She assures me that anyone who buys from her shop now will get the right thing. Up to you guys !!!.


Nope. That's a 1.3" display, you want 0.96" (27.8mm x 27.3mm). Something like this

http://www.ebay.com/itm/Blue-3-3v-5v-0-96-SPI-Serial-128X64-OLED-LCD-D isplay-Module-for-Arduino-stm32-/272038236843
gbiz
Anyone who was really quick & grabbed the BOM, i just noticed the two audio taper tall trimmers ones were marked as A100K. I've been using A500K recently so i've just changed the BOM to reflect that. A100K will work equally though so no worries if you've already ordered those. (IIRC i only changed because Thonk were out of A100K's at the time).

I just noticed that Thonk are out of the B50K tall trimmers used for the mix pots. I'll get some B100K's in & check they'll work instead. They might need a change to a couple of resistors.
SkoPe
Already got the display, got this one http://www.ebay.com/itm/182072147746

I trust that seller because i've bought 4x 1.3" for some mxmxmx projects and all work fine.

gbiz That last link shows a oled with SSD1306 driver not SSH1106.
Will order Mouser and Thonk parts as soon you can confirm B100k will work too.

Will also take a "special" panel and EEPROM programmer pcb if you still have any.
Eloc
I'd take a PCB set, programmer and panel (with batch code if one's still left).

You'll have to specify that you WANT the batch code next time as they're proving more popular than the ones without...
gbiz
SkoPe this is the auction i bought from http://www.ebay.co.uk/itm/281850381283, exactly the same description, they both call it a SSD130 whatever that is. One of the displays from that auction is in the pic on the previous page so they certainly work wink

I recall reading somewhere when i first started looking at these displays, that most of the 128x64 0.96" displays that are sold as having SSD1306 are actually SSH1106. With the SSD1306ASCII library i'm using here, if you look through the initialisation structures for the two controllers there's very little difference. A different library i tried using before this one, the 1106 display worked better using a 1306 init structure than the 1106 one they provided.

At absolute worst case, the driver i'm using supports the various SSD1306 flavours so if anyone gets stuck it'd only require a change of the init structure used in setup() & then recompile.

On the display board i put a set of vias in front of the 7 pins for the OLED display. I figured that if someone was to get a really oddball OLED with pins in totally different configuration, and they were crazy enough, they could cut the track between the via & the dispplay & rework wire the signals. 5 out of 7 of those signals can be re-mapped in the AVR code, so it's only if the 0V & Vcc are different would one need to do that. The option's there though.
gbiz
Eloc wrote:

You'll have to specify that you WANT the batch code next time as they're proving more popular than the ones without...


It's bizarre. When i saw them i thought i wouldn't be able to give them away. I'll charge extra for them next time hihi
adam
it could almost pass for decoration, it's really not that bad
Altitude909
cant go wrong with some cryptic gibberish
gbiz
Well, all the batch number panels are now spoken for. That i didn't expect when i first saw them. applause
sammy123
I now have 3 modules with batch numbers on the panel. It's a collection. w00t
Digital Larry
The next thing people need to do is say things like "batch 412931-06 C really has that certain je ne sais quoi" because - after all, they are unique like snowflakes! hihi
Altitude909
Test build complete! Nothing to report about the build.

Software programming:

The ISP header is NOT powered, this will fail the programmer software in Atmel studio or anything else (if it exists) that reads that pin to determine voltage of the part. Quick solution was to simply jump a wire from the VCC of the display to that pin and it programmed fine.

EEPROM programming:

I used the flashcat on windows sucessfully:

http://www.embeddedcomputers.net/products/FlashcatUSB/

gbiz
Altitude909 wrote:
Test build complete! Nothing to report about the build.

Software programming:

The ISP header is NOT powered, this will fail the programmer software in Atmel studio or anything else (if it exists) that reads that pin to determine voltage of the part. Quick solution was to simply jump a wire from the VCC of the display to that pin and it programmed fine.

EEPROM programming:

I used the flashcat on windows sucessfully:

http://www.embeddedcomputers.net/products/FlashcatUSB/



Well done Altitude909 screaming goo yo

Good to know there's an EEPROM option for windows users now. (I found a guide for programming serial ports on windows, so i'm going to have a go at porting my host side code).

The lack of Vcc on the ICSP is intentional. I never add it on the AVR based designs i make. I'd hate for someone to kill their programmer or worse their Dervish connecting a programmer that supplies Vcc. (I killed a Uno once doing this). I use avrdude & it works without Vcc there with an AVRISP mkII & my programmer shield. As Altitude909 says, if you need Vcc for your programmer you can easily get 3.3V from either from pin 2 of the OLED connector or pin 2 or one of the inter-board headers (J3 - the pin is marked on the silk). I'll add a jumper on the next iteration of display board that allows users to optionally enable it.
Altitude909
I have to say, the effects on this thing are really something else. Quite good.
gbiz
That's a great idea using a flattop LED Altitude909. Just tried one here & it looks lush with the black panel. Needs a lower value resistor to the Kingbright clear roundtop. I'll add it as an option in the BOM.
Altitude909
100R should be right for those
gbiz
I used a 470R, but i'm not a fan of bright LEDs.
gbiz
Anyone holding on for the B50K tall trimmers at Thonk, they're back in stock now.
BARE BONES
1 pcb & panel please smile
gbiz
Sorry for the lack of updates. I've been busy packing chips & PCBs, & getting everything ready for building. Sigh.

The last of the orders should hopefully be shipped tomorrow (friday at latest). If you've not had an email from me saying your boards are on their way, expect one.

So now the fun starts. Miley Cyrus

I made a few updates to the BOMs & the Mouser carts a few days ago. Nothing serious. I added Mouser & Farnell SKUs for the inter-board headers, & added them to the Mouser project cart. If you're like me you buy breakoff strips of headers you won't want to be buying these, so you'll want to remove them from the Mouser basket, but they're there if you want them.

I like the look of Altitude's flat top LED so much, i made it the default one beer! so i changed the LED in the Mouser cart from the Amber clear roundtop Kingbright to the green flat top. I also changed the LED resistor R12 to suit. The one in the cart is 220R, a compromise between blindingly bright & dim. I updated the BOM, which now details both LEDs & suggested resistor values for each. It's all commented.

The later (marked v3.1.1) display boards have an additional 2 pin header fitted (J6). If you jumper this, it'll provide Vcc (3.3V) to the ICSP header. You only need to do this if your programmer expects Vcc. If you use the Arduino ISP sketch with the Teensy on the EEPROM programmer, you won't need it. For the older v3.1 display boards, if you need Vcc, you'll need to fit a rework wire from Vcc somewhere on the board. There's a couple of suitable places, the build guide details all this. I've added the 2 pin header to the BOM & the Mouser cart. Again, i expect most people to not need this.


I've uploaded a bunch of files to my ftp site. I'll keep using this for now, it's easier for me to control stuff, but at some stage once it's all stabilised the intention is to move it to github. There's a zipfile containing the whole tree (linky) or you can just grab individual files from the tree here. There's various READMEs dotted around describing whats what. More items will be added.

BOMs & build/user guides are in the docs directory here. The guides should hopefully get regular updates now.
sammy123
Guinness ftw!
Rowan
I received my boards on Monday, Thanks gbiz!

Time to order the parts!
edwinm
Bit confused about LCD pins. Could somebody let me know if this screen will work?

http://www.ebay.co.uk/itm/Yellow-Blue-SPI-128X64-OLED-LCD-LED-Display- Module-For-Arduino-0-96-Serial-UK-/152061294847?hash=item23678f38ff:g: vRYAAOSwtPZXHf3L
gbiz
edwinm wrote:
Bit confused about LCD pins. Could somebody let me know if this screen will work?

http://www.ebay.co.uk/itm/Yellow-Blue-SPI-128X64-OLED-LCD-LED-Display- Module-For-Arduino-0-96-Serial-UK-/152061294847?hash=item23678f38ff:g: vRYAAOSwtPZXHf3L


Avoid bi-colour, i've not tested it, stick with monochrome (blue or white). This is their blue equivalent
http://www.ebay.co.uk/itm/Blue-SPI-128X64-OLED-LCD-LED-Display-Module- For-Arduino-0-96-Serial-UK-New-/152061317458

The pictures look OK. It's physically the correct size, & it has 7 pins, which is a good start. Most of these displays support both I2C and SPI interfaces. The interface used defined by which resistors are fitted at the back. If you look at the 4th image in that blue display auction, you'll see it's got resistors R3 & R4 fitted, which provides 4 wire SPI, so that's good. It's a bit odd that the clock & data pins are marked as SCK & SDA. With 7 pin displays these are usually marked D0 & D1, which would be SCK & MOSI for SPI, & SCL & SDA for I2C.

The specs are for a 4 wire I2C display, which doesn't match the picture at all. I assume they've cut'n'pasted the wrong description.

If the photos exactly match what they ship you, it should work. It's a good price & much faster shipping than from China. If it were me i'd risk it.
edwinm
Thanks for that! Got to say that your detailed help and documentation is about the best I've encountered and much appreciated!
gbiz
For anyone thinking of using Alps RK09's, they fit the PCB fine, but the panel will need drilling out to 9mm to take the wider bushing.

Bamboombaps
id like to give this a try if its still available? 1 of everything please
oberkorn
received the goods here some days ago, forgot to write it here
but all looking very good, thanks
Altitude909
and here's my take on the panel

gbiz
Altitude909 oh yes, that looks sweet applause

Did you use a perspex window for the OLED ?.
Altitude909
yes. Always.
edwinm
I've got my teensy set up as an ISP programmer. Is there a file somewhere I can upload or do I have to compile something? If so I might need a bit of help with the compiling smile
edwinm
I'm trying atmelstudio7 instead of my teensy but it keeps crashing when I set the fuses. I can upload the hex file with seemingly no problem but when I set the fuses as per the build guide

The ATTiny is programmed with the following fuses:
lock: 0x3f
lfuse: 0xe2
hfuse: 0xd7
efuse: 0x07


a warning comes up saying I could brick my device. I ignore this smile but when I click 'Program' studio7 crashes.

I'm new to programming chips but have successfully managed several Mutable builds. Anybody got any ideas where I'm going wrong? Thanks1
gbiz
Sorry, i can't help you, I use avrdude.

Does it have an option to show you what fuses are set ?. Can you verify the hex to check it's been uploaded correctly ?.

What OS are you on ?.

What programmer are you using ?. Does it require Vcc to be present on the ISP header ?.
edwinm
Aha.

I'm using Windows 10 and an Olimex AVR-ISP-MK2. I've run a wire to the 3.3v as it wouldn't read the device signature before. I can upload the hex and it seems to verify ok. The fuses that amtelstudio reads are

High: 0xDF
Low: 0x6E
Extended: 0xFF
Lockbit: 0xFF

I started fiddling with the Teensy as an ISP device but as per my previous post couldn't work out what to upload. I've flashed the eeeprom using my macbook which verified but there's no life on the screen when I reboot. I do get audio passing through and all the voltages read ok as per the guide.
gbiz
Aha, Windows 10.

If you want to use the Teensy as an ISP, first off install the Arduino IDE if you haven't already & install the teensyduino library. Run up the Arduino IDE, there's a sketch in Examples called "ArduinoISP". Load that. Set the Board type to the Teensy you're using in Tools, (Teensy3.0 or Teensy3.1/3.2). Click on upload. Now you can use the Teensy as an ISP.

Edit: scrap what i originally wrote. It's been a log day ..

But now you'll need to use avrdude or something similar to upload the hex to the ATTiny. There's ports of avrdude for OSX & Linux, not sure about Windows.
gbiz
Does atmelstudio give you options on what fuses to set ?.

Just reading back a page, & Altitude909 successfully used atmelstudio to flash his.
Altitude909
edwinm wrote:
Aha.

I'm using Windows 10 and an Olimex AVR-ISP-MK2. I've run a wire to the 3.3v as it wouldn't read the device signature before. I can upload the hex and it seems to verify ok. The fuses that amtelstudio reads are

High: 0xDF
Low: 0x6E
Extended: 0xFF
Lockbit: 0xFF

I started fiddling with the Teensy as an ISP device but as per my previous post couldn't work out what to upload. I've flashed the eeeprom using my macbook which verified but there's no life on the screen when I reboot. I do get audio passing through and all the voltages read ok as per the guide.


Those fuses are wrong.

They should be:

lock: 0x3f
lfuse: 0xe2
hfuse: 0xd7
efuse: 0x07

try the L/H/E fuses first, then the lock fuse

Is the Olimex running the right firmware? IIRC, you needed to flash it with a firmware compatible with AVRstudio
gbiz
I think the Olimex ships with the correct firmware for atmelstudio, you need to flash it for avrdude.

Something else, check that you've set the AVR type to ATTiny88.
gbiz
What version of Studio7 do you have ?.

Are you seeing this ?:

Atmel Studio 7.0.934 resolves the following issues present in Atmel Studio 7.0.790:
...
• AVRSV-7379: Unhandled exception when writing fuses or lockbits when Auto Read is turned off.

(i'm not sure what auto read is)
edwinm
Updating Atmel Studio resolved the crashing! I've set the correct fuses and uploaded the hex, all verify ok but still no joy. I guess I should assume that the chips are programmed ok and start looking elsewhere? Are there any other troubleshooting tips you have? Any other particular voltages etc.? If I've got the wrong LCD would that stop the module working?
gbiz
Does the DSP work ?. The DSP & ATTiny are largely independent from each other. If the EEPROM has been flashed, it'll contain the programs, so when you power on it should be running program 0 in bank 0 ("Hall" from the "3K" bank). Set the mix pots to midway, feed an audio signal in on the left hand input & you should have a reverb signal on both outputs.

If that works, try the up & down pushbuttons. It should run through the programs in bank 0. If it does then the AVR is working & it's the display.

The only way the ATTiny could affect the DSP (or the DSP the ATTiny) from working at power on is if it holds the I2C lines down. That's easy to check, SDA & SCL should be at 3.3V. I'm assuming the I2C & the SPI interfaces are OK as it sounds like you've successfully flashed the ATTiny & the EEPROM.

Do you have a scope ?.
edwinm
Do you mean SDA & SCK (not SCL) on the FV-1? SCK is 3.25v and SDA is 0.03v so that looks like the problem.

At the moment I have audio passing through from in to out but when mix is fully CW there is nothing (both channels). There is nothing on the LCD and if I put the input to full the clip does not light. I have a scope but don't really know how to use it smile Perhaps this is my chance to learn!
gbiz
Yes they should both sit at about 3V. Power off & split the boards. Power up just the DSP board & check those voltages again (on the EEPROM progamming header).

Did you program the EEPROM with just the DSP board powered up ?
gbiz
Sorry, yes, SCK.
edwinm
After fiddling I am now getting 3.25v on the SDA as well. Dodgy solder I guess so I'll reflow. I programmed the eprom with both boards together but I'll program it again after I'm confident the joints are ok
gbiz
The eeprom programmer only checks the checksum of the data over the wire. If you want to check the eeprom has been corrcetly written, read the contents of the eeprom back into another file immediately after you've written it & compare the files with "cmp" or "md5" (OSX, "md5sum" on Linux).

Once you've used one of the up/down pb's, the persisted copy of the program number will change in eeprom, so the sum of the eeprom read back will be different. "cmp" will show just one byte out at the offset the program number is stored at, so if md5's differ use cmp to show where that is.
edwinm
It lives! Fixed a couple of dodgy solder points, re flashed the eeprom and voila! Thanks for the help!
gbiz
screaming goo yo
edwinm
Just been told about this

http://blog.zakkemble.co.uk/avrdudess-a-gui-for-avrdude/

Should be useful!
gbiz
Haha. You discover that now you've gone through all that hassle to get yours working. It'll certainly be useful for someone else hihi
edwinm
That's ok cos I want another one! Are there any boards/panels left?
gbiz
Funny enough, I said this would happen earlier today with someone else who'd only bought one set. hihi

It's a bit like bikes. The answer to how many you need is N+1 where N is how many you have right now.

YHM
grizzle
Is this the correct display? I want to make sure before pulling the trigger.

http://www.ebay.com/itm/Blue-3-3v-5v-0-96-SPI-Serial-128X64-OLED-LCD-D isplay-Module-for-Arduino-stm32-/272038236843?hash=item3f56be12ab:g:vd QAAOSwT5tWPILm

Cheers,
Alex
gbiz
Yes, that's the correct description Alex. I've bought two lots from that vendor. The first couple were fine, second lot were the wrong physical size & didn't match the description. After a few exchanged messages & threat of negative feedback, the vendor sent me the correct displays, & assured me that anyone else who bought them would get the correct item.


I found this one the other day on Aliexpress that looks promising. Half the price of the cheaper ones on ebay, with similar shipping time. The stats on the page would suggest they've sold a lot from there so i assume it's genuine. I've ordered a few so i'll know in a few weeks.
http://www.aliexpress.com/item/Free-Shipping-0-96-blue-0-96-inch-OLED- module-New-128X64-OLED-LCD-LED-Display/32595649930.html
grizzle
I may go ahead and use Aliexpress... I know people have used them for midibox projects with success. Thanks!
Rowan
Im going to start building two Dervish next week and I'm get everthing together at the moment and studying the documentation so I'm prepared and hopfully get this module up and running without a problem.

After reading through all the Gbiz's great documentation I have realised that I don't know how to programe the display board MCU. I'm comfortable with the FV-1 programing as the process is well documented but im struggling with the Atmel MCU process. There is mention in the documtation about "See below" how to program the MCU but doesn't actually seem to be in the documentation.

I'm going to be using Gbiz's programing breakout PCB with a teensy 3.2 and OSX (I can use windows if necessary). I understand the process of loading the sketch on to the Teensy. It's at this point I'm stuck, acutally burring the MCU.

From what I can leart so far I need to use ARVdude via terminal. I'm comfortable using terminal if I've got good instructions.

Can anyone point me in the direction of a good tutorial online for the Atmel novice?
adam
adafruit have some good avrdude tutorials
gbiz
Rowan you're fine with OSX. Do you have Arduino & Teensyduino instaled on your Mac ?

It looks like i need to edit the Dervish build guide to change "see below" to insted reference the programmer guide. I moved it all to there.

So, for what you're planning to do:

1) If you haven't already, install the Arduino & Teensyduino environments.
2) Plug the Teensy into the Programmer Shield & into your Mac
3) Program the Teensy with the ArduinoISP sketch.
Run the Arduino program.
From the "Tools" menu, select "Teensy3.1/3.2" and the port to be "/dev/cu.usbmodem12345" (the 12345 will be a different number, but hopefully there will only be one that looks like that). Leave the other options as default.

Select "Files → Examples → Arduino ISP → Arduino ISP"
It'll load some code into the window.

Select the "upload" button (the "→" one). It should compile
The Teensy is now running as an AVR programmer.

Exit the Arduino program

4) Upload the ATTiny hex to the ATTiny on the Dervish control/display board
I use avrdude for this & how to use that is documented in the EEPROM Porgammer guide. Edwinm found a graphical tool called avrdudess (see previous post) that's a graphical front end to avrdude. That runs on OSX, so if you're unfamiliar with the command line, you might find that easier.

Disconnect the Teensy from your Mac. Connect the ICSP header on the EEPROM Programmer shield to the ICSP header on the Dervish control/display board. I use a eurorack power cable for this. The headers on the eurorack power cable will be 2x5 at one end & 2x8 at the other, & the ICSP headers are 2x3, so just make sure that the red stripe side of the connector is plugged into pin 1 of both of the ICSP headers & you'll be fine.

If you've got one of the v3.1.1 Dervish control/display boards there's a 2 pin header to supply Vcc to the ICSP header. You do not need this for avrdude.

Power up Dervish & the plug the Teensy into your Mac.

The ATTiny hex file is "Dervish/code/build/attiny88_oled.hex" from the zip file.
(In the next day or so I'm going to add a directory at the toplevel of the zipfile that contains copies of all these hex's).

Use the avrdudess program to upload the that attiny88_oled.hex file to the ATTiny. As you're using the Teensy as the programmer you need to set the programmer type to "arduino"

Whilst you're programming the attiny hex at the same time you need to set the "fuses" on the ATTiny. The values you need for these are
efuse 0x07
hfuse 0xd7
lfuse 0xe2
lock 0x3f

Once the hex is loaded on the ATTiny, power off the Dervish & disconnect the ICSP cable. Open up the Arduino IDE again, & load the FV-1 target sketch from the zipfile "eeprom-programmer/fv1-eeprom-target/fv1-eeprom-target.ino" As you did before with the Arduino ISP sketch, upload this into the Teensy.

The Teensy is now ready to program the EEPROM using fv1-eeprom-host tool.
Rowan
Great. Thanks for the detailed advice.

I think I'm ready to go once the module is built.
gbiz
I've just made some updates to the docs based on email exchanges i've had with a couple of people getting theirs working, also with some posts in this thread.

I appreciate the command line is going to be new to a lot of people, so I've tried to document how to unpack the zipfle & set up the PATH & environment variables so you can easily get to the DSP files. Please let me know if i need to make anything clearer.

I've also made a new toplevel directory "kwikfiles" that has copies of all the binaries, hexs etc to save you having to search down through the zipfile tree looking for things.

Easiest way is to grab the new zipfile.
here
thelizard
PCBs and Panel arrived a few days ago. Thanks again for this awesome project!
mckenic
Reminds me - must send a Thank You email!
Communication, support and info even before the boards arrived was/is above and beyond - many, many thanks!
mqmq
Did anyone make any video demo of this ? I'm curious to see the module in action and the "workflow" Mr. Green
gbiz
I don't really have anything to record decent quality video with, else i would mqmq. Hopefully as they start to get built, some kind soul will do one.

What would you want to see with it's "workflow" (that made me smile BTW grin ) ?.
In use ?.
How to flash it ?.
mqmq
Yea, just to see it in use, see how one navigates the menus etc...
spotta
Heads up. I got this display
http://www.ebay.co.uk/itm/162083452995?_trksid=p2057872.m2749.l2648&ss PageName=STRK%3AMEBIDX%3AIT

Came within 6 days from china, much quicker than the estimated time
gbiz
mqmq wrote:
Yea, just to see it in use, see how one navigates the menus etc...


The UI is really basic, there isn't much room in the ATTiny for any complex code, & IMHO it doesn't need anything else. Everyone who i've lent one to so far i've just left them with it & they've worked out how to navigate the UI in seconds.

Press the "select" button when it's running & you get a set of menu options.
One option lets you scroll through the banks of programs in the EEPROM & either select a new one for the FV-1 or cancel. Another set the screensaver timeout, another the screen brightness. Another is "oops i didn't mean to press that".

The up/down buttons go up/down or increment/decrement as appropriate. The Select button selects what you've chosen or takes you back up.

Thats it really.

The FV-1 runs independently from the ATTiny, so until you unload a new bank into the EEPROM space that the FV-1 addresses, the FV-1 will continue to run whatever algorithm is currently "live". If you go into a screen to change the screensaver or brightness, or whilst you're navigating the program banks, the FV-1 is just doing it's thing regardless. There's no change in the audio.

The DSP board is designed to also work with a dumb controls board with no OLED or ATTiny that supports just 8 programs in the EEPROM. It's why the DSP board is 8HP & the control/display board is 12HP.


I'll put some pics in the User guide later this evening. I've been meaning to do that for a while. Not the same as a nice video, but hopefully it'll give you some idea.
gbiz
I just updated the user doc to include some "screenshots".
Fixed a bug in the bnk2eeprom script.
mqmq
Thanks gbiz ! Exactly what i needed ! hyper
gbiz
The displays from Aliexpress (link up there ^^) showed up today & the one out of the bag that i tried at random worked fine. The serial lines are marked SCK & SDA rather than D0 & D1, but the configuration resistors are set for 4pin SPI so thats OK. Only other thing compared to the displays i've been getting from ebay, they're more of a green-ish blue colour.

Can't grumble at that price, though, and speedy delivery.
gbiz
I'll be at the Brighton modular meet this sunday with a modular & some Dervishes. So if anyone wants to sit down & go through uploading firmware or programs to the EEPROM or any of the tools to work with images, i'll have laptop, programmer etc with me.
Rowan
I've build two Dervish modules this weekend and both have what seems to me the same problem.

I've successfully (I think) uploaded the code to both the Display and DSP PCBs, the displays work, the buttons work, the clip LED works as do the input trimmers. The problem is when the both mix trimmers are rotated CW there is no wet signal.

When I rotate the mix trimmers the dry signal fades out (to be expected) and at about 10 o'clock a VERY faint wet signal can be heard, at this point if I adjust the control pots i can hear the effect changing. Once I move the Mix trimmers past about 10 o'clock the wet signal cuts out.

I've gone over all the solder joints a reflowed them all and cat spot any solder bridges any where.

Has any one got any suggestions where I should start looking?

I've got a scope if that helps.

Thanks.
Rowan
I've just fired up my scope and there is an DC offset introduced on the output when the mix trimmer is turned CW. When the both the Left and Right trimmer are rotated the offset goes from 0V (Fully CCW) to 11.6V (Fully CW).
gbiz
It sounds like the DSP is working. And the output op-amps as the dry signal is there, so that discounts a problem with U7 itself and with op-amps 1 & 4 of U7.

If it's both channels on both boards i'm wondering if there's a component value wrong.

First off, check REFP (p26) is at about 3.3V, & MID (p3) is about 1.65V. If you don't get those voltages check R17.

Trace it through. Pick a simple waveform from an oscillator, like a basic sawtooth with no modulation or filtering applied. Set the mix to 50:50, pick an effect like a reverb, turn the controls to minimum so the effect is minimal on the output signal. Set the input level so the clip LED is just not illuminating.

The DSP outputs are on p27 & 28. Should be about +/-1V, centred about that MID voltage on p3.
p7 & p8 should be the same waveform about +/- 3V around 0V.
LMIX_WET & RMIX_WET, (best probed at p9 & p6 on J9, the long connector to the left of the DSP, you'll see the signals marked in the silk on the control board), should be about +/-1V, centred around 0V.
gbiz
Something else, check the orientation of the components around u7.

Rowan
Thanks Gbiz!

Here are the measurements with a raw square wave, mix @ 50%

U5 P26 3.4V
U5 P3 1.8V
U5 P28 1.75 Centre Max 2V Min 1.52V
U5 P27 1.75 Centre Max 2V Min 1.52V
U5 P7 0V
U5 P8 3.6V

J9 P9 -3.4V
J9 P6 Square Wave
Rowan
I've mounted C54, R38, R43 and C53 horizontally rather than vertically d'oh!

That will be the problem then and explains why both board have the same issue.

Let me correct that and see if that's the issue.
gbiz
I did wonder if it was something like that, why i posted the image. It's easily done, there's not a lot of room in there to position the designators right alongside the components.

And for the record i got those test points wrong, where i said p7 & p8 i forgot to mention that's U7 d'oh! , and it should have been p4 of J6 very frustrating
Rowan
OK, I've got one module working correctly now nanners

The other one isn't, I thought they both had the same problem but I was wrong!

The non-working module's clip LED is constantly on, the left input doesn't pass any audio, the right input passes but there is no wet signal.

I'll go through the steps above and report back.
gbiz
One down ... screaming goo yo

If the clip LED is permanently on, IME, it's either the input signal is overloading the FV-1, there's too much feedback (so the FV-1 is getting overloaded again), or the FV-1 is having difficulty finding a valid program in the EEPROM - either it's not flashed or something is holding down the I2C bus.
Rowan
I'm sure that I read the EEPROM content back after programming both boards and did a checksum and they were the same.

I'll do it again to confirm that it's programmed correctly.

How can I get if the I2C bus is being held down?
Rowan
Bugger, I've cut the VBUS trace on the Teensy as I also built an Ornaments + Crime this weekend and I used the Teensy for that.

I'll have to buy another Teensy to check the EEPROM.

I'm in no great hurry, at least I have one working module at this stage.
gbiz
If the ATTiny is displaying the contents of the EEPROM correctly on the OLED, it's unlikely to be that. You can double check with your scope on the SCK & SDA pins on the I2C header. They should be at about 3V. Try changing a bank. You should see about 1 second of activity.

So if you check those voltages, i'll try & get these test points right this time:

The DSP outputs are on p27 & 28. Should be about +/-1V, centred about that MID voltage on p3.
p7 & p8 of U7 should be the same waveform about +/- 3V around 0V.
LMIX_WET & RMIX_WET, p9 & p4 on J9 should be about +/-1V, centred around 0V.

Also worth checking the inputs to the DSP, pins 1 & 2, should be similar to the outputs, about +/-1V centred around 1.6V or so.
gbiz
Rowan wrote:
Bugger, I've cut the VBUS trace on the Teensy as I also built an Ornaments + Crime this weekend and I used the Teensy for that.

I'll have to buy another Teensy to check the EEPROM.

I'm in no great hurry, at least I have one working module at this stage.


I doubt it's the I2C if the display is working. I'd continue looking elsewhere.
Rowan
Here are the readings.

U5 P27 1.8V
U5 P28 1.8V
U5 P3 1.8V

U7 P7 0V
U7 P8 0V

JP9 P4 0V
JP9 P9 0V
gbiz
How about pin 1 & 2 on the DSP ?
Rowan
When a signal is going into the Left input, nothing on P1 or P2.

When a signal is going into the Right input, nothing on P1 but is on P2.

I'm going to leave it for the night and come back to it tomorrow.

Thanks for all your help so far.
gbiz
Odd. With something going in only on the left you should get a signal on both the left & right inputs of the DSP as the right input is normalled to the left. With a signal only on the right, you should only see the signal on pin 2 (R).

Easy thing to isolate it to one board, swap the control boards between the two.

Also, with what sounds like a working signal in on the right input, if you pick a stereo in, stereo out program like one of the reverbs in programs 5, 6 or 7 in bank 6 (bank named "Spin ROM") in the EEPROM image i provide, i would expect you to get output on at least the right, but probably both outputs.
Rowan
[Deleted]
gbiz
So the DSP & the post DSP output is good. Try as i suggested & swap the control/display boards to narrow it down to one board.

Is the clip led on that bad one still permanently on ?.
Rowan
I'm an idiot. I tested the working module this morning!

Testing the one with the problem didn't produce any output with a stereo algo.

I switched the display boards over and the LED stays on with the display board from the good module. The buttons have also stopped working on the bad module...... Bad to worse very frustrating
Rowan
I just power the bad module off and on again the the buttons are working but the display contents are corrupted...... Maybe is a bad joint on the MCU?
gbiz
Now i'm confused. Do you have one display board that does work and one DSP board that works ?.
Rowan
Yes, I'm confusion myself as well... Sorry for the hassle
gbiz
NP smile

So, do you have one pair of boards you know are good, where everything works, that we can use a base for testing ?.
Rowan
Yes, I've got one working pair.

I found a solder bridge on the MCU of the display board that is show corrupt text, I've clear that bridge up but the test is still being corrupted. The display is fine on power up but after a few button presses the text becomes garbled.
gbiz
If you know you have one working display, then lets get the second DSP working first. So what happens if you take the DSP board from the non-working pair & run it with the working display board ?.

Before you do anything though, put a pencil mark or something on the two working boards so you know which ones are good. Saves confusion. I've done it smile
Rowan
Great news! I've got the non-working DSP board working nanners

P10 of U5 had a bad joint, no xtal = no DSP

The LED is behaving normally now.

The display is still show corruption thought.
gbiz
One down smile

How bad is the corruption ?. The occasional character, or like it's snowing over the display ?.
Rowan
The characters are jumbled. It's not snowy.

It happens when I press the buttons in quick succession.
gbiz
Weird, i've not seen that before. So pressing the buttons slowly it's ok ?.

Does the display brightness screen corrupt too ?
Rowan
I'll check the brightness screen tonight for corruption.

As it stands the module seem to be perfectly usable as it will tend to be set to an algo and left untouched. I anticapate that I'll find a reverb I like and leave set at that, at least that's how I have tended to use outboard verb's in the past.

I really appricate all your help gbiz and sharing the Dervish with the SDIY world.
applause


Knowing myself and the love of a DIY challange I may end up wanting to build more.
gbiz
We can't leave it as it is, we have to get it working hihi

A bit more detail on how the screen corrupts might be useful - a screenshot would be great. Is it random ?. Is it just the program details ?. Is there any pattern to the corruption ?.

You've checked your soldering on the board but have you checked the OLED soldering ?. Especially if you've cropped the legs on the top. Might be worth just running the soldering iron over the header pins on the OLED to check the soldering is good there.

First off check the 3.3V supply - the tab on the outer of the two LDO regulators. In themselves, they're good as both DSP boards work with one display, but there might be an issue on the bad display board that's loading the supply. Check it with the scope & see what happens when you change program or change bank. If there was an issue with the supply i'd expect the that regulator to get hot. (They do run slightly warm, but not excessively so. Most of the current draw with this module is the DSP, which is run off the other regulator)

The reason i suggest the screensaver screen, that display pattern is generated entirely by the CPU so it isolates the I2C from the issue. Much of the text on the program & bank screens is read from the EEPROM over the I2C. There's nothing fancy like parity checking over the I2C so the corruption might be coming from an issue with the I2C. The ATTiny simply displays what it reads. If it is an issue with the I2C though, i'd expect it to corrupt bank data when you switch from one bank to another - thats 5K read & write over I2C, not the 80 bytes for a program change. You'd notice it then with the FV-1 probably refusing to run certain programs (and lighting the clip LED) or programs not working as expected. If you take the DSP board when it's like that & put it with the working display board then i'd expect to see similar corruption, as again, the working display board is simply reading from the EEPROM & the bank 0 contents are now corrupt. But the moment you switch banks on the working display, the bank 0 will be filled with good data & all will be back to normal.

If the screensaver screen corrupts, then it's either the SPI bus or one of the control lines from the ATTiny to the OLED, or else it's the OLED itself.

The control lines, after a visual inspection etc, best check them with a scope. Have the two Dervishes side by side & compare the signals. ("CS" on the OLED is pin 10 on the ATTiny, "DC" is pin 11, "RST" is pin 12).

The SPI lines themselves from the ATTiny i'd expect to be OK. You've flashed the ATTiny over them. If you want to check these again, go back to the Teensy as an AVR ICSP & run avrdude verifying the flash. If there's an issue with the SPI bus on the ATTiny, i'd expect a flash verify to fail.

cd $DERVISH
avrdude -p attiny88 -P /dev/cu.usbmodem12345 -c arduino -b 115200 -U flash:v:kwikfiles/attiny88_oled.hex:i

If you want to test it over a period of time, run it in a loop. From the Terminal shell do

while true ; do
avrdude -p attiny88 -P /dev/cu.usbmodem12345 -c arduino -b 115200 -U flash:v:kwikfiles/attiny88_oled.hex:i
done

when you hit return after "done" it'll start running avrdude & keep re-running it. Hit "ctrl-c" to terminate the loop. It's only running verify so it doesn't matter when you interrupt it.


Of course the other thing it could be is the OLED itself ...
gbiz
Rowan wrote:

As it stands the module seem to be perfectly usable as it will tend to be set to an algo and left untouched. I anticapate that I'll find a reverb I like and leave set at that, at least that's how I have tended to use outboard verb's in the past.


Thats why the DSP module is 8HP. I'd always intended re-doing an 8HP cut down version of the control/display board that just supports 8 programs selected by a pushbutton & 3 simple LEDs to show which is selected.
n167tx


Really really happy with my Dervish. This thing sounds amazing. so many effect and banks.
Enjoyed the build a lot. Super clean and straightforward. Superb Design.
Thanks Graham for all the support
djamsia


Thanks Graham for this great work, for this open source project and for the support, enviable documentation, desing, concept, etc etc etc......
BARE BONES
How can I get a couple of these boards and panels? heeeelp me please!!!@
thelizard
Having some trouble programming the EEPROM.

So far:
-I've finished the soldering portion.
-I've programmed the ATTiny and verified it.
-I've tested the recommended voltages in the build guide. The only oddity is that junc R33-R35 is reporting about +1.35V instead of +1.65V (should I worry about that?).

When I go to program the EEPROM, I get the following:

./fv1-eeprom-host -v -t /dev/cu.usbmodem1857671 -f ../images/spin_img.img -c W

iofile ../images/spin_img.img: 65536 bytes
args:
cmd: W
ardtty: /dev/cu.usbmodem1857671
iofile: ../images/spin_img.img
pgsize: 128
nbytes: 65536
offset: 0
CR to start transfer:
sending HELLO: good
sending CMD 87: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
writing 512 128 byte packets
.timeout reading from arduino


So close, yet so far! It's very possible that I have a bad solder joint somewhere, as on my first power test I was getting +3.3V on R33 before I reflowed that section.

EDIT: Fixed it! Just needed to reflow a few joints.

New Issue: Knob 2 is acting in reverse, and Knob 3 isn't responding at all. Still, satisfied enough that I can now sell my Z-DSP.
gbiz
thelizard wrote:
Having some trouble programming the EEPROM.

So far:
-I've finished the soldering portion.
-I've programmed the ATTiny and verified it.
-I've tested the recommended voltages in the build guide. The only oddity is that junc R33-R35 is reporting about +1.35V instead of +1.65V (should I worry about that?).


Yes, it should be closer than that. This is used as the bias for the 3 CV op-amps, so unless it's roughly 1.65V you won't get the full range on the pots/CV at the FV-1. (If everything is spot on, it should be 1.64V). So give that area another close inspection. It's all contained in that area of the board, either around the reference device itself U4/R32/R33/R35/C10 or pins 3,5,12 of the adjacent mcp6004 (U9). FWIW, you should be getting 0.41V on the adjust pin of U4/junc of R32/R33, but i doubt you've got that if the 1.65V is out.

thelizard wrote:

When I go to program the EEPROM, I get the following:

./fv1-eeprom-host -v -t /dev/cu.usbmodem1857671 -f ../images/spin_img.img -c W

iofile ../images/spin_img.img: 65536 bytes
args:
cmd: W
ardtty: /dev/cu.usbmodem1857671
iofile: ../images/spin_img.img
pgsize: 128
nbytes: 65536
offset: 0
CR to start transfer:
sending HELLO: good
sending CMD 87: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
writing 512 128 byte packets
.timeout reading from arduino


That command line is fine, and the Teensy is programmed with the target sketch OK, but it's getting stuck writing to the EEPROM, which suggests an I2C issue.

Just to check, you do have Dervish powered up when you're trying to program the EEPROM ?.

Check the orientation & wiring of the cable you're using between the programmer & Dervish. Pin 1 to 1, 3 to 3, 4 to 4.

With Dervish powered up & the EEPROM programmer cable connected, the SDA & SCL pins of the I2C header should be at about 3.3V. If they're not, disconnect the I2C cable & check again to isolate the cable/programmer. If they're still not, power Dervish off, separate the boards, power the DSP board & measure again to see if the fault is caused by the control/display board or the DSP board. Those two I2C lines are pulled up by the FV-1 so you only need the DSP board by itself.

You can program the EEPROM without the control/display board connected to the DSP board. Power Dervish off, seperate the two boards. Power up the DSP board by itself, connect the I2C cable & try programming again. If that works, then the issue is with the control/display board.

The two I2C signals only go to a couple of places on each board:
DSP: p14, p15 of U5 (FV-1) & p6, p5 of U6 (24lc512).
control/display: p27, p28 of the ATTiny (3rd & 4th pins on the bottom row)
They're the bottom two pins of the 8-pin inter-board header.

thelizard wrote:

So close, yet so far! It's very possible that I have a bad solder joint somewhere, as on my first power test I was getting +3.3V on R33 before I reflowed that section.


Assuming that the 3.3V rails are still OK, the 1.65V reference being at 1.35V won't cause the issue with writing to the EEPROM. It's a different part of the circuit.
thelizard
gbiz wrote:
thelizard wrote:
Having some trouble programming the EEPROM.

So far:
-I've finished the soldering portion.
-I've programmed the ATTiny and verified it.
-I've tested the recommended voltages in the build guide. The only oddity is that junc R33-R35 is reporting about +1.35V instead of +1.65V (should I worry about that?).


Yes, it should be closer than that. This is used as the bias for the 3 CV op-amps, so unless it's roughly 1.65V you won't get the full range on the pots/CV at the FV-1. (If everything is spot on, it should be 1.64V). So give that area another close inspection. It's all contained in that area of the board, either around the reference device itself U4/R32/R33/R35/C10 or pins 3,5,12 of the adjacent mcp6004 (U9). FWIW, you should be getting 0.41V on the adjust pin of U4/junc of R32/R33, but i doubt you've got that if the 1.65V is out.

thelizard wrote:

When I go to program the EEPROM, I get the following:

./fv1-eeprom-host -v -t /dev/cu.usbmodem1857671 -f ../images/spin_img.img -c W

iofile ../images/spin_img.img: 65536 bytes
args:
cmd: W
ardtty: /dev/cu.usbmodem1857671
iofile: ../images/spin_img.img
pgsize: 128
nbytes: 65536
offset: 0
CR to start transfer:
sending HELLO: good
sending CMD 87: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
writing 512 128 byte packets
.timeout reading from arduino


That command line is fine, and the Teensy is programmed with the target sketch OK, but it's getting stuck writing to the EEPROM, which suggests an I2C issue.

Just to check, you do have Dervish powered up when you're trying to program the EEPROM ?.

Check the orientation & wiring of the cable you're using between the programmer & Dervish. Pin 1 to 1, 3 to 3, 4 to 4.

With Dervish powered up & the EEPROM programmer cable connected, the SDA & SCL pins of the I2C header should be at about 3.3V. If they're not, disconnect the I2C cable & check again to isolate the cable/programmer. If they're still not, power Dervish off, separate the boards, power the DSP board & measure again to see if the fault is caused by the control/display board or the DSP board. Those two I2C lines are pulled up by the FV-1 so you only need the DSP board by itself.

You can program the EEPROM without the control/display board connected to the DSP board. Power Dervish off, seperate the two boards. Power up the DSP board by itself, connect the I2C cable & try programming again. If that works, then the issue is with the control/display board.

The two I2C signals only go to a couple of places on each board:
DSP: p14, p15 of U5 (FV-1) & p6, p5 of U6 (24lc512).
control/display: p27, p28 of the ATTiny (3rd & 4th pins on the bottom row)
They're the bottom two pins of the 8-pin inter-board header.

thelizard wrote:

So close, yet so far! It's very possible that I have a bad solder joint somewhere, as on my first power test I was getting +3.3V on R33 before I reflowed that section.


Assuming that the 3.3V rails are still OK, the 1.65V reference being at 1.35V won't cause the issue with writing to the EEPROM. It's a different part of the circuit.


Thank you! I ended up finding a few very suspect caps, along with two or three IC legs that looked like they didn't get enough solder during a drag. After reflowing those, programming the EEPROM worked and I'm able to use the module. This is fantastic, and I much prefer the menu-based interface and EEPROM to the cartridge-juggling of the Z-DSP. Thanks again for this awesome project.

I have new issues: Knob 2 is acting in reverse, and Knob 3 isn't responding at all. I think the reference voltage is still off, so I'm going to check out the spots you mentioned, along with the relevant spots in the schematics. I'll let you know when I get it fixed!
gbiz
thelizard wrote:

I have new issues: Knob 2 is acting in reverse, and Knob 3 isn't responding at all. I think the reference voltage is still off, so I'm going to check out the spots you mentioned, along with the relevant spots in the schematics. I'll let you know when I get it fixed!


Nearly there ! smile

If the 1.65V reference was out then all 3 would be behaving in a similar way. How about control 1, is that working ok ?.

Check you have the -10V reference on the left hand pin of each of the control pots. The middle pin of each pot should swing from -10V to 0V as you turn from CCW to CW.

You should get a +3V to 0V swing on U10 pins 1, 8 & 7 respectively for control 0, 1 & 2 as you go from CCW to CW. That'll help you isolate whether the issue is around U10 or U9.

Try putting a -5V to +5V CV in on each CV input & see what that does.
thelizard
gbiz wrote:
thelizard wrote:

I have new issues: Knob 2 is acting in reverse, and Knob 3 isn't responding at all. I think the reference voltage is still off, so I'm going to check out the spots you mentioned, along with the relevant spots in the schematics. I'll let you know when I get it fixed!


Nearly there ! smile

If the 1.65V reference was out then all 3 would be behaving in a similar way. How about control 1, is that working ok ?.

Check you have the -10V reference on the left hand pin of each of the control pots. The middle pin of each pot should swing from -10V to 0V as you turn from CCW to CW.

You should get a +3V to 0V swing on U10 pins 1, 8 & 7 respectively for control 0, 1 & 2 as you go from CCW to CW. That'll help you isolate whether the issue is around U10 or U9.

Try putting a -5V to +5V CV in on each CV input & see what that does.


Thanks for the help so far! I'm still getting 1.23V reference unfortunately.

Here are other measurements:
R31 goes from 0-2.47V
R29 goes from 3.25-0V (it operates in reverse)
R30 is pegged at 2.47V

Middle pins on all pots swing smoothly from -10 to 0V.

U10 pins 1 and 8 go from 0V to 3.35V. They respond in the same direction for knobs 0 and 1.
U10 pin 7 stays at 0V, no matter the position of knob 2.

I've tried redoing all of the 1.65V reference section in the schematics. Is it possibly happening elsewhere on the board?
gbiz
thelizard wrote:

Thanks for the help so far! I'm still getting 1.23V reference unfortunately.

Here are other measurements:
R31 goes from 0-2.47V
R29 goes from 3.25-0V (it operates in reverse)
R30 is pegged at 2.47V

Middle pins on all pots swing smoothly from -10 to 0V.

U10 pins 1 and 8 go from 0V to 3.35V. They respond in the same direction for knobs 0 and 1.
U10 pin 7 stays at 0V, no matter the position of knob 2.

I've tried redoing all of the 1.65V reference section in the schematics. Is it possibly happening elsewhere on the board?


So you've got a number of issues there (as you probably guessed wink )

What you're getting at U10 pins 1 & 8 is good.
CV0/POT0 at R31 would be OK if the reference was 1.65V.
The issue with CV1/POT1 (R29) is somewhere around R22/R26/R29, pins 12/13/14 on U9.
The issue with CV2/POT2 (R30) is back at the U10 pin5/6/7 op-amp, C33/R18, p3 J5, but might also be R9/R10/p3 J4 on the control board.

That 1.65V reference literally goes to just the 3 pins on that 6004. It's quite possible the issue you're seeing with CV2 is causing it (have a good look around p12 U9). It might be worth checking the values of the resistors R32, R33, R35. If you want to measure them in situ, on a Dervish here both R32 & R33 measure about 9K, R35 is about 470R. The 1.23V you're seeing there is the minimum for one of those adjustable references.

Just a thought, it might be worth checking the orientation of R16, R18, C32, C33. They're aligned horizontally, in line with their reference designators on the silk screen. (Wouldn't hurt checking all the components around there).

Feel free to post up a decent resolution pic of that area of the board.
dtard
I'm pretty much as new as you could possibly be to eurorack but this module is extremely interesting to me, wondering how to purchase the PCB's/EEPROM etc..
FingerTappin
Posting my newly built Dervish. The module sounds fantastic! A big thanks to gbiz for the module, fantastic/informative documentation and build help.

thelizard
gbiz wrote:
thelizard wrote:

Thanks for the help so far! I'm still getting 1.23V reference unfortunately.

Here are other measurements:
R31 goes from 0-2.47V
R29 goes from 3.25-0V (it operates in reverse)
R30 is pegged at 2.47V

Middle pins on all pots swing smoothly from -10 to 0V.

U10 pins 1 and 8 go from 0V to 3.35V. They respond in the same direction for knobs 0 and 1.
U10 pin 7 stays at 0V, no matter the position of knob 2.

I've tried redoing all of the 1.65V reference section in the schematics. Is it possibly happening elsewhere on the board?


So you've got a number of issues there (as you probably guessed wink )

What you're getting at U10 pins 1 & 8 is good.
CV0/POT0 at R31 would be OK if the reference was 1.65V.
The issue with CV1/POT1 (R29) is somewhere around R22/R26/R29, pins 12/13/14 on U9.
The issue with CV2/POT2 (R30) is back at the U10 pin5/6/7 op-amp, C33/R18, p3 J5, but might also be R9/R10/p3 J4 on the control board.

That 1.65V reference literally goes to just the 3 pins on that 6004. It's quite possible the issue you're seeing with CV2 is causing it (have a good look around p12 U9). It might be worth checking the values of the resistors R32, R33, R35. If you want to measure them in situ, on a Dervish here both R32 & R33 measure about 9K, R35 is about 470R. The 1.23V you're seeing there is the minimum for one of those adjustable references.

Just a thought, it might be worth checking the orientation of R16, R18, C32, C33. They're aligned horizontally, in line with their reference designators on the silk screen. (Wouldn't hurt checking all the components around there).

Feel free to post up a decent resolution pic of that area of the board.


Thanks for the excellent detail! Almost got it. CV2 wasn't working because R10 on the control board wasn't soldered in the whole way. I also fixed what looked to be a small short near U9.

At this point, R29, R30, and R31 all behave the same way: 0-2.47V and working in the same direction.

Once I get this reference fixed, I've got a finished Dervish spinning

EDIT: Strange... Unless I'm measuring wrong, I'm getting 470R on R35, 12k on R32, and 13k on R33. Seems like there's an issue there hahah.
janost
Havent even unpacked my free spin chip yet.

But im sure its quite fun smile
gbiz
thelizard wrote:


CV2 wasn't working because R10 on the control board wasn't soldered in the whole way. I also fixed what looked to be a small short near U9.

At this point, R29, R30, and R31 all behave the same way: 0-2.47V and working in the same direction.

Once I get this reference fixed, I've got a finished Dervish spinning

EDIT: Strange... Unless I'm measuring wrong, I'm getting 470R on R35, 12k on R32, and 13k on R33. Seems like there's an issue there hahah.


Just that pesky reference to get working. There's very little around there.

Check you have continuity between:
- the pads of R32, R33 & the topmost pad of the regulator U4
- the pads of r33, r35 & the bottom most pad of u4.
- 0v & the middle pad of u4.

And you should have about 1K between 0V & the r33/35 junction.
thelizard
gbiz wrote:
thelizard wrote:


CV2 wasn't working because R10 on the control board wasn't soldered in the whole way. I also fixed what looked to be a small short near U9.

At this point, R29, R30, and R31 all behave the same way: 0-2.47V and working in the same direction.

Once I get this reference fixed, I've got a finished Dervish spinning

EDIT: Strange... Unless I'm measuring wrong, I'm getting 470R on R35, 12k on R32, and 13k on R33. Seems like there's an issue there hahah.


Just that pesky reference to get working. There's very little around there.

Check you have continuity between:
- the pads of R32, R33 & the topmost pad of the regulator U4
- the pads of r33, r35 & the bottom most pad of u4.
- 0v & the middle pad of u4.

And you should have about 1K between 0V & the r33/35 junction.


Wow, thanks for the fast response!

I'm thinking R33 may be... damaged?

I've reflowed it a few times. When R33 is connected, the top pad of R33 is continuous with the top pad of U4, however the bottom pad of R33 is not continuous. The bottom pad of R33 is continuous with the bottom pad of U4, but the top pad of R33 is not continuous.

The rest of the pads seem to be continuous as expected. Should I go ahead and order a replacement resistor (along with spares of course, which I should have ordered in the first place)?

Already started making music with the Dervish. The weird pot range is tolerable for the time being.
gbiz
thelizard wrote:
gbiz wrote:

Check you have continuity between:
- the pads of R32, R33 & the topmost pad of the regulator U4
- the pads of r33, r35 & the bottom most pad of u4.
- 0v & the middle pad of u4.

And you should have about 1K between 0V & the r33/35 junction.


I'm thinking R33 may be... damaged?

I've reflowed it a few times. When R33 is connected, the top pad of R33 is continuous with the top pad of U4, however the bottom pad of R33 is not continuous. The bottom pad of R33 is continuous with the bottom pad of U4, but the top pad of R33 is not continuous.

The rest of the pads seem to be continuous as expected. Should I go ahead and order a replacement resistor (along with spares of course, which I should have ordered in the first place)?


What you're seeing there is correct. Sorry, i should have been a bit more specific up there ^^. What i meant by "the pads of R32, R33 & the topmost pad of the regulator U4" was the two adjacent pads of R32 & R33. The other end of R33 will be open circuit.

with R33 removed you should be able to measure it. Hopefully it's still 36K.

If you're ordering spares, i'd suggest getting another LM-4041-adj reference incase U4 is bad.
$XxxxX$
Would love to purchase the whole pack.

Display & DSP PCB pair
PCB panel
EEPROM programmer shield PCB

Also sent PM.
gbiz
$XxxxX$, unfortunately the last of the boards went yesterday. I might do another run in a week or two. I'll put you down on the interest list.

I was thinking about getting the next run of panels done at the same fab that dirkwiggler uses for his O & C panels.
trip
Sign me up for interest list as well thumbs up this looks like a great project.
Rowan
Gbiz, if you do a panel run as mentioned above I'd interested in a couple of panels.
gbiz
Rowan wrote:
Gbiz, if you do a panel run as mentioned above I'd interested in a couple of panels.


Will do Rowan. A few others have expressed interest in those panels too.
Rowan
Thanks. I've got my two Dervish sitting next to an O+C, The Dervish would look great is a similar looking panel.

BTW, if possible could you make 3 control pot holes a little bigger to accomadate Alps pots rather than having to open them out with a drill?
$XxxxX$
gbiz wrote:
$XxxxX$, unfortunately the last of the boards went yesterday. I might do another run in a week or two. I'll put you down on the interest list.

I was thinking about getting the next run of panels done at the same fab that dirkwiggler uses for his O & C panels.


Cool, thank you for this.
thelizard
Forgot to post here: Graham was super helpful via e-mail. We were able to track down that R33 was somehow brutally murdered by a soldering iron.

I now have a fully-working Dervish! I highly recommend this module to anyone comfortable with surface-mount components of this size.
YannickD
hey gbiz, could you please put me down on the interested list as well? would love to have a PCB set.
glacial23
I'd like to be added to the interested list as well.
vinylvandal
i would be interested in pcb+panel set too. a pcb panel would be fine for me i think. cheers!
smidirin
Hi gbiz.
I'd take 2 pcb sets with panels. Also programmer adapter.
Will you have fv-1 ic's available or should i order them somewhere?
Cheers
gbiz
Next PCBs hopefully will be in a couple of weeks. I just need to get something else finished first. I'll PM everyone who's expressed an interest once i have them done.

smidirin i can do the FV-1. There's probably enough interest here now for me to get them at 10-off pricing.

The last few orders i ended up doing a " PITA to source" component set along with the PCBs - the FV-1, tall trimmers, OLED + M2 m/f nylon spacers. I always vowed i wouldn't do kits for this, but so many people were experiencing long delays with those bits arriving it was easier for me to include them in the same package.
ym2612
I'll take a PCB+panel+programmer+component kit whenever you have more available.
jamsk
sorry scrub that, i already have them. Just my memory going
makers
I was just getting around to ordering from Mouser.

This is out of stock:

http://www.mouser.com/Search/ProductDetail.aspx?R=LM4041CYM3-ADJ-TRvir tualkey51430000virtualkey998-LM4041CYM3-ADJTR

And this is the only substitute I could find at Mouser:

http://www.mouser.com/ProductDetail/Microchip-Technology-Micrel/LM4040 CYM3-25-TR/?qs=sGAEpiMZZMuBck1X%252b7j9fEjlFmbDt1PzdU%2fJNZmjbYk%3d

It seems to be close but not described as Adjustable Shunt Reference.

Anyone know if it's a viable substitute?
gbiz
Looks like both 595-LM4041CIDBZR & 926-M4041CIM3ADJNOPB are in stock.
jamsk
gbiz wrote:
Looks like both 595-LM4041CIDBZR & 926-M4041CIM3ADJNOPB are in stock.

I picked this as an alternative
http://www.mouser.co.uk/ProductDetail/Texas-Instruments/LM4041CIM3X-AD J-NOPB/?qs=sGAEpiMZZMuBck1X%252b7j9fFxOFMTVQaIHLbr%252b27qP280%3d

It looked compatible, what do you think?
gbiz
jamsk wrote:
gbiz wrote:
Looks like both 595-LM4041CIDBZR & 926-M4041CIM3ADJNOPB are in stock.

I picked this as an alternative
http://www.mouser.co.uk/ProductDetail/Texas-Instruments/LM4041CIM3X-AD J-NOPB/?qs=sGAEpiMZZMuBck1X%252b7j9fFxOFMTVQaIHLbr%252b27qP280%3d

It looked compatible, what do you think?


Looks good. It's the 3000/reel version of the 2nd one i suggested (the "X").
Altitude909
You can always use the B version, they have plenty of those. D version may be fine also, it's just the accuracy spec
gbiz
Indeed. The 1% D variant would be fine here. As the cost difference between C & D is so small it seemed silly not to use C.

I just updated the cart to use the 926-M4041CIM3ADJNOPB. I'll update the BOM in the zipfile in the next version.
gbiz
I finally got around to ordering the new batch of PCBs & panels. Sorry for the delay. In the end i decided to stick with the existing fab, so the front panels will look the same. They should be with me in a week or so. Once they're here i'll PM everyone & sort out PP invoices etc.


I've just uploaded a new zipfile here

Theres some new scripts to make manipulating banks easier - see the Changes file in the DSP directory for some usage tips. The EEPROM programmers guide includes these.

I got fed up booting a Windows VM to compile programs so i hacked up an fv-1 compiler (in perl !!) (yes, yes, go ahead & mock hihi). It's perl & doesn't use any external modules so should run fine on Linux & OSX. I've used it to compile all the spn source programs i have here (something over 50), & the code it's producing matches byte-for-byte with binaries from SpinASM. BUT !!!. It doesn't have all the bounds checking etc that SpinASM does. If you try & compile something illegal, perl is as likely to complain as the program is. SpinASM is still your go-to FV-1 compiler. If you have any issues with my compiler go & try the same code in SpinASM. I know there's going to be corner cases i've not covered, so please let me know if there's any issues. I'm finding it incredibly useful for quickly making simple changes to a program & uploading it directly to Dervish, for changes like the detailed banks below. Again, see the Changes file for usage.

I've included a few banks of programs i've been playing with. These are all from code posted up on the Spin forum. The sources are in the DSP/src/spn directory, the banks themselves in the DSP/banks/bank directory. I've included a link to the original Spin forum thread at the top of each source file. Each of these banks contain a single program with changes between the 8 programs (eg the tap tempo ones have different time divisions).

dattorros.bnk: the Dattorro plate reverb with various modulation, pre-delay & filter cutoff settings.
dattorro-shimmer.bnk: the dattorro reverb with a long decay is close to a shimmer anyway. I shoehorned in an octave shift from another shimmer thread on the Spin forum. This will clip if you abuse it wink
pingpong-damped-div.bnk: a ping pong delay that i've added damping to, & division on the repeats.
taptempos.bnk: tap tempos with various time divided delays. Pot 2 needs to be fully CCW for the delay to be in "tap" mode, else pot2/cv2 just adjusts the delay time as usual. CV3 is the tap input. It needs a clock pulse of < 1sec. I find winding the pot fully CCW is best.

As ever, any questions, ask away ...

Enjoy
Bamboombaps
I've got a question- can I buy one of everything pls ? screaming goo yo
d.simon
somehow I missed the emails on this one a couple months ago...
I'd be interested in a pcb/panel set if/when they're available (sounds like there might be some soon?)
gbiz
The new batch of PCBs is here. I just built one up & that works fine so I'll PM everyone who contacted me about PCBs etc.

Anyone else who wants them, i do have spares.
random:user
I´d also be interested in the "one of everything package".
Cheers!
woodster
Dervish+/-

gbiz
It seems like a few people are running or thinking of running the environment in a Linux Vagrant image. It's a good solution for people who only have Windows.

The "dervtty" script that autodetects the Teensy TTY in the current zipfile only supports OSX (it has a hardcoded check for the OS). A couple of people mentioned they were looking to use Linux in a Vagrant image so I've added Linux support. I tested it on Fedora, but most of the Vagrant images seem to use Ubuntu, which i don't run here. The code should work as it just uses commands & sysfs which are common across all recent distros, but i'm interested in getting it tested. It isn't in the zipfile (yet), but you can get it from here
$XxxxX$
Hey I was here ordering this Arduino mega 2560 r3 for touch screen experimentation when I realized could I use this behalf Teensy 3.2??
So I dont need to buy both.
Cos its basically very similar machine or am i totally off...im absolutely n00b in coding just gettin into this.
hmmm.....
gbiz
$XxxxX$ wrote:
Hey I was here ordering this Arduino mega 2560 r3 for touch screen experimentation when I realized could I use this behalf Teensy 3.2??
So I dont need to buy both.
Cos its basically very similar machine or am i totally off...im absolutely n00b in coding just gettin into this.
hmmm.....


Yes it would work, you can use any Arduino compatible device. But as it's a 5V device you need to convert the outputs for the I2C bus down to 3.3V, otherwise you risk killing the FV-1 which isn't 5V tolerant. Sparkfun have a converter board that would work (this one). You're best sourcing the 3.3V for the target voltage for the converter board from the 2560 as there's none directly available from the I2C interface on Dervish.

Code wise, aside from probably changing some pin definitions, the target sketch uses the Teensy new I2C library, so you'd need to change that to the stock Arduino equivalent.
$XxxxX$
gbiz wrote:
$XxxxX$ wrote:
Hey I was here ordering this Arduino mega 2560 r3 for touch screen experimentation when I realized could I use this behalf Teensy 3.2??
So I dont need to buy both.
Cos its basically very similar machine or am i totally off...im absolutely n00b in coding just gettin into this.
hmmm.....


Yes it would work, you can use any Arduino compatible device. But as it's a 5V device you need to convert the outputs for the I2C bus down to 3.3V, otherwise you risk killing the FV-1 which isn't 5V tolerant. Sparkfun have a converter board that would work (this one). You're best sourcing the 3.3V for the target voltage for the converter board from the 2560 as there's none directly available from the I2C interface on Dervish.

Code wise, aside from probably changing some pin definitions, the target sketch uses the Teensy new I2C library, so you'd need to change that to the stock Arduino equivalent.


Ok that is clear.
Thank you very much from this information, helps me long way.
peace
Illiac
Subscribed to this thread. Super interested!
gbiz
Illiac PM/email me if you want PCBs etc.
7C
rad! pm'd! smile
stochasticfats
Looks awesome! Would like to get pcbs, panel & programmer shield please (plus FV-1 if possible). PM sent Guinness ftw!
makers
I finished my build today, checked all voltages and managed to flash the eeprom with a Teensy 3.1

But when I tried to program the Attiny88 I couldn't get the Arduino ISP sketch to compile. So I switched over to this:

https://learn.adafruit.com/usbtinyisp/user-manual

But I couldn't get that to recognize the Attiny88 on the Display board...

Couple of questions:

Should I see anything on the display before I program the Attiny88?
Should I hear any wet signal at all from the DSP board before I program the Attiny? (Dry signal passes through fine)
Should the Dervish be powered from Eurorack while programming the Attiny or should it get power from the programmer?

Thanks!
gbiz
makers wrote:
I finished my build today, checked all voltages and managed to flash the eeprom with a Teensy 3.1

But when I tried to program the Attiny88 I couldn't get the Arduino ISP sketch to compile.


A few people seemed to have had issues compiling that sketch, so I included a precompiled ArduinoISP.teensy31.hex binary in the kwikfiles directory. Just open that with the teensy application. It'll also work with Teensy3.2.

makers wrote:

So I switched over to this:

https://learn.adafruit.com/usbtinyisp/user-manual

But I couldn't get that to recognize the Attiny88 on the Display board...


From your last question, I assume that's due to a lack of power to the module.

makers wrote:

Should I see anything on the display before I program the Attiny88?


No.

makers wrote:

Should I hear any wet signal at all from the DSP board before I program the Attiny? (Dry signal passes through fine)


In theory, yes. The ATTiny has no involvement in the DSP working at all. But, I've noticed that often an unflashed ATTiny holds the I2C lines & prevents the DSP from accessing the EEPROM.

If you want to test the DSP & audio paths without it accessing the EEPROM, you can jumper the two pins marked "Int/Ext" on the DSP board. That forces the DSP to use it's internal programs. The program it runs will depend on the state the ATTiny is holding the 3 SEL lines. Assuming they're all low (0V), then the program will be a chorus-reverb.

makers wrote:

Should the Dervish be powered from Eurorack while programming the Attiny or should it get power from the programmer?


Yes, otherwise you'll get a message about the ATTiny not being recognised, device id 0x00000000.
gbiz
I just uploaded a new zipfile, that contains a minor fix to the ATTiny code.

The previous code sourced the text for a program from the "source" bank not the "live" bank. Normally you wouldn't notice any difference as the text in both banks is identical (live is a copy of the source). You'd only notice a difference if you attenpt to make a change to the text in the live bank, expecting the ATTiny to display that. With the old code it won't, it'll continue to display the text from the source bank.

You only need to apply this fix if you want to edit the displayed text in the live bank. Really just people who are compiling code & uploading test binaries.

To apply the new hex image, you'll need to install the attiny_oled.hex file to the ATTiny. If you've used the teensy programmer shield, you'll need to reflash the Teensy with the Arduino ISP sketch, upload the attiny_oled.hex file, then reflash the Teensy with the fv1-eeprom-target sketch. These sketches can be easily applied using the Teensy application along with the appropriate hex from the kwikfiles directory.

If you're not sure what version of the ATTiny code you're running, from the menu go to the Debug screen. This fixed version should be "3.1.3 091016" or newer.
Drith
Over the weekend I got my Dervish finished up and it sounds great! No issues with the build but for some reason my MacBook wouldn't setup a port for the Teensy when flashed with the AVR programmer hex. Maybe there's a driver required? I was able to use my other programmer for the OLED board and the Teensy was detected and worked great for the EEPROM.

I was thinking of trying out Front Panel Express new graphic printing service to jazz up the panel. You mention in your first post having a FPD but I didn't see it in the bundle, could you post it or send it to me?

Great module, thanks for putting this together.
gbiz
Drith wrote:
Over the weekend I got my Dervish finished up and it sounds great! No issues with the build but for some reason my MacBook wouldn't setup a port for the Teensy when flashed with the AVR programmer hex. Maybe there's a driver required? I was able to use my other programmer for the OLED board and the Teensy was detected and worked great for the EEPROM.


Hmm. Thats odd. The sketch you run on the Teensy doesn't change the USB interface it presents to the host, so it should get recognised irrespective of which sketch it's running. You should always get a /dev/cu.usbmodemXXX device node created when you hotplug the Teensy.

I have seen situations where the Teensy (and standard AVR based Arduino) need to be unplugged & replugged after programming with a new sketch. The TTY device is still present, so as far as the host is concerned the device is still there, but the target device isn't responding.

There is an issue with avrdude 6.x & usblib that prevents the Teensy TTY port being detected if you use usblib (with "-P usb") to detect the Teensy's port. The steps in the docs all use the dedicated TTY device ("-P /dev/cu.usbmodemXXX") so you shouldn't see that.


Drith wrote:

I was thinking of trying out Front Panel Express new graphic printing service to jazz up the panel. You mention in your first post having a FPD but I didn't see it in the bundle, could you post it or send it to me?


I'll PM you the file. I'll also try & remember to put it in the next zipfile.

Drith wrote:

Great module, thanks for putting this together.


Thanks. Glad you like it.
makers
I got mine up and running last week. I wasn't programming the ATtiny properly. But it's all good now and I am thrilled with the sound.

Tonight I used the new script "bnk2eeprom" to load taptempos, pingpong-damped-div and datrorro-shimmers. SlayerBadger!
gbiz
makers wrote:
I got mine up and running last week. I wasn't programming the ATtiny properly. But it's all good now and I am thrilled with the sound.

Tonight I used the new script "bnk2eeprom" to load taptempos, pingpong-damped-div and datrorro-shimmers. SlayerBadger!


screaming goo yo

If you want to change any of the parameters in the programs in those banks (eg change the time dividers in the pingpong), it's easy enough to do with the assembler.

I've just made another version of that taptempo. Instead of the pot2/CV2 being clock sync or delay time, the delay is now only clock sync'd, & the pot2/CV2 provides a level of damping to the feedback signal. If anyone is interested in that i'll post it up.
gbiz
I've just uploaded a new zipfile (Dervish-combo-011116.zip).

This contains an updated fv1-eeprom-target Teensy sketch that fixes a bug that corrupts uploads that cross page boundaries in the EEPROM (each page is 128 bytes). Realistically, you'll only hit this bug when editing text with "fv1-edit-eeprom". Image, bank or program binaries always start on page boundaries in the EEPROM, & writes are done in page sized chunks, so you never hit this bug when uploading those. However the descriptive text typically is not on a page boundary, so you run the risk of hitting this bug when uploading new text. You'll see the bug when the new text displayed on Dervish doesn't match what fv1-edit-eeprom states it's changed the text to. To install this fix, open the relevent fv1-eeprom-target hex file (located in kwikfiles ) with the Teensy app & upload it as usual.

It also contains a few small script updates, and finally, I remembered to include the panel drill & fpd files
makers
gbiz wrote:

I've just made another version of that taptempo. Instead of the pot2/CV2 being clock sync or delay time, the delay is now only clock sync'd, & the pot2/CV2 provides a level of damping to the feedback signal. If anyone is interested in that i'll post it up.


I'd definately be interested in that version, perhaps it is included in the new .zip?
gbiz
makers wrote:

I wasn't programming the ATtiny properly.


It looks like that's probably my fault. Sorry. oops
nicdro thumbs up just pointed out there's a typo in the avrdude instructions for the flashing the attiny. There's a space in the filename for the write. The verify is ok though. (The current doc has the path as "kwikfiles /attiny_oled.hex", it obviously should be "kwikfiles/attiny_oled.hex"). I've updated the online version of the doc, i'll update the zipfile in the next day or so.

makers wrote:
gbiz wrote:

I've just made another version of that taptempo. Instead of the pot2/CV2 being clock sync or delay time, the delay is now only clock sync'd, & the pot2/CV2 provides a level of damping to the feedback signal. If anyone is interested in that i'll post it up.


I'd definately be interested in that version, perhaps it is included in the new .zip?


It isn't. I don't have a bank built with it currently, i've just been compiling code & uploading directly into the live bank. I'll make one up.
gbiz
I've made 2 versions of the damped clock sync/taptempo delay. There's one that's the same code as the existing taptempo delay, with just the delay time pot function replaced by varying amounts of damping* added to the feedback path, pot 1 controls the amount of damping.
With the existing program, there's no interpolation of the delay address read so you get a lot of clicks, tears when changing the clock frequency, more pronounced the faster the clock changes. I've tried adding the interpolation code from the Spin OEM1 echo (OEM1_5.spn), with a reasonable amount of success. It's not perfect but to me sounds better than no interpolation. I don't think it works so well for the smaller time division delays, but they also create some interesting sounds, so i left them in.

*The damping filter is set to just over 500Hz, which seems to sound about right to me, but it's easy enough to change if you want higher/lower.

I've created 2 banks, with the same time divisors as the previous taptempo bank. The names of the banks should be obvious enough. Just upload those int Dervish with bnk2eeprom as usual.

The banks plus the source are here. Unpack that file over the top of your existing Dervish tree. The banks will then be in DSP/banks/bank as usual.
I've also included the source. In each directory for the source, there's a "build" script that i use to automate building banks from a single source file for those who are interested in a quick way to create banks like this. Run that script & it'll create the whole bank from just the one source file.


Unfortunately, testing these delays highighted a bug i'd introduced in the ATTiny code d'oh!. It writes the persistent parameters into page 0 of the EEPROM, not the last page, so you'll get odd things happen after you load a new bank, change from program 0 to any other program & then back to program 0 - program 0 won't now work as expected. This bug is not in the original ATTiny hex, but is in the "3.1.3" hex from back in september. To fix, it'll need the ATTiny re-flashing. Sorry for the work this will create for you. I've included a fixed attiny hex in a new combo zipfile (here) along with the typo in the programmer guide. I've deleted the 301016 zipfile i posted a couple of days ago, & changed the link in the previous post to point to the new one.
random:user
Hey all,

i just got back to my dervish build which i started a couple of weeks ago and was then put aside since i could not get the attiny programmed. After getting to it this morning i found the updated zip file and got everything up and running in no time. w00t
While doing some testing i unfortunately ran into some problems with the pots so i went back to checking voltages on the dsp board and got ok readings on everything but on the junc r33 & r35 which reads around 3,2v and the three resistors r31 r29 r30 which swing between 2,9 and 3,3v on pot movement.
hmmm.....
Maybe someone could point me in the right direction help
Thank you in advance for any input and special thanks to gbiz for this great project we're not worthy
gbiz
That incorrect voltage at the junction of R33/R35 is what's causing the issue with the pots & lack of voltage swing at R29-31. It needs to be around 1.65V.

First suggestion is to inspect the soldering of the pads for R32, R33, R35 & U4. As it's at about 3.3V, it's probably just one pad that's not soldered.
random:user
gbiz wrote:
That incorrect voltage at the junction of R33/R35 is what's causing the issue with the pots & lack of voltage swing at R29-31. It needs to be around 1.65V.

First suggestion is to inspect the soldering of the pads for R32, R33, R35 & U4. As it's at about 3.3V, it's probably just one pad that's not soldered.


Thanks for the super quick reply!
I checked R32, R33, R35 & U4 and they seemed to be ok, resoldered them anyways. Unfortunately that did not fix the problem. Keep em coming... hyper

Btw i did some testing as is and the fx seem to be really nice, just a bit big at the moment
gbiz
random:user wrote:
gbiz wrote:
That incorrect voltage at the junction of R33/R35 is what's causing the issue with the pots & lack of voltage swing at R29-31. It needs to be around 1.65V.

First suggestion is to inspect the soldering of the pads for R32, R33, R35 & U4. As it's at about 3.3V, it's probably just one pad that's not soldered.


Thanks for the super quick reply!
I checked R32, R33, R35 & U4 and they seemed to be ok, resoldered them anyways. Unfortunately that did not fix the problem. Keep em coming...


There's really not much it can be, it's only those 4 components that generate that 1.65V reference. It's either a bad solder joint or bad component.

Check with your DVM that you have continuity between the following. Measure on the component itself, not on the pad, & check on all components.
* Between 0v, the top pad of R32 & the right hand pin of U4. (i tend to use the top pad of J1, the Int/Ext selection jumper for 0V).
* Between the bottom pad of R32, the top pad of R33 & the top left pad of U4.
* Between the bottom pad of R33, the top pad of R35 & the bottom left pad of U4.
* Check the bottom of R35 is connected to the large tab of U1, the right hand 3.3V regulator.

Top here means with the board oriented so the silk legend upright, the power connector is at the top.

I'm not a fan of measuring resistance of components in circuit, but for comparison with a working Dervish here
resistance across R32 is 9K1, R33 9K6, R35 470R. All measured with the common lead of the DVM to the topmost pad.

With power to the board, the voltage at the junction of R32/R33/U4 adj pin should be about 400mV.
random:user
gbiz wrote:
random:user wrote:
gbiz wrote:
That incorrect voltage at the junction of R33/R35 is what's causing the issue with the pots & lack of voltage swing at R29-31. It needs to be around 1.65V.

First suggestion is to inspect the soldering of the pads for R32, R33, R35 & U4. As it's at about 3.3V, it's probably just one pad that's not soldered.


Thanks for the super quick reply!
I checked R32, R33, R35 & U4 and they seemed to be ok, resoldered them anyways. Unfortunately that did not fix the problem. Keep em coming...


There's really not much it can be, it's only those 4 components that generate that 1.65V reference. It's either a bad solder joint or bad component.

Check with your DVM that you have continuity between the following. Measure on the component itself, not on the pad, & check on all components.
* Between 0v, the top pad of R32 & the right hand pin of U4. (i tend to use the top pad of J1, the Int/Ext selection jumper for 0V).
* Between the bottom pad of R32, the top pad of R33 & the top left pad of U4.
* Between the bottom pad of R33, the top pad of R35 & the bottom left pad of U4.
* Check the bottom of R35 is connected to the large tab of U1, the right hand 3.3V regulator.

Top here means with the board oriented so the silk legend upright, the power connector is at the top.

I'm not a fan of measuring resistance of components in circuit, but for comparison with a working Dervish here
resistance across R32 is 9K1, R33 9K6, R35 470R. All measured with the common lead of the DVM to the topmost pad.

With power to the board, the voltage at the junction of R32/R33/U4 adj pin should be about 400mV.


The continuity all checks out. But measuring the resistors i get R32 8k7 / R33 4k3 and R35 470R eek!
Starting to get to the bottom of this.
How did it get to this? Is there any resistors in the kit that i could have mixed up to produce this value?
If i get this right then i ll just order another 36k resistor for R33 and all will be good?
gbiz
random:user wrote:

The continuity all checks out. But measuring the resistors i get R32 8k7 / R33 4k3 and R35 470R eek!
Starting to get to the bottom of this.
How did it get to this? Is there any resistors in the kit that i could have mixed up to produce this value?
If i get this right then i ll just order another 36k resistor for R33 and all will be good?


Not neccessarily no. That R32 value is out too. Like i said, i don't like measuring resistance in circuit like that. The LM4041 is as likely to be faulty & cause those differences. The only way to be certain about the value of R33 is to remove it & measure it out of circuit. That assumes that you can remove it intact without damaging it in any way.

If you're really going to order an individual resistor, then given the cost of them, order spares for all three resistors and the LM4041.
random:user
gbiz wrote:


Not neccessarily no. That R32 value is out too. Like i said, i don't like measuring resistance in circuit like that. The LM4041 is as likely to be faulty & cause those differences. The only way to be certain about the value of R33 is to remove it & measure it out of circuit. That assumes that you can remove it intact without damaging it in any way.

If you're really going to order an individual resistor, then given the cost of them, order spares for all three resistors and the LM4041.


Would have been to easy. On my next big order i will just get a bunch of the before mentioned parts and replace them all. Might take a while but i´ll let you know how it went.
In the meantime i will just play around with those really big reverbs. Thank you for your help!
gbiz
No problem. Shame, it's so close waah

At least you can still experiment with uploading banks to it. Those Dattorro reverbs & shimmers are huuuge with the pots at max hihi Unfortunately the tap tempo/clock sync delays won't work, they need pot 2 to be close to 0V for the sync pulse to work.
random:user
Yeah, so close...
I will definitely upload some banks and familiarize with it. Those reverbs sound like a good staring point. Anything clocked will have to wait.
For now i´m really happy that i have gotten this far.
Enough for today, have been working on modules since 6 in the morning...
Will report back soon. Have a good one!
Guinness ftw!
j_p_higgins
So I built this today all the voltage checks are coming up perfect but I'm having some issues programming it.

Setting the fuses via the ISP I get this error message:
Quote:

avrdude: Version 6.1, compiled on Mar 23 2014 at 04:42:55
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/usr/local/Cellar/avrdude/6.1/etc/avrdude.conf"
User configuration file is "/Users/jonathan/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.usbmodem2137301
Using Programmer : arduino
Overriding Baud Rate : 115200
AVR Part : ATtiny88
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 64 4 0 3600 3600 0xff 0xff
flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.


avrdude done. Thank you.


And if i try and program the EEPROM (with or without the control board) I get this:

Quote:
iofile images/spin_img.img: 65536 bytes
args:
cmd: W
progtty: /dev/cu.usbmodem2137301
iofile: images/spin_img.img
pgsize: 128
nbytes: 65536
offset: 0
CR to start transfer:
sending HELLO: good
sending CMD 87: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
writing 512 128 byte packets
.timeout reading from programmer


Sometimes it times out after "sending HELLO:" other times after two dots "..timeout reading from programmer"

Having googled around some forums seemed to suggest that the "0xffffff" signature could be caused by a broken clock. With both these issues would they be caused if the crystal was damaged?
gbiz
The ATTiny uses it's internal clock source, so no. The crystal is for the FV-1.

Usually when i get 0xffffff for the device id, i've got the ICSP cable incorrectly oriented.

Two dots followed by a timeout when attempting to write to the EEPROM is usually something holding the I2C bus.

Just to check, Dervish is powered up when you're attempting this ?.
j_p_higgins
Yeah powered up as outlined in the teensy programmer guide
gbiz
Are you using the target hex from the latest zipfile (011116) ?. The previous version might cause that I2C issue, it had the pullups enabled in the Teensy. They're too "strong" to allow the I2C bus to function. The 011116 version has them disabled.

With the DSP board by itself, powered up without the programmer shield connected, what voltages do you get on the SDA & SCK pins on the I2C header ?. If you then connect the Teensy shield do the voltages change ?. Both those pins should be at about 3V.


An issue with the I2C bus won't impact on you programming the ATTiny. (The ATTiny might hold the I2C bus, preventing the write to the EEPROM, but as you've tried the DSP board by itself, so it's unlikely to be that).

What cables are you using ?.
j_p_higgins
Sometimes I'm so dumb its a miracle I've made it this far in life. I hadn't soldered all the pins on the programming board down. Don't solder when you're tired! All programmed and running great now. Thanks so much for this, loving it already.

gbiz
Hahahaha. At least it's all up & running now screaming goo yo
kogz23
Hi,
this looks fantastic!
Are there any left? Panel or pcb or hopefully both.
Thanks
Al
gbiz
kogz23 wrote:
Hi,
this looks fantastic!
Are there any left? Panel or pcb or hopefully both.
Thanks
Al


Yes, but down to the last few, i'll PM you.

I need to order some other PCBs over the next few days so i'll get some more.
teethgrinder
hi,

i'm looking for someone who can build a dervish for me within EU

I can solder THC but i'm not enough confident to start a smd project like the dervish FV-1

I already have all components ready to solder (incl. fv-1)

thanks for your help !
gbiz
teethgrinder i can build you one. PM/email me.
teethgrinder
great ! email sent
stochasticfats
Finished building my Dervish but have run into difficulties.

All voltages are OK.
Display seems to be working fine.
But all the effects banks are empty confused
Just get dry signal out.

Haven't tried to program the EEPROM via I2C as I'm using Windows, but I thought that there were 8 effects pre-installed on the FV-1?

help



gbiz
stochasticfats wrote:
Finished building my Dervish but have run into difficulties.

All voltages are OK.
Display seems to be working fine.
But all the effects banks are empty confused
Just get dry signal out.

Haven't tried to program the EEPROM via I2C as I'm using Windows, but I thought that there were 8 effects pre-installed on the FV-1?



As the EEPROM is empty, thats expected behaviour.

The FV-1 does have 8 onboard programs (well, 7 + a pass through). It can use either those, or 8 in an external eeprom, selected by the state of it's Int/Ext input. Dervish sets that signal to Ext with a pullup on the DSP board (R3), but you can override this simply by shorting the 2 pads marked J1 "Int FX" just above the DSP. Just solder a bit of link wire, resistor leg etc in there.

Program 0 of the internal bank is a chorus/reverb, so thats what you should hear if the DSP is working.

The ATTiny code is written assuming you do have a working, populated EEPROM. It's been an age since i tried this & sods law says i'm going to be wrong, but i think the ATTiny code as you have it there with nothing in the EEPROM will still react to the pushbuttons & still count through from 0-7 on the programs. So whilst you won't get much on the display, it'll still set the appropriate state on the FV-1 SEL[0-2] lines so you should be able to switch between those internal programs.
stochasticfats
gbiz wrote:
The FV-1 does have 8 onboard programs (well, 7 + a pass through). It can use either those, or 8 in an external eeprom, selected by the state of it's Int/Ext input. Dervish sets that signal to Ext with a pullup on the DSP board (R3), but you can override this simply by shorting the 2 pads marked J1 "Int FX" just above the DSP. Just solder a bit of link wire, resistor leg etc in there.

Thanks for that, I'll give it a whirl hihi
stochasticfats
Yay it's working w00t Thanks for your help gbiz.

Should tide me over until I work out how to program the EEPROM
gbiz
stochasticfats wrote:
Yay it's working w00t Thanks for your help gbiz.

Should tide me over until I work out how to program the EEPROM


Sweet. screaming goo yo I was wondering there for a minute if i was going to have to code an "Internal EEPROM" option smile

If you've only got Windows running, there's 2 options to program the EEPROM:
1) install a Vagrant image running Linux, then install the Dervish code into that. You'd need to add the Teensy's Vendor ID & Product ID to the USB passthrough table, but that should be it.

2) Find an alternative I2C programmer that has drivers for Windows. If you look back to p1 or 2 of the thread, Altitude909 found one that had all the features you'd need (ability to read/write a random number of bytes & to specify the offset are essential). Unfortunately the rest of the Dervish scripts won't work on Windows, so you'd have to find other ways to provide that functionality such as editing the EEPROM. Not impossible but a bit more work. Eg if you want to change the descriptive text for a program you'd have to work out the offset of the text in EEPROM, read from that offset for 84 bytes, edit it in a text editor that doesn't change the CR to CR/LF, then upload it back to the same offset.
pathein
Thanks Gbiz for the pcbs, panel and parts.

Another dervish in the wild. The oled was changed to white one, to match other modules with white oled in my setup.

Had to reflow some parts before getting it right with flashing the eeprom. Was really happy when the timeout issues sorted out eventually after reflow.

On the int fx pad, i soldered a low profile female header in there for easy shorting when needing to test the internal fv1 program.



[/img]
gbiz
Looks good pathein. Glad you got it up & running.

Thats a good idea for the Int FX pads.
pathein
and after playing through the initial banks of effect, i wanted to upload the additional banks of effect into the blank banks. Was using this line as stated in the programmer guide,

fv1-eeprom-host -v -o 51200 t/dev/my.tty-f banks/bank/Spin_OEM1.bnk -c W, where /dev/my.tty is being replaced with /dev/cu.usbmodemXXXXXX

i was unable to do the uploading and kept having the usage message shown instead. After some trial and error, uploading of the bank was done with this line,

fv1-eeprom-host -v -o 51200 -t /dev/cu.usbmodemXXXXXX -f banks/bank/Spin_OEM1.bnk -c W

Am wondering if anyone encounter similar?
gbiz
If you compare the two lines, you're getting the usage message because you're missing the "-" from "-t".


As you've got the lastest version of the zipfile & scripts you could have done the same using

bnk2eeprom -s 10 -b banks/bank/Spin_OEM1.bnk

The latest scripts use another script "dervtty" that tries to automatically determine the TTY device, saving you from having to work out what the device is called.
gbiz
Ooops. Sorry pathein, looks like there's a typo in the doc. I'll fix it now.

Edit: I've updated the online copy & theres a new zipfile named with todays date containing the updated doc.
pathein
Thanks g!

Will try the script method as well. Really love the module and the ability to have new fx bank is really so cool!
gbiz
No problem pathein. I'm sorry you wasted some time trying to get that working.

The helper script just saves some typing & you having to work out what offset a specific bank is at in the EEPROM. Under the covers it'll still be calling fv1-eeprom-host exactly as you ran there.

It's great to see someone having a go at customising their EEPROM smile
pathein
no time wasted at all. This is my first diy project which has the progragramming side of things beyond using teensy and uploading via usb.
Its been good experience so far with the pdf guide(love reading guide as such) and going through it, its giving me some confidence to do more diy stuff.
TimoRozendal
ah.. this module is very welcome, for various duties,

such as, 'huge reverb wash': http://www.timorozendal.com/temp/dervish_rev.mp3

Wow!
gbiz
Huge indeed. I can waste hours playing with those big reverb algorithms hihi
That sounds like one of the Dattorro programs Timo.
TimoRozendal
gbiz wrote:
Huge indeed. I can waste hours playing with those big reverb algorithms hihi
That sounds like one of the Dattorro programs Timo.


yes it is, I also like your shimmer version of it
sendepause
Had this on the "to build" shortlist, but when Timo sent me the reverb mp3 i was like maaaaaaaaaaaan....

So PM sent!
dalhasumai
Hey ! that sounds amazing. I'm in for a PCBs / Panel set, i already have an usbasp programmer.

Is this still on ?
gbiz
Yeah, boards are still available. I'll PM you with details.

Your USBASP will most likely program the ATTiny OK, but it won't program the EEPROM. You need a programmer capable of programming 3V I2C devices for that, that's really what the Teensy is used for with Dervish.
gbiz
TimoRozendal wrote:
gbiz wrote:
Huge indeed. I can waste hours playing with those big reverb algorithms hihi
That sounds like one of the Dattorro programs Timo.


yes it is, I also like your shimmer version of it


I keep meaning to put another bank of those Dattorro reverbs together but repurpose pot0 for something more useful than "mix" which you can do on the pots. Variable pre-delay or filter cutoff are the obvious ones.

Also anohter bank of shimmers with fixed shimmer level, & use the pot to set the frequency of the shimmer, rather than have it fixed at an octave.
gbiz
Dervish Workshop, Barcelona

The people at Befaco and myself will be running a Dervish workshop in Barcelona on Feb 25/26.

You'll get the opportunity to build and test your own working Dervish, including flashing the ATTiny code and uploading the EEPROM image.

Once you have a working Dervish, the rest of the workshop will be spent installing and familiarising yourself with the Dervish desktop environment. Our aim is that by the end of the workshop the student will have the confidence and knowledge to customise their Dervish, be able to take a source program, compile it and upload to Dervish.

For those who are interested in modifying existing programs, we'll take a high level look at the FV-1 architecture, the structure of a typical FV-1 source file. We'll take some existing source code, modify it, compile and upload it. (Please note this is not going to be an indepth DSP programming course, this is going to be very high level).

Given the ample amounts of time we have available for this, the pace will be very easy going, so this will be suited for people of all abilities and experience levels. The audience will certainly reflect that.

Places are going to be limited, so if you're interested, it's best to get in quick.

For a full agenda, pricing, registration details etc see this Befaco page
Southfork
gbiz wrote:
Dervish Workshop, Barcelona

The people at Befaco and myself will be running a Dervish workshop in Barcelona on Feb 25/26.

You'll get the opportunity to build and test your own working Dervish, including flashing the ATTiny code and uploading the EEPROM image.

Once you have a working Dervish, the rest of the workshop will be spent installing and familiarising yourself with the Dervish desktop environment. Our aim is that by the end of the workshop the student will have the confidence and knowledge to customise their Dervish, be able to take a source program, compile it and upload to Dervish.

For those who are interested in modifying existing programs, we'll take a high level look at the FV-1 architecture, the structure of a typical FV-1 source file. We'll take some existing source code, modify it, compile and upload it. (Please note this is not going to be an indepth DSP programming course, this is going to be very high level).

Given the ample amounts of time we have available for this, the pace will be very easy going, so this will be suited for people of all abilities and experience levels. The audience will certainly reflect that.

Places are going to be limited, so if you're interested, it's best to get in quick.

For a full agenda, pricing, registration details etc see this Befaco page


Have you done any workshops in the uk? I'd love to go to one especially for the fv-1 programming. Love my dervish btw smile
gbiz
Southfork wrote:
gbiz wrote:
Dervish Workshop, Barcelona
...


Have you done any workshops in the uk? I'd love to go to one especially for the fv-1 programming. Love my dervish btw smile


This is the first one.

I'd love do more. It'd be great to get more people customising their own banks, creating programs, and even better if they shared them. It's what i hoped would happen when i started Dervish. For me its as much about that environment as it is about the module itself. I deliberately left some of the banks blank in the default EEPROM image to try & encourage people to work out how to fill them smile

A pure customisation/programming workshop would be easier to organise than a combined build/programming one like we're doing at Befaco. Building needs tables for soldering irons, magnifiers, rework station, test equipment etc., ie a lot of arranging.

Good to hear you're enjoying your Dervish though smile
pathein
This is really fun module. I had similar fv-1 based fx module from other makers. But dervish can do much more than those. Really good to see more getting or diying this module!

Theres a free reverse reverb patch from malekko available. if anyone looking into reverse reverb, can try searching for it.

Oh yeah, gbiz, saw the info on the workshop on dervish. Theres mentioning of an expander kit available at the workshop. Is this a new add on for dervish?
gbiz
pathein wrote:
This is really fun module. I had similar fv-1 based fx module from other makers. But dervish can do much more than those. Really good to see more getting or diying this module!


Cheers pathein ! smile Glad you're enjoying it.

pathein wrote:

Theres a free reverse reverb patch from malekko available. if anyone looking into reverse reverb, can try searching for it.


(There's an audio example of it in use on the first page with a 909 kick). I built a Dervish up for someone last week & they requested i include a bank with that Malekko reverb, the Greedwood delay in it & some other programs from the Spin forum etc. I've been meaning to upload a zipfile of it for everyone to use but was going to hold off posting it until i'd finished something else. But that can wait. So, for now get it from here (linky). Unpack that zipfile into the toplevel Dervish directory, then use bnk2eeprom to upload it to a bank slot of your choice as usual. At the top of each of the source files included in the zipfile is a link back wherever the source code originated from. The bank contents are:

$ bnk_details Misc_Delays.bnk
------------------------
File: Misc_Delays.bnk
Name: Misc Delays
Prog 0: Greenwood Delay
Prog 1: Triple Delay
Prog 2: Dual LFO Chorus
Prog 3: Stereo Shimmer
Prog 4: Stereo Pitch Xpose
Prog 5: Up/Down Octaver
Prog 6: Tape Flanger
Prog 7: Malekko Reverse Rev

The dual LFO chorus is something i'd been playing with. One LFO is much more subtle than the other. Their depth changes by different amounts when the Depth pot is adjusted. The LFO is disabled when the speed Pot is fully CCW. To me it works really well on piano samples with a small amount of reverb afterwards.

pathein wrote:

Oh yeah, gbiz, saw the info on the workshop on dervish. Theres mentioning of an expander kit available at the workshop. Is this a new add on for dervish?


hahaha, i was wondering how long it'd take somone to notice that. Full marks for observation !!

Something born out of a need i had here really. It's probably not going to be useeful for most Dervish users. It's really of use only for people who want to do a lot of programming with their Dervish & don't want cables running out of their rack, or have the Dervish sat on a bench. It's a 4HP module. At the top is a slot that brings out the I2C bus. At the back of the module are 4 more pins that you connect to the I2C header on Dervish. It's only passive so you can't run long cable runs with the I2C, but it's better than nothing.
As there'd be a lot of free space i added a simple 3 way attenuverter that you can use either for CVs with Dervish or most other modules. These are simple attenuverter, theres no trimmers on there to NULL each CV. Hence it's fine for the CVs on Dervish & probably OK for most uses, but i probably wouldn't use it for something that requires very accurate 1V/oct duties for example. I'll post up a picture in a while.
pathein
Woah, awesome on the new bank! Actually i have been trying on compiling a bank with the greenwood delay, reverse reverb and some interesting patches from spin and spincad forum.
Progress been slow though as i am trying to understand the patch and learning spinasm/spincad. Again, thanks for the link to the new bank nanners

oooh, sounds good with the expander! Will love to get that when its available. That will make the loading of patches much easier and with the attenuverter, iam in love

In case if this is useful for new dervish builder, the i2c cable can be diy-ed using short or recycled power cable and pin header. Initially i was using an existing power cable for the uploading, but it was a bit cramp on the board to fit. Thus came up with this kinda,



gbiz
I have to admit, most of my programming with Dervish is something not dissimilar wink Molex SL is my choice now if you want to do the cable properly with crimped ends.

If you get stuck on compiling, ask away on here. I'm sure others would probably be interested in that too.

If you don't mind using the command line, the quickets/easiest way to compile FV-1 source is to use the assembler i wrote & include with Dervish. Run it as
"fv1-assembler program.spn". It'll generate a binary file with suffix ".bin" (eg in this case "program.bin"). That is ready to upload either into Dervish or into a bank file on the computer.
If you're testing code a lot, you can do the following trick with the unix shell, which if the compilation succeeds & there's no errors in the source will compile the code and upload into prog 0 slot 0 on your Dervish. If compilation fails it won't attempt to upload:

# fv1-assembler myprogram.spn && fv1-edit-eeprom --bi myprogram.bin

Then all you have to do is get the FV-1 to read the new binary by briefly pressing the up & down buttons (ie from prog 0, go up to prog 1 then back down to prog 0).

For me it's great as i can run it directly from within "vi" so i don't have to drop out of the editor to test a change.

(As typed there, it needs to be run in the directory the source file is in. And you need to remove the #).

If you want to put that binary into a bank, use "bin2bank".
If you want to create a new bank, there's a BLANK.bnk file that you can copy specifically for this purpose.

Then use fv1-edit-eeprom or bnk-edit-text to change the program name, pot details etc depending on whether you're working directly on Dervish or in a bank file on the computer.
pathein
Cool, great info on that thumbs up

I was trying out spinasm on combining the patches into single bank and going thru the guide to do the parameter naming, conversion etc. The ocd in me wanted to learn doing those things from ground up. Once iam familiar with that, will change to the scripts for faster access.
gbiz
Doing it that way with SpinASM, & going through the doc you'll certainly get to know how it all fits together in the end. But it's very very long winded though. And it needs Windows. Dead Banana
gbiz
Here's a couple of lofi phone pics of the I2C/attenuverter. The connector with the orange & yellow cables that's going into the slot at the top is the same size as the one you have on your cable pathein. The other end of that cable is connected to the I2C header on the Teensy, just out of the picture.

Those are Molex KK plugs on the I2C cable between the 2 boards, but i've still only got the standard pin header on the PCBs themselves. There's space on the PCBs for Molex SL or KK headers if someone wanted to do the job properly with a cable that's locked on.

I tried to get the power header orientated so that it's easy enough to use a power cable with 2 headers on it with a 90degree twist so you only have to use one power socket on the bus board.



pathein
nice one! i like that arrangement with the power header.

For the expander, is there any estimation of the power rating and value of the 3 pots? I have some spare 9mm b10k pots around, will be good if can utilise it
gbiz
pathein wrote:
nice one! i like that arrangement with the power header.

For the expander, is there any estimation of the power rating and value of the 3 pots? I have some spare 9mm b10k pots around, will be good if can utilise it


I've not measured the current draw. It's only one tl074, so only a few mA with no load.

I use B100K. I wouldn't recommend going any lower.
entomon
wow! this is a must have... hihi
Dogma
gbiz wrote:
Here's a couple of lofi phone pics of the I2C/attenuverter. The connector with the orange & yellow cables that's going into the slot at the top is the same size as the one you have on your cable pathein. The other end of that cable is connected to the I2C header on the Teensy, just out of the picture.

Those are Molex KK plugs on the I2C cable between the 2 boards, but i've still only got the standard pin header on the PCBs themselves. There's space on the PCBs for Molex SL or KK headers if someone wanted to do the job properly with a cable that's locked on.

I tried to get the power header orientated so that it's easy enough to use a power cable with 2 headers on it with a 90degree twist so you only have to use one power socket on the bus board.





I was just about to grab a zdsp and thought "nope gonna build this finally"
Does anyone know if Nik from macro machines/Omnimod scripts will work on the dervish? He showed it on a tip top zdsp but I'm sure they'd be portable...


Also i2c means monome teletype integration!!!!!!!!
pathein
Dogma wrote:


Also i2c means monome teletype integration!!!!!!!!


heh, had the same thought but didnt dare mentioning on that, since the work behind it to have it working with teletype is way beyond me lol
gbiz
Dogma wrote:

I was just about to grab a zdsp and thought "nope gonna build this finally"
Does anyone know if Nik from macro machines/Omnimod scripts will work on the dervish? He showed it on a tip top zdsp but I'm sure they'd be portable...


The FV-1 runs binary code, not scripts. Any FV-1 binary will run on Dervish.

Are the Macro Machines binaries proprietary code or open ?. If they're proprietary, please check that their EULA allows you to run them on another FV-1 platform. (The same goes for any other vendors FV-1 programs).

Dogma wrote:

Also i2c means monome teletype integration!!!!!!!!


To do what ?.
westlicht
wow, this looks amazing! great work gbiz! hope there are still pcbs and panels left smile
gbiz
Thanks westlicht smile

I have everything bar the PCB panels, which are just about finishing at the fab as i type, so i should have stock by early next week.


All PCB panels i supply from now on will be matt black PCB, & not the gloss black previously used. The matt ones should hopefully have a more consistent finish. I'll some pics up when i have them.
Southfork
gbiz wrote:
Thanks westlicht smile

I have everything bar the PCB panels, which are just about finishing at the fab as i type, so i should have stock by early next week.


All PCB panels i supply from now on will be matt black PCB, & not the gloss black previously used. The matt ones should hopefully have a more consistent finish. I'll some pics up when i have them.


Will there be spares? Would be tempted to get a matt one to bring my dervish more in line with my mxmxmx matt black panels.
gbiz
Southfork wrote:
gbiz wrote:


All PCB panels i supply from now on will be matt black PCB, & not the gloss black previously used. The matt ones should hopefully have a more consistent finish. I'll some pics up when i have them.


Will there be spares? Would be tempted to get a matt one to bring my dervish more in line with my mxmxmx matt black panels.


Yes, there will.

I'm using a different PCB fab to the one the O_C panels are made at, I'm not sure how much difference there will be visually between the two. The ones i've had made so far are 4HP, so it's a bit hard to judge what a wider module will look like, but what i have seen i much prefer. My O_C's are still in my backlog box(sorry Max hihi), so i've got panels here i can do a side-by-side comparison pic of if anyone wants to see that before ordering.
pathein
Will love to get the new matt panel and the expander panel/pcb set when its ready.
makers
I've built 2 and love having them both in my rack.

I've noticed a high frequency bleed into my Sputnik mixer through my power bus. It goes away when the display on the Dervish goes to sleep. I haven't taken the time to try different racks, power supplies etc. But I was wondering if anyone else had noticed anything similar.
gbiz
makers wrote:
I've noticed a high frequency bleed into my Sputnik mixer through my power bus. It goes away when the display on the Dervish goes to sleep. I haven't taken the time to try different racks, power supplies etc. But I was wondering if anyone else had noticed anything similar.


makers, I'm sorry to hear that. Nobody's reported anything similar to me either on here or in email.

I'd be curious to see if any changes in rack environment (PSU etc) has any impact on it.
toneburst
I'd be interested in a set of PCBs + panel for this.

a|x
stochasticfats
gbiz wrote:
2) Find an alternative I2C programmer that has drivers for Windows. If you look back to p1 or 2 of the thread, Altitude909 found one that had all the features you'd need


Finally got my hands on a FlashCatUSB programmer and programmed my EEPROM no problems. Now drowning in reverb screaming goo yo

Thanks gbiz we're not worthy

Also thanks Altitude909 for the headsup on the FlashCatUSB thumbs up
gbiz
stochasticfats wrote:
gbiz wrote:
2) Find an alternative I2C programmer that has drivers for Windows. If you look back to p1 or 2 of the thread, Altitude909 found one that had all the features you'd need


Finally got my hands on a FlashCatUSB programmer and programmed my EEPROM no problems. Now drowning in reverb screaming goo yo

Thanks gbiz we're not worthy

Also thanks Altitude909 for the headsup on the FlashCatUSB thumbs up


Excellent stochasticfats screaming goo yo

Incase you haven't tried it out yet, that FlashCat programmer allows you to specify the offset in the EEPROM to start a write to.
Banks start on 5120 byte boundaries. So you can take one of the DSP/banks/bank/ ".bnk" files and upload it to a specific bank.
Same thing for a program binary ".bin" file. They're on 512 byte boundaries in a bank.
stochasticfats
gbiz wrote:
Incase you haven't tried it out yet, that FlashCat programmer allows you to specify the offset in the EEPROM to start a write to.
Banks start on 5120 byte boundaries. So you can take one of the DSP/banks/bank/ ".bnk" files and upload it to a specific bank.
Same thing for a program binary ".bin" file. They're on 512 byte boundaries in a bank.

Looks like it's time to fill up those empty banks w00t
makers
gbiz wrote:
makers wrote:
I've noticed a high frequency bleed into my Sputnik mixer through my power bus. It goes away when the display on the Dervish goes to sleep. I haven't taken the time to try different racks, power supplies etc. But I was wondering if anyone else had noticed anything similar.


makers, I'm sorry to hear that. Nobody's reported anything similar to me either on here or in email.

I'd be curious to see if any changes in rack environment (PSU etc) has any impact on it.


I spent a few hours switching racks and module configurations but I didn't have access to a liner power supply The problem is clearly with the Sputnik mixer. I'm not the first to find problems with it.
gbiz
makers wrote:
gbiz wrote:
makers wrote:
I've noticed a high frequency bleed into my Sputnik mixer through my power bus. It goes away when the display on the Dervish goes to sleep. I haven't taken the time to try different racks, power supplies etc. But I was wondering if anyone else had noticed anything similar.


makers, I'm sorry to hear that. Nobody's reported anything similar to me either on here or in email.

I'd be curious to see if any changes in rack environment (PSU etc) has any impact on it.


I spent a few hours switching racks and module configurations but I didn't have access to a liner power supply The problem is clearly with the Sputnik mixer. I'm not the first to find problems with it.


Clearly Dervish is aggravating it though.

Something you could try if you have the parts in your spares bin. Make a small power passthrough adapter board on some stripboard, that allows you to put ferrite beads in series with the supply rails. Try running either Dervish or the mixer power using 2 power cables with this adapter board in the middle.
Excuse the ascii art ...

o-o --- [bead] --- o-o
o-o --------------- o-o
o-o --------------- o-o
o-o --------------- o-o
o-o --- [bead] --- o-o

Those are 2x5 eurorack power headers at either end. Obviously cut the track under the beads. Then connect it up like this, checking you have the red stripe correctly oriented throughout:

Busboard - [eurorack power cable] - adapter - [eurorack power cable] - Dervish/Mixer


I've often thought about making a small PCB that does this. One end plugging directly into the busboard. Using 1206 beads it'd be quite small.
makers
Thanks for the idea, I'm pretty certain I have a few spare ferrites around. What about L1 and L2 on the Dervish? Don't they already serve that purpose?
gbiz
makers wrote:
What about L1 and L2 on the Dervish? Don't they already serve that purpose?


They're there to protect the analogue side of Dervish. The supply for the ATTiny & OLED doesn't go through them.
ipnoteca
should i change the tiptop zdps for a dervish?
mainly i am interested into reverb and save some space...

anyone got boht and can make a comparison???

thank you in advance!!!

Guinness ftw!
gbiz
robocoder wrote:
should i change the tiptop zdps for a dervish?
mainly i am interested into reverb and save some space...

anyone got boht and can make a comparison???


I have both though one rarely gets used nowadays hihi

You'll certainly save some HP with Dervish. You can get 2 x Dervish & a 4HP mixer in the space one Z-DSP occupies.
There's plenty of reverb programs that you can use with Dervish. The default EEPROM image contains all the Spin demo reverbs. And theres a bank with variations on that wonderful Dattorro reverb.


A feature comparison is slightly unfair as they're very much targetted at different market segments. But here goes if you'll believe a mostly unbiased comparison from me (haha):

Benefits of the Z-DSP:
* Professionally written & supported algorithms. As much as i'd love it to happen, I can't see Sean @ Valhalla ever contributing an algorithm for Dervish unfortunately. With Dervish you're restricted to whatever programs kind people contribute online.
* Built in feedback. I couldn't see the point of adding this for Dervish. It would have added extra HP. With my Z-DSP i usually break into the feedback path to add filters etc. Thats easy enough to do with Dervish with external mixers, mults etc.
* External clock source for the FV-1. It's not something i've ever used with my Z-DSP, so didn't bother including it with Dervish. As with built in feedback, it would have required additional HP to implement.
* external switching of the program number. Again, not something i ever used with mine, and would require extra HP to implement.
* It probably sounds a lot better. I don't have a Numberz so i can't program a Z-DSP card so i have no way to run the same program on both platforms. So I've got no way to do a side by side comparison.
* It's got a nice brushed metal front panel with the name of a respected modular manufacturer written on it.

benefits of Dervish:
* Less HP. (The original display-less Dervish prototype was 8HP. The DSP board is still 8HP, so there's still an option do a reduced functionality 8HP version).
* 11 banks of 8 programs
* change a bank without powering off. Want to switch from Bit-rot bank to a reverb bank ?. With Dervish its a few pushes of the buttons. With Z-DSP, switch off, change cards, switch on, wait. (I know I'm opening myself up here to derision from all the people who hotplug their Z-DSP cards. There's no way i'm going to hotplug a £50 card that i have no way to restore from backup for free).
* relatively cheap to reprogram. Programmer costs about £25 (either Teensy3 & my shield, or the one that works for windows (sorry, can't recall the name, it's up there ^^)). Compared to $159 for Numberz + £8 per card to store 8 programs. (I just went to SchneidersLaden to check the price & it says Numberz is discontinued. So that's the current AnalogueHeaven price).
* cost, even if you get someone to build you one
* cost of ownership of multiple devices. Buy 2 x Z-DSP, if you want the same proprietary program running on both you need to buy that card twice.
* DIY. You get to say "I built this".
* startup time. Dervish is about 3 seconds, 2 of which is intentionally waiting for the FV-1 to finish it's reset routine before the ATTiny trespasses on the I2C bus. With the Z-DSP you get time to go & make a coffee whilst it warms up.
* last program persistence. Dervish will recall the program number you were using last time. Power on the Z-DSP & it'll go back to program #1. (I fully understand why they do this, you might have swapped cards).
* display control. Dervish lets you adjust the display brightness & have it blank after an adjustable period of time. Wish i could do that with the Z-DSP.
* schematics. You get them with Dervish when you buy the boards.
* tooling to easily manage program banks.
* Easy to program & to develop for. The #1 reason for creating Dervish. Without some hacking, the Z-DSP can't be directly used as a development platform. It assumes you have the Spin development platform. So to program code for the Z-DSP you need the Spin platform (£70 iirc), Numberz (£130), SpinASM running on Windows ($lots to MS). Dervish needs a simple £25 I2C interface, & is a one line "compile && upload" that you can run directly from your text editor on a nice OSX or Linux platform. Upload of a new program takes a couple of seconds.
mckenic
gbiz wrote:
* external switching of the program number. Again, not something i ever used with mine, and would require extra HP to implement.


I have not even begun to look at building mine but hope to order parts this/next month - this was a question I had.

I'll hopefully be replacing my Z-DSP (and have a Numberz so I can do side by sides if anyone wants) but switching is a HUGE thing for me. As the Z will be going I can afford the hp if there is a straight forward break-out solution?
gbiz
mckenic wrote:
gbiz wrote:
* external switching of the program number. Again, not something i ever used with mine, and would require extra HP to implement.


I have not even begun to look at building mine but hope to order parts this/next month - this was a question I had.

I'll hopefully be replacing my Z-DSP (and have a Numberz so I can do side by sides if anyone wants) but switching is a HUGE thing for me. As the Z will be going I can afford the hp if there is a straight forward break-out solution?


Depends on your interpretation of straightforward wink

If you just want a pulse to clock up or down the program number, then you could add a wire to each of the up/down pushbuttons. Take the wires to an external board. External board takes a modular logic level & converts it down to 3.3V suitable for the ATTiny. (The pushbuttons go directly into the ATTiny so you need that logic level conversion).

I'd use transistors to do the buffering & logic level conversions. Run them from the 3.3V supply on the control/display board, so no need for additional power.

You could probably do it in 2HP & a bit of stripboard. Put a 4-way polarised Molex connector on the expander board so you can easily detach it.
mckenic
we're not worthy

Thank you sir! Sincerely!
Could I use something like clamping diodes (say the 3/3.3v kind) to just use any trigger and have that cut off anything above the desired voltage?

I apologize if this is OT or for another discussion - my DIY knowledge stops when schematics etc come into it!

Thank you!
ipnoteca
gbiz thank you so much for the comparison!
gbiz
mckenic wrote:
we're not worthy

Thank you sir! Sincerely!
Could I use something like clamping diodes (say the 3/3.3v kind) to just use any trigger and have that cut off anything above the desired voltage?

I apologize if this is OT or for another discussion - my DIY knowledge stops when schematics etc come into it!

Thank you!


It's very much ontopic AFAIC.

If you were going to feed the signal directly into the ATTiny then yes you'd need clamping diodes, but if you use transistors there's no need for them. Thinking about this some more, the pushbuttons use the pullup in the arduino pin, so the transistor could probably use the same so no need for the wire to 3.3v.

You say you're not building it for a few weeks. Give me a day or so & i'll get something tested here.
mckenic
Thank you again gbiz!
I wont be building for 2 weeks at the soonest so PLEASE dont put yourself out but any advice would be very welcome!

I actually have a card with the 8 algos on it that include Greenwood and a recorder that depend on the knob positions of the Z-DSP for capture & playback, so in certain conditions they can act as a switch/vca for on/off state of the signal. It is only one patch I use it in but I demonstrated that patch at Sines & Squares and wrote about it for eContact - so its a fairly big patch for me :-)

You can have effected on, on, on, on-off depending on knob state/cv, on, on, on/off, on. So sequencing thru them (incrementally) is incredibly useful!

Thanks again!
Befacosynth
We just had a FANTASTIC hardcore-soldering and programming weekend with gBiz here in Barcelona!

Sumarizing the weekend:

39 Dervishes built and working.
A new customized bank file.
Loads of geeky conversations.
Plans for world domination.


Thanks a lot Graham!
TimoRozendal
Befacosynth wrote:
We just had a FANTASTIC hardcore-soldering and programming weekend with gBiz here in Barcelona!


awesome... I hope you chained all 39 and made a massive reverb w00t
gbiz
Haha. Thanks to Befaco for hosting it. Man, what a fantastic place to run a workshop & a fantastic bunch of people to host it Dead Banana beer!

It was impressive how many people had never tackled any SMT before. That didn't seem to put them off.

There is now one crazy person in Barcelona with (iirc) 8 Dervishes. More than i have here. rotfl.

Timo, i think the most we had running at one go was 4. We'd have probably created an instability in the space-time continuum with all 37 with that massive reverb. If the world suddenly gets kicked off it's axis, it's probably the Befaco crowd connecting them all up.




The eagle eyed might notice the odd one out in the pic posted by Befacosynth back there. Close up shot:



nanners

yes it works. there's actually 2 of them. Some impressive Dremmel work smile
Befacosynth
befacosynth wrote:
Plans for world domination.


gbiz wrote:
If the world suddenly gets kicked off it's axis, it's probably the Befaco crowd connecting them all up.


Thanks for the tip!

gbiz wrote:
nanners

Yes it works. there's actually 2 of them. Some impressive Dremmel work

You know what they say about bananas.

You should have taken a pic of the other bananized dervish. Pascual drilled a bit wider a thonkicon so the banana sticks in perfectly, then screwed the banana cap. So he get the disconnection on L IN and the beautiful look on nanas!!
pathein
Power to more dervish around nanners

Another thing which i have noticed bout dervish after playing around, the input circuit is actually pretty good as it can have signal in readily without clipping much, even with the input pot turned up till around 3/4

I have tried 3 different fv1 based effect modules, where it clips easily and having to use a passive attenuator to tame it before sending the signal to be effected. Dervish has since replaced all those!
gbiz
Thanks Pathein.

I initially tried added clamping diodes to the inputs, to keep the input signals between 0-3V. But that had an impact on sound quality. The guitar pedal crowd don't use clamping doides & don't seem to suffer from an excess of dead FV-1. The FV-1 design doc doesn't recommend protection diodes, so i opted instead to add more attenuation to the signal so it'll only just about reach the FV-1 limit with an input signal thats outside the eurorack 10V standard. I've driven one here way past 3V at its inputs without damaging it.

There's some algorithms that seem to benefit from driving it hard. We were playing with the cube distortion algorithm* at the weekend & that sounded best really overloaded. It sounded great with a 606/808 drum sample.

*The one from here. To compile it with my assembler you'll need to update it, as the previous version doesn't cope with "/" in either of the coefficients for LOG instruction. The old version spits out a couple of errors. I've put an updated version in the tree here. It also has a fix to support numeric values for LFO's in the various commands that use them. (SpinCAD generates code that uses numeric values, where as most hand written code uses the symbol equivalent (SIN0, RMP1 etc) which has always worked fine).
It'll get included in the next zipfile.
gbiz
Something else we discussed at Befaco over the weekend was a "performance" version of Dervish with just a 8HP panel & fewer banks (between 1 & 4). Designed to take your favourite few programs for use in a perfomance environment.

It'd use the same 8HP DSP board as now & would actually still contain 12 banks, but the control board would have no OLED & just one or two pushbuttons to cycle through the programs, so you'd only have access to a few of them.

As a starter on the front panel i'm suggesting we'd have left/right in/out jacks, 3 x CV jacks & 3 x control pots.

And yes, program number increment input jack too Miley Cyrus as that seems to be a popular request now Dead Banana (and no i've not forgotten i was going to come up with a solution for that, it's on the todo list)

Eg,
Should it have left & right inputs or just mono with the left hand input ?.
Should it be all tall trimmers, or bigger alpha pots (panel space vs ease of wiggling) ?

In the past i've used a simple CMOS up/down counter to change the program number, but if we go for multiple banks i'd probably go with a small AVR. That would then allow the program number to be persistent across power cycles.

Any thoughts & suggestions on this are welcome. Just remember it will probably only have 8HP.
mckenic
eek! thumbs up
gbiz
Oh and i'll probably do a 2HP panel+pcb for that up/down external clock solution.
pathein
gbiz wrote:
Oh and i'll probably do a 2HP panel+pcb for that up/down external clock solution.


this will be a great add on imho!

On other additional add on/expansion, will it be possible to have tap tempo function and the program number change be externally controlled via footswitch?

Was thinking that with hands being free up to do other wiggling while footswitches to control the tempo/patch changing might be performance friendly as well

edited: forgot to add in, regarding the patch changing function. From my guitar days, i have a delay pedal which does a delay "morphing" feature whereby changing the delay patches, it will do a gradual swell up or down to the next delay time parameter. I thought that was a really cool efx. That said, the delay pedal was using a bbd chip and i guess for digital based efx, it will be more of a stepped increase/decrease in the parameter values.

and on efx module, the other fv 1 based module i have, it has a cv input for patch changing, i find it less than ideal when using cv to change setting as the "clicking" sound of the delay time parameter changing ended up getting effected as well. Kinda distracting.
gbiz
Both are possible but they would need to generate a logic signal so you'd need power somewhere, either external, or from the module (which i'd prefer not to do), or have the signal from the switch pulled up in the module.

The easiest would be you just use a footswitch box with a battery in it. The battery would last a long time as there's no current draw.

Battery-less would need a bit of extra work, but it's possible.
gbiz
pathein wrote:

edited: forgot to add in, regarding the patch changing function. From my guitar days, i have a delay pedal which does a delay "morphing" feature whereby changing the delay patches, it will do a gradual swell up or down to the next delay time parameter. I thought that was a really cool efx. That said, the delay pedal was using a bbd chip and i guess for digital based efx, it will be more of a stepped increase/decrease in the parameter values.


It could be done in code. I can think of a couple of ways to do it. Either use a register loaded with a counter, or use the free ramp LFO in a similar way the tap period to delay time conversion is done now.

You wouldn't have a way to control the morph time between the frequency though unless you were willing to lose the feedback or damping CV.

pathein wrote:

and on efx module, the other fv 1 based module i have, it has a cv input for patch changing, i find it less than ideal when using cv to change setting as the "clicking" sound of the delay time parameter changing ended up getting effected as well. Kinda distracting.


This will be digital only. Using a CV based method would require a lot of extra work. I'm not even sure there's enough free code space in the AVR to support enabling the ADCs & converting a CV to a program select.
synchromesh
Befacosynth wrote:
You should have taken a pic of the other bananized dervish. Pascual drilled a bit wider a thonkicon so the banana sticks in perfectly, then screwed the banana cap. So he get the disconnection on L IN and the beautiful look on nanas!!


OK, now this bit is highly relevant to my interests. Do you have any more information or photos about this technique? I'd love to see some photos of this! Switchable banana jacks would be fantastic. hyper

And if you could bring an example to Superbooth in April, I could check it out there! screaming goo yo SlayerBadger!
ym2612
Another Dervish sprang to life last night! Got it working with no trouble at all. Between this and the O_C, I think my SMT skills have gone up a level.

I really like the variety of algorithms available in the default batch. I'll probably assemble a custom bank of my favorites. Some of the reverbs are really smooth. A couple of the banks don't seem to respond to CV much, if at all, but most work well.

I might try out SpinCAD sometime and see what I can build with regard to elaborate delay chains.
gbiz
Excellent screaming goo yo

That'll be the m16_24 bank that doesn't respond to CV. It's the first one to go usually after people have filled banks 9,10,11 `& are looking for a bank to overwrite.

Have you tried installing some of the extra banks in "banks/bank" ?. There's enough there to fill the EEPROM. The Dattorro one seems to be a favourite.

If you're going to use SpinCAD with my compiler, get the latest version of it. (here). I added a fix a few days ago for working with the machine generated code from SpinCAD, where the pots are referred to numerically (0, 1, 2 etc) & not by symbol (SIN0, RMP1 etc).

In SpinCAD, save the program as "ASM", then from the terminal shell compile the .spn file with "fv1-assembler" & upload the .bin file using "fv1-edit-eeprom". Once you get the hang of it, it takles seconds to upload a new try of a program. It'll save you the hassle of saving a compiled bank as hex, running hex2bin, bnk2bin & then uploading.

If you do try my compiler & get any errors from SpinCAD programs i'd be interested in the code & error. I don't really use SpinCAD so the compiler wasn't written for it's code. I wouldn't be surprised if theres something i've missed.
gbiz
As there seems to be a few more people looking to try using SpinCAD with Dervish, i've created a quick HOWTO. First draft is here, but i'll include it in the next zipfile.
Again, you need the latest version of my fv1-assembler (see previous post).

I've used the Oil Can Delay as an example. Quick crappy demo:
[s]https://soundcloud.com/gbiz/oily-delay[/s]
Virgil
gbiz wrote:
As there seems to be a few more people looking to try using SpinCAD with Dervish, i've created a quick HOWTO. First draft is here

Very helpful, thank you! :-)
gbiz
NP ! smile

If any bits of it need clarifying, or there's any typos or errors, please let me know. I don't use it much, so i'm very probably not going to pick them up.
gbiz
Whilst i'm uploading HOWTOs, here's a couple from the workshop:

bank-from-scratch.txt
extract-binary-from-bank.txt
gbiz
I finally got around to testing external clocking for program up/down last night. That works.

I've done a PCB + 2HP panel for people that want it. I'll get a test batch of those ordered later today.

I've also added a jack & pushbutton for manual setting of tap tempo. Connect the jack to CV2 on Dervish & use the pushbutton as a tap for the clock sync delays. (It only outputs 3.3v as that's the only useable voltage available from the control board, but it works).
pathein
SlayerBadger! yay, i love to get a set of the panel and pcb when its ready. Will the panel matched the old panel or with the newer one mentioned before?
gbiz
The matte black PCB panels won't happen any time soon unfortunately. The PCB FAB struggle to provide a consistent finish for them. So i'm going to stick with gloss black. I'll have to do these in both matte & gloss, as there's some people out there with matte main panels.

It's frustrating as another PCB panel i had them do in matte looks great (linky).
pathein
the matte one looks good from the link.

Oh well, the gloss one will match existing dervish panel for me, so its all good.
Befacosynth
gbiz wrote:
Something else we discussed at Befaco over the weekend was a "performance" version of Dervish with just a 8HP panel & fewer banks (between 1 & 4). Designed to take your favourite few programs for use in a perfomance environment.

It'd use the same 8HP DSP board as now & would actually still contain 12 banks, but the control board would have no OLED & just one or two pushbuttons to cycle through the programs, so you'd only have access to a few of them.

As a starter on the front panel i'm suggesting we'd have left/right in/out jacks, 3 x CV jacks & 3 x control pots.

And yes, program number increment input jack too Miley Cyrus as that seems to be a popular request now Dead Banana (and no i've not forgotten i was going to come up with a solution for that, it's on the todo list)

Eg,
Should it have left & right inputs or just mono with the left hand input ?.
Should it be all tall trimmers, or bigger alpha pots (panel space vs ease of wiggling) ?

In the past i've used a simple CMOS up/down counter to change the program number, but if we go for multiple banks i'd probably go with a small AVR. That would then allow the program number to be persistent across power cycles.

Any thoughts & suggestions on this are welcome. Just remember it will probably only have 8HP.


After using Dervish in live environment I would go for one bank only! Then choosing effects up/down with buttons with some light feedback. Like three leds to count up to 8 in binary smile
I found myself using just one program per gig. Might see myself changing and using maybe two or three of them on a gig. But definetly not more.
For home wiggling then I would go for the full-on OLED Dervish.

I used Dervish in an auxiliar send of my mixer, so dry/wet was not necessary. But if you are not using a mixer, dry wet might be a must. Maybe a stereo pot? meh
gbiz
Befacosynth wrote:
gbiz wrote:
Something else we discussed at Befaco over the weekend was a "performance" version of Dervish with just a 8HP panel & fewer banks (between 1 & 4). Designed to take your favourite few programs for use in a perfomance environment.

It'd use the same 8HP DSP board as now & would actually still contain 12 banks, but the control board would have no OLED & just one or two pushbuttons to cycle through the programs, so you'd only have access to a few of them.

As a starter on the front panel i'm suggesting we'd have left/right in/out jacks, 3 x CV jacks & 3 x control pots.

And yes, program number increment input jack too Miley Cyrus as that seems to be a popular request now Dead Banana (and no i've not forgotten i was going to come up with a solution for that, it's on the todo list)

Eg,
Should it have left & right inputs or just mono with the left hand input ?.
Should it be all tall trimmers, or bigger alpha pots (panel space vs ease of wiggling) ?

In the past i've used a simple CMOS up/down counter to change the program number, but if we go for multiple banks i'd probably go with a small AVR. That would then allow the program number to be persistent across power cycles.

Any thoughts & suggestions on this are welcome. Just remember it will probably only have 8HP.


After using Dervish in live environment I would go for one bank only! Then choosing effects up/down with buttons with some light feedback. Like three leds to count up to 8 in binary smile
I found myself using just one program per gig. Might see myself changing and using maybe two or three of them on a gig. But definetly not more.
For home wiggling then I would go for the full-on OLED Dervish.

I used Dervish in an auxiliar send of my mixer, so dry/wet was not necessary. But if you are not using a mixer, dry wet might be a must. Maybe a stereo pot? meh


Agreed. I've been thinking more along the lines of using stereo pots for the input & mix levels. You lose the flexibility to set the level/mix for each channel, but that gives a lot of extra panel space.

Should it be "stereo in + stereo out" or "mono in + stereo out" (with the single input going to both channels on the DSP) ?. I'm not sure.

One bank is certainly much easier to implement - no bank selection smile And binary for the LEDs is nice as they can reflect the state of the SEL lines. But i think i like the flexibility of 2 banks.

I was thinking about keeping the up & down program select buttons. To toggle between the 2 banks, hold both of them down for a few seconds. Use bi-colour LEDs for the program number & switch colour for the bank, eg red for bank0, green for bank1. Put the two buttons at either end of the LEDs, far enough apart that you're not going to accidentally switch banks in the middle of a live set. Obviously this would mean using a small AVR rather than a simple binary counter, but using an AVR also means that the program number is persistent across power cycles.
Befacosynth
gbiz wrote:

Should it be "stereo in + stereo out" or "mono in + stereo out" (with the single input going to both channels on the DSP) ?. I'm not sure.


Every day there are more and more stereo modules out there!
westlicht
Quote:
Should it be "stereo in + stereo out" or "mono in + stereo out" (with the single input going to both channels on the DSP) ?. I'm not sure.


Definitely go for stereo in/out, but normal the right input to the left. That's probably what the larger Dervish does anyway. Don't have the module yet, so I don't know smile
gbiz
westlicht wrote:
Quote:
Should it be "stereo in + stereo out" or "mono in + stereo out" (with the single input going to both channels on the DSP) ?. I'm not sure.


Definitely go for stereo in/out, but normal the right input to the left. That's probably what the larger Dervish does anyway. Don't have the module yet, so I don't know smile


You're right, it does smile

But it has individual control over the level for each side. This one will have to have a stereo pot, so both channels get the same level.
Dogma
Wrong question
gbiz
Dogma wrote:
Hey guys - I just traded a guy for a tip top zdsp - I want to burn cards, the z-burn is unavailable and horribly expensive if it was so can you point me in the right direction if the Another one?

All the googling and there is a dev board on the site d'oh! is this the way to go?


You're probably better off asking that on the TipTop forum.
consumer
Hi all,
I finally made some progress on these: In the attached pic, #1 was built about a week ago and #s 2 - 4 are fresh out of the oven. They look good after going over them with the loupe (except for the odd cat hair, which is a constant concern wink. Next up on my bench is SMD for the OLED pcbs (will not be in the oven), then THT for all and then a programming session over the weekend.

My only worry is R32 & R33: I assumed the text on the PCB for R32 was at the top of the resistor and R33's text at the bottom: An intuitive assumption - I hope it's correct. ...Though I may have f*&$%d something else up, too: We'll see once I start voltage-checking and/or programming, no?

On a totally spoiled level: I've gotten used to using Find commands to help me find components. It helps a lot. Graham, there is probably a way to print to PDF where it prints text as text that is searchable: That said, it may have been possible for me to run OCD on your panel prints that may have done the trick: I'll try that on my work computer with its 'fancy' Adobe and report back. Just a (spoiled) request.



Hopefully my next update is "Success * 4; Derivshes successfully divide by zero!" and you notice a tear in the space-time continuum in the DC exurbs.
Onward and zig-zag,
Dugan
gbiz
You've assumed correctly with R32 & R33.

They look tidy SlayerBadger! (R36 on board #3 is a bit skewed (the resistor by the 3 pin header on the RHS)).

I can't see any way to get text into the pdf that you could search on. The text on the silk layers is a bitmap, not ascii/unicode. It'd be interesting to see if OCR would work. I wonder if it'd get confused by the two bars between the pads on the 0603's. The bom output from pcb provides refdes & x/y co-ordinates but there's no way to tie that back into the pdf.
gbiz
Incase anyone else experiences this, to save potentially a lot of time spent checking things. I've seen a couple of builds now where the display board works fine all the time the programmer is connected. Remove the ICSP & it stops working.
Check the orientation of C8 & R13 on the control board, they should be parallel to the adjacent inter-board header. If you get these the wrong way round, the ATTiny will be in permanent reset unless the RST signal is held high (in this case by connecting an ICSP).
toneburst
gbiz wrote:
You've assumed correctly with R32 & R33.

They look tidy SlayerBadger! (R36 on board #3 is a bit skewed (the resistor by the 3 pin header on the RHS)).

I can't see any way to get text into the pdf that you could search on. The text on the silk layers is a bitmap, not ascii/unicode. It'd be interesting to see if OCR would work. I wonder if it'd get confused by the two bars between the pads on the 0603's. The bom output from pcb provides refdes & x/y co-ordinates but there's no way to tie that back into the pdf.


I've thought for a while it would be great to produce BOM linked to a photo of the board, setup so you could roll over an item in the BOM, and the corresponding component(s) on the PCB photo would be highlighted.

It would be fiddly to produce (as a web application, presumably- don't think this could be scripted in a PDF), but would be very convenient for anyone building the project.

I don't know about others, but personally, I seem to spend an inordinate amount of time when populating PCBs just searching the boards for the places components on the BOM should go. Anything that would speed up this process would save me a Lot of time!

a|x
gbiz
gEDA's "pcb" (the layout tool i use), has a bunch of different modes depending on command line arguments it's run with. One mode generates a bom from the given pcb file. An option for this bom mode is to include xy coordinates for each component. It's not something i've ever used before, i thought i'd take a look at it. This is a snippet of the output for the DSP board (which is 39mm x 106mm):

C19,"0603gb","100n",34.50,17.90,270,top
U8,"SO14","TL074",29.30,17.30,180,top
R13,"0603gb","100K",31.70,22.90,180,top
U3,"SOT23","LM-4040-10",36.57,81.80,0,top

Format is "RefDes, Description, Value, X, Y, rotation, top/bottom"
So C19 is footprint "0603gb", value 100n, located at 34.5mm x 17.9mm, rotated by 270 degrees & is on the top layer.
U8 is footprint SO14, TL074, 29.3x17.3mm, rotated by 180 & on the top layer.
etc etc

I add info to the BOM to include notes; SKUs for Mouser, Farnell etc. It's already quite cluttered, so i'm not sure i'd want to add coords there (unless people say do it), but i'd be happy to add another sheet that includes them if that would help people.

It's CSV format so easy to import into a spreadsheet. It's also trivial to use tools like sed to manipulate it, so for example to just include the reference designator, the x & y coords, & the layer. Maybe the value too.
gbiz
I got the 2HP remote program change ("updowntap") PCBs & panels in. It works as expected. Remote program change is actually quite good, i enjoyed playing with that last night smile
Tap works as i explained previously. As it's 3V you need to get the pot tuned to roughly the right level then it'll work.





Something i've been meaning to do for ages is get some acrylic windows made for the OLED cutout. This is my first attempt at getting acrylic laser cut, so I wasn't too sure about tolerances with both the cutout in the panel & with laser cutting. So got loads of slightly varying sizes. Far too many as it turns out. lol. I think there's probably one size that could be made to fit all panels. They press fit. So a slightly larger size can be used for either brute force fitting or gentle filing for the undersized cutouts. I'll have a play with this some more. Just to try them, I got clear & "natural translucent" in 3mm. To save $stupid shipping costs, I used the local UK Ponoko affiliate. Unfortunately they only do a subset of the thickness & colours that Ponoko do in teh US & NZ. The translucent is quite dark, probably too dark for most people. I quite like it though, works nicely in a dark room. 3mm thick means it sits proud behind the panel, but theres enough clearance in front of the OLED, so thats not a problem. (thanks to Altitude909 for tips on doing this)

Pics above show both, here's a close up of the clear.




I've just updated the tree & zipfile to include the BOM, schematic etc for the updowntap & attenuverter boards. I've also included some new scripts, fixes, HOWTOs etc. I've added a second sheet to the DSP board BOM with XY positions for the components. I also added a new bank of the Dattorro reverb with the mix cv replaced with adjustable pre-delay. That works really really well. Even on short decay times !! smile See the Changes file in the toplevel directory for all the changes.

Get the zipfile from here
mckenic
Oh wow! WONDERFUL work and great news!
Will the updowntap work with the original batch of PCBs?

Would you be doing a run of them and the window by any chance please?

Personally this is a game changer - Thank You so much thumbs up
gbiz
mckenic wrote:
Oh wow! WONDERFUL work and great news!
Will the updowntap work with the original batch of PCBs?


Yes, it'll work the same with all boards out there now. You'll have to solder wires to pads on the back of the control/display PCB, which is why i've put the header on the up/down/tap board, so you've got a way to disconnect it.

mckenic wrote:

Would you be doing a run of them and the window by any chance please?


That's the intention smile

I've got a few pcb+panel sets spare now if anyone wants one immediately (PM or email me please). I will be getting more in the next couple of weeks.

Now i know what sizes i do need to order for the windows i'll get a load of those. I just need to think of a way of getting those out to people without it costing a stupid amount in postage for a bit of plastic thats roughly 27x13x3mm.

mckenic wrote:

Personally this is a game changer - Thank You so much thumbs up


NP smile
Sven
Any Dervish builder in Europe?
satori
Hi all!
I have built my Dervish, the attiny is programmed using an Olimex AVRISP MK2 and the screen has some info and responds to button presses.
Now i'm trying to program the eeprom. I'm on a mac, everyhting goes smoothly until I get to the fv1-eeprom-host command. When I run that I get back 'Illegal Instructions: 4'
Any idea what is happening here? I'm basically computer illiterate.
gbiz
satori wrote:
Hi all!
I have built my Dervish, the attiny is programmed using an Olimex AVRISP MK2 and the screen has some info and responds to button presses.
Now i'm trying to program the eeprom. I'm on a mac, everyhting goes smoothly until I get to the fv1-eeprom-host command. When I run that I get back 'Illegal Instructions: 4'
Any idea what is happening here? I'm basically computer illiterate.


Are you running this on a 32-bit Mac ?.
satori
I'm new to Mac (it's my wifes) but i'm pretty sure it's 64bit.
I checked in System Information > Software > 64-bit Kernel and it says yes. So I assume it's 64 bit?
satori
I'm using the teensy and your program board also for the eeprom programming, I forgot to mention that
gbiz
OK. (The binaris are currently compiled for 64-bit, so you'd get a similar error if you were trying to run that on a 32-bit machine).

Can you open a fresh terminal window & run the following commands. Paste the output here.

sum $DERVISH/bin/fv1-eeprom-host
file $DERVISH/bin/fv1-eeprom-host
satori
Last login: Sat Apr 15 18:06:15 on ttys000
kobies-MacBook-Air:~ kobie$ sum $DERVISH/bin/fv1-eeprom-host
sum: /bin/fv1-eeprom-host: No such file or directory
kobies-MacBook-Air:~ kobie$ file $DERVISH/bin/fv1-eeprom-host
/bin/fv1-eeprom-host: cannot open `/bin/fv1-eeprom-host' (No such file or directory)
kobies-MacBook-Air:~ kobie$
gbiz
Ah, OK. I assumed you'd already got the profile setup. You've obviously not got that far into the setup yet. No problem.

What folder did you install the zipfile into ?.
satori
yeah I didn't set the profile up because of the error I got when running the fv1 command.
I've set a folder called 'Dervish' in Documents. Then I moved the contents of the zip into that folder.
gbiz
Thats fine, it's the order the doc tells you to run the commands in smile

OK. Try

sum ~/Documents/Dervish/DSP/bin/fv1-eeprom-host
file ~/Documents/Dervish/DSP/bin/fv1-eeprom-host
satori
Last login: Sat Apr 15 20:05:04 on ttys000
kobies-MacBook-Air:~ kobie$ sum ~/Documents/Dervish/DSP/bin/fv1-eeprom-host
1283 19 /Users/kobie/Documents/Dervish/DSP/bin/fv1-eeprom-host
kobies-MacBook-Air:~ kobie$ file ~/Documents/Dervish/DSP/bin/fv1-eeprom-host
/Users/kobie/Documents/Dervish/DSP/bin/fv1-eeprom-host: Mach-O 64-bit executable x86_64
kobies-MacBook-Air:~ kobie$
gbiz
Those are correct for the current binary. So what happens if you run

~/Documents/Dervish/DSP/bin/fv1-eeprom-host
satori
So I ran it straight after the other commands and it gave me the 'illegal instructions 4' line

Then i opened a new terminal and ran it again and got this:

kobies-MacBook-Air:~ kobie$ ~/Documents/Dervish/DSP/bin/fv1-eeprom-host
Segmentation fault: 11
gbiz
Odd. The checksum says that the binary is good, but these errors would suggest it's corrupt.

try running

uname -v


Also, try the following, (but i expect this will fail too)

~/Documents/Dervish/kwikfiles/fv1-eeprom-host-OSX
satori
kobies-MacBook-Air:~ kobie$ uname -v
Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64

And:

kobies-MacBook-Air:~ kobie$ ~/Documents/Dervish/kwikfiles/fv1-eeprom-host-OSX
Segmentation fault: 11
satori
kobies-MacBook-Air:~ kobie$ uname -v
Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64

And:

kobies-MacBook-Air:~ kobie$ ~/Documents/Dervish/kwikfiles/fv1-eeprom-host-OSX
Segmentation fault: 11
gbiz
Looks like you're on Lion.
Can you download this binary (compiled for Snow Leopard orwards). Save it into Downloads for now. Once you've downloaded it, run

sum ~/Downloads/fv1-eeprom-host-OSX-SL

If it returns "49080 18 fv1-eeprom-host-OSX-SL" run

~/Downloads/fv1-eeprom-host-OSX-SL\

Edit: reading that back, the important bit of the sum command is the numbers
satori
kobies-MacBook-Air:~ kobie$ sum ~/Downloads/fv1-eeprom-host-OSX-SL
49080 18 /Users/kobie/Downloads/fv1-eeprom-host-OSX-SL

kobies-MacBook-Air:~ kobie$ ~/Downloads/fv1-eeprom-host-OSX-SL
-bash: /Users/kobie/Downloads/fv1-eeprom-host-OSX-SL: Permission denied
gbiz
Sorry, i should have added you need to run this

chmod 700 ~/Downloads/fv1-eeprom-host-OSX-SL


then try the

~/Downloads/fv1-eeprom-host-OSX-SL
satori
Last login: Sat Apr 15 20:40:31 on ttys000
kobies-MacBook-Air:~ kobie$ chmod 700 ~/Downloads/fv1-eeprom-host-OSX-SL
kobies-MacBook-Air:~ kobie$ ~/Downloads/fv1-eeprom-host-OSX-SL
Usage: /Users/kobie/Downloads/fv1-eeprom-host-OSX-SL [-h] [-v] [-n nbytes] [-o offset] [-p pagesize] [-b byte] [-t tty] [-f iofile] -c command
Where
command is one of:
"R": read nbytes into iofile
"W": write nbytes from iofile to eeprom
"F": fill nbytes in eeprom with specified value, default is 0xff
offset: offset in desination eeprom. default is 0 (zero)
nbytes: number of bytes to read/zero/write
for writes, defaults to size of src file
for read & fill defaults to 0 (ie all 65536 bytes)
byte: value to fill memory with (default is 0xff)
tty: local tty device for usb connection to programmer
on OSX this will be something like /dev/cu.usbmodem12345
on Linux this will be something like /dev/ACM1
iofile: local file for content to write to or read from eeprom
pagesize: page size of eeprom to optimise writes (default 128)
this needs to match the target eeprom else writes may silently fail !
-v enables verbose output to stderr
-h prints this usage to stderr
Version: 1.2 230816
gbiz
nanners It works.

Now run this to move that new binary into the correct location

mv ~/Downloads/fv1-eeprom-host-OSX-SL ~/Documents/Dervish/DSP/bin/fv1-eeprom-host

And to test run
~/Documents/Dervish/DSP/bin/fv1-eeprom-host

You should get the same output. In which case you're good to go.
satori
Yes!!
Looks like it's all good smile
Thank you sir, for your help and lovely build documentation.
What a great community we have here.
gbiz
Cool. No problem satori. Sorry we had to go through that.
Good luck with the rest of it smile


Just for the record, the binary i've been shipping is built on Mountain Lion, with a current version of gcc, with default optimisations. That is clearly using an optimisation that's not supported on Lion, so to get this to work i've built it with optimisations supported on all versions of OSX back to Snow Leopard (ie i've added "-mmacosx-version-min=10.4").

Thats the only native OSX binary in the Dervish tree so it's the only one that needs recompiling.

I'll make this the default binary from now.
satori
This Binary worked a charm. My Dervish is now up and running smile
gbiz
nanners
jalpinist
Hi Gbiz.

You have any more PCB/Panels?

Thanks!
gbiz
Hi jalpinist, yeah, i've still got PCBs, panels, & the harder to source parts. Current prices & shipping costs etc are in the first post of this thread. PM or email me if you want to order them.
kogz23
Hi All,

This is a great effects unit.
I am having problems with my Attiny88 though.
I have built 2 successfully, but the third I am worried I have bricked the Attiny chip. When trying to program the Attiny fuses I get this response:
"
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.


avrdude done. Thank you."

I'm not sure what happened, as the same set up worked fine with the other 2 Dervishes. I have double checked all connections going to the Attiny from the ISP header, used a known good DSP board plugged into the Display board. I tried using an external 8Mhz oscillator into pin 7 of the Attiny. No joy. Same response from avrdude.
I'm worried somehow I turned off the internal Osc or something and bricked the chip. Any ideas?
Thanks in advance
Al
gbiz
You can't permanently disable the internal oscillator, that fuse setting is overridable. The only fuse setting that isn't easily resettable is the "disable SPI programing" one. But unless you cut'n'pasted really badly you're unlilely to enable that one.

It sounds to me like a problem with one of the ICSP lines to the AVR. You said you checked the lines from the ICSP header to the AVR. Did you actually check to the pin itself or the pad ?.
Check there's no shorts between those pins on the AVR (15, 16, 17, 29) & adjacent pins. With a DVM, check resistance between 0V & each of those pins, & compare with one of the working boards.

Check reset (pin 29) sits at 3V with the board powered up.

The OLED is the only other device that the SPI lines go to on that board. Check the soldering on the pads for the SCLK & MOSI pins (aka D0 & D1, pin 3 & 4) on the OLED. Again look for shorts etc.

It's obvious i know, but check you have 3V on pin 4 & 18. Also check that you have pin 1 in the correct location.

Do you have an oscilloscope ?. If so, try re-programming one of the working ones & compare the signals with the bad board. You should see activity on all 3 SPI lines (AVR pins 15, 16, 17), also on reset (pin 29).
gbiz
I've been messing about with ping pong programs the last few days, & just put this bank together.
The bank has 4 clock sync'd ping pongs, 3 basic ping pongs & one with dual delay taps each with their own delay time.
3 programs have a bit of wonkyness built in, slight variation in the delay times & some clipping for louder signals.

Here's a quick recording of one of the wonky clock sync'd ones.

[s]http://soundcloud.com/gbiz/wonky-2-1-pingpong[/s]
kogz23
Thanks!. Yes, you were right. I did a crappy solder job on C8, thus shorting Pin 29. So now Attiny is happy and up and running. Thanks for the help and a great project!
Al
gbiz
kogz23 wrote:
Thanks!. Yes, you were right. I did a crappy solder job on C8, thus shorting Pin 29. So now Attiny is happy and up and running. Thanks for the help and a great project!
Al


That figures. ICP uses that reset line to force the AVR into programming mode. Shorted as you had it there prevents that.

Glad you got it working. screaming goo yo
mmake
Hi! We managed to upload all the software, the modules seems to work as expected and sounds cool but...

1. LED not doing anything
2. D6 gives me about 0.6V pin2 the same, about 0.6V
3. Left channel dry not working
+ some other weird stuff with input level/mix

I started to think if i accidentally put a amp of sorts the wrong way because it's sort of shorting maybe? (the wrong voltages) And there is definitely something wrong with the input/mix.

Thanks for making this happen! Sounds awesome (in the right channel hihi )
gbiz
mmake wrote:
Hi! We managed to upload all the software, the modules seems to work as expected and sounds cool but...

1. LED not doing anything
2. D6 gives me about 0.6V pin2 the same, about 0.6V
3. Left channel dry not working
+ some other weird stuff with input level/mix

I started to think if i accidentally put a amp of sorts the wrong way because it's sort of shorting maybe? (the wrong voltages) And there is definitely something wrong with the input/mix.

Thanks for making this happen! Sounds awesome (in the right channel hihi )


1. If you mean the clip LED, that'll only light in normal operation when the FV-1 is clipping. It also seems to light when it's doing some internal functions such as it's reset. The best way to check if the LED is working is watch it when you power the module on. It should light for a second or so. If that happens, then it's working. The other way to get it to light easily is to pick one of the longer delays or shimmers, set feedback to 100%, & provoke some uncontrollable feedback. You need to drive it very hard to get an input signal to light it.

2. What component do you mean by D6 ?. There isn't one.

3. Can you be a bit more explicit & give more details on the fault you're seeing ?. ("weird stuff" doesn't really help me much hihi )

You say left dry isn't working. Does left wet work ?. If you put a signal into just the right hand input, with one of the stereo reverbs, do you get a wet signal from both the left and right hand outputs ?. If you do, does the left dry/wet pot fade in/out the left hand wet signal ?. (don't just use one program, try a few to ensure you have one that samples the signal at both left & right ADCs)

From what you say, the right hand channel is working. That says you've got all the op-amps correctly orientated.

That picture isn't really high enough resolution to see clearly anything obvious. The positioning of C30 doesn't look great.
tommy.york
What's the secret to getting the clocked delays (on the banks here) to correctly clock?

I'm sending CV3 a clock source from my Pamela's Workout. I'm sending it 16th note triggers from my Pamela's workout at the moment. What's weird is that changing that number - to 8th notes, quarter notes, whatever - doesn't seem to change the delay time, nor give me the digital artifacts from shifting the feedback to the new delay time and all that.

So basically, I don't think it's successfully reading my clock signal.

Anyone have any guesses as to what am I doing wrong?
gbiz
tommy.york wrote:
What's the secret to getting the clocked delays (on the banks here) to correctly clock?

I'm sending CV3 a clock source from my Pamela's Workout. I'm sending it 16th note triggers from my Pamela's workout at the moment. What's weird is that changing that number - to 8th notes, quarter notes, whatever - doesn't seem to change the delay time, nor give me the digital artifacts from shifting the feedback to the new delay time and all that.

So basically, I don't think it's successfully reading my clock signal.

Anyone have any guesses as to what am I doing wrong?


1st, the clock sync pulses have to be less than the max delay time for the program you're running (1sec apart for the mono delays, 500 msec for the ping pong I posted last week)

2nd, the clock sync pulse level at the cv2 input on the fv-1 has to swing between voltages that register as "on" & "off". To achieve this, you need to apply the correct amount bias with the control 2 pot depending on the p-p voltage of the sync pulse.
For unipolar clock pulses that are 0v to something you'll always need pot 2 less than halfway. For 0-10v you want it pretty much fully ccw. For 0-5v, I'd say at about 20%. For 0-3v, it's about 40%. (With 50% being the centre of travel).
For bipolar pulses, you'll need the control 2 pot somewhere around the middle of its travel.

If it can't sync, either because the time between sync pulses is greater than the max delay time, or it can't detect the pulses because the level is wrong, then it'll use the last valid sync time. If it has never managed to obtain a valid time then it'll use the hardcoded default - something around 300 msec.

For me, if it won't sync straight away & I know the clock frequency is valid, I have to adjust the control 2 pot.

You'll usually hear when it locks onto the sync clock as the delay time will slur from what it was using previously.

(Sorry for the delayed response, the log in issue prevented me from logging in to reply)
mmake
Here is hopefully a better picture of my dsp board.
http://imgur.com/a/HnQYE

I'm sorry, i meant D2. Initial testing (i'm no pro in debugging) showed me around +0.6V in pin2 and D2 which both should be in the -10V area. So i guessed maybe im shorting something there...

Weird == the mix level and channel level pots seem to have a life of their own but it might also be something related to normalising. I have to test it more. Only had little time to test the first time.

Thanks again. I tried finding bad soldering (it's not pretty for sure) but could not find any. All the parts look like they are getting proper connection to pads at least.


EDIT: I will do the testing with channels recommended by gbiz couple of posts earlier when next time at the module.
gbiz
No problem mmake. I couldn't be sure if you meant one of the diodes or U6 wink

That pic doesn't show D2 unfortunately. Can you check that it's oriented correctly ?. If it's the wrong way round you won't get any voltage on the pad nearest C1 & C3. Those diodes have a very faint line on them.
The line on D1 should be on the pad facing towards the FV-1.
The line on D2 should be on the pad facing away from the FV-1.

For D1 you should get 12V on the top pad & about 11.6V on the bottom pad.
For D2 you should get -12V on the top pad & about -11.6V on the bottom pad.

There's a diagram listing the voltage test points in the build doc. Until you have the same voltages, don't expect anything else to work. TBH, I'm surprised anything works without -12V. None of the audio path op-amps will work correctly, & you won't get a -10V reference so none of the CVs will work. So until you have working -12V, don't expect anything else to work.

The easiest way to check if you have a short is to put measure the resistance with DVM between 0V & the pad on D2 nearest C1/C3.
tommy.york
gbiz wrote:
2nd, the clock sync pulse level at the cv2 input on the fv-1 has to swing between voltages that register as "on" & "off". To achieve this, you need to apply the correct amount bias with the control 2 pot depending on the p-p voltage of the sync pulse.
For unipolar clock pulses that are 0v to something you'll always need pot 2 less than halfway. For 0-10v you want it pretty much fully ccw. For 0-5v, I'd say at about 20%. For 0-3v, it's about 40%. (With 50% being the centre of travel).
For bipolar pulses, you'll need the control 2 pot somewhere around the middle of its travel.

If it can't sync, either because the time between sync pulses is greater than the max delay time, or it can't detect the pulses because the level is wrong, then it'll use the last valid sync time. If it has never managed to obtain a valid time then it'll use the hardcoded default - something around 300 msec.


Bingo, got it sync'ing. And just to confirm, the appropriate tempo / clock input is in quarter notes (1ppq)? I think I hear it correctly but just want to be doubly sure.

gbiz wrote:
(Sorry for the delayed response, the log in issue prevented me from logging in to reply)

Sub 24 hours is pretty good. nanners
gbiz
tommy.york wrote:

Bingo, got it sync'ing.


Cool. What did you have to do, adjust the bias with pot 2 ?.

tommy.york wrote:

And just to confirm, the appropriate tempo / clock input is in quarter notes (1ppq)? I think I hear it correctly but just want to be doubly sure.


Depends on which program you use in the bank. In the "fixed+damping+interp" bank, the time between repeats is the clock divided by some number. In the code, programs 0 to 7 use these divisors:

;equ ntdiv 4/4 ;1/4 note
;equ ntdiv 2/3 ;1/4 triplet
;equ ntdiv 3/4 ;Dotted 1/8
;equ ntdiv 1/2 ;1/8 note
;equ ntdiv 1/3 ;1/8 triplet
;equ ntdiv 3/8 ;Dotted 1/16
;equ ntdiv 1/4 ;1/16 note
;equ ntdiv 1/6 ;16th triplet

(I think/hope the names against those divisions are correct, i got them from wikipedia. I'm no musician, they could be totally wrong hihi)

As program 0 is 4/4, the delay time is effectively the clock period.

You could (quite rightly IMO) argue that unlike with a guitar pedal, with a modular, having a divided clock is a waste of program space as you could do the clock division externally in hardware, so you'd only need a 1:1 program. So you could put program 0 into another mixed delays bank & free up a bank slot.


With the clock sync'd ping-pongs that i mentioned last week, there's 2 options.
1:1 has the ping & the pong delay times set to the clock frequency, so you get a repeat on each clock.
2:1 has the ping delay time as the clock frequency & the pong time as half the clock. (Yes, I probably should have called it 1:1/2).
mmake
I think my test power is broken. Using my rackpower, the voltages are as expected. Voltages are fine.

When i put audio to left OR right in, the right dry/wet and level works for right output.

When i put audio to left in, the right level and dry/wet works.

In all cases left dry/wet is either wet or no signal. It fades to silence.

Also weird is that if audio is going to left in, and i fade the left level, it does nothing. The right level controls the left signal.

seriously, i just don't get it

EDIT: If i put a different signal to both inputs, the right channel normalizes to both outputs. Meaning that the left signal is overriden. Maybe my soldering has gone wrong somewhere where the normalising takes place?
gbiz
mmake wrote:

When i put audio to left OR right in, the right dry/wet and level works for right output.

When i put audio to left in, the right level and dry/wet works.


Both these are correct behaviour.

mmake wrote:

In all cases left dry/wet is either wet or no signal. It fades to silence.


So basically you're just missing the left dry.

mmake wrote:

Also weird is that if audio is going to left in, and i fade the left level, it does nothing. The right level controls the left signal.

EDIT: If i put a different signal to both inputs, the right channel normalizes to both outputs. Meaning that the left signal is overriden. Maybe my soldering has gone wrong somewhere where the normalising takes place?


That will happen if you're using a program that reads from both the left and right inputs, (either a stereo one or one that sums them to mono & then writes to both outputs). That's possibly/probably confusing the issue. So, try this.

Power Dervish off.
Jumper the Int/Ext connector (J1) on the DSP board, to force the FV-1 to use it's internal bank of programs. (If you didn't fit a header there just use a resistor leg or even just a blob of solder to short the 2 pins).
Power Dervish on.

Select program 5 from the current bank. Which bank you're in is irrelevant here, as the FV-1 is in internal ROM mode. Internal program 5 is a test program that passes whatever is at the DSP inputs to the outputs. This is great for testing that the audio path is working as it should. Obviously as it's in internal mode, it *won't* be running the program that's shown on the display. Thats fine. Just make sure it's program 5.

Feed a signal into the left input.

Set both mix pots to 100% dry. The signal should be present on both outputs. The level control on each channel will adjust just the output level on that channels output.
Set both mix pots to 100% wet. You should get the same signal at the outputs. Again, the level controls will control the signal level at the respective output.

If you put a plug into the right input to break the normalisation, the left channel should continue to work, but the right should now be silent.


I suspect all you're missing is the left dry signal. I'm just not sure if it's pre or post the DSP.
mmake
J1, i dont get it

gbiz
See those 2 pads to the left of the FV-1 in that pic ?. Marked "IntFX" and "J1". That's J1 wink As you don't have header pins there (thats fine, you wouldn't usually need them), just short those 2 pads temporarily using a bit of wire.

When J1 is shorted, the FV-1 will load programs from it's internal bank, not from the EEPROM. The program it'll run is still selected by the ATTiny on the control board, so you still ned to select program 5 as usual, but the program the FV-1 will run will not be the one in the EEPROM, it'll be the one from it's internal bank. In this case, the passthrough one.
mmake
Right output works exactly as expected, the left one does nothing. No dry, no wet no nothing.
gbiz
So you've got no signal to the DSP nor passing through to the dry/wet mix, so the issue is probably going to be around R36, R37, U8 slot 2 (pins 5, 6, 7).

A short to ground at the pins of R13 or R41 that connected to U8 p7 could possibly cause it.

Also check R1 on the control board, the left level pot.
The left input jack is OK as the normallisation is working.
mmake
Bingo! Two of the legs on U8 had bad soldering. The legs didn't make proper contact. Now both of the channels work!

Thanks for helping me through this gbiz!

- very frustrating + w00t
sanderr2
Hi gbiz, I know I'm very late to the party but are there any PCBs and panels still available? Thanks! Rob
gbiz
Hi Rob smile

I'll be doing another run of PCBs & panels in a few weeks. Drop me a PM/email if you want to be added to the interest list.

I'm considering adding the option of pre-programmed AVR/EEPROM with the other "PITA to source" parts for this next run.

Also maybe boards with the SMD pre-assembled & programmed.
IImyment
Hi Gbiz,
depending on the time you'll need for the next batch, compt me in for a set, please.
gbiz
Sure IImyment.


The FAB confirmed the ship date for the next batch today. They should be with me in about 3 weeks.
Br193
I want one set how much will it cost?
gbiz
I (still) don't have parts for sale. Still working on it ... sigh.

The plan is to sell these from one of the online shops, & as i mentioned include pre-programmed chips etc to the kit. Before i do that i wanted to make installing the desktop environment that bit easier for people. So I've now got an installer script that does the majority of that. I need to re-do the docs to reflect that. I'm mostly there. It's all taking much longer than i'd like. All my fault.

For people with Windows put off because it's all Mac/Linux, I've just worked with someone on getting it all working in the MI Linux/Vagrant image, so i have a documented procedure for that now. (thanks Markthom beer! )

I've been looking into getting boards with the SMT pre-assembled , so they'd just need the TH stuff (display/pots/jacks/headers etc) added. Prototypes should be with me in a few weeks.

Sorry it's all taking longer than i'd hoped folks :(
Dragonsf
The fv1-eeprom-host.c compiles and runs fine (at first glance) under Msys64 (I just used cc fv1-eeprom-host.c -o fv1-eeprom-host).
gbiz
Dragonsf wrote:
The fv1-eeprom-host.c compiles and runs fine (at first glance) under Msys64 (I just used cc fv1-eeprom-host.c -o fv1-eeprom-host).


Thanks for giving that a try Dragonsf. I guessed it would probably work under Cygwin etc, but as i don't have Windows here, i've no way to test it.
Dragonsf
At the moment I'm struggling with the ArduinoISP, because I'm using Teensy 3.2 and can't upload you hex files. But AVRDude at least sees the ArduinoICSP.
gbiz
Why can't you upload my hex file ?. (The "31" hex files in kwikfiles work with 3.1 & 3.2).
Dragonsf
I didn't know that. I'll give it a try. OK, seems to work, but I want to get some feedback from the LED.
flab
Quote:
I've been looking into getting boards with the SMT pre-assembled , so they'd just need the TH stuff (display/pots/jacks/headers etc) added. Prototypes should be with me in a few weeks.


will that not increase the price of the project at the shops?
gbiz
Dragonsf wrote:
I didn't know that. I'll give it a try. OK, seems to work, but I want to get some feedback from the LED.


It is mentioned in the docs wink

Now there's more than just the 3.0/3.1/3.2, i think i'll symlink the "31" binaries to equivalents with "32" in the name for the next version.
gbiz
flab wrote:
Quote:
I've been looking into getting boards with the SMT pre-assembled , so they'd just need the TH stuff (display/pots/jacks/headers etc) added. Prototypes should be with me in a few weeks.


will that not increase the price of the project at the shops?


It'll have minimal impact on unpopulated PCBs.
Dragonsf
I need some recommendation regarding the soldering of the SMDs. Normally I use solder-paste first on the pads, then seat the SMD. After fixing one or more leg with an iron, I put the PCB on a preheated table and apply hot air from a blower from above.
But on the given PBS, the solder-paste doesn't stick, so I have to solder each leg individually with the iron and supply little bit of paste during that process.
I think, I can do better than this. Any advice is welcome.
gbiz
I use flux pen & wire solder with a fine iron tip, as i suspect do most Dervish builders, so thats not much help for you if you want to use paste. I know of other builders who have said they intended to use paste, & they've not mentioned that paste didn't adhere, so i have to assume it worked for them.

Have you tried cleaning the board ?. I've built a lot of these PCBs & it's not something i've had to do, but then i usually apply a coat of flux to all the pads before i start.

It almost sounds like you need more heat with the air to get the solder to flow. The iron is supplying additional heat & the solder flows with that.

One thought, is it all pads or just the ones with a thermal to the ground pour ?

(I know you'll hate me for suggesting it, but try flux + iron/wire solder wink )
Dragonsf
I'm applying the paste in a different step. I do it under a miscroscope and then I put the PCB on the preheated table. The paste, once successfully applied, flows as expected. But I'll give the flux first a try.
And I promise, not to hate anyone, who gives proper advise. For 2 or 3 legged bugs it might work, but centipedes are tedious...
gbiz
Dragonsf wrote:
I'm applying the paste in a different step. I do it under a miscroscope and then I put the PCB on the preheated table. The paste, once successfully applied, flows as expected. But I'll give the flux first a try.


Ah. So it's when you're applying it initially that it's not doing what you'd expect ?. If thats the case, i wonder if the pads are dirty. It migth be worth giving the board a wash with cleaner.

Dragonsf wrote:

And I promise, not to hate anyone, who gives proper advise. For 2 or 3 legged bugs it might work, but centipedes are tedious...


smile
Dragonsf
Your assumption is right. I tried to use flux (after cleaning the tracks) and the paste adhers a little bit better. I tried also the normal solder way, but the SMD got too much solder). So I stick to my paste.
Dragonsf
Actually the big SMDs are much easier to handle than the resistors and the capacitors. On the DSP PCB's pads, the solder-paste does stick.
bassinfected
Is it possible to get a pcb and panel set?
best
Dragonsf
If someone needs a steel soldering mask for both PCBs, I can offer an unused set for $50 + postage from Japan.
Dragonsf
I found one error in the BOM/Mouser list: the BOM calls for 3x22p, but Mouser list has 1x12p and 2x22p. Question: can I replace one of the 22p (which one) with the 12p, or do I need to order a 22p capacitor? (this would be a tedious task)
gbiz
12pF for C23, 22p for C30 & C31 is correct. The actual BOM itself is correct, as is the Mouser cart. So what you have there is fine.

I see where the confusion is from. The BOM xlsx file has 2 sheets - the BOM itself, & one with each component's XY co-ordinates that i've added to make it a bit easier to locate them on the PCB. This XY sheet is generated directly from the schematic which has C23 as 22pF. So I assume you're looking at the XY sheet. Go back to the BOM on the first sheet & you'll see C23 is 12pF.

The value of C23 needs to match the crystal. The Fox crystal in the Mouser cart requires 12pF, & theres a note in the BOM against C23 that mentiones this. I should probably put a similar note against C23 in the schematic & change it's value. I think the original crystal i used for testing required 22pF which is why the schematic has 22pF, then i switched to the Fox that requires 12pF. I updated the BOM but not the schematic.

Sorry about that.
Dragonsf
For one reason or another, there was no crystal item in the Mouser BOM. So I had to buy from a different source.
gbiz
Dragonsf wrote:
For one reason or another, there was no crystal item in the Mouser BOM. So I had to buy from a different source.


Bizarre. I have no idea how that got removed. A lot of people have built from that cart, it used to be in there. It's back there now.

I went through the rest of it & it all looks OK.
Dragonsf
I found one fox crystal at digi-key. It calls for 12.5pF, so I assume 12p will be good enough. I ahd to buy some replacement ites too, because of my clumsiness, they vanished into thin air.
gbiz
I doubt the 0.5pF difference will stop it working
I used 18pF in one build when i'd run out of 12pF & that worked.
Larrea
gbiz wrote:
Dragonsf wrote:
For one reason or another, there was no crystal item in the Mouser BOM. So I had to buy from a different source.


Bizarre. I have no idea how that got removed. A lot of people have built from that cart, it used to be in there. It's back there now.

I went through the rest of it & it all looks OK.


I was going to comment on this too. I ordered the cart without giving it too much thought. Built the PCBs--no problems otherwise--and discovered I was missing the crystal.

I don't have another Mouser order to fill shortly, but for those in the same boat, Tayda has them:

A-1592
gbiz
Larrea wrote:

I was going to comment on this too. I ordered the cart without giving it too much thought. Built the PCBs--no problems otherwise--and discovered I was missing the crystal.

I don't have another Mouser order to fill shortly, but for those in the same boat, Tayda has them:

A-1592


Oh man. That must be so frustrating, getting to the last component of a build to find the idiot who's responsible for the cart had randomly deleted something from it.

Sorry folks. very frustrating
Larrea
gbiz wrote:
Oh man. That must be so frustrating, getting to the last component of a build to find the idiot who's responsible for the cart had randomly deleted something from it.

Sorry folks. very frustrating


Naw, it's alright! hihi

I've had such a hectic summer anyway that it's been easy to deal with unfinished modules; haven't touched a knob in nearly 3 weeks!

I'm just getting back in to the swing of it this week.
Dragonsf
Larrea wrote:
gbiz wrote:
Oh man. That must be so frustrating, getting to the last component of a build to find the idiot who's responsible for the cart had randomly deleted something from it.

Sorry folks. very frustrating


Naw, it's alright! hihi

I've had such a hectic summer anyway that it's been easy to deal with unfinished modules; haven't touched a knob in nearly 3 weeks!

I'm just getting back in to the swing of it this week.

Same here.I'm also expecting some loss on the resistors (they like to jump out of the case into thin air).
Larrea
Dragonsf wrote:
Same here.I'm also expecting some loss on the resistors (they like to jump out of the case into thin air).


lol

Weirdly, in the 25 or so SMD modules I've built, I don't recall ever losing a single resistor!

I've been warned over and over again that it will happen, but so far, fingers crossed, good luck.
thelizard
Anytime you order a cart of Mouser, you'll want to round up the number of every resistor.

Mouser typically offers large price breaks at 10, 25, 100, etc. It's frequently cheaper to order 10 than 2. Plus, extras for safety and/or for the next project!
Larrea
thelizard wrote:
Mouser typically offers large price breaks at 10, 25, 100, etc. It's frequently cheaper to order 10 than 2. Plus, extras for safety and/or for the next project!


Right.

If a particular project only requires less than 10 of a given component, and I don't already have it, I always order 10.

Thankfully, I'm at a point where I have quite a robust collection of components now. There are a couple of modules in my queue for which I don't even have to order parts now. Sweet!

The downside to this is having to pay shipping from Mouser or Tayda for a relatively tiny order containing only the few parts I don't have; usually some kind of IC.
Dragonsf
thelizard wrote:
Anytime you order a cart of Mouser, you'll want to round up the number of every resistor.

Mouser typically offers large price breaks at 10, 25, 100, etc. It's frequently cheaper to order 10 than 2. Plus, extras for safety and/or for the next project!

I 100% agree. I aslo found out, why the crsytal wasn't on the list: the BOM had more then 1 Mouser ID in it's field, so it was ignored.
Dragonsf
Larrea wrote:
Dragonsf wrote:
Same here.I'm also expecting some loss on the resistors (they like to jump out of the case into thin air).


lol

Weirdly, in the 25 or so SMD modules I've built, I don't recall ever losing a single resistor!

I've been warned over and over again that it will happen, but so far, fingers crossed, good luck.

I don't know, what I'm doing wrong. Sometimes, when I remove the clear plastic strip, the SMD jumps out of it's case and goes somewhere else.
Larrea
Dragonsf wrote:
Larrea wrote:
Dragonsf wrote:
Same here.I'm also expecting some loss on the resistors (they like to jump out of the case into thin air).


lol

Weirdly, in the 25 or so SMD modules I've built, I don't recall ever losing a single resistor!

I've been warned over and over again that it will happen, but so far, fingers crossed, good luck.

I don't know, what I'm doing wrong. Sometimes, when I remove the clear plastic strip, the SMD jumps out of it's case and goes somewhere else.


I always anticipate that happening. I guard against it by keeping the bottom (non-clear plastic strip side; the 'pocket' side, in other words) down, pressed firmly against a finger of the hand holding it, then using the other hand, peel back the strip with a finger nail, while keeping downward presssure on it to keep the whole thing from moving. You just don't want it out in thin air without support. Then it's like a spring.

Hard to explain, but whatever I'm doing works. Haven't lost a single one yet.
Dragonsf
Your explanation nails it.Lucky you. But I'm getting better at it though. Do you have an advice, how to solder the electrolytic caps? I find the legs are way too short.
gbiz
Dragonsf wrote:

... I aslo found out, why the crsytal wasn't on the list: the BOM had more then 1 Mouser ID in it's field, so it was ignored.


Thats not why it was missing. If it were, you'd have purchased one of each SKU, not none of them.

I think i know why it's not there. A couple of months ago, i was creating the carts for the next set of boards, which have 2 carts, with one just for the headers. IIRC, i used the existing one as a template, removed the headers, but saved it as the wrong cart, the "live" one , not the new one. I realised my mistake, & re-added the headers but clearly didn't re-add the crystal.

I've developed a hatred for that Mouser cart/BOM/project tool. Dreadful thing.

The reason there's 3 crystals in the BOM. At the time i was creating it, i'd tried crystals from 3 different manufacturers, so i put them all in the BOM, but the cart only ever had the Fox one. Builders sometimes ask for alternatives, if the component in a BOM is on backorder, or they're buying from another vendor who doesn't stock that make. I kept those options in there, knowing that i'd tested them.
gbiz
For components like the 0603 ones, i'll put the strip over a bowl & peel the tape off, with the tape facing downwards.


How i solder electrolytics:

* Tin both pads, applying a bit more to the "first pad" (see next bullet) & cleaning any excess off from teh "second pad". I'll tin all the pads on the PCB in one go. Electrolytics are the last SMDs i fit.
* Decide which will be the first pad to solder. If it's a cap with one pad connected to 0V, typically the 0V pad will need more heat to solder. So do the non-0V one first to make it easier to get the cap in place. (I use the same method with ceramic caps across supply rails).
* Apply flux
* Apply more flux
* Rub the tabs of the cap in the excess flux
* Put the iron on the end of the chosen pad so the tinning melts but the iron tip isn't obstructing the pad. Slide the cap up onto the pad so the tab is right up against the iron. Remove the iron. Check the cap is aligned correctly & mostly flush against the PCB. re-apply the iron if needs be to move the cap. By putting this tab fully up on it's pad there's now enough of the second pad showing to be able to solder the other tab to it. It'll probably need more solder, you can do that later.
* Solder the second tab. If it needs it, apply more flux to help the solder flow. Keep the iron inplace until you see the solder flow. Remove iron.
* Visually inspect the cap & check it's flush against the PCB, correctly aligned & theres minimal play when you try rocking it gently from the top. Re-apply the iron if you have to make any adjustments.
* Leave the cap to cool. Go & do the others.
* Once they're all done, go back & touch up the solder on ones that need it. Again, use more flux to help get the solder to flow into the join.
* Remove the solder from the plastic surround at the base of the cap with wick or tweezers. Yes we all do it hihi
* clean off all that flux

That all sounds like a lot of work, but it's really not once you have it as a working method. That took way more effort to type smile

I try to go with the footprint with the largest pads possible for electrolytics to ensure there was some pad you can get an iron on. Same with the 0603 pads.
Dragonsf
No problems with the pads at all. Just the legs are so tiny...
So after finishing the soldering, I might share my experience:
1. solder all the small components like resitors and beads
2. next do the non electrolyte caps
3. next the diodes
4. the electrolyte caps
5. the ICs

This way, you don't have to worry about small gaps and solder 2 pads at the same time.
Actually the most time I spend was locating the component on the PCB under microscope. I'm using solder^paste, so soldering is quite easy (with flux in abundance).
gbiz
Dragonsf wrote:
No problems with the pads at all. Just the legs are so tiny...
So after finishing the soldering, I might share my experience:
1. solder all the small components like resitors and beads
2. next do the non electrolyte caps
3. next the diodes
4. the electrolyte caps
5. the ICs

This way, you don't have to worry about small gaps and solder 2 pads at the same time.
Actually the most time I spend was locating the component on the PCB under microscope. I'm using solder^paste, so soldering is quite easy (with flux in abundance).


I suggest a sequence pretty much identical to that in the build guide, with the exception that you fit the electrolytics last after all the other SMDs have been fitted & it's been given a thorough clean with flux remover & a visual inspection. That way you can give the board a good scrub without risking damaging the electrolytics, & it's easier to get in close up with a loupe. Then clean it again once the electrolytics are fitted.
Larrea
Dragonsf wrote:
Do you have an advice, how to solder the electrolytic caps? I find the legs are way too short.


gbiz has you covered better than I can. I can't say I followed his specific work flow, but was able to come up with a system that worked well enough.

I was surprised at how fiddly those electrolytics were to solder. The regular ceramic caps and other 0603 and 0805 parts are easier in comparison. But I managed fine.

I have encountered the occasional S1JL type diode that has similar issues, depending on which part I have and the pads.
Larrea
gbiz wrote:
I've developed a hatred for that Mouser cart/BOM/project tool. Dreadful thing.


I can't say I love it, but it works okay for me, but then I don't deal with it on the level of complexity you do I suppose.

One general tip for anyone who might be ordering parts for multiple circuits that I'm fond of is using the "Customer Part #" field to add a brief note signifying which circuit or board the parts are for.

So for example, in the case of the Dervish, I would enter something like "Dervish OLED," and then in others "Dervish DSP." You could just as soon write "SN 1011" for a Slightly Nasty PCB, and "NLC PoD" for an NLC Plague of Demons, all in the same cart, as I did for an order that included parts for all those. It all makes sorting out and managing all the envelopes and parts when they arrive that much easier, plus, for cross-checking old orders for whatever reason, it's nice.

gbiz wrote:
The reason there's 3 crystals in the BOM.


I ordered three from Tayda yesterday, but they're all the same--KDS. Just to have spares in case I break one...or two! cry
gbiz
Larrea wrote:

gbiz wrote:
The reason there's 3 crystals in the BOM.


I ordered three from Tayda yesterday, but they're all the same--KDS. Just to have spares in case I break one...or two! cry


Even though there's those warnings in Fox's product sheet about how fragile they are, i don't know of anyone who's broken one (... yet hihi )
julian
I still have not finished my own unit, but i realise there was not a photo of the metal front panel here, so ill spam you up with a photo of one of Graham's -




...and, yes, the "W16946...." was intentional. A reference back to the earlier pcb panels : )

Ill take a snap of a bare panel later, as there is some glare on the photo above which makes the text look blurred (it isnt in reality)
Dragonsf
The answer might be hidden somewhere, but one question: where to put the male headers and the female headers? I know, it doesn't make any difference, but what is the preferred way?
gbiz
The BOM for the DSP board has the female headers, so it is mentioned in one of the docs. I assume that's how most get built. The reason they're that way, there's almost no soldering that needs to be done on the bottom of the DSP board, but there's a lot on the controls board (jacks, pots etc). If you put the female headers on the control board, you run the risk of touching the plastic housing with the iron when soldering the jacks & pots, so put the pins on that one. No other reason than that.

But having said that, i built my first DSP board with the pin headers on it. No idea why i did that, i'd usually put the pins on the controls board. So now i continue to build mine that way so i can swap boards between modules. So if you see any pics of my boards that show the headers, they'll likely have the pins on the DSP board.

The holes are the same diameter on both boards.

So. Take your pick wink
Dragonsf
Had anyone tried the Spin_FV-1 from Aliexpress?
gbiz
I haven't. But personally, for relatively low volume specialist devices such as the FV-1, i prefer to source from an authorised reseller & pay the extra.

I know they're probably representative images & not the actual device you'd be sent, but take a look at the date code on the devices in the images on those Ali sales. The few i looked at were 2006, 2010, 2014. There's a thread on the Spin h/w forum where someone had issues with devices with an old date code sourced from a vendor in China.

(All the FV-1s in my Dervish partial kits have been sourced from Profusion, Spin's European reseller. The ones i bought from them last week have a 2017 date code).
Dragonsf
I completely agree what you're saying. But the postage from UK is very expensive, China is free.
gbiz
Free postage is no good if the thing doesn't work as expected wink

Spin have two APAC resellers ...
Mobius Audio: http://www.mobius-audio.com/audio_solution_fv1ic.html
Profusion have a HK office: http://www.profusionplc.com/parts/spn1001-fv1
Dragonsf
profusion asks GBP 49 for delivery to Japan (be it from UK or HK). That's ridiculous. I'm waiting for a quote from mobius.
Mobius Audio is even more crazy: Up to 100 pieces: $10.50, but $40 handling + $36 shipping.
gbiz
Wow. Yeah, thats crazy.
Dragonsf
Dragonsf wrote:
The fv1-eeprom-host.c compiles and runs fine (at first glance) under Msys64 (I just used cc fv1-eeprom-host.c -o fv1-eeprom-host).

Actually, it doesn't work. Running under Cygwin although works.
gbiz
Dragonsf wrote:
Dragonsf wrote:
The fv1-eeprom-host.c compiles and runs fine (at first glance) under Msys64 (I just used cc fv1-eeprom-host.c -o fv1-eeprom-host).

Actually, it doesn't work. Running under Cygwin although works.


What's not working ?. Something in the tty handling ?.
Are you recompiling for Cygwin ?.
Dragonsf
Something went wrong with the tty port (tcgetattr was getting an error 22). But after installing python on msys (pacman -S mingw-w64-i686-gtk3 mingw-w64-i686-python2-gobject mingw-w64-i686-python3-gobject), it's working. Very strange. So my statement has to be corrected: it's working, if everything's uptodate.
No recompiling, I used the same ewxecutable undwer cygwin.
gbiz
As you say, strange. I guess you had a mismatch somewhere between the termios header file & the c library. Installing python must have pulled in a newer, correct, library, or changed the library path to point to the one that Cygwin is using.
Wierd that it compiled OK in the first place.
Dragonsf
gbiz wrote:
As you say, strange. I guess you had a mismatch somewhere between the termios header file & the c library. Installing python must have pulled in a newer, correct, library, or changed the library path to point to the one that Cygwin is using.
Wierd that it compiled OK in the first place.

I agree, that my opinion too. Maybe the original dll had only the stub, which always returned -1 and the new one has the correct function.
Dragonsf
I could successfully program the EEPROM ,tested by reading the data back and compared to the original one and programmed the ATTiny88 using AVRDude (also verified OK). But the OLED doesn't light up.
And no effect at all.
Solution to OLED problem:
The OLED was simply defective. I replaced it with one of my stock and this one works.
The Effect is working (signale 7/8 at U7 look OK), but outputs 1 and 14 are square waves (very high amplitude).This is independ on the wet/dry settings.
After a reflow of U7, it seems to be working.
gbiz
If the dry signal isn't working on both channels but the wet signal post-DSP looks ok then both wet & dry signals are fine, so it's really just down to something in the mix section around U7 p1/p14. I doubt it's U7.

My guess is you've got an incorrect value resistor somewhere in the mix section. If you split the DSP board from the control board you can measure the resistance of the resistors in that area in-situ. Eg, measure resistance from U8p7 to J6p3 (PANEL_LOUT). That should be about 170K (24K + 47K + 100K). If it's not work back along that line of R41/R40/R20.

Check all the components in that area are oriented correctly.
gbiz
Dragonsf wrote:

After a reflow of U7, it seems to be working.


Oh good smile
sendepause
He guys, could use some help over here.
Took me some months but finally have on Dervish ready to program.
Thing is, i have no clue about programing / linux / etc etc. I very very basic knowledge of terminal usage...

So with the help of the Dervish desktop environment document, i started to install. But i already encountered the first problem.
I work on a mac, os 10.8.5
This is what i get, trying to run the installer script. I just followed what's in the document.

MacBook-Pro-van-Bart:~ bartwolff$ cd /tmp
MacBook-Pro-van-Bart:tmp bartwolff$ curl -O http://gbiswell.myzen.co.uk/dervish/dervish-installer.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 226 100 226 0 0 2395 0 --:--:-- --:--:-- --:--:-- 5512
MacBook-Pro-van-Bart:tmp bartwolff$ bash dervish-installer.sh ~/Documents/Dervish
dervish-installer.sh: line 1: syntax error near unexpected token `newline'
dervish-installer.sh: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">'
MacBook-Pro-van-Bart:tmp bartwolff$

soooo...help?!
pld
sendepause wrote:
MacBook-Pro-van-Bart:tmp bartwolff$ curl -O http://gbiswell.myzen.co.uk/dervish/dervish-installer.sh

Looks like the URL is http://gbiswell.myzen.co.uk/dervish/dervish-install.sh
So it probably downloaded an error page, which bash rightfully complains about...
gbiz
as pld says, try "dervish-install.sh", not "installer".
I'll update the doc.

Sorry.
sendepause
thanx for the quick answer guys, next problem....

what to do here? I get this:

MacBook-Pro-van-Bart:tmp bartwolff$ bash dervish-install.sh ~/Documents/Dervish
Usage: dervish-install.sh [-f zipfile] [-d dirname]
where:
[-d dirname] is optional directory to create as the default Dervish directory
default is /Users/bartwolff/Documents/Dervish

[-f zipfile] is optional location for the Dervish zipfile (supports local & http:// addresses)
default is http://gbiswell.myzen.co.uk/dervish/dervish-combo-latest.zip

MacBook-Pro-van-Bart:tmp bartwolff$
gbiz
Doc updated with the correct path to the installer script (And i've added -f to curl so it won't create a bash script with the 404 now).

Zipfile is updated.

Theres a few other updates in that zipfile. The combined blue PCB BOM now contains an alternative Mouser SKUs column for all the Panasonic components that seem to be going on backorder with long ship times. I've been updating the Mouser carts as people notify me or as i notice that components are on backorder, & i'll add the alternative to those columns. (I'm not going to keep teh green PCB BOMs updated, so if anyone is ordering the green PCB carts & they get a backorder component, take a look the blue PCB BOM for an alternative).
gbiz
Sorry. Use

bash dervish-install.sh -d ~/Documents/Dervish
sendepause
awesome...works! Thanx!!!!
gbiz
Sorry about that. This doc & the script is new (as you can probably tell). I do try & test this stuff. This is supposed ot make it easier to install !! very frustrating

(Online version of the doc etc etc updated again)
sendepause
Ahahaha, no problem. I do have a next hurdle to take:

When i do
dervish-avr-flash

From where do i have to do it? From the Dervish directory?
gbiz
It shouldn't matter where you run it from. It picks up where the Dervish directory is from the DERVISH environment valiable which gets setup by the installer script. The only thing you need to do if you've not done it since running the installer script is log out of teh terminal window, then open a new one.
Directly from the prompt you should be able to run dervish-avr-flash
sendepause
MacBook-Pro-van-Bart:~ bartwolff$ dervish-avr-flash
-bash: dervish-avr-flash: command not found
MacBook-Pro-van-Bart:~ bartwolff$

hmmmmm
gbiz
Did you close the Terminal window & open a new one ?.
sendepause
Yep...
gbiz
from the Terminal prompt, run these 2 commands

echo $DERVISH

grep DERVISH ~/.profile


The first should show /Users/bartwolff/Documents/Dervish

The second should show a few lines
sendepause
MacBook-Pro-van-Bart:~ bartwolff$ echo $DERVISH
shows nothing:



MacBook-Pro-van-Bart:~ bartwolff$ echo $DERVISH

MacBook-Pro-van-Bart:~ bartwolff$ grep DERVISH ~/.profile
export DERVISH=/Users/bartwolff/Documents/Dervish
export DERVISH_DSP=${DERVISH}/DSP
export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/lo cal/CrossPack-AVR/bin:/usr/local/bin:/Users/bartwolff/Documents/Dervis h/DSP/bin:${DERVISH_DSP}/bin
MacBook-Pro-van-Bart:~ bartwolff$
gbiz
From that Terminal, run "bash -l" (it'll just give you another prompt back), then try the "echo $DERVISH" again
sendepause
Weird no?

MacBook-Pro-van-Bart:~ bartwolff$ echo $DERVISH

MacBook-Pro-van-Bart:~ bartwolff$


Wish i had more knowledge of these things :-(
sendepause
Have to do the family thing now. Will dive into it later. Thanx for the help!
gbiz
I think i know whats hapening, you have another file there thats taking priority over the file that i put the Dervish setup into. As that other file is there, the one i put the Dervish setup into doesn't get read. (I'll need to add some code in the installer to test for this).

Run the following to show all the files in your home directory that start with ".bash".
ls -a ~/.bash*

It'll probably show you a few file names, including, I suspect one called ".bash_profile".
sendepause
Thanx for the awesome support! I will dive into it tomorrow.
Let you know the outcome.
gbiz
Sorry you're having to go through this sendepause. You're the first one to use this new installer script on OSX, besides me, but my OSX setup is a bit non-standard. A few people have used it with Linux, so i know it works there.

Thinking back, I think the very first couple of Dervish installs on OSX had the same problem when people edited the files by hand.
sendepause
ah no worries gbiz!
I'm very happy that you put your time and effort in it to guide my through the flashing!

So, you were right.
Now i got this back;

MacBook-Pro-van-Bart:~ bartwolff$ ls -a ~/.bash*
/Users/bartwolff/.bash_history /Users/bartwolff/.bash_profile
MacBook-Pro-van-Bart:~ bartwolff$
gbiz
OK. It's as i suspected. That .bash_profile prevents the .profile my script created from being used. All we need to do is move the text from one file to the other.

From a Terminal command line, run the following 2 lines. After you run each, it'll open a TextEdit window & return another command line prompt.

open -a TextEdit ~/.profile
open -a TextEdit ~/.bash_profile


Now you'll have 2 textedit windows appear displaying the contents of 2 the files. We'll cut'n'paste the Dervish setup from one to the other.
In the one from ".profile" cut (or copy) the 6 lines of text that looks something like the following.

########
# environment variables for Dervish eurorack module
# added by , 0
export DERVISH=/Users/bartwolff/Documents/Dervish
export DERVISH_DSP=${DERVISH}/DSP
export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/lo cal/CrossPack-AVR/bin:/usr/local/bin:/Users/bartwolff/Documents/Dervis h/DSP/bin:${DERVISH_DSP}/bin

Scroll down in the .bash_profile textedit window and paste it at the end. Now remove the last line, & change it to:

export PATH=${PATH}:${DERVISH}/DSP/bin:

Save both files and close the TextEdit windows. Close the Terminal window. Open a new Terminal window & try running "echo $DERVISH" again.
If that now prints something go ahead & try running dervish-avr-flash


If, as i suspect, there's no other text in the .profile file you can remove it. Run
stat -f "%z" ~/.profile

That'll just display the size of the file. If it shows "0" run

mv ~/.profile /tmp/dotprofile

That'll move it to /tmp. It'll stay there until you next reboot, so should you need to get it back you can do.


(I updated the install script last night to overcome this issue so anyone else running that will now have the Dervish setup into the correct file. It'll test for the presence of any one of the three possible files & use that if one is present. If not it'll use .bash_profile).

Edit: if you see spaces in that long PATH line, i think it's the forum code inserting them. They were pasted from a text file without them, so i know they're not in the original.
sendepause
Hurra, it;s working.....
but, now i get this... cry

MacBook-Pro-van-Bart:~ bartwolff$ dervish-avr-flash
DERVISH_TTY=/dev/cu.usbmodem2336181
tty is /dev/cu.usbmodem2336181
programming AVR fuses :

avrdude: Version 6.0.1, compiled on Dec 16 2013 at 17:26:24
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "/usr/local/CrossPack-AVR-20131216/etc/avrdude.conf"
User configuration file is "/Users/bartwolff/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.usbmodem2336181
Using Programmer : arduino
AVR Part : ATtiny88
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 64 4 0 3600 3600 0xff 0xff
flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.


avrdude done. Thank you.

an error occurred programming the attiny ... exiting
MacBook-Pro-van-Bart:~ bartwolff$
gbiz
Is Dervish powered on ?
sendepause
Doh!
Im not going to tell you what i did wrong.... (had something to do with clipping pin of a header & wrong header... d'oh! )

Anyway, attiny88 is programmed, hurrah!
Now, the next hurdle, the eeprom. No such file... confused

Last login: Mon Sep 18 20:33:11 on ttys000
MacBook-Pro-van-Bart:~ bartwolff$ cd $DERVISH_DSP
MacBook-Pro-van-Bart:DSP bartwolff$ dervtty
DERVISH_TTY=/dev/cu.usbmodem2336181
MacBook-Pro-van-Bart:DSP bartwolff$ img2eeprom -V -v -f images/default.img
no such file images/default.img
MacBook-Pro-van-Bart:DSP bartwolff$
gbiz
haha smile

Try
img2eeprom -V -v -f $DERVISH/DSP/images/default.img
gbiz
Ooops. No that won't work gbiz. I meant

img2eeprom -V -v -f images/default/default.img
sendepause
help

MacBook-Pro-van-Bart:DSP bartwolff$ img2eeprom -V -v -f images/default/default.img
ttyname & DERVISH_TTY not specified, trying dervtty
DERVISH_TTY=/dev/cu.usbmodem2336181
writing eeprom image images/default/default.img, tty /dev/cu.usbmodem2336181
iofile images/default/default.img: 65536 bytes
args:
cmd: W
progtty: /dev/cu.usbmodem2336181
iofile: images/default/default.img
pgsize: 128
nbytes: 65536
offset: 0
CR to start transfer:
sending HELLO: good
sending CMD 87: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
writing 512 128 byte packets
...................................................................... ...................................................................... ...................................................................... ...................................................................... ...................................................................... ...................................................................... ...................................................................... ......................
sending BYE: good
verifying write ... FAILED
read image file is /tmp/fv1-edit.HWZTW
MacBook-Pro-van-Bart:DSP bartwolff$
gbiz
It looks like the write worked.

Run this. It'll show how many places the files differ:

cmp -l /tmp/fv1-edit.HWZTW $DERVISH/DSP/images/default/default.img

Also could you run

md5 $DERVISH/DSP/images/default/default.img
gbiz
Sorry, that second one should be

md5 /tmp/fv1-edit.HWZTW
sendepause
i get this

MacBook-Pro-van-Bart:DSP bartwolff$ md5 /tmp/fv1-edit.HWZTW
MD5 (/tmp/fv1-edit.HWZTW) = be207fe107074f6d450ff7a681a41742
MacBook-Pro-van-Bart:DSP bartwolff$
gbiz
I just realised that if the files differ a lot, you'll be pasting a lot of lines. So i should also add, if the "cmp -l" fails on a lot of lines, just paste the first couple. Or the last couple.
sendepause
hmmmmm

MacBook-Pro-van-Bart:DSP bartwolff$ cmp -l /tmp/fv1-edit.HWZTW $DERVISH/DSP/images/default/default.img
1 0 200
2 0 100
4 0 21
6 0 300
7 0 24
8 0 22
9 0 40
10 0 300
11 0 273
12 0 222
13 0 177
14 0 376
15 0 2
16 0 104
17 0 177
18 0 376
20 0 15
22 0 40
24 0 15
25 0 77
26 0 337
27 0 4
28 0 244
31 0 4
32 0 246
33 0 3
34 0 63
35 0 2
36 0 104
38 0 40
40 0 15
sendepause
maybe a soldering error somewhere?
sendepause
weird thing is: i have to program the teensy again before i can upload.
like the connection is lost or something.
gbiz
What cable are you using between the eeprom-programmer & Dervish ?. Usually the first write would fail if it's a bad cable.

Yes check the soldering.

It looks like it's read all zeros. The compare is only showing bytes that differ in value, but the ones it's not showing (ie the ones that match) should be zero.

Can you try this. It'll read the eeprom, but it's a more verbose method
fv1-eeprom-host -c R -f /tmp/eeprom.img -t /dev/cu.usbmodem2336181 -v

If it doesn't return an error, run

md5sum /tmp/eeprom.img
gbiz
sendepause wrote:
weird thing is: i have to program the teensy again before i can upload.
like the connection is lost or something.


You shouldn't need to do that. If an EEPROM read or write fails, sometimes the Teensy will get stuck in a loop. If you try & run another EEPrOM access, it'll time out. Sometimes running the same command again will then work as the Teensy will reset itself. Sometimes the only thing to do is unplug it.

But i've never seen it where the Teensy needs to be reloaded each time. That is odd.
sendepause
my usb modem is usbmodem1896631
Could that be a problem? It differs from the one in this:
fv1-eeprom-host -c R -f /tmp/eeprom.img -t /dev/cu.usbmodem2336181 -v

When i change this i get:
MacBook-Pro-van-Bart:DSP bartwolff$ fv1-eeprom-host -c R -f /tmp/eeprom.img -t /dev/cu.usbmodem1896631 -v
args:
cmd: R
progtty: /dev/cu.usbmodem1896631
iofile: /tmp/eeprom.img
pgsize: 128
nbytes: 65536
offset: 0
CR to start transfer:
sending HELLO: good
sending CMD 82: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
reading 512 packets
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++
sending BYE: good

but then:
MacBook-Pro-van-Bart:DSP bartwolff$ md5sum /tmp/eeprom.img
-bash: md5sum: command not found
gbiz
Sorry, i meant "md5" not "md5sum" (thats the md5 equivalent on Linux).

I took that usbmodem device number from an earlier post of yours. It may well change each time you plug the Teensy in. That's normal. So don't worry about that.

what that does show is the reads & writes are fine. That suggests there isn't a problem with the I2C bus. If there was, it'd time out.

So. try running that "md5 /tmp/eeprom.img" See what that shows.

But yes, i think i's time to take a look at the soldering on the EEPROM.
sendepause
MacBook-Pro-van-Bart:DSP bartwolff$ md5 /tmp/eeprom.img
MD5 (/tmp/eeprom.img) = d51c4879832b21f249898a3facfd876d
sendepause
verifying write ... OK



we're not worthy
sendepause
Sooooo, some solder did fix the thing....

#### here starts the thank you post ####

gbiz
I have no words for this. This... i think this is the spirit of diy, you are the spirit of diy. I mean, how can i ever thank you for the time and effort you have put in troubleshooting with me, the programming n00b.

If i meet you some time, i buy you a couple of beers!!!!


Thank you!
sendepause
..and i certainly hope to meet you some day, so i can buy you some beers!!!!
gbiz
screaming goo yo

sendepause and thanks for helping debug that process. that really is so useful for me. Sorry that was a lot of hassle. Everyone who now goes through that doc without any problems owes you a beer beer!

But the question is, does it process audio ??
sendepause
well, let's solder some jacks and pots and find out!
fingers crossed...
w00t
sendepause
YES!!!!
nanners Rockin' Banana! It's peanut butter jelly time! SlayerBadger!
gbiz
\o/
sendepause
So what's better then a Dervish? Two working Dervish!
Programming the second one only took a minute this time Guinness ftw!

gbiz
Niiice screaming goo yo
sendepause
gbiz wrote:
Niiice screaming goo yo


all credits go to you! Thanx for the awesome module!

we're not worthy
NiteEagle
Finished and working well. All knobs and cvs were not working initially. Just a poor solder job on one of the legs of the LM4041. Thanks for the details in the build guide. It made troubleshooting the issue easy.

gbiz
NiteEagle wrote:
Finished and working well. All knobs and cvs were not working initially. Just a poor solder job on one of the legs of the LM4041. Thanks for the details in the build guide. It made troubleshooting the issue easy.


I'm liking that stealth all black look NiteEagle. cool
elcoco
Hi everyone, I just finished building my very own whirling dervish but for some reason it's not working great. The oled turns on and signal is passing through but if I listen to the wet output it's just noisy no matter what setting I put it on. I can hear that it's the input but just completely distorted. If I go back to dry I can hear the original signal just fine. I've done all the normal checks for power and ground and everything seems to be fine other than a 1.8k resistance between the test point on diode 2, but I've gone over the board looking for bridges and can't find any. Anyone have any tips on where to look for problems?
gbiz
Just to confirm, the output is fine dry but distorted wet for both channels, & this happens irrespective of whether the signal is fed into the left or right input ?.

Is the clip LED on ?.

Does the level of the distorted wet signal follow changes to the level of the input signal ?.

Do you hear any indication of the effect in the distorted output ?. So if you switch from a reverb to an echo, does the distorted sound change at all. Does it change if you, say, reduce the feedback/decay time to minimum & feed a single short-ish sound like a drum in ?.

Where you say "the OLED turns on", does it show the program details ?. Can you change banks & switch between programs ?.
elcoco
HI gbiz, the oled shows everything perfectly fine and changes in program change the sound a bit but it's always distorted. The led isn't on at all, I thought I had put it on correctly but I might not have. Even if the input is really low I still only get noise out but if its a delay I can hear delayed noise or if its reverb I can hear a longer noise.

*Edit: The sound is fine dry on both channels and noisy on both outputs no matter where I input
gbiz
The clip LED will light for a second or so when you power the module on. It will also light if the FV-1 has a problem, eg the program storage is random bytes, the clock/crystal signal is missing.

You can change banks OK, which suggests that the I2C bus is OK. The pullups for the I2C are supplied by the FV-1. If the FV-1 is seriously b0rked that usually hangs the I2C bus & prevents the ATTiny from changing banks. Also, that the sound changes when you change programs suggests that the FV-1 is mostly working.

First, check you've got all the components oriented correctly. Either use the DSP board topsilk pdf in the schematics zipfile, or there's a reasonably hi-res image of a board here

If they're all OK, inspect the soldering with a 10x magnifier. Rather than shorts, look for pads that don't have any solder. I'd start with the FV-1.

There's not much thats common for both channels that only handles the wet signal, basically just the FV-1 & the crystal. The dry signal passes through the same op-amps as the wet signal. As it's both channels, if it was an issue with one of the 074's i'd expect an issue with the dry signal too.

Check with no input signal you have about 1.65V on pins 1, 2 & 3 of the FV-1.

Do you have a scope ?. If you do, feed a simple waveform in on one of the inputs & check the signal at R4 & R5. Again with a program with short delay & feedback, check you get the same signal on R51 & R52. Either end of each resistor should be fine.

If you don't have a scope, as these are audio signals you can test these by listening to the signal at these points. Take a patch cable fed into a VCA etc so you can hear what on the other end. Wrap a bit of single strand wire around the other end of the patch cable. Touch the other end of the single strand wire to those resistors, & listen to the signal you have on each. It should sound much like the input signal. My guess is R4 & R5 will be ok, R51 & R52 will be distorted.
elcoco
I just checked and I'm getting 1.65v at all those pins and the output from r4 and r5 are looking good but I get nothing out of r51 and 52, and at the white side of caps 29 and 26 I just get a dc output which gets filtered out by the capacitors. I'm looking for mistakes in my soldering but it all looks ok, I'll keep checking though. Thanks for your help

*Edit: sorry I do get a signal from 51 and 52 but very low voltage and distorted. If I lesten to it it just sounds like what I'm hearing from the outputs.
gbiz
are you looking at these signals with a scope ?.

does the clip LED light when the module is powered on ?. (just need to check that it's working & that the FV-1 isn't trying to tell you something is wrong)

what voltages do you see on pins 25 & 26 of the FV-1 ?

check you have 3.3V on pins 6, 8, 23, & 0V on pins 4, 7, 11, 19, 24. Measure on the pin itself, not the pad.
elcoco
I get 2.3 on pin 25 and 3.3 at 26. The previous checks I did with the output were done with a scope. The LED doesnt turn on at all, I might have put it in wrong but I'm not sure and I don't have any solder braid right now to fix it. The 3.3 and 0v are looking good on all the pins.
gbiz
Pin 25 should be at 0V. Check the soldering on that pin. It's hardwired to the 0V rail, so it can't be any other voltage. It's directly connected to pin 24 which you've said is at 0V, so you should have the correct voltage on the pad for pin 25.

It sounds like the LED is the wrong way round. The anode/longer leg goes to the square pad.
elcoco
Thanks for all the help it was definitely the solder on pin 25, little bit of flux a some more solder fixed it right up. It all works perfectly now, thanks a lot for your help.
gbiz
That's great news elcoco smile
tetsutestu
So I finished the build and powered up the module and----bad luck! The clip light was on but the screen displayed nothing. I guess this is exactly what you were talking about in the build guide Graham. Sadly, I didn't think to get any extra crystals, so it's off to Mouser again.
In a week or so I'll replace the crystal and give it another go~~~
gbiz
tetsutestu before you do that theres a few other things to check. It might be something else. After putting that in the doc, i'm not aware of anyone who's damaged the crystal ... yet. But someone has to be the first wink

I assume all the voltages at the test points in the build doc are ok. If you've not done that, check them.

One reason the CLIP light is on, the FV-1 can't access the EEPROM because theres a fault on the I2C bus. That might be caused by the FV-1, the ATTiny, or the soldering on the pins on the header between the two boards.

First, give the soldering on the ATTiny & FV-1 a thorough inspection. On the FV-1 pay particular attention to pins 14 & 15. On the ATTiny pins 28 & 29. But don't restrict your inspection to just those pins. Check them all. Ideally with a 10x magnifier.

Check you have 3.3V on pins 4 & 18 on the ATTiny, 6, 8, 23 on the FV-1.

Inspect the soldering on the EEPROM & check the voltages on it. pins 1-4 & 7 should be at 0V, the others at 3.3V.

Check the soldering is ok on the I2C bus header pins between the two boards - pins 7 & 8, J7 on the DSP, 7 & 8 on J103 on the control board.

Check the voltage on the two I2C bus lines on the I2C programming header J3 on the DSP board. Both should be at 3.3V. Do this on the FV1 (pins 14 & 15), the ATTiny (pins 28 & 29).

Something else you could do, to give you an idea if it's the FV-1 or the ATTiny. Power off. Split the DSP & control boards, & apply power to just the DSP board. As your EEPROM is already programmed, the FV-1 should run happily by itself without the control board connected. Check the voltage on pin 2 of J7. This is the clip LED signal. If it's now at 3V, then the FV-1 is happy without the ATTiny, so i'd be looking at the control board for the cause of the issue. If the LED line is at 0V then the fault is probably on the DSP board. If one of the I2C bus lines wasn't at 3.3V, check it again, it might be OK now.


RS sell the crystals, so if it saves you having to make a special order to Mouser for one crystal, you could get them locally from RS in Japan. The RS part no for the Fox crystal is 547-6985.
tetsutestu
gbiz wrote:
tetsutestu before you do that theres a few other things to check. It might be something else. After putting that in the doc, i'm not aware of anyone who's damaged the crystal ... yet. But someone has to be the first wink

I assume all the voltages at the test points in the build doc are ok. If you've not done that, check them.

One reason the CLIP light is on, the FV-1 can't access the EEPROM because theres a fault on the I2C bus. That might be caused by the FV-1, the ATTiny, or the soldering on the pins on the header between the two boards.

First, give the soldering on the ATTiny & FV-1 a thorough inspection. On the FV-1 pay particular attention to pins 14 & 15. On the ATTiny pins 28 & 29. But don't restrict your inspection to just those pins. Check them all. Ideally with a 10x magnifier.

Check you have 3.3V on pins 4 & 18 on the ATTiny, 6, 8, 23 on the FV-1.

Inspect the soldering on the EEPROM & check the voltages on it. pins 1-4 & 7 should be at 0V, the others at 3.3V.

Check the soldering is ok on the I2C bus header pins between the two boards - pins 7 & 8, J7 on the DSP, 7 & 8 on J103 on the control board.

Check the voltage on the two I2C bus lines on the I2C programming header J3 on the DSP board. Both should be at 3.3V. Do this on the FV1 (pins 14 & 15), the ATTiny (pins 28 & 29).

Something else you could do, to give you an idea if it's the FV-1 or the ATTiny. Power off. Split the DSP & control boards, & apply power to just the DSP board. As your EEPROM is already programmed, the FV-1 should run happily by itself without the control board connected. Check the voltage on pin 2 of J7. This is the clip LED signal. If it's now at 3V, then the FV-1 is happy without the ATTiny, so i'd be looking at the control board for the cause of the issue. If the LED line is at 0V then the fault is probably on the DSP board. If one of the I2C bus lines wasn't at 3.3V, check it again, it might be OK now.


RS sell the crystals, so if it saves you having to make a special order to Mouser for one crystal, you could get them locally from RS in Japan. The RS part no for the Fox crystal is 547-6985.


Hi! Thanks for all of the solid and specific tips.
It turned out to be a false alarm. As you guessed, it was just a bridge across one of the pins. A careful reflowing took care of the problem and the module works like a charm.

Man, I can't tell you how happy I am with the Dervish Graham. I've only been playing with it for a few hours so far, but it sounds incredible.
Thanks so much for all of the support with the build--the build guide is wonderful!
Alas, I'm probably gonna have to get another Dervish soon so I'll be in touch smile
gbiz
tetsutestu smile

I think since i put the manufacturers warning about handling the crystals in the build doc, people take more care of them. So it's almost always something else thats causing these sort of faults.

I'm glad it's fixed too !. I programmed another batch of 50 AVRs & EEPROMs last week. It's a bit of a manual process & i don't make a very good robot. After about 45 AVRs i got distracted, lost my flow & wasn't sure if i'd missed one. I had to go back to the first & verify them all again. Dead Banana When i saw your post I had a nagging doubt that i'd somehow done something similar & yours had missed being programmed smile
toneburst
Just finished assembling the two Dervish boards.
Voltages all check out and the LED lights for a moment when the module is turned on, then goes dark (which I understand is a good sign). However, I'm failing to program my ATiny AVR (which was bought unprogrammed).

This is the output I get when I run dervish-avr-flash:

============================

dervish-avr-flash
DERVISH_TTY=/dev/cu.usbmodem3491301
tty is /dev/cu.usbmodem3491301
programming AVR fuses :

avrdude: Version 6.2, compiled on Jan 15 2018 at 21:39:34
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/usr/local/Cellar/avrdude/6.2/etc/avrdude.conf"
User configuration file is "/Users/alex/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.usbmodem3491301
Using Programmer : arduino
AVR Part : ATtiny88
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 64 4 0 3600 3600 0xff 0xff
flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9311 (probably t88)
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: erasing chip
avrdude: reading input file "0x07"
avrdude: writing efuse (1 bytes):

Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.04s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x07:
avrdude: load data efuse data from input file 0x07:
avrdude: input file 0x07 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0x07
avrdude: verification error; content mismatch

avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: efuse changed! Was 7, and is now ff
Would you like this fuse to be changed back? [y/n]
avrdude: safemode: Fuses OK (E:07, HgrinF, L:6E)

avrdude done. Thank you.

an error occurred programming the attiny ... exiting

============================

I can see it's failing to write, but don't know why.

Any tips?

a|x
gbiz
That's caused by unused fuse bits reading back as '1'.
replace the version of dervish-avr-flash (it's in Dervish/DSP/bin) with this patched version from here & try it again. It'll now print a warning rather than exit.
toneburst
Wow, super-quick reply!

Now I get:

=============================

avrdude: Version 6.2, compiled on Jan 15 2018 at 21:39:34
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/usr/local/Cellar/avrdude/6.2/etc/avrdude.conf"
User configuration file is "/Users/alex/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/cu.usbmodem3491301
Using Programmer : arduino
AVR Part : ATtiny88
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 64 4 0 3600 3600 0xff 0xff
flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9311 (probably t88)
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: erasing chip
avrdude: reading input file "0x07"
avrdude: writing efuse (1 bytes):

Writing | | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.04s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x07:
avrdude: load data efuse data from input file 0x07:
avrdude: input file 0x07 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0x07
avrdude: verification error; content mismatch

avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: efuse changed! Was 7, and is now ff
Would you like this fuse to be changed back? [y/n]

======================================

If I type 'n' and return, it end, and hangs if I type 'y'.

a|x
toneburst
I think that's exactly the same error as before, in fact.

Initially, after installing the patched script, I did get a different error, I think.

I didn't copy the output, unfortunately.

a|x
gbiz
Are you sure you copied the new file over correctly ? It's still trying to set the efuse to 0x07

It should go to (assuming you used the defaults) Documents/Dervish/DSP/bin

The other option is to just edit the file you have there (open it with TextEdit assuming you're on a Mac). remove the lines that say "exit 1" towards the bottom of the file.
toneburst
Ah, the path to attiny88_oled.hex was incorrect in the patched file, it seems.

I tried running the script directly, using the full path, with the updated hex file path, and it worked.

I still get the same error when I run dervish-air-flash, though. I'm not sure what's going on there. I guess the $DERVISH environment variable isn't setup correctly.

a|x
toneburst
Ah, the path definitions in my .bash_profile file was incorrect. I'd updated one line with the correct path, but missed another two instances. Corrected them, and now I can successfully flash the avr using dervish-avr-flash.

Excellent, and thank you again for the amazing support, gbiz!!

Now, to attempt the EEPROM write..

a|x
gbiz
Oh yeah, sorry, "Dervish-web" is my local directory for the web copy of the Dervish files. Glad you got it working. (I've corrected that online file).

When you run dervish-avr-flash, that will be run from DSP/bin which is in your PATH environment variable. It's prefixed by $DERVISH. If it was wrong it wouldn't work at all.

If you want to be sure you're overwriting it try this

cd $DERVISH/DSP/bin
curl -O http://gbiswell.myzen.co.uk/dervish/DSP/bin/dervish-avr-flash
toneburst
Good to know. Env paths are all now working ok, though. smile

Buttons and screen seem fine, too. Love those tiny OLEDs.

I guess there's no point running any audio tests until I've flashed the EEPROM.

a|x
gbiz
Talking of the attiny firmware. I've got a new version if anyone is feeling brave & wants to test it.
(probably not toneburst tonight hihi )

Dragonsf has been working on getting his Dervish into a synthesisers.com format panel. He's got it working with a 1.3" OLED (the same as o_C etc), and a rotary switch to replace the 3 pushbuttons. He's also patched the SSD1306ASCII OLED library to include inverse video & underline support. thumbs up

So the new firmware has some eye candy - inverted video for the highlighted option in the menus. Having this means the bank menu can now display an extra 2 characters of the bank name. Under the covers it also has wear levelling for the persistent param storage in the EEPROM (i'm not sure this is actually going to work as the EEPROM writes at 128byte pages), but it's there anyway.

The rotary switch support is compile time option, so it's either support for the regular 3x pushbuttons or the rotary.

To get the rotary code working we had to free up some RAM in the ATTiny. Just about all the const variables are now PROGMEM. I've ditched the Arduino "print" & "println" that the OLED library was using, & written a very basic equivalent thats a lot lighter in resources. There's quite a lot of code changes, so i don't just want to drop it in as the next default firmware. Some testing would be appreciated if anyone is up for it. It's working for me & Dragonsf, but thats the extent of the testing so far.

The pushbutton firmware image is here. If you do need to back it out, you'll need to wipe the persistent storage area in the flash. There's a "-R" option to the current version of fv1-edit-eeprom that will do that for you. Thats available here

gbiz
toneburst wrote:
Good to know. Env paths are all now working ok, though. smile

Buttons and screen seem fine, too. Love those tiny OLEDs.

I guess there's no point running any audio tests until I've flashed the EEPROM.

a|x


You can test the dry path audio.

If you want to test the DSP without any programs in the EEPROM, jumper the "Int/Ext" header pins on the DSP board (J2 iirc - it's the 2 pin one by the DSP, the one nobody fits). That'll enable the internal programs on the DSP. You can change the program number using the front panel switches, just the display won't show any detail about the program it's running.

In Internal mode, program 5 is basically a passthrough, the DSP passes it's input signal directly to the outputs. There's a slight delay but thats it.
The other Internal programs are (i think) ones from the Spin ROM bank in the default image.
toneburst
Cool.

Audio tests aren't looking so good, unfortunately.

I get dry audio through the L. channel, with L. Level pot turned up, but if I turn up the L. Mix pot, I get some initial noise (the kind go crackle you sometimes get with a dirty audio level pot) and an increasingly distorted version of the input signal until about 10:00, when silence.

On the R. channel, I get nothing passing through to the R. output at all. No crackle when I turn the R. Mix pot, just complete silence from the R. output.

Also nothing passing to the R. input from the L. input.

There's a general sense of heat coming from the back of the module, but I can't identify any particular component that's getting hot.

I guess I'll have to get the soldering iron our again tomorrow (too late now), but some tips on where I should start checking would be great.

My boards are the earlier, green ones, incidentally.

a|x
gbiz
What FV-1 program are you running to test this ?.

Do all the voltages at the test points measure correct values ?.

First thing i'd suggest is give it all a very thorough clean & inspection. Concentrate on the bottom of the DSP board, the FV-1 & below, especially around the bottom two 074's. They cover the audio. The upper one is for the CVs.

The R input is normalled to the L, so you should get the left dry signal out on both L & R outputs with just a signal on the L input. That "dry" signal passes through a couple of op-amps though.


Elcoco had a not dissimilar issue with a crackle in place of wet signal. Have a read back through the last page or so, that has some tips where to look for that issue.
gbiz
Sorry, i didn't see the last couple of lines, the email notification missed it off.

The regulators get very slightly warm in normal use. The rest should be cool.
Another thing, check the orientation of the components around those 074's. There's pics in the build guide that should be high enough resolution to check this, or use this one

Green & blue PCBs are identical in this area of the circuit.
toneburst
Right output seems to be working with some programs, so I guess there's no problem there.

Right input also seems to work, again, only with certain programs. I guess a lot of the programs are mono-in, only using the L. input.

So, it's looking like I've narrowed down the problem to the R. output!

I'll read up a few posts, as you suggest.

Thanks again.

a|x
gbiz
The dry signals don't pass through the DSP, they're not dependent on the program, so either they work or they don't smile

If you put a signal in on the left input & turn both mix pots to dry, you should get that signal out on both outputs. If you don't then theres an issue with the dry signal path for that channel. Depending on the program, as you turn the mix pots towards "wet" you should hear wet signal appear on both channels.

If you now swap the left input to the right input, turn both mix pots back to 100% dry, you should get dry signal out on the right output only. Again, depending on the program, as you turn the mix pots to wet, you should hear wet output on both channels. This depends on the program ...

how the DSP treats the input signals depends on what program you've got selected. There will be some that read only from the left input & output on both outputs. Some will read from both inputs, sum them & output on both outputs. A few are true stereo, they'll read both inputs & treat them separately (eg the "simple stereo" ping pong delay prog 2 bank 10).
toneburst
gbiz wrote:
What FV-1 program are you running to test this ?.

Do all the voltages at the test points measure correct values ?.


Yes, voltage and resistance tests both passed fine.

Quote:
First thing i'd suggest is give it all a very thorough clean & inspection. Concentrate on the bottom of the DSP board, the FV-1 & below, especially around the bottom two 074's. They cover the audio. The upper one is for the CVs.


Will do.

Quote:
The R input is normalled to the L, so you should get the left dry signal out on both L & R outputs with just a signal on the L input. That "dry" signal passes through a couple of op-amps though.


That doesn't seem to be happening. I was getting no pass-through to the R. output from the L. input, and don't seem to be getting any wet output from the L. out at all.

Quote:
Elcoco had a not dissimilar issue with a crackle in place of wet signal. Have a read back through the last page or so, that has some tips where to look for that issue.


I'll check the soldering around the FV-1 and the lower op-amps tomorrow. Hopefully a quick reflow will solve the problem(s).

Incidentally, could it be an issue with any of the electrolytic caps? I must admit, I'm not confident soldering these at all, and several of them look a bit messy.

Time for bed anyway.

Thanks again for all your help, gbiz.

a|x
gbiz
toneburst wrote:
gbiz wrote:
What FV-1 program are you running to test this ?.


It'd be useful to know what program you're using to test this with. As i say, they all work slightly differently hihi


Quote:
Quote:
The R input is normalled to the L, so you should get the left dry signal out on both L & R outputs with just a signal on the L input. That "dry" signal passes through a couple of op-amps though.


That doesn't seem to be happening. I was getting no pass-through to the R. output from the L. input, and don't seem to be getting any wet output from the L. out at all.

But you're getting wet signal out on the right output ?

Quote:
I'll check the soldering around the FV-1 and the lower op-amps tomorrow. Hopefully a quick reflow will solve the problem(s).


That usually fixes these issues.

Quote:

Incidentally, could it be an issue with any of the electrolytic caps? I must admit, I'm not confident soldering these at all, and several of them look a bit messy.


All the audio paths have electrolytics in them, so yes its very possible.

I think a lot of people would agree with you there. It would seem reasonable to expect them to be one of the most common failures. But i can't think of a single one. It's invariably a reflow of the op-amps that fixes it, which is odd as they're probably the easiest devices to solder.

I really should do a debugging table for the build guide with a list of what components to check for what input or output problem. If i get time in the morning i'll put something together. I'm sure i've got the majority of it already in emails i've sent to people.
toneburst
Good to know the electrolytics are usually OK. I generally dislike doing them, and on the Dervish DSP board, the components around some of them are pretty tightly-packed, too, which makes me even less confident.

a|x
gbiz
The electrolytics though you have a lot more pad to solder onto. You might not have a great connection & it might not be soldered the whole length of the pad, but it's got more chance of working than a badly soldered 0603 pad. And as people expect it to not work, they probably pay more attention to it. smile

I've started putting together a debugging tips chapter for the build doc. For now it's only in a work in progress text file. Once it's done i'll put it in the build guide all be nicely formatted. This should be enough for you to work out what components are in the various sections that comprise the audio paths. So rather than me dump another screenful of places to check, have read through this (I *think* it's mostly ok, though i can't guarantee it smile ) I'll continue adding to it today, but most of what you need for the audio paths is there now.
toneburst
The problem with the electrolytics is that the tab sticking out of the component that you have to solder is tiny, and it's very hard not to end up melting the plastic base of the cap while trying to solder the tab.

I'll have a good look at that doc when I get home. Thanks again for all your help, gbiz.

a|x
gbiz
A bit of melted plastic might look fugly but probably won't prevent it working wink

When i was laying this board out, i tried to make it as easy as possible to assemble these electrolytics. The pads are about as large as i can go for those footprints without causing issues for automatic assembly. (I had to reduce the footprint size of the two 5819's & the ATTiny88 on the current boards to keep the PCB assembly people happy).

I've also tried to orient them so you can get a soldering iron to both pins & have the ability to slide the cap in from one direction whilst keeping an iron on a pad from the other direction.


I've developed a way of soldering these that usually works for me, but might not for others. I thought i'd detailed it somewhere on this forum but i can't find it.
Theres a few tricks you can use to improve how the solder flows down the pad to reduce the amount of time you need to put the iron on the cap's legs. Pre-tin both pads. Keep the tinning on the first pad you're going to solder but remove it with some wick from the other pad. Then add lots of flux & make sure some of it gets onto the cap's legs. The flux will help the solder flow into the joint.
Put the soldering iron onto the outer edge of one pad, slide the electrolytic into place right up to the edge of the pad & up to the iron. That way there's a bit more pad for you to solder on the other pin. Once both pins are mostly soldered i go back & redo both, & often after applying more flux. Sometimes there's a pin that protrudes more than the other. I solder that one first, again so you can get more pad to solder the second pin.

If you're soldering the electrolytics that are across the supply rails, solder the pad thats on the rail first, not the pad connected to the ground pour. The ground pour tends to act as a heatsink & makes soldering it a bit harder. These are usually the ones i have most issue with.
toneburst
All working, now!

After reflowing solder on all the components for the L. channel dry > DSP and L. Wet > J6 P9, I realised that I had R43 and C53 soldered the wrong way round (ie horizontally, when they should be vertical).

Very stupid!

I desoldered them the in the right orientation, and now all seems to work as it should!

Along the way, I discovered that this minijack socket and breadboard jumper lead make a pretty good audio probe.



Thanks very much once again for your super-quick response, patient explanation, and excellent documentation, @gbiz. Definitely beyond the call of duty, and I'm very grateful.

I'm looking forward to playing with this great module!!

a|x
gbiz
screaming goo yo

You're not the first to do that toneburst. The silk screen isn't as sharp as it could be on those green boards, sometimes it's a bit confusing, so it's a reasonably easy mistake to make. Not that it helps you much but the blue PCBs are from a different FAB & the silk screening is much sharper.

Haha. I like the audio probe. That's a great use of a breadboard wire
toneburst
Good to know it wasn't just me that made that mistake. Apologies if it was mentioned on an earlier page. I'm afraid I had this project on the back-burner for a while, and haven't trawled back through the thread to catch up on the many posts I missed.

a|x
gbiz
No problem. It's not something that's common to one pair of components on the DSP board.

A much more common one was on the green control board, with the resistor & cap that generate the reset line for the AVR oriented incorrectly. With it built like that, it'd program & work as expected until the ICSP programming cable is removed then the AVR never gets out of reset. Blank display, no pushbuttons etc. Enough people did that one that i've separated those 2 components on the blue control board.
toneburst
Now that I have it fully working, I have to say this module is a Lot of fun!

I wish I'd made it up a long time ago.
jfberma
Hi all, hoping I could get some advice/help. I just finished my hardware build and I'm in the process of flashing the ATTiny.

The script seems to run successfully, but the end result is just snow/static on the screen (see attached). The EEPROM is blank, so I should be seeing the 0=======

Do you think this could be a crystal related issue? I suspect I was a little too rough with it when installing. I have extras, but wanted to know if this could be the issue or if I should be looking elsewhere.
gbiz
Oh that doesn't look right. I've not seen one do that before :(

It won't be the crystal. That's only used by the FV-1. The Clip LED is out which is a sign the FV-1 is OK.

It's either a problem with one of the lines between the ATTiny & the OLED, or a fault with the OLED itself.
The OLED is lit, so the ATTiny is trying to get it to display something, so the ATTiny is probably ok. You're correct that if the EEPROM is blank you'll just get the "0 =====". But if you press the select/menu button it should drop into the menu. Hopefully if you do that the snow will change pattern.

You've managed to program the ATTiny, so the SPI bus into/out of the ATTiny is OK. The OLED also uses two of these SPI lines, but although you've been able to program the ATTiny with them doesn't mean they're OK into the OLED.

The control lines to the OLED at the ATTiny are 10 (CS), 11 (DC), 12 (RST), (they're just to the left of the "U1" silk screen) & the SPI lines are pins 15 (MOSI/D1) & 17 (SCK/D0). Try buzzing those out pin to pin from the ATTiny to the top of the OLED, check they're all ok.

The pic is a bit dark, i can't fully see the soldering on the ATTiny. There also appears to be some white residue on the OLED pins around D0/Vcc/0V. It's probably worth cleaning that off. Is there more of that on the underside of the OLED ?.
The foil between the OLED PCB & the display itself looks ok from what i can see.
jfberma
Super appreciate the quick reply. I'm gonna give it a good cleaning and maybe a reflow and report back

Thanks!

EDIT: Clicking the menu button does seem change the "snow" although, it's still snow.
jfberma
progress! after a reflow and some cleaning i was able to get not "0===========", but "3===========". Clicking the menu button brings me to what seems to be the correct menu.

Not sure if this is correct, but I'm gonna try to load up the EEPROM now and see how it goes
jfberma
Success! Everything seems to be working as intended! Time to have fun and then build a second one. Thanks for the help! This is truly a killer module
gbiz
Excellent smile

That "3 ====" you saw is fine. Thats what you'd see from program 3 in a bank that has no text associated with bank name, program name or the controls. At some stage when the screen was random you must have pressed the up/down buttons changing the program from 0 to 3. That change would have been saved, & when you next powered on the module on it'd revert to 3. A newly built module would start at program 0, hence the "0 ===="

I appreciate it's a bit late now, one thing i forgot to say when i suggested cleaning the pins at the top of the OLED. Be careful using too much solvent around there. The OLED glass is held on the PCB carrier with a double sided sticky foam pad. The adhesive on the pad will dissolves in the solvent & the OLED glass can lift or move diagonally. I've done it hihi

Good luck with the build of the second one smile
mqmq
Hi ! I just finished building one and WOW it's incredible ! Even though I'm running into a couple of issues : The 3rd knob behaves in reverse and the right input is very quiet. When I input a signal on the left input I have to turn the right level pot all the way up just to hear a faint dry signal. It's almost like the normalizing isn't working here. Hope that makes sense smile
gbiz
If you think it's incredible now, wait until you hear it when it's all working grin

With all the following, check the voltage on the device leg/tab rather than the pin

3rd knob reversed:
Check your soldering around C33, R18, R25, R23, U9 pins 1,2,3, U10 pins 7,8,9.
check you have 1.65V pin3 U9
check you have 0V on pin5 U10
If it's working, with the knob fully CCW check you have roughly 3.3V on p7 U10 & 0V on p1 U9.
With pot3 fully CW. You should now have 0V on p7 U10, & 3.3V on p1 U9.


Right input level:
What happens when you feed the signal into the right input only ?. Do you get any dry signal out on the right output or is it as faint ?. (You won't get a dry signal out on the left, thats fine).
With the signal only in on the right, do you get a wet signal on both the right and left outputs ?. (Pick a stereo effect for this - the simple stereo pingpong would be ok)
jfberma
Are there any of the 2hp expanders still available?
gbiz
jfberma yes i've got 2HP UpDownTap & 4HP attenuverter expanders.
PM or email me.
mqmq
gbiz wrote:
If you think it's incredible now, wait until you hear it when it's all working grin

With all the following, check the voltage on the device leg/tab rather than the pin

3rd knob reversed:
Check your soldering around C33, R18, R25, R23, U9 pins 1,2,3, U10 pins 7,8,9.
check you have 1.65V pin3 U9
check you have 0V on pin5 U10
If it's working, with the knob fully CCW check you have roughly 3.3V on p7 U10 & 0V on p1 U9.
With pot3 fully CW. You should now have 0V on p7 U10, & 3.3V on p1 U9.


Right input level:
What happens when you feed the signal into the right input only ?. Do you get any dry signal out on the right output or is it as faint ?. (You won't get a dry signal out on the left, thats fine).
With the signal only in on the right, do you get a wet signal on both the right and left outputs ?. (Pick a stereo effect for this - the simple stereo pingpong would be ok)


Thanks ! Knob 3 is fixed, I reworked the soldering and it's fine now, all voltages are correct and the knob know acts like it's supposed to !

Right input : when I feed a signal in the right input I get nothing out, no dry nor wet signal. If I crank the level knob all the way up I have a very very faint noise.
Another thing I noticed is the clipping led never lights up seriously, i just don't get it
gbiz
As it sounds like you don't have any wet signal on the left output with an input on the right , it's probably an issue with the right input signal before it's fed to the DSP. That's R48. R49, pins 1,2,3 U8.
Also check pin 1 of J4 & the corresponding pin on the control board.
Also check the soldering on the right input level pot on the control board.

If you do get wet signal on the left output with a dry signal on the right input then the fault is on the right output stage - U7 p12, 13, 14, R21, R7, J6 p1.


The Clip LED should light for a second or so when you power the module on as the FV-1 goes through it's reset routine. If it doesn't you've got the LED the wrong way round.
The other times it'll light is either when the FV-1 has an issue (eg a bad program), or if you're overloading it - a *lot* of feedback in an echo or one of the longer reverbs. But the signal is usually distorting before then.
mqmq
Thanks so much ! Yes my soldering was the culprit... I guess I need to stop past a certain hour haha, even the LED was the wrong way around. Now I can fully enjoy that BEAST you made !!
toneburst
mqmq wrote:
I guess I need to stop past a certain hour haha


I usually only get started about about 10:00pm wink

a|x
mqmq
Did a small jam to take the Dervish for a spin, here it is in chorus+reverb on Chord Organ and Elements, sweet !!!! : https://www.instagram.com/p/BebJ83EHb9m/
gbiz
Nice mqmq smile
I think thats the first white Dervish panel i've seen.
mqmq
Thanks gbiz ! It's not actually white but yellow-ish wood !


gbiz
love

Sorry mqmq, with the lighting on that video i couldn't it see that clearly. That looks fantastic !. It's definitely the first wooden Dervish panel i've seen.
It looks like you even got the acrylic window to fit applause
mqmq
Haha thanks but sadly I couldn't make the acrylic window fit, not by far, not even half a millimeter on each side seriously, i just don't get it . But I'm not giving up !
gbiz
Oh :(
From that image it looks like theres's a reflection at the top of the screen.
Is the window too big ?.
mqmq
Yes I think I cut the window too big, as you can see on the picture there is space on the left and top left. But I have leftovers clear acrylic sheets I'll try cutting another one

gbiz
I guess if you used the dimensions from my FPD file, the dimensions for the cutout are for a PCB or metal cut to size. The width of the laser will add that small increase in size.

Do you have your own laser cutter ?.
mqmq
gbiz wrote:
I guess if you used the dimensions from my FPD file, the dimensions for the cutout are for a PCB or metal cut to size. The width of the laser will add that small increase in size.

Do you have your own laser cutter ?.


Yes that what I thought. Also first time using this kind of wood so I wasn't sure about the settings.
I do not own a laser cutter but we have a great network of FabLabs in my city which is just awesome This is fun!
gbiz
Thats great you have easy access to tools like that.

These windows with Dervish are my first attempt at getting something laser cut. Using some tips that Altitude909 kindly gave me, plus the FAQ at the FAB, I got a prototype sheet cut with a bunch of different sizes above & below what i thought i needed. In the end, the size of the PCB panel cutout plus the radius of the laser plus a small amount to make the window a tiny bit oversized is perfect.
Boogie
Hi,
as I'm fresh on this thread, and didn't read all 25 pages,
Is there a summary of the effects available ?
Are you using the built in effects, or did you add some own programs ?
If so, which ones ?

thanks !
gbiz
There's a link in the OP to a page that has links to all the docs wink
That page includes a link to this list of the programs in the default image.

Some of the programs are from Spin, some are from programs published on forums, & some i've written. The combo zipfile includes the source for all those programs, & there's a file in the same directory as that list that details the author & where you can get the original source for each.

The default image is intended as just a start. I also provide an FV-1 assembler & a bunch of tooling that makes it relatively easy for others to create their own programs or modify the existing ones, & customise their banks.
gbiz
Only about 10 months after i said i'd do an 8HP "live"/"performance" version of Dervish, i finally got around to getting it done ...

µDervish uses the same DSP board, just a different control board. So in theory it can access all 11 banks/88 programs as it's OLED sibling does. In practice it's probably sensible to limit it to either one or two banks, but it's tuneable.

The "Prog Adv" jack allows an external clock pulse to increment the program number.

It also has banana/Thonkiconn combi jack footprints. It's peanut butter jelly time!

This is prototype PCB/panel. I'll get some nicer ones done after the CNY holidays are finished. And yes, i'll sort the labels on the controls out.

@realwiggler
Loving this in 8hp! Clap
mutedial
I’ve been meaning to ask about the mini dervish, it looks great! It's peanut butter jelly time!
pathein
lovely 8hp!
Befacosynth
gbiz wrote:

It also has banana/Thonkiconn combi jack footprints. It's peanut butter jelly time!


The opressed banana minority is holding a party in your honor!!
random:user
It´s been a while.
Still loving my dervish love real workhorse that thing. Only thing that i am missing is some kind of tape echo/delay.
Does anyone know of a program that might emulate that?
Would be really great so i can retire my delay stomp box hihi
gbiz
Great to hear you're still loving your Dervish random:user smile

I many hours trying to get a tape delay sounding good. Haven't succeeded yet. Getting that tape saturation sound is really really hard. My current efforts are the drv102 programs in the current image (the reverb in those isn't mine, its someone else's code that i've bolted on). TBH I think it probably sounded better in a previous version of the code a year or back when it had a bit more HPF in the feedback. Maybe i'll have another go at it for µDervish.

If someone got the Space Echo right for the Fv-1 they'd be selling carts for the Z-DSP for and then some.

There is a binary only bank of emulations of 1960's tape echos that are available online for download for an FV-1 based guitar pedal. They will run on Dervish, you just need to convert the binary bank into a Dervish bank (basically take the binary bank, & add the text for the bank name, the program names & the pots. I did a HOWTO on how to do this (linky)). The source code for these programs isn't available online (afaik), so i don't include it with Dervish. Whilst the download isn't dodgy (it's not at some warez site), I'd prefer to not link to it from here but if you put "fv-1 tape echo" with your favourite online search engine should give you some ideas of what to go looking for. There's a video of someone using the guitar pedal on youtube.
gbiz
random:user i suddenly thought you possibly have an old EEPROM image installed. Have you tried the current one ?. (this file contains a list of whats in the current image).

Also, if you want to try & create your own, i think i saw there's a tape delay function block in SpinCAD.
toneburst
Nice mini version. @gbiz!

I might be tempted by one of those, too. Can never have too many FX modules..

a|x
toneburst
mqmq wrote:
Thanks gbiz ! It's not actually white but yellow-ish wood !




That plywood panel looks great, @mqmq!

a|x
Digital Larry
gbiz wrote:
random:user
Also, if you want to try & create your own, i think i saw there's a tape delay function block in SpinCAD.


Sorry to say there's no such thing. In general, I tried not to offer "canned" patches as blocks, although with reverbs it's almost unavoidable. Emulating some analog gear boils down to figuring out what aspects of it you really want to emulate and then trying to piece that together from the smaller blocks.

Real tape delay would probably include delay (of course), high and low frequency filtering, noise, saturation (of a sort that the FV-1 might or might not do easily) and compression. I don't have any of that old funky gear so I'm just guessing.
gbiz
Digital Larry wrote:
gbiz wrote:
random:user
Also, if you want to try & create your own, i think i saw there's a tape delay function block in SpinCAD.


Sorry to say there's no such thing. In general, I tried not to offer "canned" patches as blocks, although with reverbs it's almost unavoidable. Emulating some analog gear boils down to figuring out what aspects of it you really want to emulate and then trying to piece that together from the smaller blocks.

Real tape delay would probably include delay (of course), high and low frequency filtering, noise, saturation (of a sort that the FV-1 might or might not do easily) and compression. I don't have any of that old funky gear so I'm just guessing.


Thanks for correcting me Larry. Looking back at my notes, I used your oil can delay example for my SpinCAD + Dervish HOWTO. Maybe it was that i was thinking of, but that isn't a code block either d'oh!

I don't have a tape echo here either, but i know roughly the sound i'd like to achieve. Add wow & flutter to your list & thats the ingredients. There's a couple of white papers on the Space Echo that analyse it's supposed unique sound, but converting that into a working algorithm is something else.
It's the saturation i've really struggled with. Either it doesn't do much or it distorts badly. I'm sure there's a magic combination there somewhere.

The trouble i find writing code for the FV-1, i hit on a great sounding program & then "waste" an evening playing with that one program rather than continuing to try alternative code smile
random:user
Thanks for the quick and detailed reply gbiz

I was slightly afraid that it wouldn´t be that easy. My stompbox is glad to hear that it won´t be spending the rest of it´s days collecting dust in the corner.

And you´re right , my EEPROM Image is pretty old
I´ll be installing the newest one asap!

At the moment i´m a little short on time and trying on my own is beyond my capabilities.

µDervish looks really cool!
Digital Larry
gbiz wrote:

I don't have a tape echo here either, but i know roughly the sound i'd like to achieve. Add wow & flutter to your list & thats the ingredients. There's a couple of white papers on the Space Echo that analyse it's supposed unique sound, but converting that into a working algorithm is something else.
It's the saturation i've really struggled with. Either it doesn't do much or it distorts badly. I'm sure there's a magic combination there somewhere.


Getting different types of distortion is not the FV-1's strong suit. There is the "t/x" distortion which is at least a smooth clipping rather than just slamming into the "rails" followed by low pass filtering.

https://animagraffs.com/roland-re-201-space-echo/

I didn't realize the RE-201 also had a spring reverb, that will add to the challenge.

gbiz wrote:

The trouble i find writing code for the FV-1, i hit on a great sounding program & then "waste" an evening playing with that one program rather than continuing to try alternative code smile

Bummer! w00t That would lead me to believe you're on to something.
gbiz
Agreed, the FV-1 wouldn't be a first choice for a decent distortion. (You'd have more problems getting a lush reverb out of a germanium diode hihi )

If my experience is anything to go by, you'll run out of instructions adding a decent spring reverb. I've added parts of one that someone posted to the Spin forum to drv102 & it does add a twang to the sound, but it's nothing like what you'd want from a truthful emulation. I say parts, as it needs a lot more instructions than 128. Every time i want to add something else to the echo i have to chop off a couple more taps on the reverb. It's lost it's boing now. The pingpong version has almost nothing left. I didn't bother trying to add it to one with tap tempo.
I also added EQ to that reverb. I found a whitepaper on spring reverb algorithm design (that typically i can't find now, i thought i had it bookmarked), that looked like it's exactly what that Spin forum algorithm was based on. One difference was the paper suggests using an EQ at the end of the taps at the frequency of the boing. I was playing around with that spring algorithm by itself & the EQ certainly improved matters, more so with a reduced number of taps, so i kept it in drv102 at the expense of a few extra reverb taps.

The other issue really is more of lack of controls. I'd like to have a control over HPF in the feedback signal damping, but then that'd mean losing control over reverb signal mix, or delay time or feedback. I did consider using both DACs, have the echo signal on one & echo + reverb on the other & letting the user mix them in an external mixer. Another option is to have a fixed reverb level. This is the same old issue with the FV-1. I end up with a bank of the same basic program, each with a variation on the same theme, with different controls. Oh to have another 3 pot controls.

Code for my 1 & 2 heads drv102, including the pingpong version is here
toneburst
Thinking out loud, but does the FV-1 have any digital inputs that could be used in combination with an MCU sending it data, to increase the number of available controls?

Obviously, this would make any patches that depended on this incompatible with other FV-1-based hardware.

a|x
toneburst
Incidentally, I saw a photo of the Erica Synths Pico DSP the other day, and noticed an FV-1 chip featured prominantly on the PCB.

a|x
gbiz
Unfortunately not, otherwise i'd be using it in Dervish. The FV-1 just has the 3 pots for control over an algorithm*. We have to work within those restrictions. I assume this is down to it being designed for the stompbox market. Extra controls equals larger IC die, larger device footprint, higher costs etc etc. Smaller guitar pedals only have room for 3 pots. And Alesis had DSPs for rack mount & desktop FX with lot more controls.

*I've not tried it, but you could probably use one of the input ADCs as an additional CV but then you'd lose that for audio usage, so it'd make the unit mono-in. Those inputs require the input to be biased to 1.6V so CVs would have to be bipolar. I think most people would want the ability to run the unit stereo audio.

Count yourself lucky. A lot of the guitar pedals use one of those pots for dry/wet mix, so they only get 2 controls over the effect.


There's is talk on the Spin forum of a newer device with (IIRC) 6 controls, MCU interface etc. I've not read the thread for some time so i don't know how far they are towards a shipping product.
Digital Larry
I spoke with Frank Thompson (of Spin and now Experimental Noize) at NAMM a week or two back. One thing to remember about the FV-1 is that there is nothing like it at that price point. That thing is going on ten years old now with essentially the original design! Perhaps familiarity breeds contempt? What it can do in 128 instructions is pretty amazing. That limitation is a brick wall in some cases and in others it may inspire a suitable workaround that is "almost" what you want.

I'll agree about the spring reverb though - that seems beyond what the FV-1 can do believably at this point.

Experimental Noize did announce a new chip with a number of new features (although still just 32k bytes of now 16-bit delay RAM) that should allow the things you mentioned. Although not bound by NDA, I'll let Frank chime in publicly if he so desires regarding updates on this chip.

I also met Andrew Kilpatrick of Kilpatrick Audio, the guy who originally wrote ElmGen, the Java library simulating the FV-1 upon which I based SpinCAD. He threw in the towel a few years back on FV-1 guitar pedals but now offers a standalone digital reverb box which he said uses a general purpose chip or DSP, I can't recall exactly. He said he'd rewritten one of his favorite FV-1 reverb algorithms in C and it was way more difficult doing it that way than using the FV-1's optimized instruction set.

That's just anecdotal of course - I'm sure there are some people who can write reverbs in C with one hand while tweaking their low pass filter resonance live at the Super Bowl half time show with the other hand. That's not me though!
gbiz
Digital Larry wrote:
I spoke with Frank Thompson (of Spin and now Experimental Noize) at NAMM a week or two back. One thing to remember about the FV-1 is that there is nothing like it at that price point. That thing is going on ten years old now with essentially the original design! Perhaps familiarity breeds contempt? What it can do in 128 instructions is pretty amazing. That limitation is a brick wall in some cases and in others it may inspire a suitable workaround that is "almost" what you want.


No contempt for the FV-1 from over here smile I love it. I understand the architecture decisions that they made at the time, it's perfect for the stompbox market. As you say, there's little to compare at that price. I think Keith Barr pretty much got it spot on.

Digital Larry wrote:

I'll agree about the spring reverb though - that seems beyond what the FV-1 can do believably at this point.


That algorithm that Don Stavely posted in the Spin forum doesn't sound half bad by itself. Take out the tremelo he included & there's room for a couple of extra boing taps, or the EQ i mentioned. Adding a feedback loop gets interesting if you can avoid it hitting the algorithms resonant frequency.

I keep meaning to go through the other reverbs that are in the Spin examples to see if one would better suit being added to a tape delay. lack of time etc. sigh

Digital Larry wrote:

Experimental Noize did announce a new chip with a number of new features (although still just 32k bytes of now 16-bit delay RAM) that should allow the things you mentioned. Although not bound by NDA, I'll let Frank chime in publicly if he so desires regarding updates on this chip.


Thats the chip i was on about in my previous post. It's an interesting feature set. They clearly have a target market in mind. I'm sure it'll get used in any number of eurorack modules when it's out. I just hope it's got a more open development environment than the FV-1. An open source compiler/toolchain would be nice.

Digital Larry wrote:

I also met Andrew Kilpatrick of Kilpatrick Audio, the guy who originally wrote ElmGen, the Java library simulating the FV-1 upon which I based SpinCAD. He threw in the towel a few years back on FV-1 guitar pedals but now offers a standalone digital reverb box which he said uses a general purpose chip or DSP, I can't recall exactly. He said he'd rewritten one of his favorite FV-1 reverb algorithms in C and it was way more difficult doing it that way than using the FV-1's optimized instruction set.


Thats obviously the way to go if you want to offer a lot of control over the sound, have long tails etc, but I find a lot of those reverbs, especially the budget "Arm + I2S codec" ones is (IMHO) they all sound the same. All very nice, clean & digital. I much prefer a bit of dirt & analog warmth.

Digital Larry wrote:

That's just anecdotal of course - I'm sure there are some people who can write reverbs in C with one hand while tweaking their low pass filter resonance live at the Super Bowl half time show with the other hand. That's not me though!


No. Nor me. I struggle with the maths to get the saturation working. I'm sure others would just jot something down on the back of a beer mat, then have it coded, compiled & up & running in 5 mins.
kogz23
Hi all,

so while trying to upload the spin image to my Dervish I plugged the power in the wrong way. It is a virgin Dervish. I think I successfully flashed the Attiny, though there is no life from the OLED.
While trying to upload the Spin Image via the teensy I get the following :

"CR to start transfer:
sending HELLO: good
sending CMD 87: good
sending LEN (3) 0 0: good
sending OFF (3) 0 0: good
sending PSZ 128: good
writing 512 128 byte packets
.timeout reading from programmer"

Sometimes it just gets to "sending Hello" then times out.
Is it likely I fried something? If so could it just be the eeprom chip needs replacing? Or am being stupid elsewhere?! Also should I have some signs of life from the OLED before uploading the spin image?
Thanks in advance.
gbiz
Hi kogz23

It has reverse power protection so you should be ok. I do it quite regularly & all mine survive.

If the ATTiny is flashed correctly and you've still got a blank EEProm you should see "0 =========" on the display. Press the select button & you should see the menu. Thats the first thing to aim for before flashing the EEPROM.

The ATTiny flashing procedure usually finishes with a verify of the write, so assuming the verify ran without error, that means the code got uploaded OK. It also means the SPI bus is basically working. The SPI bus is also used by the OLED. But there's 2 other things that could stop the OLED from working - either an issue with one of it's control lines, or the ATTiny is hung in it's setup code by an other issue.

The OLED control lines are CS, DC, RST & are clearly marked on the top of the OLED. With the DVM buzz those pins to the corresponding pins on the ATTiny (pins 10, 11, 12 respectively). Check on the pins themselves, not the pads.

What you're seeing from the Teensy programmer is caused by an issue with the I2C bus. Assuming the Dervish is powered on when you're trying this, it it could be caused by a bunch of things, including the ATTiny. But it could also be causing the ATTiny to not finish it's setup routine which would explain the lack of display.

Give the soldering on the ATTiny, the FV-1 & the EEProm a good visual inspection. The I2C bus on the FV-1 is the two top pins (14 & 15), pins 5 & 6 on the EEPROM, & pins 27 & 28 on the ATTiny.

If you've got a DVM, another check of the ATTiny is power the module on & press the up & down buttons. You should see the SW0 line (pin 4 of J3 on the control board) toggle from 0V to 3.3V with each press. SW1 (pin 5 J3) will toggle on every other press. SW2 (pin 6) will toggle every 4th press.
Check the voltage on the two I2C data lines (SDA & SCL, the two pins together on J3 on the DSP board). Both should be at 3.3V.
kogz23
Hi there,

thanks for all the suggestions!
So I got it fixed, but sorry to say I can't report exactly how. I checked the soldering around the points you suggested and saw some dubious work. When I built this I did not own a Loupe. Now it is one of my favourite tools. Why didn't I get one years ago!? I reflowed some joints then after some minimal headbanging flashing the Attiny (had to move the OLED hex file out of kwikfiles dir for some reason) got the img file loaded and all looks well.
Thanks for the help and sorry my repair is not so enlightening for others with similar issues.
gbiz
no problem kogz23, the main thing is you got it working. "inspect & reflow" is a good enough fix for me smile

I don't know how i'd manage without my Loupe. I use it to check my work as i progress thorough building a board.

Which eeprom image did you install ?. You specifically mentioned Spin image in your previous post, which makes me think you might be using an older one, as the default image hasn't been called that for some time. Some of the original images had a few blank banks & a bank of programs where the controls don't do much. If you've got the Teensy with the target sketch installed, you might want to install the current one.
gbiz
I've had a go at redoing the drv102 echo programs to try & improve the saturation & replace the reverb with something that sounds better as a standard reverb, as there's clearly not enough spare instructions for an even half decent spring emulation.

The OEM1 Plate reverb is probably my favourite of the Spin reverb algorithms (it always reminds me of the reverb in Amber era Autechre tracks). It still sounds good running with only 2 of the 4 taps, so i've switched to using that.

The limiter code now works better & allows better control over more repeats & damping, without it feeding back uncontrollably (or when it does, it sounds better). When it does saturate it doesn't sound quite so metallic or harsh.

I've put a bank together of a few of the programs. A mix of mono, pingpong echos, single & dual head, with & without reverb. Anyone who wants to try it, you can download the bank
here I've got other programs that i didn't include in the bank - different delay dividers, different reverb levels etc.

I recorded some of the output whilst i was messing about with some of the programs in that bank. Apologies in advance for the poor recording levels etc.
[s]http://soundcloud.com/gbiz/drv103-test[/s]
ym2612
This sounds great! I need to get this on my Dervish. This is fun!
gbiz
Cool. I'll be interested to know if you think the reverbs are bit too intrusive. They seemed to work for me for some types of sound but less so for others. Theres a few parameters that i can tweak for the reverb - damping, decay time, dry signal in level, echo signal in level. And then the ratio of reverb to echo levels in the output.

I'll try & get a clock sync version of the non-reverb algorithms done in a few days. Unfortunately i don't think there's enough instructions free to do clock sync and reverb.
gbiz
I thought the reverb sounded a bit odd in those drv103 programs, but i just put it down to only having 2 taps. Wrong.

Whilst i was getting the clock sync working with the non-reverb programs in that drv103 bank today, I noticed a bug with the reverb code. Thats fixed now, so they sound much better, more how i expected them to.

I've updated the bank in the link above, & replaced 2 of the programs with ones that have clock sync. The reverbs are all fixed. So any of you who downloaded the previous one should probably get the updated one. Sorry about that smile
random:user
Wow, that sounds great.
Even more of a reason to update my dervish.
Sorry for the late reply btw. Somehow i didn´t get notified on the new replies. Must check my settings d'oh!
Keep it up we're not worthy
random:user
I just found the time to finally update to the latest image. Loving the clock synced programs. I just spend the whole night fiddling around and haven´t even gotten through all the new greatness yet applause
resynthesize
I just received a second hand dervish and there is an audible high pitch whine coming from the physical module itself. It's kind of hard to tell where it is emitting from, but I _think_ it's the OLED. Any ideas on how to fix? I tried with two different power supplies with the same result.
kogz23
gbiz wrote:
no problem kogz23, the main thing is you got it working. "inspect & reflow" is a good enough fix for me smile

I don't know how i'd manage without my Loupe. I use it to check my work as i progress thorough building a board.

Which eeprom image did you install ?. You specifically mentioned Spin image in your previous post, which makes me think you might be using an older one, as the default image hasn't been called that for some time. Some of the original images had a few blank banks & a bank of programs where the controls don't do much. If you've got the Teensy with the target sketch installed, you might want to install the current one.


Sorry, just saw this. Yes, I was loading the old spin image. Time to update! Thanks
makers
resynthesize wrote:
I just received a second hand dervish and there is an audible high pitch whine coming from the physical module itself. It's kind of hard to tell where it is emitting from, but I _think_ it's the OLED. Any ideas on how to fix? I tried with two different power supplies with the same result.


Does it go away when the display goes to sleep?
gbiz
makers wrote:
resynthesize wrote:
I just received a second hand dervish and there is an audible high pitch whine coming from the physical module itself. It's kind of hard to tell where it is emitting from, but I _think_ it's the OLED. Any ideas on how to fix? I tried with two different power supplies with the same result.


Does it go away when the display goes to sleep?


I'll take the liberty of answering for resynthesize. I chatted with him & the previous owner in email about this. (I built this module for the previous owner).

This is "mechanical" noise coming from the module itself when it's powered on, without it being connected to any other module. It doesn't change when the screen is blanked. It'll do it even if it's the only module powered from a specific PSU.

Someone posted up a thread* here a few days ago with an SSG creating a similar noise. In a followup post, someone linked an EEVBlog video that describes a similar noise being generated by an LCD backlight. As with the LCD, these OLED displays utilise a similar charge pump to generate 7.5V required by the display from whatever Vcc it's supplied with. The SSD1306 controller on the OLED requires 2x 1uF. These are mounted on the underside of the OLED board. Right now I have to assume it'll be one of these that's causing this. The original owner of the module is returning it to me for it to be fixed so i'll be able to diagnose it then.

* https://www.muffwiggler.com/forum/viewtopic.php?t=197812
temaniak
Thats my big review of that module. In Russian yet, but yo can hear a lot of sounds (from 7:50). Sorry for broken focus seriously, i just don't get it
gbiz
Wow !!. That is indeed a big review smile
Thanks for sharing that temaniak beer!
temaniak
gbiz
Thanx for this fucking great module! )))
mutedial
hiya gbiz --- any update on the mini dervish? cheers!
gbiz
hi mutedial

Nobody has asked for it, so i assume there's no demand for it.

The few spare boards i had from the prototype run went out to a couple of testers some time back. What little feedback i had suggests it's ok. The only enhancement request was an option for the program advance input to change to a random program rather than sequential.

I'd want to do any larger PCB/panel run at a quality fab which would need a relatively expensive initial outlay. I'd need a certain amount of interest before committing to that. I considered doing an "interest check" thread for it, but given the lack of interest, i didn't want to spam the forum unnecessarily.
mckenic
Id be down too!
mutedial
I see! I’ve been meaning to ask for ages, and didn’t want to pester you. : )
I’m interested. I’ll be at a Befaco diy workshop in a few weeks and try and drum up interest.
Cheers! Fingers crossed.
gbiz
mutedial wrote:
I see! I’ve been meaning to ask for ages, and didn’t want to pester you. : )
I’m interested. I’ll be at a Befaco diy workshop in a few weeks and try and drum up interest.
Cheers! Fingers crossed.


Feel free to pester smile

The majority of the µDervish prototype boards went to the Befaco/Hangar people. They were the ones who asked for it originally.

It won't be a lot of work for me to get this organised, it's mostly done, i even have Mouser carts smile
I'll start a µDervish thread later today & put all the details as i have them now into that.
mckenic
Thank you!
toneburst
I love this module! This little mess-around jam is drowning in Dervish reverb (in a lovely way)...

https://soundcloud.com/toneburst/tsnm2u-jam-01
gbiz
Nice one toneburst !. Made perfect listening whilst putting the µDervish thread together smile
gbiz
I just started the µDervish thread ... linky
toneburst
gbiz wrote:
Nice one toneburst !. Made perfect listening whilst putting the µDervish thread together smile


Hey, thanks! Glad it was useful smile
toneburst
Is there a reverse echo patch for the Dervish (or uDervish)?
gbiz
There's a thread about reverse delay program on the Spin software forum (here if you're interested). Nobody got it to work that well without it clicking as it wraps round, it needs some cross fading to smooth out the transition. I gave it a try & at the time, didn't manage to overcome that, & gave up. That was some time back though.

Since then i had a go at a looper, which has the same click issue when it wraps around. I managed to overcome that using crossfading. The crossfade code in the looper might work with that reverse delay code.
toneburst
Thanks for the info, @gbiz. Afraid ASM is a bit over my head, or I'd have a go at adding the crossfade myself.

a|x
NiteEagle
The Dervish features heavily in this recording. Not me, but I built it.

https://yealace.bandcamp.com/album/to-that-man-who-once-explained-his- theory-of-the-ghost-moon
uwe
I sent Graham an email a few weeks ago but haven't heard back. Does anyone know where I could get a PCB and panel?
gbiz
uwe oh i'm sorry. That was probably when i was getting a lot of emails about uDervish. Would you mind emailing me again ?. I promise i'll respond this time.
Waz
Interested in this project. Emailed!
muelb
On the input attenuators I have a serious crackling when I turn them. On all my 3 builds the same. Is it the same at your builds?
gbiz
muelb wrote:
On the input attenuators I have a serious crackling when I turn them. On all my 3 builds the same. Is it the same at your builds?


Do you mean with the Song Hui tall trimmers ?.
technotron
Hi!

I've run into problem trying to program the EEPROM via the supplied Teensy sketch. I'm using Vagrant and the Mutable dev environment.

When I type 'dervtty', I get this output (which seems to be alright):
DERVISH_TTY=/dev/ttyACM0

But when I then write 'img2eeprom -v -V -f $DERVISH/kwikfiles/dervish-default.img', I get this output:

Can't open programmer tty /dev/ttyACM0
verifying write ... Can't open programmer tty /dev/ttyACM0
OK

I first tried to use the Teensy to program the attiny88 via the ISP sketch, but I couldn't make it work. The scripts didn't execute correctly, so something seems to be off. However, I managed to program the attiny using avrdudess on Windows, and it works.
technotron
Hi!

I've run into problem trying to program the EEPROM via the supplied Teensy sketch. I'm using Vagrant and the Mutable dev environment.

When I type 'dervtty', I get this output (which seems to be alright):
DERVISH_TTY=/dev/ttyACM0

But when I then write 'img2eeprom -v -V -f $DERVISH/kwikfiles/dervish-default.img', I get this output:

Can't open programmer tty /dev/ttyACM0
verifying write ... Can't open programmer tty /dev/ttyACM0
OK

I first tried to use the Teensy to program the attiny88 via the ISP sketch, but I couldn't make it work. The scripts didn't execute correctly, so something seems to be off. However, I managed to program the attiny using avrdudess on Windows, and it works.
ndf
technotron wrote:

But when I then write 'img2eeprom -v -V -f $DERVISH/kwikfiles/dervish-default.img', I get this output:

Can't open programmer tty /dev/ttyACM0
verifying write ... Can't open programmer tty /dev/ttyACM0


Check permissions maybe.

you might need to add your user to the dialout group (or whatever is appropriate for your system) in order to get access to the serial port that the programmer presents. Usually you do something like:

gpasswd -a user dialout

then log out and back in, try again.
gbiz
ndf is correct. It's a permissions issue. You don't have permission to write to the tty device (/dev/ttyACM0) that is used to communicate with the Teensy.

This should be sorted by the udev rule which is added when you're installing the dervish environment. See the top of page 4 of the Dervish-environment-on-Windows+Vagrant doc. You'll see

# cd /etc/udev/rules.d
# sudo wget https://www.pjrc.com/teensy/49-teensy.rules
# sudo service udev restart
# cd

This adds a rule for a system service called "udev" which sets up permissions for the tty that the teensy will use. The rule will run any time you plug the teensy in. (As the doc states, don't type the #'s when you type this, otherwise nothing will happen).

ndf's suggestion to add yourself to the dialout group should also work.

Try either one of these. If it still doesn't work, run"ls -l /dev/ttyACM0" & show us the output.
gbiz
Oh, and incorrect permissions on ttyACM0 would probably explain why you couldn't program the ATTiny.
technotron
And now it works! smile I remember that I set up this rule earlier when following the instructions in the 'Dervish-environment-on-Windows+Vagrant' document. But I must have screwed up somehow.

Thank you very much gbiz and ndf! ^^
gbiz
If you cut'n'paste the text & include the #'s then the command line will treat them as if they were comments in a program, & it won't do anything. I bet that's what happened.

If you want to see if that was it, run "history | grep rules" you'll get a list of every time you've run something with the text "rules" in the line.
technotron
I know that # denotes the start of a comment, so I didn't type the hashes in.

I experienced some strange problems with the vagrant environment, including not being able to see the mutable-dev-environment directory inside the VM. So it might have been something related to that.

For me, doing this project was also an eye opener on how powerful the Unix shell tools are. smile Thanks again for doing this gbiz! <3
gbiz
Oh sorry ! smile

If those issues with the vagrant image reappear, feel free to post them here. Something might be obvious as to whats wrong.

Yes, the Unix tools make handling files like the program, bank & EEPROM images so simple. That's great you've got something out of doing that, besides the ability to customise your program banks smile
Waz
Hello. I got one of these up and running. One issue I am noticing is mismatched stereo signal. It's really difficult to get a solid matched stereo signal. Is this due to the tolerances of the level pots?
gbiz
Waz wrote:
Hello. I got one of these up and running. One issue I am noticing is mismatched stereo signal. It's really difficult to get a solid matched stereo signal. Is this due to the tolerances of the level pots?


One obvious thing i have to ask, have you checked you haven't got a couple of the trimmers swapped ?. That would cause a difference in signal levels between the channels.

If it's not that, can you give more detail as to what you mean by "a solid matched stereo signal". Are you seeing this with purely dry signal as well as wet ?. Is it all programs or just a few ?.
gbiz
I've just done a re-write of the OLED code*, & i'd appreciate it if any of you who've got easy access to an AVR programmer could install this & give this a beta test for me. It's working here so hopefully you won't have any issues. It doesn't change the format of the EEPROM, so if you want to revert back to the 3.1.5 or 3.2.2 code, that should be fine. Hex file is downloadable here, & the source tarball if you want it is here. If you do test it, please let me know. Feedback will be useful. Unless i hear of major issues, I'm going to make this the default in pre-programmed ATTinys in a couple of weeks.

The new code has a basic line drawing ability, so gone is the fugly line of '=' across the screen, replaced with a seamless narrower line. The bank name list is now flicker free when you scroll down through it. Same goes for the main program screen. Bank select keeps the inverted text support from 3.2.


*I've had to do the re-write as i'm finding it difficult to source SSD1306 OLEDs. Increasingly vendors send me what are labelled as "SSD1306 (new)". These have a 20-way FFC foil connecting the controller to the carrier PCB, ("old" displays have 30-way), & i from what i have read suggests they are actually SSD1315z, not SSD1306. The new ones are supposed to be compatible, but none worked in the Dervish modules i tried here. Rather than debug the issue with the SSD1306Ascii library that Dervish has been using up to now, i decided to rewrite the OLED handling code from scratch in C (upside ... no more C++ \o/ ). The new code works fine with either display controller. I only implemented support for what Dervish actually uses, so the code is a lot smaller. Eg the Dervish display layout is hardcoded to use a 5x7 font, so support for multi-row fonts was adding a lot of unnecessary bloat. I've removed the requirement for the ATTinyCore library, something i've wanted to do for a long time. Dervish with pushbuttons doesn't need it. The new code is now 25% smaller & a much smaller memory overhead. The benefit of the latter means it now has enough free memory to implement a cache for the bank names, speeding up the bank selection screen.

(I think the issue turned out to be with how i was implementing contrast levels. The SSD1306 has contrast levels documented as 0x01 to 0xff, but I was using 0x0 to 0xff, which by luck worked fine, so i never noticed i was using an unsupported value. I suspect the 1315's have implemented a contrast value of 0x0 as blank screen, but thats hard to confirm as there's no programming manual available for it that i can find. I run all my modules with contrast set to 0x0, so all the modules i tried the 1315 in it didn't work but the 1306 worked fine).

These "(new)" displays are also slightly smaller physically. They seem to be 0.91" but vendors still sell them as 0.96". The smaller size footprint still fits, so no problem there, & the text occupies more of the glass area of the screen, so display wise, there's minimal difference in use.
Altitude909
on it.
gbiz
Altitude909 wrote:
on it.


thumbs up
secrethero303
gbiz, do you know which version was included in the kits you recently sent me? Once I finish building them, I’d be happy to try installing the new code to test too.
gbiz
secrethero303, the current attiny88_oled.hex is 3.2.2.

The easiest way to check on a running module, go to the debug screen, it shows it there, along with the amount of free memory.

Yes please, give the new code a try. thumbs up
Altitude909
gbiz wrote:
Altitude909 wrote:
on it.


thumbs up


Looks good. I like the bank name for sure, Everything seems to work as expected but the kerning on that font seems a bit tight, the letters connect to each other in most cases.

If you're having issues with sourcing the displays, you should just make your own. It's probably going to be a bit more per display but you wont have to play hide and go seek finding the right ones. Just get a hotbar attachment for your iron (or just do them one by one), its a LOT easier than it looks. I stopped hunting for OC displays a while ago. I just get the screens separate and have the boards made how I want them
gbiz
Altitude909 wrote:

Looks good. I like the bank name for sure, Everything seems to work as expected but the kerning on that font seems a bit tight, the letters connect to each other in most cases.


Thanks for checking it.

The font itself hasn't changed so it's down to how my code is positioning each character. I'll add a pixel spacing between them & see how that looks. I suspect it'll mean losing one character width on the bank select screen to provide them, but that's back to the number of characters of the previous code so it's not really losing anything. It's late here now, I'll give it a go in the morning & post the new hex up.

Quote:

If you're having issues with sourcing the displays, you should just make your own. It's probably going to be a bit more per display but you wont have to play hide and go seek finding the right ones. Just get a hotbar attachment for your iron (or just do them one by one), its a LOT easier than it looks. I stopped hunting for OC displays a while ago. I just get the screens separate and have the boards made how I want them


If i was starting from scratch again i would, but its probably not worth it now. The only issue was with these "new" displays, but now they're working i'm good (for now).
gbiz
I tried adding that extra pixel spacing. The text definitely looks better, but now, as i suspected, bank/program/control strings that are the full 20 chars lose some pixel columns at the right of the screen. So i've added some basic proportionality to the font handling (anything that already has a blank row of pixels on the right doesn't get the extra row of pixels) & that helps some.

For the program screen i currently have 4 options. See image below
1 is basically what it was previously but with the continuous line & new font code
2 includes the program & pot number & a 4 pixel version of ": ". May drop a column or two off the end of the longest 20 char strings.
3 is 2 but with a full ": ". That certainly will drop pixels off the end of the longest strings, as below.
4 is 1 but without the program number

Personally i prefer 4.

The bank select display will drop pixel columns with the longest strings. I'm not too fussed about that.

If you want to check out each display option attiny code, i've bundled them all into this tarball. I've deleted the previous attiny hex & source until i get this sorted, then i'll re-upload it.

pld
Nice. I'll try and give it a test when I have a minute.

Although I'll mumble a bit under my breath a bit because of
gbiz wrote:
(upside ... no more C++ \o/ )

but will let it slide because it's an attiny (and better good C than bad C++) smile

It's maybe a bit too small to be useful, but maybe icons instead of the pot numbers would work?
Altitude909
4 for sure. Much cleaner
gbiz
pld wrote:
Nice. I'll try and give it a test when I have a minute.

thanks. (If you want the source let me know & i'll post it back up).

Quote:

Although I'll mumble a bit under my breath a bit because of
gbiz wrote:
(upside ... no more C++ \o/ )

but will let it slide because it's an attiny (and better good C than bad C++) smile


haha. What if it's it's bad C replacing good C++ ?

I never really liked the idea of mixing the two. Now at least all of it is in my hacky C smile

Quote:

It's maybe a bit too small to be useful, but maybe icons instead of the pot numbers would work?


I did think about doing something like that, but an icon would have to be 10x8 pixels max. As you say probably a bit too small.
pld
It definitely works smile

gbiz wrote:
haha. What if it's it's bad C replacing good C++ ?

I never really liked the idea of mixing the two. Now at least all of it is in my hacky C smile

Isn't all C hacky? w00t
(in case it's not obvious -- I kid, SCNR, no flame on please).

Quote:
I did think about doing something like that, but an icon would have to be 10x8 pixels max. As you say probably a bit too small.

Yeah, it's pretty tiny. Someone with a better eye for design than me might have an idea, but mainly I deal in programmer art smile

Maybe 5) without a separator? Admittedly the numbers aren't really providing too much additional information.

(this isn't the updated keming).

Spontaneously one might display the bank/program number for a short interval on change and then hide it, but that could easily be too busy/annoying.
gbiz
pld wrote:
It definitely works smile


thumbs up beer!

pld wrote:

Isn't all C hacky? w00t
(in case it's not obvious -- I kid, SCNR, no flame on please).


You're probably safe saying that here on Muffs sdiy wink

Quote:

Quote:
I did think about doing something like that, but an icon would have to be 10x8 pixels max. As you say probably a bit too small.

Yeah, it's pretty tiny. Someone with a better eye for design than me might have an idea, but mainly I deal in programmer art smile


hahahahahaha

Quote:

Maybe 5) without a separator? Admittedly the numbers aren't really providing too much additional information.


That still means some of the control descriptions that use the full 20 chars could lose a few pixel columns on the RHS. I think the full description without the number looks cleaner.

Quote:

Spontaneously one might display the bank/program number for a short interval on change and then hide it, but that could easily be too busy/annoying.


That would mean after the delay, shifting all the text over to the position the numbers were occupying. I agree, it would look a bit busy, and would probably annoy me after a while.

The SSD1306b has support for sliding text, so if everyone had displays using that controller it'd be possible to do some eye candy & slide the text into place & have the number pixels drop off the LHS. The 1306b doc states it also supports gradually fading the screen to dark, which i had hoped to use when the screensaver kicks in, but I couldn't get that to work with the controllers i have here unfortunately. The equivalent 1306 doc i have doesn't mention screen fading support, it seems to support just the minimal set of essential commands, so i suspect its a 1306b feature only & my displays here are vanilla 1306 or 1315z. Shame. I tried implementing fade with "while (contrast) { setContrast(); delay(); contrast--; }" but decided against using it. There's a marked jump between contrast of 1 & screen off, not the nice fade out i was hoping for.


I've just updated the zipfile & ftp tree so it's all there now. This code is here. The attiny88_dervish.hex is in kwikfiles as usual. Option 4 is currently the default in the code & the hex files. But if anyone wants to hack with other options, i've left that code there for now & a #define DISPOPTION in inc.h to change it (use 1, 2, 3 or 4 corresponding to the image above), then recompile. The code layout is in display.c, just look for the #if DISPOPTION lines. At least compilation is much easier now as it only needs the standard avr-gcc/avr-libc.
The tarball mentioned previously with those 4 precompiled hex files is still available.
secrethero303
I think I prefer option 4 as well, the numbers don’t add too much and it looks much cleaner.
kogz23
Uploaded the new Attiny code and the OLED looks great.
I am having some probably unrelated issues though. One issue is that when I change program the effect only changes every 2 pushes. i.e Push down button: The display shows a change, but the effect stays the same. Push again: The display changes and so does the effect.I hope that makes sense, terrible description I know!
The other problem I am having is getting clock sync to work. This could be related to the above issue. It is creating some cool, but very unpredictable results.
Thanks!
gbiz
kogz23 wrote:
Uploaded the new Attiny code and the OLED looks great.
I am having some probably unrelated issues though. One issue is that when I change program the effect only changes every 2 pushes. i.e Push down button: The display shows a change, but the effect stays the same. Push again: The display changes and so does the effect.I hope that makes sense, terrible description I know!


It's working for me & nobody else has reported it. I didn't make any changes to the program select code, (especially not the part that generates the program select lines for the FV-1), so there shouldn't be any issues with it. Did it work before you updated the code ?. If you revert it back to one of the older attiny code releases does it work again ?. (hex files for 3.1.5 & 3.2.2-pb are in the online kwikfiles directory here) If one of those older versions works, let me know. Whilst you're trying different code versions, just so i know you're running the latest (you didn't say which version of the new oled code you've installed), try the attiny88_dervish.hex in that same kwikfiles directory. (The debug screen reports it as version 3.3.3).

Whilst i'm not going to rule out an issue with the new code, as it's working for others, TBH it sounds more like you have an issue with the select 0 (SW0) line from the attiny to the FV-1. This should toggle between 0V & 3V for alternate program selections. It sounds like yours is stuck at one voltage level. The first place to check that signal is on the ATTiny pin 24 (the bottom pin on the left hand row of pins, by the clip led, so relatively easy to access once you have the panel off). If that's toggling between 0 & 3V on each button press, check pin 4 on the 8-way header between the boards (pin 4 is the one to the left of the "J3" text thats above the I2C header) & pin 16 on the FV-1.

Quote:

The other problem I am having is getting clock sync to work. This could be related to the above issue. It is creating some cool, but very unpredictable results.


The ATTiny doesn't have any involvement with the programs themselves, so thats definitely unrelated to the code update smile
You don't what signal you're using with it. There's three things that can impact getting it working
1) ideally use as close to a 50:50 duty cycle on the clock waveform as you can. A short pulse will get filtered out by the FV-1 & probably won't work. Low & high levels have to be stable for a period of time before they're counted as valid to prevent noise being counted as a clock signal. (Someone reported issues with a Pamelas with a 5% gate pulse. Configuring the output to a wider pulse on Pamela fixed that).
2) Use the pot to set an offset voltage, so the clock signal will shift between detectable 0 & 1 as far as the cv input on the fv-1 is concerned. What offset you need to apply depends on the voltage level of the clock you're using. With a 0-10V clock, the pot can be almost totally CCW. With a 0-5V clock, i find the control at about a third (roughly 10am) works. You'll know when it's the right level as you'll hear the delay sync.
3) the clock pulse period has to be less than the maximum delay time for the effect. Most of my clocksync programs now have the maximum clock period as part of that control's label text.

Clock sync can be tricky to get running because of the severe signal filtering on the CV inputs internally in the FV-1 itself. (If you present a 50:50 square wave to the CV, the FV-1 CV inputs will see it as a rounded triangle). Theres no easy way to work around that. You need to have a sufficiently wide clock pulse & use an offset that gives low & high signals for sufficient time for the program to sync.
The clocksync delay programs start at a default period, dependent on what the maximum delay time for that program is. They'll remain at that time until it can lock onto a valid clock pulse. If it subsequently loses sync it'll continue with the last valid period. It'll lose sync if the signal is too weak so it doesn't swing between detectable levels for long enough, or the period between pulses exceeds the maximum delay time. if you're getting wired syncing issues it might be that the level isn't quite right. Try adjusting the pot voltage or the width of the clock pulse.

For the single tap delay programs the maximum delay time is 1sec, for the 2 tap delays (ie the ping pongs) it's 500msec, & for the 4 tap delays (stereo ping pong) it's 250msec. I can't remember what the hardcoded default delay times are - iirc the single tap one is 300msec. It's in the code.

(I really should put this into a howto ! smile ).
kogz23
Thanks for the suggestions/insights.
The version I had was the 3.3.3 hex. When flashing it it did mention something about detecting a new fuse "keep or use new value" or something to that effect. Responding "yes" halted the process, so i answered "no" and the flashing seemed to go fine. I am not sure if this could have caused a problem.
So I tried earlier versions and I have the same situation with the only every other program loading. So it must be a hardware issue eek!
I will check the area you suggested and report back.

Concerning the clock, it sounds like user error. I am using a Midibox Seq4 to provide clock. The clock width is 1ms, but is adjustable. I tried various PPQN settings. 16PPQN seemed to have the most effect, though it was pretty wild!
gbiz
kogz23 wrote:
Thanks for the suggestions/insights.
The version I had was the 3.3.3 hex. When flashing it it did mention something about detecting a new fuse "keep or use new value" or something to that effect. Responding "yes" halted the process, so i answered "no" and the flashing seemed to go fine. I am not sure if this could have caused a problem.
So I tried earlier versions and I have the same situation with the only every other program loading. So it must be a hardware issue eek!
I will check the area you suggested and report back.


No, the fuses thing is not an issue. There's some unused fuses in the attiny88. I don't set them, so i play it safe & leave them at "1" but some read back as "0" so the verify complains.

Those program select lines go directly from the attiny to the fv-1, so it can only be the soldering on the attiny, the fv-1 or the header pins between the two boards. There's no other components involved.

Quote:

Concerning the clock, it sounds like user error. I am using a Midibox Seq4 to provide clock. The clock width is 1ms, but is adjustable. I tried various PPQN settings. 16PPQN seemed to have the most effect, though it was pretty wild!


It's not user error. Blame it on the lack of documentation of what clock signal the program is expecting wink

I suspect that's still too fast, which would explain why it sounds wild, though it's probably fine for a clocksync'd flanger smile You only need one pulse per delay period, so if you can, try 1ppqn, or even lower, eg 1 pulse per bar.

Just as a test to getting it working, try an alternate clock source, eg the square wave from an LFO. Try varying the level of the control pot & the frequency of the LFO to see how the delay reacts to changes with those.
kogz23
Yup, you were right, it was poor soldering. Pin 16 of the Spin chip was not properly soldered, This was one of my first SMT projects, some of the soldering was pretty shocking!
So now it working correctly. I will experiment with different clock sources soon...Thanks!
MUFF WIGGLER Forum Index -> Music Tech DIY  
Page 1 of 29
Powered by phpBB © phpBB Group