henrygr

QBAS, You got the C-Code scanmatrix to work with velocity! You have already inspired me!! Mark. :P

Nice photo Jidis, he he he... ;D

Not an expert on LF PIC, but I don't think it will cut thr turkey. Search the forum regarding that, as I have read elsewhere before that that is the case. When you get a 9v. battery tomorrow, do a voltage check, and at least that will tell you if the multimeter is on the blink. You need to get the voltage right, or, from experience, what is programmed on the PIC will not work right. I wouldn't put the PIC back in till that is the case, so the next time you put the PIC in will be the last time. No more wear and tear on the pins! In the past, I have incurred problems with power supply, that had my PIC giving me anything but crap. When that was the case, I reloaded the bootstrap via midi cable (MIOSStudio, Manual upload, not Smart mode), then MIOS (again, Manual), then my app (via MidiOx- I send the sysex file). Important to point out that you should upload the first two within two seconds of powering up. I know you told me before, but what is your midi interface to PC? And by the way, did you check the caps for leakage? That's all that I can think of for the moment. Will post more if it comes to mind. Oh yeah, it's always a good idea to run your pots consecutivly ie don't load a pot on pin two if pin one isn't loaded, and always leave pin one at the end of the Vs/Vd chain. See here http://www.midibox.org/users/tor_arne/midibox64_walkthrough/potsbuttons.html. I know you are currently running the full MBox64 in ASM. If you want, I will email you a sysex file that will cut down the core to an UnMuxed state (ie connect you pots directly to the core) for troubleshooting, and any other sysex stuff you might need to get to the bottom of this. It will save you seting up the c-code comiler on your PC, which at this stage might side track you, although I do recommend it for the future, for writing your own apps. In fact, I think it may be a good idea to strip away the AINX from the set up at present, just to pinpoint the problems, and then expand from the smallest set up possible- the solitary core. My email can be found in my profile. See what you think. Mark.

OK. There are two common components left. The PIC and the power supply. Power Supply: Can you get hold of a nine volt battery and power the unit that way, then do the voltage tests (BTW what you call 'resistor tests', should in fact be 'resistance tests') PIC: What PIC is it? Mark.

What are the voltages? Not sue what the above means!

Shoot santa clause is another idea I got from the experience....

I find this whole thing fascinating. What was the original design of the whizzer? Any clues to be has there? How did they achieve memorising etc?

I agree, stryo_one, if I had the math right!! Messed up on the equation end of thing for early. Anyway, the way it wotked out, the drawbars left a lot to be desired in terms of unwanted signal, so I was to filter that out by giving it a DEFAULT value with SWITCH/CASE and using a simple argument not to process it. Will do that WIKI at some point on the whole drawbar issue, as I've done a few at this stage. I was thinking that perhaps a section on retro-fitting in the WIKI would be a good article to start up, as there are quite a few thing here on the forum (QBAS getting the c-code scan matrix working on an old alesys being but one) that I think well deserve a topic of their own. No? Thanks again, Mark.

http://ucapps.de/mbhp_core.html IIC module.

What the hell was I thinking. Next time, I'll multiply myself in two so I can take proper aim and shoot myself. :o I could remove all the crap below, but I'll leave as a humble reminder to myself of my own stupidity. :P Apologies to all, and thanks to all. ;) Switch case arguments worked out just dandy. I think i'll have a hot cup of tea to celebrate. Hoorah!! (my ar*e. Off to the pub for lashings of beer, me thinks.....he he he.) Case Closed. Mark. ;D

