Monthly Archives: March 2014

Noise Source Transistor — Conclusion

DSC00098_2I have been working for a while to determine which transistor to use for noise source in noise generator.  I was using 2SC3311 which was obsoleted recently.

I did several tests, mainly by listening, and chose BC547.  The reasons are:

  • It has good taste as a noise source.  Easy to find sweet spots when using it with a filter and VCA.
  • Noise level was close to 2SC3311, so my previous design works with simple replacement.
  • Availability is good.
  • Unlikely to get obsoleted soon.

I started the test with listening “raw” noise without any modification and filtering.  However, it didn’t work well.  Many of the candidates sounds similarly.  However, I found characteristics of transistors are so different when I also used a VCF and a VCA driven by an envelope generator.

Also, it was hard to determine “which sounds better” when I conducted A/B comparison test.  So I changed the strategy and just played with synth using each candidates, and chose one I felt the most fun to play with.  Thus I gave up “measuring” eventually.

Demo using the chosen transistor.


Reading Keypress with Python

This works for windows.

http://stackoverflow.com/questions/12175964/python-method-for-reading-keypress

However, you cannot use this feature from cygwin.  You need to invoke python script directly from Windows.  Double-clicking the python script works, but you need to catch exceptions in the case (otherwise, you don’t know what happened when an exception was raised).

Here is the sample program to read arrow keys.

#!c:\Python32\python

from msvcrt import getch
import sys

print("press ESC to exit")

while True:
    try:
        key = ord(getch())
        if key == 27: #ESC
            break
        elif key == 224: # special keys (arros, f keys, ins, del, etc.)
            key = ord(getch())
            if key == 75:
                print("left")
            elif key == 77:
                print("right")
            elif key == 80:
                print("down")
            elif key == 72:
                print("up")
    except:
        print(sys.exc_info()[0])

SPI / RX collision test

spi_rx_collision_testDone collision test between SPI and RX in the comm driver.  The driver would receive RX signal any time, even while the host processor is accessing the driver via SPI to send or retrieve data.  Currently, the serial RX is handled in external input interrupt handler, so any bug in RX handler may break registers (i.e., states) for SPI communication.  I actually saw those bugs several times.  The bugs are fixed now and load test has passed.  In the test, the load generator keeps sending data via serial channel.  I’ve changed the timing of data retrieval in the host of the receiver so that SPI / RX collisions frequently happen.  Actually, they are happening every other packets in the test.  The test ran for 10 hours so far and there is zero communication error.  Session keeps going without freezing.

Dragon’s Tail

dragons_tailAs mentioned in my previous post, AVI Dragon’s SPI pins in debugWire interface have to be disconnected during debug run in order to properly run an application that uses SPI / USI.  I also noticed that the Dragon dominates RESET pin, too.  In my project, I’m resetting target chip from Arduino.  The Dragon is killing this functionality as well.  This makes me quite uncomfortable with my development work, so I’ve enhanced the switch I made on bread board previously, and made a helper device.  It’s nicely working.  I named it “Dragon’s Tail”.

Continue reading