|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
Well, I've spent the entire week getting deeper and deeper into Digital Signal Processing. What a complex arena this is. I've actually had to go and buy a book on Calculus to understand much of the documentation. It was either that or call Richard and admit he's smarter. Aside from that being exceedingly unmanly, it wouldn't have helped because I didn't even know the names of the symbols to describe to him what I was reading. I'd have had to scan pages or describe things as pictures.
After some really heavy reading and coding, I now have an accurate signal processor which handles a range from around 20hz to as much as about 22khz with a step rate of about 10hz -- giving me valid frequencies +/- 5hz which is fine for most signaling. I can make it much more accurate and/or much more narrow or wide by changing a few constants; and more important, I understand why changing those constants will change the scale. I'm evening using a "Blackman" window (one kind of Window-Sync Filter) to prevent aliasing caused by the nature of taking a frame from a continuous signal.
What started as strictly focused on one particular need -- audio processing -- has become much more general knowledge. Since I now know how to interpret impulses from hardware devices to examine any number of properties, I also know how a transmitter, receiver, and amplifier work. This should help me build some of the stuff I've always wanted. If this interests you and want to learn how to do it, there's a fantastic book on the subject, called "The Scientist and Engineer's Guide to Digital Signal Processing" by Steven W. Smith, Ph.D. You can download and read chapters of the book one at a time in PDF (yes, the whole thing) or order it online. I've used it so much that I've decided to order it. There is so much more in it to learn on other subjects. I can't wait to explore neural networks.
Another side benefit of all this work, has been that I've spent serious time now working in both Visual Studio.net (mostly VB.net) and Eclipse (Java). I've done enough now that I can compare working with them, so I'll do that in another blog entry not too long out. I've been surprised by both. I will say that Microsoft's documentation is horrendous, immature, and hopelessly tangled.
Now, onto the list of things that annoy me. First, understand that with Barb and the kids gone all week and me with my head deep in complex programming, nearly everything annoys me. That said, a few things bubble to the top. These are not in any particular order.
When someone wants to borrow something, they call and ask if they can borrow "THE" whatever. If they eschew the word "YOUR" and replace it with "THE" do they believe that this somehow increases their chances of getting a yes? If I was going to say "No" in the first place, this little bit of mealy mouthed manipulative denigration of ownership and importance will change nothing. It will annoy me however.
When someone has a home office and makes no secret of it, its not unexpected that sometimes if you call them they'll have kids running around. This is especially true if you call without any warning or appointment. True, it would be less rude to just let the call drop to voicemail and call back when you have the time, but OK -- it happens. If on the other hand, you are going to call and interrupt someone else from your home office it is extremely rude to do so while holding a yelling infant. Its not like you didn't have the infant in your lap when you made the call. Its a home OFFICE not a day-care without computer. If you are conducting business from home, please spare me the need to hear your children screaming into my ear -- particularly when you've placed the call in the first place.
If you call someone and ask if they have "a minute" -- a yes response does not equate to an acceptance of an instant conference call, a long discussion, or a heavy support request. If you need "an hour" than for the love of God ask for "an hour" and not "a minute".
When you call someone, decide what you are going to say BEFORE you dial. Not in the general sense, but in the specific. In firefighting, we use the expression "Key the mic with your brain first, then your thumb." Along the same line, don't call me on your cell phone and then once you make the connection figure out that you can't talk and hand the phone to someone else. In general, if I have to sit and listen to dead space while you figure out what to do with the phone, its annoying. You called me. How is this a problem?
Finally, if we're on the phone, talk to me. Don't stop talking to me and go deal with other things while I sit there and listen. If you need me to hold on, say "hang on" or something. If you can't take the few minutes to focus on our conversation, ask to reschedule the call.
Please wait while your document is saved.
about in thr first place.
Just what you need when you're rebuilding a server or something.