design rigor: electronics vs. software

So the FFT is faster than multiplying? So you take a chunk (time wise) of signal, FFT it, compare phase and amplitude to fundamental in ref. and then spit out a number? I'll have to look up how to do a digital LI if I ever need one.

With noisy signals a BP filter somewhere in the signal chain is a must. (IMHO)

Hey, when you were talking about measuring blood response while having a few brewskis. I was wondering if this is something you could sell to bars? So patrons could see if they need a taxi before they leave. I've always wanted to know what my blood alcohol is...

Oh speaking of FFT's and windows I read this nice talk by Richard Hamming

George H.

No, just multiply-and-accumulate is faster than the FFT, but it only gets you one frequency component.

Depends on how much you care about the absolute phase.

Some bars have breathalyzers today.

Cheers

Phil Hobbs

And unique pointers also have no overhead as compared to raw pointers. They enforce ownership at no cost.

For bare-metal programming on small ARM processors without managed memory you often have no choice but to resort to raw pointers but something like a std::observer_ptr, a non-owning pointer, would be nice.

Storing raw references in classes and structures is problematic when you add in move construction and assignment, same with const-qualified raw pointers. Returning qualified raw pointers from functions and passing them into classes/constructors is prickly, too. std::reference_wrapper makes a raw reference move-able but a reference isn't always what you want since it assumes the object it refers to is "alive"

Something like that may exist. Wouldn't be too hard to write one I guess.

Another thing I do is when array-like data doesn't require very fast access I store it in a List class, and the data is accessed via iterators rather than manipulating the underlying array directly.

Array indexing errors are the source of a lot of bugs, sanity-checking access to the underlying array is a good thing whenever you can afford the overhead.

Phil Hobbs wrote in news: snipped-for-privacy@electrooptical.net:

About 9 years ago I saw a news item on TV showing a UK bar giving alcohol to people by way of vapor infusion. Instant buzz, no ingestion required.

Never saw them show up here in the us.

I guess they would be called Breathabuzzers.

Wow. Sounds horribly frustrating. Thanks for the deatiled write-up.

There are quite a few similarities with our first product, which measured blood oxygen saturation. We had a very steep learning curve, if I'd known about your book at the time we could have avoided some of the worst blind alleys.

For oxygen saturation the wavelength region of interest is right in the middle of the visible, so rather than a mechanical monochromator we were able to use a spectrometer with a grating and a linear 2048-pixel silicon CCD array. The spectral data then got fed into a curve-fitting algorithm running on an embedded Windows PC. I wasn't very closely involved with that part, my job was to design the CCD interface. The proof-of-concept used an Ocean Optics USB2000, but the CEO was convinced we could do it smaller and cheaper. Let's just say that didn't turn out quite how he expected...

The team that developed the proof-of-concept, and then sold us the rights, were initially looking at glucose, but oxygen saturation seemed to be a lot easier to get working. There are InGaAs detector arrays available, I take it they weren't suitable for your system?

Yeah, it's better when we all learn from each other.

No huge surprise there. OO is a pretty good outfit, although their hardware is much better than their software nowadays--what with all the fancy programming features, it's amazingly difficult to just turn the thing on and take a spectrum.

They're very expensive, and the ones I know about don't have a lot of pixels. Also I don't think they're available in the extended-wavelength (0.8-1.9 um) variety. It was much cheaper to use more fibres.

Cheers

Phil Hobbs

Hi Phil, In conclusion, we electronics design engineers are trapeze artists who hand-off hardware designs to our team with a certainty.

Software programmers are the Fed Ex handoff folks who throw the software over the fence.

We care. Alan F.

g me

ute,

ector

eeing

ck up

so

he

ere

ng

ced

out

ed

I'm always happy to help the software people. But often they don't like my answers. I had one who was integrating some speech compression software a nd didn't like the sounds he was getting. He used a scope and saw the 100 kHz noise from the class D amp. He started raising a big fuss about the ho rrible noise and would not let go of the bone. Nothing I said about how th at noise was inaudible and likely never made it past the filter of the spea ker cone anyway, made any difference to him. Finally he found the problem in his software.

Another time was about a board with an FPGA that could not be booted. Conf iguring an FPGA is not complex. There are about five things you have to ge t right and it will boot. The trouble is if you mess up any one of them it simply sits there acting like you've done nothing and won't raise the one line that says "programming complete". There's no debugging except to look at what you are doing and get it right.

So I was called to help with the debugging and there were five people at th e bench, one a software manager. Software because the put the FPGA group i n software. So there was the lead SW engineer, an assistant SW engineer (f resh out of school) a software manager, and the same guy who couldn't get h is voice compression to work and blamed it on me doing actual software for this board. In addition they had a FPGA consultant who was making as much as any of the two of us. At first they don't even want to talk to me even though they demanded that I be there.

Eventually I took control and explained how simple booting the thing was an d if each of the five things weren't right, it would not work with no indic ation. So now I list the things and they rattle off of the things they had done to make sure it was working like giving a few extra config clocks to complete the internal functions and release the FPGA to run. Trouble was w hen they started working on some other issues they were also doing wrong th ey had dropped the extra pulses... So I pointed out that they needed to do ALL of these things and when they did that it worked. I asked if they ne eded anything else and when they said no, I walked away. The manager looke d dumbfounded. lol I guess she didn't have a lot of time on the bench.

I guess my point is that while I was happy working with them, they didn't c all me in until they were so frustrated they couldn't see what they were do ing. They wanted to throw it back over the wall to me.

Nah, I work both sides of that line, and optics and mechanics as well. There's lots of praise and blame to spread around.

In the blood project, the CE's problems showed up mainly on the hardware side, but the real trouble was a vicious circle of incompetence and a bad attitude. That's seriously hard to fix.

Cheers

Phil Hobbs

g me

ute,

ector

eeing

ck up

so

he

ere

ng

ced

out

ed

Probably a misreading.

There are good engineers on both sides of the hardware/software divide, but not all that many of them.

A lot of the job is getting the less good engineers to raise their game. "N ot invented here" gets in the way all too frequently.

Some of us do, but so do some software engineers. The problem is that most developments are team efforts, and some parts of the team can be weaker tha n others (and the weaker members of team tend to be more confident about th e correctness of their work than the stronger members, who have better gras p of the myriad ways that things can go wrong).