Needing more than a spark test?

[rabler]

@WobblyHand, thanks, I ordered a couple for testing.

 

[homebrewed]

https://www.pjrc.com/store/display_ili9341_touch.html Get the 3.2" one, it is $18. The 2.8" one is $16.
HTH.

That's much less than Adafruit's offering. Next time, if I need another one for something I'll buy from PJRC. I noticed that they currently have more T4.0 and T4.1's in stock. I may spring for a 4.1, mostly for the additional GPIO's.

Awhile back I bought one of their LC controller boards. I put it somewhere so "safe" that I can no longer find it!

 

[WobblyHand]

That's much less than Adafruit's offering. Next time, if I need another one for something I'll buy from PJRC. I noticed that they currently have more T4.0 and T4.1's in stock. I may spring for a 4.1, mostly for the additional GPIO's.

Awhile back I bought one of their LC controller boards. I put it somewhere so "safe" that I can no longer find it!

Yes, it is. It's resistive, but perfectly adequate for the job. PJRC has some really nice libraries for the ILI9341, they can update the display pretty quickly. I'm using the PJRC ILI9341 and a Teensy 4.1 in my ELS. I'm glad I chose the 4.1, lots more IO, which is really good for beginning a project.

Speaking of displaying FFT data, I did this on a ILI9341 breakout board from Adafruit for my doppler chronograph. FFT displayed in dB's. Lines on graph are every 10 dB. Automatic detection of a tuning fork. A = 440 Hz, converted to speed at X-band. (10.250 GHz ISM band). Display is only 320 pixels wide, but the 512 points are mapped to 320. 1K FFT sampled continuously at 60KHz (DMA), using ping pong buffers. The FFT's never stop. Get FFT results and detections every 17.05ms, (58.65 Hz) but results are only displayed if there is a target detection. Using it to chronograph pellets. With the Adafruit libraries, I am limited to a 6 Hz screen update rate. The PJRC libraries allow significantly higher data rates. Another reason to use the PJRC display.

As you can see, I am trying to box it up. Totally screwed up the USB connector location, and for that matter, the box wall thickness. Don't have enough room for inserts without blowing out the walls. Hey, I'm new to this 3d printing and design...

 

[homebrewed]

Yes, it is. It's resistive, but perfectly adequate for the job. PJRC has some really nice libraries for the ILI9341, they can update the display pretty quickly. I'm using the PJRC ILI9341 and a Teensy 4.1 in my ELS. I'm glad I chose the 4.1, lots more IO, which is really good for beginning a project.

Speaking of displaying FFT data, I did this on a ILI9341 breakout board from Adafruit for my doppler chronograph. FFT displayed in dB's. Lines on graph are every 10 dB. Automatic detection of a tuning fork. A = 440 Hz, converted to speed at X-band. (10.250 GHz ISM band). Display is only 320 pixels wide, but the 512 points are mapped to 320. 1K FFT sampled continuously at 60KHz (DMA), using ping pong buffers. The FFT's never stop. Get FFT results and detections every 17.05ms, (58.65 Hz) but results are only displayed if there is a target detection. Using it to chronograph pellets. With the Adafruit libraries, I am limited to a 6 Hz screen update rate. The PJRC libraries allow significantly higher data rates. Another reason to use the PJRC display.

As you can see, I am trying to box it up. Totally screwed up the USB connector location, and for that matter, the box wall thickness. Don't have enough room for inserts without blowing out the walls. Hey, I'm new to this 3d printing and design...
View attachment 429890

A tuning fork isn't a bad way to go if you don't have a good signal generator. I recently bought a cheap DDS based sig gen that claims resolution down to the micro-hertz level. I have a potential application that actually will benefit form that kind of resolution but for most folks it's overkill.

I read your thread describing your efforts to package your chronograph in a 3D printed enclosure. Sounds like you're learning a lot there!

 

[WobblyHand]

A tuning fork isn't a bad way to go if you don't have a good signal generator. I recently bought a cheap DDS based sig gen that claims resolution down to the micro-hertz level. I have a potential application that actually will benefit form that kind of resolution but for most folks it's overkill.

I read your thread describing your efforts to package your chronograph in a 3D printed enclosure. Sounds like you're learning a lot there!

It's good enough to calibrate a police radar to give you a traffic ticket. It's what the manufacturer uses, which is good enough for a judge! This is X-band, I don't have any known good RF sources. One could multiply up the DDS or phase lock it to get that, but it's not necessary for a calibration. The fork is more than good enough. If I used an external source I would have to phase lock it to the radar and then generate an offset signal say 10 KHz away. This is a colossal PIA in a simple home lab. I used to do it a work all the time, but I had access to 500K Microwave and MMW synthesizers.

