Needing more than a spark test?

[WobblyHand]

For now I'm simply discriminating on the pulse width. Pulse overlap = a longer pulse. I was hoping that my 2nd order polynomial fit, performed around the pulse peak, also might help. Presumably a peak caused by the overlap of two pulses won't be as "nice" in terms of the goodness of fit. But, given the noise levels I'm seeing, I'm starting to think that my polynomial fit may not buy me much in that regard. One problem with the fitting routine is that my ADC sample rate is slow enough to limit the number of samples around the peak. I'm using 10 samples at this point. A 1MSPS ADC would more than double that number of samples, plus the ADC resolution would be much better. The Teensy ADC's ENOB is around 10 bits.

Ah, the fitting is kind of a correlation, I think. That might help. Certainly lower computation load.

Its a bummer that the newer Teensy 4.x has only 10 bit ENOB. To be honest though, the 3.x chips aren't hugely better. They might have 10.5-11 bits. Based on my Doppler chronograph, it was about 66 dB dynamic range on an M4. I think Teensy 3.5 is an Arm M4 processor.

 

[homebrewed]

Since the local average can be heavily biased by the energy of a local pulse, you may be inadvertently raising your threshold,

My "low pass filter" code rejects data that exceeds my baseline+noise estimate in an attempt to prevent pulses from affecting the threshold. I long ago figured out that classic analog-based approaches to things (like PID controllers) can be sub-optimal compared to more intelligent methods that can only be implemented in S/W.

But more eyes can offer a different perspective. I just uploaded my latest code to my Gdrive so folks can give it the once-over. Like I said earlier, I think it's rejecting more pulses than it should, so definitely still a work in progress. Here's the link. Anyone who uses the link should be able to access the file.

 

[WobblyHand]

My "low pass filter" code rejects data that exceeds my baseline+noise estimate in an attempt to prevent pulses from affecting the threshold. I long ago figured out that classic analog-based approaches to things (like PID controllers) can be sub-optimal compared to more intelligent methods that can only be implemented in S/W.

But more eyes can offer a different perspective. I just uploaded my latest code to my Gdrive so folks can give it the once-over. Like I said earlier, I think it's rejecting more pulses than it should, so definitely still a work in progress. Here's the link. Anyone who uses the link should be able to access the file.

Appreciate the link. I will take a look in a couple days.

A median filter sort of behaves linearly for stuff that's noise like, practically low pass filter like but rejects high amplitude impulse junk. Sometimes it's a great solution. It's used in many automotive radars. It's rather immune to false biasing and maintains the threshold in the correct place. This results in fewer missed detections. False negatives, we called them. It's not the only technique that can work, but it is rather robust to enormous variation in operating conditions. There are millions of automotive radars using this or related methods for detection. It might work for this application.

 

[WobblyHand]

Forgive me if you already do this, but do you have a software repository set up? Might facilitate development, or at least better manage it. I have done this for my larger home projects. What's nice about this is backtracking or development of advanced features without messing up the main development. I can try out stuff without breaking what works. The software branches are independent of one another.

When I develop over a 1000 lines of code, I don't want to risk breaking it. A repository allows me to backtrack to any point. Of course one has to comment enough on one's changes, but that should be second nature for most. I comment both my source code and my commits because typically I'm the only developer and I don't have anyone else to ask. In a couple of weeks, I've usually forgotten some tricky bits, so I comment profusely. Defensive coding, for myself... Seems to work for me anyways.

 

[homebrewed]

Forgive me if you already do this, but do you have a software repository set up? Might facilitate development, or at least better manage it. I have done this for my larger home projects. What's nice about this is backtracking or development of advanced features without messing up the main development. I can try out stuff without breaking what works. The software branches are independent of one another.

