Skip to main content


This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - ferdinandk

Bus Pirate Development / Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)
The ADC speeds (15 and 50khz) are very low though. With the TI ADCs we can do 1msps or 2.5msps which is in DSO nano territory. Eventually we'll do a dual rail parallel ADC at 100msps, but not till we move to the bigger BGA FPGA chip.

The DAC side would be really easy with FPGA pin, agree. Since we're using two in the power supply system I'm quite worried about the noise though. The other two I'd like to put behind a op amp with shutdown and output analog waveforms on two IO pins. Noise is still an issue with the DACs though because they have almost zero PSRR.

True, the sample rate of the ADC is quite lousy. But hey, it's basically free  :D

If you're worried about the PSRR of the PWM DAC you can run them through a buffer (e.g. inverter gate) powered from a reference.

I'm aware that these solutions are a bit of an oddity, as a cost saving of 3 USD won't make a big dent in you total BOM cost.
Bus Pirate Development / Re: Bus Pirate "Ultra" v1a & v1b with ICE40 and Icestorm :)
Very neat project so far, looks like it will be able to compete with Saleae's Logic Pro series.

Regarding the ADC and DAC: have you thought about implementing those in the FPGA? There is a white paper about implementing and ADC in one of their FPGA's from Lattice [1]. The DAC can be as simple as a PWM with an RC filter.

Project logs / Re: Really universal soldering controller
[quote author="sparkybg"][quote author="ferdinandk"]
Q5, ZD1, ZD2 and the surrounding circuitry look like a linear reg, but I can't find it's output node.
This ensures the rectified voltage never gets under 5V. You need a flat voltage on Vin while measuring the TC, otherwise the rectified voltage penetrates the upper MOSFET drain to source capcitance and gives erratic measurement.
I'll have to work out how the drain-source capacitance would offset the TC measurement, but I now see what you're doing there.

It's great to see so many discrete circuits, makes the design much more approachable IMHO. I haven't looked at the firmware yet, but if it's as advanced as your hardware sign me up for a pre-order :) Maybe you could order some PCBs and sell them for a profit. What  case you were planning to use?
Project logs / Re: Really universal soldering controller
This is just amazing. Thank you for making it public.

I've been looking over your schematics, but I didn't quite get everything sorted out, maybe you can help me:

  • Q5, ZD1, ZD2 and the surrounding circuitry look like a linear reg, but I can't find it's output node.
  • does Q6 reduce the ripple on the -0.6V rail, and if so, do you have measurements for that?
  • with all your linear regs you a diode from the emitter to the base, what is it for?
  • I think some electrolytics have the wrong polarity (C22, C8, C11, C4).
Project development, ideas, and suggestions / Re: I2S DAC board for raspberry pi and beaglebone black
That's good news. I'm working on a similar project, except that I want to connect an audio ADC via I2S.

I did some research on the BBB and it seems to be possible to output I2S when the HDMI is not connected. The processor on the BBB supports multiple I2S inputs and outputs, but as far as I can see the Kernel code only makes use of one of them.

Regarding your post from January, why do you think that cascading LDOs would hurt the noise specs? I'd say that the noise would be dominated by the specs of the last LDO in the chain (ADI AN-1120 seems to confirm that).
The reason why Cbyp is omitted in the ODAC design might be that these LDOs are really sensitive to the value and type of this cap. I used it in a project once and it was oscillating with Cbyp but perfectly stable without it. Also I guess that the PSRR of the DAC is good enough for the noise not to be a problem.
Tools of the trade / Re: 3D Gerber Viewer
I know, I know my notebook's hardware is quite dated. This is the most up-to-date driver Intel released, so I'm stuck. My Lua knowledge is minimal and I've never worked with OpenGL, but maybe I will give it try.
On my desktop machine (using version grbv completely blocks one of two cores (100% CPU load). So everything get rather unresponsive :) Trying the most current version ( it even utilizes both cores to their fullest.
Tools of the trade / Re: 3D Gerber Viewer
I got it to run on my desktop PC (AMD CPU with integrated graphics), but it is quite slow. However on my four years old notebook I can't get it to work. The error message I get has stayed the same for the last revisions:

Code: [Select]
Gerber viewer
C:UsersferdinandDesktopGerber Viewerlua5.2nb.lua:149: ...erdinandDesktopGerber Viewerlua5.2enginerender.lua:72: ...DesktopGerber Viewerlua5.2enginedisplayshader.lua:72: GLSL compilation error:
while compiling ./shadersentity_textured.glsl:
ERROR: 3:69: 'texture' : no matching overloaded function found (using implicit conversion)
ERROR: 3:69: '=' :  cannot convert from 'const float' to '4-component vector of float'

stack traceback:
[C]: in function 'error'
...DesktopGerber Viewerlua5.2enginedisplayshader.lua:72: in function 'compile'
...DesktopGerber Viewerlua5.2enginedisplayshader.lua:179: in function 'load'
...DesktopGerber Viewerlua5.2enginedisplayshader.lua:227: in function 'new'
...rdinandDesktopGerber Viewerlua5.2enginedisplay.lua:233: in main chunk
[C]: in function 'xpcall'
...erdinandDesktopGerber Viewerlua5.2enginerender.lua:67: in function 'display'
...erdinandDesktopGerber Viewerlua5.2enginerender.lua:125: in function <...erdinandDesktopGerber Viewerlua5.2enginerender.lua:100>
(...tail calls...)
stack traceback:
[C]: in function 'error'
...erdinandDesktopGerber Viewerlua5.2enginerender.lua:72: in function 'display'
...erdinandDesktopGerber Viewerlua5.2enginerender.lua:125: in function <...erdinandDesktopGerber Viewerlua5.2enginerender.lua:100>
stack traceback:
[C]: in function 'GetExitCodeThread'
...sferdinandDesktopGerber Viewerlua5.2enginegui.lua:424: in function <...sferdinandDesktopGerber Viewerlua5.2enginegui.lua:422>
stack traceback:
[C]: in function 'error'
C:UsersferdinandDesktopGerber Viewerlua5.2nb.lua:149: in function 'resume'
C:UsersferdinandDesktopGerber Viewerlua5.2nb.lua:244: in function 'run'
C:UsersferdinandDesktopGerber Viewergrbv.lua:670: in main chunk
[C]: in ?

Running it on the command line reveals that my GPU only supports GLSL 1.2 - that might be part of the problem.
General discussion / Re: Transmitting current into a big loop
At least for prototyping I would go with an analog current limiter. But as you said, it depends on the DC resistance of the coil you want to drive. If it is high enough, you might get away with limiting the current going to the H-bridge.
General discussion / Re: Transmitting current into a big loop
I would definitely go with an H-bridge. Especially as you can get really nice high-power H-bridge drivers and matching FETs. With an IR2110 I was able to get rise- and fall-times in the order of ns (at low load currents and voltages above 200V - so your mileage may vary). Circuit layout with these things is critical and you might even run into some EMI issues, so just be aware of that when your circuit starts acting funny.

Regulating voltage and current is a different beast. Depending on your requirements you might have to roll your own regulator circuitry. However at 24V and 2A you can get away with off-the-shelf regulator ICs.
Project logs / Re: Sunrise alarm clock
Very nice design. Using simple PVC pipe for a case is really clever!

I have one question still: how do get the station name from the TEA5767? Looks to me like you are using RDS.