TRAXMOD

Project Background FAQ Support Forum Developer's Area (schematics, firmware, etc.) SD Cache Methodology SD Card Interface

Nectarine Demoscene Radio United Trackers MODs in Memorium The Mod Archive

Go back to the main TRAXMOD page.

Archived News

Put a samples order in for some PCM1770 DAC chips with integrated headphone amplifier and digital volume control. Hopefully this will provide decent quality audio while taking up the least amount of board space. I used to think the PWM-DAC was the best way to do audio without I2S support in my microcontroller. When you add up all the components for doing high quality 16-bit PWM audio and volume control, it takes up too much board space and it's too complicated. If we can do I2S with a slave mode SPI port and some tricky clock signal routing, we might be able to use almost any off the shelf audio DAC chip.

Spent some time this weekend working on the AD1955 DAC chip, but I think I might put it on hold. Many people on the Internet liked the sound quality from this high-end DAC chip, but ultimately, AD1955 looks like a lot more work than I bargained for. It requires an external current to voltage conversion, filter, and differential output to single ended output conversion stages. The example circuits needed +12V and -12V power supplies. Still might use it for a USB DAC project if I ever get that far.

A lot of people on the Internet really like the sound quality of non-oversampling TDA1545 16-bit DAC chips that Philips made. Seeing that my old Gravis Ultrasound Rev 3.4 sound card used one of these chips and remembering the sound that used to come out of it, I'd tend to agree with them. Too bad I can't get samples or even buy those chips any more. It might have been fun to play with them. The DIP packaging would be a plus for tinkering on the bread board. As it is today, I will not be able to play with the PCM1770 until I can at least make a breakout board for it.

I love some of the music coming out of the software synth tracker Psycle. Check out the free music available here to get a taste: Taika-Kim -- Goddess Guerrilla. Wow!

Spent the weekend working on a new volume control idea. The last idea didn't work particularly great in practice, but this new one shows good potential.

Basically, the idea is to adjust the power supply voltage to a 7414 inverter/driver logic chip. This will cause the amplitude of the PWM signal to be higher or lower, without directly modifying the audio signal at all. An additional op-amp can be used to provide this variable voltage power supply for the 7414 logic chip. The input to the power supply opamp can be a single pot voltage divider, or it can be fed from a microcontroller PWM pin (heavily low pass filtered to provide a stable output voltage).

The beauty of this idea is that the volume control does not directly touch the audio signals, so it should introduce very little noise. Since the opamp input is high impedance and we don't need very fast changes, the input volume control signal can be heavily low pass filtered. Another benefit is that the audio signal can now be driven at higher voltages than the microcontroller's 3.3V I/O levels, which should also improve performance, plus allow for higher output volume (if desired).

Starting to kick around ideas for laying out the player inside an enclosure again. I'm thinking of making two or three different PCB's that stack on top of each other with header pins connecting them together. Here is a mock up of what could be the main processing board:

This would essentially be a second generation BBMICRO protoboard with the SD Card socket interface added. I will replace the 74HCT14 inverter with an open-drain 74LCX06 inverter chip. The two extra gates that were previously unused in the BBMICRO will be connected to two PWM pins for digital volume control. I have not tried using this chip before for inverting serial port signals, but hopefully it will work. The right hand side showing batteries would not be part of the board, they are just there for reference to give me an idea of how much room I have left inside the enclosure to fit the board into.

The header pins are layed far enough apart so that the board could alternatively be plugged into a bread board instead of crammed inside a plastic enclosure. There is no possibility to fit the SD Card socket between the pins, so this board will end up completely covering up one side of the bread board. It should still be possible to wire up the bread board first, then insert the PCB on top. Not quite as convenient for making rapid circuit modifications, but still pretty nice.

When the board is used for building a TRAXMOD audio player inside the plastic enclosure, most of the connectors will be left off, not soldered in. Not installing the DB9, JTAG header, reset button, and DC power jack will give more room for the audio board to fit closer to the mainboard. If firmware needs to be FLASH upgraded, the user will have to remove the board from the plastic enclosure and temporarily connect (but not solder down) a DB9 connector for serial communication.

