Stop the sirring noise!


Mixing f1 with f2 produces f1+f2 as well as f1-f2 afaik?
You could wolfram alpha plot sin(2*t), sin(3*t), sin(2*t)*sin(3*t), t=0..3*pi to see the effect.


I meant Interference in sense of multiple frequencies put "on top" of each other resulting an audible waveform.
I think you're getting something mixed up there. But it's probably not f1 and f2. Mixing in the sense of 'put "on top"' signals - I'm guessing you mean the superposition of signals - can never create any new frequencies, as it's completely linear.
Where you actually get f1+f2 and f1-f2 is with multiplication of signals (which is the same as folding in the frequency domain).
 
You are right. "On top" is the wrong wording (which is why I used quotes). Nevertheless. If you switch an AC signal, you get f1*f2. f1 being the ripple on the input (capacitor), f2 being the switching frequency. Or am I wrong there?

But yeah.. it's possible that it is totally unrelated to that and just part of the dynamic response to the switching edge (rise time)... which would be bad as changing the frequency would not help in that case (but changing the inductor could).
 
Last edited:
Assuming the IC runs stable and is correctly compensated, It does nothing but applying a rect with defined frequency and rise time with a calculated pulse width to a choke that feeds a capacitor. Not sure what can be out of specs there... The actual wave form comes from load, inductor and capacitor.

For instance the DC/DC could be running below its minimal load, so the capacitor could be trying to suppress the overswing. I do vaguely remember something about the noise disappearing when you connect something to the USB ports and the above would match up with that symptom.

We know it's something to do with the USB ports; the system probably runs at 3.3/.7 V throughout, except it needs 5V plus a bit for those sockets at least when in host mode for the power pins. So I assume it's practically tied directly to the 5V pin of the USB type-A port.

My own plug in 3.1A USB charger emits a tone when it's switched on but nothing is drawing any current from it. It's just on the limits of my hearing, so it comes and goes as I turn my head, but I think it's basically a constant tone if I can hold my head still enough, and not in any way a 'sirring' type noise. It goes away when I attach something that needs charging though.

Which leads me to believe it's a DC/DC boost converter, which also means there should be a coil in there somewhere. It could be that we've built an LC oscillator with a resonance frequency coinciding with another circuit on the output. This would also explain why the noise differs so much between boards.

Some time and TI search engine poking later...

I think I've narrowed it down to 2 possible ICs which we could be dealing with here and one of them has this application note attached to it in the documentation section, the relevant excerpt is as follows:

Texas Instruments said:
At no load or very light load condition, the switching frequency of the boost converter is very low, as shown in Figure 4. The input current is pulsating in the same frequency which makes the input current hard to be measured using a current meter.

A simple RC filter circuit shown in Figure 5 helps to solve this problem. The cut-off frequency of the RC filters must be much lower than the switching frequency of the boost converter.

From Figure 4, the switching period is 62 ms, so the time constant of the RC filter can be set to 6 seconds. Based on the input current calculated by Equation 2, we can select 10 kΩ for R_F and 600 μF for C_F. Large R_F results in large voltage difference between the power supply voltage and the real input voltage, which cause trouble in setting the right input voltage. Small R_F results in large ceramic C_F, which increase the cost.

Firstly, connect the power supply to node 2 shown in Figure 5 to charge the C_F and start up the boost converter. Then move power supply quickly to node 1. The input current can be calculated by measuring the voltage drop across the R_F with a multi-meter. It is suggested to wait at least ten minutes until the input current becomes stable. Table 2 shows the calculation and measurement results of the no load input current at different input voltages conditions. The calculated values are closed to the measurement results.

For those without a PDF reader on hand:
Figure 4 shows how the switch is trying to regulate without any load, which causes it to switch at long and irregular intervals. The illustrated periods range from about 30 ms to 62 ms.
Figure 5 shows how to properly measure the input current in this unstable state through the voltage drop across a known resistance in series with the power supply, after charging up the two input capacitors C_F and C_I in addition to inductor L. The output only has a capacitor C_O attached to it and there's an illustrative resistor to show where a load would be attached.

The example clearly illustrates what happens below the minimum load of the DC/DC. Even though the minimum load is not explicitly specified in the table of electrical properties it clearly has one since this application note is attached to it. The datasheet of the IC has a chapter called "Checking Loop Stability" which may be relevant to fixing this through adjusting the inductor and capacitor values, which also mentions the loop stability must be measured across the entire voltage, current and temperature range to verify it's stable.

That's about as much time I have for researching this today, I have a fluid mechanics test tomorrow and I want repeat a few more things (only 2 weeks in so it's basically just hydrostatics combined with Reynolds number and the unmodified Bernoulli equation, but still). Feel free to reply but don't expect an answer until tomorrow afternoon ;)
 
The example clearly illustrates what happens below the minimum load of the DC/DC.
That's why I wrote "Assuming the IC runs stable and is correctly compensated [...]". You normally select components from a table of "reference designs" to rule out instable operation.

"Skipped" output swings would potentially be another source of audible wave forms though...
 
Still on topic. Amazing!
but you've just set the 1st stone for the thead to derail completly
19thomas-600.jpg
 
