Scratch wheel

[rasteri]

I'm having a problem - I need another AIN input for the capacitive sensor but if I change MIOS_AIN_NumberSet to 4 then it stops tracking the wheel properly. I guess it must be polling the photodiodes too slowly.

I tried setting the T0CON prescaler to 1:2 (instead of 1:4) in the MIOS source, but that doesn't seem to have made any difference. Any ideas?

Should I start another thread for this?

(BTW, I'll get a step by step howto up as soon as I get it working properly :P)

[stryd_one]

Heh, I think I was warning you that this might happen, when we first chatted about this  :)

Rather than mod MIOS, it's probably better to adjust the timer in your app... It's strange that it didn't work though. In all honesty, I never use AINs (I don't even bother soldering the jumper on most of the time) so I might not be the best person for advice.

Alternately, you could use the touchsensor pin (J14/PORDT:RD4) and a DIN... That's what I'd do.

Or maybe just a bit of good old fashioned optimising might get the code fast enough again?

If you've got an oscilloscope, this is where it can come in really handy. (This is one of my favourite tricks I learned from TK) Just set a pin high at the beginning of a function, and set it low at the end, and connect the scope to the pin, and you can tell exactly how long your function runs.

Also, you can take a look in the _output\ directory and see the ASM that your app creates. You might want to sit down for that, it's rarely pretty ;) It's a pretty straightforward bunch of code in C, but it fleshes out pretty well in the output. There are two things that jump out at me

pinval = MIOS_AIN_Pin7bitGet(pin);

you can grab the MSB from MIOS_PARAMETER2 and shift it right like

pinval = MIOS_PARAMETER2 >> 1;
pinval &= 0x7f //mask out the top bit. This may be obsolete, check the output.

Saves you resampling the ain. That'll speed up the AIN_Notifychange i think. The other thing is the BIG tick function:

             S_main__Tick       code   0x00330e    program   0x000204
 S_main__AIN_NotifyChange       code   0x00361e    program   0x0000ac

Notifychange is big enough, but the tick function worked out kinda large, considering the C is not that big really. You might benefit from a trick I've been employing lately to help with some array accesses. You've done a lot of operations on your global variables, and it leaves a banksel command in there every time. Bit of a bummer seeing as they're all in the same bank. Preferably, the optmiser will sort that out, but it's missed quite a few. Access RAM would be perfect, but you have to be careful about how you use it, because it's very limited... but you can leave it to the compiler anyway, by using temporary registers for your working. Instead of doing like this:

