Jack Crossfire's blog - Page 55 - RC Groups
Jack Crossfire's blog View Details
Posted by Jack Crossfire | Aug 21, 2012 @ 04:25 AM | 5,310 Views
Aren't you glad you didn't need to solder that board, but when an LF353 would either cost $20 or take 5 days to order, the easier option is some more epic analog BJT magic.

This one took a while to figure out. The object of the game was to make a comparator out of the fewest transistors. The trick was using the output of 1 side to drive the other side & using an NPN where a PNP would be used in an H bridge.

There was probably a magic search term which would have found the same thing on the goog.

So the next great hope is broadcasting pings from the ground to the aircraft. Initial tests with a single h-bridge driven transducer were promising. The trick is driving 3 transducers with a reasonable circuit, getting the aircraft to know which transducer is pinged & when, getting a ping rate high enough.
Posted by Jack Crossfire | Aug 19, 2012 @ 03:37 AM | 5,714 Views
Among sonar methods, the most solid has a sideways emitter on the aircraft pointing directly at a sideways receiver array on the ground. The aircraft can't point towards any other direction & the altitude is limited to nearly the same height as the array. Totally worthless for an aerial camera, but this has the widest range of horizontal motion.

It might work on a monocopter, by pinging once for each revolution, when the emitter is pointing towards the array.

The next item was having the ground array transmit pings to the aircraft. The aircraft transducer receives less motor noise because it points away from the motor & is extremely directional. That gave a big improvement in low altitude noise rejection, but now 3 pings have to be created for each position solution, slowing the position sensing to 7Hz or 13Hz if you're lucky.

Each ground transducer needs either a real expensive op-amp or a real complex h-bridge. The oscilloscope finally revealed just how bad the LM324 was at driving a transducer. It was good enough for outputting very small 1 volt signals, but took 60us to go from 30V to 0V. That's 2/3 of the sonar wavelength. All those flights in 2009, with the LM324 driving pings at 10V weren't even close to full power.

To its credit, the op-amp has a hard job, outputting a precisely calculated voltage for a fixed gain. The h-bridge only knows on & off.

The good news is those are the only 2 contenders for sonar. Only the latter would be applicable to a monocopter.

Should note the oscilloscope brings a dream within reach, manely receiving the space station on a home made radio.
Posted by Jack Crossfire | Aug 18, 2012 @ 12:20 AM | 5,506 Views
So the AHRS & attitude stabilization came together. The Blade CX is so unstable, it's amazing anyone can fly it manually. As predicted, the mane contentions were setting the 3 in 1 gyro gain, balancing it, aligning the IMU. Eventually, it was controllable for the computer with the same signals as the human interface. Fears of the low IMU frequency not handling the vibration were unfounded.

So either the machine noise or the downwash from the Blade CX killed sonar.
That was revealed by the year old PIC waveform recorder. The Rigol can't capture a long waveform.

Windscreens on the transducers did nothing, but it also depends on altitude. Changing the receiver gain did nothing, since motor noise is louder than the transducer when not head on.

This problem may be solved by putting the transducers on the ceiling & having the sender point up. The sender could also point straight ahead at a sideways array for testing.

Hanging position sensors on the end of a long boom for a ceiling mounted system has now been validated by this award winning vehicle:

Posted by Jack Crossfire | Aug 17, 2012 @ 01:38 AM | 5,179 Views
After very slow & methodical plugging of servos in, viewing all the voltages on the oscilloscope for surprises, all 4 PWMs were pulsing successfully. PWM could finally be measured precisely enough to do it without burning out servos.

The 1k resistors seemed to do the trick. It's very easy for a test probe in such a confined space to connect a PWM output to 30V.

Had yet another networking bug, in which another specific packet size was causing it to crash. The solution is to make all packets a known, good size. In none of the reappearances of this bug did a real solution emerge. Telemetry alone now goes at 90kbit/sec even though it only uses 20kbit/sec.

Armed with the I2C waveforms, the IMU slowness could now be tracked down to another pointer error instead of I2C interference. At 25Mhz, 3.3V, the PIC is now maxing out at 80 readings/sec from lack of clockcycles.

Finally, the oscilloscope revealed 2 strange behaviors in the 3 in 1 motor controller. The throttle & yaw pulses must be staggered or it reads all yaw as full left. Yaw must be pulsed in order to shut down the motors. If just throttle is pulsed at cutoff level, it'll never shut down.

