More Prophet VS Hardware issues.The

The VS I have been working on must have been used as a training kit for monkeys learning electronics. There are so many weird errors and botched jobs inside. After finishing the keyboard scanner, 8 keys (g#2 to d#2) still didn't work so I disassembled the keybed, initially leaving the pcb in place, to figure what was going on.

From the schematics it is clear that all these are connected to row 20 in the cable (I knew from earlier that it was the start key switch that was the problem, not the end).

I started by measuring between the diode kathode and pin 20 and got nothing. But the same was true for the working lines! Turns out there is an inaccuracy in the VS service manual - the diodes are before the key switches, not after, so it is the columns that are common to the diodes, not the rows.

Even if I tried pressing a key, my multimeter's connection checker didn't beep. I gave up and unscrewed the pcbs to get a closer look. It quickly became apparent where the error was. I also figured out why the connection checker didn't work: the switch pads have a tiny resistance. Also, I could see that both the top and bottom switches are in fact in the same place. Assumingly, the outer ring that makes the connection is pressed down slightly slanted, connecting two of the poles before the other two.

What happened here?!

Scraping away a bit of solder mask from the broken trace enabled me to solder a new wire to bypass the fault. It worked straight away.

After (of course, after...) assembling the keyboard I heard and felt a clicking from one of the keys. I opened it up again and discovered a bent spring. How it is possible to bend this is beyond me, it was really hard bending it back. It only strengthens my monkey theory. Anyway, the synth is now fully operational and will be returned to a happy owner.

The bent spring in the middle black key

The bent spring

MPG-200 cards received

I got the MPG-200 PCBs from dirtyPCBs yesterday. They look very good. My little trick of panelizing four on a 10 x 8 cm card was accepted by the maker and it turned out like it should, which means I'll probably get 40 MPGs from this order. Next time I will put the holes closer to make the cards easier to break apart though, and maybe have fewer of them. These cards are still very well connected...

Pic 18f gotchas: interrupts on portb change

I have constructed the 68b01 clone to use interrupts to detect when the main controller has read the output data. To do this I detect when pin 7 on portb changes. Changes on pin 4-7 on portb can generate an interrupt, PBIF whenever the input changes.

GIE = 1; // global interrupts enable

PBIE = 1; // portb change interrupt enable

IOCB7 = 1; // only pin 7 should trigger interrupt

IOCB6 = 0;

IOCB5 = 0;

IOCB4 = 0;

PBIF = 0; // reset any portb interrupt

While I got the interrupt working, clearing it would not work properly, the interrupt just refired instantly. 

A little googling found me application note AN566 from microchip which solved the mystery: after the interrupt has been triggered, portb must be read to reset the mismatch state.

It may be possible to read the values into any variable, I haven't tried this yet. The solution used in the AN is a single assembly statement that reads portb onto itself:

MOVF PORTB, 1

After this, everything works as expected.

NB: the pic18F's (some of them at least) have one or more external interrups, on portb 0-3 on the 18F46k80 for example. It is better to use these if you only need to check that an interrupt has occurred. The external interrups are edge triggered, so they will only trigger on EITHER the rising OR the falling edge. Portb change interrups trigger on both.

Led indicator ring driver

I intend to have rings of LEDs around the potentiometers on my synth to show the current value of the parameter, and have been thinking about ways of doing it. One can take the normal approach and do a full matrix that runs through all the pots and have a single controlling circuit, but that requires a lot of data lines running across the PCB. Another option is to use a 16bit shift register per dial and connect each led to a pin, which reduces the number of lines necessary to six - two power lines, serial in-out and clock, latch.

I have been considering having even more LEDs per dial. For 32 LEDs this last method requires either two 16bit or one 32bit shift register, and things start being costly and take up a lot of board space.

Thus, a combination may be a good solution. If one uses a 12bit shift register, one can control 6 rows x 6 columns for a total of 36 diodes, while still only using 6 transmission lines (16 diodes may be controlled by a 4x4 matrix, requiring an 8 bit register only). It means you have to do row scanning instead of just updating the shift registers whenever the dials change, so there are pros and cons of each method. The scanning requires more (but cheaper) components - transistors and resistors. It also requires a more complex controlling algorithm which takes up time in the microcontroller, and ultimately the number of controllable LEDs and the refresh ratio is limited by the time it takes to fill the shift registers.

A possible circuit may look like this:

The shift register must be able to sink around 20mA per pin which means a normal CMOS chip won't do. A constant current sink led driver will be a good option, it may even do away with the resistors in the schematic.

I've found 16bit led driver shift registers at prices of just above $1in quantities of 50, for example the STP16CPC26 at mouser.com.

PS: a 32 LED dial may be controlled from a 12 bit shift register using 8 bits for rows and only 4 for columns. This reduces the necessary transistors from 6 to 4.

68b01 boards arrived

The 68b01 clone is close to completion. The v1.1 boards arrived while I was away - they actually arrived before the 1.0 boards as I got bumped to a faster production board by oshpark. 

The reason I did a revision so soon was that I discovered that in order to use interrupts for the kybd line, it had to be part of portb. Unfortunately, while rushing to fix this before going on holidays, I forgot to read the data sheet properly. I have used porta for top switch scanning, but on this particular mcu (the pic18f46k80), only 7 of the 8 pins on porta are available. Worse, the remaining pin is used as a power output pin, which led to some surprises when connecting it to ground. I cannot easily change the chip either, as it is the only 44qfp chip to accept 5v power and have 5v data lines.

In addition to this I somehow forgot to move the pgc and pgd lines. They are now connected to some of the bottom switch data lines instead, which is of course no good. 

On top of this, when I sat down to solder everything, I could not find the proper pin strips and had to make a Frankenstein solution out of sockets and male header pins, and didn't solder some of the pins properly. As a result I spent a lot of time trying to figure out why things didn't work properly.

A lot of rookie mistakes, but I guess that's to be expected when the time available to development are the minutes in between diaper changes, bottle feeding and singing lullabies ;-)

Oh, and I just realised that the VDDCORE line of the PIC18F46K80 must have a 10uF ceramic cap to ground (an electrolytic one has been used in the photo above as I thought it could be the source of some of my problems - turned out I had a spelling error in my code. I meant to write ANCON1 and wrote ADCON1. Since both exist the compiler didn't give me any errors).

I may finally get to try the chip tonight - fingers crossed!

MPG-200 PCBs ordered from DirtyPCBs

I ordered what is hopefully the final version of the MPG-200 cards from DirtyPCBs last night. If all things go to plan I will get approximately 40 boards somewhere next month. Exciting!

WebMIDI and the MPG-200

A couple of days ago I put the final touches on a settings editor that can generate sysex for changing the MPG-200 internal settings like CC mappings and midi channel etc.

I wrote everything using javascript and HTML, and initially made it generate a sysex file that you could download and send using your favourite tool.

As an experiment, I thought I'd make it possible to send the data directly to the device using the newly available WebMIDI standard. I had a few issues but now it seems to work nicely.

I have been using Google Chrome to do the development, and there are a few things to be aware of:

1) In WebMIDI you have to ask the user for access to sysex messages. In Chrome, this cannot be done if the javascript file is accessed as a local file or from a local html file (file://...). Neither can it be accessed through an insecure connection (I assume this means you have to use HTTPS).

To get around this, I installed a tiny webserver (The TinyWeb actually) locally and ran the code through it. Works like a charm.

2) You have to send the complete sysex message in one go - it must start with F0 and end with F7. You cannot send the messages in blocks so the message has to be calculated up front.

3) Running status is not allowed, as with the sysex message each message has to be self contained and complete.

