Jack Crossfire's blog - Page 7 - RC Groups
Shop our Airplanes Products Drone Products Sales
Jack Crossfire's blog View Details
Posted by Jack Crossfire | Apr 15, 2017 @ 12:57 AM | 3,358 Views
The closest you'll get to a vintage computer might be the FT2232. It's 1 of the older FTDI chips, but apparently still in production, widely available, & quite capable. It's a dual serial interface. The high end is the FT4xxx line which are quad serial interfaces.

The trick with the FT2232 is to not use the commercial drivers, but use libftdi. Most of the commercial drivers don't support it but libftdi does. Also, libmpsse provides limited abstraction of libftdi into SPI, I2C, & GPIO interfaces, but it doesn't allow simultaneous GPIO control & hardware protocols which the FT2232 does allow & it has many bugs. The trick is to refer to libmpsse to get the command structure for the hardware protocols, but directly call libftdi commands in your own program to control the GPIOs.

It's not clear how he figured out the command structure besides sniffing packets as they went through libusb. FTDI doesn't document it anywhere. Fortunately, it's not a very complicated protocol. The chip doesn't have any concept of GPIO, SPI, I2C modes the way libmpsse does. Libmpsse just uses mode settings to determine what commands to send, but the chip can accept any command in any mode.

The hardest part is figuring out the pins labeled GPIOH & GPIOL are ambiguous. What's really happening is all the pins labeled ADBUS are GPIOs written in a traditional 8 bit GPIO register & all the pins labeled ACBUS are written in another 8 bit register. They can be...Continue Reading
Posted by Jack Crossfire | Apr 07, 2017 @ 01:15 AM | 3,347 Views
It was a long & hard process between 1 month of commutes, but Heroineclock I was finally shut down after 13 years of blinking & replaced by a much better Heroineclock II, factoring in much more experience.

Introducing Heroineclock II (4 min 0 sec)



All the Chinese options which appeared in the last 13 years were studied & found to be too expensive. The largest Chinese digits were 12" tall & $50. EL wire would cost a fortune. Projectors were too dim & small. Superbright red LEDs had dropped from 22c to 15c & become much brighter.

With the new experience, power consumption dropped from over 20W for Heroineclock I to 7W, yet light output increased greatly. The audio synthesizer was much more sophisticated, with 3 square wave oscillators & decay timing. The clockspeed was increased from 20Mhz to 40Mhz to allow the improved audio. The new speaker driver was a real PWM driven class D with the 0 crossing at 50% duty cycle. The speaker brought the total current with all the LEDs & sound to 0.6A.


The flaky buttons & switches which plagued Heroineclock I were replaced with an IR remote. It was a 1st experience decoding an IR remote & it revealed IR receivers don't output RS232 but PWM. The decoding had to be really schmick for it to handle the rapid button presses involved in setting a clock.


The shift registers which drove Heroineclock I's LEDs were replaced by direct wiring to 1 GPIO per segment....Continue Reading
Posted by Jack Crossfire | Apr 03, 2017 @ 02:20 PM | 4,547 Views
The answer is yes, you can change the voltage of a laptop power supply, within limits. It was long dreamed of changing a 12 year old, 20.5V, 6A deal into a more useful voltage. 1st was discovering that it could be opened. 2nd was discovering there was a common circuit in most power supplies. It could be probed for by providing DC to the output instead of connecting the manes voltage. With the output powered, look for 2 inputs of an op-amp. 1 input should be around 2.5V, the other input should be a ratio of the output voltage.

The ratio is determined by a resistor divider. In this case, it was an irrational number around 15 for the high side & a complicated network for the low side. Decreasing the high side would raise the op-amp input & lower the output voltage.


Whacked in a parallel 47k which reduced the output to 16V, but what the internet didn't say was on a scope, it was a sawtooth. With load, it was 8-16V. Without load, it was 14-16V. Whacked in a 100k & 1 meg in parallel to finally yield a voltage of 17.9, right on the edge of where it became unstable but .1V low enough to power the Accucel 8150. Another 1 meg in parallel threw it off.


The problem is it needs a minimum voltage to power itself. It tries to bootstrap itself when it turns on, but if the minimum voltage isn't reached, it indefinitely tries to bootstrap itself. That's what generates the sawtooth waveform.

