Recent Posts

Pages: [1] 2 3 4 5 6 ... 10 Next
Beginners / Re: Copper bar soldering problem
« Last post by Karlo_Moharic on Today at 02:55:04 am »
use propane TORCH !!!!!!!
Soldering irons aren't made to give out that much heat.
Maybe a couple of swift drinks prior to going to a real party to get into the mood?
Beginners / Re: Which osciloscope will be better?
« Last post by Karlo_Moharic on Today at 02:52:56 am »
R&S is just higher quality . So yes R&S over tektronix any day.
Microcontrollers & FPGAs / Re: Discussion on state machines
« Last post by NorthGuy on Today at 02:51:24 am »
(back to the topic)
Like the state-machines: the flow of actions can get from non-obvious to really confusing with if/then/else or switch/case implementations. Not separating the code under a case out into a function worsen the issue and may yield switch statements of several 100 lines.
I would not consider it bloat to have a mechanism/library/language feature to make that sort of code more readable even if it is not more performant (assuming no requirements exist that inhibit this choice).

Excellent example.

Someone creates a state machine which is too big and unmanageable. I don't think the effect may be measured by the number of lines - few hundred lines is not that bad, depending on the way it is all organized, even few thousand may net be bad. On the other hand, 50 lines may be enough to create a mess. The case statement for a state machine is reminiscent of the Spaghetti code of old ages, and if you don't think well, your state machine can turn into a mess very quickly. Assume this happens - you created a state machine which is unmanageable (happened to me few times). This is already a bloat. The solution to this is to simplify the design - may be use different set of states, may be use hierarchy, may be avoid the state machine at all, may be re-think your data structure. At any rate, you need to throw away the mess, re-think it and re-do it in simpler, more efficient and more manageable way. This is a sad situation, but you should've thought of this before.

What people do instead? They try to preserve the mess while changing the form - using libraries, creating tables, may be using function pointers, may be switching to C++. These things may be useful, but it is possible to create/maintain a mess with any of these. Somehow, changing the algorithms and logical structure of "already working" solution looks like impossible task. On the other hand, using a library (or similar) which may magically organize the messy project looks easy. They try to preserve the worthless existing codebase as if it was their flash and blood. So, libraries get added, languages switched. This adds more bloat, but doesn't really clean the mess - may be ever so slightly.

We all know where it all moves - more libraries, RTOS, bigger MCU, FPGA - things keep snowballing - there's actually no end. And what is it all for? To perform a task which can be done on tiny little MCU with much simpler code and much less of development time? If you ask, they'll tell you that all this bloat simplifies (sic!) their work and make time-to-the-market way shorter and the extra-cost of the hardware doesn't matter. What else you expect them to say?

Microcontrollers & FPGAs / Re: Analog domain and aliasing
« Last post by rhb on Today at 02:51:07 am »
For any particular record of samples, there are many possible analog waveforms which could generate it. This is trivially true: draw dots on a piece of paper and connect them any way you like.  There are infinitely many possibilities. If you want to interpret/treat the samples as representing a continuous analog signal, you have to decide which one you think it is.

But what if we continue sampling (assuming we have a repeatable waveform)? The random sampling will be able to reconstruct the underlying waveform better and better. Given enough time, you can reconstruct any curve, no matter how the original dots are connected.

This is not the case with conventional sampling. Additional sampling will eventually stop providing new information. In extreme case, if you sample a sine wave with sampling rate matching the frequency, the inflow of new information will stop after only one sample, and all the other samples will be exactly the same to the rest of eternity.

The quotation attributed to me above is incorrect.  I did not write that.

As for what follows, it has nothing to do with compressive sensing.  The random sampling technique described was used in sampling scopes particularly for microwave when ADCs had no hope of keeping up.  It worked because the signal was periodic.

The extreme case cited above violates the Nyquist criterion.  But a sinusoid can be completely described with 3 samples.

Compressive sensing works by finding the Fourier transform using an L1, rather than the traditional L2 method.  Once one has the transform one does an inverse transform using a conventional FFT to recover the time domain signal at regular sample spacing.
Test Equipment / Re: Test Equipment Anonymous (TEA) group therapy thread
« Last post by Cerebus on Today at 02:49:04 am »
Talking of empty gas cannisters everywhere, Monday is shopping day, and SWMBO and yours truly made a rare side trip to Asda today (they often have fantastic Sorrento lemons at this time of year).  Scattered around the parking space next to the one I picked were three empty cartons and about thirty-six empty N2O 'sparklets' bottles, and the trash from a couple of six packs of beer. I'm all for a party, and I try not to judge other people's definition of 'party', but surely of all places to pick for one Asda's car park has to be pretty near the bottom of the list.
I have a U1273A used almost daily for a few hours and it is holding pretty well. My experience is also mentioned in the thread quoted below
As another piece of anecdotal evidence, on the lab i work, several equipments have  OLED displays running for quite a number of years without fading. My own 2014 manufactured (2017 purchased) U1273A is holding quite well. Also, as bluekull mentioned, it beats the crap of almost everything else indoors.

Beginners / Re: Copper bar soldering problem
« Last post by Twoflower on Today at 02:46:42 am »
I would be a bit careful and do some tests on cheap parts. If you preheat the copper bar it stays hot for some time. That might be enough to roast the devices. It would be very interesting to see to maintain an acceptable temperature curve.

I think you have to mount all devices in one shot to minimize the thermal stress. My idea would be to use solder paste, fix all the devices to the copper bar (e.g. metal clamps) and heat the bar from the backside using a hot air gun until the solder paste melts. Now using a fan to cool it down (not too fast, not to slow).
Test Equipment / Re: Low Noise (Sound) Oscilloscope
« Last post by glarsson on Today at 02:41:38 am »
Rumors say expensive DMMs can compensate temperature drift in software. So, they rely on fans to have certain known performance, otherwise software model will not work as expected. Don't know if this is true or not, that's what I read in a volt-nut thread.
But the cooling performance also depends on the room temperature and any object blocking air from entering or leaving. They have no external sensors for this and internal sensors will se the combined result of fan performance, room temperature and any blockage. That means that fan performance (within reason) can't be that important for the software.
I can recommend Ryobi mini/mouse sander for doing stair spindles with and I'll try and not drop anymore canisters over you garden fence.
Pages: [1] 2 3 4 5 6 ... 10 Next