The sysex editor and my WebMIDI code is found on the Xonik webside, but as I said, you cannot use the WebMIDI part directly as it is not served over HTTPS.

MPG-200 final hw version finished

Just finished what I hope will be the final version of the MPG-200 hardware, correcting the small mistakes with the previous verson. Will probably order a batch from dirtypcbs soon.

Decoding the 68b01 keyboard scanner

Returning to the Prophet VS service manual, I noticed that the output bus from the keyboard scanner runs through a set of latches. This means that bus communication is one way only. In addition to the bus, the only pins connecting the scanner to the main MCU are the KYBD and KYINT lines. Thus, the communication protocol should be fairly simple.

I connected logic probes to various parts of the 68B01 and its surrounding components. First to the CD4022 octal counter to see how the keyboard lines are scanned. Then to the rows to see which ones are connected to the first and second set of keys. I registered the data on the output bus while pressing keys to understand the protocol. I also checked the KYBD and KYINT lines while monitoring the data bus to see how the MCUs interacted.

The velocity was a bit trickier to get right. I needed to know the interval between hitting the first key and the second key, and at the same time registering the data bus output. I only have 8 probes on my logic decoder, but luckily, the velocity is 7 bit only, and by ignoring the least significant bit I could still get quite accurate velocity measurements.

