So the up arrow had been glitching for a while. Lowering the radio power, not probing it when transmitting, making the debounce longer didn't fix it. The microscope revealed a spot of green, the sign of water damage. The clamshell wasn't keeping sweat out. The next step is what worked before, cleaning off the corrosion, a dab of hot glue acting like a conformal coat. This is all because the board doesn't have a solder mask like every toy. The speed buttons actually do have strong pullup resistors, the 3 10k's.

What began in 2014 ended with all the plastic parts getting thrown away, after many thousands of miles. They were worn to bits. The 1st one ended up being the last one, with the 2nd one falling apart much sooner & getting torn down last year. Only the farsteners, electronicals, transmission, & metal parts remaned. Much was learned from it & it was all applied to the newest 3D printed trucks. The 3D printed trucks have the heart of the lunchbox, but they do the job much better.

The G-buggy, ECX Ruckus, & H-king Sandstorm were kind of forgotten. They only lasted a year while the lunchboxes could go forever.

There is still some belief the 2 transmissions from the lunchboxes may have a use. They're noisy. There's only 1 functioning motor. They provide a lot of torque at high RPM, but none at starting RPM. No mechanicals from any past vehicle were ever reused.

Pole cam speed test (15 min 57 sec)

Came out to 9.8MPH going down hill with a tail wind. The days of 10mph footage are over until a bigger motor is installed. The thought has occurred of installing forced air cooling, since the motors are now sealed.


How a simple bearing became a monster. Some complexity came from not wanting it to require tools. Since it requires tools anyway, it might as well undergo a simplification. There's a growing list of improvements for it, yet all it does is pan. There's also a desire to bolt it onto the side panels.

The battery recharge went a lot faster with the radios just 5db lower, but the speed button continued glitching. The next theory was a mechanical defect, so it was replaced. Fortunately, the radios made it without requiring a power cycle.

Ended up keeping frequency hopping on, adding more bytes to the preamble, reducing the power by 5db, taking the current channel out of the packet. There's no way the channels are ever going to crosstalk. A longer preamble might help with any framing errors. The RFX1010 datasheet has a saturated output power of 27dbm, a gain of 28db. The Si4421 says it outputs 7dbm. So it would need at least an 8db cut to avoid clipping the amplifier. The mane impact of clipping would be harmonics & power usage, rather than any data loss.


The speed buttons started glitching, which may have been from the battery dying & the voltage sagging from the amplifier. Reducing the power might help with this.


Even after 15 years of hacking custom radios, there's always more to do.

So there was the problem of phone towers overlapping the 915Mhz ISM which was fixed by adding more power, but there were still occasional losses of signal away from phone towers. There was a software change to send the channel number inside the packet, in case there was crosstalk. This only made the signal losses worse.

It would work perfectly for several minutes, handling errors, then just recieve 1 packet every 2 seconds. It was always a constant rate of reception rather than a total loss of signal. It would scan, immediately get a packet, enter hopping mode & get no more packets. Then it would time out after 2 seconds & scan again, immediately getting a packet. Power cycling either the transmitter or receiver made the problem go away for a few more minutes. It didn't depend on how far away the radios were or the error rate.

It became a lot more reliable just by adding debug statements to the receiver. The debug statements caused the UART receiver to overrun, so the UART had to be reset, which might have been 1 problem. The UART registers showed frequent framing errors, which might have been another problem. This UART scheme had been used for years without getting into a permanent framing error or buffer overflow, though. The mane difference might be those applications didn't turn the radio off between every packet. It could require a software UART on the receiver if it's a permanent framing error.

This was impossible to debug without a spectrum...Continue Reading

The answer is yes, lions have gotten fatter since the last container was printed. It's probably been going on ever since the 1st container in 2015. As the containers have gotten bigger, the amount of food has indeed increased. Once you realize 1 more noodle container fits, you always put it in. Overheating motors have not deterred lions from stuffing in as much as possible. There's always a need to find the maximum capacity.

At least the steering since the software I2C has been rock solid.

So there was delamination in a tire, giving a vote for tapered edges. Only the left tire delaminated, showing it was a problem with the 1st layer in the printing process.

