The parts just arrived. Yay!
Building transducer as we speak. It'll be a few days till I have final results.
But at leas I have some real work to do now.

Out of curiosity what form does the transducer take?
Max.

 

Out of curiosity what form does the transducer take?
Max.

The transducer is a <REDACTED>.

Thanks for playing!

 

The transducer is a <REDACTED>.

Thanks for playing!

Please don't tell me, Joey ... I don't want to die!

 

Some metrics on my cooperative multitasking framework:

1. CPU utilization -- just for floating point operations -- is currently about 80%.
2. Average main loop time: ~150uS.

What this means is that, while I am utilizing more than 80% of the TInsts for useful work, each task still gets to execute, on average, once about every 150uS (or 300 instructions at 8MHz).

Pretty damn good in my book.

The framework will allow close to 100% utilization before tasks begin to get skipped -- but they get skipped gracefully.

 

Oops.

I forgot my data processing state machine has a state that waits for some data to become available before continuing the signal processing chain. No floating point operations are occurring during that time.

Accounting for that, I am at 45% CPU utilization, not 80% as stated above.

 

Okay! Things are starting to work.

So far the performance is better than expected.

 

I am happy to announce that, so far, the new transducer is a resounding -- freakin' awesome -- success.

Now I've got to wrap up my code and start the long slog of long-term drift & accuracy testing, and durability.

But, for now...

 

I am happy to announce that, so far, the new transducer is a resounding -- freakin' awesome -- success.

Now I've got to wrap up my code and start the long slog of long-term drift & accuracy testing, and durability.

But, for now...

Joey ... I assume that eventually you're gonna launch it to market, and tell us what it is? What's that gonna take, a couple of years?

 

Joey ... I assume that eventually you're gonna launch it to market, and tell us what it is? What's that gonna take, a couple of years?

When you visit Florida, I'll buy you a beer and show you what I do.

 

When you visit Florida, I'll buy you a beer and show you what I do.

I'll take your word for it...

 

Nice, thanks for sharing

 

Final code wrap-up is done.

Code size: 16,162 lines of .asm code over 28 .inc files and 35 .asm files, and 20,293 bytes of program memory used.

Testing is going perfectly. So far, all systems go.

 

Topic: Digitally filtering large values...

In this post, I illustrated a simple RC IIR filter implemented as a macro using my floating point library. As written, it processed the samples as 32 bit floats.

My app involves numbers greater than 1M, with a few decimal places of resolution. I was short-sighted in forgetting that 32 bit floats provide only 24 bits of precision in the mantissa, giving ~16M distinct values for a given exponent.

Obviously, trying to compute a filter output with a small alpha <0.01 is going to cause precision problems. I discovered my mistake quickly.

The problem was easily solved by switching to 56 bit doubles which are handled natively in my library.

Now, I've perused the various C floating point libraries, and they seem to be limited to 24 bit single precision floats and 32 bit double precision floats.

What would I have had to do if I wrote this entire project in C, only at the end to discover I needed more precision?

 

Potential customer for the new sensor is highly impressed.

 

Potential customer for the new sensor is highly impressed.

And how big would the market be?

 

And how big would the market be?

Bigger than mine.

 

Bigger than mine.

So it would more than duplicate what you're currently selling right now?

 

So it would more than duplicate what you're currently selling right now?

Potentially. But that could take years.

One has to take a long view on these things. It's one of the reasons I left corporate America a hundred years ago.

I got tired of worrying about quarterly performance when the work I was responsible for wouldn't show up on the books until much later in the future (and completely disconnected from my efforts) .

Under that model, engineering just looks like an unavoidable current expense, not the future success of the company that it really is.

 

Under that model, engineering just looks like an unavoidable current expense, not the future success of the company that it really is.

I agree ... some companies treat their engineering departments as if they were just a bunch of accountants ... no offense to accountants, but their work is not visionary nor creative ...

 

I agree ... some companies treat their engineering departments as if they were just a bunch of accountants ... no offense to accountants, but their work is not visionary nor creative ...

Watch it! I've run across some highly creative accountants.

At least one of them is in jail right now.