Needing more than a spark test?

WobblyHand said:
The Adafruit break out display can be powered by either 3.3V or 5V. My chronometer uses the 5V option, so I don't draw current on a Teensy regulator. Should work the same, I think we have the same displays.
Click to expand...
If the display controller's SPI logic levels remain fixed at 3.3V that's doable. Documentation of that nature for the Adafruit display seems to be nonexistent. Their "data sheet" for the display is nothing but a mechanical drawing.
 
It's good to be cautious. I'm using that display with a Feather M4 Express board for what it is worth. In that case, I regulated a 6.4V battery to 5V. That powered the M4 Express and the display. The M4 has 3.3V I/O. The M4 outputs like SPI controlled the display. You could separately power the display and measure the inputs and outputs.

You've hit upon a peeve of mine about documentation. Seems that the "Maker area" is weak on documentation and Adafruit follows that trend. Really makes it a more difficult for true makers, like HM folks, who come from backgrounds that are expecting actual documentation, in all three dimensions, and actual data sheets with content. If it's a simple breakout board, sometimes one is pointed to a vendor part number. They are peddling incomplete products and are expecting the users to figure it out themselves, in exchange perhaps for lower product cost. Seems to be the nature of the beast these days. My approach is to use this stuff perhaps for one ofs. I don't think I'd ever attempt a product, with the Adafruit's of the business since there's scant evidence that these kinds of products have sufficient configuration management to support a product based on them. PJRC seems to take this a little more seriously, and supports businesses that use PJRC products. That being said, their documentation is not much better than Adafruit's.
 
Here's a photo showing the TFT in operation. It's been quite awhile since I've written pixel-level computer graphics code so it took an embarassingly-long time to get the relatively simple code working right. The biggest hangup was correctly addressing the need to plot about 70 data points (about the number of samples I may get per detected x-ray pulse) while fitting them into 320 horizontal pixels.

I _am_ at the 4 day point into Covid so I'll use that as an excuse :) The anti-viral that's available for it is amazing but....I still have a low grade fever, for me at least. Fully vaxxed/boosted but that clearly is not a guarantee.....

Adafruit TFT.JPG

To get this display orientation to look right I called tft.setRotation(3). That's using the Adafruit graphics libraries.

I like this little display. I think I will find lots of uses for it.
 
WobblyHand said:
It's good to be cautious. I'm using that display with a Feather M4 Express board for what it is worth. In that case, I regulated a 6.4V battery to 5V. That powered the M4 Express and the display. The M4 has 3.3V I/O. The M4 outputs like SPI controlled the display. You could separately power the display and measure the inputs and outputs.

You've hit upon a peeve of mine about documentation. Seems that the "Maker area" is weak on documentation and Adafruit follows that trend. Really makes it a more difficult for true makers, like HM folks, who come from backgrounds that are expecting actual documentation, in all three dimensions, and actual data sheets with content. If it's a simple breakout board, sometimes one is pointed to a vendor part number. They are peddling incomplete products and are expecting the users to figure it out themselves, in exchange perhaps for lower product cost. Seems to be the nature of the beast these days. My approach is to use this stuff perhaps for one ofs. I don't think I'd ever attempt a product, with the Adafruit's of the business since there's scant evidence that these kinds of products have sufficient configuration management to support a product based on them. PJRC seems to take this a little more seriously, and supports businesses that use PJRC products. That being said, their documentation is not much better than Adafruit's.
Click to expand...
I agree 100% with your observations. The majority of hobbyists served by Adafruit and the like don't seem to understand or value the goodness that really complete documentation brings to the table. I think if their customers demanded it things would be different. Operations like PJRC (and likely Adafruit) probably have just a few really technical people and their time is spread out over many products so something has to give, eh?

But the lack of good documentation must surely limit their penetration into markets where customers are accustomed to paying more for well-documented products. Sort of a nasty feedback cycle because less money coming in = less support. I suppose for folks like us we have to grit our teeth and take what we get.
 
homebrewed said:
Here's a photo showing the TFT in operation. It's been quite awhile since I've written pixel-level computer graphics code so it took an embarassingly-long time to get the relatively simple code working right. The biggest hangup was correctly addressing the need to plot about 70 data points (about the number of samples I may get per detected x-ray pulse) while fitting them into 320 horizontal pixels.

