after my latest attempt at cloning an xp-100 failed, ive decided to keep things simple. what i am looking for is a schematic for a digital effects board. preferably i would like the actual DSP to have RAM expansion as i will add more effects later. could someone send me in the right direction regarding schematics or a DSP that will work fairly good? i'm not looking for anything thats got super low latency or perfect modelling but something that will sound decent.
on a side note and slightly more complex, how would i go about adding a display to said effects unit to tell the user that the effect's algorithm has changed? to keep it simple i will use two 7 segment displays. i assume that i would need a display driver (mircocontroller and an octal flip flop?), buttons to switch both the algorithm and what is displayed on the screen and of course an algorithm to change what the display shows (unless the driver already has this feature built in)
thanks
~A
Check this out...
https://www.sparkfun.com/products/12767
that looks really cool, i already have my teensy in use but i'm sure i can try it. only setback is that it's out of stock...
I think you can geit it from the PJRC site directly
https://www.pjrc.com/store/teensy3_audio.html (https://www.pjrc.com/store/teensy3_audio.html)
I will take a look and see if they have it.
On a side note, i feel that if i buy a premade board i might be limited. What i really want to be able to do is add a potentiometer to a PIC and use small increments to either shift the pitch or change volume depending on what patch i will use. Also im not sure how to change patches/effects with a rotary encoder or buttons but i think i will have to use another PIC. My problem is that im not that competent in C thus im not sure how i can get this stuff to interact. I feel bad for asking someone to do it so i guess someone could maybe explain how to do what i am asking from a software standpoint?
Thanks
~A
One thing to remember is that Teensy hardware is open source, even the audio board, so you could conceivably develop something to your own needs. Regarding knowing C or not, I think you could find a lot of pre-existing code for i2c interface, but you will still need to learn something in order to bring it all together.
yeah i think i will go down the Teensy route but as i said, i am currently using it in a project (a keyboard) so i cannot use it. i'l probably order a new one.
just to clear something up, lets say i add a potentiometer for an expression pedal (using a PIC) would i set the increment value to the PIC, set its action in each program in the ROM (so volume or pitch) and then put code in the DSP instructions telling it what GPI i am using? i did find a DSP that would be a good DIY solution but i'm not sure if you can add external ROM and i'm not sure about how it interfaces with other parts. i think i'l use i2c as you said and try when i get the parts. i would supply a schematic but i don't want to go completely off topic as this is about DSPs and not adding expression pedals unless you actually need one. :P
Doesn't the Teensy itself have ADC inputs you could use for adding a pot or an expression pedal input?
Adding a PIC to do that seems like making things unnecessarily complicated, and these things are generally complicated enough as it is! ;)
Dealing with rotary encoders isn't too bad, but you need two pins (rather than one for a pot) and if you're doing it properly, you need to do software debouncing on the encoder contacts. None of it is hard, but it's all fiddly the first time you do it. That said, you might well find code for the Teensy that implements that for you.
HTH,
Tom
yeah i will certainly look for some code to hook up an encoder and what not.
when i said 'i will add another PIC' i meant if i was to actually build the unit with a dsPIC33FJ64GP802 and port expander. obviously the DSP can't process the audio, a pot and a rotary encoder alone so i was considering adding another PIC and writing some basic code so that i could drive the pot with x amount of increments whilst running some debounce code for the rotary encoder. that is, of course, if i decide not to go with the Teensy/DSP board combo.
If you do decide to go with the dsPIC 33FJ64GP802, my DigiDelay pedal would be a possible hardware platform. Since it's a digital pedal, you've got the dsPIC, 256KB of external RAM, and 5 pots connected for controls.
http://electricdruid.net/diy-digital-delay/ (http://electricdruid.net/diy-digital-delay/)
You won't find much boilerplate code for the dsPIC though, and it doesn't have the power of the Teensy, so I don't think I recommend it. Plus the DAC on the dsPIC '802 is noisy. I was disappointed, although I did the best with it I could.
Tom
thanks for the link, i will read up on it as i am sure it will help me with this project. i also heard it's not really perfect but it's a start. then again, as you said, the Teensy does have more processing power so i will probably see if i can do more with a Teensy.
just another general question, how many different effect patches do you think i can get onto the Teensy/dsPIC? I suppose i can add some EPROM but i don't know how to add it and switch between effects yet. my main worry with using the dsPIC is that i will be limited on GPIOs and space for the code as i will add multiplexed LED displays and a rotary encoder as i previously discussed. i feel like a port expander would do the trick but i still would be limited on processing speeds etc.
You can probably get far more patches than you'll need. I mean, a patch is what? 8 parameters tops? so just 256 bytes of EEPROM would give you 32 patches. If you had 1K of EEPROM, you'd have plenty of storage, I'd have thought.
Tom
yeah that makes sense, i think i'l be fine just for a couple patches since i'm not going too crazy. personally i like to stick to analogue effects but some stuff has to be done digitally. there really isn't too much that interests me other than stuff like pitch modulation so i definitely thing i'l be okay.
i appreciate all the help guys, its been very helpful :D
Well, you're going to need algorithms in addition to patches which might be considered as settings of those algorithms. Until you know what you're going for and actually compile some of those things, I'd say it will be hard to predict how much space will be needed.
yeah i know. considering most of the external stuff such as all the pots and the display will be controlled by the DSP i think i will lack space. do you think it's worth using another PIC to control the the patch changes and pots? if i do that then i'l have to figure out an algorithm to get the DSP and PIC working together. plus i still haven't figured out how to change the patches so it will just make it more complicated :icon_eek: :icon_biggrin:
Unfortunately I don't have any experience with PICs or Teensy so can't tell you.
don't worry, i'm sure i will figure it out. i think my schematic will work fine but i still have to figure out ways around some constraints such as memory as we discussed. the dsPIC i want to use had a flash of 64kb so it will suffice for now. when i actually figure out how to digitally switch patches then i will add some EEPROM, figure out how to get the EEPROM and internal flash memory to work together and work from there.
Quote from: Digital Larry on June 04, 2017, 01:35:35 PM
Well, you're going to need algorithms in addition to patches which might be considered as settings of those algorithms. Until you know what you're going for and actually compile some of those things, I'd say it will be hard to predict how much space will be needed.
I agree about the "Until you know what you're going for" part, but there are two different things going on here. One is algorithms and program code, which all goes in flash memory. The other is patches (settings for those algorithms) which would typically go into EEPROM. Many chips have both, but usually a lot of flash and not much EEPROM, and that balance is typically what's required.
Obviously having enough space is a concern, but until you're hard up against the limit, you don't really need to be worrying about it. 64K is a lot of program and data tables (flash) and 256bytes is a lot of patches (EEPROM).
Once you *are* hard up against the limit, you start pruning, or get clever with your tables, or something. There's always a way.
HTH,
Tom
Edit: Anyway, the dsPIC 33FJ64GP802 has a bigger brother, the dsPIC 33FJ128GP802 with 128KB flash, so you can always move to the larger chip.
FYI -- I just bought a teensy 3.2.
Comparing the specs of the audio codec in the teensy audio board and the ADC in the Teensy 3.2 I don't see that the audio board adds anything of value. Both are in the same range of ENOB and SNR.
The DAC on the Teensy is 12-bit...but that isn't the end of the story. Add an 8-bit PWM to the 12-bit DAC output through a resistor divider and now you have a 20-bit DAC. You send the 12 MSB to the DAC and 8 LSB to the PWM output and I am willing to guess you can get better DAC performance than the CODEC on the audio board.
I haven't got that far yet...probably a month or 2 out before I start messing with this, but for mono audio I would consider the Teensy to be a 1-stop shop.
The other advantage is it's conceivable that you can keep up with sample-by-sample processing on the built-in ADC and DAC for a total of 1 or 2 sample latency through the system. A little more aggressive analog filtering is the main thing needed to for the built-in solution.
Either way I think for the frequency range typical for guitar I would go as far as saying you can get BETTER audio quality from the built-in ADC and DAC than you can from the audio board. The audio board CODEC specs were not looking like a very substantial improvement when I reviewed it.
The audio board adds a lot of value if you're doing stereo or more channels...but it also adds latency.
Quote from: Transmogrifox on July 25, 2017, 03:40:27 PM
The DAC on the Teensy is 12-bit...but that isn't the end of the story. Add an 8-bit PWM to the 12-bit DAC output through a resistor divider and now you have a 20-bit DAC. You send the 12 MSB to the DAC and 8 LSB to the PWM output and I am willing to guess you can get better DAC performance than the CODEC on the audio board.
I'd be surprised if that were the case, specs notwithstanding. A PWM output is the lowest-fi of audio output solutions. Getting it and the DAC matched up well enough to say that you've really got 20 bits would be a very big ask.
What's the linearity on the 12-bit DAC, for example? It could well be a couple of bits out.
Quote
The other advantage is it's conceivable that you can keep up with sample-by-sample processing on the built-in ADC and DAC for a total of 1 or 2 sample latency through the system. A little more aggressive analog filtering is the main thing needed to for the built-in solution.
I wouldn't sweat the latency. Assume you sample at 48KHz and process a block of 16 samples each time. This is a good idea since block processing is much more efficient than doing one single sample everytime. How bad's the latency? 16/48000 = 33usecs, a 1/3rd of a millisecond. That's so far below perceptible you'll never know.
Quote
Either way I think for the frequency range typical for guitar I would go as far as saying you can get BETTER audio quality from the built-in ADC and DAC than you can from the audio board. The audio board CODEC specs were not looking like a very substantial improvement when I reviewed it.
Again, I'd be very surprised if this is true in practice. My recent experience has been that external codec beats on-chip devices every time. Putting sensitive ADC and DAC on the same chip as a noisy uP is asking for trouble and asking for digital noise to creep into your input/output signals. Getting ADC/DAC off onto a separate chip with its own power supply with its own decoupling usually helps a lot.
Quote
The audio board adds a lot of value if you're doing stereo or more channels...but it also adds latency.
Try it. I think once you've done some experiments you might rethink whether the audio board is worthwhile.
Tom
I've read that Teensy audio board is noisy. This may be down to the specific implementation rather than something inherently wrong with the concept.
Maybe it is, I dunno.
In general, the principle is to keep the analog and digital parts as separate as you can, but the practice can get tricky..
T.
Quote
I'd be surprised if that were the case, specs notwithstanding. A PWM output is the lowest-fi of audio output solutions. Getting it and the DAC matched up well enough to say that you've really got 20 bits would be a very big ask.
What's the linearity on the 12-bit DAC, for example? It could well be a couple of bits out.
I think I mis-communicated what I meant by calling it a 20-bit DAC. Clearly the noise will swamp anything below 14 or 15 bits, but that's all I need to get close to the ADC accuracy claims, and consequently audio shield performance. The point is there is lots of dither built-in by using the PWM output for the last few MSB.
The main thing missing from the SAR ADC is the FIR anti-aliasing filter. This isn't an issue as long as the signal source is reasonably quiet above 20 kHz to around 100 kHz at which point reasonably good rejection can be had from analog filters.
The idea is to use the DAC as the MSB bits since the noise is clearly lower than a PWM output. The noise on the PWM output is divided by 2^12 from the get-go (already at -72 dB). A SPICE simulation shows me I can get the PWM noise down to <90 dB with a 4rth-order analog reconstruction filter. This also is adequate to take off a good bit of the the 12-bit DAC digital noise.
What I'm hoping to do is get to something near 14-bit ENOB, which is on par with the audio shield. This will get SNR and distortion down near stompbox quality audio and arguably noise from other parts of the system will dominate, making it not sound "digital".
If DAC accuracy turns out to be a significant issue then can output 10 bits DAC and increase weighting on the PWM.
This is what I'm starting with. This is just 12-bit DAC output wired to ADC input, and used Audacity to send a sine wave via the USB audio function and record it back. I don't think dropping the noise floor another 10 dB is entirely unreasonable, and this would get performance comparable to the audio shield.
(https://forum.pjrc.com/attachment.php?attachmentid=11266&d=1502768526)
QuoteI wouldn't sweat the latency. Assume you sample at 48KHz and process a block of 16 samples each time. This is a good idea since block processing is much more efficient than doing one single sample everytime. How bad's the latency? 16/48000 = 33usecs, a 1/3rd of a millisecond. That's so far below perceptible you'll never know.
The thought about latency is more for being able to put digital gain & filter blocks in feedback loops with other analog circuits. Single-sample latency is fast enough to incur small enough phase shift at the <5 kHz range that one might reasonably use it (with some caution) as if it were an analog IC. This is another draw-back to an audio CODEC -- they have significant latency built-in to the resampling filters (significant in the sense of phase-shift concerning integration with audio-frequency feedback loops).
As for most things a processing block of 64 samples is fine. Remember the latency isn't 1.45 ms, it's double that, which is 2.9 ms.
I find the 5.8 ms latency fine for a single device. The problem is something like a Teensy lends itself well to single-purpose stompboxes. Add up a few of these at 5.8ms and now you're getting into the perceptible range.
With a 64 sample block you can have a few of these before it gets into the perceptible range. I think a 32-sample block would be totally fine for 5 or 6, and 16-sample would be overkill.
So yes, I agree with your point about latency when it comes to perceptible delay. It's just a completely different matter if making the unit into an analog circuit building-block if you ever want to apply feedback.
Quote from: Digital Larry on August 05, 2017, 01:12:03 PM
I've read that Teensy audio board is noisy. This may be down to the specific implementation rather than something inherently wrong with the concept.
I also read that the internal high-pass filter is the culprit. Apparently much of the irritating high-pitched whine goes away when this filter is disabled.
As for any reports about the built-in ADC being noisy, I have identified the culprit for that one, which is also the DC removal function.
https://forum.pjrc.com/threads/45770-DC-offset-removal-noise-distortion-in-input_adc-cpp-input_adcs-cpp
The DC removal function bins 128-sample averages into a 16-element delay line, and runs a moving average on that. This is simply down-sampling followed by a moving-average filter. The down-sampling "anti-aliasing" filter is an integrator, which doesn't have very good rejection. The end result is significant aliasing on the input signal:
(https://forum.pjrc.com/attachment.php?attachmentid=11258&d=1502687731)
Ok, I understand and agree with your points about the latency. If you start putting feedback around anything digital, all bets are off, for sure. If that digital thing has a 64-sample latency, the bets that are off are off!
I'm still not sure about the DAC+PWM though. Ok, you've measured the performance of the DAC - feed sine wave out, read sine wave in, analyse data, get results. Nice. Some facts are good to have, and it's too easy not to bother and just wing it (I'm guilty as hell of this...) But measurable data is the gold standard and we should stick to it.
But the problem here is that the DAC's output isn't entirely linear, in which case, adding a PWM signal to it at low level isn't necessarily going to help. I imagine it like this:
The main DAC output is a rising staircase, with fairly big steps. The PWM output is another staircase, but with very fine steps. So fine, in fact, that we'll imagine it as a rising ramp waveform. Now, if we get the ramp waveform the same height as the steps and add it onto our staircase waveform, we get a lovely smooth ramp wave rising all the way to the top. Woowee!
But now think what happens if our DAC staircase is out by a couple of bits. Some of the stairs are taller than others. Some are shorter. When we add the PWM ramp on, the flat stairs become slopes, but we still have abrupt jumps where the stairs are too short or too tall, and those jumps *are just as tall as the errors they represent*. E.g. The addition of the PWM does nothing to remove the errors. You might increase the resolution, but you don't reduce the errors. Say the errors are in the last two bits of the 12-bit DAC. Instead of a 12-bit ADC accurate to 10-bits, now you've got a 16/18/20-bit DAC accurate to 10-bits. It's not a huge improvement.
Presumably some kind of compensation algorithm could be worked out that would allow the PWM to compensate for the ADC errors, but that's a bit more involved...
This is theoretical for me since I've never tried it, and I'm always extremely wary of theoretical "it'll never work"s over "actually, I tried it and it's not bad", so I'm not trying to put you off at all. I'm just trying to explain my thinking. If it was me, I'd go ahead and do it and see what it looks like. All the theories in the world are spot-on correct until someone does an experiment that proves that they're not.
Tom
Quote from: ElectricDruid on September 04, 2017, 05:44:59 PM
Ok, I understand and agree with your points about the latency. If you start putting feedback around anything digital, all bets are off, for sure. If that digital thing has a 64-sample latency, the bets that are off are off!
For longer delays and even reverb, I would not get too worked up about 64 samples of latency. For a flanger or resonant filter, yes. As time goes on (maybe it's just my brain starting to fall apart) I worry a little less about theoretical stuff and sometimes I just try crazy stuff to see what will happen.
Absolutely agree, Larry. It's nearly always worth giving it try, even for the "crazy" stuff. After all, what's the worst that can happen? It blows up, burns your house down? pfft...
T.
Quote from: Digital Larry on September 05, 2017, 06:25:30 AM
For longer delays and even reverb, I would not get too worked up about 64 samples of latency. For a flanger or resonant filter, yes. As time goes on (maybe it's just my brain starting to fall apart) I worry a little less about theoretical stuff and sometimes I just try crazy stuff to see what will happen.
Agreed. One thing I have in mind is once I made a thing I called a "haw-wah", where I put a Crybaby in a feedback loop and it turned it into a sort of a swooshy vibey thing. One might think, why not just do it in DSP? It can be done, but when considering the Teensy as a basic building-block, then it is nice to be able to mix analog and digital techniques.
Whether I can make it actually work is another question altogether :).
This is also true for the case of extending the DAC resolution by using PWM. I understand your point about DAC accuracy, but it's going to be accurate to a certain number of LSB, and that is where I shift the bits in the PWM.
In either case, I agree it may not turn out as simple as combining a 12-bit DAC with 8-bits PWM and getting a 20 bit converter.
However, I do hope I can get the noise floor to <80 dB and then the performance will probably be comparable to the SGTL5000 (except for rejection of aliasing), and ultimately going for noise and distortion performance comparable to a typical stompbox.
Whatever the opinions I'm working toward that and I will report on how it turns out.
In the mean-time I'm trying to port my floating point inductor wah model to fixed point processing. The ultimate goal is to turn this into my "Wahd Blahk", which will be a proximity-controlled wah (like Zvex Wah Probe), but with a really broad range of wah pedal models to choose from.
I still contend the built-in ADC and DAC can be caudled into having specs not far short of the SGTL5000 minus the anti-aliasing filter that is typically built-in with these sigma delta codecs. For that I anticipate the input source is sufficiently bandwidth-limited so (hopefully) the main contributor to aliasing will be the high frequency noise floor.