The 2.5V reference is generated by a Xena diode labeled 1273. It's...Continue Reading
Posted by Jack Crossfire | Mar 30, 2017 @ 08:36 PM | 3,394 Views
They pushed the reentry velocity a bit higher on this one. The grid fins were molten hot right when the video died. It looked like it burned up, but it reappeared after a successful landing. The 2 lower grid fins got a lot hotter than the upper grid fins, showing an attempt to use the fins to pitch the rocket. You'd think it would be more important to slow it down by spreading the heat between all 4 grid fins than change the angle of attack by sacrificing 2. The rear end probably got hotter.
Posted by Jack Crossfire | Mar 21, 2017 @ 01:16 AM | 4,239 Views
So today, the Alphabet corporation finally closed down the party by disabling the last of the downloadable API's on youtube. 4kvideodownloader & movgrab no longer work for any videos. No more 4k video unless your connection & browser are fast enough to play it in realtime. No dynamic range compression besides what a piece of hardware connected to your headphone jack can do. There's a slight chance someone may find another back door. There should be another back door as long as playback is supported on a browser, but the current generation doesn't have any interest in making things work.

With cleverly hacked software, 4k was glorious on 7 year old hardware that couldn't play it otherwise & an internet connection only fast enough for 640x480.

Still remember 8 years ago, when it was as simple as renaming files in the browser cache & the entire video was a single file. They played cat & mouse games for 8 years, constantly obfuscating the API in new ways. It's not whether something can be done anymore, but whether anyone has the interest or the intelligence.
Posted by Jack Crossfire | Mar 15, 2017 @ 01:52 AM | 4,270 Views
A vision of the pad if they tore down the shuttle service tower. The transporter erector starts to echo futuristic architectural elements of the Mars rocket service tower. The shuttle service tower will never be torn down because it has a lightning pole & locations to put cameras. NASA had to tear the 39B tower down because they envisioned a much bigger rocket.
Posted by Jack Crossfire | Mar 13, 2017 @ 02:55 PM | 3,885 Views
Finally conceeded that the hardware in a cheap ESC isn't fast enough to make a continuous sine wave stepper controller. That's why we do minimal tests. But it can step in 120deg increments through the sine wave by only modulating N's. The reduced precision was probably good enough, but the FETs still got too hot when the motor was stalled.


The scope showed all the voltage drop in the FETs, so they were putting out 12W. The motor has to provide a minimal resistance greater than the FET resistance. Then ohm's law transfers all the voltage drop to the windings & the ESC can reach its ratings.

A custom, super motor driver is required, with active cooling & FETs placed farther apart with heat dissipating pads. The supply of Hobbyking 35A's will probably never be used, so the parts could be recycled. It would still be expensive. The ATMega pinout could be rearranged for hardware UART & encoder feedback. 2 Hobbykings would be combined on a single board, with all the FETs on the center of the board under a fan.
Posted by Jack Crossfire | Mar 11, 2017 @ 07:42 PM | 3,789 Views
1 thing missing from modern videos about retro computing are case studies of how specific games were implemented. It was the rage, 30 years ago, for magazines to write about how the use of sprites, character sets, bitmap graphics, & raster interrupts made up a certain game. All the modern videos are just introductions to what sprites are. The current generation just can't grapple with the level of material we understood 30 years ago, so everything has to be simplified down.


It's become clear that a lion will never use a retro computer for anything. As intriguing as making a game in 6502 assembly, with the graphics hardware of the time is as a challenge in itself, there's no practical reason. It can be a game to make a game as it was done 30 years ago, but it's only going to be fascinating to see it done by other people.


The most retro computing which is still practical is a stopwatch in a single C file, with no dependencies, which is legible in sunlight. It could run as long as there's a C compiler & VT100 emulator. Python graphics libraries would be a more modern minimal way, but if the score is based on achieving the most with the least on modern hardware, the winner is the C console program.
Posted by Jack Crossfire | Mar 08, 2017 @ 10:27 PM | 3,966 Views
After 2 weeks, the Ruckus finally pulled off an 8 miler. It took 2Ah with no payload. It got the very last STM32F405, downgraded headlights to save power, & yet another conformal coating. The STM32 is truly overkill. When this one goes, it may get a redesign with an ATMega328. The mane obstacle is converting 2 UARTs to software. The differential is going next.


When the differential goes, it'll be time for a new vehicle. A wheel base as narrow as the Ruckus but capable of carrying Lunchbox payloads is highly desired. Cargo emerged out of nowhere, after the Ruckus arrived. These vehicles ceased to be merely visual pacers. The grocery bag ban gave cargo another step up.


The Lunchbox is11" wide. The Ruckus is 7.7" wide. Prices have come down, in the last year.

