Highcooley Posted June 3, 2014 Report Share Posted June 3, 2014 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 Quote Link to comment Share on other sites More sharing options...
Highcooley Posted June 3, 2014 Author Report Share Posted June 3, 2014 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! Quote Link to comment Share on other sites More sharing options...
lukas412 Posted June 3, 2014 Report Share Posted June 3, 2014 Nice avatar! Quote Link to comment Share on other sites More sharing options...
TK. Posted June 3, 2014 Report Share Posted June 3, 2014 I won't delete this topic, because it's a useful confirmation that two chained MBHP_AOUT_NG modules are working :) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted June 4, 2014 Author Report Share Posted June 4, 2014 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! Quote Link to comment Share on other sites More sharing options...
Alasdair Moon Posted October 20, 2014 Report Share Posted October 20, 2014 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 .. Quote Link to comment Share on other sites More sharing options...
TK. Posted October 20, 2014 Report Share Posted October 20, 2014 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. Quote Link to comment Share on other sites More sharing options...
Navicat Posted March 4, 2015 Report Share Posted March 4, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted March 8, 2015 Report Share Posted March 8, 2015 It should work this way (up to 32 channels are supported) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted September 11, 2015 Author Report Share Posted September 11, 2015 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 setAOUT type=AOUT_NG cs=1 num_channels=24 (cs=0 still used for AINSER)and addressed the new channels withfwd_id=CV:17upwards But nope, no response yet. Thanks for your reply! Cheers,Andy Quote Link to comment Share on other sites More sharing options...
TK. Posted September 13, 2015 Report Share Posted September 13, 2015 I've to test this at my side if nobody is using this configuration yetBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted September 13, 2015 Author Report Share Posted September 13, 2015 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted September 21, 2015 Report Share Posted September 21, 2015 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.zipBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted September 22, 2015 Author Report Share Posted September 22, 2015 (edited) Hey ThorstenThanks 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted September 22, 2015 Report Share Posted September 22, 2015 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. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted September 22, 2015 Author Report Share Posted September 22, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted September 22, 2015 Report Share Posted September 22, 2015 (edited) 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.zipIt 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. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted September 23, 2015 Author Report Share Posted September 23, 2015 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.zipIt 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)FS1001 0000 0000 0000 (CTRL1 setting everything to default)FS1011 0000 0000 1000 (blank) or setting any AOUT to 0FS1011 0000 0000 1000 (blank) or setting any AOUT to 0FS1011 0000 0000 1000 (blank) or setting any AOUT to 0FSThis 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 0000FS1001 0000 0000 0000 1000 0000 0000 1000 0000 0000 0000 0000 0000 0000 0000 0000FS0000 0000 0000 0000 1001 0000 0000 0000 1000 0000 0000 1000 0000 0000 0000 0000FS0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 0000 0000 1000 0000 0000 1000FS0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 0000 0000FS Or am I completely mistaken?Best Regards, Andy Quote Link to comment Share on other sites More sharing options...
TK. Posted September 23, 2015 Report Share Posted September 23, 2015 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. Quote Link to comment Share on other sites More sharing options...
Zam Posted September 23, 2015 Report Share Posted September 23, 2015 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.BestZam Quote Link to comment Share on other sites More sharing options...
TK. Posted September 23, 2015 Report Share Posted September 23, 2015 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 overPlease try this version at your side: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre10.zipNo 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. Quote Link to comment Share on other sites More sharing options...
Highcooley Posted September 23, 2015 Author Report Share Posted September 23, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted September 24, 2015 Report Share Posted September 24, 2015 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. Quote Link to comment Share on other sites More sharing options...
Zam Posted October 20, 2015 Report Share Posted October 20, 2015 Hi TKJust a question about TLV5631As 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.BestZam Quote Link to comment Share on other sites More sharing options...
TK. Posted October 25, 2015 Report Share Posted October 25, 2015 Ca I expect to run 5631 at full res 10bit and having the same precision than a 5630 downgraded at 10bit.yesIf you only need 10bit, 5631 is a good choice.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.