Tuesday, October 04, 2016

Spinning a motor is hard

I'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?


Sinusoidal commutation of BLDC motors is hard.  Even so-called "open loop" commutation (which still expects feedback -- is it still really "open"?) is difficult.

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.

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?

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.

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....)

I'm really learning how much I don't really know.

Spinning a motor is hard...

Tuesday, May 24, 2016

Taking a SIP from the VoIP fountain....

Bad metaphorical post title aside (ouch),  I am currently investigating "cutting the Vonage cord" (another bad metaphorical allusion).

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).

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 swim in someone else's pool (sorry about that, there I go again).

But, hey... wait a minute!  I am a software engineer who specializes in communication.  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!

I could...

  • 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)
  • Forward the call to voice mail immediately if we aren't home.
  • Register another "business" phone number that does something similar... basically track me down (e.g. smartphone or home number or voicemail)
..and so much more!

So, I start looking at FreeSWITCH and Asterisk.  Wow!  I need a book, or two, and a lot of time.
(Another variation of swimming in someone else's pool).

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.)

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....

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 just enough to do what I want.  How better to learn a system than to dive right in and try to build one yourself?

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.

So, I start with the SIP RFC .  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?

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 I am going to have fun with it and I am going to learn a lot. 

Maybe I'll finish enough of it to put it out there as open source. Not an OpenSIP competitor, but a super simple, super hacky way of creating your own lightweight home VoIP system.

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!

Saturday, April 09, 2016

Hackable (Software) Things

I like hackable things. I'll keep that vague, because I am in a vague mood.
See if you can spot the common theme:

  1. Emacs
  2. TeX / LaTeX
  3. Forth (interactive on an MCU)
  4. Snabb Switch
  5. Smalltalk  (Squeak)
  6. Unix command line (awk, sed, kornshell, bourne shell, maybe bash, etc)

Okay... why?

They are worlds at my fingertips.
They don't use XML.
They are extensible.
I can make them do useful things.
With the exception of #3 (Forth), none really manipulate the "physical world".

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.

Something I would love to have for embedded MCU work:

A nice REPL / Editor environment (host side, please) for manipulating/deploying eLua on MCUs. 
eLua has poor interactivity support, but I wonder if remotely instrumenting it is a better approach... maybe via ZeroBrane or Emacs?

Monday, February 22, 2016

Premature Optimization during Design

As 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?

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.

Now, TeX (same sources pretty much) can run on your Android phone.

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).

Now, I install it on every Linux/BSD laptop I use and fire it up as needed.

These systems (and others) were not designed to work on minimal hardware, but over the years hardware caught up with them.

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?

Tuesday, February 16, 2016

Mutter... Adventures in VOIP/messaging systems

Over the past couple of years I've been playing around with a "toy" Mumble server I developed.
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).

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.

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.

Other things I am curious about playing with is "adhoc" conference calls that could spawn quickly and privately in the cloud. 

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....

S.A.F.E: An IoT compatible Manifesto

My home monitoring projects/products follow a manifesto I call SAFE.  SAFE is an acronym for Set And Forget Engineered.  It follows the basic tenant that home monitoring systems should be reliable and not require lots of care and attention.  You set it and then forget it.

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.

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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) should, 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 router. 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...
  6. 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!
  7. No SD cards. Nope. SD cards are not designed for reliability or longevity. Use persistent memory that has at least a 10 year retention.
  8. No rechargeable batteries.  How long do you really get on a L-ion/poly?  Two years? Five years?
  9. 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. 
  10. No disabling or critical manipulation through the Internet.  Sorry, see #6.
  11. 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).
  12. Know thy software. Don't just load up a Linux and go. Are there processes running you don't understand? Update software maybe? 
I try and to design to these tenets. I am surprised how many commercial IoT devices seem to ignore them. 

Wednesday, November 25, 2015

Elderly Monitoring: Revisiting with Brutal Simplicity

Short backstory:

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?).
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).
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?

Let's review some of the short comings of the current solution:

  1. 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.
  2. The PC - Why do I need a full blown PC just to do the basic "Door is Open"?  
  3. 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.
  4. Batteries. Batteries. Batteries - Damn. Did the X10 sensor batteries die? When did I change them last? Ugh.
  5. 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.
What is the simplest thing I can possibly do?  Especially if I want to add logic like #5?
I am revisiting this problem and addressing it with brutal simplicity. 

Two things are going to get ripped out:
  1. The PC. No more computer. A microcontroller should be able to do this.
  2. 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.
Stay tuned.  More details to follow as I hash out my brutal "simplest thing that could possibly work" design.

Monday, October 19, 2015

Elderly Monitoring: Telling a Story with minimal sensors

How many sensors do you need to tell a story?

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.

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?

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?

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:

  • Did she leave the house or is she just "checking the weather" (door opens but is followed by movement in her bedroom)?
  • Is she restless at night (motion in bedroom)?
  • How many times did she visit the bathroom?
  • Is she in the bathroom for an unusually long time? (Bathrooms are where a high incident of heart attacks tend to occur)
  • When did she get up in the morning? (Motion in bedroom, then bathroom, then bedroom again)
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.

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.

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):

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.
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.