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.

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.

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.

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.

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.

Manely showing off the 4 channel scope.

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

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.

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.

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.

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