Jack Crossfire's blog - Page 11 - RC Groups
Jack Crossfire's blog View Details
Posted by Jack Crossfire | Oct 11, 2016 @ 06:57 PM | 2,191 Views
Posted by Jack Crossfire | Oct 11, 2016 @ 03:30 AM | 2,406 Views
The answer is yes. Computers can probably now govern us better than ourselves. All the information ever recorded in human history is online. A computer could assimilate it all to create the perfect government, decide all our votes, create all our laws. A lot of people would hate the result, but it would achieve the optimum potential, least pain, & most fairness of every alternative.

If there was any more land to colonize, the new colonies would probably base their government on a computed result. They would admit it's beyond our mortal constraints to govern ourselves, but luckily we have tools that the founding fathers never dreamed of, to do what mortals can't do.

In a way, we're already moving towards a computational government. The
stock market is entirely automated. We all rely on Goog searches to
decide how to vote.

It's surprising no-one has already tried to create a computational government. The Goog could do it right now, but the result would probably put them out of business.
Posted by Jack Crossfire | Oct 10, 2016 @ 01:36 PM | 2,200 Views
Feiyu run timelapse 2 (2 min 55 sec)

1st timelapse run with the Feiyu running custom firmware. It's pretty bad, but comparable to Ginger Guy's raw Feiyu footage. The heading drifts a bit more when running. Roll drifts ever so slightly. The drift is nowhere near as bad as stock firmware. The motor mixing issue is pretty bad. It's rough to have to keep it always vertical.

F-22 stabilized (11 min 36 sec)
...Continue Reading
Posted by Jack Crossfire | Oct 09, 2016 @ 01:20 AM | 2,382 Views
Feiyu Mini 3D alternative firmware (2 min 4 sec)

Still managed to not burn out the motors or break the flex wires. These are considered the mane risks for any development on it.

Stepped the IMU & feedback up to 2khz, but the mane limitation is nothing else can happen while I2C is being accessed. The IMU board has to send the readout & wait for a data packet to make a full round trip to all 3 microcontrollers & back before taking the next reading. Function indirections contributed quite a delay to the I2C driver so inlined a lot of it.

Much PID tweeking got useful pointing accuracy but not as good as stock, despite much higher current. The reluctance cogging ended up not a factor. In certain parts of the rotation, it slightly vibrates when fighting reluctance cogging, but it doesn't ruin the video. The feedback allows it to do smooth panning with no evidence of the cogging troubles.

Decided to implement the full auto centering using the hall effect sensors. So if it's within 10 deg of the target position, it uses the IMU. If it's outside 10 deg, it uses the hall effect sensors. There's a small jump when transitioning because the hall effect sensors aren't as accurate as the IMU, but it's better than a complete loss of control when it bumps into something.

Mixing of the roll/heading motors is definitely horrid. It didn't work in the stock firmware, but it was better. There's never going to be variable pitch or ability to initialize upside down. These problems are solved with matrixes & needing a matrix to solve kinematic problems has always been a career ending event.
Posted by Jack Crossfire | Oct 06, 2016 @ 04:00 PM | 2,087 Views
It was somewhat of a surprise that 3D Robotics dissolved. Fully expected it to get bought by someone, but they held out for too high of an asking price. They followed the open source philosophy like VA Linux, with the same results. We all lived through the failures after the open source boom of 1999. Now, if you opened up the DJI source code, you would find the 3DR source code. It promotes adoption through charity, but after fueling the kickstarter boom, even millenials have discovered charity doesn't buy as much as making money. Now, like their predicessors, they're hoping for a buyout at a much lower price.

Given enough money, would have gone with 3DR copters because they had replaceable parts & were hackable. All copters have since moved to proprietary all in 1 systems because they're the only way to solve the vibration, balance, & calibration issues. Maybe they're a lot less crashable & the cameras are good enough to not upgrade.

Anyways, consider in 2007 an autonomous quad copter with shaky cam was $18,000 with a lot of fussing. People used to hack them in their spare time. Today, the Mavic Pro is $1000 with a rock solid cam & no fuss. No-one hacks quad copters anymore. You just put them in the air & they're as good as tripods.

