Needing more than a spark test?

WobblyHand said:
I think it's a bit of misinformation to state that python is always slow. If you use the numpy and scipy libraries it isn't. It's at least as fast as Matlab. Both those libraries are vectorized and have been optimized in C++. So like Matlab you can do element by element multiplication or matrix math of any sort, including SVD and stuff like that. (Singular Value Decomposition)
Click to expand...
Indeed, and I agree. It's just that, at least at the fairly humble level I dabble in, the examples of Python code, downloaded, and supposed to work projects one might be making, have suffered from slowness. It was always from poor programming. In my very first sentence, I said that Python can be good, and using libraries that have fast implementations of functions is the skill I was alluding to.

I thought I chose the words carefully, but it seems I should have tried harder. When it came to getting really good programming, it would not be from me. I would get in professionals who could manage high accuracy servo control code good to about 280 milli-arc seconds, at an exact celestial time, with computer clocks using local time servers synced to NIST, and we could rely on a interrupt response within 300uS.

I definitely did not intend the observation to be seen as "disinformation", and I am sorry you thought it so.
 
I have some experience with Python as well. I used it as the data acquisition/plotting side of a home-made spectrometer. It drew heavily on functions available in numpy, pylab (the latter for plotting the spectrum) and a machine vision library. The latter can acquire image frames from a web cam, extract individual video lines and process them. I can (and do) average the pixel data over several frames to improve the SNR. That's the stuff I used to actually grab the spectral lines so the physical spectrometer itself is very simple -- an aperture, a diffraction grating and a webcam.

Using it I can generate spectra like this:

CFL_spectrum.png
This is the spectrum from a CFL. The peaks are very characteristic so that's what I used to calibrate the system. The webcam I used for this plot has a built-in IR filter, which limits its performance -- basically there's nothing down in the near IR region. I have since gotten a "night vision" webcam that has no IR filter but haven't had an opportunity to try it yet.

Going back to the XRF stuff, I wasn't counting on finding or writing code for a realtime serial plotter. The serial interface itself isn't fast enough -- even at 115200 baud the circular buffer wraps around & trashes the pulse data before it can all be sent to the host.

Anyway, I have sort of bypassed the serial plotter. I bought a little TFT display from Adafruit that should be fairly easy to use (so he sez blithely). They have an Arduino library to make it easier to get it up & running so hopefully most of the harder bits are already done.

Another approach would be to use a PWM output as a slow DAC, then view the reconstructed pulse on my 'scope. That would be VERY non-realtime! If I had a Teensy 4.1 I'd have enough digital pins to roll my own DAC using an R/2R ladder but that's not in the cards right now.
 
One point I neglected to mention is that the limitation of the serial interface really only is significant when trying to debug my code. My plan all along has been to use the Teensy as a pre-processor to send just the relevant pulse information, which would just be 3 values: the goodness of fit, peak voltage and pulse area. This would be on a per-qualified-pulse basis.
 
homebrewed said:
Anyway, I have sort of bypassed the serial plotter. I bought a little TFT display from Adafruit that should be fairly easy to use (so he sez blithely). They have an Arduino library to make it easier to get it up & running so hopefully most of the harder bits are already done.
Click to expand...
Ooh, falling into the rabbit hole I see. That's what I used for my doppler chronograph using a $3 eBay X-band door opener module. I used the display to plot FFT's in dB's. (Linear scale is useless for radar work.) The chronograph would only display upon a detection, which helped with the update rate. The 1K FFT's and detection process ran continuously. I used DMA for the ADC and a pair of ping pong buffers. While one buffer was filling, the other one was the data source for the FFT and detection. Had to time everything so there were no overruns. Was a great bit of fun to do! On a Feather M4, SPI display interface, and the Adafruit libraries, I could do about 6 Hz update rate. Adafruit limits SPI to 24MHz, but the displays can take data about twice as fast. PJRC allows you to set the SPI rate faster. The sample rate was 60 KHz, an FFT and OSCFAR detection and a parabolic estimator was done every 17.05ms continuously. The trickiest bit was the noise estimator, I used a rolling median filter of length 17 to quiet things down to a tolerable level. Length 21 would blow the timing budget, and 19 wasn't much better performance wise than 17.

There was as much code for the FFT display as for everything else... It's not terribly hard, but there's plenty of stuff to do... For my ELS it has been 2X the code for the display and human interface. It's quite rewarding when the displays are up and running correctly, never mind the application.
 
