noofny

Here I come again with my obvious general questions! ;) Isolate the issue is your best friend. If you swap the connections from AIN->CORE around does the same problem happen on both cores? This is basically isolating the problem to be a core or ain issue. Then I would suggest if you can, swapping pots between AIN's - this isolates the problem to a single AIN module. Also I would try swapping the SR's around to see if the problem may be a flaky SR (not likely tho). Did you solder the filter caps onto the AIN's ? Some people like myself don't seem to need them but others do, but it can affect things. And don't forget to power down any nearby Deathstars or particle accelerators whilst testing MidiBox... (sorry) 8)

well done dude! shame about besthongkong...you should be able to return hopefully

I'm not sure if this is the cause of your problem but I noticed your code reads; Code: ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS before the shift register are loaded ///////////////////////////////////////////////////////////////////////////// void SR_Service_Prepare(void) __wparam { // HELPED BY BUGFIGHT ON MIDIBOX - http://www.midibox.org/forum/index.php/topic,12786.0.html static unsigned char row; unsigned int x; //edit* just noticed, no reason for this to be static row = ++row & 0x07; //<-- here you were cycling 16 rows i think you meant 8, no? //this would have resulted in a 6.25% duty cycle (vs 12.5%). //note that the duomatrix uses a 25% duty cycle MIOS_DOUT_SRSet(_MATRIX_DOUT_START, 0); //<-- hardwire bad, napster good. define constants // so you can move your matrix in the chain MIOS_DOUT_PinSet1(row); for (x = 0; x < 8; x++) { DisplayLED(x , matrix[row][x]); } } whereas if you remove the reference to 2nd DOUT mine would be; void SR_Service_Prepare(void) __wparam { // HELPED BY BUGFIGHT ON MIDIBOX - http://www.midibox.org/forum/index.php/topic,12786.0.html static unsigned char row; unsigned int x; //edit* just noticed, no reason for this to be static row = ++row & 0x07; //<-- here you were cycling 16 rows i think you meant 8, no? //this would have resulted in a 6.25% duty cycle (vs 12.5%). //note that the duomatrix uses a 25% duty cycle MIOS_DOUT_SRSet(_MATRIX_1_DOUT_START, 0); //<-- hardwire bad, napster good. define constants so you can move your matrix in the chain MIOS_DOUT_PinSet1(row + (_MATRIX_1_DOUT_START * 8)); for (x = 0; x < 8; x++) { DisplayLED(x + (_MATRIX_1_DOUT_START * 8), matrix_1[row][x]); } } So what is actually the problem you get - is it no lights at all? And how are you testing? When I tested mine first I made a function that was called after INIT - event though this is not ideal - it removes other possible problems like MIDI related or button/DIN/AIN related causes. I would reccomend updating your code to my example above, then set a whole row/column of LED's on and put a multimeter accross various pins to see where voltage is being directed. Ensure that voltages are getting to your DOUT and ULN's first. It could be that it is working but the wrong columns/pins are being sent voltage....just some ideas to try. Sorry I cannot be much more help at the moment but try those things and let us know your results. The LED matrix can be tricky to get working - you do need to understand a few things and I think I speak for most of us here when I saw it's pain we all share with you but you'll get it going soon.

I think for this you will have to learn about MIDI spec and get comfy with decimal/binary/hex and ASCII codes. There’s tons of stuff around, sift around and after a few sleeps it will sink in and you’ll get it. Some sites I found usefull for MIDI were; http://www.midi.org/aboutmidi/resources.php http://www.gweep.net/~prefect/eng/reference/protocol/midispec.html http://www.srm.com/qtma/davidsmidispec.html Good luck! :)

Cheers dude! Now I'm trying hard to not start the next one...need to stop spending $$ for a while!

no way worthy of that....but thanks anyway...i only made my posts hoping i could inspire/motivate someone else to try it for themselves. but thanks for the response

Right - that's it - the project is finished! 8) http://noofny.blogspot.com/2009/05/projectclose.html Now it's time to get down and dirty with some sets (and upload the doco to the wiki).

lol...well thanks...but no need to be jealous...just make your own! :P

She's almost done now...got the face plate fitted...very exciting times! http://noofny.blogspot.com/2009/05/almost-done.html Once I clean the doco up I'll post a page on the wiki.

john, sorry about the longdelay - have moved house and been offline for a while. in my midibox sofftware i kind of hard-code the pot values to various control change events. you wont see any handling of these specifically in my liveapi script because I used the UI to 'learn' these pots. Later down the track I'll probably move this into the api script so it's easier to understand. Hope this helps.

think this might help; http://www.ucapps.de/midibox_lc/midibox_ng_switching_psu.pdf from; http://www.midibox.org/forum/index.php/topic,2081.0.html