I would imagine if it was rounding off 4.8v it would go to 5v. You have a major problem here in terms of functionality. Directly check your meter if you want to see if it is that. But, irrepestive, even with 12v at 500ma, you should be getting 5 to 5.4 volts at most of the locations. Lets remove that PIC till we get to the bottom of this as a safety measure. The drop in voltage would explain the random data. Check the joints on IC3 (7805). If its nor even getting warm, then it sounds that it may not be connected properly. Also check the joints on C4, , C5, C6, T1 and BR1. The best way to do this is, on the printed side of the PCB, trace the printed circuit from the base of the pin you are testing to the next available bare area (if you are using SmashTV. Otherwise touching the coppper would do fine). Put one end of the multimeter at this area, the other to the pin on the far side of the board (this may be difficult if you have soldered the components close to the board) and check for resistance. For example, to check the middle pin of TI, check for resistance between the pin itself, and the joint of R4 where it meets the board closest to IC3. Make sense? Anyway, you'll figure it out. Another tip is a soldering one. If you find that a joint is not right, rub the solder that is already there with a bit of flux. (I use plumbers flux, which has a smooth ceamy consistency like Oil of Ulay, but I wouldn't recommend rubbing it on the face, though admiteddly, considered giveing it to my mother-in-law for christmas). This has the effect of thinning out the solder as you heat it, and lets is set better around any contact that is there. Keep me posted. Mark.

The PSU sounds fine, althouh SmashTV was right, I should have pointed you toward that earlier. SamshTV also makes a very valid point in that if you don't nail this now, it will get worse. Before you remove any componants, set up he resistors as I pointd out earlier, and then jiggle bits on the core (not very scientific, I know). If there is a loose connection, and you somehow find it, the jitter may stop momentarily. Also check your voltage across the board with reference to the following http://www.ucapps.de/howtodebug/mbhp_core_extract_measuring_vdd.gif. Actualy, do the above in reverse order....

Modified Post. Rushed it first time. Apologies. The intention was to show the idea in algebraic form. My query is whether the Pic can handle this type of function on the fly. What's it for?- This linkhttp://www.midibox.org/forum/index.php?topic=8276.0 The values I get from the resistors I used go from 55 to 126, almost sequntially- close enough for jazz. Reason- these were the resistors I had lying around, and there were no chances of me going to Maplin electronics during xmas/january sales. So, moving along, I need to pass the signals to Native instruments B4, my clonewheel of choice. Values passed into this do not have to be exact, but close enough for jazz!! Hence: . First value is the value passed from the M1 drawbars, second value is what B4 will use for moving drawbar (ie the midi signal it sends on moving a drawbar), but it will accept a value close to latter for actually moving them eg will move to stop 8 from midi signal 121 and above. This has made my day. I am not the only one doing it, yipppeee. And I must add- he he he. So, passing the algebraic function into C unsingned char midiInputValue = MIOS_AIN_7bitGet(pin); //Do I leave the underscores? unsigned char midiOutputValue = (midiInputValue - 55) * 2; //then sending the third value on pot movement: MIOS_MIDI_TxBufferPut(midiOutputValue); // where normally this reads - // MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); How does it look? Has it a leg to stand on?

I think it's a fair conclusion to say that there is something loose on the core side of things. I mean, with the resistors, we have given a voltage that is exact, leaving no room for mechanical error, and still the jitter comes. Jitter generally only kicks of after a voltage return of some sort has been sent to the AIN (this is a broad generalisation, but concise enough for this examle). If you are getting jitter, then there is leakage, and that has to be somewhere in the soldering or in the capacitors. Check your caps with a multimeter set to, say, 20k resistance. If there is nothing but 100% resistance then the cap is faulty (can be a bit tricky checking them on the board, as the circuit may completes at another point that will give you a fals reading). Check tha solidity of all soldering. If it turns out to be none of the above, at least you're two steps closer to the resolve ie figuring out what it is not!! Mark.

Were you holding the pot in your hand?

Antoher idea struck me driving home from picking up the kids (always amazes me when these things strike home). The relationship between the AIN (call it x) and the desired midi output value (call it y) is roughly; 2(x-55) = y ....and that's close enough for jazz. How is the PIC chip at dealing with these types of formulae? Any comments, as ever, much appreciated. Mark.

filmcomposer, here is a link that, at this stage, I have memorised, http://www.cprogramming.com/tutorial.html I am possibly the worst at CCode around here, but manage to get by. :o