Some time and TI search engine poking later...
You might be interested in the Pyra schematics once your exam is behind you... it has the part number for every major component. The wonky chip in question is the tps2505.

The switching frequency of a good DC/DC should be outside audible range so I'm worried it's not operating within spec for some reason.
If I'm reading figure 14 in the datasheet correctly, it shows ripple at around 13kHz, so it's normal. Pulsed frequency mode (used when load is low) has even lower frequency.
 
If I'm reading figure 14 in the datasheet correctly, it shows ripple at around 13kHz, so it's normal. Pulsed frequency mode (used when load is low) has even lower frequency.
Exactly. This is the problem. Figure 4 in http://www.ti.com/lit/ds/symlink/tps2505.pdf also shows it. It is a "feature" of the tps2506 to have such ripple in low-load situations and we have connected "piezo speakers" (aka MLCC) to it. This is even frequency-modulated by different power demand by an USB client. Therefore the sound is not stable in frequency. This chip is an older design and maybe was never intended to be used with MLCC. So the best solution seems to be to use a different DC/DC which does not producte this audible ripple.

You are a wonderful community - you identify and better describe the issue than I am able to follow the postings :)

PS: Pyra and the Pyra-Phone idea were well accepted during FOSDEM by everybody I was able to talk to. So expect some prototype of a Pyra-Phone to be shown (photos, videos) in a while. Next we can think about doing preorders for a handful of developers. And if everything goes well, about crowdfunding for a series. But please don't expect that we can fulfill many wishes for change (most notably: we can't change to a capacitive screen if we want to reuse the existing Pyra display for keeping the project simple and doable in an evolutionary mode).
 
PS: Pyra and the Pyra-Phone idea were well accepted during FOSDEM by everybody I was able to talk to. So expect some prototype of a Pyra-Phone to be shown (photos, videos) in a while. Next we can think about doing preorders for a handful of developers. And if everything goes well, about crowdfunding for a series. But please don't expect that we can fulfill many wishes for change (most notably: we can't change to a capacitive screen if we want to reuse the existing Pyra display for keeping the project simple and doable in an evolutionary mode).
That sounds very sensible. I expect any telephony app for Pyra will be designed for mouse/nubs/stylus usage, so you'd also need a completely new UI for everything. That doesn't seem like a sensible thing to pin the pyraphone project on at this stage.
 
I know nothing, but would a lump of glue around the capacitors not mitigate this situation? Are there significant disadvantages to that approach (other than perhaps pride -- it seems from a couple of EEVBLOG videos that this is 'uncool')?
 
I know nothing, but would a lump of glue around the capacitors not mitigate this situation? Are there significant disadvantages to that approach (other than perhaps pride -- it seems from a couple of EEVBLOG videos that this is 'uncool')?

I think that comes because it stops you debugging that specific area by putting probes to it.
 
I think that comes because it stops you debugging that specific area by putting probes to it.

Thanks! Presumably debugging would be of limited use AFTER the hardware is released (in the meantime most testers may need to tolerate the noise or use blu-tac or similar). Or perhaps the USB power circuit is unlikely to be of great interest to modders, especially if it is small (is it? If so, then presumably also the hot-snot will be small and so the debugging hindrance would be small). Are those reasonable counter-arguments against that disadvantage?
 
It's of limited use, but probably quite useful to the kind of person that has an oscilloscope and has opened up a Pyra on their workbench. He's usually probing things to figure out how things work, or to figure out why they don't when something's broken.

I'd have thought it unlikely a problem in this area less than a full on short would stop a system booting though, and if the glue doesn't spill over any other significant areas of functionality, it might be unlikely to cause a problem to any hardware hackers.
 
It is trivially easy to remove hot glue from a board. Just get you one of these.
If you've got an oscilloscope and a hankering for some probing it'll take less than 2 minutes to clean the glue off to get to the contacts.
Being able to probe this particular part seems of limited use to most people, and since it is pretty easy to undo if you really want to I can't think of a reason not to investigate. If a spot of glue solves the problem then it's done, no need to worry about redesigning the board, nor about sourcing tantalum caps. I think Haraldur has an idea worth considering.
 
Do those caps produce heat? Does hot glue conduct heat well? Does hot glue shrink over time, thus exert strain on the caps and further on the soldering? I'm not trying to hint on something, I already know. I don't know.
 
That sounds very sensible. I expect any telephony app for Pyra will be designed for mouse/nubs/stylus usage, so you'd also need a completely new UI for everything. That doesn't seem like a sensible thing to pin the pyraphone project on at this stage.
There exist several mobile and touch gui focussed OS from the heritage of OpenMoko & GTA04. For example: Replicant, QtMoko, FSO, SHR and more. They just need a little polishing and some people are keen on doing that provided that they get newer hardware. A Pyra-Phone does not necessarily mean you have to use Pyra-OS on it. They share hardware components and kernel but there will be multiple GUI projects to choose from.
 
I too support this idea. I really liked my OpenMoko and I would like to see another device like it. Too bad it got stolen, still wondering if the thief managed to even make a call...
 
Back
Top