protofuse

I found little case for my psu: I guess it wouldn't be enough to insulate it. someone could tell me the correct name for the proximity effect I have between wire and psu? is it the famous EMI?

super beau ! je suis moi même en train de finir ma protodeck et suis en train d'hésiter : changement d'alim ou pas. car elle "rayonne" pas mal et perturbe les cables de mes potentiomètres proches... grrrrrrrr! les pots sont là si qques uns sont intéressés: http://www.midibox.org/forum/index.php/topic,14189.0.html sinon tout sera exposé là : http://www.julienbayle.net/diy/protodeck/ et pour l'instant, le blog de la construction est là : http://www.julienbayle.net/diy/protodeck/

thanks for all advice and ideas! I think 99% of this problem is the proximity influence effect and not the "noise over the wire" I have to insulate better the PSU from pots and wire near from it. or move my psu in the box at another side.. I don't know. or build a faraday shield :) or ??

I can confirm that. no problem now. I isolate a bit with a little piece of plastic direclty put over the PSU which doesn't heat too much... so no prob with that. the path of cable is better too, but could be improved! but in order to be safer & more reliable, I guess it could be better to use a linear PSU very less noisy. I didn't test with 2 capacitor cause 99% of this problem came from the proximity between cable & PSU (I mean: bypass capacitor doesn't fix that)

I'm on this right now.. I insulate better pots wire / PSU & I replaced this freaky deadly 4051................. NO PROBLEM OCCURED sinde 10minutes moving the frontpanel, testing etc. by "insulate", I only mean: make a better path inside the box. btw, you're right. I guess the PSU is noisy. But indeed, I probably don't have to change it.

thanks nILS. about the PSU, I'd be able to rebuy a new one. I sized this one because I was afraid about power consumption. the one I bought is : ECM40 What kind of PSU could you advice me in order to match 5V, around 4A and WITHOUT noise ? ? ?

the main aggregator about the protodeck's troubleshooting war is this one the post where I found and understood my noisy PSU effects is that one so I can begin.. I read a lot about bypass capacitor. this article was very good for me to understand well the system. instead of changing my psu now, I'm going to put several capacitor at the place where I supply the protodeck modules. I'm using the smashTV last revision modules so everything gets capacitors near from each IC. even the AINx4 I use, those that gave me headache with my noisy PSU. I read that with long cable (and unshielded) it could be nice to use bypass capacitor too. in the previous link, it is writtent: so the question is: may my system be improved by adding a couple of capcitors correctly place here and there on my 5V/GND supply of all pots? here and there mean, for instance, at each rows or something like that... Do the bypass capacitors at the PSU side of my pots supplying wire enough or not ? my schematic is this one: even if it could improve a bit, I can put them to have a more stable system. any help, ideas, words from you increase my knowledge, so help would be very appreciated :)

a nice site that clearly explains bypass capacitor concept: http://www.seattlerobotics.org/Encoder/jun97/basics.html

TK answered :)

could you paste your code here...?

adn?

I changed all the AIN<>CORE cable by shielded one. nothing has really changed. I found one of the 4051 was freaky dead ! easy to isolate. I had doubt so I putted it at the end of the AIN chain and put the value of pots in main.h to 56 in order to let it for later... so now I 'm sure it is a dead component (or almost dead) my PSU seems to be noisy (it is a switchmode PSU) the proximity between pots wire (ribbon between pots and AIN) and PSU gives me big flow of false detections. so I had around 2 problem, but one consequence: freaky flow of false detections. indeed, by puttin the cable far enough from psu, I decrease the data flow false detection by an amount of 10000. really. after that, I found sometimes little false detections, but only between very little range of values. I guess DEADBAND parameter could correct a little bit this. but it isn't made for it, I guess (too) so, one big advice: - buy good PSU as less noisy as possible. (switchmode means noisy, too) - put a big distance between pots wires and PSU tomorrow, I'll try to put a couple of capacitor between 5v and GND at the main supply of the protodeck. we'll see. but I guess my problem is found and almost solved (at least in my head!) big thanks to nils who didn't laught at me too much with my questions and tests ;)

it all depends of your apps. paste the code

hello nebula, already bought some shielded wire. I'm trying that asap! I'm a little bit despaired by all of that.. I tried to do my best in all step and this unstability problem gives me headache it is only with (some) pots, I mean: some ain. leds, buttons are very ok ... indeed, it is positive :)

should I move all my pots cable to these ? http://fr.farnell.com/3m/3517-10/cable-en-nappe-10-voies-par-m/dp/8608571 or maybe, only CORE<=>AIN cable.. my problem comes only from this cause: proximity between wiggling analog cable from pots & digital cable between CORE<=>AIN

apparently, groundind the case isn't a way... I'll recheck all my connections and just hope I won't have to REDO ALL THE POTS wiring ?!!!! nILS and ssp helped me : I would have to check the analog and digital cable proximity... near from AIN and core. and I guess it could be the problem. indeed, "moving cable analog" means "make cables closer from the SR, from the digital line" ..... it should be the cause! I'll test it asap !

I have to add this. I read http://www.midibox.org/dokuwiki/doku.php?id=troubleshooting#how_can_i_avoid_pot_flickering_jitter, and http://www.midibox.org/users/tor_arne/midibox64_walkthrough/potsbuttons.html and other precious posts. My frontpanel & my box aren't connected to ground. could it really fix that? I mean, I can test it but, does the reason come from bad soldering/wiring?

