Wilba
-
Posts
3,310 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by Wilba
-
-
Hi,
I finally got my core and SID modules done, hooked them up and can't get MIDIbox SID app to produce sound when I send note on events.
Everything else appears to work fine though.
I have run the SID player app and that works - I get cheesy C64 game themes without problems.
The MB SID step C app runs OK, control surface (I have step A hardware) works, I can use jsynth to upload patches, I can change volume with control surface or from MIDI and get pops and a changing volume of background hiss (all normal I assume from reading posts). I can even change parameters remotely from MIDI-OX or jsynth. What I don't get is any response from note on events other than an increase in noise - I hear the digital traffic or the SID registers being changed... there's a definite change in state, just no note being played.
I've tried the prebuilt hex and syx files - no success.
My rebuilt app should be making sound because I explicitly called SID_TUNE_Play1 in USER_Init and get that rising pitch sound on startup. I haven't changed the source other than that and setting menu items to 4.
Any troubleshooting advice is welcome.
My config (not that relevant though):
MIOS v1.4b (valid CRC), MIDIbox SID v1.5c
SID chip is 6581R3/4385
Core has step A control surface with rotary encoder, 2x16 LCD, no BankStick.
Regards,
Wilba
-
If anyone's interested in getting these PCBs, after posting to this thread, just instant message me your email address and postal address and I will send the PCBs soon after.
-
Analog Devices (http://www.analog.com) make accelerometers in a small chip package. I came across these when they were used in a tilt sensor for a Palm handheld. I thought they might be interesting as a MIDIbox sensor (and I wanted to make a Palm tilt dongle as well) so I ordered some samples of the ADXL202E from Analog Devices and got some experimenter PCBs made (since the chip is a tiny 8-pin LCC package).
The PCB order contained FAR MORE PCBs than I need.
Thus I am planning to give them away to any experimenters out there who are interested in integrating a tilt/movement sensor concept into their MIDIbox. In theory, you could make it sense movement like a Theremin... or the angle of tilt of your hand, or head, or whatever... there are many possibilities.
The experimenter PCBs are 1 inch square, there are pads for the chip and surrounding that is an array of donut pads/holes just like your standard experimenter board.
So if you're an experimenter and are interested in getting some of these PCBs:
- Go to http://www.analog.com/
- Check out the data sheet for the ADXL202E. I'm planning to use the analog output instead of the DCM output.
- Post to this thread to reserve your 3x PCBs
- Order some samples: 2x ADXL202JE (commercial) and 2x ADXL202AE (industrial) - these are identical except for temperature range, I believe. Consider the ADXL210E, which has an increased range (+/-10g instead of +/-2g), but I don't know if it will work as well for tilt.
- Send me one of the ADXL202 samples
- I'll send you 3x PCBs and pay for postage.
Sending me a sample chip is fair compensation for me paying the postage of the PCBs. I would like a couple more chips to play with and I'll give the rest to some local friends.
I have 7 groups of 3x PCBs, plus 3x PCBs reserved for Thorsten Klose.
PLEASE NOTE: I only just got these PCBs and sample chips and haven't tried out accelerometers at all. I don't know how good this idea is, or if it will turn out to be a useful and incredibly cool control method or just a novelty. Don't expect an instant "air mouse" - there's still some coding to massage the raw data into useful MIDI state.
If there's some success to this whole idea, maybe at some point in the future uCApps will host an "official" PCB design which non-experimenters can buy/build. So if you're interested in the idea but aren't an "experimenter", hold off getting these experimenter boards until a proof-of-concept prototype has been achieved.
Regards,
Wilba
- Go to http://www.analog.com/
-
Hi,
I would love to work on this app for you, TK... I'm a software engineer by profession (electronics and music are my hobbies)... and would love to contribute back to the community here by donating my skills.
The functionality doesn't appear difficult, but getting the multiple windows to work (ie. designing a good framework) might be tricky.
Wilba
-
I know they stock it at a local art supply shop (ie. where they sell canvas, paint, craft supplies, etc.) Perhaps you should check out ones in your area.
Found this, must be new:
http://shop.store.yahoo.com/embroideryadventures/lazertran1.html
For those in Melbourne, Australia:
Last time I checked, they had packs of 4 x A4 Lazertran paper for AU$24.65 at Eckersley's Arts Crafts & Imagination in Prahran. I was also told they sell a single A4 page for AU$6.85.
Wilba
-
I'm using photodiodes instead of LDRs... they have fast response times and they are usually spectrally matched to infrared light, so you can use infrared LEDs and ambient light is less of an influence. You can effectively treat them as LDRs... more light = more current flow = effectively lower resistance. Don't know much more about the electrical differences.
What I do know is: a reverse-biased photodiode gives high-speed response and a wide propertional range of output - ie. good sensitivity to light levels.
The best advice I can give is: get one of those experimenter boards and experiment with different parts and circuits. The real trick will be getting the vane right... I think reducing the amount of movement between no blowing and full blowing, and then mounting the light source and sensor close together will give the best results... but that's just a guess...
Some links that I found while researching MIDI controllers and optical sensors:
The Theramidi uses two LDRs and a PIC, includes circuit diagram.
http://www.soton.ac.uk/~rmc1/robotics/artactile.htm
Interesting theory regarding tactile/force/pressure sensors, including using optical techniques.
Wilba
-
Nice diagrams!
I've experimented with infrared LEDs and photodiodes...
In my experiments, I had them about 7 cm apart and was able to detect the blocking of the beam with a finger, with a fairly good range of output voltages over about 7mm of finger movement.
You could use the sensor you suggested, but if you want full control over sensitivity etc. you really should build it using a photodiode and resistor.
What worked easiest/best for me was using the photodiode as a basic current-to-voltage converter - the photodiode is reverse biased, anode to ground, cathode to a resistor to positive rail, voltage at cathode will then range between ground and positive rail (eg. 5v) which you can then plug into an AIN input. You'll need to tweak the resistor value to get the sensitivity you want. NB: voltage will be inversely proportional - ie. more light = closer to 0v, less light = closer to +5v. You could either invert the value in firmware or even redesign the layout - ie. put photodiode above the pipe, LED below the pipe, valve between them and the mouthpiece so the valve opens and blocks the ligh path. Just a thought...
The other way of using a photodiode involves wiring it up with an opamp so that it gives a better linear response - ie. rather than outputing a voltage relative to ground/+5V, it outputs an absolute voltage relative to the amound of light. But I found that it wasn't worth the extra effort. If your +5v reference voltage isn't too stable, then the first way (a pseudo-potentiometer in effect) works better.
I'm interested in building something similar... I'm not sure what to make the valve out of... if it's too flexible it might flutter like a flag in the wind.... which I guess could be a feature!
Will post circuit diagrams soon - they're all scribbles on notepaper atm.
Wilba
-
Finally had JDM programmer success last night.
I tried reusing my PIC16F84 JDM programmer without success, the programming voltage was too low even at I/O delay 1. (I was using I/O delay 10 with PIC16F84 chips.)
So I rebuilt the JDM programmer on an experimenters board according to circuit diagram on uCapps.de. (8.2v zener diode instead of 8.7v)
The programming voltage was less than desired and it didn't burn.
So I substituted the 8.2v zener with a 9.1v.
Still didn't work with I/O delay 1, but with I/O delay 10 it WORKS! Just thought people should know that a 9.1v zener works, and that a very low I/O delay might be a cause for failure.
TK: I suggest you update the JDM module page and mention using a 9.1v zener as a substitute. Also mention that a low I/O delay can introduce problems of its own - perhaps because I'm running a fast PC?
-
I solved a problem I had with IC-Prog and the JDM programmer kit I got from Talking Electronics when running Windows XP. I couldn't get the "official" IC-Prog NT driver to work for me, hence discovered this workaround solution.
In short: I use a device driver (totalio.sys) that gives total access to the I/O ports like the good old DOS/Win95 days. Solved problems I had using this JDM programmer with 2000/XP and buring PIC16F84 (but should in theory also work for other PICs since it's just an IC-Prog issue I had).
Go here to find instructions and required files:
http://www.talkingelectronics.com/FreeProjects/MultiChipPgmr/MultiChipPgmr-P3.html
Wilba
-
I'm also building SID step B with a 16x2 LCD, four selection buttons and encoder, using encoder's button as the menu button (plus seven other buttons/leds).
Captain Hastings: I noticed that at line 405 in cs_menu.inc, there's the assumtion of a 20x2 LCD/5 selection buttons... the name editing menu has five options ( < > Del Ins Clr ). Which means you miss out on the "Clr" command, which I assume won't be that big a deal.
goyousalukis: Do you see the left/right arrow symbol in any of the menus? If you do, that ought to validate that the core has firmware configured for 4 menu items. Can you check the last displayed parameter in each menu with the tables in cs_menu_tables.inc and tell me which ones work and which dont?
I'm keen to find out what's wrong here as I want to use a 16x2 LCD myself... had a quick scan of source code and can't find anything wrong with the code. I should be finished soldering soon and will do some testing myself (maybe within a week).
Wilba
-
Trapstate: I've checked out that datasheet before... but initially thought it would blow out my budget... and also got the impression they would trigger even if your finger was near the contact (not what I want). Maybe I'll check it out in more detail...
Can you explain that picture? What is it?
-
TK, you continue to blow me away with detailed responses... thanks a lot!
Best regards,
Wilba
-
Directed to TK:
As per our discussion in another thread, I'm planning to make an array of touch sensors. The DIN module design is quite clever - I wish I thought of that when I was prototyping!
What I'd really like to know is how they work, electronically and in software.
I am assuming pin 14 goes high just prior to sampling the DIN inputs, thus charging any fingers touching the contacts, then it goes low and the DIN inputs get sampled.
How does the parameter set by MIOS_SRIO_TS_SensitivitySet control sensitivity? If my assumptions above are correct, I'd also assume it controlled how long pin 14 goes high prior to sampling, or control a delay between it going low and the DIN inputs being sampled.
I'm asking all this because I plan to have a long cable between the touch sensor contact and the DIN inputs and I'm wondering if that will affect things... Also wondering how the 47k resistor value was determined - it pulls DIN inputs low, but can sensitivity be improved by increasing current to the fingertip and getting pin 14 to drive a current sourcing transitor rather than source the whole current from the PIC?
I'll have my core module/DIN module finished soon and I can do some experiments of my own... but I still need some idea what's going on first.
Regards,
Wilba
-
1A!
??? What does that mean? One amp?
-
In case you're interested, the controller I'm building is inspired by the Ztar ( http://www.starrlabs.com/ ).
(Check out a video of someone playing one: http://www.shanesanders.com/music2.html )
I'm not copying the Ztar completely, because I can't get my hands on force sensitive switches (on the Ztar, ALL the fretboard buttons are velocity/force sensing!) and I can do without polyphonic aftertouch (not many synths use it anyway).
So the main differences are: 4 "strings" made of touch sensors (ie. zero "action" in guitar-speak), and optical strum/pluck sensors, both concepts already proven in prototyping using PIC16F84... It will have a joystick for pitch bend/expression effects (salvaged from play station controller!) and some other analog input devices.
When it's complete, I plan to share the circuits and source code with the MIDIBox community, in case others are interested in building something similar. (I can't wait to hook it up to the SID and jam with it!)
Wilba
-
MIDIBox SID (step A first, ultimately step C)... also a MIDI controller/instrument inspired by Ztar (see here: http://www.starrlabs.com/ ) basically an array of touch switches in fretboard arrangement and optical strum/pluck sensors. Encoders are for basic parameter control.
-
I'm having trouble locating a supplier if rotary encoders that is either in Australia or delivers to Australia.
Any Aussies out there who can suggest how they got their hands on some?
Thanks,
Wilba
-
$16 is a good price. I bought two on-line for US$25 each! So count me in for at least two.
-
Thanks for the answers TK,
On the other hand: it would be interesting why you don't plan to use the standard handlerOK, since you're interested, I'll explain further...
I've been working on a custom MIDI controller for a few months, using a PIC16F84... until I realised I really needed more I/O pins, A/D conv, more RAM, etc... Came across uCApps/MIOS and now I'm keen to use MIOS and PIC18F452 to do the job. (Also really like the SID project so I'm building one of them too).
The controller is a fretboard design, like a bass guitar. Instead of strings there are touch switches (copper wire) between where the frets would go. There are also plucking/strumming sensors which are an infrared LED/photodiode pair - you break the beam with a finger.
One "mode" just maps presses on the touch sensors to note on events directly - ie. just a keyboard-like interaction. The other mode is guitar-like - ie. you need to strum/pluck to get the note, and while a strum/pluck sensor is down, fret changes trigger notes played legato (with optional portamento) or even retrigger currently held down frets higher up the string, etc.
So the reason why I wouldn't want to do it in a USER_DIN_NotifyToggle handler is because I need to take into account the entire state of all the registers (ie. calculating the "highest" touched fret, comparing to "highest" touched fret last time, calculating velocity from time of partial to full blocking of IR beam, etc.)
It's a bit more complex than "button A AND B" - I was just trying to simplify it to give an example...
Thanks again for your help... I should be able to utilize the SR_DIN_CHANGED array to do all I want.
Regards,
Wilba
-
can't get free samples to Australia, via the on-line form at least...
I've answered my own question - the RAM layout is slightly different so although in theory you could get MIOS running on a 458 (by changing the source), the binary probably won't work.
Should have just ordered 452's in the first place... my mistake.
-
Hi,
This is directed to Thorsten, but anyone else could help me if they want!
I'm a total newbie to MIOS, but I'm a software engineer so I can appreciate how great it is. TK you're a legend!
However, what I'm currently stuck on is the lack of documentation regarding when MIOS ISRs get called and what you can and can't do in them.
What I want to do is not use USER_DIN_NotifyToggle but rather do my own handler of edge transitions in the DIN shift registers.
I am ASSUMING I can just handle USER_SR_Service_Finish and then call MIOS_DIN_SRGet to get the FSR to point to the start of the "array" containing the captured state of the DIN module's input pins. Then in this handler I can compare to a cache (in my app's memory) and do whatever MIDI I/O I want then - by iterating FSR1, I can compare the before/after state of the captured DIN input pins.
ie. I want more than a toggle handler... I want to do things like "if this switch is currently closed AND another switch becomes closed, then send this MIDI event" etc.
I just want confirmation that (a) USER_SR_Service_Finish gets called between updates of the DIN state in RAM, and (b) I can iterate FSR1 to iterate over that DIN state in RAM (I don't need to call MIOS_DIN_SRGet to access each register, right?)
ALSO, what's the mapping between DIN module pins and the bit positions in registers returned by MIOS_DIN_SRGet?
Apologies if this was already answered on the forum or in a MIOS example...
Thanks,
Wilba
-
Thanks all for the other supplier sources... I was actually hoping someone else had tried using the 458 before and would tell me it should work... I guess I'll just try it and see what happens!
The reason I got the PIC18F458 from Futurlec was cos it was US$9.90 and only US$3 postage to Australia, Canada, EU, UK, USA. That's better than I've seen anywhere else. They list the PIC18F452 (US$8.90) but it's currently not in stock. Futurlec were REALLY fast in getting the order to me (package was shipped from Thailand, actually)... and they have cheap LCD modules too and a very cheap PCB manufacturing service (although you need Protel files).
Next time I'll just wait till they get 452's in stock and order them instead.
-
Hi,
I couldn't find any PIC18Fxxx suppliers in Australia so I ordered a PIC18F458 from Futurlec (they didn't have PIC18F452 chips in stock) and the datasheets are practically identical. The only differences I can see are a CAN module and "enhanced" CCP module (ie. extra features on the PIC18F458 ).
Anyway, this was before I was convinced I should not try to reinvent the wheel and go 100% with MIOS.
Now if I had the source to MIOS, I could just open it up in MPLAB and validate that it will work on the PIC18F458 (ie. recompile with different inc file if need be).
But since I can't do that, I'll have to just plug it in and see what happens, but then if it doesn't work, I won't know if it's my board, or my programmer not working, or the fact that I'm using a different PIC.
Hmm...
Any comments/suggestions welcome.
Wilba
MIDIBox SID troubleshooting
in Testing/Troubleshooting
Posted
I'm already using MIDI-OX to send the Note On/Note Off events.
While debugging what might be wrong, I even validated that MIDI-OX was sending those events by running MIDImon on the core.
I can send other events (eg. on channel 1) and they're received and do things, ie. changing CC values update the displayed values (and changing volume using MIDI-OX to send CC #7 events results in pops and background hiss volume changes).
ALSO if I change the MIDIbox SID's MIDI channel to 2 and keep sending channel 1 note on events, I don't get the same digital noise - therefore I believe that it's not a MIDI communications problem.
I'm at the stage now of running debug commands to peek into RAM and see what's going on!
What annoys me is that it will probably turn out to be some really simple mistake on my part, but I'm blind to it! >:( I can't see how it's a bug in the application, but that's what my troubleshooting suggests... ???
Regards,
Wilba