The Razer

[Sam_K]

Yay I have a flashing LED!

The hardest bit so far is identifying the components in the kit.

---Edit

Now I have a LED that flashes faster! :)

Edited January 22, 2010 by Sam_K

[Sam_K]

OK, hit my first speed bump.

[EDIT: Fixed.. My bad, I didn't follow instructions]

I am up to the part where it should identify to the computer as a MIDI device, and I should be able to Query the device info using MIOS Studio.

Here is what happens, when I plug the board into the USB port WinXP reports it as a "USB Audio Device" (not MIDI) and when I do a Query in MIOS Studio it never finishes and no info is returned.

When I look in Device Manager, in the "Sound, video and game controllers" section I have a "USB Audio Device". When I open the properties for this device it shows the following info:

[General Tab]

USB Audio Device

Device Type: Sound, video and game controllers

Manufacturer: (Generic USB Audio)

Location: Location 0 (MIOS32)

Device Status: This device is working properly

[Properties Tab]

+Audio Devices

-->USB Audio Device

+MIDI Devices and Instruments

-->WDM MIDI Device

+Mixer Devices

-->USB Audio Device

+Line Input Devices

-->USB Audio Device

Now in there it does show a WDM MIDI Device as being present and functional, but the MIOS Studio app just can't seem to either find it or get any data out of it.

Any help or ideas appreciated.

Edited January 23, 2010 by Sam_K

[Sam_K]

Ooops! Never mind. I didn't follow instructions properly to set-up MIDI routing in MIOS studio. It's all working fine now.

[Sam_K]

Core32 module finished and working!

Well, working as far as I can tell. Embarrasingly, I only have one MIDI cable in the house so I can't test the MIDI sockets (requires 2 cables). Also I haven't gotten around to sourcing my LCD display so I can't test that either.

However, the whole thing is fully built and it still happily does the MIDI Query test via USB so that's a win.

I'll also take this opportunity to say that the PCB provided by SmashTV is a top quality piece of kit.

[Sam_K]

Some more progress tonight.

I got some more MIDI cables and tested both sets of MIDI ports with the MIOSStudio "Query" function and everything worked.

I also bought a 16x2 LCD display module from my local electronics store (Jaycar). This did not go so well. Getting it wired up correctly was a bit of a brain teaser, especially since on the LCD end I was wiring it into the backside of the PCB. I did it wrong a couple of times and ended up having to draw a fully detailed diagram on a sheet of A4 paper so that I could make sure I was getting everything right.

When I finally had it hooked up properly it did the following. As soon as power is applied the backlight comes on and the top line of characters has every pixel on (a row of 16 solid filled rectangles) and the bottom row has every pixel off (totally blank) and this is all it will do. It doesn't change after the "MIDI 2x2" application is loaded and running and I also cannot get it to change at all with the MIOSStudio "MIOS LCD Message" window.

At this point I am a bit stumped, I have triple checked the wiring and as far as I can tell it is definitely wired up correctly. I am a littlle worried I may have fried the LCD display on those occasions when I had wired it wrong. I can confidently say that VDD and VSS were ALWAYS wired correctly and that B+ and B- were always going to the backlight (though I had the backlight wired in reverse polarity at one point) everything else got plugged up all arse about at one stage or another though.

Any ideas? Did I kill the LCD or the Core32?

That's all I have time for tonight. Hopefully a lightbulb will come on next time. :\

[Sam_K]

Here is a link to the spec sheet for the LCD in case it helps.

QP-5516 16x2 LCD

[ssp]

has the core 32 got two little 10k pots like the core pic? one is for brightness and the other for contrast. on mine it did the same i then adjusted the contrast and all was well, however double double check the connections!!!!

[Sam_K]

Thanks to your hints SSP I found the problem!

First I adjusted the contrast to the middle position of the dial and the screen went blank all over. At least now I know what that pot does.

So then I took your advice to check the conections and did a continuity check between the solder points on the back of the Core32 and the solder points on the back of the LCD module with my multi-meter. (I used a DIL header and IDC connector on the LCD module side for ease of soldering) Turns out that the RS line consistantly measures at 1.8K Ohms, so I opened up the IDC plug connector at the LCD end and worked the RS wire up and down connector blades to help it cut through the insulation.

After that it now measures at 0 Ohms so I put it all back together and turned it on and it was still blank. So then I tried the coontrast pot again and there it was! "see README.txt for details". YAY!

[Sam_K]

I'm pretty excited right now because I just figured out that the soft-pots are actually dual-touch capable!

They have 3 pins on them, one that measures from one end of the strip to the point of touch, a 2nd that measures from the other end of the strip to the point of touch, and a common ground. Thing is, each of those touch measurements is between the respective end and the first point of touch from that end, other touches beyond that point have no effect on the reading. This means that if you monitor from both ends you can touch it in 2 places and know where both touch points are!!!

Very excited about this!

EDIT: Oh.. wait.. never mind.... I see now.. pin 1 is vdd, pin2 is gnd and pin 3 is the variable. boo... that's boring... Surely there must be a way I can exploit this???

Edited January 27, 2010 by Sam_K

[Sam_K]

OK I think I may have found a solution to give me 2 point multi-touch from the soft-pot, but I am going to need a little advice.

I have attached a circuit diagram to this post that should hopefully do the trick. (Excuse my dodgy MS Paint rendition) The only sticking point is that when you lift your finger off the soft-pot, the potentiometer goes open circuit. (The wiper is lifted off the track)

This means that the two analogue inputs to the STM32 chip will simply be attached to 5V through a 10.3K resistor. Will this let the magic smoke out?

[Sam_K]

OK I think I've answered my own question, which is that yes, that circuit will let the magic smoke out.

After thinking about it I realised that when the soft-pot goes open circuit the Analogue inputs will get pulled up to 5V or close to it. I downloaded the specs for the STM32 chip and confirmed that the voltage on the analogue inputs is not to exceed 3.6v.

So for now I will put a dual-touch implementation on the back burner until either I have an epiphany or someone else can suggest a workable answer.

[Sam_K]

I've now realised this problem is not going to go away, because the FSR Strip (The one that measures the touch pressure) is only a rheostat (2 pin resistor), not a potentiometer (3 pin voltage divider). The FSR also has the same property of being an open circuit when no touch is applied.

To use the FSR at all I still have to solve this same problem of needing to control a voltage between Vdd and Gnd using a single rheostat that can also be open circuit part of the time. When (not if) I find a circuit to solve this problem, then I can use the same circuit to exploit the soft-pot for dual touch.

[ssp]

to use my fsr 4x4 sensor pads in my bpm build nils had me wire in a 10 trim pot on each pad to get it to work right. so now they work as basically momentaries.

[Sam_K]

Well it's been a long few days of research and head scratching but I have finally found a satisfactory solution.

First off, that circuit I posted above could be made to work if you just reverse the positions of the fixed and variable resistors, That way when the pot goes open circuit the analogue input goes to ground instead of 5V, but the real problem with using a basic voltage divider like that is that the voltage response is a knee curve and that voltage knee curve causes one of the end of the touch strip to have very low resolution.

I actually built this circuit and wrote an app to just display the raw analogue input values on the LCD screen. With the analogue deadband set to just 2 ticks, at the low-rez end of the sensor I could actually wiggle my finger on the sensor and have no change registering at the MIOS callback level. Whereas at the other end of the sensor the same wiggle would produce triple digit swings in the number.

So, out with the basic voltage divider.

At this point I knew that what I really needed was some kind of automatically adjusting resistor to go in place of the fixed resistor in the voltage divider. If I had a resistor that would adjust in opposite proportion to the variable resistor then the voltage response across the variable resistor would be a straight line thus giving me a consistant response and resolution across the full length of the touch strip. With some thinking I realised that this theoretical auto-variable resistor could only work if it adjusted itself according to the current that was flowing through the circuit. With this in mind I did a bit of googling around and discovered the "current regulator" circuit that can be built using a variable voltage regulator.

After studying current regulator circuits for a bit I realised that I could get what I wanted by using a standard variable voltage regulator circuit applied to a nominal load with the touch strip being used to control the regulator voltage. (see attached pic) Due to the voltage regulator keeping a fixed voltage across R1 this means that the voltage across R2 changes in linear proportion to the changing resistance.

As I sweep through the full range of 0 to 20K ohms on the touch strip, the voltage at Ain sweeps from 0v to 2.35v. This is because the maximum possible voltage at Vout is 3.6V with a 5V input, and there is always 1.25v across R1. When I take my finger off the touch strip and R2 goes open circuit, the voltage at Ain jumps up to 3.6v which happens to be the maximum allowable voltage at the analogue input pins according the STM32 specs.

I cannot get the voltage across R2 to go any higher than 2.35v without the "open circuit R2" voltage going above 3.6V. Also I cannot swap R1 and R2 (To make Ain go to ground when R2 goes open circuit) because the maths just doesn't work right when R1 is the variable resistor.

I have setup this circuit on the proto-board and it all works as predicted. Along the way I also discovered that RLoad was necessary otherwise the LM317 would not operate properly as a minimum current of 10mA is required at Vout in order for the regulator to run.

Of the full 12 bit range of 4096 input values at the analogue input, I am utilising the range 0 to 2820 with the number 4096 representing "no touch". This gives me a consistant 5.64 values per millimeter. It would be even better if I could utilise the full sweep of 4096 values, but I am happy with my progress so far.

Tonight I also designed and built a veroboard circuit based on this design with three seperate regulators to drive all three of the variable resistors in my test strip (2 in the soft-pot, one in the FSR). I have finished all the soldering but still have yet to check my work. Probably another couple of hours of double checking everything and making some cables to go to the Core32 before I can finally plug it in.

I hope you don't mind the long winded explanation but I am learning a lot and it's fun to share.

Cheers

Sam

Edited January 31, 2010 by Sam_K

[Sam_K]

Tested, cabled and working. Yay!

The actual swing displayed on the LCD is 0->2520 and the R2-open-circuit voltage is only 3.25v. I immediately suspected and confirmed that the 5V line from the USB port on my laptop was not quite 5V, it was at around 4.7v.

In the long run I intend this to be battery powered from a 2 cell LiPo battery (7.4v) through the Core32's own 5v regulator so I won't make any changes to that for now.

Now to get it to send MIDI...

[Sam_K]

OMG IT FREAKING WORKS!!!! :frantics: :D

I have coded for basic note on/off with pitch and velocity. It is so awesome to actually hear sounds come out of the speakers in response to touching the strip.

[Wilba]

I hope you don't mind the long winded explanation but I am learning a lot and it's fun to share.

Definitely not... you're doing stuff that I've planned to do for years but haven't due to too many distractions... :whistle:

Well... I did actually experiment with the PAiA "two-touch" ribbon controller circuit but it didn't work as well as I'd hoped... there was an issue of the output voltages doing strange things when you released the touch, I never resolved those issues. Then when another guy was developing his own ribbon controller and apparently solved this issue with some analog electronics beyond my level of expertise (not that I have much anyway), I was waiting for the results of that, and then buy a PCB... but I'd sort of lost interest (and funds) by the time the PCBs were available. IMHO that project is good but quite overkill for me, since I probably only need a single touch point value to be sampled. I could probably distill some of the debouncing ideas out of the schematic and use them eventually... but maybe I won't need to if your voltage regulator idea gives a reliable gate on/off from touching.

I cannot get the voltage across R2 to go any higher than 2.35v without the "open circuit R2" voltage going above 3.6V. Also I cannot swap R1 and R2 (To make Ain go to ground when R2 goes open circuit) because the maths just doesn't work right when R1 is the variable resistor.

It sounds from this statement that you're limited by the 3.6V... i.e. that you can't get the voltage range across R2 for fear of driving the analog input into the STM32 higher than 3.6V. Maybe what you can do is just add a protection diode to the STM32's analog input so the "open circuit" voltage can swing higher.

One thing I recall from the MIDIbox Extensions page is the "3 LFO Extension" example, which shows how you can make some hardware LFOs running with +12/-12V outputs and connect them safely to the PIC analog inputs. The schematic is pretty self-explanatory... by putting some diodes between the analog output/PIC analog input and the rails (5V/0V), it will clip the voltage range to -0.7V to 5.7V. Note also the 1K resistor to prevent high currents. Maybe this same idea can be used for your circuit, so using a diode between the 3.6V rail on the core and the analog input, plus the 1K resistor, should limit the voltage to 4.3V. FWIW... Figure 54 of the STM32 datasheet shows the analog inputs already have diodes to Vdd/ground to prevent damage from the input voltage being outside the Vdd/ground range (not that I suggest you leave out external diodes).

Just out of interest, do you notice any voltage "noise" as you release touch? If you have basic note on/off and pitch, then when you press and hold the ribbon, you should get a fairly constant "pitch", when you release, does the "pitch" change drastically before the "note off", or stay as just as stable as while it was being pressed?

[Sam_K]

Hi Wilba,

Thanks for your post! Yes your interpretation of my problem with the voltage range is correct. At first glance that diode protection circuit certainly looks promising, I'll put my thinkbone onto it tonight to see what I can do.

Regarding the behaviour of the touch strips at the on/off transitions, yes they do ramp. As you press down, the resistance swings down from Infinity until it settles at the correct resistance. As you release, the resistance swings upwards until it reaches infinity. My code accounts for this by waiting for the analogue input value to stabilise before acting on it.

On the Soft-pot, these transitions are very quick, smooth and predictable and so are easy to account for. The FSR however is VERY jumpy and erratic, even after reaching the correct "on" state it still swings around pretty wildly, I think I will have to write some kind of smoothing routine that is always in effect for the FSR rather than just debouncing the transitions.

[Sam_K]

I have the software working well now for driving the strips. I just spent about half an hour playing various synths with it and it was really fun which is a good sign. The dual touch works surprisingly well.

I am really happy at the moment because I really had no idea when I started if the touch strips were going to turn out to actually be enjoyable to play. The $300 I've spent so far to get to this point was a pretty big gamble and I can now say that it has paid off!

The code is a bit of a labyrinth of logic as there are 3 different types of strip (soft-pot, inverted soft-pot and FSR), each can have up to 5 different states (Off, Transition to On, On, Transition between notes, Transition to Off) and all the strips are depoendant on each other to provide things like dual touch and velocity.

[Wilba]

Some more to think about: a good, simple circuit for getting fast touch on/off from a SoftPot. It's designed for CV/gate control, so it has a sample and hold section which might be redundant for MIDIbox, but a simpler alternative to the Appendage circuit when all you want is one analog output from a ribbon to feed into a microcontroller.

http://www.electro-music.com/forum/viewtopic.php?t=32246

[Sam_K]

Thanks for that link Wilba, it is an interesting read. That circuit is a little beyond my abilities at the moment but I will certainly keep it in mind when I revisit the design of the soft-pot connections. For the time being the current circuit is good enough for me to focus on getting the other components working. Reading through the text it seems that a lot of the problems they are trying to solve in that circuit are things that I am dealing with in software instead.

[Sam_K]

I've got my keyboard matrix hooked up and did some experiments with the software. Unfortunately it looks like I am going to have to bypass the SRIO API layer and interface to the SPI directly.

Just using the APP_SRIO_* hooks, I can only scan one column per SRIO pass, this means that the minimum velocity time that can be detected is the number of columns in milliseconds. This is an order of magnitude too slow for decent velocity detection.

It looks like scanning the whole key matrix every millisecond might just be adequate, but I have a feeling I'm going to end up having to scan twice per millisecond to get a really good velocity response.

[Sam_K]

Progress!!!

After heaps of research into the SRIO and SPI interfaces, which mainly involved reading through the MIOS and FreeRTOS code, I finally took the plunge this past weekend and now I have my own matrix scanning code working!

My application now polls the entire keyboard matrix on each application tick (1ms).

The response is much better than it was before, but it is still not excellant. Due to the nature of how it works, the resolution of the velocity detection gets worse the faster you hit the key, so at the upper end of the scale the resolution of the velocity sensing is quite poor.

For example:

* A deliberately slow keypress is in the low hundreds of milliseconds (between the first and second key contact closing)

* A mild keypress gets you around 20-50ms

* A moderately firm key press usually gets you 5-10ms, .

* A reasonably fast/hard hit typically produces a result of 2-4ms

* You have to hit it VERY hard and fast to get 1ms

* You have to hit it VERY hard and fast AND get lucky to get 0ms

So, by my subjective experience, 10ms is what I would call the mid-point of velocities. So there are only 10 steps of resolution between a "mid range strike" and the very fastest possible velocity, but there are hundreds of steps between that same mid-point and the slowest (practical) velocity.

When doing rapidly repeated hard strikes it is easy to get a run of several keystrikes all with exactly the same value around 5ms. This doesn't strike me as being conducive of an expressive instrument but I'll really have to play it and see if it really is bad or not.

I also tried increasing the configTICK_RATE_HZ (in FreeRTOSConfig.h) from 1000 to 5000 and even 10000, but it seemed to make no difference at all. Perhaps there is something else I need to do also to make my scanner run more frequently, or perhaps the CPU is already running as fast as it can go? I'm not sure.

Anyway, I'm still pretty chuffed to have (mostly) pushed through this obstacle. I think that is possibly the hardest part of the project behind me now other than perhaps the final finish on the case.

:thumbsup:

Edited March 15, 2010 by Sam_K