What I found was that certain number of rounds of scanning the keys in between first and second keys made contact corresponded to a certain velocity. In other words, there is no 'free running' counter used for calculating velocity, one only needs to know how many times the keys have been scanned. This makes sense, as the only legal intervals corresponds to the times the keys are scanned.

I got a nice surprise when I made a plot of the velocity versus the scan cycle count. It turns out the velocity is a faux exponential curve, much like the way an analog audio-scale potentiometer works. For the first quarter of the measured cycles the velocity follows a steep line. For the other three quarters it follows a much flatter line. This, of course, makes calculating the velocity much easier (without the use of a lookup table. In that case any curve would be equally simple).

Plot of cycles vs velocity

(Disclaimer: The lines measured are not perfectly flat even if I try correcting for a +/- 1 error. This means that there is actually some kind of timer involved that is not connected directly to the keyscanner cycles. However, when recreating the program it will be sufficient to count cycles as long as cycle lengths are constant)

Here are some details about the scanner:

The keys are scanned column-by-column. The first column is turned on for about 70uS, the rest for 52uS. The total period (time between successive scans of the same column) is 432uS, giving a scan frequency of about 2.3kHz.

The three first columns and their scan pulses

The columns are scanned by clocking a CD4022 octal counter. Each clock pulse is approximately 2.5uS wide. The carry out from the CD4022 alternates between 0 and 1 every four clock pulses.

Data transfer works like this:

When the scanner has something to send, it lowers the KYINT line. At the same time, it puts the data on the output bus. Approximately 10uS later, the main MCU lowers the KYBD line. This turns on the 74HC367 transparent latches and puts the data on the databus, and at the same time signals to the scanner that it is reading data. KYBD stays low for about 0.25uS. The scanner waits an additional 10uS and then puts the next data byte on the output bus. The main MCU seems to read the data bus until it gets a 0 (0 on the bus is not a valid note on or velocity).

The data format is equally simple:

Note on is sent as two bytes: Note and Velocity
Note off is sent as a single byte: Note.

Both note and velocity are seven bit values. To differenciate between Note on and off, the MSB is always 1 for note on and 0 for note off. MSB is always 0 for velocities.

The lowest key on the keyboard, C0, is sent as x0100100 (x being 1 or 0 depending on note on/off), so the note value to send is simply 36 + key number.

Velocities:

Time t from key is pressed until it reaches bottom is x * 432uS + 571uS, where x is the number of times the first switch is scanned before it reaches bottom.

