This is the final item on the Goldilocks Analogue as a design and production exercise.
Thank you for pledging on the Kickstarter Project page. Closed on November 19th 2015, with 124% funding. Now that the Kickstarter Pledges have been shipped, the Goldilocks Analogue is available on Tindie.
I’ve been updating this post with the pre-production and production experience over the past few months.
Also additional optional libraries to provide support for each of the advanced features of the Goldilocks Analogue are available in the Arduino IDE Library Manager.
DAC Library (including IIR Filtering), using Timer 3.
Arduino IDE compatibility testing revealed only a few remaining issues related to support of the ATmega1284p used in the Goldilocks Analogue. Two issues have been raised and resolved as 2 pull requests on the main Arduino IDE development path.
In the SD Card Library, the hardware SPI interface was linked to a limited set pin assignments contained within the library, rather than referring to the relevant pins_arduino.h or the variant.h file suiting the board selection. So the SPI pins defined in the Sd2Card.h header file are assigned from pins_arduino.h rather than those arrived at in the SD2PinMap.h method for Software SPI.
Both these issues have been committed into the Arduino main git tree, and they have landed in Arduino IDE Release 1.6.8.
The only remaining known issue is the limitation in the configuration of the Tones() code to use only Timer 2. We would like to use Timer 2 for the RTC. There is no other option but to use this Timer for the RTC support, so it would be good if Tones() could be configured to use a different timer.
Testing
Rather than going back over old ground, I’ll just be testing the pre-production version against the Version Prototype 4, to ensure that the things that should have improved, are improved, and that nothing has become broken.
Power Supplies
In the image below, Channel 1 (yellow) is 4.47mV of noise present at the output capacitor for the power supply, and Channel 2 (blue) is the 3.47mV supply noise present on a test Vcc pin closest to the MCU.
The significant improvement in noise level for the pre-production version at the MCU is similar to that achieved for the Prototype 4 (even slightly better), and this is probably due to reduced capacitive coupling into the ground plane by removing the ground copper from directly under the main supply inductor.
GA PP: 5V Power Supply Noise
Remembering, for context, that 4mV is still the same order of the least significant bit for a 5V 10 bit ADC sampler, as found in the ATmega1284p, and a one bit change in the LSB of the MCP4822 input generates a 1mV change in output.
Checking the other power supplies on the board, Channel 1 (yellow) is the 3.3V positive supply, provided by a linear regulator. This supply is not used for analogue components, so the 4.0mV noise level is not critical, but never the less it is slightly less than on the Version P4.
Channel 2 (blue) below shows the -3V supply for the Operational Amplifier. This shows that the supply voltage noise of 5.9mV after filtering by a first order LC filter further smooth this supply. Compared to the Version P4 with no filtering (shown below) the noise is reduced substantially. The Version P4 shows a 10mV ramp, because it is a capacitive charge switching device. The addition of this LC filter was the one substantial change from the Prototype 4, so it is good to see the positive effect on the negative supply input to the Op Amp.
GA PP: 3.3V and -3V Power Supply Noise
GA P4: 3.3V & -3V Power Supply Noise
Analogue Output
The standard test that I’ve been using throughout the development is to feed in a 43.1Hz Sine wave generated from a 1024 value 16 bit LUT. The sampling rate is 44.1kHz, which is generated by Timer 1 to get the closest match.
The spectra and oscilloscope charts below can be directly compared to the testing done with prototype Version P4 and earlier versions of the Goldilocks Analogue.
The below chart shows the sine wave generated at the output of the Op Amp. This is exactly as we would like to see, with no compression of either the 4.096V peak, or the 0V trough.
GA PP: 43Hz Sine Wave – Two Channels – One Channel Inverted
Looking at the spectra generated up to 953Hz it is possible to see harmonics from the Sine Wave, and other low frequency noise.
The spectrum produced by the Goldilocks Analogue shows most distortion is below -70dB, and that the noise floor lies below -100dB. The pre-production sample shows slightly higher noise carriers than the Version P4, but the difference is not substantial.
GA PP: 43.1Hz Sine Wave – 953Hz Spectrum
In the spectrum out to 7.6kHz we are looking at the clearly audible range, which is the main use case for the device.
The Goldilocks Analogue has noise carriers out to around 4.5kHz, but they are all below -80dB. After 4.5kHz the only noise remains below -100dB.
GA PP: 43.1Hz Sine Wave – 7k6Hz Spectrum
The spectra out to 61kHz should show a noise carrier generated by the reconstruction frequency of 44.1kHz.
The Goldilocks Analogue shows the spectrum maintains is low noise level below -90dB right out to the end of the audible range, and further out to the reconstruction carrier at 44.1kHz.
GA PP: 43.1Hz Sine Wave – 61kHz Spectrum
The final spectrum shows the signal out to 976kHz. We’d normally expect to simply see the noise floor, beyond the 44.1kHz reconstruction carrier noise.
The Goldilocks Analogue has a noise carrier at around 210kHz, probably generated by the -3V supply. The noise carrier at 340kHz is generated through the 5V SMPS supply, and is absent when powered by USB socket. Aside from the two carriers mentioned, there is no further noise out to 976kHz.
GA PP: 43.1Hz Sine Wave – 976kHz Spectrum
The Pre-production analogue output works as specified, and is essentially identical to the analogue output on the Prototype 4. It can maintain the 72dB SNR required, of which it should theoretically be capable.
I’ve been working on the Goldilocks Analogue now for so long that its been the centerpiece of my coding evenings for the past 18 months. This is the first time that I’ve designed a piece of hardware, and I’ve managed to make many mistakes (or learnings) along the way, so I think that every step of the process has been worthwhile.
Goldilocks Analogue Prototype 4 – Rotating
In this project, I’ve learned about Digital to Analogue Converters, Operational Amplifiers, Voltage translation, Switching Power Supplies, and most importantly have gained a working knowledge of the Eagle PCB design tools.
Version History
The original Goldilocks Project was specifically about getting the ATmega1284p MCU onto a format equivalent to the Arduino Uno R3. The main goal was to get more SRAM and Flash memory into the same physical footprint used by traditional Arduino (pre-R3) and latest release Uno R3 shields.
The Goldilocks project achieved that goal, but the resulting ATmega platform still lacked one function that I believe is necessary; a high quality analogue capability. The world is analogue, but having an ADC capability, without having a corresponding digital-to-analogue capability, is like having a real world recorder (the ADC capability) with no means to playback and recover these real world recordings.
A major initiative of the Goldilocks is to bring an analogue capability to the Arduino platform via a DAC, so this project was called the Goldilocks Analogue. Following a Kickstarter campaign, the Goldilocks Analogue is now available on Tindie.
Version 1 implemented the MCP4822 DAC buffered with an expensive, very musical, Burr Brown Operational Amplifier. Although the DAC performed exactly as designed, I neglected to provide the Op Amp with a negative supply rail, so it could not approach 0V required to reproduce the full range of output available (0v to 4.096V) from the DAC. That was a mistake.
Version 1 also reverted the USB to Serial interface to use a proper FTDI FT232R device from the ATmega32u2 MCU (the solution preferred now by Arduino). Using the ATmega32u2 (or ATmega16u2) to interface with anything not running at its own 16MHz CPU clock rate is broken and doesn’t work. This is because the ATmega devices don’t produce correct serial when their CPU clock is not a clean multiple of the USART required rate. I learned this the hard way with the Goldilocks Project.
Finally Version 1 implemented a buffered microSD card interface, using devices suitable to convert from 5V to 3.3V (SCK, MOSI, CS), and 3.3V to 5V (MISO) for the SPI interface. This was a correct implementation, but later I removed it because sometimes I’m really too smart for my own good.
Goldilocks Analogue – Version P1
Some significant rework of the analogue section was required for Version 2. Firstly, I decided that audio was a significant use case for the Goldilocks Analogue so it was worth while reducing the cost of the Op Amp, and sharing that expenditure with a special purpose headphone amplifier, working in parallel with the Op Amp.
The TPA6132A2 headphone amplifier was found, and implemented into the prototype. This “DirectPath” device removes the need for large output capacitors in the signal path, as it provides a zero centred output from a single supply voltage.
Version 2 also had a lesser but fully adequate TS922A Op Amp for providing DC to full rate signals, buffering the MCP4822 DAC. I had learned that Op Amps need to be provided with a negative supply rail, if they are to achieve 0V output under load.
To create a negative supply rail for the Version 2 Op Amp, I used a pair of TPS60403 voltage inverters producing -5V from the main power supply, and then fed that signal into a TPS72301 regulator configured to produce -1.186V. This design worked very well, but needed 3 devices to produce the output and also quite a lot of board space.
Finally, for Version 2, I changed the microSD voltage translation to use the TXS0104 (TXB0104) level translation products. These special purpose devices enable the bidirectional transfer of signals over voltage transitions. Normally these two device types (TXB / TXS) work very well, but somehow I couldn’t ever get either version to work properly, which caused the microSD card to never work. This exercise was a failure, and was reverted to normal buffer logic for Version 3.
Goldilocks Analogue – Version P2
Version 3 was supposed to be my final prototype prior to putting this into a crowd funding project. I made some fairly simple changes, and I was pretty happy with the outcome of Version 2 as it was.
Version 3 changed the MCP4822 DAC interface to use the USART1 interface present on the ATmega1284p MCU. Using the USART1 in MSPI Mode allows the DAC to operate independently of the normal SPI bus. This frees up timing constraints on the SPI interface so that slow microSD cards can be read and streamed to the DAC, or SPI graphics interfaces can be used as in the case of the synthesiser demonstration.
As part of the testing, I found that the ATmega1284p would operate successfully at 24.576MHz. This is a magic frequency because it allows an 8 bit timer to reproduce all of the major audio sampling rates related to 48kHz. I’ve tested using this frequency and everything is working fine.
Obviously there was some feature creep over the course of experimentation, so I decided to add two SPI memory device layouts to the PCB. This would allow up to 23LC1024 256kByte of SRAM to be addressed, together with AT25M01 256kByte of EEPROM, for example. Putting these layouts on the board meant that the JTAG interface had to be moved to the back of the PCB. This was actually not a bad thing, as it would have been impossible to use the JTAG interface with a Shield in place anyway.
I was asked to beef up the 3.3V supply capability of the Goldilocks Analogue, so I added a AP1117 device capable of up to 1A supply, upgrading from 150mA.
Goldilocks Analogue – Version P3
Version 4 added the feature of amplified Microphone Input. Using the MAX9814 Mic Amp electret microphones present in the normal headsets used with smart-phones can act as an audio input to the Goldilocks Analogue. The amplified signal is presented on Pin A7, which falls outside of the normal Arduino Uno R3 footprint. For completeness, I also added a level shifted non-amplified signal (for line-in) to Pin A6.
Because of the extra microphone amplifier circuitry, I needed to reduce the footprint of the negative supply rail. So I used a regulated -3V device LTC1983 to produce the negative supply rail required for the Op Amp. There are now 3 regulators on the Goldilocks Analogue, 5V at up to 2.4A, 3.3V at up to 1A, and -3V at 100mA.
Version 4 also saw the last of the through hole components gone. Both the main crystal and the 32kHz clock crystal were reformatted into surface mount technology. This reduces the flexibility of the platform, but it makes manufacturing a bit easier.
Goldilocks Analogue – Version P4
Version 4 is the end. There will be some minor adjustments to the board for the production version. But, finally, I think this is it.
Unboxing
Prototype 4 back from manufacturing
Errata
There is no power supply jumper provided. Add this to the BOM.
The EEPROM is built with SOIC8 Wide Body, but it should be Narrow Body. Fix the BOM.
Labels for the recommended power supply Voltage are partially obscured by power jack. Move the labels.
The main crystal doesn’t oscillate, because the Eagle library had an incorrect footprint.
Tested to work by rotating the crystal on its existing footprint.
Respecify the main MCU crystal to the Atmel recommended type.
Change C2 and C3 to 15pF in line with Atmel recommendation.
Change C1 and C11 to 12pF in line with Atmel recommendation.
Change R18 to 100kOhm, to bias the Analogue Line in correctly.
Add a simple LC filter to the -3.3V supply, using the known inductor and 10uF capacitor.
Tie Mic Gain to AVcc with a separable link, to produce 40dB default gain. This is the setting required for most normal microphones, so will improve the “out of box” experience for most users.
Testing
Version P4 – Front
Version P4 – Back
Power Supplies
First, looking at power supply noise, we’ve got a slightly better result for noise at the power supply over the Prototype 1. Prototype 1 used the EUP3476 Switched Mode supply device. Problems with obtaining ready supply of this device led to changing it to the AP6503, which is pin compatible but needs slightly different voltage selection resistors. In contrast to the Arduino Uno and other devices, this is very good.
We remember that 1mV represents the Voltage change in the least significant bit of the 12 bit MCP4822. The least significant bit of the ATmega1283p 10 bit ADC is about 4mV. Sampling voltages similar to the noise level inherent on the platform will not generate any further accuracy.
GA P4: 5V Power Supply Noise
Channel 1 (yellow) is 4.0mV of noise present at the output capacitor for the power supply, and represents the lowest noise inherent in the supply. Channel 2 (blue) is the 5.6mV supply noise present on a test pin closest to the MCU.
The significant improvement in noise level for the GA4 version at the MCU may be due to the currently decreased system clock rate, and therefore is subject to confirmation.
GA P1: 5V Power Supply Noise
Checking the other power supplies on the board, Channel 1 (yellow) is the 3.3V positive supply, provided by a linear regulator. This supply is not used for analogue components, so the 4.3mV noise level is not critical.
Channel 2 (blue) below shows the -3V supply for the Operational Amplifier. This shows a 10mV supply voltage ramp, generated because it is a capacitive charge switching device. This is not particularly good, and it will be worth adding an LC filter to attempt to further smooth this supply, for the production Goldilocks Analogue.
GA P4: 3.3V & -3V Power Supply Noise
Microphone Input
Microphone amplifier works.
Interestingly, when the amplifier is set to 60dB gain (default setting, Channel 2, blue) it oscillates at 144kHz when not connected to anything, while it doesn’t do this with the normal gain setting of 40dB (Channel 1, yellow) based on the amplification required for typical smartphone headphones. In either case, as soon as the Mic input is grounded, the Mic output reduces to less than 4mVAC on the correct bias of 1.25VDC.
Suggest to make 40dB amplification the default setting for the production Goldilocks Analogue, but allowing the connection to be segmented for increased amplification if required.
GA4 – Mic Oscillation Comparison at 40dB (CH1) and 60dB (CH2) amplification.
Line-In (PA6) seems to be biased at 1.07V rather than 1.25V. Check calculation again… Doh! R18 should be 100kOhm.
Analogue Output
The standard test that I’ve been using throughout the development is to feed in a 43.1Hz Sine wave generated from a 1024 value 16 bit LUT. The sampling rate is 44.1kHz, which is generated by Timer 1 to get the closest match.
The spectra and oscilloscope charts below can be directly compared to the testing done with previous prototype versions of the Goldilocks Analogue.
The below chart shows the sine wave generated at the output of the Op Amp. This is exactly as we would like to see, with no compression of either the 4.096V peak, or the 0V trough.
Goldilocks Analogue P4 – 43Hz Sine Wave – Two Channels – One Channel Inverted
Looking at the spectra generated up to 953Hz it is possible to see harmonics from the Sine Wave, and other low frequency noise.
The spectrum produced by the Goldilocks Analogue shows most distortion is below -70dB, and that the noise floor lies below -100dB.
Goldilocks Analogue P4 – 43.1Hz Sine Wave – 953Hz Spectrum
Comparing the same DAC output channel A from Op Amp (Channel 1 – Blue) with the same Headphone Amp Left (Channel 2 – Red), we see slightly more noise carriers.
Goldilocks Analogue P4 – 43.1Hz Sine Wave – 953Hz Spectrum – Headphone in Red
In the spectrum out to 7.6kHz we are looking at the clearly audible range, which is the main use case for the device.
The Goldilocks Analogue has noise carriers out to around 4.5kHz, but they are all below -80dB. After 4.5kHz the only noise remains below -100dB.
Goldilocks Analogue P4 – 43.1Hz Sine Wave – 7.6kHz Spectrum
The spectra out to 61kHz should show a noise carrier generated by the reconstruction frequency of 44.1kHz.
The Goldilocks Analogue shows the spectrum maintains is low noise level below -90dB right out to the end of the audible range, and further out to the reconstruction carrier at 44.1kHz.
Goldilocks Analogue P4 – 43.1Hz Sine Wave – 61kHz Spectrum
The final spectrum shows the signal out to 976kHz. We’d normally expect to simply see the noise floor, beyond the 44.1kHz reconstruction carrier noise.
The Goldilocks Analogue has a noise carrier at around 210kHz. Aside from the single carrier mentioned, there is no further noise out to 976kHz.
Goldilocks Analogue P4 – 43.1Hz Sine Wave – 976kHz Spectrum
Analogue output works as specified. It can maintain the 72dB SNR required, of which it should theoretically be capable.
SPI Devices
MicroSD works.
SPI SRAM / EEPROM devices work.
Tests for REWORK
These tests are for the factory rework of the prototype boards.
Check 5V Power Supply
Plug 7-23VDC positive centre into J1.
CHECK: that there is 5VDC available on H15 DC Pin.
Check 3.3V and -3V Power Supply
Add a jumper to J1 from the centre pin to DC Pin.
CHECK: that 5VDC, 3.3VDC, and -3VDC is available at the test points indicated.
Check for Internal RC Oscillator Function
Connect an AVRISP Mk2 in circuit programmer to the ICSP Socket.
Use the following command to enable the CLKO on PB1, and set other fuses correctly.
Connect the Goldilocks Analogue to a USB port and open a serial terminal at 38400 baud to the attached FTDI USB /dev/ttyUSB0 interface.
CHECK: Enter !!! into the serial terminal, immediately following a board RESET (using the RESET button). This will enable the Boot Monitor. These are the boot monitor commands.
Bootloader>
Bootloader>H Help
0=Zero addr (for all commands)
?=CPU stats
@=EEPROM test
B=Blink LED
E=Dump EEPROM
F=Dump FLASH
H=Help
L=List I/O Ports
Q=Quit
R=Dump RAM
V=show interrupt Vectors
Y=Port blink
Bootloader>
Bootloader>? CPU stats
Goldilocks explorer stk500v2
Compiled on = Oct 7 2015
CPU Type = ATmega1284P
__AVR_ARCH__= 51
GCC Version = 4.8.2
AVR LibC Ver= 1.8.0
CPU ID = 1E9705
Low fuse = D7
High fuse = D8
Ext fuse = FC
Lock fuse = FF
Close the serial terminal program (disconnect from the /dev/ttyUSB0 device).
Load Test Program
With the USB interface connected to the Goldilocks Analogue, and the DTR switch in the right most position (closest to DTR text; opposite position to the pictured position).
Use the following command to program a Test Suite using the provided HEX file.
Plug a standard smartphone headset (with microphone) with a 3.5mm TRRS connector in LRGM (left, right, ground, mic) configuration into the socket.
CHECK: Sound (echo of input) should be heard from the headphones, when speaking into the microphone.
Connect the Goldilocks Analogue to a USB port and open a serial terminal at 38400 baud to the attached FTDI USB /dev/ttyUSB0 interface.
CHECK: Information on each Task’s stack “Highwater” mark should be seen on the serial terminal.
Just over 6 months since the third iteration of the Goldilocks Analogue Prototyping was started, and now I’ve finished the design for a forth iteration. The Goldilocks Analogue Prototype 4 design is now finished, and I’m working out what the final bill of materials will cost to assemble into a final outcome. Testing for the Prototype 4 has begun, and everything is working as expected.
The third prototype was completely successful, and produced the improvements I was looking for. The use of the MSPI Mode on USART1 means that two SPI interfaces can be run in parallel, allowing the DAC to hold its tight timing requirements while slower SD card transactions take place (for example). This was proven through the implementation of a direct digital synthesiser, controlled by a SPI controlled touch screen.
Goldilocks Analogue – Prototype 3
Revision for Prototype 4
The Prototype 3 was supposed to be the final version, and it achieved everything that I set out in the original design specifications. But, then there was some feature creep.
Prototype 4 back from manufacturing
In discussing the TRS 3.5mm audio socket, a better more robust TRRS version was found. The realisation that it would be possible to have a microphone input, without requiring additional board space, led me to experiment with the Adafruit breakout board for the MAX9814 Microphone amplifier, and then to build a very simple Walkie-Talkie demonstration to test the use of audio input (with the integrated ADC), simultaneously with audio output (via the DAC).
Once the use of the MAX9814 was proven, I could implement a reference circuit as an input option. The amplified microphone input is connected to Pin 7 of the Analogue Port A. Conveniently, the MAX9814 delivers the amplified signal at +1.25V with a 2V peak to peak signal. This allows the sample to fall into the range of 0V to 2.56V internal reference voltage for the ATmega ADC, providing the maximum sampling resolution with no further adjustments.
The MAX9814 also includes an integrated microphone biasing circuitry, which is designed to support normal electret microphones.
As an alternative input functionality, the Prototype 4 also allows for LINE level inputs. I have used a voltage divider to reference the input signal to 1.25V DC. Although a 2V peak to peak Line level input will overload the Microphone amplifier, rendering the output signal on PA7 unusable, the LINE input is routed to Pin 6 on Port A will have exactly the right range to sample using the internal ATmega ADC voltage reference.
Both Port A Pin 6 and Pin 7 are outside of the normal Arduino UNO R3 footprint, so the normal functionality of the UNO footprint is not affected by either the two input options. And if desired, the connection can be separated at a solder-jumper on the rear of the board.
The additional space required for the microphone and line level input circuitry has been created by simplifying the negative supply rail for the Op-Amp. The Op-Amp is provided to support DC to 50k sample per second analogue output. To achieve a linear output from 0v to 4.096V the Op-Amp requires a negative supply voltage. In this revision, I have used a single LTC1983 regulated supply device to provide the negative -3V supply rail. The outcome should be equivalent to the Prototype 3 solution, which used 3 devices.
Board Layout
The final board layout has been completed, and the board is now in discussion for manufacturing.
This is the front of the board showing all of the layers, and the general layout of the devices. The board layout is pretty busy, but still there is sufficient prototyping capability to take all the port pins off-board, or provide on-board breakouts.
Top Layer
This is the Top Layer, which contains all of the devices. There are no devices on the Bottom Layer.
Route 2 (GND) Layer
The Ground Layer on Route 2 is unchanged from previous iterations, and provides a solid platform for low noise analogue circuits.
Route 15 (Vcc) Layer
The Route 15 power supply layer contains all of the supply lines, providing 5V regulated, 5V filtered for analogue AVcc, 3.3V regulated, and -3V regulated.
Bottom Layer
All the pin outs are defined on the Bottom Layer. In addition to the items previously mentioned, there are two small locations where the Line and Microphone inputs can be cut, and allow the full functionality of PA6 and PA7 to be recovered.
Pin Mapping
This the map of the ATmega1284p pins to the Arduino physical platform, and their usage on the Goldilocks Analogue
I’m building an advanced Arduino clone based on the AVR ATmega1284p MCU with some special features including a 12 bit DAC MCP4822, headphone amplifier, 2x SPI Memory (SRAM, EEPROM), and a SD Card. There are many real world applications for analogue outputs, but because the Arduino platform doesn’t have integrated DAC capability there are very few published applications for analogue signals. A Walkie Talkie is one example of using digital and analogue together to make a simple but very useful project.
Two Goldilocks Analogue prototypes with XBee radios, and Microphone amplifiers.
The actual Walkie Talkie functionality is really only a few lines of code, but it is built on a foundation of analogue input (sampling), analogue output on the SPI bus to the MCP4822 DAC, sample timing routines, and the XBee digital radio platform. Let’s start from the top and then dig down through the layers.
XBee Radio
I am using XBee Pro S2B radios, configured to communicate point to point. For the XBee Pro there needs to be one radio configured as the Coordinator, and the other as a Router. There are configuration guides on the Internet.
I have configured the radios to wait the maximum inter-character time before sending a packet, which implies that the packets will be set only when full (84 bytes). This maximises the radio throughput. Raw throughput is 250 kbit/s, but the actual user data rate is limited to about 32 kbit/s. This has an impact on the sampling rate and therefore quality of speech that can be transmitted.
Using 10 bit samples companded using A-Law to 8 bit code words, I have found that about 3 kHz sampling generates about as much data as can be transmitted without compression. I’m leaving G.726 compression for another project.
The XBee radios are configured in AT mode, which acts as a transparent serial pipe between the two endpoints. This is the simplest way to connect two devices via digital radio. And it allowed me to do simple testing, using wire, before worrying about whether the radio platform was working or not.
XBee Packet Reception in Purple
Looking at the tracing of a logic analyser, we can see the XBee data packets arriving on the (purple) Rx line of the serial port. The received packet data is stored into a ring buffer, and played out at a constant rate. I have allowed up to 255 bytes in the receive ring buffer, and this will be sufficient because the XBee packet size is 84 bytes.
The samples to be transmitted to the other device are transmitted on the (blue) Tx line, more or less in each sample period even though they are buffered before transmission. The XBee radio buffers these bytes for up to 0xFF inter-symbol periods (configuration), and only transmits a packet to the other endpoint when it has a full packet.
Sampling Rate
Looking at the bit budget for the transmission link, we need to calculate how much data can be transmitted without overloading the XBee radio platform, and causing sample loss. As we are not overtly compressing the voice samples, we have 8 bit samples times 3,000 Hz sampling or 24 kbit/s to transmit. This seems to work pretty well. I have tried 4 kHz sampling, but this is too close to the theoretical maximum, and doesn’t work too effectively.
Sample rate of 3,000 Hz seems to be the optimum.
Looking at the logic analyser, we can see the arrival of a packet of bytes commencing with 0x7E and 0x7C on the Rx line. Both the Microphone amplifier and the DAC output are biased around 0x7F(FF), so we can read that the signal levels captured and transmitted here are very low. The sample rate shown is 3,000 Hz.
Sample Processing
I have put a “ping” on one output to capture when the sampling interrupt is being processed (yellow). We can see that the amount of time spent in the interrupt processing is very small for this application, relative to the total time available. Possibly some kind of data compression could be implemented.
DAC and sample processing
During the sampling interrupt, there are two major activities, generating an audio output, by placing a sample onto the DAC, and then reading the ADC to capture an audio sample and transmit it to the USART buffer.
This is done by the audioCodec_dsp function, which is called from the code in a timer interrupt.
void audioCodec_dsp( uint16_t * ch_A, uint16_t * ch_B)
{
int16_t xn;
uint8_t cn;
/*----- Audio Rx -----*/
/* Get the next character from the ring buffer. */
if( ringBuffer_IsEmpty( (ringBuffer_t*) &(xSerialPort.xRxedChars) ) )
{
cn = 0x80 ^ 0x55; // put A-Law nulled signal on the output.
}
else if (ringBuffer_GetCount( &(xSerialPort.xRxedChars) ) > (portSERIAL_BUFFER_RX>>1) ) // if the buffer is more than half full.
{
cn = ringBuffer_Pop( (ringBuffer_t*) &(xSerialPort.xRxedChars) ); // pop two samples to catch up, discard first one.
cn = ringBuffer_Pop( (ringBuffer_t*) &(xSerialPort.xRxedChars) );
}
else
{
cn = ringBuffer_Pop( (ringBuffer_t*) &(xSerialPort.xRxedChars) ); // pop a sample
}
alaw_expand1(&cn, &xn); // expand the A-Law compression
*ch_A = *ch_B = (uint16_t)(xn + 0x7fff); // move the signal to positive values, put signal out on A & B channel.
/*----- Audio Tx -----*/
AudioCodec_ADC( &mod7_value.u16 ); // sample is 10bits left justified.
xn = mod7_value.u16 - 0x7fe0; // center the sample to 0 by subtracting 1/2 10bit range.
IIRFilter( &tx_filter, &xn); // filter transmitted sample train
alaw_compress1(&xn, &cn); // compress using A-Law
xSerialPutChar( &xSerialPort, cn); // transmit the sample
}
I am using the AVR 8 bit Timer0 to generate the regular sample intervals, by triggering an interrupt. By using a MCU FCPU frequency which is a binary multiple of the standard audio frequencies, we can generate accurate reproduction sampling rates by using only the 8 bit timer with a clock prescaler of 64. To generate odd audio frequencies, like 44,100 Hz, the 16 bit Timer1 can be used to get sufficient accuracy without requiring a clock prescaler.
The ATmega1284p ADC is set to free-run mode, and is scaled down to 192 kHz. While this is close to the maximum acquisition speed documented for the ATmega ADC, it is still within the specification for 8 bit samples.
ISR(TIMER0_COMPA_vect) __attribute__ ((hot, flatten));
ISR(TIMER0_COMPA_vect)
{
#if defined(DEBUG_PING)
// start mark - check for start of interrupt - for debugging only (yellow trace)
PORTD |= _BV(PORTD7); // Ping IO line.
#endif
// MCP4822 data transfer routine
// move data to the MCP4822 - done first for regularity (reduced jitter).
DAC_out (ch_A_ptr, ch_B_ptr);
// audio processing routine - do whatever processing on input is required - prepare output for next sample.
// Fire the global audio handler which is a call-back function, if set.
if (audioHandler!=NULL)
audioHandler(ch_A_ptr, ch_B_ptr);
#if defined(DEBUG_PING)
// end mark - check for end of interrupt - for debugging only (yellow trace)
PORTD &= ~_BV(PORTD7);
#endif
}
This interrupt takes 14 us to complete, and is very short relative to the 333 us we have for each sample period. This gives us plenty of time to do other processing, such as running a user interface or further audio processing.
SPI Transaction
At the final level of detail, we can see the actual SPI transaction to output the incoming sample to the MCP4822 DAC.
SPI MCP4822 DAC Transaction
As I have built this application on the Goldilocks Analogue Prototype 2 which uses the standard SPI bus, the transaction is normal. My later prototypes are using the Master SPI Mode on USART 1 of the ATmega1284p, which slightly accelerates the SPI transaction through double buffering, and frees the normal SPI bus for simultaneous reading or writing to the SD Card or SPI Memory, for audio streaming. In the Walkie Talkie application there is no need to capture the audio, so there’s no down side to using the older prototypes and the normal SPI bus.
void DAC_out(const uint16_t * ch_A, const uint16_t * ch_B)
{
DAC_command_t write;
if (ch_A != NULL)
{
write.value.u16 = (*ch_A) >> 4;
write.value.u8[1] |= CH_A_OUT;
}
else // ch_A is NULL so we turn off the DAC
{
write.value.u8[1] = CH_A_OFF;
}
SPI_PORT_SS_DAC &= ~SPI_BIT_SS_DAC; // Pull SS low to select the Goldilocks Analogue DAC.
SPDR = write.value.u8[1]; // Begin transmission ch_A.
while ( !(SPSR & _BV(SPIF)) );
SPDR = write.value.u8[0]; // Continue transmission ch_A.
if (ch_B != NULL) // start processing ch_B while we're doing the ch_A transmission
{
write.value.u16 = (*ch_B) >> 4;
write.value.u8[1] |= CH_B_OUT;
}
else // ch_B is NULL so we turn off the DAC
{
write.value.u8[1] = CH_B_OFF;
}
while ( !(SPSR & _BV(SPIF)) ); // check we've finished ch_A.
SPI_PORT_SS_DAC |= SPI_BIT_SS_DAC; // Pull SS high to deselect the Goldilocks Analogue DAC, and latch value into DAC.
SPI_PORT_SS_DAC &= ~SPI_BIT_SS_DAC; // Pull SS low to select the Goldilocks Analogue DAC.
SPDR = write.value.u8[1]; // Begin transmission ch_B.
while ( !(SPSR & _BV(SPIF)) );
SPDR = write.value.u8[0]; // Continue transmission ch_B.
while ( !(SPSR & _BV(SPIF)) ); // check we've finished ch_B.
SPI_PORT_SS_DAC |= SPI_BIT_SS_DAC; // Pull SS high to deselect the Goldilocks Analogue DAC, and latch value into DAC.
}
Wrap Up
Using a few pre-existing tools and a few lines of code, it is possible to quickly build a digitally encrypted walkie talkie, capable of communicating (understandable, but certainly not high quality) voice. And, there ain’t no CB truckers going to be listening in on the family conversations going forward.
This was a test of adding microphone input based on the MAX9814 to the Goldilocks Analogue. I will be revising the Prototype 3 and will add in a microphone amplification circuit to support applications needing audio input, like this walkie talkie example, or voice changers, or vocal control music synthesizers.
I’m also running the ATmega1284p devices at the increased frequency of 24.576 MHz, over the standard rate of 20 MHz. This specific frequency allows very precise reproduction of audio samples from 48 kHz down right down to 4 kHz (or even down to 1,500 Hz). The extra MCU clock cycles per sample period are very welcome when it comes to generating synthesised music, or encoding audio samples.
Code as usual on Github AVRfreeRTOS repository. Also, a call out to Shuyang at SeeedStudio who’s OPL is awesome, and is the source of many components and PCBs.
Following my initial design article, and the testing article, I’ve put quite a lot of thought into how I can make this Goldilocks Analogue device best achieve my stated goals. Pictured is the only Goldilocks Analogue Prototype in existence.
Goldilocks Analogue Prototype – Analogue section front of image.
From the testing it was clear that the MCP4822 DAC fully achieved the goals that I had set out to achieve, but that my design for the analogue buffer stage behind it was really quite bad. Fixing it was going to take some thought.
I have decided to separate the analogue output stage into two sections. An AC section which drives the headphone socket, with a designed for purpose headphone amplifier device, and a DC section using a high current rail to rail OpAmp and a negative 1.18V supply rail to allow the OpAmp to fully reach GND or the equivalent 0x000 digital input.
I also found a better solution for the uSD level translation. There is a device designed for purpose, which I’ve now designed into the Goldilocks Analogue.
DAC – MCP4822
The selected dual DAC uses the SPI bus to write 12 bit values to each of its channels. The increments are either 1mV or 0.5mV giving full scale at DC 4.096V or 2.048V depending which scale factor is being used. The testing showed that the DAC is capable of achieving close to the 72dB of SNR that is its theoretical capability.
So from my point of view the DAC, and the AVcc filtering system employed to provide a clean analogue power rail, have achieved their design goal. Let’s not change anything.
Headphone (AC) Output – TPA6132A2
Driving a headphone socket with a nominal impedance of 32 ohm is a hard job for an OpAmp, and they are not designed specifically for this job. Therefore, I thought it would be best to separate the two outputs into two separate full-time output devices, specialised for their purposes (AC headphones, and DC PID or general pin-out). Both Goldilocks Analogue output options are driven simultaneously, and they will not interfere with each other.
For the AC and headphone output, using a specific single ended “DirectPath” headphone amplifier device enabled me to remove the large output coupling capacitors but still achieve a good low frequency output response.
The TPA6132A2 is capable of driving 25 mW into 16 ohm headphones. Its amplifier architecture operates from a single supply voltage and uses an internal charge pump to generate a negative supply rail for the headphone amplifier. The output voltages are centred around 0 V and are capable of positive and negative voltage swings. This means that the TPA6132A2 doesn’t need output blocking capacitors, and therefore can achieve a very good low-frequency fidelity. Using the 1 uF input capacitors stops any turn-on pop or noise, and achieves a low frequency corner below 10 Hz.
As the DAC outputs a signal with up to 4 V peak to peak, I have set the gain on the TPA6132A2 to -6dB. This should result in the full range of the headphone signal being 1 V peak to peak, with approximately 25 mW being delivered into 32 ohm headphones.
The TPA6132 also has a very high power supply an RF noise rejection ratio. Although I’ve gone to a lot of effort to filter the AVcc power supply, the power supply noise generated was still significant. Having over 90 dB PSRR will help to keep the output quiet.
Analogue (DC) Output – TS922A
I originally selected a highly regarded audiophile OpAmp for use in the Goldilocks Analogue. That device was incapable of operating close to its GND rail, and caused significant distortion in the output signal. Based on that experience, I decided to use a rail-to-rail output OpAmp to provide the DC buffered signal.
Even though rail-to-rail OpAmp devices are sold as full Vcc to Vss outputs, under high current loading they all have significant output droop. The only way to avoid this is to avoid driving the (any) OpAmp close to its supply rails.
The positive rail is ok. The supply voltage is a well regulated 5 V DC, and the maximum voltage required from the OpAmp is 4.096 V which is 0xFFF input to the DAC. It is the Ground Rail, which causes the issue, as the OpAmp will be unable to deliver the analogue equivalent 0x000 under high current situations.
The only way to get an OpAmp to deliver a solid GND potential output, is to supply it with a negative supply voltage Vss. Getting a Vss rail is described below.
The TS922A device is designed for high current rail-to-rail outputs, and is specified to work into 32 ohm headphones, 75 ohm video, and 600 ohm inputs. This DC coupled output can be used to drive PID, Triac or any other application requiring a precise analogue signal up to around 50 kHz.
OpAmp Vss (negative) rail
The TS922A can support over 50 mA per channel output, but at this current its output resistance has dropped its ability to reach both rails to greater than 300 mV. Specifically, it can only reach between 0.3 V and 4.4 V. Therefore to enable the output signal to reach GND potential, we have to generate a Vss with greater than -0.3 V, and capable of supplying in excess of 100 mA (over OpAmp both channels).
I looked at a number of options for charge coupled devices, and decided that the cheapest and best way was to use two paralleled TPS60403 devices to each generate -5 V 60 mA from the 5V power rail. These devices don’t filter their output, but since we are not going to use the -5 V directly, this doesn’t matter.
Following the generation of the -5 V supply, I’ve decided on a TPS72301 variable voltage 200 mA linear regulator, configured to generate its reference voltage -1.186 V, to provide a regulated Vss. Using the internal reference voltage saves a few resistors, and it still generates sufficient negative voltage to enable the OpAmp to easily reach true GND potential.
uSD Card Level Translation – TXS0104
Some further analysis of the voltage translation application revealed that the TXS0104 is designed to exactly suit the purpose of interfacing SPI bus at up to 24 MHz. As a side benefit it is a much smaller package, which recovers prototyping space back to the original Goldilocks benchmark. It is also cheaper than the general purpose OpAmps previously used.
Initially, the prototype used the TXB0104 device, but it was unsuccessful. The 4kOhm output resistance combined with less than optimal uSD card characteristics meant that the design failed. The TXB series cannot drive anything with pull-up or pull-down greater than 50kOhm. The uSD card is specified to have 10kOhm to 100kOhm integrated pull-up resistors, but in practice they all seem to be around 10kOhm. The schematic below will be updated to show TXS shortly.
The PCB Layout
The board layout has been completed, and a PCB ordered to this design.
More detail soon.
Top Signal Layer
GND Signal Layer
5V Signal Layer
Bottom Signal Layer
As of June 2014, I’ve now got all the parts, and the PCB ready for a new prototype. This new version was constructed late July 2014 and is awaiting basic testing.
Version 2 of the prototype, fresh out of the oven.
As of August 2014, I have started testing. So far the analogue design seems to check out, with both the headphone (AC biased) circuitry and the OpAmp (DC biased) circuitry performing as intended. More testing soon, and a new post.
Goldilocks Analogue demonstrating a clean DC biased sign wave (to 0V) .
The spectrum at the output of the TS922A OpAmp is cleaner now than directly at the MCP4822 DAC output of the previous prototype iteration.
The nominal 12 bit DAC capabilities are able to achieve 72dB SNR. Target achieved.
Last time I designed a Goldilocks board, it was because I was unhappy about the availability of a development platform that was within my reach; a tool to enable me to continue to learn about coding for micro-controllers.
This Goldilocks, let us call it Goldilocks Analogue, it is not about what I think is necessary, but more about what I’d like to have. The focus is not so much about the basics of SRAM and Flash, but much more on what functions I would like to have, and using my own means to get there.
Also, as the original Goldilocks is sold out, Freetronics are considering making their own version. Please add your wishes here.
Test results are in. Check out the detailed post on Goldilocks Analogue – Testing. Following the testing, I’ve redesigned the analogue output section to make it much more capable. It now support simultaneous AC and DC outputs, with an application specific headphone amplifier device to provide AC output, and high current OpAmp to provide DC output.
The Goldilocks Project was specifically about getting the ATmega1284p MCU onto a format equivalent to the Arduino Uno R3. The main goal was to get more SRAM and Flash memory into the same physical footprint used by traditional Arduino (pre-R3) and latest release Uno R3 shields.
Original – Goldilocks Version 1.1
I also tried to optimally use the co-processor ATmega32U2, (mis)utilised by Arduino purely for the USB-Serial functionality, by breaking out its pins, and creating a cross-connect between the two MCU to enable them to communicate via the SPI bus.
Whilst the Goldilocks achieved what it set out to do, there were some problems it created for itself.
Firstly, the ATmega family of devices is really very bad a generating correct USART baud rates when their main frequency doesn’t match a multiple of the standard USART rates. Engineers in the know select one of these primary clock rates (for example 14.7456MHz, 18.432MHz, or 22.1184MHz) when they’re planning on doing any real Serial communications. Unfortunately, the 16MHz clock rate chosen by the Arduino team generates about the worst USART timing errors possible.
This means that the Arduino devices can only work at 16MHz while programming them with the Serial Bootloader, otherwise programming is bound to fail, due to losing a bit or two due to the clock rate error.
Arduino had serial programming completely solved in the old days by using a real USB-USART chip, the FTDI FT232R, but for some reason they stopped doing the right thing. This might have been the perfect solution, but they abandoned it. Who knows why…
Secondly, although having an integrated uSD card cage on the platform is a great thing, using a resistor chain to do the voltage conversion is nominally a bit problematic. The output pins (SCK, MOSI, CS) are permanently loaded by 3k2 Ohm and an input pin (MISO) high signal generates only 0.66 of Vcc, which only just clears the minimum ATmega signal high level of 0.6 Vcc. Neither of these issues prevent the uSD card from working, and the voltage divider resistor chain takes almost no space on the board. But still it is not perfect.
Thirdly, there are some minor oversights in the V1 build that I would like to correct if possible.
New Directions
I’ve been toying with the idea of building an Xmega board, in Arduino Uno R3 format, because of the significantly enhanced I/O capabilities of this MCU including true DAC capabilities, but I’ve not followed up for two reasons; the Xmega has no history of use by hobbyists as there is with the ATmega devices, and it doesn’t bring any advantage that an ARM MCU wouldn’t otherwise do better and faster.
Never the less, the ATmega platform still lacks one thing that I believe is necessary; a high quality analogue capability. The world is analogue, and having an ADC capability, without having a corresponding DAC capability, is like having a real world recorder with no means to playback these real world recordings.
A major initiative of the Goldilocks is to bring an analogue capability to the Arduino platform. So this device will be called theGoldilocks Analogue.
Updated – Goldilocks Analogue
There have been music shields and audio shields built before, and the design used is closely aligned to the original Adafruit Wave Shield, but I’ve not seen dual high quality DACs with both AC and DC capability, integrated onto the main board of an Arduino previously. So that’s where I’m going.
The goal is to be able to produce a DC referenced signal, from 0Hz up to around 100kHz, that can provide a binary-linear representative voltage (with sufficient current) to enable a control system, as well as to produce the highest quality audio, with very low noise and THD buffer amplifiers, that the basic AVR platform is capable of producing.
Using Eagle
I used to look at Eagle (Kicad, etc) with healthy scepticism. Yeah, not something that I’d be able to learn, but in the process of realising the Goldilocks Analogue, I have learned that it is far easier to learn a new skill than it is to guide someone in India or Malaysia, who doesn’t even get the start of what I want. The old idiom, if you want something done right, you’ve got to do it yourself.
There is a “Fremium” version of Eagle available, which is enough to get started. I’m going to try to get a “Hobbyist” version as soon as the paperwork is through.
So all this below is my first Eagle project.
The Schematic
I’ll talk through each item in the schematic, particularly those things which are novel in the Goldilocks Analogue. The schematics for the Goldilocks V1 can be found in the User Manual.
FT232R
The FT232R is the same device used in countless earlier Arduinos, such as the Duemilanove, and in USB-Serial adapters everywhere. The drivers for all major operating systems are widespread and there is no magic required. Importantly, the FT232R chip generates a real USART baud rate, at any speed from 300 baud to 3 Mbaud.
Unlike in the Duemilanove I’m using the FT232RQ chip, which is in the QFN package. There is too much going on to take up the board space with the larger package.
I’ve added a switch to disable the DTR Reset functionality of the Arduino and Wiring Bootloaders. Often, I would like a running device NOT to be reset by plugging the USB cable, but then I’ll be using the Goldilocks in another thing where I do want this to happen. Having a switch, like Seeed often do, is the best answer.
Also, I’ve added a 6 pin connector replicating the standard FTDI pin-out, to enable the FT232RQ to communicate with other devices, should this be necessary. It would be a shame to lock it into the board, with no option for extension.
uSD Buffer
In designing the buffer for the uSD, I was trying to achieve two things. Firstly, isolate the uSD card entirely from the SPI bus when it was not in use. By isolate, I mean over 1MOhm resistance. This isolation ensures that the uSD card doesn’t load up the SPI pins at all, when the uSD is not being used.
Secondly, I was trying to ensure that each end of the SPI bus receives the correct voltages and currents to ensure maximum throughput.
The two devices selected achieve both goals as desired.
For the MCU to uSD direction (SCK, MOSI, and CS) I’m using a 74LVC125 in quad package. This package is tolerant of inputs at 5V rising above its Vcc of 3V3. The output enable on low, is connected to the Chip Select line, which means that the uSD card will not be driven unless the CS line is low. It always presents a high impedance to the MCU.
As a quad package the 74LVC125 has one spare gate, which can be used to drive the Arduino LED. This is neat no cost result that entirely removes any loading on Arduino Pin13.
For the uSD to MCU direction the buffer has to effectively produce a 5v CMOS high when receiving a 3V3 CMOS high. The best way to do this is to use a device that is TTL signal compatible. The TTL minimum high signal is only 2V, much lower than the CMOS minimum high signal of 2/3 of Vcc, and importantly below the worst case of 2/3 of 3V3 CMOS.
The only device I could find with the required characteristic of accepting TTL inputs with a low output enable, is the MC74VHC1GT125. I’m sure there are other options though.
DAC and Buffer
This is the fun stuff. Analogue… the real world. As noted above, the goal is to produce two binary-linear signals with enough buffering that they can drive a reasonable load (such as small headphones or an audio amplifier) and produce a constant voltage under a number of power supply options.
The inspiration for the circuit came from the Adafruit Wave Shield, but there are a number of significant improvements that are worth noting, not least the use of a dual DAC, for two channels of output.
Firstly, if you want to get a very low noise output, whilst using a high current Switch Mode Power Supply, it is necessary to filter the supply voltage. I’ve utilised the dual steps of an L-C primary filter, followed by a ferrite core bead secondary filter. I’m not sure whether this is all necessary, and I’ll be testing the circuit later with various components removed to check their efficacy in the role, but if they’re not designed in now they never will be added later.
I’m using the Microchip MCP4822 DAC to produce the raw output voltage. This is an SPI device which will be selected using the other “spare” Goldilocks digital pin PB1. Using PB1 to signal the DAC means that none of the Arduino R3 pins are used for on-board Goldilocks functions, and as both CS lines (PB0 and PB1) are tied high they will ensure that all these on-board devices stay off the SPI bus during system reboot.
The MCP4822 takes 16 bits to set a signal level, this is two SPI bus transactions. The maximum SPI rate is SCK/2. Therefore, if my Goldilocks is doing nothing else, it can generate 691,200 SPI transactions per second. If both DACs are being driven we can generate a square wave of 172,800Hz. This is an unreachable figure. More likely, the best case will be around 50kHz for both channels, or 100kHz if only one DAC is being used.
Optionally, the LDAC pin-out can be used to synchronise the transfer of digital inputs to the analogue output buffers across the two DACs or to a specific clock with low jitter.
Unlike the Adafruit solution, the MCP4822 generates its own internal 4.096V reference voltage Vref. This means that irrespective of whether the Goldilocks Analogue is being powered by a battery, by USB, or by the barrel connector and the SMPS, the output voltage for a particular digital input will be constant.
The op-amp configuration with dual op-amps, in a quad package, designed to double the current capability of the output, has raised concern from all who see it. Concern was my initial thought too. However after some research, I found it to be a recommended configuration for current doubling. The only difference to the Adafruit example circuit is to add low value output resistors which allow each op-amp to find its own offset level without consuming excess current.
I have added the option to bridge the output capacitors to provide a DC output. The output capacitors are necessary for audio use, as headphones or audio amplifier inputs require an AC connection, with no DC offset.
The Layout
It takes many hours to layout even a small board the size of an Arduino Uno. Luckily, I had a completed and fully functioning example to use as a platform, thanks to Jon’s prior work on Goldilocks V1.
The final prototype board layout is now done, and the board design sent off for manufacturing.
In this layout, I’ve been able to retain most of what makes a Goldilocks; the ATmega1284p, the complete dual rows of header pins arranged in pin-logical order 0-7, bridging of the I2C pins to A4/A5, JTAG, and a high current power supply. Added to this now are the three items described above; the FT232RQ and Reset switch, buffers for the uSD card, and the analogue platform.
Starting in the bottom left, the SMPS has been relaid to significantly shorten the high current paths around pins 2, 3, and 4. This will reduce the circuit noise, and taken togther with the effort to create solid ground planes, and specific AVcc filtering, will help to ensure the minimum of power supply noise in the analogue platform.
On the right we can see the uSD buffers, which have eaten into the prototyping space significantly. Although the signals will be much nicer than with a resistor bridge, the cost is clearly on space. If the Goldilocks Analogue ever goes into production the SOIC package buffer chip will be replaced by a QFN package, and some space should be recoverable.
Finally, the analogue platform is implemented in the top left of the board, to the left of the pin-outs for the analogue platform and the FTDI interface. Below the pin-outs the analogue supply voltage filtering is implemented, with exception to the chip decoupling capacitors which are tied directly to their supply pins.
Keeping the analogue lines as short, as balanced, as fat, and as well shielded as possible was a key focus of my design. There are a few USART lines running under the chips, but they are unlikely to produce noise as they are under the first ground plane.
The top layer of the board is pretty crowded. Some tricks such as bridging my lines to get a solid ground plan under the crystal, were passed to me.
The Route2 or second layer is the ground plane of the board. As such it needs to provide a stable and solid path for currents to return to the origin. I have been able to provide almost solid copper under the entire area from MCU to power supply, and also from the analogue platform back to the central ground point.
In the Goldilocks Analogue (as in Goldilocks V1) the Route15 layer is wholely at 5v and is a massive supply line. I’ve used this layer to transport the 3v3 supply around the lower edge of the board, to provide power to the uSD card, and its input buffer. The other thick tracks are the USB input line and the analogue AVcc supply line.
On the back of the board, mirrored here, things look as we expect. The previously noted bridge capability for the I2C bus to A4/A5 is there, as is the capability to bridge the DAC A and DAC B output capacitors to enable DC output.
Next Steps
The Goldilocks Analogue prototype board design has been sent to Seeed Studio for conversion into a PCB. While this is happening I’ll be sourcing components to solder to the PCB. I think the next post will be on this stage of the process.
Well I have everything finished and in the interim, until I write a new post, here’s the photos of the final assembly of the prototype at Jon’s SuperHouse.
Here Jon is assembling the first prototype, using several faulty Goldilocks v1.1 devices as donor boards. Only two components didn’t fit correctly, and we didn’t have a uSD card cage so that was left off.
Out of the toaster oven, and final assembly finished. Just checking that the voltages are as expected across the board.
Well I’ve had it on the desk now for two nights, and I’m very impressed that it seems to generally meet the specification that was intended. The code for setting the DAC levels is currently only optimised for setting two values at a time. Specifically, it is not a streaming function. Never-the-less, it is possible to achieve the stated goal for both DAC channels. The actual number achieved is 108 kSamples/second, shown below, or 18.8us to transmit 2 samples on 2 channels.
The trace below shows the signals for both DACs at 0x0000, then both DACs set to 0x0FFF.
Therefore, we’ll be able to achieve the 44.1kHz sample rate for CD audio, but only 12 bit resolution, with some time time to spare. If there is a need to read a uSD card, or do some other processing then it is likely that this rate will be more than halved, as the data would then need to to be read over the SPI bus (the same bus the DAC is using) for example. Also, there is a single pole filter between the DACs and the OpAmp buffer, with a 3dB cut-off frequency of 23kHz, which will limit the maximum output frequency but will help to reduce sampling alias issues.
Looking at the board from the top left the MCP4822 can be seen in the SIOC8 package, with the Burr Brown OPA4132 quad op-amp in a SOIC14 package just near the POWER selection jumper. The FTDI FT232RQ USART in QFN package takes up much less space than its FT232RL peer.
Goldilocks Analogue – Top Left
Now the prototype is finished, it is easy to see what needs to be improved. Actually there’s not too much wrong. The inductors for the Analogue Vcc have the wrong footprint, so they will need to be fixed. The inductor is too large for the footprint and is snuggled up to the POWER jumper, and the ferrite bead is somewhat too small. I didn’t source the very small 15 turn potentiometers, so they are just shorted out. As is the DTR (RESET) disable switch located near the USB connector. As a final issue, the footprint for the 1/8″ jack was wrong for the supplied connectors, so I’ve just added a short set of jumpers to achieve the same outcome.
Goldilocks Analogue – Bottom Right
Here is a short video demonstrating a Voltage Controlled Oscillator running at 44.1kHz sampling into dual channels. It sounds a little odd, because one of the channels is inverted, generating an out of phase effect.
Results
Well, things are good, and bad.
I’ve been testing the DAC stage and found (what I should have known) that I needed an output buffer op-amp able to reach the negative rail (0V) on input and output to support the MCP4822 0v to 4.095V ranging DAC. The OPA4132 exhibits noise and instability issues around 0.3V output.
Unfortunately the OPA4350 (rail to rail high current), which looks like it will be the right pin compatible device, costs over $10 each, which is nearly as expensive as the audiophile OPA4132 I specified previously.
There seems to be a pin compatible alternative, the TS924A, which is about $2 each, but it is several orders of magnitude worse in performance.
For Example: OPA4350 vs TS924A
Gain Bandwidth Product: 38MHz vs 4MHz
Slew Rate: 22V/μs vs 1.3V/μs
Total Harmonic Distortion: 0.0006% vs 0.005%
Is it worth the difference, when working with a 12 bit DAC in the presence of mV of power supply noise?
Personally, I doubt it.
Using my new Red Pitaya to analyse the output, with a 43.066Hz Sine wave (1024 samples at 44.1kHz) the noise floor is 70dB down from the signal ex DAC. It seems the DAC performs as advertised.
43.066Hz 12bit Sine wave, 1024 samples output at 44.1kHz.
Part 2 of this project involved learning how to use hardware PWM to control servos. And, then to make the clock actually work with retrograde analogue hands.
First the functional definition. A retrograde movement in horological terms is where the indicators or hands spring back to their home or 0 position at the end of their cycle. So for a minute hand, after 59 minutes and 59 seconds, its next movement would be to reverse move to home at 0 minutes. For the hour hand this could happen after 12 hours or 24 hours. 24 hours is the case that I have chosen to implement. The idea is to have the hour hand trace out a day from sunrise in the east, to vertical noon, and to set in the west.
In part 1, I added the servo headers to align with the Arduino Digital Pins 5 & 6. These pins are driven by the Timer 0 PWM hardware. Following quite a few evenings trying to understand how to generate PWM using the hardware (OK, I’m a bit slow), I realised that it is not very easy to get a good servo signal out of Timer 0 or Timer 2.
To generate the right signal for a servo, you need to produce a pulse every 20mS (50Hz). The width of the pulse should be 1.5mS to get the neutral position. Depending on the servo design, pulses with width from around 0.8mS to around 2.2mS (repeated every 20mS) will drive it to either end of its range. Depending on the servo, 0.8mS may drive it clockwise or anticlockwise. I have both in the clock. For example, the “hour” servo goes clockwise with a wider pulse. The “minute” servo is the reverse case.
The main issue with Timer 0 and Timer 2 is that they are 8 bit timers, counting to 255 before resetting to 0 (ideally after 20mS). Since the required pulses are between 0.8mS and 2.2mS, there are only about 12 “positions” available for the servo to take. Not enough to allow a minute hand to indicate 60 different positions.
Therefore it became clear that, for this application, it was only possible to use the 16 bit Timer 1 to control the servos.
Setting up Timer 1 is relatively easy, once that decision had been made, so the code was implemented. But, this meant that I had to reconnect the servo headers to Arduino Digital Pin 9 and Pin 10, which are driven by the Timer 1 PWM hardware.
Also, in the pictures below, I have added a header to allow power, LCD backlight (32Ohm), and contrast (1kOhm), connections to the standardised HD44780 LCD.
Ok, so here’s the issue. I’m using the Pololu Libraries for writing to the LCD, and the standard connection for the data line 4 on the HD44780 LCD goes to Arduino Pin 9. The same pin I need for the Timer 1 PWM. Ouch.
Modifying the library is not too difficult. We can move the Data line attached to Pin 9 onto Pin 11, and all is well. This is done in the following file.
~/libpololu-avr/src/OrangutanLCD/OrangutanLCD.h
The changes are noted in the #define lines below
#define LCD_DB4 PORTB3 // Was PORTB1. Use PORTB3 to avoid the Timer1 pins.
#define LCD_DB5 PORTB4 // PB4
#define LCD_DB6 PORTB5 // PB5
#define LCD_DB7 PORTD7 // PD7
#define LCD_PORTB_MASK ((1 << LCD_DB4) | (1 << LCD_DB5) | (1 << LCD_DB6)) // Modified to avoid using DB1
#define LCD_PORTD_MASK (1 << LCD_DB7)
#define LCD_PORTB_DATA(data) ((data & 0x07) << 3) // Modified the data mask to avoid using DB1
#define LCD_PORTD_DATA(data) ((data & 0x08) << 4)
The below pictures show the LCD pin layout.
<blockquote”>Red = VCC
Black = GND
BLUE = Voltage for contrast or backlight
Orange = Data lines (4-bit: DB4 – DB7) PB3 (not PB1), PB4, PB5, and PD7. Arduino Digital pins 11 (not 9), 12, 13, and 7
Purple = Control lines (RS, R/W, E) PD2, PB0, and PD4. Arduino Digital pins 2, 8, and 4
So now we have PWM for our retrograde analogue hands, and a LCD display.
But wait, there’s more…
There’s too much display going to waste, so let’s add something else… Hmm… Temperature, and time, make a min/max thermometer that can show what time each extreme temperature was reached during the day.
Quickly getting a LM335Z temperature sensor, I’m now testing whether the 10bit ADC is good enough to generate reasonable temperature readings from the device. At full range of 5000mV across 1024 levels, we have about 4.88mV per level. The LM355Z produces 10mV per degree, so we should be able to get 0.5 degree accuracy. If everything is perfect.
Currently the temperature gauge works, but the accuracy is still a work in progress, as are the min / max functions. The LM335Z has only two connections, and is biased by a single resistor (3200 Ohm), so it will fit into the board if that is all that is needed. Getting perfection may require addition of decoupling capacitors on AREF and across the sensor, but I’m still
experimenting with this.
The overall working product is shown below. But wait, there’s more…
I was not happy with using resistors to tie up the SCL and SDA lines high for the I2C bus, as it should be possible to use the internal pull up resistors in some situations (according to the Atmel datasheet).
So using a new Freetronics 2010 from Little Bird Electronics, the clock is now rebuilt without external pull up resistors. The I2C code is modified to only pull up the lines between the start and stop bus instructions. The levels are messy (not showing sharp transitions in my SLO) but, never the less the code and the clock works.
The working device is shown below. Note the rather funky white on blue display I got from Sparkfun.
Gone Bush 