Jump to content

Scratch wheel


rasteri

Recommended Posts

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)

Link to comment
Share on other sites

  • Replies 208
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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 ;)

Link to comment
Share on other sites

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!)

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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

AC6373small.jpg

Link to comment
Share on other sites

  • 2 weeks later...

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.

Picture.jpg

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Hey hey! Congrats  :o :o

sw_smilie.png

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

...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.  ;)

Link to comment
Share on other sites

.. 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?

Link to comment
Share on other sites

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 :

scratchtroller7.png

(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...

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...