Motor control issues being resolved leaves extreme drifting in the IDG3200 IMU, calibrating the E-flite rate gyro without a stick controller, calibrating attitude stabilization, automatic cyclic, full automatic.

A traditional coaxial copter, with its multitude of different PWM waveforms, vibration, &...Continue Reading
Posted by Jack Crossfire | Aug 16, 2012 @ 03:35 AM | 5,396 Views
After 20 years of electronics in the dark, an oscilloscope finally materialized on the bench. It's the legendary Rigol DS1052E, overclocked to 100Mhz. The mysteries of I2C & sonar problems could now be revealed. The rise time on I2C is extremely slow & is what's limiting the bandwidth. There's no obvious RF interference.

The sonar voltage very precisely matched its predicted shape, but there's a spike to 40V.

The next board came together, immediately revealing the dual LM317 scheme is still not enough. There needs to be yet another offboard TO-220 hack. Never figured out what fried the last chip. Just put 1k on all the PWM outputs & delayed the airframe integration to think of more ideas. Never giving up, the board has the footprint for a TCM8230 camera.

The 30V sonar voltage is actually present on the transducer case. If any of it conducts through balsa or the transducer contacts a servo pin, it could explode.
Posted by Jack Crossfire | Aug 15, 2012 @ 02:48 AM | 6,181 Views
So with everything buttoned up, plugged the battery in, the servos seized up, & unplugged the battery. The servos are not pulsed at this stage. Only floating inputs could have done that.

Plugged it in without the servos & got sporadic crashes & bogus DC voltages from the PWM outputs. 1 motor would spin, but not the other, regardless of yaw. Then, noticed the ARM was getting hot, rebooting, & dying. Somewhere during the fabrication, the ARM got damaged. Yaw PWM was showing ground. Roll servo was showing 2.5V. Pitch servo was proper PWM.

The only logical explanation is some funny business with the PWM wires. Maybe they have transient connections to 8V. Maybe they have to be connected through resistors.
Posted by Jack Crossfire | Aug 14, 2012 @ 03:16 AM | 5,380 Views
The TCM8240 was finally voted off the island, when it showed a sporatic short circuit which caused the CPU to die. Maybe that was making it fail to output raw data.

The closest it came to outputing anything was using the registers found on:


It only produced a completely white picture. Maybe the chip was defective. Maybe the pinout had an error. It doesn't matter, since it never encoded JPEG & there is a much smaller camera which can output raw.

Also remembered 1 way to simplify the routing & shrink the board is to connect the data pins out of order, then use a software lookup table to reorder the bits. Who knows how slow that would be. A speed test on the revision 1 board would reveal the impact, but be a lot of work.

The PWM signals are being generated. The IMU is being read & fused. Time to put it on the airframe.
Posted by Jack Crossfire | Aug 13, 2012 @ 04:32 AM | 5,419 Views
So that's the traveling exhibit. Marcy 2 underwent 2 board designs to support 2 different cameras. After 3 days fighting it, the TCM8240 finally won & no picture could be gotten from it. There wasn't enough documentation to get either JPEG or RAW.

There was a brief fascination with getting the TCM8240 to work in any RAW mode, once JPEG was proven unworkable, but without JPEG, it's absolutely worthless & too heavy to justify buying any more of.

In 1280x1024 mode, the scan rate would be so slow, it could only photograph stationary objects. No-one is going to invest in an SRAM if cheap spycams can get higher resolution. Finally, the TCM8240 overheated the power supply.

With single layer home made etching, the TCM8240 board can't be reconfigured at all to use the TCM8230. Rerouting is only feasible with the arrangement on the TCM8230 board. It needs to get a lot bigger to support sonar.

If the TCM8240 worked, it would have been a wifi video downlink from the Blade CX. It would have been neat, but the Blade CX is going to a customer, never to be seen again.

It got me thinking the monocopter is extremely limited. It could only be used for low resolution still photos, but nothing useful. The neatness of 4fps video from a spinning wing quickly fades when considering the usefulness of video from a stationary copter. Something that automatically follows your face would be useful for a low end video blog.

Both platforms are aerial, so always very shaky compared to a ground based camera robot, but still ahead of most content. Anything aerial would be better suited to still photos. Part of the motivation to fight for shaky, low res video on a copter that's going away, with a camera that's going away, was to keep the $60 spent on those from being a mistake.
Posted by Jack Crossfire | Aug 12, 2012 @ 01:25 AM | 5,456 Views
The time finally came to integrate another flight computer on another airframe. The IMU is limited to 60Hz, because of the wifi interfering with i2c.

