John Beans


Jolly Logic designs and manufactures flight electronics for model rockets, drones, and planes.

John Beans

's contributions
    • Sigh. This seems to be an area where the Perfect will be the enemy of the Good. Is the standard for robotaxis that they kill no one, ever? Meanwhile, over a million people die in traffic deaths each year. We have come to accept that, and it doesn't seem to factor into what we demand of autonomous systems. People are not so great at driving. They text, they drive drunk, they swerve over three lanes to avoid missing an exit, they fall asleep, they tailgate, they reach for snacks, they get road rage. All things an autonomous vehicle will ever do. Discussions such as this will seem antiquated once neural networks have been developed that are decisively much better at driving that people. It's just like when they were trying to develop a neural net to play chess. "It will never beat a Grand Master." Then it beat one, once. Now it always wins. "Oh, but the game of Go has more possible scenarios than molecules in the universe." Again, first it beat a master, then it beat everyone. Then they developed a second neural net that beat the first one every time. "Oh, but it can't win a complex computer game..." You get the point. It never looks like a computer can do something. Until it does. Driving is like that.

    • As a product designer, it's hard to compare two approaches without also considering cost and power consumption tradeoffs. I'd love to see a comparison of some hypothetical IOT application (SPI bus, two timers, simple math, 8K of RAM storage for variables and data buffer) compared in terms of cost and power consumption. But IOT may be a poor setting for FPGAs, though, since IOT apps aren't especially performance-critical compared to, say, image filtering. And maybe you'd never implement such an app in FPGA when you could get a $0.92 MCU that sleeps at less than 1uA...

    • Old HP calcs are still known for their key feel, and a 31CX got me through two engineering degrees. I'm still nostalgic for the alphanumeric font they used. But It's super sad to hear how much of the design was outsourced on this current model. HP is a hollow shell of its former self.

    • I've always loved (and used) Microchip parts for the peripherals. This part furthers that tradition. *However*, as low power design has become increasingly important to me, I find I most now have to pay more attention to certain low power features that Microchip has not kept up with, such as rapid wake-up. For instance, you can find competing parts that might have slightly higher per-megahertz power consumption, but that wake up in 1uS. In other words, the competing part can wake up, do tasks, and go back to sleep (at ~1uA) before the Microchip clock has stabilized. So I'm waiting for these low power features to come to Microchip before I design futher product with their MCUs. No one likes switching MCU families, but since I've had to do it already, but now that we're spread across a couple, we've got flexibility.

    • Well *of course* I already knew about your article, since that's why I bought the uCurrent in the first place. Good tip about the new 300kHz Gold Edition...

    • What should be interesting is why only the 9V was designed to prevent reverse bias. If you're one of those people who thinks they notice problems others miss, ask yourself why you've never complained about most battery shapes before. Billions of units later, and they still design batteries that won't work 50% of the ways that they can go in a product. Kind of odd, huh? If you try for a moment, you can think of plenty of ways to design batteries that only fit one way. It's almost like battery designers are messing with us. They must say things in design meetings like, "Hmmm, should we lighten up the etch on the + and - a little more? I can almost see it under room lights." Design meetings. As if.

    • My impression is that most designers make a mental jump right from "GUI" to "a graphics library running on an RTOS." That immediately moves you into a power-hungry, more expensive realm of both hardware and development tools (at least for the tools pros use). Good luck getting that thing work battery-operated. However, what is less appreciated is that for very little additional cost, a bitmapped LCD can come equipped with an embedded graphics controller chip so that you can just send SPI commands to the LCD. We're talking LCDs that cost just a couple of dollars in quantity. My most recent products, which have bitmapped fonts and scrolling animation, are driven by a PIC microcontroller with no LCD driving hardware of its own. I wrote tiny libraries to render the fonts, and constructed easy-to-use functions like display(text, size, line, column), clearLCD(), etc for use by my apps. While it may seem a chore, these are trivial (but I found fun) routines to write. I would encourage designers of embedded devices to get closer to the metal on their GUIs. It's no big deal, and frankly if you don't understand your display needs well enough to write routines to display it without a giant flexible stack of third-party code, you've got a product requirements problem. If you knew how little code it actually took to render your final result "from scratch" you'd be amazed at how small, fast, and affordable it is. I'm just saying...

    • I'm very grateful for the fundamental analysis you're posting here. I make small devices and wrestle with battery life, capacitors, and MOSFETS all the time. Love the work you're doing. Please keep at it. You can include some analysis of voltage regulation, too, if you like. Really, power consumption has to be looked at from whole system perspective, right?