My last problem deals about AIN/pots. Here is a schematic of the pots wiring of my protodeck (attached piece) I have 2 core. AIN are all AINx4 & are named like that: AINxy (x=core number, y=AINx4 number in the chain) AIN11 is filled with 32 pots. none problem with them ! nothing strange etc. AIN21 is like shown on the schematic: - SR1: 8 pots ok - SR2: 8 pots - SR3: 8 pots - SR4: 6 pots + 2 pins clamped to GND AIN22 is like shown on the schematic: - SR1: 6 pots + 2 pins clamped to GND - SR2: 6 pots + 2 pins clamped to GND - SR3: 8 pots - SR4: 5 pots + 3 pins clamped to GND as I have to scan all pots in the chain, my MIOS_AIN_NumberSet(AIN_NUMBER_INPUTS); goes with AIN_NUMBER_INPUTS defined to 64. strange things happens witj AIN21 and AIN22. if I "touch" SR with my finger, or by squeezing corresponding flat ribbon onto them, randomly value appears... on pins corresponding sometimes, when I turn pots on AIN22-SR1 for instance, 0 value is 0 (ok), I turn it ... value increase, but decrease inconsistently and become 0 instead of 7F the biggest problem is... it happens sometimes (I guess, when i touch flat ribbons connection to SRs) sometimes all seems very ok. but I need a more reliable deck so questions are: - does my wiring seems to be VERY strange? (flat ribbon for values, red/black 0,25mm wires) - what should I test first? in second ? I mean , a process to track that... I checked my midilink, it works very fine: I mean, pots value from core1 (from AIN11) are VERY stable, reliable etc. I checked 10 times my GND clamps... seems ok. any help would be very appreciated!

Thorsten... what a big and precise answer! I'll test it as soon as I had my AIN/Pots problem solved! I'll put it in the protodeck post. of course, I have to thank you a lot for me ... and for us!

as suggested by TK, I'm opening this thread in order to aggregate all the tests/troubleshot and solutions I found here and there. - rgb led matrix & common anode matrix & ISR solved => code was ok, but static keyword involves "non loading" at startup - DIN problem, strange messages received in midiOX solved => I listened midi link encapsulation, cause I didn't listen at the right place (wrong midi out..) - blinking led a BIG TK's answer not tested yet by me - false detection by 4051 analog mux this post itself, see lower AND this post too I'll update this thread as soon as I'd have solutions, questions etc etc. I hope it is ok for all the eventual helpers... ;)

I think the problem came from midilink command MIOS_MIDI_BeginStream and MIOS_MIDI_EndStream... Those message named "stranged" in my post were only encapsulation for midilink purpose... and my interface had a strange behaviour when it receives it ... only that. all is ok now!

I guess you proved this doesn't change thing... so I may probably make a mistake by changing, changing and rechanging .. btw, the last code works fine. I have the same kind of problem with AIN I'll track it asap! thanks a lot TK

E:\JU\ECLIPSE\_rootDev\protodeck_CORE_1>sdcc --version SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.8.0 #5117 (Mar 23 2008) (MINGW32)

everything is fine now. I don't really understand. I forced (unsigned char) cast of my array value in DIN_NotifyToggle... compilation issue ??? 18F4620 specific thing ??? by the way, it works fine now :)

Thorsten, I wanted to separate post because I thought about separate problems. I can do as you'd prefer. your test works very fine. only note on and note off message sent! is it a type issue? my mapping array is: const unsigned char button_event_map[64][2] = { //------- clip matrix control //-------- DIN11 // Buttons 1-8 = tracks mute = channel 1-8 {0x90, 0x01}, {0x91, 0x01}, {0x92, 0x01}, {0x93, 0x01}, {0x94, 0x01}, {0x95, 0x01}, {0x96, 0x01}, {0x97, 0x01}, // Buttons scenes 1 = 9-16 = channel 1-8 {0x90, 0x02}, {0x91, 0x02}, {0x92, 0x02}, {0x93, 0x02}, {0x94, 0x02}, {0x95, 0x02}, {0x96, 0x02}, {0x97, 0x02}, // Buttons scenes 2 = 17-24 = channel 1-8 {0x90, 0x03}, {0x91, 0x03}, {0x92, 0x03}, {0x93, 0x03}, {0x94, 0x03}, {0x95, 0x03}, {0x96, 0x03}, {0x97, 0x03}, // Buttons scenes 3 = 25-32 = channel 1-8 {0x90, 0x04}, {0x91, 0x04}, {0x92, 0x04}, {0x93, 0x04}, {0x94, 0x04}, {0x95, 0x04}, {0x96, 0x04}, {0x97, 0x04}, //-------- DIN12 // Buttons scenes 4 = 33-40 = channel 1-8 {0x90, 0x05}, {0x91, 0x05}, {0x92, 0x05}, {0x93, 0x05}, {0x94, 0x05}, {0x95, 0x05}, {0x96, 0x05}, {0x97, 0x05}, // Buttons scenes 5 = 41-48 = channel 1-8 {0x90, 0x06}, {0x91, 0x06}, {0x92, 0x06}, {0x93, 0x06}, {0x94, 0x06}, {0x95, 0x06}, {0x96, 0x06}, {0x97, 0x06}, // Buttons scenes 6 = 49-56 = channel 1-8 {0x90, 0x07}, {0x91, 0x07}, {0x92, 0x07}, {0x93, 0x07}, {0x94, 0x07}, {0x95, 0x07}, {0x96, 0x07}, {0x97, 0x07}, // Buttons scenes control = 57-62 = CHANNEL 16 {0x9F, 0x01}, {0x9F, 0x02}, {0x9F, 0x03}, {0x9F, 0x04}, {0x9F, 0x05}, {0x9F, 0x06}, // Buttons offset control = 63,64 = CHANNEL 16 {0x9F, 0x07}, {0x9F, 0x08} }; and you learnt me const are loaded at starting time (instead of static) :)