The audio board might then look something like the diagram to the right. One 3.5mm audio connector would be for audio out, while the other for audio in. Two MCP6004 op-amps provide low pass filtering for the audio out, and line drive for the audio in. I'm not sure about the switch, maybe it would be an on/off switch or maybe it could serve some other purpose. Maybe I should put some buttons on here, or maybe those should go on a third board? I kind of feel like user interface stuff should go on a separate board covering the entire surface area, including battery area. If I had a battery charger circuit, maybe it could go in unused space on the audio board? Haven't worked out all the details yet.

Built three more BBMICRO boards this weekend. Only tested one of them so far, worked fine first try. Haven't put any up for sale yet, I might need an extra board myself for some prototyping of a battery charger (if I get around to working on that).

Spent some time this holiday weekend brainstorming ideas with my brothers. I want to add a volume control feature that does not throw away any DAC resolution to achieve lower volume levels. That rules out doing the volume control strictly in software, unless we ran our DAC at a higher resolution than 16-bits. I don't want to do that for other reasons (more calibration intersection points to worry about, and/or lower PWM noise frequency).

The simplest solution is to just use a dual potentiometer. My crummy pair of head phones has this built in to the cord, which is how I am using the player currently. But using a pot like this is crappy. The dual pots don't always match up, resulting in balance mismatch and you can audibly hear scratching noises when adjusting the pot.

The solution I'm thinking of building is to use an open-drain inverter chip. The inputs will be connected to another PWM pin of the microcontroller, and the outputs connected to the initial PWM-DAC output node through a low valued resistor (say 330 ohms or some such). This will allow the volume control PWM pin to pull down the amplitude of the audio signal, without (hopefully) affecting the other audio signal properties. The software can control the output volume by setting the volume PWM pin's duty cycle. The software will not have to do any calculations using this method, and it does not impose more complex DAC calibration. Because we probably don't need very many different volume settings, the volume PWM pin can be configured to run at a very high PWM frequency, way beyond the audible frequency range.

According to my brothers, this method's downside is that it makes the initial audio output node of the circuit no longer a fixed impedance. This will alter the frequency cut-off of our fourth order low pass filter, unless we stick a buffering op-amp in front of the low pass filter circuit. So, it is starting to look like the audio circuitry is going to need a lot of chips (albeit low cost chips):
• One dual op-amp chip. Two op-amps used for the fourth order PWM-DAC audio output filter.
• One dual op-amp chip. One op-amp used for a second order audio input filter/gain circuit (for sampling audio). One op-amp for buffering the volume control audio output prior to entering the fourth order audio output filter.
• One open-drain inverter chip for the PWM volume control feature.
One of my brothers keeps telling me I should ditch the PWM-DAC and just use an off-the-self DAC chip that has volume control and filtering all built into one chip. He can't seem to get it through his head that off-the-shelf audio DAC's are usually difficult to interface to because they have very strict input data clocking requirements that necessitates using a more expensive microcontroller with I2S support. If I'm going to ditch anything, I think I'd ditch the output low pass filter to reduce component count. Just use one op-amp for buffering output to head phones, and one for audio input gain adjustment. The raw PWM audio sounds the same to me on everything I've hooked it up to, who cares if there is some super high frequency PWM noise in the output that no one can hear anyway?

We also brainstormed about how to make good touch sensitive buttons. A long time ago, my brother made a touch sensitive lamp switch. It worked, but it was kind of crappy because once in a while it would falsely read some ESD and turn off the lights on you (hehe). That was back before we were using microcontrollers.

One method I read about on Usenet was to connect a small (10pF) capacitor between two microcontroller pins. One pin outputs an A/C signal, while the other pin reads that signal back, through the capacitor. If someone touches the read pin, they end up sucking up all of the charge from the tiny capacitor such that the A/C signal can no longer pass. The downside of this method is that you probably can't really tell how close someone is to touching the pin without using an ADC pin to read a lower amplitude A/C signal. I'm not even sure if the ADC could see the lowering of the A/C signal very well anyway.