An approximation to the velocity transfer curve is as follows (not rounded):
[0, 1]: y = 127
[2,19]: y = 124 + (1867uS - t) / 80
[20,69]: y = 38 + (8779uS - t) / 570
[70, ->: y = 0

If more than 70 scan cycles are reached without the key hitting the bottom, a note on with velocity 0 is sent (and a note off is sent when the key is released later).

where
x = number of key scan cycles
y = velocity sent to master

This will of course not be an easily calculateable curve, so one is better off using a lookup table.

Top three: colum enable. Line four: key start switch, line five: key bottom switch. Pulses on key lines show when they are read. It seems that a lot of work is done when the first switch is turned on, making the initial delay longer than normal.

Important I/O pins:

Pins 13-20 corresponds to row 0-7 of the key press start switches
Pins 37-30 corresponds to row 0-7 of the key at bottom switches (NB: reverse order!)
Pins 22-29 are the output data bus pins
Pin 8 is clocking the CD4022 column selector
Pin 9 reads the carry bit from the CD4022
Pin 12 is the KYINT bit that must be set low before data transfer
Pin 39 is the KYBD bit that can be used to detect that the master reads the data.

Please don't butcher your synths!

A friend of mine recently brought me a Prophet VS he bought some time ago. The synth had some serious issues - while it worked perfectly over MIDI, 24 of the keys on the keyboard did not work as they should. 16 of the keys did not work at all, while 8 worked but always triggered the notes at maximum velocity. He considered selling the synth, but I was intrigued by the problem and asked him to wait for a while so I could look into the problem.

After consulting the service manual, I quickly realised that the keys in question were connected to three row-input lines of the keyboard scanning circuit. This got my hopes up, as it could simply be a matter of a few corroded or short circuited data lines.

I opened up the synth and within seconds came to the conclusion that it had to be something way more serious. Someone had, quite visibly, tried to fix this synth before. Aside from the fact that most of the screws holding the lid were missing, there were a few modifications, repair jobs and even a custom replacement for one of the CEM5580 sample and hold chips. Not a problem in itself, but surely a sign that this synth was in need of some love and care.

This is probably a factory fix but still looks funny

This could also be a factory fix, but the left resistors look horrible

Someone has smudged the print on this SaH chip. Maybe we could do a finger print analysis?

One of the CEM5510s has been replaced with a cool looking mod.

The biggest shock came when looking at the keyboard scanner chip. This chip, a Sequential Circuits 68B01, is a rebranded (or cloned) motorola 6801 microcontroller. Take a look at the pictures below:

Someone has cut deep grooves into the packaging and soldered new pins to the exposed internal connectors! I can only guess why - perhaps they cut the legs to get the chip loose from a PCB instead of trying to desolder it, or maybe one or more of the legs broke and they had to dig into the chip to reattach it. Whatever the reason, the person doing this must either have been well informed and highly competent, extremely brave or just desperate. The 68b01 is a very rare chip, and replacing it with a off-the-shelf 6801 will not work as it contains custom firmware. I guess if I owned this synth and the chip died, I could have tried something similar, after all you have little to lose if it does not work in the first place.

The chip even had a small wire connecting the first and second key switches for one of the rows. Now, the first switch detects when the key leaves the top position and the second when it reaches the bottom. The time between is used to calculate velocity. When they are connected, the effect will be that the synth thinks the key instantly hits the bottom position. This explains why 8 of the keys only played at maximum volume.

I tried resoldering the pins and even removing the wire, but this did not help. The chip is defective.

Luckily it seemed that the only defective parts are the row inputs. The chip still sends keypresses for most of the keys, which means it would be possible to decode the protocol. This lead to the only sane conclusion - I had to create a custom drop-in replacement. Challenge accepted!

Exponential curve using lookup table

It has been a while since my last update. My daughter arrived on Norway's national day, the 17th of May. It's so incredibly nice and I am the proudest dad ever! It does take the focus away from other things though :-)

Just before she arrived, I bought a book from 1980, musical applications of microprocessors. It may sound outdated but in fact is a treasure - it explains lots about sound theory, filters, DAC and ADC etc.

Today I am reading about generating waveforms digitally. Since the book is from 1980, the available computers were incredibly slow, worse than many of today's microcontrollers. This is a plus, since it means it explains a lot of neat tricks to make things run faster.

For example, it shows how to generate a sine wave using a small lookup table and doing linear interpolation between the points (p. 388). If certain criteria are met, the task only requires two subtractions, an addition and one multiplication.

