The STM32 can do a 1024 point FFT in 5ms. There's also the unknown matter of computing magnitude, normalizing, making it probably 10ms. At 10 sweeps per second, that gives only 10 FFTs per sweep.
That comes with a 8192 byte tag.
2048 bytes: analog capture window
2048 bytes: imaginary value window
2048 bytes: simultaneous capturing of next window
2048 bytes: normalization table
Then, the 1st 256 samples from each window are stacked on a polar projection. Only the 1st 1/4 of the window has had useful range. That comes with a 2560 byte tag for the current projection & 2560 bytes for the previous projection for 10 FFT's per sweep. 50 FFT's per sweep would take 12800 * 2 bytes.
Motion tracking in a polar projection would take some doing, but be the most efficient solution. An additional 5120 bytes of ROM might be required for a lookup table to convert the polar pixels to square pixels for motion tracking.
Then, some 1024 bytes of scratch memory might be required, bringing it to 60416 for the 50 FFTs per sweep or 19456 for the 10 FFTs per sweep.
To rotate the FFT's & motion track a square projection would take 256kbytes to retain the full resolution. It would involve a similar lookup table to only track filled pixels.
No matter how limited the microcontroller, the resolution & speed of the sampling can always be scaled down to fit. The difference is only in the resolution of the output, not whether it can...Continue Reading
A static radar antenna doesn't give a consistent reflection pattern as the aircraft pitches & rolls, so it needs to sweep a certain angle so something is always detected as reflections come & go. Exactly what angle to sweep is a matter of experimentation. The worst case is 360' 20 times per second.
Making synthetic aperture radar with hand tools is harder than it looks. The fastest a home made gadget ever spun was 60rpm. To get 20 position updates per second, the required RPM is 1200.
There is the idea of a spinning reflector under a stationary radar. A flat piece of metal in exactly the right position actually directs the radar beam quite well.
It's conceptually simple, but requires an exact 45' miter cut to mount the reflector & the reflector needs to be exactly aligned on a separate jig under the radar. The reflector is huge, moves too much air to spin fast enough, makes a lot of vibration, & decreases the radar power. Errors in alignment from fabrication take away more power.
It can use a very long rod attached to a motor. The rod needs to be exactly parallel to the motor. It couldn't be made by hand tools to spin very fast & would need a large diameter to counteract the vibration & drag.
Another way is a triangle mounted on a pancake motor & the motor mounted on a long rod. It could spin faster.
Making a shaft coupling is still out of reach for hand tools. Mounting something flat on a pancake...Continue Reading
Found the story intriguing. Batteries remane fickle things. Their total charge is still only estimated by stopwatches & coulomb counters, but there is no dip stick for a battery. Even a pilot experienced enough to keep 1 eye on the flight time while the other eye is on the 5000 other details still is often surprised when a battery comes up empty ahead of schedule.
Sometimes you forget to charge batteries. Battery chargers sometimes don't finish charging because they overheat or their own supply sags. Sometimes they don't start charging because of a balky button or a poorly designed user interface. Sometimes they report maximum voltage despite no longer holding a full charge.
A return to launch feature when the battery is low also remanes fickle. GPS comes & goes anywhere besides a wide open field. Is the return to launch feature supposed to count coulombs & maintain a database of every battery's capacity in order to determine when to end the flight? Should the pilot enter in the current battery ID or should the batteries have ID chips, raising the cost & complexity?
It's yet another one of the variables & details that keeping something in the air still involves keeping your mind on. There is still a lot of room in the current state of reliability to keep the price, complexity & training beyond the reach of hobbyists before the personal drone becomes as ubiquitious & hand off as the marketing campaigns depict.
So a phone still can't outdo a dedicated mp3 player for a car. After the Sansa broke again, it was a rough 10 hours of driving, fighting the Android music app & getting mono audio out of its 4 conductor headphone jack.
The problem with lens test patterns is they're all photographs through other lenses & they're all greyscale. A printer can't print greyscale. It can only print halftones which convert your test pattern to dots. So you convert the test pattern to 1 bit & get aliasing artifacts.
The camera used on the 1st Delta IV launch was an el cheapo Sanyo, which could only achieve this quality from the test pattern:
Goog searches for radar are about as useful as goog searches for IMU's were, 7 years ago. They haven't reached the mass consumer usage that it takes for something to yield useful results, but you know radar is going to be the next IMU in every phone.
Notably, he used a bandpass filter as a range gate. Perhaps a range gate filter could knock out reflections in the module itself that saturate the amplifier. He also has example videos of radar images, which are few & far between.
Finally hit the Zoom H2 with the radar output. The Zoom H2 uses the TLV320AIC32, the highest quality ADC in the apartment.
A quick comparison revealed no significant difference in the range of interest.
It turns out while the Zoom H2 records 24 bit files, its ADC documentation never specifies how many bits it records. It oversamples at 128x to fill in extra bits. It seems to convert 19 unique bits. There's a 528 sample section at the beginning of every file where only 19 bits are written.
It definitely can receive reflections from materials other than metal, but not in FMCW mode. In doppler mode, the gain can be increased to 1000x, where it detects wood & body parts. The problem with doppler is it can't detect slow movement.
So the problem with detecting non metallic materials is the gain, which is limited by very a large low frequency component in the signal. It would take an unreasonably sharp filter to cut it off.
Also tried sinusoidal frequency modulation, which made even more low frequency offset.
Finally, a video showing how well the radar works, including its inconsistencies.
The shape of the frequency ramp is the biggest factor in your radar range. Ideally, the VCO would generate a linear frequency ramp from a linear voltage ramp, but this probably never happens. The VCO is an open loop controller, since it has to make thousands of ramps each second.
The following is the most optimum ramp, so far:
Unfortunately, it doesn't agree with the datasheet's voltage ramp. Without a spectrum analyzer, there's no way to get a perfectly linear frequency ramp. There may be a feedback loop in practical systems which adjusts the voltage ramp based on ghosting in the image.
After much kiwipedia graph searching, the nearest function to the nonlinear VCO ramp was:
x range = 0 ... STEPS
y range = 0 ... MAX
y = pow(x * 2 / STEPS, EXPONENT) * MAX / 2;
y = y * curve_weight + x * MAX / STEPS * line_weight;
The magnitude & eccentricity of the curve can be changed by changing the exponent & blending it with a straight line.
Then came some experiments to minimize the blurring on the spectrogram with various curve weights at exponent 0.333.
There was a tradeoff between intensity of the target & ghosting. The datasheet ramp produced a very intense target with lots of ghosts.
So after stacking 16 waveforms, still using the nonlinear frequency sweep, a metal reflector finally started to appear in the image. It was the 1st time any radar modulation showed anything. Also, when the metal reflector was moving, it disappeared. It only had 1 foot range & couldn't sense anything besides the reflector. Things would be better with a linear frequency sweep.
There is a point in averaging waveforms where increasing the number of averaged waveforms reduces the detected signal. There is a ripple in the frequency modulating which makes later waveforms cancel out earlier waveforms. More stacking also requires running the ADC faster.
It's not bad for a single chip radar, but reveals why radar guidance on this scale probably still isn't workable. After reviewing sample waveforms & experiencing what the imaging entails, the mane problem is power. The single chip solution doesn't put out enough power to do the 20 scans per second to construct a 1D image or the 400 scans per second for a 2D image.
Even weather & air traffic radar is limited to very slow scan rates by power.
Magic lantern finally released a version for the T4I. It has the coveted digital zoom for video. The zoom is exactly 3x. It converts a 200mm to a 600mm with no loss in F stop, but the sensor size is reduced. The digital zoom is not accessible from the zoom buttons, only the menus.
It often fails to stop recording until it's power cycled. 1 time, it didn't create a recording, but that may have been a wrong button. Every time it was observed to properly start recording & not stop recording, it still properly wrote the file when power cycled.
It also fails to go back into video mode when power cycled. It needs another power cycle to work.
When video cropping is enabled, the 10x focusing aid is unavailable. The peaking feature isn't as accurate.
Video cropping also adds pretty nasty noise because of the reduced sensor size. It's no good if moving closer is an option. It's physically equivalent to the F stop change of a teleconverter.
So VHDL was the chosen language for FPGA development, because most of the example source code is in VHDL. It was surprising that the world abandoned Verilog in the last 13 years.
Hardware design is a step below assembly language. It's very time consuming to do things like print a character on a UART. It's amazing that video decoders have been implemented in hardware. The Xilinx development environment is slow, has a really lousy text editor, but is necessary for using their IP cores. Just checking for syntax errors is really slow.
Implementing the required FFT with motion detection algorithm on the FPGA is a big deal. The concept is roughly known. Attach an automotive radar & FPGA to a computer fan. Power the circuit using a commutator, inductor, or separate battery. Get data from it using IR or RF.
The radar module spins around as fast as the computer fan can go. It takes as many chirps per revolution as the FPGA allows. Depending on the noise level, it can get a doppler reading which would allow unlimited chirps per revolution or it can get a frequency modulated reading which would limit the chirps per revolution to the FPGA's memory.
The frequency modulated solution would be limited to under 16 chirps per revolution. Each chirp would feed a 1024 slot 16 bit FFT. 2 FFT's would be compared to get a distance change. 320 FFT's would be required per second if there are 20 revolutions per second. It might be within reach of a blackfin.
If you have enough battery power, you can make a rover use stepper motors. There might even be an opportunity to use direct drive brushless gimbal motors for precise rover odometry or a direct drive balancing robot.
That's a rover board using A3967 stepper motor controllers. Unlike an ESC, the A3967 has complete control of the motor position. Unlike a brushless gimbal controller, it only has 32 steps per revolution. A brushless gimbal controller has thousands of steps. The mane parameters for a stepper motor are the total current, the size of the step, the steps per second, & the direction.
The DAC on the STM32 connected to the REF pins determines the total current. GPIO's bang out the steps. This would be better done with hardware PWM than bitbanging. The A3967's are using the Easydriver reference design.
The motors overheat well below the maximum current a REF of 3.3V provides. The current is foremost limited by the voltage & resistance of the coil. When that fails, the A3967 clips it based on the REF voltage.
The MS pins determine the number of steps per phase. For a pointing application, you want 8 steps. For a rover, you want 1 step.
The stepper motors succeed in guaranteeing that all the wheels rotate at exactly the same speed & distance. They allow a much wider range of speeds & more consistent speed than an ESC or variable resistor. An encoder regulating RPM is not as accurate.
Combined with the consistent motor speed at low speeds, a magnetometer is enough to provide reasonably precise turning. It has to be carefully calibrated & perfectly level.
The reality of wheel slippage is still there. That prevents driving in straight lines without heading feedback & turning without a magnetometer.
Rcgroups introduced a strange program of giving temporary upgrades to plus features, then switching you back to regular features. That means your message limit toggles between 200 & 2000. When it goes back to 200, all your messages beyond 200 get deleted. It's about as annoying as if gmail randomly deleted your last messages.
Obviously, rcgroups gets enough leverage from better exposure than a generic blog that people are willing to pay for 2000 messages in an age where everyone else has a free terabyte. The free sample program that ends up being an email deletion program is still a bit ridiculous, in this age. It just makes you hate the existence of plus features completely.