The mane problem was both motors got flaming hot again. This time, the left motor seized up. It's definitely from pulsing the throttle with a heavy payload. They burned 1.5Ah to go 2 miles. If the throttle is constant with a heavy payload, it gets by. The bolts started flying off, despite being impossible to turn by paw. M2.5 bolts are so expensive, it might be easier to replace the entire motor.

It's still nominally burning 350mAh/mile with a payload & softer tires in front. It may be time to upgrade the front tires. Motor seizing happened with the original hard tires.

The next revision of camera electronicals began. It's getting the full frequency hopping 500mW.

The lion got dehydrated & was walking by the end. The robot burned 300mAh/mile with 9Ah of batteries & food. Went back to the original idea of a soft starting throttle which goes into auto when it's 100%.

Inductive charging for the paw controller is just as problematic as a JST connector. The mane problem is all 5V phone chargers have protections against a number of conditions. If there's no load for a certain amount of time or if there's a load for too much time, they shut down. You have to use an ATX power supply, a dedicated raspberry pi power supply, or a mean well, which are all too big & expensive.

It was time to return to the original wheel design, with a much larger diameter. It turned out the PLA hub has no meaningful mass difference from PETG, so it might as well be PETG for the higher temperature. This design had retaining rings glued on the hub, which were a disaster to glue on. A better idea might be diagonal overhangs. Then, there was adhesive to keep the tire from freewheeling.

It held the hexogrid tire on in an 11 mile drive. Power consumption with 1 new tire & 1 old tire was 254mAh/mile with 14oz of food.

Getting such a large clamshell to keep the wheel in place is tricky. It might be easier with a traditional block of infill or spokes. Lions just hate having any material which isn't visibly appealing.

5 miles went down like a brick. The webbing kept the tire from sliding 1 way, but the adhesive did nothing to keep it from sliding the other way. The result was part of it sliding away & part staying in place. That rules out farstening at any single point. Too bad TPU can't stretch like rubber.

Been putting off upgrading the camera controller because it's so rarely used, but it definitely needs an amplifier.

As these things tend to do, the stakes have been raised to get a reasonable combination of traction & range. There was a partial hexogrid tire which proved too soft for the cost.

Because it takes so much more material to make a flat tread stiff enough, the decision was made to go back to a PETG hub with a thin TPU tire. This would limit the compression if the tire completely compressed. Helas, PETG is noticeably heavier than PLA, despite its heat resistance. It could probably get away with PLA since the motors rarely get flaming hot. The biggest weight savings may be abandoning the hexogrid. Like the SpaceX logo & the isogrid, sometimes you just want it to look good.

The lion kingdom has evolved its 3D printing game to the point of making the thinnest possible lines & planes with the thickest possible layers. The .4mm nozzle can print a .5mm wide line but takes forever. The .8mm nozzle can print a .9mm wide line but is much faster.

Since the tires slip around the hub, there's still a dream of bolting the tires to the motors, but they now have to transfer force a lot farther across a much bigger hub. A 7 hour tire with webbing had good compliance, transferred rotation to the motor, but easily slipped sideways. It would need some kind of adhesive, whether it bolted to the motor, if the hub clamped it as before, or if it clamped around the hub. It might as well be a plain cylinder.

After the 13 mile fiasco, some documentation of tire compression with a typical payload. It clearly is a matter of traction vs stiffness. The flat treads need a lot more material to be as hard as the curved treads, but are necessary for any traction.

A tire with a slightly curved tread didn't get any stiffer. Changing the number & straightness of the spokes didn't make a significant difference. Putting the extra spoke material into more tread thickness might make it stiffer. Printing spoked tires with .4mm layers takes only 2.5 hours.

There is a new honeycomb design with a flat tread & integrated motor mount, but it takes 10 hours & the lion kingdom is low on filament again.

A 13.75 mile drive with a decent payload went slowly & ended in battery death. The increased traction of these tires wasn't worth the reduction in range. It actually hit a wet patch & spun out, but these tires have never spun out as much as the stiff ones. It burned 335mAh/mile, still in line with the lunchbox but real slow.

The motors couldn't go very fast with the full payload on level ground & that was the deal breaker. There could be a new tire with a very slight arch to bring back just enough stiffness without requiring tons of material. Real car tires are flat, but it takes a lot of material to make them stiff.

What's needed is a tire which can be made stiff when it has a payload & flexible without a payload, without air pressure. Having a variable diameter based on desired speed would also be a win.

presets (0 min 48 sec)