It was 1 of those niches which suddenly went from not existing to having unlimited possibilities with only the need for someone to figure out what the right quad copter was. The brushless gimbals have also followed the downward trend towards phone size. It's not long before the original Gopro box with 3 big motors is gone & the complete gimbal + camera fits in a what was once the Gopro box.
Posted by Jack Crossfire | Oct 03, 2016 @ 12:03 PM | 2,095 Views
Decided to just put in a standard brushless gimbal program & see if it worked without trying to fix the reluctance cogging. The immediate problem was latency when propagating data from the IMU to the 3 microcontrollers. This was why the stock Feiyu used 1Mhz I2C & 2Mhz UART, but I2C was crashing any higher than 100khz. Tried shorting the series 100R's & replacing the 2k pullups with 1k pullups on their I2C bus. That didn't work. It turned out I2C on the STM32 needs to be polled as fast as possible. Once done, it went all the way to 1Mhz using 2:1 duty cycle.

Captured a waveform to show 1Mhz I2C was really a thing. Helas, 16:9 duty cycle doesn't allow it to do the stock 1Mhz, only 720khz or 1.4Mhz. The 16:9 would be more reliable, but to get 1Mhz would require a clock speed multiple of 10. If the gimbal is fully deflected, it'll break I2C. 2Mhz for the UART wasn't a problem.

It would have been quite valuable to know the frequency of the stock IMU readouts. Set it to 1khz. Used source code from an ancient BruGi project. They ran the gyros at 8khz, but 1khz was the fastest the Feiyu could get the data down all 3 microcontrollers. It started glitching above 1khz, so left it. Better scheduling of I2C & UART is required to max out the rate.

At 1khz, the minimal feedback worked quite well. It seemed to compensate for reluctance cogging on its own. It's a bit more solid to run the motors at higher current than stock, but it overheats after a short time. Considered mounting a fan on the handle to blow air at the entire gimbal.
Posted by Jack Crossfire | Oct 01, 2016 @ 12:02 AM | 2,907 Views
Making Humans a Multiplanetary Species (best audience questions) (2 min 11 sec)

Part of the problem was the show happening in Mexico. The other part was even though a lot of the world took it very seriously, there was another part which doesn't take him seriously at all. At least he didn't moderate the questions with some bureaucrat.

Good grief, the government should fund more Musk, just like governments funded Columbus, Luis & Clark. Governments just don't do that anymore.
Posted by Jack Crossfire | Sep 27, 2016 @ 10:29 PM | 9,655 Views
Must concede, the 1st time the BFR appeared on the monitor was a bit of a letdown. It seemed too unreal to ever achieve. It went against everything in the Andy Weir book. The size was completely nonsensical. Just when the ship was supposed to stop at an orbiting outpost, the ship kept going, all the way from the launch pad to Mars. Was this nonsense what Musk worked on for the last 2 years?

The internet expected something more realistic, a 3 cored rocket of incrementally more power than the Saturn V, but not 4x more powerful. Things went downhill when the 42 engines all randomly stuffed under the booster appeared. It looked more like throwing the kitchen sink at a problem than rational calculations.

Then Iron Man showed up with a moustache resembling Howard Hughes. He assuaged some fears by stating the video was based on CAD models & there was enough room for BFR facilities to coexist with the current Falcon 9 facilities on LC-39. He already built a full size oxygen tank for the 2nd stage, in addition to firing an engine which seemed to be the full size engine. We all hope today's speech goes down as a Kennedy moment, where we all remember where we were when it happened & quote the lines for all eternity.

The spartan black & white graphics brought back memories of the Saturn V diagrams from the good old days. That made it look a little more legit. Nothing that detailed was released for the Falcon 9. Delta IV & Atlas V diagrams were always...Continue Reading
Posted by Jack Crossfire | Sep 26, 2016 @ 11:38 PM | 8,415 Views
Predictions for Musk night 2016: The BFR will be a single core equivalent of the Falcon heavy, with 9 Raptors. It'll be the same size as New Bezos, but have a reusable 2nd stage. It'll have a 3 core version outputting 15 million lbs of thrust. The raptor engine will produce 600,000lbs of thrust in the same size as the Merlin & a fraction of the size of the RS-25 which made 400,000lbs of thrust.