He he. I have developed the great habit of compiling after every line of code, kind of helps pin point badly written p's and q's. Anyways, going to go with switch and case. The string of variables isn't really that long, and I don't really seeing it taking up too much valuable RAM. I will say this though, that when I can't see the wood for the trees when it comes to programming, I find it helps just to get what's off of my chest any ideas I do have and post them here. Thanks all for putting up with it. ;D

Ahh. You have the full app, of course. If you are set up to compile in C, follow this link and adapt as previously mentioned http://ucapps.de/mios_c_send_ain.html and here http://ucapps.de/mios_c_send_mapped.html. If not, then a workaround would be such. I know you have done most of it, but bare with me... Ground everythhing bar te first pin. Try your pot. If it jitters then do the following. Run three leads from the Vs, Vd and the AIN. Take a resistor of a value about 7.5k, and connect it between the Vs and the AIN, There should be no jitter, as your AIN is esentially grounded, as though you had turned a pot three quarter ways around away from where the Vs was connected. Take a second resistor of a value about 100R. Use this to connect the Vd to the AIN, while the Vs is still connected. The value in MidiOx should change to about 126 in Midi terms, and when you break the contact, the value should return to zero, WITHOUT jitter. If it helps, use the Vs of J2, and the Vd of J4. If this works, then your pot is dodgy, and if there is still jitter, check C6 for proper connection. Hope this helps, Mark.

Thank you TK. ;D I had a look at that code. I think it assumes that you are using a pot or fader that goes, in normal operation from 0 to 127 (I will keep it in midi terms), and will return a value scaled to whatever amount between those two values. My predicament with the matrix I built is that the input values go from 55 to 126 (and not necessarily on a scale), and need to output values between 0 and 127. There is on good bit of news though, and that is that the input and output values for all nine pins are the same. I have attempted the following to call values for one pin. The plan was to get that right, and move to all nine.... // The first of each of the sets of two values is the 7 bit input value of the pin the second being the // value to pass as output const unsigned char inputOutputMidiValues [9][2]={ {126,127}, {110,111}, {99,95}, {86,79}, {78,63}, {73,47}, {67,31}, {61,15}, {55,0}, }; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) __wparam { // initialize the AIN driver MIOS_AIN_NumberSet(1); // only one pot is connected MIOS_AIN_UnMuxed(); // no AINX4 modules are used MIOS_AIN_DeadbandSet(7); // should be 7 when 7bit resolution is used } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam {if (MIOS_AIN_Pin7bitGet(pin)=inputOutputMidiValues[0]) // send coresponding value MIOS_MIDI_TxBufferPut(0xb0); // Midi Channel One MIOS_MIDI_TxBufferPut(0x5b); // Reverb MIOS_MIDI_TxBufferPut(inputOutputMidiValues[1]); // Corresponding output value } Sould this work? Itried it nd it wouldn't compile, and even after that, am left in the lurch of figuring out the other eight pots!! Thanks Again....

I know i've seen it somewhere before, and yes, I know, my C was crap, I read up, never practrised, and I'm kind of back to square 1. I have set up a switch to return 9 possible values, I want the core to send out nine different corresponding values? Can anyone help? Purpose- http://www.midibox.org/forum/index.php?topic=8276.0 Thanks.

We could all make one!!!

When you have the core unmuxed, I assume you set the program to beahave as such- ie set mode to unmuxed. So, when you have done that, set the number of pots to one, That way, the PIC will only accept signal from that pin. It doesn't matter if the other 7 are ground or not, as the PIC is not looking for signal from them. So set it to one, test it, set to two, test them and so on...... Then post the results. That is how I trouble shoot, so personally would be better able to read the problem through that route of troubleshooting. Mark.

FYI Bidding started at €1!!!! Bet the seller was surprised... :o

This topic here will help. http://www.midibox.org/forum/index.php?topic=8201.0 Read it rop to bottom....