So much easier to wake up when it repositions itself.

Until the 5060 motors. Another 9 miles without any food but at higher speed burned 260mAh/mile. Those flat wheels might be burning more power for the improved traction.

These were manely to get more cushioning in front. Same softness settings. Really awful overhangs. The tire empire continues growing. Surprising how these never seem to wear out, after years of trying to keep the Tamiya tires alive with every known material.

10.8 miles later with a lot of food, it only burned 260mAh/mile. Surprising, considering the wheels have more contact area. The tachometer is definitely slower with the compression.

It was the 1st TPU tire which actually compresses under the weight of the battery. The mane reason is the flat tread. Curved treads were all hard, with no amount of curving making any difference in the hardness. The flat tread has some risers along the edge to keep from digging in, but is very flexible.

Stringing in the tires is actually less if they're printed in timelapse mode.

Tried adjusting the number & curving of the spokes, but it's either going to require a lot of money or finite element analysis to get the perfect hardness. The 1mm PETG hub cap is horrible. It would have to be 1.2mm with .4mm walls & .4mm infill to look as decent as the old one, in which case it would trap more heat.


Then of course, the bumper finally got stripped down to make it softer. Getting the right amount of softness without finite element analysis is an expensive process.


These did quite well in their 1st drive, burning 233mAh/mile & getting much better traction. About time to print new front wheels in the interest of a softer ride. Lions hung onto the idea curved treads could be as soft as flat treads, since they would use less material, but it seems flat treads are the only way....Continue Reading

Completely rewound a motor only to find no obvious damage in the windings. It probably wasn't burned out. The PLA parts which clamped down the tire all melted, so the tire was freewheeling. There were also rocks in the motor, despite all the effort to shroud it.


The long term solution is new tire wheels which bolt on the motor & eliminate the PLA parts completely. The tires used PLA hubs to reduce costs, but the cost of the TPU & the amount of material has been reduced enough to make a single piece tire wheel possible.

The new tire has a larger flat area for traction or applying silicone, 2mm smaller diameter, thinner hub to improve heat dissipation. This required eliminating the X. There could be a metal hubcap on the outside to dissipate more heat. More revisions to follow.

The bit banged I2C was successful in ending the steering glitches. There were other failure modes where a bad connection to the servo caused it to permanently die & the radio continued to sometimes die, but so far the mane failure mode seemed to have been I2C.

The next mane problem is the motor. Although it didn't seize up for another 8 miles & it didn't get smoking hot, it did continue to slow way down under easier loads than the past. The battery was 10.3V & hot. The right motor is believed to be damaged from past heating, so it's just shunting a lot more current.

Those 5060 motors are expensive, but they're not going down in price. Lions remember 2006, when all brushless motors were over $100 & made in east Europe. Then, low RPM Chinese motors came along for a fraction of the price. There isn't a cheaper option coming along to replace China & there isn't going to be an end to any tarriffs.

1 source of erratic speed was finally narrowed down to integral windup. It took a long time to slow down when a load came off. Integral windup is a bigger problem in an underpowered vehicle than it was in the sufficiently powered lunchboxes.

Right wheel seized up again & overheated. It spun freely by paw, but not by the motor on the ground. This time, after letting it cool down, it started spinning again by motor. This is pointing towards a clearance problem with the shroud & a feedback loop where the motor warms up, starts rubbing, warms up more, rubs more. The overheating melted the PLA some more. The left wheel didn't seize up & stayed cool, so they can probably handle more current if they have enough clearance.


Printed a new retaining ring with 3 layers & installed with the horizontal expansion side up, to try to get it to stick more.



After 10 years, it was time for a rematch with the I2C glitches, as steering frequently froze up. The latest change froze the servo when I2C locked up, instead of steering erratically. It was little improvement.


10 years ago, I2C on the STM32 was assumed to be vulnerable to electrical glitches. Lions resorted to limiting I2C to 150khz & shielding the I2C cables, which worked most of the time. In the last 5 years, the internet started to lean towards a hardware bug involving concurrent register writes & recommended bit banging all I2C.


The lion kingdom always had a bit banging I2C driver, but burst mode never worked & bit banging is too slow without burst mode. Revisiting the driver 10 years later involved printing the pin values in software rather than soldering on test points. Then, comparing the bit bang waveform to the...Continue Reading