Been having fun doing the packaging! Shorted out my main LDO regulator somehow. Repaired it and got it running again. Going at another spin of the case. Relocated the holes, thickened some walls for the inserts, and hopefully got the USB port located a little better. Will be printing Rev3 tonight and tomorrow. With any luck it will be a lot closer, and maybe good enough.

 

[homebrewed]

Are you holding a vibrating tuning fork in front of the module? If so I dispute the velocity detection as being definitive. If the position of a tuning fork tine is equal to A * sin(2*pi*r440*t) then velocity is equal to A * 2*pi*440 * cos(2*pi*440*t), the derivative of position WRT/time. Doppler shift isn't going to work out very well for that, particularly since A is an exponentially decreasing function == continuously changing velocity. Then there is the continuously changing velocity due to the cos() term.

I also note that the free air wavelength of a 10GHz signal in cm is equal to 3e10/10e9 = .3 e1 = 3cm so the sub-mm vibration of even a hard-struck tuning fork wouldn't seem to be enough to produce much of a phase shift in the transmitted vs. received signal, if THAT is what's going on. But maybe it IS enough??? I admit to being confused about what really is being detected here. I suspect the relationship is more ad-hoc rather than having a strong theoretical basis: and if I was a lawyer with some technical background might be able to throw some sand in the works.

How is that tuning fork being used? When you mentioned it I thought you were injecting the tuning fork's signal via a microphone but that doesn't seem to be the case.

 

[WobblyHand]

Are you holding a vibrating tuning fork in front of the module? If so I dispute the velocity detection as being definitive. If the position of a tuning fork tine is equal to A * sin(2*pi*r440*t) then velocity is equal to A * 2*pi*440 * cos(2*pi*440*t), the derivative of position WRT/time. Doppler shift isn't going to work out very well for that, particularly since A is an exponentially decreasing function == continuously changing velocity. Then there is the continuously changing velocity due to the cos() term.

I also note that the free air wavelength of a 10GHz signal in cm is equal to 3e10/10e9 = .3 e1 = 3cm so the sub-mm vibration of even a hard-struck tuning fork wouldn't seem to be enough to produce much of a phase shift in the transmitted vs. received signal, if THAT is what's going on. But maybe it IS enough??? I admit to being confused about what really is being detected here. I suspect the relationship is more ad-hoc rather than having a strong theoretical basis: and if I was a lawyer with some technical background might be able to throw some sand in the works.

How is that tuning fork being used? When you mentioned it I thought you were injecting the tuning fork's signal via a microphone but that doesn't seem to be the case.

No microphone what so ever. The tuning fork causes the reflected phase of the RF signal to be shifted by the movement of the tine towards or away from the radar. The rate of change of the phase d phi / dt is the frequency (velocity) by definition. Say there's a movement of 0.1mm, that is a phase shift of 0.1/30 * 360 degrees = 1.2 degrees. 440 Hz corresponds to dt = 0.0023 seconds. So dphi/dt = 1.2/0.0023 = 521 Hz, which is a pretty big quantifiable number. If you recall, the doppler frequency is given by fd = -2 * vr / lambda. For fc = 10 GHz, there are 66.7 Hz per meter/sec of velocity. So for this rough example, the velocity would be 521 Hz/ ( 66.7 Hz / m/sec) = 7.8 m/sec, or about 25.6 feet per second.

You might want to reconsider that court challenge. The tuning fork creates a doppler return which is accurately measured by the radar set. It is fortuitous that such a simple instrument can be used to calibrate a complicated system. A lot cheaper than a synthesizer!

Radars are very good at detecting vibrating objects, IF the vibration is relative to the radar. If the relative velocity is zero, ie perpendicular to the radar, then there is no doppler. Then we use ranging

There are some radar chronographs that use microphones to start the FFT. I didn't want that, because they can be falsely started.

Probably be good to wander back to your original content... Don't want this thread to wander too far!

 

[homebrewed]

Yeah I agree, time to get back to shooting x-rays at stuff .

 

[graham-xrf]

Analog = Linear Technology = Maxim
It seems that Analog has "integrated" maximintegrated.com.

Aside from that now, there is Analog, and not very much else when it comes to analog stuff, one wonders if this means we soon get LTSpice models for Maxim parts?

 

[WobblyHand]

Analog = Linear Technology = Maxim
It seems that Analog has "integrated" maximintegrated.com.

Aside from that now, there is Analog, and not very much else when it comes to analog stuff, one wonders if this means we soon get LTSpice models for Maxim parts?

I hope so. LTSpice is a pretty good simulator. Designed and simulated a 7 pole Chebychev filter with it and it got me really close. Only thing that was way off were the bias currents. Some detective lab work fixed that.