tag:blogger.com,1999:blog-165783082024-02-02T03:18:34.106-05:00Copious Free TimeRamblings about projects I work on during my "copious free time" (CFT).toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.comBlogger239125tag:blogger.com,1999:blog-16578308.post-91130699162973238902019-10-02T11:44:00.001-04:002019-10-02T11:44:48.143-04:00Wandering Tag - Discreet GPS tag for people and petsIt's been a while since I've posted any ramblings. Those (few) souls who have been following my sporadic blogging and rants (thank you all dozen or so of you ;) may remember me going on about "<a href="https://toddbot.blogspot.com/search?q=elderly">elderly monitoring</a>" (I even had a side blog addressing <a href="http://eldermonitor.blogspot.com/">this</a>).<br />
<br />
An decenet Elderly monitoring system would include some lightweight tracking capabilities (i.e. for early dementia sufferers who tend to wander from the house).<br />
<br />
I've been working on and off of such a device. I kept running into walls regarding how to do long range communication of geolocation. Cellular is obvious but is costly, requires a "subscription" and is at the mercy of the telcos. I wanted something more in control of the user (consumer). Basically: No subscription needed.<br />
<br />
Enter LoRa. Well, enter LoRa like capabilities: hundreds of meters range RF. In testing some simple LoRa modules I've been able to get reliably around 800 meters (approx 1/2 mile), in a sub-urban (e.g. building, trees, hills, etc) environment, with a small trace antenna broadcasting to a large whip antenna (at 915Mhz). I should be able to get further but these initial tests were with conservative bandwidth and spread factor settings.<br />
<br />
This is actually an adequate range to track a "wandering" elderly person. When my mother-in-law lived with us and she would "take off" early in the AM (before we woke), we always found her within a quarter to half mile radius (siting on a bench or at the local McDonalds).<br />
<br />
In addition, this is probably adequate range for tracking pets (e.g. dogs that get out of the yard, cats that decide to go missing, etc). So, I'll probably focus on that as an initial target.<br />
<br />
I've gotten requests for pointers to "pet tracker" products. I found a few, with Amazon's <a href="https://www.theverge.com/2019/9/25/20883874/amazon-fetch-sidewalk-wireless-standard-ultra-low-power-devices-developers">Fetch</a> being the gorilla in the room. (Amazon's solution sounds like yet another way for them to gather more private data on people... I don't want to do that).<br />
<br />
Now, to be clear, I'm talking LoRa and not LoRaWAN. I know that there are asset tracking devices out there that do LoRaWAN (and rely on infrastructures like the Things Network). There are also "Tile" trackers that rely on social networks (i.e. people with apps installed on their phones that help the "community" find a lost pet).<br />
<br />
What I want is a completely private system that requires no external "subscription" or "social network". So, you would run a LoRa base station in your home (e.g. nothing fancy, maybe an ESP32 + LoRa + large antenna) and talk with it using your smartphone via Wi-Fi or BLE. The basestation would also be "portable" so you could take it with you (walking or in a vehicle) to do live tracking of the pet.<br />
<br />
Of course, it may make sense for you to use something like twilio to forward events to your smartphone when you aren't home, but that would be an option (not a requirement).<br />
<br />
I am working on this now and have made quite interesting progress. I intend the design and code to be open sourced (in particular: GPL'd) and there will be some interesting sizing as well as power saving tricks.<br />
<br />
More to come... stay tuned.<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-27197038549423609462019-06-06T16:03:00.005-04:002019-06-06T16:03:58.041-04:00Sleepy Bee to MSP430 to STM32L031... Woeful complexityI need a simple very, very low power MCU to form the basis of coin cell sized IoT sensor monitoring.<br />
Here is what it needs to do:<br />
<br />
<ol>
<li>Control the Semtech SX1276 LoRa chip via SPI</li>
<li>Talk to an accelerometer via I2C</li>
<li>Spend a lot of time sleeping waiting for accelerometer events.</li>
<li>Wake up, send a LoRa command and go back to sleep</li>
<li>Wash, rinse, repeat.</li>
</ol>
<br />
(If you read this blog you'll know that C and pre-written Arduino or STM32Cube or whatever frameworks are not the answer for me. I'm old and tired of learning your new (potentially half baked) frameworks. I've got spec sheets on the peripheral chips and know how to use them....)<br />
<br />
So, I need to choose...<br />
<br />
Sigh... the C8051 (Silabs SleepyBee) is just too low level. I've got enough 16 bit math and string manipulation to do that it simply doesn't make much sense to go this low.<br />
<br />
MSP430 is long in the tooth. Sure, the specs are still there and the chips are available but they seem overpriced for what I need (basically 1KB RAM and maybe 32K Flash). I'm not nickle-and-diming it, but it just feels wrong to pay $3-4 for such an old design. I've got Forth Inc SwiftX MSP430 code and there is always Mecrisp too, so from a development perspective the MSP430 has what I need. But, the chip availability is spotty and pricey...<br />
<br />
What about ARM Cortex? It's hard to beat the ARM Cortex these days. Size, power, diversity: It has that in spades. I'm well versed with the STM32L496 and STM32L432 but those M4 beasts are overkill for my needs. They are very complex chips.<br />
<br />
So I stumble upon the STM32L031 and I am blown away by the datasheet specs. It's a Cortex M0+ with MSP430-like low power specs. Heck, it blows away most MSP430s. And is cheaper... given 8KB RAM and 32KB Flash.<br />
<br />
A couple of years ago I ported Forth Inc's SwiftX ARM compiler to the STM32L432. It took a little effort, but it worked. I think I used an STM32F411 as the basis for the port. I'm not looking forward to porting to the STM32L031. But wait, it looks like there is a Mecrisp-stellaris port for that chip. Hurrah! But, wait again... its a bare port. No systick, no CMSIS mappings, etc. Okay. I like bare metal stuff... but... I have this thing I want to build and I need something working soon. Maybe I don't want to bite off the effort. Let's see... there is already a systick interface in Mecrisp for another STM32 part, maybe I can start there. But then I have to deal with sleep transitions. On the MSP430 (and Sleepy Bee) it is dead easy. The STM32L has always been a bear. Is the L031 sleep code the same as the L432? I hope so.. otherwise I have a lot of reading to do.<br />
<br />
I download the L031 reference manual... it's around 900 pages. Okay, I know I don't need to consume it all, but I'll need to do the laborious register bit hunt and the requisite ten thousand clocking options.<br />
<br />
What am I doing here? I need a simple low power microcontroller with an RTC sleep mode less than a couple of uA and run mode less than 5mA. I want it with enough memory that I can get my stuff done.<br />
<br />
To add to this dilemma, the STM32L072 (which should be very close to th STM32L031 I mentioned above) is now the darling of "module" embeds. Well, "darling" may be overselling it, but there is a rather nice LoRa module I'm looking at that embeds this MCU. If (a big IF) I get the L031 working it should be a simple port to the L072.<br />
<br />
But... I'm stuck on the overall complexity of the STM32L. I've been there before (the L496), but I was paid to work with that chip for 9 months. Nine months living and breathing the nearly 2000 pages of reference manual. Tweaking. Tuning.<br />
<br />
Maybe MSP430 isn't dead to me after all. The MSP430F2274 (1KB RAM + 32KB Flash) is more than adequate. I've got a SPI driver written. I've got a development environment. <br />
But at $6 (https://octopart.com/search?q=MSP430F2274) it's insanely pricey. The STM32L031 (which has more memory, features, smaller sizes and uses less power) is only around $2.50.<br />
<br />
Honestly, I am not making millions of devices so a few dollars here and there doesn't really matter.<br />
<br />
But I have to ask myself... is it worth the complexity?toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com3tag:blogger.com,1999:blog-16578308.post-85802547401804849812019-05-15T18:23:00.002-04:002019-05-15T18:23:27.083-04:00Frustrated with ComplexityI've been doing a bit of ESP32 development at work (and some at home) and I've hit a wall. When things fail, they fail bad. I can't say that I understand the xtensa toolchain (I do know that it takes several minutes to build an ESP32 binary on my laptop: FreeRTOS and my app).<br />
<br />
I've been using LuaRTOS and am generally happy with it (a few crashes due to not quite well debugged libraries), but my problem is....<br />
<br />
The more and more I use other people's code, the less I can say I know what is going on inside of my devices. I am building (critical) house monitoring devices (including one that controls a pump via H-Bridge and PWM). Not exactly real time constraints, but certainly 24/7 reliability. I need to know that this system can be trusted.<br />
<br />
Okay, okay... so back to Forth. Looking into replacing the ESP32 (w/ LuaRTOS) Copious Free Time project with a SleepyBee (w/ MyForth) and an ESP8266 (in AT command mode) for Wi-Fi connectivity.<br />
<br />
Why? Because I'm pedantic that way. Close to the metal, baby!<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com6tag:blogger.com,1999:blog-16578308.post-55023344783861342019-03-17T16:56:00.000-04:002019-03-17T16:56:09.633-04:00Alien Technology... of sorts...and a restart?It's been a long time since I've blogged here. I have no idea if anybody is still reading this, but I'll go ahead and say that I intend to start writing more blog entries in the coming weeks.<br />
<br />
But, in the meantime, a bit of catch-up:<br />
<br />
I've had a wonderful opportunity during 2017-2018 to work with GreenArrays and their wonderful GA144 chip, on an actual real work project. There were lots of starts and stops, and not quite "full time", but we did deliver around 25 boards (and software) to the customer for "evaluation and proof-of-principle" goals. They liked what they got (delivered last December), but... they don't know if they want to continue. <shrugs></shrugs><br />
<br />
I also got to do some more work with MyForth (Charley Shattuck's Arduino version) and have (for my own personal projects) pivoted back to the 8051 version (Charley & Bob Nash's work).<br />
I ported MyForth to SiLab's (new) SleepyBee (EFM8SB2). I'll write more about that later. Perhaps a lot more, since it is one of my Copious Free Time projects.<br />
<br />
Taking a break from intense GA144 work (in PolyFORTH and arrayFORTH) I am getting nostalgic for Forth block editors. I'm an emacs die-hard, but there is something still very focused and useful in using a block editor (well, especially when it is integrated into your development environment as deeply as PolyFORTH is on the GA144).<br />
<br />
I may dust off my GA144 EVB and do some toolsmithing or I may dive deeper into the MyForth tooling (hmmm... can I fit a block oriented dev environment on an EFM82B2?) Recompilation is the challenge (as all of that is done in the PC under gforth). I could use the gforth block editor but MyForth is not an incremental compiler....<br />
<br />
Still... I expect to do more Forth in the next few months (if not at work, then on my Copious Free Time projects). Stay tuned.<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com20tag:blogger.com,1999:blog-16578308.post-69131541291216253232017-10-13T09:24:00.003-04:002017-10-13T09:24:41.060-04:00Wish List: Clojure tethered to an MCU running ForthI want to do 2 things:<br />
<br />
<ol>
<li>Use the power of a full desktop system (e.g. Linux, Emacs, Clojure, etc) to play with some SPI/I2C peripherals</li>
<li>Compile a very limited subset of Clojure/Lisp to Forth for flashing into a microcontroller</li>
</ol>
<div>
<br /></div>
<div>
Essentially, I want to take the "tethered" Forth environment (i.e. a full blown interactive development environment talking directly to an MCU), but instead of Forth (Gforth, etc) on the desktop I want to use Clojure/Lisp (basically a language with very rich desktop support). </div>
<div>
<br /></div>
<div>
#1 is pretty easy. I can pick a popular Forth like Mecrisp (which runs on lots of MCUs) and talk to it's Forth interpreter from the Clojure REPL. </div>
<div>
<br /></div>
<div>
#2 is harder, but necessary if I don't want to use #1 just for prototyping.</div>
<div>
<br /></div>
<div>
But why not just use a terminal and Mecrisp (for #1)?</div>
<div>
<br /></div>
<div>
Each Cortex M arm chip comes with a ton of definitions (registers, bit names, etc) that I don't want loaded onto the chip. Also, every little "helper" function I write (to enrich the Forth REPL) takes space on the MCU</div>
<div>
<br /></div>
<br />
<div>
Tethered Forths don't have this problem (as you leverage the desktop Forth to handle such things). </div>
<div>
<br /></div>
<div>
But, while Gforth is very nice, it still isn't as "rich" as I want regarding integration into Linux/Emacs (i.e. not enough batteries included).</div>
<div>
<br /></div>
<div>
<br /></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com4tag:blogger.com,1999:blog-16578308.post-48353744247605859162017-06-13T17:03:00.005-04:002017-06-13T17:03:59.718-04:00Low Power MCU FetishesSo, I am pretty familiar with the STM32L4xx low power Cortex-M4 MCU.<br />
It has some insanely low power consumption profiles including a 0.65 µA standby mode with RTC (and just 14 µs wakeup time).<br />
<br />
This thing is a beast to program (1600+ reference manual <i>to start with</i> and copious app notes). But, I work with this chip for a living.<br />
<br />
This current consumption is specified (in the documentation) at 1.8V, so a more typical 3-3.3V actual power supply will likely cause it to consume more current. I am assuming direct battery hookup otherwise the current consumption of an LDO regulator has to be considered.<br />
<br />
Still... this is insanely low.<br />
<br />
I am looking to play around a bit with some "old" 8-core Parallax Propeller Chips (P8X32A) I have laying around and I read some forum discussion where you could likely get it to consume as little as 7- 10 µA when running just one COG doing not much (maybe as a timer?).<br />
<br />
To these jaded ears that sounds like a lot of power, but... honestly... really?<br />
<br />
With a couple of 1200 mAh AAA batteries (3V) the P8X32A would run around 11 years. That is greater than the shelf life of AAA batteries.<br />
<br />
Most of the current consumption these days aren't from the MCU but from the peripherals and sensors. If I wanted to beacon some temperature measurements via BLE (connection-less -- just as a "tag") maybe every minute, the battery life drops to around 1 year. So, it would be more reasonable to beacon every 10 minutes. Then I could get maybe 5-6 years.<br />
<br />
We get lured into thinking too much about how low an MCU can go, when in the world of IoT, it is the RF that is killing us.<br />
<br />
Just food for thought.<br />
<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com1tag:blogger.com,1999:blog-16578308.post-72151737429176147872017-06-05T15:25:00.003-04:002017-06-05T15:25:32.409-04:00My Forth Story (Part 1)This is just a few collected thoughts on my 30+ years of using Forth. So, if you are expecting high quality technical content, please move on. Yes, nothing to see here, move on...<br />
<br />
This past weekend I was going through old books, trying to clear out some bookshelf space, when I came upon a yellowing Forth Dimensions from 1986. It got me thinking about when I first became enamored with Forth and how it is has popped up now and then throughout my career.<br />
<br />
Back in 1982, armed with my first computer: a<a href="https://en.wikipedia.org/wiki/Commodore_VIC-20"> Commodore VIC-20</a>, I started my first year in college (I was 16 years old -- I skipped a year in grade school) infatuated by the possibilities offered by computer programming. I wasn't really college material (I was planning on going into TV repair or maybe an Art school), but I had just (to everyone's surprise) won the Engineering division of the DC Science Fair and was offered a 4 year scholarship to the University of the District of Columbia. I had prototyped an LED display based oscilloscope using some op-amps and 555 timers. It was inspired by a design I saw in Popular Electronics. But I digress...<br />
<br />
So, here I was starting college (and a job as a TA in the computer lab!) and I knew it was time to "up" my skills (I was proficient in BASIC and some 6502 assembly). We had a lab full of the newly purchased <a href="https://en.wikipedia.org/wiki/Commodore_64">Commodore 64</a>s (C64) and a terminal room (oooh, remember green phosphorous terminals?) remotely connected via 1200 baud modems to the school's <a href="https://en.wikipedia.org/wiki/DECSYSTEM-20">DEC2060</a> (more on that later). I would split most of my day time between the C64 and DEC260 and my nights were spent hacking on my venerable Commodore VIC-20.<br />
<br />
Suffice it to say, my VIC-20 wasn't cutting it to get me kick started into the highly competitive CS department. I saved up money to get a Commodore 64 so I could continue my hacking education from the comfort of home.<br />
<br />
On the DEC2060 we didn't have BASIC. We had a sophisticated Macro assembler, Rutger University Pascal and Fortran IV and 77. None of this would work on the C64, and BASIC was quickly running out of steam.<br />
<br />
It was either through BYTE (or maybe it was Compute!) magazine that I stumbled upon this language developed by this guy named Chuck Moore. It was Forth and there were a couple of implementations available on the C64. An implementation that intrigued me, in particular, came in cartridge form and booted (nearly) instantaneously. This wouldn't require me to fiddle with the painfully slow floppy drive.<br />
<br />
I became obsessed with Forth. The interactivity and the power (to lock up the C64) was addictive.<br />
<br />
But, my CS (well EE, I started as an EE student and defected to CS) courses were on a DEC2060. The DEC20 was a lovely 36-bit word "mainframe" (shhhh! DEC wasn't allowed to call them mainframe as they didn't want to face the wrath of IBM and their patents). The 36-bit word size happened to be perfect for a Lisp cons cell. I found Lisp quite lovely, powerful and intriguing but I was still in the midst of my Forth obsession.<br />
<br />
This obsession became even more all consuming, around 1985, when I read about Chuck Moore's amazing <a href="https://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html">Novix NC4016</a>. I even ordered a fact sheet from Novix Inc so I could pour over as much detail as I could -- knowing I would never likely touch one.<br />
<br />
In late 1985, my C64 Forth obsession hit a wall. This wall was my obsession with Fractals, particularly the Mandelbrot Set, of which I first heard about in the <a href="https://www.scientificamerican.com/magazine/sa/1985/08-01/">August 1987 issue of Scientific American</a>. The C64 just didn't seem to have enough processing power to execute my naive implementation of Mandelbrot's algorithm.<br />
<br />
Eventually, I found a Forth that ran on a DEC20, converted the algorithm to fixed point and managed to get the set rendered on a graphics terminal (over a 1200 baud modem!). If my memory serves me correctly, the terminal was a <i>fancy</i> <a href="http://terminals-wiki.org/wiki/index.php/Tektronix_4105">Tektronix 4150</a>. It took a lot of false starts and missed classes, but a couple of days later I had a color fragment of the famous fractal.<br />
<br />
As I got further along in my CS curriculum, I discovered that technologies like home computers (C64, etc) and languages like Forth were not really encouraged as tools of study. So, I learned TOPS-20 assembly, Pascal, Fortran (IV and 7), TeX and Lisp. I fell in love with Emacs (the original written in TECO!) and generally was happy, but I was missing some of the hands on immediacy of having my own personal computer and personal <i>happy-to-crash-it-language</i> like Forth. There was a driving need, brewing inside me, to do something low level -- something <i>dangerous</i>.<br />
<br />
So when a secretly procured copy of AT&T's UNIX Version 7 arrived at the University Computer Center (where I worked, distracting me from my scholarship and short circuiting the pursuit of my degree), I worked with a couple of my friends to boot it on the DEC20, play around with it and then remove it, before the next day's classes began. This was no trivial task as it required hand entering the bootloader on the front panel. Fun stuff.<br />
<br />
I soon fell for the spartan language that accompanied the UNIX tape: C.<br />
<br />
Over the years, I would continue to play with (and implement my own) Forths, but it wouldn't be until 20 years later that I would get a chance to program in it extensively (around 2006), when I revisited my low level hardware past in the form of embedded development on Microcontrollers.<br />
<br />
To be continued...<br />
<br />
<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com4tag:blogger.com,1999:blog-16578308.post-50255862916244842572017-04-14T08:29:00.003-04:002017-04-14T08:29:41.567-04:00Hack CWork has been busy and eating up most of my "Copious Free Time", so most of my projects have been placed on hold.<br />
<br />
However, one thing I am getting from the past 6 months "deep dive" back into C programming (I've been programming C on and off since 1985 -- yes over <b>30</b> years *gasp*), is that a lot of my code in LuaJIT, Perl, C++11, Clojure and Haskell (and others) could be rewritten pretty concisely in C (C99 or C11 in particular).<br />
<br />
Now, hold on, you say -- that is crazy talk.<br />
<br />
A lot of the types of applications/tools I write are "system level". When not coding Cortex M4 ARMs (my day job) I do a fair bit of networking (ethernet/IP packet level) hacking. Or, I use libraries such as OpenCV to do simple vision stuff. So, I am not really using the advantages of higher level programming languages.<br />
<i><br /></i>
<i>What I am really benefiting from is those language's REPL -- the interactivity. </i><br />
<br />
I recently rewrote an OpenCV based image detection application, I originally explored and coded in LuaJIT, in C99. It was almost a line by line translation (I even found a couple of bugs!).<br />
<br />
Okay, so honestly, I wonder if I had some sort of C REPL (gdb on steroids?), all I am missing is a nice convenient hash table (i.e. associative array, dictionary, etc). I don't like the baggage of bringing in whole toolkits/frameworks for that (I like to keep my C lightweight and avoid things like pseudo-OO), so I just need a nice fast, generic hashtable implementation.<br />
<br />
I need to get back into hacking C (for a while at least) and avoid the drama associated with picking a programming language "tribe".<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com2tag:blogger.com,1999:blog-16578308.post-33891759090577447442017-02-01T10:17:00.001-05:002017-02-01T10:17:09.849-05:00Perl 6 - Diving in...So, I've been a long time Perl user since the 1990s. I rarely used it on job, but my only (widely?) used open source contribution is an application written in Perl 5: <a href="http://maplefish.com/todd/aft.html">AFT</a> (It is on <a href="https://github.com/tcoram/AFT">github </a>and is also available to any Ubuntu based distro by typing "<span style="font-family: Courier New, Courier, monospace;">sudo apt install aft</span>".<br />
<br />
Apparently, <a href="https://perl6.org/">Perl 6</a> is now usable.<br />
<br />
It looks very interesting. In particular, I am excited about its concurrency/parallel support (why is it that so few languages come with this baked in?). The FFI looks usable (I've managed to get Perl 6 working with libusb pretty quickly).<br />
<br />
But why bother?<br />
<br />
I've always liked the language design approach of Perl. The maximal syntax approach is dense but can have some appeal. In particular, it seems to avoid the (overbearing) library approach that other languages take. This is a strength shared by Haskell and (yes) C++1x (C++11, C++14, etc).<br />
<br />
For me, a couple of lines of well written code always wins over the "I must dive into a hierarchy of libraries and calls". You just need to avoid making the couple of lines too dense.<br />
<br />
This is the thing... in C++ and Perl I tend to avoid libraries if I can. Externally dependencies are more subject to code rot. AFT still runs (on almost any Perl distro) in part due to lack of dependencies on libraries that may be "abandoned" or improperly upgraded (to kill backward compatibility with older Perl distros).<br />
<br />
But, I digress....<br />
<br />
This entry is just my way of committing myself to a Perl 6 learning effort:<br />
<br />
I have written 2 <a href="https://wiki.mumble.info/wiki/Main_Page">Mumble </a>compatible chat/VoIP servers: One in Erlang and one in Lua(JIT). (I attempted one in Clojure but Java based networking made it nearly impossible to do sanely.)<br />
<br />
I am now trying to see if Perl 6 is up to the task.<br />
<br />
Stay tuned...<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-48687604330575017992017-01-18T21:17:00.001-05:002017-01-18T21:17:14.202-05:00Crazy Complexity:The STM32L476The STM32L476 very low power Cortex M4 costs $9 at Digikey.<br />
This tiny MCU has, among other features, 128KB RAM, 1Mbyte Flash and<br />
<ul class="disc" style="background-color: white; box-sizing: border-box; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: 14px; line-height: 1.5; list-style: inherit; margin: 0px 0px 0px 1.1rem; padding: 0px;">
<li style="box-sizing: border-box; margin: 0px; padding: 0px;">USB OTG 2.0 full-speed, LPM and BCD</li>
<li style="box-sizing: border-box; margin: 0px; padding: 0px;">2x SAIs (serial audio interface)</li>
<li style="box-sizing: border-box; margin: 0px; padding: 0px;">3x I2C FM+(1 Mbit/s), SMBus/PMBus</li>
<li style="box-sizing: border-box; margin: 0px; padding: 0px;">6x USARTs (ISO 7816, LIN, IrDA, modem)</li>
<li style="box-sizing: border-box; margin: 0px; padding: 0px;">3x SPIs (4x SPIs with the Quad SPI)</li>
<li style="box-sizing: border-box; margin: 0px; padding: 0px;">CAN (2.0B Active) and SDMMC interface</li>
</ul>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;"><span style="font-size: 14px;"><br /></span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;"><span style="font-size: 14px;"><br /></span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;"><span style="font-size: 14px;">The reference manual is 1704 pages long. </span></span></div>
<div>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;">The reference manual is 1704 pages long. </span></div>
</div>
<div>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;"><span style="font-size: large;">The reference manual is 1704 pages long. </span><span style="font-size: 14px;"> </span></span></div>
</div>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;"><span style="font-size: 14px;"><br /></span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Helvetica, sans-serif;"><span style="font-size: 14px;">I work on this beast at my day job.</span></span></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com1tag:blogger.com,1999:blog-16578308.post-91414045550785156022016-12-16T10:34:00.003-05:002016-12-16T10:34:47.220-05:00Even Simple things are Complicated... in IoTSo, I strive for simplicity in my design. But I realize that simplicity in design doesn't mean simplicity in implementation. Even simple things are complicated when you consider IoT.<br />
<br />
Let's take a fairly "simple" example: You want to design a water leak detector for your water heater (or the utility room/closet that hosts it). Or maybe you are in a flood zone.<br />
<br />
This water leak detector should notify you (via your Internet connected Smartphone -- you may not be at home) that there is water present (or rising significantly)on the floor. Assume that this is VERY IMPORTANT to you because your house is prone to floods or leaks. Or, you want to make sure your "pump" is doing it's job. <br />
<br />
During rainstorms while you sit at work... your mind may wander... to your house... to that damn pump... Okay, IoT to the rescue!<br />
<br />
Simple? Sure. Just throw an ESP8266 or ($10-20) Raspberry Pi at it.<br />
<br />
Fine... now let us look at what needs to be done.<br />
<br />
<ol>
<li>A water sensor. Okay, let's assume you found one or threw together a nice one that can be securely mounted to the floor or wall just above the floor. Basically let's punt on this one. Done.</li>
<li>You need Wi-Fi. Chances are you aren't located near an Ethernet port and probably don't want wires everywhere.</li>
<li>You need to be battery powered. (Assuming even if you rather plug it into AC, there are flood conditions that could occur during a power loss, right? Like your flood pump isn't working..) So, yes, you need to be battery powered. And the battery should last at least 1 year.</li>
<li>You need a cloud server to host the relaying of messages to your Smartphone.</li>
</ol>
<div>
Okay, so you've done all of that hard work or found a nice little sketch/hackaday-device that does all that for you. Done?</div>
<div>
Nope.</div>
<div>
<br /></div>
<div>
Here are some issues you need to consider:</div>
<div>
<ol>
<li>How do you get notified that the battery is dying?</li>
<li>What if someone does an DoS attack (or you changed your Wi-Fi router and forgot to re-configure this device).</li>
<li>Speaking of Wi-Fi... How do yo configure this device in the first place?</li>
<li>Do you have redundant servers in the cloud. (What if your cloud server goes down?)</li>
<li>What do you do if your ISP (or cloud) connection goes away for a few minutes?</li>
<li>What if the water sensor is accidentally "detached" (or is damaged)?</li>
<li>Is your connection to the cloud secure? Is it authenticated? What if some joker thinks it would be funny to fake out your server into thinking that there is a water leak?</li>
<li>What if the device was suddenly "unpowered" (unplugged or batteries were removed). Can you handle that?</li>
<li>How do I know, in general, that the device (and my connection to it) is working properly?</li>
</ol>
<div>
Now, you don't have much control over the "Internet" portion of this (realistically). But, at the end of the day, your device will always be blamed. It didn't notify you and your basement is now flooded.</div>
</div>
<div>
<br /></div>
<div>
So, let's address some of these issues. Let's assume that this device is either very, very critical to you (you have lots of water problems and can't afford the massive damage an unattended one would cost) or you want to go to market with this device.</div>
<div>
<ol>
<li>How do you get notified that the battery is dying? <span style="color: #990000;"> </span></li>
<ul>
<li><span style="color: red;">You are going to have to monitor the battery voltage. So, some ADC work. </span></li>
<li><span style="color: red;">And you probably should have a local (loud) buzzer in addition to sending it over Wi-Fi</span></li>
<li><span style="color: red;">LEDs will be next to useless (unless you tend to hang around your utility room/closet a lot)</span></li>
<li><span style="color: red;">Also... Wi-Fi transmission take a lot of power. Consider that in your power budget.</span></li>
</ul>
<li>What if someone does an DoS attack (or you changed your Wi-Fi router and forgot to re-configure this device).</li>
<ul>
<li><span style="color: red;">Once again, a buzzer. But don't make it too annoying. </span></li>
<li><span style="color: red;">How (and/or when) do you shut off this buzzer?</span></li>
</ul>
<li>Speaking of Wi-Fi... How do yo configure this device in the first place?</li>
<ul>
<li><span style="color: red;">Smartphone? Via Bluetooth? As a (temporary) Wi-Fi access point?</span></li>
<li><span style="color: red;">You are also going to need a "rich" app for the phone, or otherwise a nice web server for the device (a web server for a <i>freaking</i> water monitor, ugh)</span></li>
</ul>
<li>Do you have redundant servers in the cloud. (What if your cloud server goes down?)</li>
<ul>
<li><span style="color: red;">Of course, your ISP can go down... but more likely it will be that $5 per month virtual instance in the cloud that you thought was a really good bargain.</span></li>
<li><span style="color: red;">Consider at least 2 servers (not co-located).</span></li>
</ul>
<li>What do you do if your ISP (or cloud) connection goes away for a few minutes?</li>
<ul>
<li><span style="color: red;">You are going to need to cache this information and send it later... so you need a "retry" mechanism</span></li>
<li><span style="color: red;">You are probably going to want an event "date" (or at least elapsed time from). Has it been trying to notify your for hours?</span></li>
</ul>
<li>What if the water sensor is accidentally "detached" (or is damaged)?</li>
<ul>
<li><span style="color: red;">First you need to detect this. Your monitoring algorithm considers false positives right? Is this a measurement glitch or did the sensor get yanked?</span></li>
<li><span style="color: red;">The sensor (which may just be a couple of traces on a board) needs to have some means of being "detected". So.. it needs to be more than a couple of bare wires or traces on a board.</span></li>
</ul>
<li>Is your connection to the cloud secure? Is it authenticated? What if some joker thinks it would be funny to fake out your server into thinking that there is a water leak?</li>
<ul>
<li><span style="color: red;">Encryption may not be important (this isn't critical private info), but spoofing can and will be a problem. You will need to some form of SSL/TLS, so you just went beyond your 8 bit Arduino in terms of parts count.</span></li>
</ul>
<li>What if the device was suddenly "unpowered" (unplugged or batteries were removed). Can you handle that?</li>
<ul>
<li><span style="color: red;">Basically... ask this question if you want to use a Linux based solution (A Pi or Beaglebone). </span></li>
</ul>
<li>How do I know, in general, that the device (and my connection to it) is working properly?</li>
<ul>
<li><span style="color: red;">A system check... a heartbeat... an alert to your smartphone that something is amiss</span></li>
<li><span style="color: red;">A heartbeat will affect battery life... be careful.</span></li>
</ul>
</ol>
<div>
So... this simple device starts to become complicated really, really fast. Doesn't it?</div>
</div>
<div>
<br /></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-67746807402882717212016-12-12T12:02:00.000-05:002016-12-12T12:03:24.684-05:00Brutal High Availability vs SimplicityI've been toying with the idea of using an <a href="https://espressif.com/en/products/hardware/esp8266ex/overview"><span style="color: #0b0080; font-family: sans-serif;"><span style="background: none rgb(255, 255, 255); font-size: 14px;">ESP8266</span></span><span style="background-color: white; color: #252525; font-family: sans-serif; font-size: 14px;"> </span><span style="color: #0b0080; font-family: sans-serif;"><span style="background: none rgb(255, 255, 255); font-size: 14px;">Wi-Fi</span></span><span style="background-color: white; color: #252525; font-family: sans-serif; font-size: 14px;"> </span>SoC</a> (running NodeMCU) as the basis for my kitchen/stove monitor. It's cheap ($3), it has the sensor inputs (and libraries) I need and gets my device on the Internet (IoT!)<br />
<div>
<br /></div>
<div>
However, I have some serious questions regarding the stability of the platform (mostly the software -- and yeah I know I can punt NodeMCU and go with C, but I am still using frameworks and libraries I don't trust yet). Can I run this SoC for years without a glitch? My device can't afford to "fail". It needs to always be working. Even if it had to "reset" due to a watchdog or long running glitch, it needs to be up and running in order to be useful. It needs "High Availability". </div>
<div>
<br /></div>
<div>
What can I do if I want to use this useful SoC?</div>
<div>
<br /></div>
<div>
Well...assuming that the hardware is stable, I can address software instabilities by adding another "trusted/reliable" system.</div>
<div>
<br /></div>
<div>
Maybe an ATmega326 running minimal firmware: Just logic. It would be the "master". But, it is quite an anemic master.</div>
<div>
<br /></div>
<div>
Since my device is AC powered (I wanted something you could enable and use without thinking about battery replacement, etc -- not play the Wi-Fi power budget problem), I don't have to limit myself to an anemic microcontroller. Maybe a Linux SBC? Maybe... a Beaglebone Black?</div>
<div>
<br /></div>
<div>
So, here, I begin to abandon "Simplicity" (and increase my cost significantly). But, I can do a few more things by choosing a Linux SBC:</div>
<div>
<br /></div>
<div>
<ol>
<li>More robust protocol for Internet use: A real messaging system (XMPP? RabittMQ client?) with caching and reconnect strategies.</li>
<li>More security (Stronger encryption and authentication at endpoint)</li>
<li>Leverage proven multi-year uptime of a Debian or Ubuntu distro</li>
</ol>
<div>
<br /></div>
</div>
<div>
But, why use the ESP8266 at all? Because getting peripherals (e.g. I2C, 1-wire, etc) to work on a Linux SBC is black magic and a waste of my time. Plus, the ESP8266 is cheaper than any Wi-Fi USB module I can get for Linux.</div>
<div>
<br /></div>
<div>
The idea here is to have the Beaglebone <i>control</i> the ESP8266. The Beagle will periodically either ping it for liveliness or simply <i>reset</i> the module before transactions or as a "daily" ritual. It may sound kludgey but so as long as the ESP8266 is okay with periodic resets, this lends the system to higher availability than a pure MCU (bare metal or non-commercial RTOS) solution. </div>
<div>
<br /></div>
<div>
Another benefit is I can do an "all Lua" implementation (Lua on the ESP8266 via NodeMCU) and LuaJIT on the Beaglebone. This would allow me to integrate some telephony (SIP) stuff I've been working on (a completely different project) to "call" instead of just message the user about kitchen/stove activity.</div>
<div>
<br /></div>
<div>
Or, I could just continue developing with my current minimalistic approach of using the ATmega326p with Charley Shattuck's <a href="https://github.com/CharleyShattuck/myforth-arduino">myforth-arduino</a> (which is a pleasure to use -- I've already got my temperature monitor working :)</div>
<div>
<br /></div>
<div>
<br /></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com1tag:blogger.com,1999:blog-16578308.post-91553477189743086802016-12-01T13:38:00.001-05:002016-12-02T11:17:50.309-05:00The Mind of a (low level) Systems ProgrammerI'm a systems programmer... an obsolete term, indeed. But that is what I am. It's not about coding in assembly (fun!) or squeezing out every drop of optimization in C (double fun!), but it is about wanting to "make" systems. <br />
<br />
Compare this with an "application programmer" (another archaic term). They love the domain. I love the innards, the thing that runs the application. My work should be silent and never seen. My stuff needs to just "work".<br />
<br />
I like watching my front loading washing machine run. It is a complete system, but no fancy UI or IoT interface to be seen. It has sensors, it has actuators, it spins.... that's it. <br />
Most of the time it works (it's getting old so there are a few faults here and there). But it is successful because no one thinks about it. It lies in the background of our lives, silently do its job.<br />
<br />
A year ago I had to replace the logic board in my HVAC. It was expensive ($700 list -- but I got mine new from ebay for around $400). The complexity (and wonder) of that board is that it has to be as solid as NASA system.<br />
<br />
My HVAC uses natural gas. A lot of the components on that board (and the logic / program) are there to make sure my house doesn't blow up. No fancy interface. No operating system. No complex 32-bit floating point math (I assume... I mean, my house shouldn't blow up do to a rounding error, right?).<br />
<br />
I installed the Hunter ceiling fan, in my bedroom, over 15 years ago. It runs every night and mostly through the day. It has never failed. It is still silent. I wonder what kind of motor it has built in and how it is commutated (must be AC since brushless DC wasn't widely available back then -- I think).<br />
<br />
That was a good design... a systems design.<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com1tag:blogger.com,1999:blog-16578308.post-43197114685704701472016-11-27T09:54:00.000-05:002016-11-27T09:54:53.918-05:00Excessive Portability and Embedded DevelopmentWhich is better?<br />
<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">/* Read the angle register (ANGLECOM) */</span><br />
<span style="font-family: Courier New, Courier, monospace;">angle = spi_write(0xFFFF);</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: inherit;">or</span><br />
<br />
<span style="font-family: Courier New, Courier, monospace;">/* Read the angle register */</span><br />
<span style="font-family: Courier New, Courier, monospace;">angle = spi_write(A_READ | A_PARITY_1 | A_ANGLECOMREG);</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
Now, you don't have to understand exactly what's going on here (and the actual process of reading an angle from the AS5147 rotary position sensor is a little bit more complicated), but I am trying to make a point.<br />
<br />
I would argue that the second code snippet is a waste of time. (Some presumptions here: You had to define A_READ, A_PARITY_1 and A_ANGLECOMREG).<br />
<br />
But, why would I advocate the hard coded version?<br />
<br />
<ol>
<li>The chip (AS5147) isn't going to change SPI command structure anytime during its production cycle.</li>
<li>If you choose a new chip, you are going to have to study it and figure out the hard coded values anyway.</li>
<li>The abstraction in the 2nd code snippet is going to only work for this exact chip.</li>
<li>You have to work out the bit twiddling anyway (to come up with A_READBIT, etc)</li>
<li>0xFFFF is what you will see in your debugger</li>
<li>It is *always* 0xFFFF </li>
<li>Ease of modification doesn't work here. If you go "oh, that should be A_PARITY_0" and change it (without verifying the actual resulting write value, it is going to cause a lot of debugging woes).</li>
</ol>
<div>
This is sort of an argument between "ease of writing" vs "ease of debugging" and in embedded development, "ease of debugging" is what you are really shooting for (or maybe call it "ease of validation").</div>
<div>
<br /></div>
<div>
I see the same thing happening with STM32's HAL or StdPeriph. There is a focus on making it easier to load up registers (often taking 1 line of register loading code and stretching it into multiple lines of structure loading using verbose enums/types you have to look up).</div>
<div>
<br /></div>
<div>
To be honest, when I work in Forth on the STM32, I don't have such luxuries and my program is full of well documented hex and binary register banging.</div>
<div>
<br /></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com2tag:blogger.com,1999:blog-16578308.post-81993284442607646572016-11-14T14:58:00.003-05:002016-11-14T14:58:53.210-05:00Attack At Dawn<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgc8po_9noL_x_jFm0UD17zUFpjq8AaU3qSasGexpLAoJwe7kxNlXk9BzwA41wsIAYodbPFEAXkEYH4gpYZxE5XzSpQ7EYtmfQUEysIQ4V5t_jTJ4YwvMhnTcrkXHY5KOLX8Pu/s1600/ps1_3740_fnt_dd_t16-tms.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="420" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgc8po_9noL_x_jFm0UD17zUFpjq8AaU3qSasGexpLAoJwe7kxNlXk9BzwA41wsIAYodbPFEAXkEYH4gpYZxE5XzSpQ7EYtmfQUEysIQ4V5t_jTJ4YwvMhnTcrkXHY5KOLX8Pu/s640/ps1_3740_fnt_dd_t16-tms.jpg" width="640" /></a></div>
<br />
This is a painting on display at The Walters Museum in Baltimore Maryland. (http://art.thewalters.org/detail/4911/the-attack-at-dawn/). <span style="font-family: inherit;">It is by "Attack At Dawn" by Alphonse de Neuville. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">I am not particularly a fan of military battle scenes, but there is something about this painting that I can't get the image out of my head. </span><br />
<span style="font-family: inherit;">This photo does it no justice. The somber, winter setting, the lighting, the mastery of painting techniques. It is not a famous painting, but it does so many things that resonate with me: The distant foggy morning sky, the snow, the dim light sources (e.g. dawn, the lamp post, the doorway on the left, the rifle fire), the sparse brush strokes, the sense of desolation.</span><br />
<span style="font-family: inherit;">Go see it, if you can.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><br /></span>toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-73257354044649905792016-11-14T14:20:00.001-05:002016-11-14T14:20:33.038-05:00Literate Programming... A RevisitFor someone reason (nostalgia?) I've been re-visiting Donald Knuth's concept of Literate Programming.<br />
<br />
(For a quick intro, critique and discussion on this approach see this <a href="http://www.johndcook.com/blog/2016/07/06/literate-programming-presenting-code-in-human-order">blog entry and the responses</a>.)<br />
<br />
I first discovered Literate Programming via looking at TeX sources in the 1980s. Then I became somewhat obsessed with the approach around 1992 with the publication of <a href="http://www.goodreads.com/book/show/112245.Literate_Programming">Literate Programming</a> by Knuth. This is still one of my favorite books on programming.<br />
<br />
I still like to thumb through <a href="http://www.goodreads.com/book/show/499934.Computers_Typesetting_Volume_B">TeX: The Program </a>(likely the largest Literate Program ever written).<br />
<br />
Perhaps I am starting to revisit Literate Programming because of my full-time-deep-dive into embedded programming (again). Still stuck with C and code that is supposed to <i>work </i>(I deal more with "firmware" than software these days -- code that can't just be frequently updated, is hard to unit test and must be very, very reliable).<br />
<br />
Literate Programming doesn't fit well in today's rapid development, big team, fastest-time-to-market culture. But, when I am writing control systems with little instructional software/literature available (e.g. learning how to spin a BLDC motor using sinusoidal waves), I start thinking about approaching it in a literate style.<br />
<br />
Shhh... don't tell my partners, but I am definitely thinking about using <a href="http://www.literateprogramming.com/cweb.pdf">cweb </a> or perhaps <a href="http://www.literateprogramming.com/cwebx.pdf">cwebx </a>for this ;)<br />
<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com2tag:blogger.com,1999:blog-16578308.post-20654176674200040632016-11-08T16:59:00.001-05:002016-11-08T16:59:21.162-05:00SPLAT Logic AnalyzerFound: A Logic Analyzer written in Tachyon Forth on a Parallax Propeller chip.<br />
This is insane. I love it.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/a-lYGX-ka8ZqkvjOrGR9aFXSZAMnB-h4T_DlFA332ZHEGvk7s1lOMvrVumB04N7xSu1csTIfvUidXs-kp6xrCCun9lRBCECuaNcksvwX9daL-D7npEiyCeKkug=s1600" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="287" src="https://4.bp.blogspot.com/a-lYGX-ka8ZqkvjOrGR9aFXSZAMnB-h4T_DlFA332ZHEGvk7s1lOMvrVumB04N7xSu1csTIfvUidXs-kp6xrCCun9lRBCECuaNcksvwX9daL-D7npEiyCeKkug=s1600" width="320" /></a></div>
<a href="https://docs.google.com/document/d/1vszFLwzIfwMEqe2vWA0y4HwVIc4uVpxyjmApKNlY8QQ/pub">https://docs.google.com/document/d/1vszFLwzIfwMEqe2vWA0y4HwVIc4uVpxyjmApKNlY8QQ/pub</a><br />
<br />
Somewhere, in a box, at my last job, is an "over the air" (GSM/SMS) remote control device that I developed using the Propeller chip and Tachyon Forth. It was a prototype I put together in less than 2 months and "field tested". It was an interesting (and fun) experience. I would have love to have used this logic analyzer during development.toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-10489839899746271722016-10-04T22:21:00.000-04:002016-10-04T22:21:01.642-04:00Spinning a motor is hardI'm trying to spin a 3 phase motor really, really slow. For this I have chosen Sinusoidal Commutation. Just a few sine calculations and I'm good, right?<br />
<br />
Ugh.<br />
<br />
Sinusoidal commutation of BLDC motors is hard. Even so-called "open loop" commutation (which still expects feedback -- is it still really "open"?) is difficult.<br />
<br />
You can find a google load of papers on how to perform (6 step) trapezoidal commutation and then some that kind of talk about sinusoidal.<br />
<br />
It's all maddening and the reason why motors are its own field of study. Lots of physics. Lots of math. Lots of stuff you can't shortcut. Jerk, torque ripple, back EMF. Don't get me started on rotors and pole count. How about Phase finding? Know how to do that?<br />
<br />
To spin, you must have feedback! Don't Hall effect sensors? How about with angular magnetic encoders? If you are man (or woman) enough, you venture into FOC.<br />
<br />
I'm spending weekends and some weeknights learning how to spin a motor so me and my partners can build a killer robotic application. (Killer may be a bad choice of words....)<br />
<br />
I'm really learning how much I don't really know.<br />
<br />
Spinning a motor is hard...<br />
<br />
<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-52129802201314565802016-05-24T11:27:00.001-04:002016-05-24T11:27:29.728-04:00Taking a SIP from the VoIP fountain....Bad metaphorical post title aside (ouch), I am currently investigating "cutting the Vonage cord" (another bad metaphorical allusion).<br />
<br />
I haven't had a proper land line in 10 or so years. Vonage has served me well. But, I find that with everyone in my family owning a smartphone, we rarely use our home phone line. As anyone who has called us will know, sometimes we can't find our "wireless" phone(s) -- is it buried in the couch cushions again? We are also horrible about retrieving voice mail (even though we have Vonage forward transcripts to our smartphones).<br />
<br />
Really, outside of having a number "for our house", we don't use it much. But our monthly bill for this convenience is over $30 per month! I know, I know... why don't we just find a lower cost VoIP provider? But that still requires us having to <i>swim in someone else's pool</i> (sorry about that, there I go again).<br />
<br />
But, hey... wait a minute! I am a software engineer who specializes in <i>communication</i>. There must be something I can do here. All I need is some way of getting my home phone number to forward to a PBX under my own control. Think of the things I could do!<br />
<br />
I could...<br />
<br />
<ul>
<li>Have the call ring to any smartphone that is registered on my Wi-Fi (i.e. mine and my wife's phones when we are home)</li>
<li>Forward the call to voice mail immediately if we aren't home.</li>
<li>Register another "business" phone number that does something similar... basically track me down (e.g. smartphone or home number or voicemail)</li>
</ul>
<div>
..and so much more!</div>
<div>
<br /></div>
<div>
So, I start looking at FreeSWITCH and Asterisk. Wow! I need a book, or two, and a lot of time.</div>
<div>
(Another variation of <i>swimming in someone else's pool</i>).</div>
<div>
<br /></div>
<div>
Okay, so do I really need a full blown PBX to do this? Nope. I can do most of this with a cheap DID (Direct Inward Dialing) provider that could forward to a SIP proxy (of my own configuration or design). (I won't go into details about SIP here... just know that it is the standard Internet way of locating and setting up calls. It is pretty complex too, but it is fundamentally a protocol specification.)</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
So, I start looking at OpenSIPS and over SIP server solutions. It looks like all the pieces are there to do what I need. I just need to write a script....</div>
<div>
<br /></div>
<div>
Okay. My engineer senses start pulsing again (sort of like Spiderman's senses but rather than danger it warns me that I am about to use a complex system to do what seems so simple in my head). I don't want to solve my problem with a simple OpenSIPS configuration... I want to intimately understand what is going on inside of SIP and implement <i>just enough</i> to do what I want. How better to learn a system than to dive right in and try to build one yourself?</div>
<div>
<br /></div>
<div>
By learning OpenSIPS, I'll become an OpenSIPS expert but I won't really know how SIP works. Sure, they take care of the plumbing, but I am interested in the plumbing.</div>
<div>
<br /></div>
<div>
So, I start with the <a href="https://www.ietf.org/rfc/rfc3261.txt">SIP RFC </a>. Well that's over 200 pages! Okay, Todd.. slow down. What do I minimally need to let two VoIP user agents (i.e. phones or smartphone apps) talk to each other?</div>
<div>
<br /></div>
<div>
I start from there.... and here I am today. I've got some primordial code handling SIP registrations over UDP. I have a long way to go, but <b>I am going to have fun with it and I am going to learn a lot. </b></div>
<div>
<br /></div>
<div>
Maybe I'll finish enough of it to put it out there as open source. Not an OpenSIP competitor, but a super simple, super <i>hacky</i> way<i> </i>of creating your own lightweight home VoIP system.</div>
<div>
<br /></div>
<div>
<i>Note: Currently using LuaJIT and Copas socket server to play around with SIP and I as I mentioned above, I've got Registration working. Ooooh... so much fun!</i></div>
<div>
<i><br /></i></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-70995424948459855172016-04-09T12:37:00.000-04:002016-04-09T12:37:00.080-04:00Hackable (Software) ThingsI like hackable things. I'll keep that vague, because I am in a vague mood.<br />
See if you can spot the common theme:<br />
<br />
<ol>
<li>Emacs</li>
<li>TeX / LaTeX</li>
<li>Forth (interactive on an MCU)</li>
<li>Snabb Switch</li>
<li>Smalltalk (Squeak)</li>
<li>Unix command line (awk, sed, kornshell, bourne shell, maybe bash, etc)</li>
</ol>
<div>
<br /></div>
<div>
Okay... why?</div>
<div>
<br /></div>
<div>
They are <i>worlds </i>at my fingertips.</div>
<div>
They don't use XML.</div>
<div>
They are extensible.</div>
<div>
I can make them do useful things.</div>
<div>
With the exception of #3 (Forth), none really manipulate the "physical world".</div>
<div>
<br /></div>
<div>
Speaking of Forth... having shipped a few professional devices built with Forth, I still haven't found anything nearly as useful or fun for MCU work.</div>
<div>
<br /></div>
<div>
Something I would love to have for embedded MCU work:</div>
<div>
<br /></div>
<div>
<i>A nice REPL / Editor environment (host side, please) for manipulating/deploying eLua on MCUs. </i></div>
<div>
eLua has poor interactivity support, but I wonder if remotely instrumenting it is a better approach... maybe via <a href="https://studio.zerobrane.com/">ZeroBrane</a> or Emacs?</div>
<div>
<br /></div>
<div>
<br /></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-66785107341413036462016-02-22T10:58:00.000-05:002016-02-22T13:20:04.996-05:00Premature Optimization during DesignAs I design my embedded software, I am always looking for the most efficient tools and design. We have limited resources and must therefore constrain our designs. Or do we?<br />
<br />
I remember struggling to get Donald Knuth's TeX typesetting system to compile and run on the big DEC2060 timesharing system back in 1984. It was a beast of an application and not written to run on anemic platforms. It was Knuth's idea to solve the typesetting problem, not write an application that would run on limited hardware.<br />
<br />
Now, TeX (same sources pretty much) can run on your Android phone.<br />
<br />
Back in 1986 I was trying to get Richard Stallman's Emacs to compile and run under Unix. It was a big, bloated and slow beast (but worth it for all the power it gave me -- I was already an Emacs addict for a couple of years).<br />
<br />
Now, I install it on every Linux/BSD laptop I use and fire it up as needed.<br />
<br />
These systems (and others) were not designed to work on minimal hardware, but over the years hardware caught up with them.<br />
<br />
I am not advocating that IoT devices use big bloated tools, but as far as "basestations" go... why are we constraining ourselves to RasPis and Beaglebones?<br />
<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-53206524426110900552016-02-16T10:51:00.002-05:002016-02-16T11:02:22.105-05:00Mutter... Adventures in VOIP/messaging systemsOver the past couple of years I've been playing around with a "toy" Mumble server I developed.<br />
Mumble, if you don't know, is a popular gamer VOIP and messaging system. It is open sourced and has clients running on Windows, Linux, iOS (iPhone) and Android (I prefer Plumble). It has a published spec for communication so it is relatively easy to build a minimal server. I've built one in the past in Erlang and have recently started one in Lua(JIT).<br />
<br />
Why would I want to implement my own Mumble server (I'm calling it Mutter) when a perfectly good one exists as part of the Mumble project? Well, I am curious how many interesting things I can do with a compliant server without touching the client software.<br />
<br />
Some of my experiments involve creating additional levels of authentication (e.g. a query response from a server bot, additional detection of client OS/hardware stuff, etc) as well as the potential to bridge to other VOIP or messaging systems.<br />
<br />
Other things I am curious about playing with is "adhoc" conference calls that could spawn quickly and privately in the <i>cloud. </i><br />
<br />
Right now it is mostly for fun. I've got basic messaging and TCP voice channels working. I am not interested in building a full blown Mumble server (that already exists!) but curious as to what can be done minimally....<br />
<br />toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-55148292421390429102016-02-16T10:22:00.001-05:002016-02-16T10:25:21.447-05:00S.A.F.E: An IoT compatible ManifestoMy home monitoring projects/products follow a manifesto I call <b>SAFE</b>. SAFE is an acronym for <b>S</b>et <b>A</b>nd <b>F</b>orget <b>E</b>ngineered. It follows the basic tenant that home monitoring systems should be reliable and not require lots of care and attention. <i>You set it and then forget it.</i><br />
<i><br /></i>
This manifesto doesn't exclude IoT (Internet of Things) devices, but it has some rules. Let's consider the class of devices to include: Flood monitors, Stove usage monitors, Motion detectors and Entry/Exit monitors.<br />
<br />
<br />
<ol>
<li>If you don't run off of AC, your nominal battery life should be 5 years. Assume 2 years of worst case (power consumption-wise) performance. Do you check/change your smoke alarm batteries religiously every year? Maybe not. If you can't guarantee 2 years of performance (and you are a critical monitor) then you should run off of house current (AC).</li>
<li>If you need to run when power is loss, then you should have backup batteries that last at least a couple of days. This is particularly important for Flood monitors, etc.</li>
<li>If you can't automatically recover from a power failure, use backup batteries to keep the system running or use persistent memory to snapshot states.</li>
<li>Your device should have some "local" alert capability and not rely 100% on the Internet for notification. If I am in the house, there should be an audible alarm and not reliance on my smart phone being notified via the Internet.</li>
<li>If Internet notification is critical, don't trust Wi-Fi. Let's use an analogy: Your car's critical systems (engines, steering, braking, locks, etc) <b>should, </b>by design, run on a separate network than your Entertainment system (radio, etc). Your IoT device probably should follow that same rule. Wi-Fi can get congested, it can have password changes, it is a common target for attack. But what can you use instead of Wi-Fi? Consider ZigBee, XBee or other more robust protocol (no, not Bluetooth!) as the delivery transport to the home <b>router</b>. All home routers still feature Ethernet ports so your transport receiver can be plugged in there. You still rely on the monitor but you are not affected by all the issues with Wi-Fi. Now, of course, you should consider encryption and authentication too when using a non-Wi-Fi protocol...</li>
<li>Don't design for over the air software/firmware updates. This is a HUGE security hole and although you may have thoroughly thought it through -- you haven't. Get your software as correct as possible and consider doing updates through a computer or smartphone "directly" and "physically". Things that can be controlled through the Internet will be a nice fat target for people who want to control your stuff through the Internet. Don't advertise your house as hackable!</li>
<li>No SD cards. Nope. SD cards are not designed for reliability or longevity. Use persistent memory that has at least a 10 year retention.</li>
<li>No rechargeable batteries. How long do you really get on a L-ion/poly? Two years? Five years?</li>
<li>Avoid LCD/button interfaces as much as possible. What is this, the 1990s? If you need a way to silence an alarm or (temporarily) disable a sensor use touch or tap and a simple indicator. </li>
<li>No disabling or critical manipulation through the Internet. Sorry, see #6.</li>
<li>Know thy hardware. Don't just choose a Raspberry Pi or Arduino unless you know exactly how each critical component is rated (e.g. environmentals, write duration, etc).</li>
<li>Know thy software. Don't just load up a Linux and go. Are there processes running you don't understand? Update software maybe? </li>
</ol>
<div>
I try and to design to these tenets. I am surprised how many commercial IoT devices seem to ignore them. </div>
<br />
<i><br /></i>
<i><br /></i>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-71117461542603493712015-11-25T13:24:00.002-05:002015-11-25T13:24:32.023-05:00Elderly Monitoring: Revisiting with Brutal SimplicityShort backstory: <br />
<blockquote class="tr_bq">
<br />I've been running over a year now with the current Elderly Monitor system in my house. Mother-in-law has dementia and the current system lets us know her general movements throughout her living space (e.g. how long has she been up this morning? How many trips to the bathroom?) and whether or not she has opened the front door (e.g. is she going for a walk? Has she made her escape?).<br />The current system consists of X10 wireless monitors for the door (open/close) and living spaces (motion detection). This is fed to a small Linux computer I've coded with tracking logic, the ability to speak "Front Door is Open", and the ability to communicate (event message and status query) using XMPP to a cloud server (Digital Ocean) and to our smart phones (running Xabber XMPP clients).<br />It has been a success but with the lessons learned I've found the most critical aspect of this setup is the ability to simply detect that the front door has opened and then notify us via a speaker in our bedroom. All of this flows from X10 to Linux computer to soundcard (the Cloud is not involved here). Still, this seems overly complex. Can it be simplified yet still be expanded to deal with "enhancements" in the future?</blockquote>
<br />
Let's review some of the short comings of the current solution:<br />
<br />
<ol>
<li>X10 Wireless - This has been "mostly" reliable and inexpensive. Still, I do have an RF noisy house and what if the neighbor starts using X10 RF? (Not likely, but for a rock solid solution, this is a weakness). Also X10 pretty much means that I have to have a full blown PC (with X10 CM19a transceiver) unless I decide to seriously hack the protocol and build my own RF receiver.</li>
<li>The PC - Why do I need a full blown PC just to do the basic "Door is Open"? </li>
<li>The Cloud - Sure, I've got it, but if I want to distribute the "Door is Open" beyond the bedroom speakers, I have to connect via the Cloud (currently) and subscribe to XMPP messages (essentially what I do with the smartphone). I need to make some of this stuff local.</li>
<li>Batteries. Batteries. Batteries - Damn. Did the X10 sensor batteries die? When did I change them last? Ugh.</li>
<li>There is no indication of whether or not she has just opened the door or left the house. I can code this logic, but since I want to address the above short comings first, this will have to wait.</li>
</ol>
<div>
What is the simplest thing I can possibly do? Especially if I want to add logic like #5?</div>
<div>
I am revisiting this problem and addressing it with brutal simplicity. </div>
<div>
<br /></div>
<div>
Two things are going to get ripped out:</div>
<div>
<ol>
<li>The PC. No more computer. A microcontroller should be able to do this.</li>
<li>No more X10. I'm going "wired". No more batteries either. I want to "set and forget" this thing. I'll deal with a little wiring. All of the current sensors are less than 20 feet apart: Door, hallway, bedroom, bathroom.</li>
</ol>
<div>
Stay tuned. More details to follow as I hash out my brutal "simplest thing that could possibly work" design.</div>
</div>
<div>
<br /></div>
<div>
<br /></div>
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com0tag:blogger.com,1999:blog-16578308.post-79224707817469799642015-10-19T10:41:00.002-04:002015-10-19T10:41:54.472-04:00Elderly Monitoring: Telling a Story with minimal sensorsHow many sensors do you need to tell a story?<br />
<br />
I have a motion sensor in my mother-in-law's room, her bathroom (down the hall from her bedroom) and an open/close sensor on the house front door (which is next to her room). With just these two (cheap) X10-RF sensors I can tell a lot about the nightly activity of my dementia suffering guest.<br />
<br />
If you haven't been following this blog's "elder care" stories: My mother-in-law has dementia so she lives with me and my family. She is apt to get confused and wander. Her room (the only available extra room in the house) is unfortunately next to the front door. The rest of the bedrooms are one floor up. Mother-in-law needs constant monitoring. She has "escaped" our house several times (at night and at dawn -- when we are still asleep) with the idea that she is going to walk to "her house". She also complains of insomnia and chronic pain. Is she sleeping at night? Is she up wandering the house?<br />
<br />
So, I've designed a cheap sensor-based monitoring system. I explained that tech setup elsewhere. Here I want to posit the question: What kind of "story" can you tell with a couple of sensors?<br />
<br />
With just a bedroom, bathroom motion sensor and a sensor to alert us when she opens the front door, I can talk about the following:<br />
<br />
<ul>
<li>Did she leave the house or is she just "checking the weather" (door opens but is followed by movement in her bedroom)?</li>
<li>Is she restless at night (motion in bedroom)?</li>
<li>How many times did she visit the bathroom?</li>
<li>Is she in the bathroom for an unusually long time? (Bathrooms are where a high incident of heart attacks tend to occur)</li>
<li>When did she get up in the morning? (Motion in bedroom, then bathroom, then bedroom again)</li>
</ul>
<div>
Now, my current software doesn't tell a complete story (yet), but with the reports/alerts it generates, my wife and I can determine with a quick view of the data on our smartphone, any of the above scenarios.</div>
<div>
<br /></div>
<div>
I'd like to add a couple more sensors, maybe a light sensor and temperature monitor for the bedroom to help flesh these stories out.</div>
<div>
<br /></div>
<div>
The moral (of this post) is: You can tell a lot with just a few sensors and a lot of common sense. It isn't about the "hardware tech". It is, ultimately, about making sense of data. I want to get my software to the point where it "tells the story" rather than just provide data for my wife and I to review. Here is my ideal morning report (sent to my phone instead of the raw data events):</div>
<div>
<br /></div>
<blockquote class="tr_bq">
Betty slept between 9:30pm and 6:15am, awaking at 11:15pm and 2:30am to go to the bathroom. At 6:30am she opened the front door, closed it and went back into her room. Her room light has been on since 6:45am and there is currently no movement in her room.</blockquote>
I don't need this report in verbose english (like above), but I should be able to quickly derive the above story from summarized data points. All of this can be surmised by the current three sensors.<br />
<br />
toddbothttp://www.blogger.com/profile/00551771132277351922noreply@blogger.com2