I 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.
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.
from msvcrt import getch
print("press ESC to exit")
key = ord(getch())
if key == 27: #ESC
elif key == 224: # special keys (arros, f keys, ins, del, etc.)
key = ord(getch())
if key == 75:
elif key == 77:
elif key == 80:
elif key == 72:
Done 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.
As 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”.