Multiple AOUT_NGs

[Highcooley]

To daysichain multiple AOUT_NG modules, I connected J2 of the first module to J1 of the second AOUT_NG.

 

And as much as I understand from the Midibox_NG manual, the config for two AOUT_NGs should simply be:

AOUT  type=AOUT_NG  cs=1  num_channels=16 (cs=1 as I use an AINSER64 at cs=0)

 

After that, I should be able to address CVs 1-16

 

However, the second module doesn't respond. Am I missing something? If I hook my osciloscope to J2, I do see the clock signal at pin 5 but no DOUT at pin 4.

 

Thanks for your help!

 

Regards,

Andy

 

 

[Highcooley]

Sorry, everything working smoothly now. Haven't got a clue yet what the problem was, but consider it as resolved.

 

@Admin: Please delete this topic, thank you!

[lukas412]

Nice avatar!

[TK.]

I won't delete this topic, because it's a useful confirmation that two chained MBHP_AOUT_NG modules are working :)

 

Best Regards, Thorsten.

[Highcooley]

All right...I'll give you some feedback as soon as 4 AOUT_NGs are working :yes:  

... btw. octave transpose is working perfectly! Semitone transpose works with CCs. Next will be a test with NRPN to see, if I get a smooth semitone transpose over a 15 semitone range without audible steps. 

 

@lukas412: THX!

[Alasdair Moon]

Veeery good to know ... cause I need more CV for my analogue modular Synth ..
Does the BIPOLAR setting produce +- 5Volts?? I use Yusynth, CGS, MFOS, Curetronic DIY modules that sometimes need that range .. 

[TK.]

The bipolar setting is a hardware option and should work without additional software measures.

It just shifts the offset into the negative range.

 

Best Regards, Thorsten.

[Navicat]

This is a module for SeqV4 and i need 16 cv channels.

 

Here in my schematic is a Daisy-chained AOUT_NG which gives me 16 CV outs : http://www.docdroid.net/srwp/core.pdf.html

 

With the simple conficuration : 

 

AOUT  type=AOUT_NG  cs=1  num_channels=16

 

Will my daisy-chain work?

Edited March 4, 2015 by Navicat

[TK.]

It should work this way (up to 32 channels are supported)

 

Best Regards, Thorsten.

[Highcooley]

Hmmm, has anybody been successful with more than 2 AOUT_NG Modules? I am struggling with the 3rd module which does not respond yet (checked cabling and also if this additional module is actually working, which it is). So, no luck with more than 16 channels yet.

 

I set

AOUT  type=AOUT_NG  cs=1  num_channels=24 (cs=0 still used for AINSER)

and addressed the new channels with

fwd_id=CV:17

upwards

 

But nope, no response yet. Thanks for your reply!

 

Cheers,

Andy

 

   

 

[TK.]

I've to test this at my side if nobody is using this configuration yet

Best Regards, Thorsten.

[Highcooley]

Do you have enough AOUT_NGs laying around for the tests or can I help you with anything by performing tests?

 

I did a couple of tests myself:

- exchanged all cables and modules with each other. Still the third module does nothing and the other two work.

- fed 5V directly to the third module to rule out voltage drop

- reduced cable length by eliminating the AINSER_64 which is daysichained ahead of the AOUT_NG modules.

- configured 16 channels in the hope that module 3 would replicate module 1. No change with or without the AINSER_64 (however,I don't fully understand the transfer protocol, so maybe if the software only feeds 2 modules, the third won't do anything no matter what)

- measured DOUT of the third module and didn't measure any signal coming out

 

One thing I noticed though is, that if I fully sweep the output CV of a channel of the third module, the voltage changes from 0.09 to 0.11 V.

 

This does not make any sense to me, but maybe it could be a clue what's going on here.

 

Thanks for your effort!

 

Regards,

Andy

 

 

[TK.]

Hi Andy,