A different method my brother had been playing with is to use an LC oscillator to drive a microcontroller timer count pin. The LC oscillator circuit will be rigged such that the output frequency changes as someone comes closer to touching the electrode (increasing the capacitance value). The microcontroller just needs to read the frequency of the LC oscillator circuit to determine how close someone is to the sense pad. This requires more components, but could allow for more sensitive readings.

Added firmware v0.5.2 to the Developer's Area.

This firmware adds the battery voltage monitor code and the beginnings of an interrupt driven SD Card block read routine. For some reason, I can't get the interrupt handler code to work when reading more than 2 bytes from the FIFO per interrupt.

Started working on adding some code for monitoring the battery voltage using an ADC pin. I don't always get a good reading, maybe I need to add a capacitor or something. Don't have time to do much more work on it right now.

Posted v0.5.1 firmware and schematics in the Developer's Area. The schematic now includes a fourth order low pass filter using the MCP6004 quad op-amp chip from Microchip. This chip is pretty cheap at only $0.36. The audio signal on the oscilloscope looks much cleaner now, very little high frequency PWM ripple left after going through the new low pass filter.

Also fixed a bug in the firmware's audio interrupt handling. It wasn't disabling the PWM reload ISR between samples, so the higher the PWM frequency, the more CPU being used up by the PWM reload ISR. Also modified the 16-bit DAC calibration for a 1K to 274K resistor divider ratio. This allows us to run the PWM at a higher frequency (making it easier for the low pass filter to smooth things out).

Turns out the PWM audio likely had nothing to do with why the player sounded like crap in my brother's Honda Civic. I was using a 4 conductor 3.5mm audio jack and cable, but hadn't grounded both ground conductors. Grounded the second one and the problem went away.

Been too busy at work to really get any further progress on TRAXMOD. But, I've been listening to music daily using the new 16-bit player and enjoying it quite a bit.

We hooked it up to an oscilloscope to look at the audio signal. Even though we have a first order RC low pass filter on the audio output, the 137KHz PWM frequency is still very visible on the oscilloscope. This high frequency noise is generally too high pitched for the human ear to hear, so it doesn't noticably affect the audio output under normal conditions. Most speakers can't produce this high frequency, which also helps.

However, we hooked up the player to a 2007 Honda Civic head unit and it sounded like crap there. This head unit is probably running the audio through an analog to digital converter (ADC) so that it can do some DSP audio effects on it. Perhaps the ADC's sample acquisition time is fast enough that it can see the PWM signal. As a result, the audio ends up missing all of the midrange sounds and what is left over sounds like it is being played through a long sewer pipe.

Started playing around with the Microchip FilterLab filter design software. To eliminate the high frequency PWM signal, we could add a higher order low pass filter using an op-amp. The higher order filter will slope off faster than the first order filter, making the 137KHz PWM square wave much smaller. Adding opamps could also have the benefit of increasing the total output power of the player so that we can drive headphones or small speakers better.

Fixed some more minor bugs in the 16-bit DAC code. Posted the TRAXMOD/ARM 0.5.0 firmware and schematics in the Developer's Area. This version doesn't play MOD files correctly any more because the mixer code needs some work to interface properly with the new 16-bit DAC hardware. But the RAW audio player works with very nice audio now.

Found and started fixing a bug in the 16-bit DAC calculation where it was sometimes calculating an invalid least significant byte (LSB) value. Now I can finally definitely hear a difference in sound quality when playing a quiet song with the LSB PWM pin enabled vs. disabled. When the LSB pin is disabled, I can hear a faint background white noise that cleans up nicely when the LSB pin is enabled.

I'm still not sure that I have the calculation 100% bug free, there still might be some more improvement possible. But being able to hear a sound quality difference now is quite exciting!

Last night I hacked some firmware together that seems to make the 16-bit DAC work okay. I can't say I really notice much difference in sound quality when 16-bit mode is enabled vs. 8-bit mode. Maybe a little longer sizzling at the end of a quiet song that slowly fades out as its ending. It's possible maybe my old ears just aren't good enough any more to hear that much resolution.