Of course - thanks - have posted there. :)

I followed the steps to setup Putty and generate the key etc here; http://www.midibox.org/forum/index.php/topic,10691.0.html http://www.midibox.org/dokuwiki/doku.php?id=windows_toolchain_svn#putty but when I connect using Putty I get; Using username "svn". Server refused our key svn@svnmios.midibox.org's password: I stepped through the process again very carefully...am I missing something? Read access is working fine...just the write access using ssh aint. cheers

Great - thanks TK.

anyone??

haha...well thanks all the same bugfight TK can i buy you a beer through paypal...? :D

I'm almost done making my midibox and getting the code working...and wondering if it's worthwhile adding my code to the source repo? Some of the code is very much customized to my needs but there may be some things others can benefit from. Am happy to share it anyway. I've found some posts about some developers lounge - do I need access to that or can I use svn to checkin?

have implemented all the advised changes and not only does everything still work but things seem to be working better...not yet tested lighting up both matrix's full tho...has been a good learning task. bugfight - thanks so much mate - I owe you a beer - what do you drink? 8)

sorry have been away from the project for a few days...needed a break....thanks bugfight and julian for your posts. Had a quick look over the code changes and think I understand them all so will be refactoring the code tonight and will post the results. Apart from that - so long as I dont try light up all the LED's as white things are working so at least it's not a show stopper!

bugfight - I can't thank you enough for taking the time to help out - have felt a bit lost with this one! Good idea I'm familiar with that, will stay away from calling stuff in Init(). Yeah did that over the weekend...even swapping the SR chips around for a spare set, etc. Doesn't seem to change anything. Do you mean try bypassing the darlingtons altogether? I would really welcome and appreciate that...didn't want to ask...if you have the time PM me your suggestions/critiques/ideas.

Other things I'm thinking it might be; 1) Length of cables going from SR outs to the LED's....longest ones are around 40cm. 2) Is my connection correct? CORE J8 > 1st DOUT J1 then 1st DOUT J2 > 2nd DOUT J1 3) My dodgy code routines for driving the matrix (full code file attached) 4) Not possible - nobody else has ever ran 2 full 8x8 led matrix's off a single core? 5) Am I trying to bite off more than I can chew...too many electronics knowledge gaps? ain64_din128_dout128_v2b_CORE_2.zip ain64_din128_dout128_v2b_CORE_2.zip

ok so i can stop rambling about the darlingtons cheers! not sure where you mean by those caps...i already put in the bypass caps shown here for the dout in and the sr's; http://www.ucapps.de/mbhp_dout.html

The LED's are these; http://www.besthongkong.com/product_info.php?products_id=41 DC forward voltage : VF (IF =20mA) Green & Blue: 3.2V-3.4V Typ, 3.8V Max Red: 1.9-2.1V Typ, 2.4V Max DC reverse current : IR (VR =5V) 100uA Wavelength : Wd (IF = 20mA) Red: 625nm Green: 525nm Blue: 470nm The psu is a switcher....not a cheap one...from farnell. The 5v rail is rated at like 6 amps so I guess there's plenty of available current to draw on. Not having any probs with pot values jittering or other signs of dirty power through the circuit. I'm still wondering if the problem is related to the fact I haven't connected the COM pin on the darlingtons to anything ? The DOUTs work singly yes...this is how I'm connecting them; CORE J8 > 1st DOUT J1 1st DOUT J2 > 2nd DOUT J1

What I dont understand though, is that I can have all pins active on a single DOUT (ie all annodes lighting up all LED's) and the dout/core handles fine. It's only when I chain the 2 douts from the core that it cant manage. The DOUT's themselves seem to be handling fine driving all LED's on at once and it's nice and bright. I guess what you're saying is if in order to chain the 2 DOUT's I've gotta get all the currents correct and may have to use the resistors because of the greater load the 2nd set of SR's introduce to the core? The other thing I'm not sure about is with the darlingtons - I have only connected the GND to the DOUT GND. There is nothing connected to the COM pins on the darlingtons. Should I be connecting the COM pins on the darlington to +5v from my power supply? I guess that also means I should connect the GND pins on the darlington to the GND on my power supply? Appreciate all the help too guys.

bugfight - thanks for the response and question - I omitted them because the LED's were too dim with them (I tested with ~30k on red, ~25k on green, ~20k on red )...I thought this was strange but never asked anyone about it - just left all resistors out - all seems very nice and normal without them until now. Do you think this could be the cause? I think my problem is my ULN's are hooked up through the CORE>DOUT power chain. Shouldn't I be hooking up the ULN GND/COM to the power supply GND/+5V ? I'll draw up a rough diagram tomorrow morning and attach it...might explain things easier.