today I spent some time on a code review (since I've only a single AOUT_NG module there was no easier way...)

I think that I found the potential problem: all AOUT_NG modules require a CTRL0/CTRL1 register configuration after power-on, but the AOUT driver did this only for a single module. This means that only the first AOUT_NG module was configured correctly, and that the second AOUT_NG module got an incomplete configuration (only CTRL0), and that the following AOUT_NG modules haven't got a configuration at all!

Please try this version, where all chained modules should get CTRL0/CTRL1 properly:
http://www.ucapps.de/mios32/midibox_ng_v1_033_pre9.zip

Best Regards, Thorsten.

 

[Highcooley]

Hey Thorsten

Thanks for the update. Unfortunately, the init seems not to be working properly every time. Where as module 2 is working every time with v1.032, now I either have 4 or only 1 module working. Rebooting always only enables 1 module no matter how many times I try. Only if I reflash the software several times, suddenly all modules work after about 5 to 8 tries.

Update: Soft resetting via MIOS terminal sometimes also helps after a couple of tries.

 

Best Regards, Andy

Edited September 22, 2015 by Highcooley
new discovery

[TK.]

It seems that the TLV5630 chip doesn't shift the data as expected (and unfortunately the datasheet doesn't make clear how to handle the cascading software-wise)

However, I've some spare chips but no PCBs. I will solder them on a veroboard to debug the transfers soon.

Best Regards, Thorsten.

[Highcooley]

I consulted the datasheet as well. Do we need any changes in CTRL1 at all? Otherwise, CTRL1 could be skipped.

As soon as CTRL0 is set to DOUT enabled for the first chip (D3=1 --> 1000 0000 0000 1000), one could conclude that any further telegram will be put to DOUT with a 16 bit delay. What is unclear to me is, if these first 16 bits get discarded or pushed on (to be used for the next chip). If they are lost, the process would have to be repeated two more times for 4 chips, extending the string length by 16 bits after each cycle. A pity there are no further details concerning this in the datasheet. Google also didn't help.

Regards, Andy

Edited September 22, 2015 by Highcooley

[TK.]

I don't really want to skip CTRL1 preload as a workaround, but prefer to understand the reason why the driver doesn't work as expected.

For the case that you would like to try it out: here an alternative sequence, where CS is strobed after each 16bit transfer:
http://www.ucapps.de/mios32/midibox_ng_v1_033_pre9_aout_ng_multics.zip

It might work, but I see the potential problem that the first DACs will temporary output the voltage of the following DACs (and I can't believe that this is the intended way how to preload the DACs). :-/

Best Regards, Thorsten.

Edited September 22, 2015 by TK.

[Highcooley]

I don't really want to skip CTRL1 preload as a workaround, but prefer to understand the reason why the driver doesn't work as expected.

For the case that you would like to try it out: here an alternative sequence, where CS is strobed after each 16bit transfer:
http://www.ucapps.de/mios32/midibox_ng_v1_033_pre9_aout_ng_multics.zip

It might work, but I see the potential problem that the first DACs will temporary output the voltage of the following DACs (and I can't believe that this is the intended way how to preload the DACs). :-/

Best Regards, Thorsten.

Gonna test it tonight if I find the time. When you say "where CS is strobed after each 16bit transfer" you mean only during init phase? Afterwards, the whole 4*16bits need to be sent between CS (named FS in the datasheet), otherwise the first DACs will repeat the output as you described.

 

Just to be sure we are talking about the same thing. You do init the following way for 4 modules with midibox_ng_1_033_pre9_aout_ng_multics:

1000 0000 0000 1000 (CTRL0 setting DOUT=on)
FS
1001 0000 0000 0000 (CTRL1 setting everything to default)
FS
1011 0000 0000 1000 (blank) or setting any AOUT to 0
FS
1011 0000 0000 1000 (blank) or setting any AOUT to 0
FS
1011 0000 0000 1000 (blank) or setting any AOUT to 0
FS
This way, all DACs receive CTRL0 and CTRL1. After that, you normally send 64bits followed by a CS continuosly to update the AOUTs?

 

of course, you could also do someting like this to keep the 64bits and one clock rhythm:

1000 0000 0000 1000   0000 0000 0000 0000   0000 0000 0000 0000   0000 0000 0000 0000
FS
1001 0000 0000 0000   1000 0000 0000 1000   0000 0000 0000 0000   0000 0000 0000 0000
FS
0000 0000 0000 0000   1001 0000 0000 0000   1000 0000 0000 1000   0000 0000 0000 0000
FS
0000 0000 0000 0000   0000 0000 0000 0000   1001 0000 0000 0000   1000 0000 0000 1000
FS
0000 0000 0000 0000   0000 0000 0000 0000   0000 0000 0000 0000   1001 0000 0000 0000
FS

 

Or am I completely mistaken?

Best Regards, Andy

[TK.]

We should stop speculation... ;-)

I will solder three chips on a veroboard so that I can try out different update strategies in order to find the best (and hopefully) working one.

Best Regards, Thorsten.

 

[Zam]

It seems that the TLV5630 chip doesn't shift the data as expected (and unfortunately the datasheet doesn't make clear how to handle the cascading software-wise)