It would be nice if I had a better way of capturing the output voltage readings. I feel like my voltmeter just doesn't have enough precision to measure the few µV difference betwen least significant bit (LSB) changes. Ideally, I'd have a very high precision ADC, well calibrated, and means to automatically capture the data to my PC for manipulating in a spreadsheet.

Spent the entire weekend working on the 16-bit DAC using two PWM pins. I think I have the hardware wired up and working okay now on my breadboard. I still have more work to build the software to drive the thing properly.

I added a feature to the firmware to let me step through each PWM's timer values so that I can take readings of the final output voltage with my meter. From there, I need to figure out a calibration formula that will let me take 16-bit sample data and convert it into the correct PWM timer values to produce a perfectly linear and monotonic 16-bit DAC output.

My meter doesn't let me see changes less than 0.1mV and it might be making some other mistakes down at this precision level. I'm seeing unexpected output voltages when the PWM high pulse is set at 1 to 3 clock cycles long. It smooths out and provides the expected voltage increments for the longer pulses.

If those readings are correct, it means the calibration formula has to avoid values at the top AND bottom of each PWM pins' period range.

Posted firmware v0.4.8 for TRAXMOD/ARM in the Developer's Area. This code adds some better handling of start/stop audio pops between files.

It also has some experimental code in rawplay.c for using the FAT file system to find the first SD Card address of a file, then bypasses the file system to read the file directly off the SD Card. This will become useful for playing large MOD sample data directly off of the SD Card again like the old dsPIC proof of concept did.

Someone should write a function to check a file for fragmentation. If a file is fragmented, we could skip trying to play it so that the user doesn't end up getting blasted with garbage when the player tries to play a fragmented file directly off the SD Card.

Here is a nice tutorial explaining various DAC designs: MT-015: Basic DAC Architectures II: Binary DACs.

The design I am thinking of is a hybridization of the basic PWM DAC with either a Binary-Weighted Resistor DAC or possibly a R-2R Resistor Ladder DAC. Instead of making inputs for each bit of the DAC (spaced at 1 bit apart), we will have one input for each PWM pin connected to the resistor DAC. The resistor network will then be spaced further apart (ex: 8 bits for 2 PWM pins to make 16-bits).

The spreadsheet I posted is for the Binary-Weighted Resistor DAC hybridized with the PWM DAC. My guess is that the R-2R Resistor Ladder DAC could be used instead, but I have not done the calculations to verify this yet. Hopefully, if I can get some time, I can play around in SPICE to verify the circuit details for both types of hybride PWM/Resistor DAC's.

One of the big problems with manufacturing a high resolution resistor DAC (greater than 4 to 8 bits) is that the resistors must be very precise in value, otherwise the ratios will not be correct and you lose monotonicity. However, I believe that the problem could be worked around by software. Inside the microcontroller, we can dynamically adjust how many bits of resolution to assign to each PWM pin by changing the PWM registers. As long as the range of possible output voltages produced at each PWM pin has some overlap with the adjacent PWM pin(s), resistance errors could be overcome by adjusting how high to count on each PWM pin.

This will require more processing time in the microcontroller, but it should be doable. The main thing worrying me now is the low 3.3 operating voltage. The lowest order bit will be producing 50µV (3.3V / 2^16), or even less if the PWM pin output voltages are required to overlap for resistor error tolerance. At that low a voltage, noise could be a problem.

Had a little brainstorm session with my brother Fritz about increasing the PWM-DAC resolution. Using the current hardware/firmware, we can only reach about 10 bits of resolution at 44.1KHz.

The idea we came up with was to use two PWM pins for each audio channel. The two pins would be connected through a resistor voltage divider to allow the two pins to work together at producing the DAC voltage. One pin would provide the most significant bits (MSB) of the output while the other would provide the least significant bits (LSB). Thus, using four PWM pins of 8 bits resolution each, we could achieve 16 bits, 44.1KHz, stereo audio.