It'll put an object 75% as large as the shuttle in LEO. It'll use multiple launches for the MCT, fuel, & the permanently space based component.

The rest of the architecture will be equivalent to Andy Weir's vision. The mane focus will be the unveiling of the big rocket, since Andy Weir's vision is familiar to everyone.

It's the largest methane engine ever tested. That alone should have made more headlines than year 50 of race riots. As usual, the engine was heavily obscured in the test photos. It looked much smaller than past 600,000lb thrust engines, but Musk has a history of getting more thrust from the least weight than anyone else.

There's no obvious gas generator exhaust like there was on the Merlin, confirming it's the staged combustion cycle promised earlier.

Musk said it's the same size as the Merlin, but making 3x more thrust from a tripled chamber pressure. Based on photos of the Merlin next to construction workers, the engine under test is indeed the full size version. They're both slightly smaller in diameter than a handrail. The nozzle diameter...Continue Reading
Posted by Jack Crossfire | Sep 25, 2016 @ 12:47 AM | 6,237 Views
The guy who made a timelapse movie of traffic by writing a javascript program to load the data from the Goog developer API makes you wonder why he didn't just screen capture a browser window all day.

It brought to mind the 1+1 problem. The way modern developers add 1+1 is by creating several objects. There's a starting event broadcasted by the user. It causes a 1 object to broadcast an event. A + object waits for the 1 event. Then another 1 object broadcasts an event. The + object waits for that event. When the + object gets 2 1 events, it adds them & broadcasts an = event. There's an = object which waits for = events before broadcasting a display answer event. All the objects reside in their own threads.

Adding 1 + 1 can be done in a single line of code, but it's 1 of many more realistic examples in the mobile app boom where what could be done in a few lines of C code is done using thousands of objects & horrendously complex event passing sequences. Deciphering the simplest workflow requires much worshiping of the IDE's search tools & swapping between many files.

But a single line adding 1+1 is not a dogmatic solution & won't get you a job. The availability of plenty of money to enforce any software architecture dogma, no matter how inefficient, is a key facet of the mobile app boom. Many an interview has been failed by giving direct answers instead of dogmatic answers or worse, looking up the answer like you would do in the actual job instead of trying to recite it from memory like you're supposed to do in an interview.

It seemed to start in the 1990's with the idea of plugins & interprocess communication. The modules became smaller & more fundamental until every single thing is now done by a new object. Many a developer is shocked by the idea that a program can actually be written from left to right, top to bottom, stepped through like a book. The current generation never saw anything like that.
Posted by Jack Crossfire | Sep 24, 2016 @ 12:47 AM | 5,345 Views
For the impatient: “a breach in the helium system”

The helium spheres plagued them for a long time, starting with a “bad trends” tweet in 2015. Surprised the failure caused that much fire instead of just spraying liquid oxygen all over the place like the 2015 explosion. Carbon tanks never did the job on the x-33 & ended up killing the program. If carbon fiber can’t do the job again & they switch to solid metal tanks, it would be another blow to reusability.

As usual, millenials will be satisfied just knowing it was ruptured tank & it was fixed by whacking on a little more fabric & she'll be right. Generation X will never be satisfied & assume the tank was ruptured by an external force not to be disclosed until Nov 9.

The internet converged on spontaneous combustion of carbon fiber as it rapidly unraveled in a liquid oxygen environment. It would be a nifty experiment to deliberately rupture a COPV in a tank of liquid oxygen to see if it explodes, but it would be real expensive so it won't be done.

NASA tested COPVs to 7500psi, back when it made spaceships. The SpaceX ones were 5500psi.

Based on the graph, all tanks fail after a certain amount of time under pressure. Decrease the pressure or the time & the failure rate becomes a function of the number of tanks. In 100 launches, there would always be a failure.

