Recent Posts

Pages: [1] 2 3 4 5 6 ... 10 Next
1
Test Equipment / Re: Choosing between entry-level 12-bit DSOs
« Last post by shapirus on Today at 06:26:17 pm »
I meant I get a clean sine wave up to 841MHz.
Ah, I see. Well, that's just one point in time, and the display persistence hides the deviation of the peaks from the real value. What we're interested in is observing dynamically how the waveform becomes wobbly as the signal frequency increases and gets closer to that point.

It's clearly better than the Rigol, though, which is much worse at 1/2.5x the sampling rate. I wonder how the SDS800X HD scopes perform in this scenario.

Here's, BTW, a 500 MHz sine wave captured at 1.25 GSa/s sampling rate:

2
Beginners / Re: Checking for noise in resistors
« Last post by Calambres on Today at 06:23:00 pm »
Very interesting those last two postings. Thanks!
3
You'll wish you either hand-placed the whole thing, or paid a fortune for a local assembly company.   |O

Or you'll wish you spent more time sourcing parts from JLCs library. 
4
Programming / Re: Linux Dependency Black Hole
« Last post by Siwastaja on Today at 06:21:16 pm »
What's wrong with docker? It actually provides a way to create an abstraction layer to decouple the software in question from the host OS, thus helping to solve dependency issues

It is "solving" an unnecessary problem that is created by poor practices. I consider it as a bandaid, or hack, or lipstick on a pig. Even if you end up using it, I strongly suggest designing your software such that it does not depend on docker. If docker is making things slightly easier for some (the new docker generation), then it's OK. If your software is nightmare to use without docker, then it's a good indicator of failure.

* Avoid dynamic linking, link statically if possible, and therefore:
 * Avoid library dependencies like plague;
How does the latter follow from the former? If you link statically, you don't care about dependencies.

Even with static linking, unneceassary dependencies increase the size of your binary, and makes your own development work more difficult to you or anyone else who tries to build the project from sources. So what I really meant: avoid excessive library use regardless of static vs. dynamic linking.

Quote
By using libraries, you avoid reinventing the wheel and avoid making dangerous mistakes.

In the perfect world, yes, and this is correct use of libraries. It is very typical however to solve relatively simple problems with libraries which do not exactly solve that problem, and end up doing same amount of work anyway, in which case you have both your own mistakes plus any hidden within the library.

You seem to have good trust in quality of libraries. I don't. Therefore I suggest use only those you actually need. Quality over quantity.
5
Beginners / Re: Photodiode output emulation
« Last post by elki on Today at 06:19:30 pm »
Thanks a lot. I am using a photodiode that is voltage biased - cathode to positive power supply, anode to the input of the amplifier. If I understand correctly, the general approach would be just pass the pulse from function generator through a resistor to achieve the needed current.
6
Thanks... so I thought.

FWIW the general heap I use is the one in libc.a i.e. newlib. The block starts as usual after end of BSS and goes all the way to the general stack. The code seems OK; I had to mutex it to make it thread-safe, and in the RM for the box I tell coders to not use the heap ;)

MbedTLS runs its own private heap within a static block you give it. Well that's one mode; I give it 60k and that is obtained with the newlib heap, and is de-allocated when the TLS session ends but because 60k is such a huge block - most of my heap - fragmentation is not possible. And I think it is that heap which the MbedTLS guys were talking about. MbedTLS is incredibly complicated and almost nobody understands it, so chucking away the whole block is probably a good idea.

FreeRTOS also runs its own private heap for allocating memory to tasks as they are defined during startup, but I never de-allocate those either.
7
Test Equipment / Re: Choosing between entry-level 12-bit DSOs
« Last post by KungFuJosh on Today at 06:18:36 pm »
I meant I get a clean sine wave up to 841MHz.
I've been able to do that that too.  Well, I only went to 840MHz.

I win. 😉
8
The story is obviously made-up. Obviously when you buy expensive software, you register your order with the publisher and if you lose your copy, any company would give you a new copy. It's not like you'd anonymously buy a license for a multi-thousand $ software.
9
Test Equipment / Re: Choosing between entry-level 12-bit DSOs
« Last post by BillyO on Today at 06:14:10 pm »
I meant I get a clean sine wave up to 841MHz.
I've been able to do that that too.  Well, I only went to 840MHz.
10
Not easy working with small squeeges to fit between components but probably easier and cheaper than what OP was considering: using small stencils.

You would also need to exclude all of any non-JLC placed footprints from the manufacturing stencil used by them, otherwise those pads will already have molten paste and flux residue which has quite possibly spread wider than your new stencil apertures.  The new stencil will not be able to sit properly flat and/or your squeegee won't go over the solder bumps cleanly... meaning the squeegee is lifted off the stencil.

Sounds like a great idea at first, but in practice the process is likely to be far more painful than you can imagine.  Your attempts at paste application will likely be awful.  A bad stencil "gasket" leads to paste leaks causing bridges, and the need to continually clean the underside of the stencil.

You'll wish you either hand-placed the whole thing, or paid a fortune for a local assembly company.   |O
Pages: [1] 2 3 4 5 6 ... 10 Next