I2C on the IMU can handle 29khz. At 30khz, the wifi kills it. An oscilloscope would show what's happening & probably reveal a solution, but lacking the budget, the IMU speed has to be stuck.

I2C in burst mode is an alternative way, but it has never worked.

Also spent a few hours on the TCM8240. The JPEG output seems to have a valid header & start codes, but its compressed image data is all repeating patterns which the decompressor can't read.

Here the 0xffda code for the data segment is followed by a repeating pattern.

30    e5 e6 e7 e8 e9 ea f2 f3 f4 f5 f6 f7 f8 f9 fa ff     ................
40    da 00 0c 03 01 00 02 11 03 11 00 3f 00 af 45 00     ...........?..E.
50    14 50 01 45 00 14 50 01 45 00 14 50 01 45 00 14     .P.E..P.E..P.E..
60    50 01 45 00 14 50 01 45 00 14 50 01 45 00 14 50     P.E..P.E..P.E..P
70    01 45 00 14 50 01 45 00 14 50 01 45 00 14 50 01     .E..P.E..P.E..P.
80    45 00 14 50 01 45 00 14 50 01 45 00 14 50 01 45     E..P.E..P.E..P.E
90    00 14 50 01 45 00 14 50 01 45 00 14 50 01 45 00     ..P.E..P.E..P.E.
a0    14 50 01 45 00 14 50 01 45 00 14 50 01 45 00 14     .P.E..P.E..P.E..
b0    50 01 45 00 14 50 01 45 00 14 50 01 45 00 14 50     P.E..P.E..P.E..P
c0    01 45 00 14 50 01 45 00 14 50 01 45 00 14 50 01     .E..P.E..P.E..P.

Posted by Jack Crossfire | Aug 11, 2012 @ 05:47 AM | 5,021 Views
With the 168Mhz ARM, full IMU, & JPEG camera, the hackneyed power supply is maxed out. Now a real bench power supply with current limiting is looking real good. You need current limiting to handle accidental battery connections into the power supply. With 30V sonar, it's going to be sucking serious power.

A quick IMU to handle the newly discovered instability came together. It updates at only 50Hz. The theory was there is so much interference between wifi & i2c, the IMU would use a PIC to read all the i2c sensors locally, then encode the results on a UART for the long wires to the ARM.

Like the ARM, the PIC i2c bus maxed out at 24khz before wifi started interfering. That only gave 50Hz updates. It could double it with parallel i2c busses for the accelerometer & gyro, but those are no longer made in separate chips. It would be a 1 off board. Have a feeling, if there's time left over, parallel i2c busses are coming anyway.

The PIC needs 16Mhz to get 50Hz updates.

Time for another stab at downlinking the JPEG video & then some AHRS solutions.
Posted by Jack Crossfire | Aug 10, 2012 @ 01:17 AM | 3,992 Views
So decided to bring up the TCM8240 on the latest board. Decided to use the same board for Marcy 2 & the Blade CX II. It's a lot of work to lay out a new board for each aircraft. They would both use the magnetometer & possibly camera.

Got it spitting out JPEG images at theoretically 1280x960. There is hope it can compress 640x480 in addition to the full 1280x1024. The mane issues with the TCM8240 are:

The pins are ridiculously close together, since it was obviously a surplus item intended for another product. If anything bridges, you need to desolder it & try again.

Pulse reset after power up.

PLL must be enabled for JPEG to work. Set register 0x3 to 0xc1.

Enable the data output & JPEG compression by setting register 0x4 to 0x40.

Data automatically starts streaming from the pins.

The day was spent remembering to call DCMI_CaptureCmd(ENABLE); to begin capturing on the STM32F407.

Thought this camera streaming wirelessly would make a good demo during an interview. Helas, another interview never happened, as someone else with just the right buzzword came along.

Then came the Blade CX II. Passed up any newer quad or flybarless copter in favor of this, because it was believed to be the most passively stable, it had the smallest size for its payload, & coaxials used to dominate academic research before quads.

For all the hype about coaxials being super stable, fuggedaboudit. It was extremely unstable & hands on to stay in position. To be sure, the tail undoubtedly stabilized the yaw & balanced it more, but there's no way that level of sensitivity is always going to be satisfied.

Marcy 1 is extremely stable. She can lift off & hover with no cyclic input. That kind of stability is way beyond anything commercially available.