A good deal:
https://hobbyking.com/en_us/h-king-s...buggy-rtr.html
8.5" wide
Posted by Jack Crossfire | Mar 07, 2017 @ 11:02 PM | 3,664 Views
With the 18A cannibalized for fixing the Ruckus, the stepper motor switched to a 35A which didn't work at all.


The 1st problem was the same locking up of the FETs on startup & burnout. It wasn't a defect. Current from the UART retained the register contents when the ESC was off. It never happened in practical vehicles, probably because all signals were off at the same time. Zeroing the registers as soon as it boots up got it to work, sometimes.


The required deadband when switching MOSFETs was 24us on the 35A instead of 9us on the 18A. Probing the gates revealed an incredibly slow rate of turning off the P FETs. It just seemed to be a fact of life with cheap hardware. The simonk firmware doesn't PWM the P FETs, so it's not an issue for commutating motors. The stepper motor does PWM the P FETs. Simok also turns off all the FETs 1/3 of the time to detect back EMF.

The stock 35A P FET turned off faster than the stepper motor P FET, so there's some variability.
Posted by Jack Crossfire | Mar 06, 2017 @ 01:20 PM | 3,414 Views
The software fuse completely failed when powering the ESC because any practical load has multiple USB dongles connected to it. The USB dongles pass ground from the load to the USB dongle connected to the fuse, which goes to the supply GND. The easiest solution was to cut V+ instead of GND.


Also decided to put back the 3DR's BEC module. It would now not work below 6V instead of 2V, but it would lessen the chance of another misplaced connection.


Even better than a software programmable fuse would be a software programmable fuse which recorded the maximum current usage & the amount of time the current usage was over the limit. There were also a few old time text effects allowed by VT100 emulation, to more clearly show the user configured areas & when the fuse was active. VT100 character formatting is definitely an underappreciated area of microcontroller development.


It was quite convenient being able to control the power from the same console as writing the firmware & viewing the load output, but probing the load was now difficult. The fuse defaults to off, so turning on the load requires sitting at the fuse console. Ideally, the fuse could be controlled from a phone, but there are no phone apps which access a serial dongle & provide a remotely bearable VT100 interface.


The maximum current readout often shows bogus values because the 3DR current sensor isn't reliable below 6V. The Mastech always cuts the voltage during an overcurrent condition, so the fuse always shows current higher than the Mastech could provide.


The 3DR is definitely a limiting factor, but it would be pretty rough to replace it. A custom op-amp would need rail voltage higher than the load voltage.


The fuse definitely ended up worth the investment. MOSFETs were instantly heating over 60C, but the cases were staying cold. Only the source pins carried the heat. Being able to automatically drive short bursts of power & record the maximum current is required.
Posted by Jack Crossfire | Mar 02, 2017 @ 11:30 PM | 4,081 Views
The next servo lasted only about as long as the last one, despite being a Futaba instead of Horizon's own overpriced one. What should have been a simple replacement ended up being total destruction of the electronics by plugging in the wrong cables. Plugging the battery balancer into the ESC header fried the PWM GPIO because that was the 8.4V line. The tach GPIO survived because it was the 4.2V line. Then pulled it out & plugged the ESC into the servo header. This fried the ESC because the tach pin connected to the servo's 5V line. The tach pin forced a P FET on, frying it. 2 days of repairs thus began.

If only it was as easy as buying a new ESC down the street. Recycling FETs from other ESC's managed to revive it. Put a diode in the tach line, so plugging it into a servo header wouldn't send current to the P FET. It was easier to shuffle parts than flash a new ESC. Fortunately, the fried PWM GPIO was driven by software & plenty of pins were brought out to debug pads, so it could be easily swapped. Only the single GPIO fried instead of the entire chip.

Couldn't find a better solution than just labeling the battery balancer & not plugging it into a servo header.

Helas, after 5 more miles of driving, the ESC failed stuck going forward & the CPU lost communication. Other parts of the CPU may still have been fried. The Ruckus's duties had already been curtailed in the last 3 months, so it isn't a big loss if it goes on a long vacation.
Posted by Jack Crossfire | Mar 01, 2017 @ 01:30 AM | 4,172 Views
Instead of hacking the Mastech to detect its current limiting LED, it was decided to make a standalone fuse which was fully programmable from a serial terminal. It was finally a use for the ancient 3DR current sensor. Merely plug the fuse into a USB port & it provides its own console interface. It requires 5V from the serial dongle. The load & power for the load are on a separate circuit from the fuse.

