Wednesday, October 02, 2019

Wandering Tag - Discreet GPS tag for people and pets

It'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 "elderly monitoring" (I even had a side blog addressing this).

An decenet Elderly monitoring system would include some lightweight tracking capabilities (i.e. for early dementia sufferers who tend to wander from the house).

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.

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.

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

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.

I've gotten requests for pointers to "pet tracker" products.  I found a few, with Amazon's Fetch  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).

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

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.

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

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.

More to come... stay tuned.

Thursday, June 06, 2019

Sleepy Bee to MSP430 to STM32L031... Woeful complexity

I need a simple very, very low power MCU to form the basis of coin cell sized IoT sensor monitoring.
Here is what it needs to do:

  1. Control the Semtech SX1276 LoRa chip via SPI
  2. Talk to an accelerometer via I2C
  3. Spend a lot of time sleeping waiting for accelerometer events.
  4. Wake up, send a LoRa command and go back to sleep
  5. Wash, rinse, repeat.

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

So, I need to choose...

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.

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

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.

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.

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.

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.

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.

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.

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.

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. 
But at $6 (  it's insanely pricey.  The STM32L031 (which has more memory, features, smaller sizes and uses less power) is only around $2.50.

Honestly, I am not making millions of devices so a few dollars here and there doesn't really matter.

But I have to ask myself... is it worth the complexity?

Wednesday, May 15, 2019

Frustrated with Complexity

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

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

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.

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.

Why?  Because I'm pedantic that way.  Close to the metal, baby!

Sunday, March 17, 2019

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

But, in the meantime, a bit of catch-up:

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. 

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

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

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

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.