The good news about the blade is the radio & flight computer were separate boards, making radio replacement easy. The payload should be plenty to handle the new flight computer.
Posted by Jack Crossfire | Aug 08, 2012 @ 11:11 PM | 4,230 Views
Sonar came out at 6g when miniaturized. A tri-state op-amp would still be a lot better. The h-bridge is a buster to solder & a real nail biter during the 1st 30V power up.

The ferrite inductor is a weight buster. Getting 30V takes either lots of ferrite or lots of ceramic. Any 6x voltage increase requires storing a lot of charge. Connecting it to the CPU requires the actual aircraft, to route the cables.

After spending a good 8 hours fabricating without even getting to the camera, the massive complexity of the electronics & boredom required to do this simple thing became obvious. The complete electronics would come to 12 hours, not counting airframe assembly.
Posted by Jack Crossfire | Aug 08, 2012 @ 03:42 AM | 4,379 Views
The sonar board is a bit larger than the Maxbotics & probably too heavy for Marcy 2. It's going to take a lot of discrete analog components & voltage boosting to get the best sonar ever made.
Posted by Jack Crossfire | Aug 07, 2012 @ 02:13 AM | 4,541 Views
Wound the wick all the way up to the 30V op-amp maximum. Even though the circuit isn't going to use the op-amp for high voltage, the transistors explode at 40V, the boost converter explodes at 37V, & the capacitor explodes at 35V, so it's about as high as it can go, before components start getting big.

Distance over carpet got better, even with a single transducer, but it sure had a lot of boost converter ripple. The current consumption is only 2mA. The mane problem is now getting 30V 2mA from an aircraft size boost converter.
Posted by Jack Crossfire | Aug 06, 2012 @ 01:21 AM | 4,654 Views
So today's lesson was another way to boost voltage with a BJT. Sonar is going to need very high voltage. The MOSFET needs a 4V gate to turn completely on & generate the high voltage sonar needs, so a straight microcontroller pin won't do.

A full set of tests with the H bridge & a single pulse driving the transducer showed a reduction in the deadband. Also tried driving 1 pin only & got a negligable reduction in deadband with a significant reduction in power. In all cases, the H bridge was held for 1ms after the pulse. When it was held longer, the deadband & power were negligably reduced.

The bulletproof, ideal system is dual transducers with both pins driven by 1/2 pulse from an op-amp & no floating of the pins. It works over carpet.

To eliminate 3 grams, the single transducer with both pins driven by 1 pulse from an H bridge can be used, but has more deadband.

There was a lot of variability from slight changes in the transducer positions & through hole soldering perils.
Posted by Jack Crossfire | Aug 05, 2012 @ 12:40 AM | 4,582 Views
So the deadband is less with dual transducers or when the op-amp or microcontroller is used to drive a single transducer. It's slightly less still when both pins of the transducer are held at a constant voltage, but not if 1 pin is floating.

It's double when the h-bridge is used, at any voltage. The ringing duration is unaffected by voltage. Only the amplitude of the entire waveform was affected by voltage. The op-amp ringing & h-bridge ringing were compared at 5V, since the op-amp couldn't go higher.

The exact cause of ringing is unknown. The transducer has some resonance. Only an oscilloscope with 20V range would reveal what's happening.

Another rebuild of the op-amp with diodes revealed some more nuggets. This configuration still died at 20V. Then came some new ideas. Instead of an oscillating waveform, drove it by toggling the pins twice, separated by 100 microseconds. That still killed the pings at 20V. Toggled the pins once & that got it working at 20V.

Interestingly, in the single toggle mode, the pings peaked somewhere over 5V, died somewhere above that, & recovered by 20V. 20V still gave less amplitude than their peak. So the diodes are dying at a certain resonant frequency & voltage, but a diode free op-amp works at all voltages. Single toggling still doesn't allow it to switch off for audio sampling, so the voltages must 1st go 1 way, then get reversed, then get turned off.

In the 3 state mode, another test showed the power output decreased as the pulse length increased. So the diodes aren't knocking out the high frequencies but acting like a band reject filter.

The op-amp with diodes is important, because it has a shorter ringing time than the h-bridge & Marcy2 isn't going to fly with 2 transducers.
Posted by Jack Crossfire | Aug 04, 2012 @ 02:29 AM | 4,195 Views
This circuit is doing a pretty high level logic function with simple transistors. Looking at such a simple transistor alone, for many decades, it was hard to believe this single component could overthrow the human race.

When 7 were connected, they got incredibly more powerful. That's all it took for a voltage to be inverted & amplified, & inclusive ored. It's easy to see how trillions & trillions of transistors could easily take over the world.