In the OMM, I intend to do linear to exponential conversion using a lookup table. With 16bit values this would require 128kB for a full table. This can be reduced dramatically if I accept a little inaccuracy and use the same interpolation. As long as the result is not used for controlling the frequency of a vco, it should not be much of a problem

Saving space would also allow me to implement for example both 50dB and 70dB curves etc.

Free the PG-200!

Around three years ago, in april 2012, I decoded the PG-200 protocol. Using a Saleae logic probe I took a closer look at what happened while using the PG-200, and built a device that converts MIDI CC messages into PG-200 commands. This device, the MPG-200, also receives and transmits MIDI note messages, making it possible to completely control the JX-3P using MIDI.

To my knowledge, at the time I started the project only two other devices existed that could do this - the KiwiTechnics JX-3P upgrade and Patch Editor and the Organix Midi upgrade kit. These both require extensive modification of the JX-3P. Later, Mode machines made a PG-200 clone called the DT-200. I have yet to see the PG-200 protocol fully documented anywhere, but I may have missed something as I have not searched the web lately.

As a tiny gift to the synth community in honor of my daughter's birth, I now release all the information I have gathered. This document is based on the data found in the JX-3P/PG-200 service manual as well as a lot of work done by myself. Feel free to use it in any way you see fit, but I would be really happy if you acknowledged my contribution.

The complete protocol description can be found at http://www.xonik.no/mpg-200/pg-200/pg-200.html

Mmmmyeah... just one more bug.

I found the bug today. It wasn't the software - it is hardware related.

I have connected pin 2 of the midi connector to the PIC's MCLR. For some reason, when several midi messages arrive rapidly, the processor reboots. I assume it's induced noise on the line as I don't think the little phatty outputs anything on pin 2 (and it doesn't happen when just one or two messages arrive).

Fortunately, I foresaw that it could be a problem and added a solder blob jumper. After removing this the mpg-200 works as it should (but it cannot be programmed of course).

I have added a temporary normal jumper, so now things work again. I can just remove this jumper before shipping.

Btw: the midi connector didn't fit so i had to remove some of the copper and drill a new hole for the shield connector. Rookie mistake...

Mpg-200 hardware verified

After some initial trouble - the pic18f25k50 has analog inputs on all ports that has to be turned off - I got the mpg-200 up and running. Receiving and transmitting midi works, but something is wrong with the software. Even so, it's great that the hardware is working as it should. The same hw will be used for other projects too.

The mcu runs at 16MHz without an external crystal which is really nice. And programming it through the pins of the midi input works like a charm, even with the  optocoupler in place!

MPG-200 programming through midi cable

I soldered together the first MPG-200 today. I've made a few mistakes - my midi connector does not perfectly fit the board, and the electrolytic caps and transistors would have liked a little more space, but nothing serious.

I have yet to try it out as the mpg-200 firmware has to be adapted to the PIC18F25K50, but I got the programmer working. I've chosen to run the programmer pins, five in total, through the midi connector. The wiring is as follows:

Pin 1: 5V
Pin 2: MCLR
Pin 3: PGClock
Pin 4: PGData
Shield: GND

Now, I do not usually want the shield to be connected to GND, so I've added a jumper that must be removed after programming. Pins 1,2 and 3 are not normally used by midi so those are hardwired, but I've added solder-blob jumpers that can be removed should you use any equipment that use these lines for something else.

Pin 4 is normally midi in, but as long as I have not added the input optoisolator it can be used by the programmer as well.

The Mikroelektronika mikroProg connected to the MPG-200 through a custom cable

Time to update my knowledge, paper style

I ordered the "Circuit Designer's Companion" yesterday. Hopefully it will answer all my questions ;-) Bwack suggested it after I pondered him with questions about ground/earth connections etc.