I haven't actually tried this idea out on my hardware yet. We did a bunch of calculations in a spreadsheet and the results look like they should work fine. I've put a copy of this spreadsheet in the developer's area (pwm-dac.sxc, open using OpenOffice.org). If this idea really works, it will be totally sweet, as we will not need to buy a separate DAC chip to get high resolution audio. I love making more using less!

Spent some time this weekend to solder two more complete BBMICRO development boards. My brother bought one of these Habor Freight Heat Guns for a mere $10. I used it to help smooth out some of the soldering on the LPC2103 LQFP-48 chips. It seemed to work nicely. I think this might make it a bit easier to build boards using this chip in the future. I have been using a plain soldering iron, but sometimes the solder wants to extrude a little as you pull the iron away. Using the heat gun lets you melt those tiny extrusion bumps away without physically touching the solder, so you get nice smooth solder joints. I like it!

I also started using a Schick razor blade I bought at Walmart. This is the only thing thin enough to reach into the 0.5mm pin pitch. Sometimes you get a little piece of burnt flux stuck down between two pins and there is no way to reach in there to pull it out. Washing gets rid of most crud, but sometimes a little piece can get stuck. The Schick razor blade can get in there and pull it out. I put tape around the rest of the razor blade so that I don't accidently cut myself while holding it. I also cut it so that it has a sharp corner instead of a rounded corner, for reaching down beneath the chip better. Solder doesn't want to stick to the big cold razor blade, so you can even use it to help clear solder bridges between pins sometimes. I've never needed it for that purpose though lately.

Haven't had much time to play with the TRAXMOD project, but finally did a little work this past weekend. I'm putting together a new converter program that will generate an intermediate module file format for TRAXMOD to use (*.TMD). This intermediate file format will basically be a regular MOD file, but will have all of the sample data byte aligned to 64 byte blocks for playing modules of any size directly off of the FAT formatted SD Card, using limited microcontroller RAM.

I've been screwing around with the DirectSound API using Visual C++ 2005 Express Edition. I'm hoping to build some test playback code for the PC so that I can play/test TMD file formats quickly (faster than swapping SD Cards and new firmware into the TRAXMOD hardware for each little change). This weekend I was able to compile some example C++ code to play a raw wave file. I was pretty stoked.

In other news, I saw some folks posting in the Yahoo LPC2000 group that they can overclock their LPC2103 to 110MHz! I haven't tried it, and I'm not even convinced that I'd want to at this point, but it's cool none the less. If we overclocked the LPC2103 to 100MHz, we could clock the SPI port to 100MHz/4 = 25MHz, which would provide the fastest rate you can clock an SD Card. Might come in handy some day, down the road.

traxmod-0.4.7-efsl-0.2.7.zip - Something weird is going on in the mixer code. The compiler must be doing something with signed/unsigned conversions because the postprocessing routine to convert signed audio data to unsigned data is commented out, yet the audio is sounding okay. I'll deal with that later when converting the mixer to assembly language.

This one plays in stereo and has quite a few of the effects implemented. Next weekend maybe I'll start tackling playing samples directly off the SD Card instead of RAM.

traxmod-0.4.6-efsl-0.2.7.zip - Started implementing a few simple effects commands.

Added "traxmod-0.4.5-efsl-0.2.7.zip" last night. Some minor code cleanups and improvements, nothing too exciting.

Added "traxmod-0.4.4-efsl-0.2.7.zip" to the TRAXMOD/ARM Developer's Area. This one plays raw audio files at 44.1KHz, 10-bits, stereo. It also has some extremely rudimentary MOD playback code. Currently does not try to stream sample data off of the SD Card, so you can only play extremely small MOD files where the sample data is small enough to fit into CPU RAM. No effects implemented yet.

Not too much to report yet. Spent the weekend writing a space efficient malloc/free implementation for embedded memory management. This will let me use the same memory space over again for the different parts of the application. I've still got some waste memory usage going on in the Embedded Filesystem Library that could probably be optimized.

Surprisingly, it looked like the default malloc routine included with newlib wasted like a full 1KB of RAM just for it's own internal tables! My implementation only uses 2 bytes of RAM for each chunk of memory allocated.