It was the 1st programming of an 8 bit PIC in C, with the official MPLAB. It was also the 1st use of a C program on a point to point soldered, through hole chip. All those years of assembly language with the free gputils & nedit weren't worth it. MPLAB on even a Mac is lightyears faster. It has all the navigation & autocompletion functions of other IDE's. It has handy displays of memory usage. The compilation & flashing is automatic. The crippled features of the commercial compiler don't matter. Many commercial products are made with unpaid versions of the compiler.

The fuse program used 80% of the PIC's 4k of ROM & 20% of its 256 bytes of RAM, but probably a lot more of its stack. It needed a few 32 bit operations to handle current & time conversions. It needed routines for persistent settings & a menu interface. It wasn't a huge amount bigger than an assembly language program.


The original idea was to have just a bag of analog comparators & RC timers. After LTSpice proved that to be very complex, it moved to a...Continue Reading
Posted by Jack Crossfire | Feb 25, 2017 @ 03:59 PM | 3,893 Views
Managed to get the ESC up to 16khz without resorting to assembly language, while keeping the software UART functional enough for testing. The trick was making a longer table of events with simpler operations to perform in the interrupt handler. Each event contains a value to copy to the timer & a value to write to the PORT. The long term plan is a 2 wire SPI with the ESC as a master.

At 16khz, the motor was super inefficient. It had to be reduced to 8khz to get any movement. At 8khz, it was still taking a lot more current for a lot less power than before, but it was much quieter than the previous 6khz routine. The only difference was the ability to have multiple FETs in the deadband between P & N, simultaneously. The table still goes from N to P without a deadband.

Discovered the MOSFETs were getting extremely hot, even below 3A. It was a Supersimple 18A but it overheated under 3A. Somewhere during the 16khz upgrade, all of the MOSFETs got fried & were intermittently short circuiting, despite the power supply being limited to 10A. We all know about current spiking when a motor is stalled, but whether stalled or short circuited, these were limited by the power supply to much less current than when they hovered a quad copter.

So for motor testing, the power supply needs to limit time more than current. Besides burning up a bag of ESC's, the next step would be a smarter power supply which shut down if the current limit LED stayed on too long. Even better would be not relying on the LED but a table of times vs current. Unfortunately, it's not clear if the LED was on when the MOSFETs blew.
Posted by Jack Crossfire | Feb 24, 2017 @ 02:57 AM | 3,392 Views
So when is spaceflight going to be like the movies, with multiple spaceships docking & undocking simultaneously & fast enough to discern motion with the naked eye?
Posted by Jack Crossfire | Feb 20, 2017 @ 01:08 AM | 3,474 Views
Spacex crs10 landing (6 min 12 sec)



The complete landing.


Spacex crs10 vs iridium1 landing (6 min 3 sec)
...Continue Reading
Posted by Jack Crossfire | Feb 18, 2017 @ 11:48 PM | 3,566 Views
Hobbyking 18A driving Hextronic DT700 as a stepper (1 min 25 sec)



It turned out just enough of the ancient DT700's were acquired over the years to make exactly 8 legs. 1 would have to be rewound & the exact number of turns is unknown. It seemed to be 19 turns in a delta. The ESC department has 5 Hobbyking 35A's, 1 Hobbyking 18A, 1 Castle creation 35A, 1 Align 35A. The last 2 are based on the 8051, so quite hard to reprogram.

They're amazingly still sold. They performed much better than the smaller motors. They could jump the load with only 12V. With active cooling, encoder feedback, reducing the lever size, they could probably just manage a slow bounding movement.

Active cooling has been deemed essential for any application. Even with active cooling, overheating still makes it impossible for them to hold the torque longer than a second. The mane problem with continuing is finding encoders for feedback.
Posted by Jack Crossfire | Feb 16, 2017 @ 01:37 PM | 3,323 Views
Hobbyking 18A driving 9 turn stepper motor (1 min 37 sec)



Call it ignorance about magnetic theory, but for jumping movement, 9 turns ended up better than 50 turns. Where the 50 turn couldn't jump at all, the 9 turn jumped the 140g load quite efficiently with very little heating, at 20V. Surprised the maximum starting torque as well as the maximum speed increased, since one would think the 2 would trade places. Holding movement suffered, since it could no longer hold the load without instantly overheating.

The power supply showed 8A being used for jumping & 3A used for holding. The holding current couldn't be fine tuned below that. Software PWM isn't precise enough. There's a way to theoretically determine the optimum turns count, but prototyping has proven faster.

Decided to use active cooling to reduce the risk of a burnout. A scaled down version of the Minotaur's bounding movement is certainly possible. It would start as a single leg with 2 wheels, to predict performance. It wouldn't stand up when not jumping.