Jump to content

Multiple AOUT_NGs


Highcooley
 Share

Recommended Posts

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

 

 

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 4 months later...
  • 4 months later...
  • 6 months later...

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

 

   

 

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 by Highcooley
new discovery
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Highcooley
Link to comment
Share on other sites

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 by TK.
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

mbhp_aout_ng_chained.jpg

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.

Link to comment
Share on other sites

Wow, 160 bucks on a veroboard :grin:

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. :sweatingbullets: The synth starts to sound cool :sunglasses:

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

Edited by Highcooley
test done
Link to comment
Share on other sites

  • 4 weeks later...

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

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...