Made some sound quality improvements. Now playing in stereo. Also made the firmware scan the root directory for all files ending in *.RAW and plays each file on the disk instead of only playing AUDIO.RAW like before.

Also posted schematics.

Added "efsl-0.2.7-traxmod-0.4.zip" to the "traxmod-arm" folder in the Developer's Area. This includes our first raw audio player firmware for the LPC2103 ARM chip! It currently plays an 8 bit, unsigned, 22KHz, mono raw audio data file (AUDIO.RAW) straight off of a FAT formatted SD Card!

Added "timertest.zip" to the "traxmod-arm" folder in the Developer's Area. This firmware sets up the P0.8 and P0.9 pins as 10-bit PWM outputs, and then blinks LEDs using the PWM in an interrupt handler controlled by timer 3.

Now, I just need to tie the SD Card code into it and we should be able to play some raw audio data.

This last weekend we successfully got the Embedded Filesystems Library example up and running on the BBMICRO wired up to a 32MB SD Card! I have zipped up a snapshot of the modified code and put it in the Developer's Area under the "traxmod-arm" folder. It reads the root directory of the SD Card's FAT filesystem and prints out of the text of a log file stored on the SD Card. No audio code written yet, that will have to come next. I also haven't drawn up a schematic diagram yet, but it should be fairly obvious how to wire it up.

Also submitted an order for some more LPC2103 chips and the inductors we need to start experimenting with battery charger circuits.

Installed WinARM on my laptop and managed to compile the Embedded Filesystems Library LPC2000 example for my BBMICRO. The LPC2000 port was initially written for an LPC2138, but it looks like most of the register addresses are the same for LPC2103, so it might work without much modification. I did have to change the lpc_config.h file to match my development board's 10MHz oscillator and use a 7x PLL multiplier. I also modified main.c to use uart0 instead of uart1 so that I don't have to wire up another serial port. After all that, I flashed the chip and it wrote some text to the serial port! Tomorrow I'll have to try wiring up the SD Card socket on the bread board and see if we can get it to actually read data off a FAT formatted card as advertised.

This is kind of interesting: CrapTracker II. Basically, it's a Java Applet that runs in your web browser and lets you make a single pattern chiptune. And it actually works!

Been spending a lot of time working on the BBMICRO Protoboard lately. This board will allow us to start work on the ARM port of the TRAXMOD firmware using a bread board. We submitted the BBMICRO PCB design for manufacture last week, and this weekend I ordered all of the parts I need to build one, once everything arrives (hoping it will arrive before next weekend).

I also ordered 4 each of every AAA battery clip that might be useful. Using these parts, hopefully I can design a good way to mount all the batteries inside the final TRAXMOD device. We also ordered a couple parts for prototyping the battery charging circuit, but there's still an inductor I need to get from Digi-Key. I'm holding off on ordering from Digi-Key until we can get the first BBMICRO board up and running.

Check this out: sCrAmBlEd?HaCkZ! Specifically, watch the video, as it makes a lot more sense than trying to read about it.

I've been thinking about how to create a portable MOD tracker for composing music away from the computer. With the sCrAmBlEd?HaCkZ! example, the answer seems obvious. Instead of relying on a big computer screen and keyboard like a traditional tracker, you simply include a few select buttons, a minimal screen (if any) and a microphone. When you want to compose music, you simply hum your notes into the microphone and the device runs some fourier analysis against the humming (the way Scrambled?Hackz! does) to determine what notes you want played at what time. The device records the note information to your current track. When you play it back, instead of hearing your humming, it uses pre-recorded instrument samples instead, and bases the notes off the ditty you hummed.

Think of it as a "digital trumpet," if you will. A trumpet has a mouthpiece that you make note noises into, and three keys for further control. A trumpet can only sound like a trumpet though, and it does not have the ability to record what notes you played for later. A TRAXMOD device with the proposed "voice tracker" software described above would let you compose music on the fly, and be able to share your music with other people beyond the live performance.

The microphone would be useful for recording instrument samples out in the field too.

Older news...