When I develop over a 1000 lines of code, I don't want to risk breaking it. A repository allows me to backtrack to any point. Of course one has to comment enough on one's changes, but that should be second nature for most. I comment both my source code and my commits because typically I'm the only developer and I don't have anyone else to ask. In a couple of weeks, I've usually forgotten some tricky bits, so I comment profusely. Defensive coding, for myself... Seems to work for me anyways.

At this point as I implement major changes I increment the version # and keep the old code so if I break something I can backtrack.

I also comment my code pretty extensively, for pretty much the same reasons.

If this project actually produces some usable results it will be time to get more formal about managing the code so other folks can work on it, too. Perhaps use github or the like. So far I haven't done that for anything I've written, but it really hasn't been written for anyone else but myself. The exception was some graphics and animation stuff I did for the old Atari ST platform. That was in the 80's......and a lot of it was written in Forth.

 

[WobblyHand]

Based on what I am seeing, there will be tangible results. Think you are heading in the right direction.

 

[homebrewed]

Based on what I am seeing, there will be tangible results. Think you are heading in the right direction.

The proof of the pudding is in the eating, as they say .

I'm not in a place where I think what I'm doing is THE right way to do things. Like I have said many times before, we STILL don't have a lot of results so who knows what the final system will be. It's clear to me that you have a lot of experience in dealing with noisy signals: and one of the keys to getting good results out of a cheap xray detector is going to be noise management. I am convinced of that (I think @graham-xrf is, too). I am totally open to suggestions on ways to turn that lemon into lemonade, whether that's S/W or H/W design (most likely both). Based on that, I think it probably IS time to set something up so other folks can mess with the code. Or at least examine it to come up with something that functions the same on different platforms.

But we need to consider the fact that different systems could be fairly different w/regard to overall gain, noise level, bandwidth etc. A well done hardware layer would help a lot. OR: fix things on the hardware level and define the parts so they're affordable for interested DIYers and perform well enough for the task at hand. Again, some vigorous discussion on that side of things is needed.

BTW, congratulations (I think) on posting #1000 in this thread......who'd a thunk it??

#1:

I have some chunks of nice steel, 31mm thick and 120mm x 60mm (about 1.2" thick and 4.7" x 2.3").
The 31mm apart faces are parallel to within a tenth thou, so they are sometimes handy as a sort of fat parallel, but the perimeters are not as in a rectangular block. They have the profile of whatever hydraulic pump kit they were originally destined for.

They don't rust - so not just some nearly tool steel.
They are magnetic, so mostly iron in there.

It seems there is not much between the "spark test" on a grinder, and some expensive kind of analysis.
I can't afford one of those FLIR things which are only cost-effective if they are identifying exotic stuff all all day long.
Trying for density once let me identify a nice chunk of titanium, but I did have some other clues.

Is there some lower cost way of figuring out what is in the alloy?

 

[WobblyHand]

Happy New Years to all the hardy souls that have weathered this epic thread.

Wasn't aware of making the 1000th post, but that's amazing.

 

[WobblyHand]

Just got back from visiting my kids, and have downloaded @homebrewed 's code. Where can I find FastPeak.h?
Will have to look at this in the next day or so. Kind of worn out from 10 hours on the road...

 

[homebrewed]

Just got back from visiting my kids, and have downloaded @homebrewed 's code. Where can I find FastPeak.h?
Will have to look at this in the next day or so. Kind of worn out from 10 hours on the road...

There is a sub-folder inside the XRF drive folder I posted a link to. Drill down to the "src" folder. The link should be here if it turns out the sub-folder isn't shared.

I've been doing some additional debugging and have managed to eliminate most of the "malformed pulses" problem. Unfortunately, it was accomplished using some random experimentation so I still am not certain WHY my code was working that way. Probably another head-slapper when I figure it out .

I don't envy your long drive. The older I get, the less fun that kind of stuff gets. Our most-recent long road trip was an 11 hour drive from my wife's sister's place back home. Yet another wedding. Fortunately it was a little earlier in the season so we didn't have to worry about snow. It helps to regularly switch places between driver and navigator. Fortunate that way.