Most of us have probably heard the old Tootsie Pop slogan, “How many licks does it take to get to the center of a Tootsie Pop?” [E-Smoker2014] had a similar question about his e-cigarettes. These devices are sometimes advertised with the number of puffs they are good for. [E-Smoker2014] had purchased an e-cigarette on a trip to Belgium that advertised 500 puffs. After a bit of use, he started to suspect that he wasn’t getting the advertised number of puffs in before the battery would die. Rather than just accept that the world may never know for sure, he decided to test it out himself.
There aren’t many details on this build, but you can tell what’s going on from the video below. [E-Smoke2014r] built a machine to artificially puff on an e-cigarette. The e-cigarette is hooked up to what appears to be vinyl tubing. This tubing then attaches to a T-splitter. One end of the splitter is hooked up to a DIY actuator valve that can open or close the port. The other end of the splitter is hooked up to more tubing, which in turn is attached to a plastic cylinder placed in a container of water.
To simulate breathing, the computer first opens the relief valve in the splitter. It then mechanically lowers the plastic container into the bowl of water, pushing out a bunch of air in the process. The valve closes, and the computer then raises the plastic container out of the water. This action creates suction that draws air in through the e-cigarette like a normal user would do with their lungs. The computer increases the puff count and then repeats the process, expelling any vapor out of the relief valve.
It’s only been a few months since the ESP8266 rolled out of some factory in China, and already the community is moving from simply getting custom firmware to work on the device to making the development tools easy to use. That’s huge – the barrier to entry is lowered, getting even more people on board with this very cool Internet of Things thing.
While the majority of the community is settling on using the Lua interpreter firmware, there’s still the matter of getting this firmware uploaded to the ESP. [Peter Jennings] of Microchess fame has been working on a Windows app to upload firmware to the ESP via a serial interface. There’s not much to it, but this will allow you to upload the community-created Lua firmware, set the WiFi credentials, toggle GPIO pins, and give you the ability to write a little bit of Lua in the same window.
If you’re looking for something that isn’t designed exclusively for Windows, there’s an alternative firmware flasher over on the nodemcu Github. This flasher also connects the ESP8266 to a network and uploads firmware. It’s a stripped-down programmer without a serial terminal or the ability to toggle pins, but there are plans for making this programmer cross-platform.
For some people, R/C cars just aren’t enough. [djMedic2008] has gotten his hands on a monstrous 1/5 scale wheel loader. The loader weighs in at 500lbs, and can lift up to 250 lbs. It was built several years ago as a prototype by [Richard] at Tiny Titan Earth Movers.
The design is based upon huge machines made by companies like Caterpillar and Komatsu. The 4WD system is driven a DC motor through a worm gear reduction. Bucket operation and steering are both operated by a hydraulic system driven by an electric pump. Just like the full-scale machines, the mini loader uses an articulated steering system. The front wheels are locked in place while the entire chassis bends at the middle pivot point. This allows for a much stronger solid front axle.
After several years of hard life, the loader came to [djMedic] in need of some TLC. The biggest issue was that the rear axle bevel gear had lost several teeth. This gear is under enormous loads when the loader is turning. A gear made of harder steel was the easy answer. Thankfully, you can order high carbon steel bevel gears from Amazon. The repair video gives us a look at the design of the loader. The main components of the machine are welded up from steel sheet and tube stock. This means that [djMedic] won’t have a hard time finding spare parts for his machine once he puts it to work clearing snow, dirt, or anything else that gets in its way!
Whether you are trying to drop some fat or build some muscle, it’s important to track progress. It’s easy enough to track your weight, but weight doesn’t tell the whole story. You might be burning fat but also building muscle, which can make it appear as though you aren’t losing weight at all. A more useful number is body fat percentage. Students from Cornell have developed their own version of an electrical body fat analyzer to help track body fat percentage.
Fat free body mass contains mostly water, whereas fat contains very little water. This means that if you were to pass an electrical current through a body, the overall bioelectrical impedance will vary depending on how much fat or water there is. This isn’t a perfect system, but it can give a rough approximation in a relatively easy way.
The students’ system places an electrode on one hand and another on the opposite foot. This provides the longest electrical path possible in the human body to allow for the most accurate measurement possible. An ATMega1284P is used to generate a 50kHz square wave signal. This signal is opto-isolated for user safety. Another stage of the circuit then uses this source signal to generate a 10ua current source at 50kHz. This is passed through a human body and fed back to the microcontroller for analysis.
The voltage reading is sent to a MATLAB script via serial. The user must also enter in their weight and age. The MATLAB script uses these numbers combined with the voltage reading to estimate the body fat percentage. In order to calibrate the system, the students measured the body fat of 12 of their peers using body fat calipers. They admit that their sample size is too small. All of the sample subjects are about 21 years old and have a similar body fat percentage. This means that their system is currently very accurate for people in this range, but likely less accurate for anyone else. Continue reading “DIY Electrical Body Fat Analyzer”→
This year’s CES has dredged up some memories. I had assumed that as one becomes old they are supposed to become used to memories of a young vigorous person that shared their body and memories leaving little else except some scars and some old stale socks lying around plus 2 or 3 pictures to prove it was in fact not a series of hallucinations. Turns out you don’t get used to it, you just endure.
30 Years ago was our CES: Commodore had the reputation of showing something new every CES and this was a time when a Home Computer meant a Consumer Computer. I have written before about how we endeavored to make sure other’s failures didn’t become ours and we did in fact make it, just in time, to the ’85 CES with what became our flagship computer, at least for the next 4 days.
To the Very Last Minute
1985 Commodore CES Booth
Commodore 1985 CES Booth: an “elegant” grey and yellow battleship parting the CES seas. (Marketings’ idea)
Putting 85 CES together. Pics courtesy of [Terry Ryan]
When I say made it just in time I am counting people hand carrying the last ten or so homebrewed and MOS cooked 80 column chips either the night before or that very morning. The C128 computers where waiting lined up and open in the room seen below; cases agape much like a row of baby birds waiting on whatever engorgement MOS had come up with for us as the seconds counted down.
And then finally we stood on the second floor of our booth (yes they built a 2 story structure for us in a couple of hours the night before) surveying the now working computers; C128’s and the never released LCD machine, when the last “issue” before the doors opened arrived; a Marketing person (panting) telling us of “yet another C128 failure” though she couldn’t actually point to any previous computers that had failed. We wouldn’t let her continue with her complaint until she retracted the previous general statement of failure, more on principle than actual meanness.
As with most highly technical in-the-field fixes this one was something to remember. My last act of “the ’85 CES show” became the simple motion of walking up to the “failed” computer station and pressing the key changing the C128 back to 40 column mode, especially important since it only had a 40 column monitor attached to it.
End of Line
Then something happened: We were done. I felt sub-processes actually end that had been consuming both CPU and I/O for months, I was suddenly unencumbered by the next “must fix”. I didn’t have a next task to pop from the stack… the phrase “End of Line” came to mind.
I was 24, in Las Vegas and had just delivered one of the major products for the best computer company in the world to the only show that mattered to us. I started walking towards the door with the uncommonly bright Las Vegas sun streaming through the windows. There were lines of people around the block waiting to enter, but the exit was completely unobstructed.
I buried myself in Las Vegas in a way that only youth, testosterone, and adrenaline can enable.
Making the Rounds
I won’t report here much of what all was done over the next days as I understand that for some things the statute of limitations never truly runs out, but inspired by [Mike’s] reporting of visiting the suites of the companies I will relate one small tale here: I had grabbed my best friend and fellow hardware designer who was the father of the 1581 disk drive, also successfully released on this day, and headed out. With the 6’8” [Greg Berlin] (grandson of the designer of the Curtis Wright P-40 Warhawk) in tow we started hitting the floors of the local hotels looking for the suites of the “important” companies that never managed to personally invite us. We had a secret weapon that opened doors as if bribed; not in Greg’s towering presence but in the simple phrase: “we’re from Commodore”.
Doors fully opened that had previously opened only 12-14 inches only to stop on the shoe of the doorman, and 5.25” floppies were stuffed in our pockets like the $20 bills of a VIP trying to impress his date. The suite that comes to mind was that of Electronic Arts (EA). With backslaps and copies of this year’s (and a few of last year’s) C64 game floppies shoved in our pockets we were welcomed like old friends; appointments were made and more than a couple of chugging contests were held. They lost or at least didn’t better us as we were young and full of testosterone.
As we made ready to leave the good folk of EA, after making sure that we would swing by their booth the next day (we did), they asked if there was anything they could get for us. This may sound like a strange or gratuitous question but I had already spied the case of Michelob (a beer from the early days of 1 micron silicon) and was pointing to it before the question was fully uttered. EA grabbed the case with no hesitation as I turned to face the door so he could set the case of teardrop shaped bottles on my shoulder for me.
Back out into Las Vegas we went with Electronic Art’s beer on my shoulder… It was a good CES.
A few months ago, the Intel Edison launched with the promise of putting a complete x86 system on a board the size of an SD card. This inevitably led to comparisons of other, ARM-based single board computers and the fact that the Edison doesn’t have a video output, Ethernet, or GPIO pins on a 0.100″ grid. Ethernet and easy breakout is another matter entirely but [Lutz] did manage to give the Edison a proper display, allowing him to run Doom at about the same speed as a 486 did back in the day.
The hardware used for the build is an Edison, an Arduino breakout board, Adafruit display, speaker, and PS4 controller. By far the hardest part of this build was writing a display driver for the Edison. The starting point for this was Adafruit’s guide for the display, but the pin mapping of the Edison proved troublesome. Ideally, the display should be sent 16 bits at a time, but only eight bits are exposed on the breakout board. Not that it mattered; the Edison doesn’t have 16 pins in a single 32-bit memory register anyway. The solution of writing eight bits at a time to the display means Doom runs at about 15 frames per second. Not great, but more than enough to be playable.
For sound, [Lutz] used PWM running at 100kHz. It works, and with a tiny speaker it’s good enough. Control is through Bluetooth with a PS4 controller, and the setup worked as it should. The end result is more of a proof of concept, but it’s fairly easy to see how the Edison can be used as a complete system with video, sound, and wireless networking. It’s not great, but if you want high performance, you probably won’t be picking a board the size of an SD card.
[Robert] has been snooping around Naenara in order to learn more about how North Korea’s intranet might work. Naenara is the web browser that comes bundled with North Korea’s official Linux-based operating system known as Red Star OS. [Robert] once saw a screenshot of the browser and found it interesting that the browser seemed to automatically load a non-routable IP address immediately upon start-up. This made him curious about what other oddities one might uncover from the software.
Upon start-up, the browser tries to load a page located at IP address 10.76.1.11, which is a reserved IP address for private use. This indicated that North Korea’s “Internet” is actually more of in intranet. [Robert] suspects that the entire country may be running in private address space, similar to how your home or business likely runs.
[Robert’s] next thoughts were that the browser looks like a very old version of Mozilla Firefox, but with some default configuration changes. For one, all crashes are automatically transmitted to “the mothership”, as [Robert] calls it. He suspects this is to fix not only bugs, but also to find and repair any security vulnerabilities that may allow users more control.
There are some other interesting changes as well, such as the supported security certificates. The Naenara browser only accepts certificates issued by the DPRK, which would make it very easy for them to snoop on encrypted HTTPS traffic. there is also evidence suggesting that all traffic for the entire country is routed through a single government controlled proxy server.
None of these findings are all that surprising, but it’s still interesting to see what kind of information can be gleamed from poking around the browser and operating system. [Robert] has found more than just these few findings. You can check out the rest of his findings on his blog.