When the tanks burst, it looks like a lion mane got abused.
Posted by Jack Crossfire | Sep 18, 2016 @ 05:32 PM | 2,788 Views
The ganged batteries made their debut 18.6 mile drive. Speed was reduced to 9:30 on account of the heat, which translated to 10:00 after PWM errors. The fuse didn't heat up. After the drive, both batteries were cold.

It was quite luxurious to not have to stop the run, squat, & change batteries. You have no idea what a pain that was for 1st 3 years of robotic exercise coaching.

Battery #2 in the low tray took 4545mAh. Battery #1 in the payload bay took 3294mAh. So they discharged as expected, but it was a quite high current draw. They carried water for 7.5 miles with 5 miles uphill. Need to swap battery trays to see if it was cable loss or internal resistance.

The wiring was redone to handle more current & gain a fuse. The fuse in the apartment was a polyfuse which started blowing at 3A. It was delayed proportional to the current. 3A took a long time. 8A blew it almost instantly. It got hot, never cut off, but allowed a current below 1A after blowing & continued heating. It would probably explode if the batteries shorted, but it's better than the wire bursting into flames. An HRC fuse would be nice. The normal cruising current with 2 batteries is 1.2A - 1.7A if they're balanced. It might blow on a hill or if the human goes real fast.

The once dubious LED arrangement turned out pretty respectable in its ability to light a large area.

The attempt to glue the wheels failed. The rubber flexed. They instantly popped out of the glue & spun the same as before.
Posted by Jack Crossfire | Sep 16, 2016 @ 11:11 PM | 2,745 Views
Suspect because it was a terrorist attack, the cause of the last Falcon 9 explosion won't be disclosed until after the election & H-Rod already had the talk with Musk Rod, for his sake. It'll be quite the stir when he finally reveals it right after H-Rod's election, but maybe Americans will just think it was politically correct for ISIS to blow it up. More of a stir would be if Emirates, Quatar, & Etihad airlines immediately got into the space tourism business, just like how the Islamic airlines took over the industry after 9/11.

In other news, I was intrigued by the fact that the fictional New Bezos would be larger than the fictional Musk Heavy, yet would make 1.5 million lbs less thrust. Musk's strategy was always to clear the tower as fast as possible. Every second of the liftoff burns enough fuel for 9 seconds of the landing. So he puts out 2 million more lbs of thrust than the weight of the rocket.

The liftoff mass of New Bezos was never given, but it would be comparable to Musk Heavy. A lot more propellant would be burned to clear the tower, so all that size would probably end up giving the same payload capacity as Musk Heavy.

7 Bezos-4 engines would make 3,850,000 lbs of thrust. The Musk Heavy would make 5,200,000 lbs of thrust to hurl 3,200,000 lbs.

New Bezos would offer a much bigger payload fairing. The payload volume on a 3 cored rocket is the same as 1 core, limiting the benefit to manely higher orbits of the same payloads or...Continue Reading
Posted by Jack Crossfire | Sep 15, 2016 @ 01:01 PM | 3,018 Views
It was a white knuckle experience to gang the batteries for the 1st time without polarized connectors. The batteries were chilled to reduce the maximum current. There was a brief sensation of heat which went away. 8.9 miles later, battery 2 in the undercarriage took 2220mAh. Battery 1 in the cargo took 1222mAh. They ran for 87 minutes.

Suspect the higher internal resistance of battery 1 prevented it from discharging as much as battery 2. Battery 2 would have eventually run out enough for battery 1 to supply most of the current.

The balancing tab was always the easiest way to gang batteries, but with the risk of reverse polarization. A fuse is highly recommended. The mane problem is the surge current when accelerating. The fuse might go for too long for battery 1 to supply any current at all.

String held battery 1 in quite well.
Posted by Jack Crossfire | Sep 13, 2016 @ 01:23 PM | 2,431 Views
With a pile of LEDs from the Radioshack sale, it was time to upgrade the lighting. The lighting could be doubled without increasing current, by shuffling voltage regulators.