However, I've some spare chips but no PCBs. I will solder them on a veroboard to debug the transfers soon.

Best Regards, Thorsten.

Just for info, there is a guy "rochey"at groupDIY, I believe he work at TI as dev or something like that, maybe he can help for specific info that are not so clear in datasheet.

Best

Zam

[TK.]

Ok, I finished the prototype and fortunately the HW itself worked immediately ;-)

The issue was as initially described by Andy: during the initialisation phase, the DOUT pin has to be enabled step-wise for each chip in the chain before the next one can be accessed:

      // initialize CTRL0
      // Note: with each CTRL0 access we enable the DOUT pin which is connected to DIN of the next module
      // Therefore we've to strobe FS after each 16bit transfer to ensure that the next module will get the following data
      for(dev=aout_num_devices-1; dev>=0; --dev) {
        MIOS32_SPI_RC_PinSet(AOUT_SPI, AOUT_SPI_RC_PIN, 0); // spi, rc_pin, pin_value
        // DO=1 (DOUT Enable), R=3 (internal reference, 2V)
        u8 ctrl0 = (1 << 3) | (3 << 1);
        MIOS32_SPI_TransferByte(AOUT_SPI, 0x8 << 4);
        MIOS32_SPI_TransferByte(AOUT_SPI, ctrl0);
        MIOS32_SPI_RC_PinSet(AOUT_SPI, AOUT_SPI_RC_PIN, 1); // spi, rc_pin, pin_value
        MIOS32_DELAY_Wait_uS(1); // short delay to ensure that RC will be pulsed by at least 1 uS
      }

In addition, a short delay was required to ensure that the data is taken before accessing the next chip!
(these are the details which are very time consuming to debug remotely, could have caused additional iterations without direct access to the HW!)

All other transfers are working as intended: set FS=0, transfer n x 16bit data, set FS=1 -> data will be taken over

Please try this version at your side: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre10.zip

No need to try any pre9* version (because it will set FS for each 16bit transfer, also for channel value updates, which isn't required and will lead to unnecessary glitches)

Best Regards, Thorsten.

[Highcooley]

Wow, 160 bucks on a veroboard 

Thanks for the fix, it should work a treat. Giving you feedback asap. Shall I do any testing with different number of DACs or have you already done that?

 

Best regards, andy

 

Update: Yep, all working fine now with every reset and power-up I tried with 4 DACs. The synth starts to sound cool

Thanks a lot (and secretly hoping that my other issue with the DIO matrix turns out to be a software problem as well) 

Edited September 23, 2015 by Highcooley
test done

[TK.]

Actually I used the cheap TLV5631, and I got them as free samples many years ago ;-)

Great that it's working now - yes, I tested with different DAC numbers :)

Best Regards, Thorsten.

 

[Zam]

Hi TK

Just a question about TLV5631

As the price is 1/3 of the 12bit version, I'm thinking of using it for my fader CV out data which work fine at 10bit and I don't see any reason to have better resolution (0,1mm travel is way enough).

Ca I expect to run 5631 at full res 10bit and having the same precision than a 5630 downgraded at 10bit.

Data sheet talk about full scale and non linearity error but I have no idea how this translate for real at DAC output.

Best

Zam

 

 

[TK.]

Ca I expect to run 5631 at full res 10bit and having the same precision than a 5630 downgraded at 10bit.

yes
If you only need 10bit, 5631 is a good choice.

Best Regards, Thorsten.