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.
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.
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 ..
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)
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.
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!
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.
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.
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.
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). :-/
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:
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.