I _am_ at the 4 day point into Covid so I'll use that as an excuse :) The anti-viral that's available for it is amazing but....I still have a low grade fever, for me at least. Fully vaxxed/boosted but that clearly is not a guarantee.....

View attachment 430741

To get this display orientation to look right I called tft.setRotation(3). That's using the Adafruit graphics libraries.

I like this little display. I think I will find lots of uses for it.
Click to expand...
They are quite handy displays. Although they are small, you can convey a bit of information.

Sorry to hear about your catching COVID. Your excuses are accepted. :) Actually, you've done very well for starting out and being sick. It took me quite a while to get my chronometer display graph to be presentable.

Doing grid lines, axes and graphing are tough the first time. Auto scaling is fun as well. You'll get thinking about that after clipping or having the display do unexpected things.

I don't know the dynamic range of the expected signals, but for the chronometer I had to convert the Y axis to dBs to see everything, since the dynamic range of signals was more than 60 dB. You just can't see the noise floor, all the little stuff and large signals at the same time without dBs.
 
The expected data range is the resolution of the ADC used. At the moment I'm using the T4"s built-in ADC, set to 12 bits resolution so to display full-scale signals it is necessary to multiply the ADC result by 240/4096 -- at least, if you want to use the display in the landscape mode. Since I'm immediately converting the ADC value to a floating point in the ISR that's trivial.

Scaling data to expand lower-level signals will run the risk of clipping higher amplitude signals, but at this point I'm mostly interested in using the display to debug the pulse processing code. I may just auto-scale each pulse so it fits, since I'm currently interested in finding the actual start and end of each pulse.

The power supply for my most recently-acquired Linux computer for lab work just died. I mean that literally, like 45 minutes ago. Sucks. I unplugged & re-inserted the power cord at the socket and brick (the computer side is a hardwired connector), no joy there. Banged on it to hopefully reconnect a bad solder joint somewhere. No joy there. I have a replacement on order but given the season it won't arrive until after Christmas. I _could_ pay a bunch more to get it sooner but I'm teed off & refuse to pay any more than necessary. I'll do something else for a little while. God knows I have plenty of projects to keep me busy!
 
  • Sad
Reactions: rwm
Sorry to hear of the demise of the power supply. It happens. My laptop keyboard is dying, so I can sympathize.

Re: dynamic range. With some radars FFTs are used, and they can extend the dynamic range of the system, at least if you have decent ADCs. As I understand it there won't be any FFTs used for this application, so no process gain there, all one gets is the ADC. Even so, 10 or 11 bits is still 60-66dB. If it was me, I'd plot in both linear and dB and see which conveyed more useful information. Might see some info near the noise floor that would be invisible in a linear scale. Even if it is power supply issues, like supply modulation, it is useful to find, so you can eliminate it from your design. I have observed in systems, current variations due to processing get put onto the signal waveform.
 
I found a few papers discussing pulse analysis using FFTs. My impression (perhaps incorrect) was that the claimed improvement in effective SNR is due to the fact that each term of the FFT is derived from the entire time-domain-based data set. In essence, averaging-out the noise (assuming it isn't correlated to the pulse, which is a reasonable assumption). Calculating the area of the pulse will accomplish something very similar but with much less computation overhead.

I think this type of per-pulse processing -- calculating the FFT or something like integrating the pulse -- should produce a noticeable improvement in the XRF spectral data. Since my pulse-processing code will output both the peak and integrated pulse values it should be easy to compare those two approaches.
 
FFTs reduce the noise by having multiple narrow band filters. They cost N*log(N) computations. You can do things like pulse area integration to help, instead of an FFT. However, a 1024 point FFT reduces noise power by 1024, where as integrating 10 points gives only a factor of 10 in the pulse, but doesn't reduce the local noise nearby. The FFT does that automatically. However, sometimes an FFT isn't appropriate.

The better choices become more obvious when you have access to data. It depends on the nature of the inputs. Think you have a good approach for now, just need to see where it leads you. Simple is good, especially in the beginning, loads easier to debug and get some further insight. If required, then increase the complexity of the processing.

Hope it never escalates to SVDs, although that might be fun on a Teensy. An SVD has an unusual property of decomposing inputs into a signal space and a noise space. It's used in the ESPRIT algorithm. Head splitting linear algebra, I'm afraid, but very powerful under some circumstances. Probably have to compile LAPACK to use it.
 
You must log in or register to reply here.
Back
Top