The lighting would now drop 7V across 2 LEDs. The trick was using a different plug to prevent plugging 7V into the status LED & to prevent the glitches which plagued lighting before. LED voltages ended up disappointingly uneven. The white ones varied from 3.4 to 3.6. The red ones varied from 1.9 to 2.2. Any attempt to go higher would put some white ones at 4V. It's tempting to put them all in parallel again. It would double the current from 80mA to 160mA.

There was an unused 3V regulator on the board. That became the mane electronics regulator. The 1st test lasted 3.6 miles before it overheated. The XBee used too much power. The next step was to feed it from the 5V regulator to dissipate the heat better. That got it down to 50C....Continue Reading
Posted by Jack Crossfire | Sep 10, 2016 @ 01:59 AM | 2,432 Views
Given the time he had to review fault trees, that puts the needle strongly at a terrorist attack. Given the cause of almost every single explosion, plane crash, & mass shooting in the last 8 years, it's the simplest answer. This explosion was too energetic from the beginning to be accidental. We already saw a Falcon 9 oxygen tank fail last year. It seemed to be pretty benign & broke apart rather than exploding. The only times they exploded was a range safety detonation in Texas & when the 1st stage fell over after landing.

Someone picked a time when security would be the most relaxed & the high speed cameras weren't rolling. Maybe it was an inside job. They have to inspect for explosive residue.

The sound 5 seconds before the explosion sounded like a someone getting off a tailgate to see what the f*** just happened. The microphone had too much proximity effect for it to be far away.
Posted by Jack Crossfire | Sep 07, 2016 @ 12:29 AM | 2,775 Views
50% off most items. Tried to remember everything will still be available elsewhere, so didn't buy all the stock. The knobs were some of the best things they had & quite a steal. Online shopping is a fortune, in comparison. Wire cutters, perf boards, & 2 channel pots all sold out at higher prices.
Posted by Jack Crossfire | Sep 06, 2016 @ 03:12 AM | 3,097 Views
Since the EQ sounds so much better on the custom amplifier than it did on the HTR-5230, decided the long term should include a bigger front panel with a knob for the bass & enough room for a treble knob. There's enough room to fit 2 more pots by merely making a slightly wider front panel & mounting the pots diagonally. Also, the order from left to right needs to be power switch, LED, EQ, volume. This is the international front panel standard.

The HTR-5230 had 2 25k pots for the EQ & a 100k pot for balance. The 100k pot was specifically for balance & couldn't be reworked as a resistor divider.

The treble is always going to be at full. Sometimes the bass should be at full & sometimes it shouldn't. This was realized by Japanese decades ago, with their famous bass boost knobs. Helas, the age of bass boost is long gone. Steve Jobless didn't include it on the ipods & everyone has since dropped it. Not sure why this is.

A load switch to disable the amplifier until after the CS4227 initializes is on the plan. The speakers also need a way to easily pitch up & down.
Posted by Jack Crossfire | Sep 05, 2016 @ 12:54 AM | 3,109 Views
It's rare for anything to work when transferred to the final assembly. In this case, the sound was still perfect, but thermal management was gone. The 5V regulator was pegged at 93C. It took a major rework to add a heatsink to it. It's adequate for normal apartment use. The regulators & STA540 stay in the 50C range. For 20Hz sine waves at high volume, fuggedaboutit. The 12V regulator instantly jumps to 100C & shuts down.

There were definite compromises for cost. It would have more power with a PC power supply, but need a lot of space. A 19V laptop brick with linear regulator was the most compact. A lot of wires & heatsinks are flapping in the breeze. It's unsuitable for a vehicle.

Adjusting treble is a buster. The probe points for R1, R2, R3, R4 are shown. R1, R2 determine the treble. They're both 40k when the pot is centered. R1 or R2 is 62k when the pot is fully deflected. The resistances can be calculated by applying parallel resistor equations to the Baxandall schematic.

Bass can be adjusted visually, but the bass pots turn in opposite directions. Probe points for bass resistors are R3, R4. The EQ could be broken out to a front panel extension, but it isn't changed often enough.

The 12V regulator is adjusted with R5 & its output is measured at the cap terminals. Voltage must not exceed 16V or the caps will explode.

The output of the DAC is attenuated with R6, R7 before going to the front panel volume control. The...Continue Reading