Project Logs

Collapse logs

• Needed a 3d model for the new power switch. Wasted an evening.

  Tim Trzepacz • 3 hours ago • 4 comments

  I like having 3d models for PCB parts so that my 3d board renders will be accurate. I found a lovely switch on AliExpress (which I still haven't even placed the order for) and decided that I needed a model. But the internet didn't cough one up, so I wasted a whole evening and got it done. 

  This was made possible by the fact that they did include a very nice drawing of the part and some decent pictures.
  

  I could have made a simpler model.
  

  I could have done without.

  But I had to do it.

  And I had to do it right.

  I don't know what that says about me.

• Puzzling out power

  Tim Trzepacz • 10 hours ago • 0 comments

  This project is powered by AA batteries. Normal, non-rechargable AA batteries. But I'd also like to attach it to USB for stuff, and draw power from there when it is so attached.
  

  So, the worry is that USB power will back-bias the batteries and they will eventually leak or explode. That would be irresponsible. So I should probably do something about that.

  Now, the easiest option is to simply use a 3 position switch, which has one direction for battery power, and one for USB power. But that's confusing, and I'm not sure what happens when you are attached to USB but on battery power. I don't want to do stuff that blows up computers USB ports, either.

  Now there are plenty of solutions that provide all sorts of protection for circuits against voltage spikes, reverse polarity, etc. Some of the protection chips alone are $2.50-$5, tho, and whole board solutions from Adafruit are $10+. This project is shooting for a $10 price point for the whole thing, so the price points on that kinda stuff aren't really reasonable! And many of those parts just can't be sourced easily in China, where the PCBA happens. If it isn't on AliExpress, I can't use it!

  So, I'm looking at a bare minimum solution that adds a few pennies to the design and doesn't impede performance. 

  The simplest transparent option seems to be to put a diode in series with the battery and the power in, and another on the USB side. 

  But I'm a n00b. What kind of diode?

  I really had no idea, so I got in the Hackaday.io Hack Chat and talked to Al Williams and Jez Boxall. Al pointed out some useful articles ( 1 & 2) and suggested a Shottky diode with a low V_{R .}  After some looking around, I found the 1n5822 Schottky diode on AliExpress for barely over a penny! Al had decamped by this point, but Jez seemed to think the specs were in range for this project. Second opinions are good!

  I also found a lovely set of articles on the topic of polarity protection which seemed to be in the right direction for what I was doing.

  I finally decided to use a diode on the positive side of batteries, and on the positive side of the USB plug to prevent backflow from batteries. Adds 2.1 cents to the design; I think they client will accept it!

  Next thing to do is to order parts and wire it up!

• 3d print of V2 case!

  Tim Trzepacz • 5 days ago • 0 comments

  The 3d printer finally coughed up the finished print of the V2 case! It snaps together very nicely, and screws can be added for increased solidity.
  

  From the front, it looks very similar to the V1 case, but you might notice a much larger bezel around the bottom of the keyboard, an indentation over the buttons, and the thru-hole parts for the PWM are now covered with a little bump.

  The plastic under the banana plug socket had a tiny hole in it due to a very thin feature that I tried to patch with extra plastic and a soldering iron, but just ended up making it worse. 

  The USB port hole awaits a connector! On the real one, if this appears, it will probably be optional and perhaps differently located. Currently, you have to attach the USB cable directly to the microcontroller inside the case, which means I have to disassemble it to work on software every time. This should solve that.

  The speaker mount got a redo as well, but because of some unintended relations in the model, it screwed up the rest of the model, so I had to revert all of that work. I can still get this part from the history, but having it attached to the rest of the design intent is not really possible unless I redo it.

  I had also started on a bezel for the LED ring before I discovered this, so all of that work is gone as well. 

  I finished updating the schematic to reflect the changes I made to the board with bodge wires and cut traces, but I keep crashing KiCAD when I try to reroute the PCB to match.  I've downloaded a new daily build of KiCAD, and will try to install it soon and see if it helps.

  Now that the contest entry has met requirements, I'm hoping to slow down a little and get my sleep schedule (as well as various health issues) back in order, so work may be a little slower.

  The whole case was mainly made for "dog-and-pony" purposes; the project wasn't really ready for that, but contest deadline was Monday, so being pretty is good. I intend to finish up the beautification with the USB port and the LED ring cover, and maybe do something about the amp board that sticks out, but after that I intend to finally get back to the code.

  In the code, the state machine for the UI is being written, but because of the massive debouncing required to make this thing work, that system needs to be tweaked to accommodate the different needs of playing the piano keyboard vs touching UI buttons.

  For example, when tracking the piano keyboard, if the user moves to a new key by sliding the stylus, you want to go to that immediately... unless it is a key you just left, because you might be sitting on the boundary between keys. In that case, you want to wait for it to be stable. But on the buttons, you want to wait a good long time for stability. Probably the best thing to do is to have them trigger on stylus UP, but then you think the user will be confused if they touch the thing and nothing happens. So buttons need a LONG debounce period, and states for both stylus down (update LEDs with solid color change) and stylus up (LEDs flashing in current "state color" to reflect a need for further input.)

  This also applies even to synthesizer systems like the envelope generator state machine. Since the keyboard needs low latency, a "trigger" for envelope needs to start immediately on key down, but then debounce heavily any key up.  This could potentially be done in the envelope generator by having "attack" reassert itself from whatever the current volume level is if there is a momentary off due to stylus motion. This works better with envelopes that are only "attack-decay" than with full ADSR tho, so this might not be an option after all.

  Anyway, it's code that is in the middle of being written, but I'm in CAD land for a few more days...

• Case update

  Tim Trzepacz • 10/09/2018 at 15:32 • 1 comment

  I thought I'd take a few minutes to fix a couple of problems with the original case design and do a 2nd 3d printing, but I ended up spending all night on it.

  A larger bezel means it might actually fit together properly. this time.
  I added alignment nubs and screw holes with proper recesses in the bottom for the screw heads.
  There are now proper holes in it for the stylus and USB plugs.
  The ring support on the front is now shorter, since I had to chop the original one way down, and the hole is bigger so maybe the ring will actually fit in it this time.
  I capped off the bump where the thru-hole components stick up.
  Recessed the area around the buttons a bit.
  Inside, I added support for the battery holders.

  3d printer is running; hope it doesn't burn down the house while I sleep...

• "Just one more pin!"

  Tim Trzepacz • 10/09/2018 at 04:21 • 0 comments

  Previously in our adventures, I had to reuse the line for the MODE button for one of the keys, because the line it was using turned out to be used for USB. <Sad trumpet sound>
  

  Well, I'd still like to have a MODE button, but I'm out of pins. I'm trying to keep the cost down, so I don't want to add extra shift registers and multiplexers to the design.

  Now, if I could hit two pins at exactly the same time (say WRITE and PARAM), I could detect that in software. But if I just wired those two pins to the pad, it would hit both pins if I hit either of the original pads as well.

  The obvious solution to that is to add two diodes going from those pins to the MODE pad that I want to trigger. Current can go to the MODE pin, but it can't come back up to the WRITE pin if the PARAM pad is touched, and vice versa. SMD Diodes are cheap, and PCB assembly houses usually have that kind of thing in their stock, so I'm not even worried about the price of these items.

  The circuit for this is pretty simple:

  I used a 1N4148 switching diode, which is pretty common in keyboards and such and is very good for this type of task. I still have a ton of them from when I was trying to build my own keyboards for the NanoEgg synthesizer project (I will get back to it eventually, I promise!)

  So then, wiring it up:

  The first thing to do is to disconnect the mode button pad from it's pin and from the pad for the key that needed to be remapped.

  Then a bodge wire needed to be run to reconnect the keyboard pad to that pin again. That is in black in the picture below.

  Then, two diodes need to be attached to the MODE pad (black line on that side for correct polarity, and the other end attached to the pins/pads for WRITE and PARAM. I put yellow insulation on the leads to keep it from shorting stuff out. It is easy to find such things on the floor if you never clean up in your workshop / home.

  Here you can see the two diodes in yellow attached to traces going to their pins on the right, and the mode button on the left, and the wire rerouting the key's pad to the pin that was formerly for the mode button in black on the lower left.

  Powered up in software and everything is worky! Yay!

  How to do the software?

  Just put an "if" statement before returning any key down and check for both pins together. If they are down, set the value to the mode button instead of either of those two pins. Standard debouncing applies.

  So, there you go. A pretty basic hack that involves hardware and software, but saves a lot on money for a multiplexer. Obviously, one could use this technique to multiply pins to get more buttons, but at some point board real-estate, part and assembly costs come into play and you might be better off with a multiplexer or shift-register solution.

  Pad multiplication with "charlieplexing"?

  Another interesting possibility, similar to "charlieplexing" would be to move the stylus to a pin that can do input and output, and then use a diode on each pad to indicate whether it was sensitive to being an input or output.  On some pins, the stylus would act to pull the pin, and the pin would be the input. One others, the pin would be the output, and you would detect it's touch on the stylus line. This does require one diode per key, and requires one additional pin for the stylus, but doubles the number of pads you could attach. 

  I'm not sure the "multiple downs per button" thing would work well here, since you have other pads reading current the other way that might be triggered  when you change the line from input to output, but perhaps that wouldn't be a problem if the software isn't looking for that input at the time it is driven that way? I'm not sure; it bears further thought. 

  I know, I'll leave it as "and exercise for the reader" like they did in all of my old textbooks! Don't you just hate that? I always thought that was just the authors getting lazy. Which is exactly what I am going to do now...

• New Intro Video!

  Tim Trzepacz • 10/08/2018 at 15:28 • 0 comments

  I finally recorded the new intro video for Stylish! This one should fulfill all of the requirements for the Hackaday Prize (which the previous video did as well) and the "Tindie Project to Product Program". 

  This video appears only as the result of a full night of hacking to get the thing to be presentable.
  

  First, the inside of the 3d printed case was Dremel'd out to give more room for the PCB so that the enclosure would have a better chance of actually closing. 

  Some holes were drilled in the bottom of the case so that the USB and debugging lines could get out. One of these cracked the plastic and left an oversized hole that I covered with blue tape for the show.

  I was really having trouble getting the case to stay shut, so I designed a part to cover the seam, and printed it out of TPE (aka Ninja-flex) to cover the gap. It worked, but it didn't hold the thing together, so I had to add some clear tape to keep it all from falling apart. In the process of adding the tape, I lost the TPE ring, and so it didn't show up in the video. I found it immediately after uploading the video.

  
  

  I made a new stylus by hollowing out an old permanent marker and adding a tip from a 1/4" to RCA adapter that had broken in half. I used the soldering iron to heat the tip and push it into the plastic, and then to smooth out the plastic afterwards. I soldered a foot long piece of stranded speaker wire to it, which was threaded through the pen body. The pen body and tip had all of the felt removed and once everything was installed I filled it with silicone RTV to seal things up and give it a little weight.
  

  I dug around in my storage until I found an old fashioned banana plug and socket to attach to the case for the stylus to plug into, allowing the stylus to be removed. I am a 3rd generation electrical engineer, and have the accumulated junk^h^h^h^h technical wealth of that I have inherited from my late father and grandfather to dig through, so I can almost always find what I need if I look hard enough. I used the soldering iron to melt a hole through the case and screwed in the socket for the banana plug there, taking care to make sure the plug was not at such an angle as to cause the case to ride up. But then it was discovered that the back of the plug was hitting the speaker mount, so the back of the speaker mount was clipped off. That caused the speaker to immediately fall out, so I taped it in with some clear tape. I'm not proud... ya do what ya gots ta do!

  Then, solder joints were repaired on the board to get the LEDs working again, fix a stuck key, and the new lead for the stylus, which was attached to the banana plug socket with a proper crimped wire contact and everything! Having fixed all of this, the holes for the USB and debugging weren't necessary any more, and I was able to attach the batteries.

  I knew I wasn't going to have the final belt mount ready, but I wanted to have something that would work, so I dug around and found the perfect thing!

  I clipped out the spacers for cables in the middle of the medium sized clips, and super-glue'd them to the back.

  At this moment, I just realized that there is an issue with the video, and so I have to re-upload it. But a TON of progress was made tonight/this morning, even if it was mostly dog-and-pony stuff that won't be reused, it makes it easier to show the thing off.

• Found an open-source version of the Blue Pill microcontroller board.... sorta

  Tim Trzepacz • 10/07/2018 at 23:51 • 0 comments

  While perusing the other Hackaday Prize entries for this year, I noticed that there is an open source version of the blue-pill board that I'm using for this project! The "green pill" is by open-plc.com.

  I followed the links over to GitHub, where I discovered that, while they published PDFs and Gerbers, the original board and schematic files from design software were not in it. So I can't make a nice 3d render of the board, or add modifications, or incorporate it into my own designs or anything.

  So "open", but no usable "source". C'est la vie.

  I sent a message asking for the sources to be posted. Maybe they will do it?

• Storing Patch Data in Flash

  Tim Trzepacz • 10/07/2018 at 14:45 • 0 comments

  I hadn't really looked into the amount of EEPROM "save" memory that the STM32F103 series chips had, but I assumed that it had some, and that it would be comparable to the AVR chips, which have ~1k in Arduino.

  I was wrong.

  It has some storage for registers for power-down sleep conditions, but that's only around 20 bytes. One patch on this system is going to be 16 bytes, fully packed, so that really doesn't help.

  So I looked into whether it would be possible for my program which is in Flash memory to actually save data to Flash.

  It does appear to be possible!

  I found a fine article here on how to do it.

  I haven't tried it yet, but I'll be updating this log entry as soon as I do!

• 3d Printed Enclosure: First Draft Issues

  Tim Trzepacz • 10/07/2018 at 14:05 • 0 comments

  So, 22 hours later, I've got my 1st draft 3d printed enclosure! I knew it was going to have some problems, and I wasn't disappointed!

  As it came off the 3d printer!

  
  But if you don't look too closely, it does look pretty!
  

  The Tindie contest requirements say you should show your project inside and out, so here it is!

  
  

  It... doesn't fit together as well as I'd like, I had to chop, chop, chop away a lot of stuff to get around all of the bodge wires and lumps of solder, etc. and even then it doesn't go together very well. 

  When assembled with batteries installed, it works very strangely. The LED ring will either light dim red, or full bright white when the power switch is on. It will play, but it won't light up correctly. It works fine when USB or programming adaptor are installed. It ran fine on batteries for yesterday's case, so I can only imagine that the manhandling to put it in the case is disturbing some delicate connection somewhere. 

  Anyway, things learned: 

  1. There should be a groove in the bottom part for the board to fit in. 
  2. There should be a much thicker edge around the board. 
  3. The groove in the top part that the board fits in is really hard to get support material out of. 
  4. The hole for the LED ring is way too small, and the tube is too tall. 
  5. The power switch hole isn't wide enough. 
  6. There should really be some holes or groves for the stylus, USB, and debugging connections.
  7. There should be some sort of mount for the battery.
  8. The speaker mounting ring really doesn't fit in the hole when printing, and really had to be chisled out. 
  9. he solder vias at the top of the keyboard cause things to ride up.

  I thought I had to have another video done by 7am, but it turns out to be 7am on Monday. And it's Sunday. Who knew?

  So I get to sleep before I try to make another video. Yay!

• Gerbers and 3d model STL files added to the GitHub

  Tim Trzepacz • 10/07/2018 at 10:26 • 0 comments

  I noticed that there was also a Tindie contest associated with the Hackaday Prize contest, and they require that you share the Gerbers for your project, so I added them to the GitHub. I also added the STL files for the case (that I am currently still 3d printing). Mind you, all of these items are in heavy development, and so might not be quite up-to-date, or if they are up to date, they might not have been tested yet. So, be wary before trying to build it!

  https://github.com/softegg/Stylish-Trucker-Belt-Synthesizer

View all 28 project logs