Output to Oscillosope options

#1

All, Am looking for a way to be able to tap into sections of a patch in development as output to an external oscilloscope for viewing.
My first thought was to use the 2 Analogue outputs that would even give a 2 channel view, but based on what I have found on the forums, this will only transmit at 3kHZ which may not give a very effective resolution.
The other option is to use the Audio outputs as mono's which is how I have it setup anyway, but this would only give me one channel, and will limit what I can do with the Audio path, or use the Headphone output, but this is limited to the position of the outputs in the Audio path as well and won't give the option of freely tapping into sections of the patch.
OR, am I completely misrepresenting what the Axo may have to offer here ?

P.S. Am learning look closer at the signal path, so as to learn more about what is happening as the signal is manipulated through the path. Seems to be a natural progression to understanding what the Axo can do.

Thanks..

#2

Why not use the virtual scope? It's called scope:)

#3

Because I get a lot more info from an oscilloscope.
And this is no complaints about it, its great, but because I play the base guitar I don't get much of the signal on the scope, plus I can use the spectrum analyzer also on the oscilloscope, but I have found the spectrum analyzer in a patch extremely useful, but takes up a lot of resources from the scope. So I just get worried about causing problems by putting to much load on the patch.

#4

This is an interesting question... more broadly, how fast could the GPIO pins be driven?

Im assuming the 3kHz rate, is just quoted, as the control rate... but presumably this could be exceeded in the same way as audio is, i.e. you write to a buffer that is N bytes, giving you 3xN kHz.
so then the question is,
a) whats the limit from the STM32F4?
b) is there a way to get chibios to read this buffer, and write to the pins at a guaranteed rate?
I guess (b) is the problem area...

(a) could be found in the STM ref quite, (b) in the chibios documentation , though I guess @johannes already knows the answers :slight_smile:

theres a few areas, Id like to go look at...
go check the current audio code, is it the responsibility of the codec to guarantee the timing of 16 byte buffer?) , how would things like usb audio, or audio via X3 work (I2S?) ... how do/would they reliably clock?
if this is controllable, then again, writing the gpio pins would seem possible in a similar way.
(and are easier(?) since your not caring about syncing any clocks, you just want steady timing)

as for the problem space...
if your using mono, can't you use the other channel as an data channel?
(unfortunately the headphone socket is hardwired to the audio output iirc, and the additional aux channel too)
on the other side, many signals on axoloti are control rate, so reporting at higher rates wont buy you anything, but I'm assuming your talking about audio rate signals.

#5

Driving the on-chip DACs at audio rate is not implemented, and requires a substantial compromise, and ultimately I do not expect good audio quality.

(warning: deep tech talk ahead...)

Here are some pointers for anyone interested in implementing this. It goes quite deep as it involves combining SAI, DAC, GPIO, DMA, Timer, documented in STM32F4 reference manual DM00031020.pdf.

Triggering

The DAC's can be triggered (DM00031020.pdf section 14.3.6), but none of the possible trigger sources is already connected to the codec sample sync (PE4_SAI1_FS_A, available on X4).

  • One way around is connecting PE4_SAI1_FS_A to PB9, which is configurable as a trigger source as "EXTI line9".
  • Another potential way is enabling codec sample sync output on PF9 (alternate function SAI1_FS_B), that's a free pad, and configuring that as a trigger source for "EXTI line9", but both SAI1A and SAI1B are in slave mode, SAI1B is configured to be synchronous to SAI1A ("SYNCEN"), and the documentation says, when synchronous it must be slave too. In slave mode, FS is an input, not an output. Maaaaybe it works as an output when configuring SAI1B as synchronized to SAI1A but in master mode, but the documentation does not specify, only says don't do it.
  • One of the on-chip Timers could be "softsynced" at audio buffer boundaries (SAI DMA interrupt) to generate something close to sample sync, and used as a trigger for the on-chip DAC.

Feeding data

  • The DMA1 streams 5 and 6 are the only ones that can be used for the on-chip DACs. They're currently configured to be used with I2C1, available on the Axoloti Core gpio pins, one DMA stream can not be used for two things at the same time. One workaround is moving I2C1 to use interrupts rather than DMA, freeing up DMA1 streams 5 and 6 for the DAC. Chibios 2.x does not support I2C via interrupts. Also I2C via interrupt is far less efficient than using DMA.
  • Alternative: using the DAC interrupt to feed it data, but that's far less efficient than using DMA.

If someone wants to develop an implementation, I'd welcome such contribution, but since the DMA streams conflict with I2C1, I think it 'd be best if it's kept optional.

#6

I don't have the coding skill but I've seen STM32 code for a pt8211 audio DAC chip using SPI that might be useful to someone, http://www.stm32duino.com/viewtopic.php?t=519 and https://forum.pjrc.com/threads/29284-Dual-channel-16bit-dac-PT8211 for an i2s version of code. The pt8211 chips are incredibly cheap as well, I picked up 20 for a few ££.

#7

About the PT8211: this is quite a bit more involved than copying some source code for pt8211, need to synchronize the sample clock, and buffer-timing to the on-board audio ADC/DAC. Looking at the datasheet, I expect disappointing sound quality from this chip as it does not have a reconstruction filter at all. It is possible to implement a reconstruction filter in firmware, and oversample the convertor at 8x normal sample rate. But that makes it more complicated to synchronize with the on-board audio ADC/DAC.

#8

Hi @johannes of course, I didn't necessarily expect it to be easy, I was just pointing out options where other work was being done, it's good to share ideas from time to time imho :smile: I will take a look soon and see what the quality is like on a teensy board, I've got 20 of those chips to mess around with.

I'm quite interested in getting CV in/out of the axoloti, obviously one of these chips would be quite wasteful for that purpose but a 4/8 output dac would be very useful.

#9

Perhaps check the MAX11300 chip and MAX11300PMB1 evaluation board, more expensive than pt8211, and certainly not made for audio, but a huge number of CV in- and output channels. I have not tested this, but others have: https://sebiik.github.io/community.axoloti.com.backup/t/max11300-for-cv-in-and-cv-out/1568

#10

@johannes I've read that thread, I'm going to keep an eye on it, I'm hoping that someone might make a kit with a PCB and pre-programmed 11300 chip...