Needing more than a spark test?

[homebrewed]

While in the process of getting some higher-resolution spectrums to evaluate my XRF setup I now seem to have some sort of programming problem -- the Teensy code hangs at random times into the pulse acquisition process. The problem may be some sort of buffer overflow issue in my code, or perhaps a clipping problem in the TFT library code. I'm in the process of adding code here and there to flash LEDs attached to some otherwise unused digital pins so I can get a better idea regarding where the code is hanging up.

So far I haven't found a smoking gun.....

 

[graham-xrf]

While in the process of getting some higher-resolution spectrums to evaluate my XRF setup I now seem to have some sort of programming problem -- the Teensy code hangs at random times into the pulse acquisition process. The problem may be some sort of buffer overflow issue in my code, or perhaps a clipping problem in the TFT library code. I'm in the process of adding code here and there to flash LEDs attached to some otherwise unused digital pins so I can get a better idea regarding where the code is hanging up.

So far I haven't found a smoking gun.....

That's a tricky one. A hang at random is tricky to catch in the act.
In every small compute code I ever did, I always kept the "heartbeat".

It is true that the 32-bit processors, and other types I got into did not have the power of SBCs like a Teensy, or a Pi, but there was always the "cycle", where a certain fraction was always running essential housekeeping code, and a remaining time within the cycle for user code. If the cycle was 10mS or 5mS or 2mS, that was fast enough for programs to seem "instantly responsive", at least for interface. Yes indeed, I would have high priority interrupts to deal with, and put away stuff that had to happen at high speed, but the time through it's route was so instantaneous, it never threatened the cycle.

The "heartbeat" was a very low impact little thing that would execute each cycle, counting up a sufficient delay to flash one IO LED slowly, and with a longer OFF time than ON.

Eventually, I took to giving specific program segments a "heartbeat" of their own. Without this, a little computer looks very much much like when it is switched off, except perhaps for the "+5V is here" red LED. When the LED is flashing, you immediately know lots of stuff, mainly that it is alive, has a clock running, and that it is executing tons of code just to go around it's cycle!

Having a heartbeat for code segments, supposedly to let me know which had hung up, proved less useful than I had thought. Reasonable breakpoints, and adding in bits of code in program segments to make output with diagnostics worked rather better. I even had code where the amount of "commented out" diagnostics exceeded the amount of working stuff. Even so, looking at three LEDs winking away did have a nice positive sychological effect on the mood. Utterly useless when they wink away, and the code is still crashing!

I admit - I am not very good at "programming" ! :|

 

[WobblyHand]

While in the process of getting some higher-resolution spectrums to evaluate my XRF setup I now seem to have some sort of programming problem -- the Teensy code hangs at random times into the pulse acquisition process. The problem may be some sort of buffer overflow issue in my code, or perhaps a clipping problem in the TFT library code. I'm in the process of adding code here and there to flash LEDs attached to some otherwise unused digital pins so I can get a better idea regarding where the code is hanging up.

So far I haven't found a smoking gun.....

Go back a version... This is why using git or some software configuration management like it is so valuable. Or perhaps you could use meld, or a similar program to find differences in files? It stinks when stuff blows up on you. It's why I use git on any SW that is longer than two screens. Of course, one has to be disciplined enough to regularly commit changes - otherwise you have to backtrack a long, long way.

I have had to flash leds before to find problems... I would put a scope probe on the points and see if the timing looks "normal" or what you imagine it should look like. Sorry that stuff blew up, it happens.

Edit: I am also not such a good programmer, which is why I learned about the value of a tool like git. My ELS software that I wrote is in git. It's a darned good thing, because I broke my SW quite a few times along the way.

 

[graham-xrf]

Mark will figure out the code. My interest is aroused over what makes "higher resolution" spectrums!

 

[graham-xrf]

I have calculated the potential current consumption of the ADC, and the reasonable count of of op-amps (up to 9). It comes to 168mA.
That's quite a lot, though I think it can be stolen from the Pi.