From the list of "others who bought this also bought" I recon it will suit me very well - the main suggestions seemed to be "Practical electronics for inventors" which I bought in Singapore in 2007 and "The art of electronics" that I bought a couple of years ago on Ebay (hot tip: you can get an "asian only" copy from India at half price if you're lucky).

DAC board soldered too

I finished something else yesterday - the DAC board prototype. My first real 0.5mm pitch soldering job. I think it turned out alright, I did as bwack suggested and tilted the card under the microscope. It looks good to me.

I can't test it with the sample and hold circuit just yet as I have no angled connectors for some reason. I may try just the DAC tomorrow though.

The DAC is an AD5547 dual output parallell input 16 bit device. There are two reasons I selected this. First of all, I selected the parallell version as I thought maybe I could load it faster than if I went for the SPI version. Second, I was not sure if I could load 32 sample and holds fast enough with only one DAC, this allows me to load two at the time before clocking the result into the sample and hold. The dual version costs significantly more than a single one though, so hopefully I'll get away with one channel. The sample and hold card lets me select which channel I want to use for output 17-32, so I can test both single and dual channel versions.

The DAC chip with its tiny legs. My index finger for measure.

Through the microscope. Before cleaning away the flux obviously

I had to add this as well, I am really impressed with the quality of the OSH park silk screen! Look at those sharp lines (this is at 80x magnification I think)

The DAC card with two high quality AD8672 opamps. I have socketed these to be able to switch between these and TL072s to see if I can hear any difference - the AD8672 is about $5 and the TL072 is $0.50, so if I cannot hear any difference I'll just go with the TL072.

The DAC and sample and hold together but not connected. The large white header is for analog power, digital power comes thru the 36 pin connector to the left.

PSU finished!

Tonight I finished something for a change. The dual transformer, triple voltage PSU is safely enclosed in a box, transforming away. The output voltages are only as good as my cheap multimeter of course, but I had no problem dialing in +/- 15V and 5 or 9V. For the moment I've set the output of the "digital" PSU at 9V as this is what the EasyPIC Fusion 7 wants.

the digital and analog PSU's grounds meet at a star grounding point. This point is in turn connected to the "chassis ground"/earth via a 100nF/50V capacitor as suggested by bwack. In addition, I have exposed earth on top of the PSU to be able to clip on my ESD wrist band.

The DGND and AGND meet at a star point which is also connected to Earth via a 100nF cap (inside the shrink tube)

Earth is also connected to a point outside the box where I can attach my ESD wrist band

The box

PSU update

I completed a PSU board the other day. Nothing much to say about it, I haven't tried it out. It has six outputs per voltage and three voltages - 5V, -15V and +15V. The 5V and +/-15V have separate grounds that can be used as digital and analog ground.

The caps may be a bit close to the heat sinks though, not sure if it is a problem yet.

Sample and hold completed

I soldered the Sample and hold circuit today. Except for the side connectors it is complete. I have to say again, liquid flux is magic! I've had it in my toolbox for ages but never used it, but it makes things so much easier.

The two rows in front of the four chips are 10nF capacitors.

Tiny 0603 bypass capacitors, This is the first time I've soldered such small parts but it went rather well (I know, they are poking up from the board, but next time...). which is nice since I've bought more than 150.000 resistors of this size!

Practice makes perfekt. Or not. But close

As I decided to use PIC32MX chips for the voice cards, I had to learn how to solder tiny TQFP packs with 0.5mm leg spacing. I've been worried about this for some time, and to try to learn it without breaking anything important, I ordered up some QFP-to-through-hole adapters and the cheapest chips I could find. 

Yesterday I tried soldering them for the first time.The first chip was a complete disaster. I used way too much solder lead. I tried removing it with some solder wick but that was no success.

After watching a video on drag soldering, things started to go a bit better, and on the third chip, a 100 leg QFP, it got very good (except for a bent first leg).

My method ended up being this:

- Apply a tiny amount of solder on the lower left leg (on the PCB of course).

- Position the chip using SMD pliers. Once the chip is in the right spot, tack down the lower left leg with the soldering iron (in my left hand, even though I am right handed) while still holding the chip with my right hand.

- Adjust the chip if necessary (NB: Only do adjustments while the solder is still liquid, reheat if necessary.

- When all legs are in the right position, solder the upper right leg. The chip will now stay in place.

- Now apply a generous amount of liquid flux to all legs. This is very important for a good result.

- On each side, melt a tiny amout of solder onto the two first legs, in effect creating a solder bridge. Then drag the soldering iron across the legs several times. The solder will spread nicely. I use a huge chisel shaped tip, using the corner of it works very well. If you get a solder bridge, move the iron from the legs and outwards and it will disappear (if you haven't used too much solder).

I had to wear a pair of magnifying glasses to be able to do this properly. It is actually really hard to see if you get any solder between the legs and the PCB at all. To be sure, I had my wife bring them to her lab (she's a PhD student working on hormones and using fish cells for her work, so she has some really powerful microscopes in her lab) and take some close up photos of the result

Here are the photos. In my experience, 10 x magnification would be great for soldering while 20 x is perfect for studying the result in detail.

My second and third attempts. 

I managed to bend the first leg while tacking down the chip, so this will never work. The rest look good though

The mishap at maximum magnification

I am rather pleased with the result, especially since this is the first time I've tried to do it.

My wife's kick-ass stereo microscope. I want one but they sell for $4000+ used... There are cheaper models out there though.

The ketchup effect

My project tend to go by the ketchup effect. For a long time nothing happens, then suddenly  all parts and boards and whatnot arrive at the same time.

Within the same week I got at least 5 envelopes with parts from China, the prototype boards for the mpg-200 arrived, my orders from Farnell and RS componens were delivered and to top it off, the grease for the JP-8000 keyboard that I've been waiting for since christmas was suddenly ready for pickup.

Aaand - in around three weeks the biggest shipment of my life - my daughter - arrives. She is due on the 16th of May, so who knows when she decides to show up :)

PIC32 100 pin SPI ports

Just to make it a bit easier - here is a list of SPI pins on the 100 pin PIC32 chips.

The PIC32MX795 has four SPI ports, named SPI1, SPI1A, SPI2A and SPI3A. They are all equal.

SPI1:

name	pin	port
SCK	70	RD10
SDI	9	RC4
SDO	72	RD0
not SS	69	RD9

SPI1A:

name	pin	port
SCK	48	RD15
SDI	52	RF2
SDO	53	RF8
not SS	47	RD14

SPI2A:

name	pin	port
SCK	10	RG6
SDI	11	RG7
SDO	12	RG8
not SS	14	RG9

SPI3A:

name	pin	port
SCK	39	RF13
SDI	49	RF4
SDO	50	RF5
not SS	40	RF12

On the EasyPIC Fusion v7 from Mikroelektronika, the only SPI that has all the necessary pins on the same 10 pin connector is SPI3A

For reference, a 40 pin PIC18F has the following SPI

name	pin	port
SCK	18	RC3
SDI	23	RC4
SDO	24	RC5
not SS	7	RA5

PIC32 3.3V - 5V interfacing

According to the PIC32MX Family Reference Manual - chapter 12 I/O ports (http://ww1.microchip.com/downloads/en/DeviceDoc/61120D.pdf), PIC32s are 5V tolerant when the pins are in INPUT mode. I have read that this may only apply when pins are configured as digital, but unsure about this.

The Microchip Tips'n tricks guide has a chapter on 3.3-5V interfacing here: http://ww1.microchip.com/downloads/en/DeviceDoc/chapter%208.pdf

Sparkfun has an example of a bidirectional interfacing card here: https://learn.sparkfun.com/tutorials/using-the-logic-level-converter

This post indicates that it should be possible to drive a 5V PIC's SPI input using a 3.3V chip without interfacing. Let's see if that is true :-)

PSU boards

I unpacked the boards last night - they look great. The only thing I didn't realize before ordering is that they are not gold plated, in this regard oshpark still has one up on DirtyPCBs. I got 12 cards so still very pleased.

DirtyPCBs

I got the cards for the power supply today, from DirtyPCBs. I ordered them about three weeks ago, not to bad I think. The quality looks good too, though I haven't unwrapped them yet. I got 11 cards for around $25, a VERY reasonable price considering the cards are 8x10 cm.

 

DAC and S&H boards arrived

The DAC and sample and hold PCBs arrived from oshpark today. They look great as always, I am very excited about them and wether they'll work or not. 

I will start ordering parts today too, I have two populated shopping carts, one with Farnell and one with Rs components and will press submit as soon as I get an answer from Farnell about the value of the Tempco resistor they offer - the data sheet indicates 1k but their page says 100Ohm... 

Transformer power ratings

Transformers are usually rated in VA. The power rating is the same on both the primary and secondary windings.

To calculate how much current you can draw from the transformer, just divide the VA rating by the secondary voltage:

A 10VA / 12V transformer will supply 0.833A.

For dual secondary transformers, the rating is for both secondaries combined. To get the maximum current for each secondary, divide by double the voltage:

A 60VA / dual 18V transformer will supply 60 / 36 = 1.67A per secondary.

Power and DAC

It's been a busy week. I've designed prototype cards for an AD5557 based DAC card (parallel input dual output) and a separate multiplexed 2-input 32-output sample and hold card, and sent both off to OSHPark for production.

Today I designed two PSU cards based on Ken Stone's CSG66 module - one dual voltage (+/- 15V) and one single voltage (2.2-9.6V) that I'll use as the analog and digital PSU in future projects.

Sample and hold hold time

I am trying to figure out if the simple s&h circuit can hold its charge at a usable level long enough to update 32 units with only one dac.

Returning to the prophet 5 service manual, they indicate that their cycle time is 8ms, that they update 41 channels and that each channel update takes 20us for the DAC to settle and then 30-40us for the s&h to setle as well.

I made a little POC cirucit that held a mux output high for 25us then switched it off for 1ms. I could not see any drooping on the s&h (surprisingly it droops upwards towards 15V when nothing is connected to the input), but this is of course no proof as I am aiming for a very high output resolution - the Prophet 5 has a 7 bit dac whereas I will use a 14 bit one. Still, I will hopefully be able to update all 32 channels in around 0.8ms, which is 1/10th of the time it takes for the prophet 5, so it might not be impossible after all.

Top line is s&h output. Some noise is visible while the s&h is acquiring its value (when the bottom line is low), this may just be because I used an opamp 2.5V output as "DAC out".

I will try building a dual 16 channel s&h and see how that works out.

Sample and hold acquisition time

I did a quick test on a home made sample and hold circuit to figure out how fast it settles (reaches a stable state).

The circuit consists of a 10nF capacitor and an opamp buffer, similar to what you will find in the Prophet 5 and the Jupiter 8.

The prophet 5 service manual says that they let the sample and hold settle for 30 to 40 uS. I connected the circuit to a function generator's square wave output and the output to a oscilloscope. Finding the maximum frequency was then only a matter of observing when the output no longer reached its peak within the time before the square wave changed polarity.

With a 10V p-p input, the s&h managed about 10kHz on the function generator. Since the s&h changes on both high and low parts of the wave, the s&h frequency is in fact 20kHz, meaning that the acquisition time is 50uS.

When changing the input to 5V p-p I was able, unsurprisingly, to reach 20kHz on the function generator, which means an acquisition time of 25uS.

Vertical resolution: 2V/square, Horizontal resolution: 20uS/square. Squares are input, slanted ones are output.

I am aiming for a 32 channel controller, which means that with a 40kHz S&H I get a maximum refresh rate per channel of 1250Hz. It remains to be seen if this is fast enough for pitch bends etc.

Old school din-based midi runs at 31.25 kbits/s. Each 14 bit pitch bend takes up 16 bits, which means that the maximum midi pitch bend rate is 1953Hz. Perhaps 1250Hz is enough, if not, I have to use a dual channel dac with two 16channel s&h, and update two and two at the same time.