LOL, just started debugging my 20x4 character LCD output this morning on my version 1 (aka prototype) board. Just used one of the common port I2C expanders (MCP23008) and typical schematics so it should be compatible with most of the LCD "shield" libraries, but, still at the get it working stage. I used a second MCP23008 as an I/O expander for buttons and LEDs. 2nd dedicated I2C channel for an A/D converter.

I'm looking at using the wifi interface on some of the newer gumstick modules to get higher output speeds and data logging post FFT.
 
rabler said:
LOL, just started debugging my 20x4 character LCD output this morning on my version 1 (aka prototype) board. Just used one of the common port I2C expanders (MCP23008) and typical schematics so it should be compatible with most of the LCD "shield" libraries, but, still at the get it working stage. I used a second MCP23008 as an I/O expander for buttons and LEDs. 2nd dedicated I2C channel for an A/D converter.

I'm looking at using the wifi interface on some of the newer gumstick modules to get higher output speeds and data logging post FFT.
Click to expand...
After suffering with those sorts of displays, I have given up on them. They work, but convey limited information. If it works for your application, then great.

I went with small pixel addressable 320x240 TFT touch displays for my little chronograph and for my ELS. The interfaces and the info you can display are a lot nicer, but naturally take a bit more work. I think the work is worth it, having done it twice. What's nice after having done it once, you have learned the hard part of doing display work. The second time around, I spent more time designing menus and storyboards, because implementing them had become much easier. Reused some of my old chrony display code to speed up the development of the ELS graphics. Most of the work is just text stuff and locating stuff on the screen and optionally doing processing on soft buttons. Occasionally you can go wild and insert pictures and stuff like that. I somewhat gave up on pictures simply because they became a distraction and I was running out of screen real estate. Designing clear interfaces with a lot of information is an art, especially on small displays. Really focuses you on the essentials.
 
WobblyHand said:
After suffering with those sorts of displays, I have given up on them. They work, but convey limited information. If it works for your application, then great.

I went with small pixel addressable 320x240 TFT touch displays for my little chronograph and for my ELS. The interfaces and the info you can display are a lot nicer, but naturally take a bit more work. I think the work is worth it, having done it twice. What's nice after having done it once, you have learned the hard part of doing display work. The second time around, I spent more time designing menus and storyboards, because implementing them had become much easier. Reused some of my old chrony display code to speed up the development of the ELS graphics. Most of the work is just text stuff and locating stuff on the screen and optionally doing processing on soft buttons. Occasionally you can go wild and insert pictures and stuff like that. I somewhat gave up on pictures simply because they became a distraction and I was running out of screen real estate. Designing clear interfaces with a lot of information is an art, especially on small displays. Really focuses you on the essentials.
Click to expand...
Already have the v1.0 boards fabbed for a character LCD display although I'm targetting the 20x4 display instead of the more common 16x2. Looked at TFT graphics but just stuck with the character display and a rotary encoder for entering numbers/adjusting values. Admittedly clunky, especially the interface. The majority of the TFT displays I saw end up with fairly small characters. Obviously more $$ buys bigger. But I'm not fond of squinting, reminds me that I'm aging.

Ironically I'm in coding mindset, so typing here on HM is painful, I keep resorting to VI editor keystrokes for error correction.
 
rabler said:
The majority of the TFT displays I saw end up with fairly small characters.
Click to expand...
The font size is programmable, so are the fonts. Making a readable display on a small screen does have it's challenges.

FWIW, the screen I am using is $18 in unit quantities. 320x240 3.2" across the diagonal. Good enough for an ELS with DRO. I can display or select 25 threads on a page without scrolling. That's good enough for me. Bonus is the touchscreen, I just press the thread I want, the display shows what I selected and geek parameters (for me :)) and I press the enter button. If I don't quite have enough room for all those characters, I can cheat and use a narrower font! You can have mixed larger and smaller fonts on the screen. Easy as pie, or is that pi?

Can't help you with the squinting part, so update your vision prescription. It will help your coding too! It helps to be able to see what you are doing. :grin:
 
WobblyHand said:
FWIW, the screen I am using is $18 in unit quantities. 320x240 3.2" across the diagonal.
Click to expand...
That's the same size as the LCD display. Hmm. Link to the one you're using?

Readers work fine for coding. I use a weaker lens in the safety glasses, most of the shop work is at a bit more distance. But at 3.2" diagonal, not an issue.
 
Last edited:
You must log in or register to reply here.
Back
Top