Points learned: the transistors are polarized. The emitters on the PNP's go to the power supply. The emitters on the NPN's go to the ground. Since the transistors are activated by current, not voltage, the PNP bases need to connect directly to the NPN collectors, not pullup resistors.

Most importantly, the transducer needs to be right next to the receiver, not a long wire. This draconian requirement means the sonar needs a breakout board with 2 options with a lot of wires.

20V, GND, H bridge, H bridge, transducer disable, output

5V, GND, output, transducer, transducer

Suspect any long wires between the H bridge & transducer would kill it. No way to know without building & testing with all the RF sources, leading to no option besides 6 wires.

Sadly, the ringing time doubled with this design. It now has 1 meter minimum range. Though the reflected signal increased, the ringing time didn't depend on voltage. Something about the h-bridge or transducer mounting increased the ringing time. All...Continue Reading
Posted by Jack Crossfire | Aug 02, 2012 @ 07:13 PM | 4,096 Views
That was bulletproof. Even 2 meters over carpet, it got most of the reflections. Practical use over carpet would be much lower. The transmitter runs at 20V, but could go up to 30 before the op-amps explode. There's another option for making a single transducer work, but the show must go on. Parallax probably uses dual transducers because there wasn't a way to make a single one work as well. A real problem is sizing the inductor for a flyable boost converter.

Unfortunately, it didn't change the amount of magic required to detect short distances. There is still a lot of noise from the outgoing ping. Still not switching to the parallax, in order to get more omidirectional range.

A BJT H bridge was a massive improvement over the LM324 at DC. The voltage goes all the way to the rails. The outputs go as floating as can be, when disabled. Too bad it took so many hours to troubleshoot. Time to reinstall Windows & simulate more. The BJT magic is more expensive than a transducer but lighter.
Posted by Jack Crossfire | Aug 02, 2012 @ 12:01 AM | 5,313 Views

Lacking an oscilloscope to truly know what it's doing & being too lazy to reinstall Windows & run LTSpice, it appears the circuit is against the bandwidth limitation of the diodes.

The higher the voltage change, the longer it takes the diodes to switch completely on or off. At 5V, there's enough time to switch to 0V. At 10V, they only get part of the way to 0 before the voltage inverts. At 20V, they may only reach 15V before being switched off again.

Switching off all the op-amp power rails doesn't work. There's always current flowing from the output into the op-amp.

At 24khz, diodes aren't enough to switch the op-amp outputs off. The last way is to use an H bridge + op-amps. The H bridge can have high impedance output by getting all 0 inputs.
Posted by Jack Crossfire | Jul 31, 2012 @ 09:48 PM | 4,842 Views
Years ago, 10V seemed to improve the range of single direction sonar. In reflected mode now, it completely destroyed it. At 10V, the range started to decrease. By 20V, there's no detected reflection at all.

At 20V or 40V peak to peak, the sensor actually seemed to stop receiving. Maybe the diodes broke down. Maybe the sensor heated to a point where it can't receive. The ordinary Radio Shack diode breaks down at 25V. Maybe the diode magic degraded it.

Nothing has worked over carpet. It's hard to believe anyone is using reflected sonar over carpet, unless it's a ridiculously low altitude.

Reflected mode goes at 20Hz, by shortening the pings to the absolute least amount of time. The sensor rings for a fixed amount of time after the voltage is cut off, so the idea of driving it is just to get it started, like a hammer hitting a string. It may work with only a single pulse.

The Maxbotics probably gets shorter ranges by measuring how long the sensor rings, then for distances below 14", it measures the end of the ringing.

There's also the chance reflected & single direction can be combined to produce a more accurate distance. Lots of things to try, with the winner whoever picks the right things 1st.

In other news, the next laptop arrived ahead of schedule, a 2.3Ghz Intel I3 with 4 hyperthreaded & 2 physical cores. When it dies, the super slow EMachines with 1Ghz AMD dual core will finish the rest of its life. Having this upgrade definitely makes the last year with the EMachines look like a simpler, impoverished time.

As with the Intel I2 from 2008, it's much faster & smoother than the AMD at the same clockspeeds, but has only 1/4 the battery life of the AMD. It's much faster than the 1st 2.4Ghz laptop, a super expensive 2.4Ghz AMD single core from 2005.

Hyperthreading has improved drastically, over the years. In 2010, hyperthreading slowed down compilation. Now look at the difference:

4 cores: 48s
2 cores: 1m29s

The Intel requires a 4S battery where the AMD used a 3S battery.