void Tick(void) __wparam
{

  int direction = 0;

  if (dostuff){
.... SNIP! ..........
  }

  dostuff=0;

  }

  if (oldsensor1 != sensor1 || oldsensor2 != sensor2){ // if edge transition

  if (oldsensor1 == 0 && oldsensor2 == 0){
    if (sensor1==1 && sensor2 == 0){direction=1;} // 00->10 RIGHT
    else if (sensor1==0 && sensor2 == 1){ direction=-1;} // 00->01 LEFT
    else if (sensor1==1 && sensor2 == 1){ direction=0;} // 00->11 ERROR
  }

...... ETC

Try this:

void Tick(void) __wparam
{

unsigned char tmpsensor1,tmpsensor2,tmpoldsensor1,tmpoldsensor2;
int tmpsensordirection, tmpoldsensordirection;

tmpsensor1=sensor1;
tmpsensor2=sensor2;
tmpoldsensor1=oldsensor1;
tmpoldsensor2=oldsensor2;
tmpsensordirection=sensordirection;
tmpoldsensordirection=oldsensordirection;

\\ I know that looks ugly but sometimes SDCC gets funny about initialising them when you declare them (Like this next line). Go figure.

  int direction = 0;

  if (dostuff){
.... SNIP! ..........
  }

  dostuff=0;

  }

  if (tmpoldsensor1 != tmpsensor1 || tmpoldsensor2 != tmpsensor2){ // if edge transition

  if (tmpoldsensor1 == 0 && tmpoldsensor2 == 0){
    if (tmpsensor1==1 && tmpsensor2 == 0){tmpdirection=1;} // 00->10 RIGHT
    else if (tmpsensor1==0 && tmpsensor2 == 1){ tmpdirection=-1;} // 00->01 LEFT

...... ETC

\\Then set your global variables on the way out


sensor1=tmpsensor1;
sensor2=tmpsensor2;
oldsensor1=tmpoldsensor1;
oldsensor2=tmpoldsensor2;
sensordirection=tmpsensordirection;
oldsensordirection=tmpoldsensordirection;

Or something like that. I haven't analysed the code much and this was written in the browser so don't trust anything you see ;) But it may be worth a try.

If there's some way you can think of, to reduce the amount of comparisons and IF statements, then I'd go for it for sure.

Random thought: If you want signed chars, declare them that way - SDCC has been known to change it's default from signed to unsigned and back ;)

[Zossen]

is it possible to use a " Heidenhein Encoder"  like used in CNC ; they can make more than 1000sinals/U

[stryd_one]

The problem here is not how fast the signals are generated, but how fast they are processed by the PIC....

[rasteri]

Wow, that's what I call helpful...  thanks stryd, I'll give that a go when I finish work.

[rasteri]

Works now ;D

I just put the cap sensor through a DIN* like you suggested. That means I can have MIOS_AIN_NumberSet set to 3 - and this tracks the wheel perfectly.

I'll post code in a bit.

(* - actually just to RD1, and I'm strobing RB4 myself. Fuck shift registers!)

[rasteri]

Here, have some pics

http://picasaweb.google.com/rasteri/Scratchtroller

I'm in the process of updating the wiki page too.

[dstamand]

Here, have some pics

http://picasaweb.google.com/rasteri/Scratchtroller

I'm in the process of updating the wiki page too.

The M-Audio Xponent wheel is almost like the one idea you've built. :-)

Good job so far!!

[rasteri]

I've been designing a more robust version of the device. The scratch wheel will be made out of aluminium or something, attached to a steel rod going down inside the device, then attached to an encoder wheel. It means the optical components can be inside the device.

I'm kinda stuck with one thing though - how can I make electrical contact with the steel rod (and therefore the scratch wheel) if it's going to be rotating? Carbon brushes? Or just stick it through a bush and hope for the best?

I'm obviously going to experiment with various things and post results, but if anyone has any thoughts on this matter I'd really appreciate them. I'm very much out of my area of expertise here.

[stryd_one]

I'd keep the electronics stationary and just move the encoder wheel.

[rasteri]

'Fraid I need electrical contact with the wheel - the metal surface acts as a big capacitive touch sensor.

[dstamand]

how can I make electrical contact with the steel rod (and therefore the scratch wheel) if it's going to be rotating? Carbon brushes? Or just stick it through a bush and hope for the best?

Brass bushing works.

You can try this :

Slip Ring, cost around 75$ USD for 6 conductors.

http://www.polysci.com/sliprings/slipring.html

http://www.polysci.com/images/AC6373small.jpg

[p13fke]

hi,

in an earlier post you said that the sensor sometimes misses the grooves so you made your pattern smaller. Have you tried to split the pattern in two patterns with half the grooves. I dont know how to explain this exactly ,because my english is not the best.so i made a little picture. Keep in mind that i only draw it for one sensor. you have to do the same for the  B Sensor later on.

As you can see Signal A1 and Signal A2 combined are the same as the original Signal A. So the sensors only need to read half the amount of information.

[dj3nk]

I think it has more to do with the update rate of the pic. optical devices are fast enough.

[cimo]

I've been designing a more robust version of the device. The scratch wheel will be made out of aluminium or something, attached to a steel rod going down inside the device, then attached to an encoder wheel. It means the optical components can be inside the device.

I'm kinda stuck with one thing though - how can I make electrical contact with the steel rod (and therefore the scratch wheel) if it's going to be rotating? Carbon brushes? Or just stick it through a bush and hope for the best?

I'm obviously going to experiment with various things and post results, but if anyone has any thoughts on this matter I'd really appreciate them. I'm very much out of my area of expertise here.

i would go for capacitive sensor placed under the wheel, 3mm acrylic shouldn t be a problem for the signal

Simone

[dstamand]

Hey hey! Congrats  :o :o

http://www.skratchworx.com/news3/comments.php?id=991

The coolest thing you'll see this year

Manufacturers around the world are pumping squillions into R&D labs trying to make the perfect MIDI controller. I'm sure there are shelves full of almost but not quite platters of all shapes and sizes littering the vaults of the big boys and many a frustrated Product Manager still searching for the perfect platter for their next generation of bandwagon hopping product. So imagine my glee when some guy in the UK armed with an open source project, a cardboard box and some gaffer tape serves the manufacturers their arses on a MIDI platter. All hail Rasteri - king of the controllers.

[stryd_one]

Fame :)

[nILS]

"Fame" in this context == credit where credit is due ;D

[rasteri]

Heh, Gizmo from skratchworx has been really cool about it. I'm gunna send him one for testing, see how it holds up to other DJ controllers.

Just a few updates. The non-cardboard version is up and running, using a real piece of 7" vinyl sprayed with conductive nickel paint.

Also, the photodiodes now use the comparators of the 18f4620, so it tracks perfectly no matter what. This opens the possibility of a higher resolution wheel, but means 18f452s can't be used. (who cares)

I'll post pics/vids/code as soon as I can. Probably about time I improved the wiki page too....

Future plans include making the unit completely standalone. I've already got 8bit 22khz sample playback working (kinda sorta), just need to figure out if the PICs are powerful enough to allow scratching (probably not). A couple of dsPICs are on their way, maybe they can be used?

[Sasha]

...The non-cardboard version is up and running, using a real piece of 7" vinyl sprayed with conductive nickel paint.

I suppose you sprayed the vinyl so it can be used as a touch sensor. But, how did you connected it to the circuit? Wasn`t that problem?

Looking forward to see some new pix and videos.  ;)

[cimo]

25 kits without 0.0005% cut resistor leads for me.

[Sasha]

Wow, I see you found some good local supplier for cut resistor leads! Are you willing to sell some? I pay good!

[cimo]

.. you know i own a favor or two but this stuff is hot, too hot.Need to think about it ok?

EDIT: yep my noise to signal ratio is too high, this stuff is amazing, i was wondering if 1.8" HDD motors can be used.Maybe not cause the chassis is embedded in the HD.

What about my idea of using "touch" sensitive capacitance system for the wheel?

[rasteri]

I suppose you sprayed the vinyl so it can be used as a touch sensor. But, how did you connected it to the circuit? Wasn`t that problem?

Looking forward to see some new pix and videos.  ;)

This pic explains all :

(http://picasaweb.google.co.uk/rasteri/Scratchtroller/photo#5216080813603959586)

That's an older design, from when I was planning to use an aluminium disc as the scratch wheel, but the principle is the same.

The vinyl is held between 2 nuts (with washers) on an "engineering stud", which is a threaded rod with a smooth non-threaded middle section. The non-threaded part makes contact with the brass bush, which is in turn connected to the PIC. I wasn't sure if it would work, but it's perfect :) Whether it'll still work in a few months time is a matter for debate however...

[Sasha]

Rasteri, thanks for posting the diagram, but you probably disabled some layer in photoshop as I don`t see any Kryptonite part. We all know how importance of Kriptonite in scratch controller designs are, but some neeb can be confused.

EDIT: Not sure did you know, but Kryptonite is recently discovered in serbia (where I live)  ;D

http://news.bbc.co.uk/2/hi/science/nature/6584229.stm