-
Second build report
02/06/2018 at 01:45 • 0 commentsThe second prototype boards came today and they're almost ideal.
As I mentioned in the last log, I do think I'll back down from a buck converter to an LDO to make the 3.3v power for the controller and GPS, but the addition of the preamp improved the range of output loudnesses available - making more of the range of the adjustment pots usable.
I am going to change a pair of component values, however. The preamp only needs to have 5x gain instead of 10, so that means dropping the feedback resistor from 200kΩ to 100kΩ. The audio (to my ears anyway) sounds a bit less tinny changing the LPF feedback cap on the final amp from 2200pF to 0.01µF.
But that's about it. With the larger speaker, I wouldn't call the volume "room filling" in the same sense as a stereo, but it's certainly loud enough to serve the purpose. If I did a better job recording the audio samples, that would probably help quite a bit too.
-
Buck -> LDO
01/31/2018 at 15:52 • 0 commentsIt occurred to me today that the combined draw of the Xmega and the GPS chip isn't likely more than 75 mA or so, so the buck converter is a bit of a waste. The final version will have a simple LDO instead. There should still be plenty of capacity left over to power a 3.3v antenna if it's jumper that way (the default, however, is 5v antenna power).
The only other question for that version is whether the preamp will be kept or not. We'll get the answer to that when the 2nd prototype boards arrive, probably early next week.
-
Accuracy
01/28/2018 at 19:58 • 0 commentsThe old saw is, "measure with a micrometer, mark with chalk, cut with an axe."
Using GPS to provide a source of time signaling directly through human senses is always going to be swatting a fly with a hydrogen bomb. Humans just aren't very accurate preceptors without lots of technological assistance. The visual GPS clock that presaged this project wound up with an accuracy of ~180 µs, but the granularity is only 100 ms. The speed of light has essentially no bearing on the accuracy.
Unfortunately, I don't have any information about the latency of human perception.
The talking clock has a granularity of only 1 second. But how accurate is it?
Because the tick/beeps of the talking clock are 1 kHz and the oscillator for them is free-running, the accuracy spec starts at ±1 ms, but there's also the PPS ISR's latency to consider, which is probably a few microseconds (that ISR has little to do other than enable the tone output). Depending on where you are in the room relative to the clock will also have an impact because of the speed of sound - probably adding another 2-3 ms of latency if you're ~1 meter away.
-
Mystery solved
01/27/2018 at 16:53 • 0 commentsThanks to Ted Yapo for responding in the comments to a previous log. He solved the mystery.
He said that the LM4871 LPF feedback cap (C20) was the problem. That got me to recalculate LPF rolloff and it was 24 Hz. Way, way too low. I had wanted something more like 2.4 kHz.
First I removed the cap entirely and it really did jump right up.
I had replaced the 20kΩ feedback resistor (R9) with 56kΩ, so the LM4871 gain is now officially 7 dB instead of 3 dB. I added back in 1000pF just to give it some pro-forma rolloff, but I can't really hear a difference.
When the next boards come, I can experiment a bit. I can replace the pre-amp's feedback resistor with 0Ω and leave off the rest of the preamp components and it will be as if nothing is there. Or I can populate the pre-amp and see which way is better.
As for the speakers, the little tiny ones I originally bought won't cut it. Trying to get enough gain for the voice output to sound decent makes it clip badly. The larger speakers, unsurprisingly, sound a lot better. If there's a downside, it's that the case will wind up having to be much larger (still not at all sure what I'm going to do there).
It turns out that a new board rev was going to be necessary anyway because of the previously noted errors. In addition, I swapped the poles of the two gain trimmers so that the directionality correctly matches ordinary expectations (CW for higher gain).
-
Next prototype ordered
01/27/2018 at 06:17 • 0 commentsI've added an op amp preamp configured for 10 dB of gain and ordered a set of boards. 10 dB is ostensibly too much gain, but the way things are now, the two gain pots are all the way up. With 10 dB of intermediate gain, the hope is that the "sweet spot" for the output will have those pots further down in their ranges. The most likely explanation I can come up with is that the maximum amplitude of the output from the controller is 1.65Vpeak. Doubling this yields 3.3Vpeak. If you calculate the average power (P = Vpeak^2 / 2R) into 8Ω, you get a little more than 0.5W. If instead you look at the power from 5Vpeak, it's over 1.5W.
Configuring an OP Amp for a single supply voltage to amplify an audio signal isn't too hard. You use an inverting configuration (because audio doesn't care if it's inverse - that just means the speaker pulls instead of pushes, but it sounds the same) with a Vcc/2 virtual ground (classically the non-inverting input is grounded) made with a two resistor divider (and a decoupling cap). The input and output are both AC coupled. The LM4871 generates differential output power with 3 dB of gain, so if the output of the pre-amp is maxed out, it will max out the output of the power amp.
I've now got two choices for speakers. One is smaller, but it's low frequency performance is much poorer (as you might expect). It's also a couple of dB less efficient overall.
If the result still isn't loud enough, then the audio amp will need to be ramped up, probably to something running on a higher voltage supply.
-
The audio mystery
01/21/2018 at 16:45 • 5 commentsI'm going to have to take the clock back to the workbench and check some stuff out on the scope. It just doesn't seem completely reasonable that given input levels that are ~3Vpp that the LM4871 can't generate enough output. At the same time, given that the specifications of the speaker are something like 98 dBA 1W/0.1M I can't quite square that with "hold it next to your ear" levels of audio. The input levels ought to be making easily 1W of output, and 1W of output ought to be making far more sound unless I'm misunderstanding something badly.
-
First hardware report
01/19/2018 at 00:57 • 0 commentsThe first boards came back from OSHPark. There were a couple of bugs and improvements in the firmware that came out of it, but at the moment there are two hardware bugs that I'm going to have to fix.
The first is that I reversed the differential inputs on the LM4871 audio amplifier input. I was able to work around this on the prototype by lifting the pins and air-wiring them. The v1.1 board design has already been fixed for this.
The other issue is that the audio output is just way too quiet. You can hear it if you hold the speaker right up to your ear, but it's not nearly loud enough to actually use. I'm not sure if it's because the speaker is too puny or if the input levels aren't high enough. What you can hear, however, is definitely good enough in terms of audio quality. The tick/beep output has just a little bit of shrillness (the low-pass filter isn't quite sharp enough to really make it a pure sine output), but that's not out of place. Even increasing the feedback resistor (and thus increasing the amplifier's gain) from 20k to 56k wasn't a significant increase in output volume.
Another correction v1.1 will have is that I've decided to put a MOSFET in to properly level-shift the audio !SHUTDOWN pin. The current design has a 5v pull-up resistor, but that still winds up feeding some current into the output pin of the controller when it's off (since the off level is 3.3 volts). It's not fatal, but it's not ideal.
I'm not going to order the next version of the board, though, until I decide what I need to to do get more audio out.
-
First cut at firmware complete
01/08/2018 at 07:54 • 0 commentsI spent most of this evening writing the first cut of the firmware. I don't think I'll be sufficiently inspired to breadboard the whole thing before the boards come back from the fab, and even if I did, I don't have any of the requisite audio files created. I'll have to spend an evening this week sometime dictating those.
The top level directories on the card are ZONE, HOUR, MINUTE and SECOND. Inside of zone will be files named with two letter names (with the exception of just "U" for UTC) with the first letter being one of 6 for the timezone (P, M, C, E, A, H) and the second letter being S or D for standard or daylight savings time.
Inside of the other directories will be numeric filenames for 0-23 hours, 0-59 minutes and 0, 10, 20, 30, 40 and 50 seconds.
All of the audio files will be little endian 16 bit 8 kHz mono raw audio files (though the files are 16 bit, the DAC will truncate them to 12 bits. In the grand scheme of things, this probably won't be noticeable). Each intro file must be no longer than 4 seconds, and each of the other files must be no longer than one second.
The ticks and beeps will have their leading edges synchronized with GPS time via the PPS pin ISR. Given that the frequency is 1 kHz, that implies up to 1 ms of jitter, though exactly how meaningful that is to human hearing is questionable. It still will wind up being far more accurate than any "time talker" telephone line you can use today given the lack of latency and jitter guarantees of the telephone network.
-
The world's lamest MP3 player
01/07/2018 at 01:02 • 0 commentsI used one of my XMega32E5 breakout boards today to get a proof of concept for the audio generation.
I took one of my favorite songs (Waste by Seether) and converted it into 8 kHz 16 bit raw audio and loaded that onto a microSD card. I built a microSD slot breakout board and stitched the two together on a breadboard.
I was able to make the intended design functional without too much trouble. TCC4 is configured as an 8 kHz timer. Its overflows are used as an event to trigger a DAC conversion. The DAC data-register-empty bit is used as a trigger for DMA. The DMA system is set up for double-buffering (so the transfers will be completely gapless), and Petit FFS used to read the data from the card. TCD5 is used to generate a 1 kHz square wave on one of the pins. This is turned on and off by changing that pin from an output to an input and vice versa. As a side effect, that same timer will generate overflow interrupts to keep a millisecond (it's actually half milliseconds, since the timer actually counts at 2 kHz) counter for SD card timeout handling.
No changes to the circuit are required, at least for this part of the system.
I think now I have enough confidence to actually order the first boards.
-
Initial design
01/02/2018 at 17:01 • 0 commentsThe PDF of the initial schematic has been uploaded to the files section. The first page is very similar to the most recent design of the GPS clock - the XMega32E5 and its connection to the GPS module is the same.
The second page is almost entirely different. There we have the SD card, which is connected to the SPI bus on port C. Instead of the display, the DAC output on port A and the OC5A pin on port D are fed into an audio mixing arrangement (with a low-pass filter on the timer output) and then into an audio amplifier. The audio amp can be turned on and off under software control, with the pushbutton being another input into the controller. This allows the button to have different behaviors defined in software.
I've added a couple of diagnostic LEDs to the circuit to aid in software development. Their exact purpose is TBD.
The software development hasn't started yet, but already it's clear that timer 4 will be set up to run at 8 kHz and act as a DMA clock for sending the audio to the DAC. Timer 5 will be set up to run at 2 kHz and toggle OC5A whenever it runs out. That will generate a nominal 1 kHz output. The actual output pin will be turned on and off in software. It will be turned on at the start of the PPS ISR, and then turned off in the main loop either 50 ms past the second or 500 ms past the second (depending on whether the second is an even multiple of 10).
The audio system will be double-buffered with two 512 byte buffers. Since we're going to use Petit FFS, we're not going to gain any benefit from using DMA to read from the SD card, since it has a synchronous calling structure, so the DMA ISR that switches the DAC to the other buffer (or stops on completion) will set a flag to tell the main loop to fill the other buffer.
The PPS ISR will have several outputs that it fills for the main loop - the time for the next 10 second block, the current second's place within the block (second 0-9), the captured value of timer 4 (so the main loop can calculate when to turn off the 1 kHz output), and a flag indicating it took place.
The main loop will check to see if it's time to turn off the 1 kHz output, then see if it's time to fill an audio buffer from the SD card, then see if the PPS ISR has been triggered or not. If it has been, and if it's second 1, 5, 6 or 7 of the block, then it will open the appropriate SD card file and set up the audio playback for it (reading the first block and configuring the DMA transfer for it). If none of that has happened, then the button will be polled to check its status and appropriate actions taken.