The thing is, at 16mA per amplifier, that makes 144mA. My negative supply has to have more cahunas than likely from a little charge pump bias circuit. I will have to just go for it, and put in lowest noise, high frequency, bonkers filtered little PSU, and rely on the PSRR. Apparently 95dB, so this should still work.

 

[homebrewed]

Mark will figure out the code. My interest is aroused over what makes "higher resolution" spectrums!

It's just the "width" of the MCA bins. My MCA library allows me to set an energy window, which will come in handy considering that low-energy noise "peak" -- I can just clip that off. No magic energy-resolution improving approach. That would be nice.

So I guess it really isn't making higher resolution, more like a zoom. Sorry to raise your hopes!

Most of the code is OK because I've let it run overnight just to see if anything blew up -- and it didn't.

 

[homebrewed]

Go back a version... This is why using git or some software configuration management like it is so valuable. Or perhaps you could use meld, or a similar program to find differences in files? It stinks when stuff blows up on you. It's why I use git on any SW that is longer than two screens. Of course, one has to be disciplined enough to regularly commit changes - otherwise you have to backtrack a long, long way.

I have had to flash leds before to find problems... I would put a scope probe on the points and see if the timing looks "normal" or what you imagine it should look like. Sorry that stuff blew up, it happens.

Edit: I am also not such a good programmer, which is why I learned about the value of a tool like git. My ELS software that I wrote is in git. It's a darned good thing, because I broke my SW quite a few times along the way.

I'm keeping older code so I can back up to a working version if I need to. The "hang" is a little mysterious because I let a slightly older version of code running overnight and it ran just fine. I'm wondering if the problem was there all along but one or more of the operating settings I'm currently experimenting with are exposing it.

So far it looks like the problem isn't due to some issue in the TFT display library code. Early on I discovered that I couldn't use the on-board LED for diagnostics because it is used as the SPI clock. If I tried doing that the TFT library code WOULD hang, probably because the SPI interface went to la-la land.

 

[homebrewed]

Just to back up a little from my current problems, I want to mention that I was able to pretty much eliminate the signal originating from the Am241 sources. I cut a piece of 1/16" thick lead sheet and punched a hole whose diameter matched the preexisting hole in my aperture plate, then taped it into place. The added shield thickness around the aperture hole seemed to do the trick. There still is a low-amplitude peak but its energy is different. I think it may originate from either the aluminum enclosure or perhaps the steel screws used to assemble the enclosure. I ran into the program-hang problem when trying to characterize aluminum and steel so I could figure out what I can do to reduce the background counts even more.

I suspect my current setup is doomed to have some low-level background spectrum so it may be necessary to do something like subtracting a background spectrum from ones obtained from samples of interest. This approach isn't without its "interesting" aspects, since a sample will block Am241 gamma rays so the effective background could well change. So the jury is out on this one.

 

[WobblyHand]

Another fool? bought the Pocket Geiger. @homebrewed what did you end up using on the Pocket Geiger board? I think you replaced the TIA, but I don't recall your final bits and pieces. Do you have a current marked up "working" schematic? I have a spare ELS PCB with a Teensy 4.1 and display pre-wired that I can hack. Might help me get up and running, I hope. Have some old smoke detectors that haven't been discarded (I think).

 

[homebrewed]

Another fool? bought the Pocket Geiger. @homebrewed what did you end up using on the Pocket Geiger board? I think you replaced the TIA, but I don't recall your final bits and pieces. Do you have a current marked up "working" schematic? I have a spare ELS PCB with a Teensy 4.1 and display pre-wired that I can hack. Might help me get up and running, I hope. Have some old smoke detectors that haven't been discarded (I think).

Give me a day or so to work up what I did. My current marked-up schematic has some stuff that's specifically related to the enclosure that I made -- the DIN connector's pinouts I used for the power supply stuff and pulse output to the Teensy. It also doesn't have anything regarding my replacement of U1, U2 and removing U4 (the boost regulator).

Based on what I'm seeing w/regard to low-amplitude noise it may not be necessary to replace U1. It's likely that noise coming out of the PIN detector is larger than the amplifier's voltage and current noise so there's not much to be gained there.