Long life logger using eeprom and bluetooth

I'm not sure if this forum is for showing off completed projects, or the discussion of problems associated with current projects, so if I am polluting this forum please let me know and I will move this, or split it into discrete isssues.

I have a project to create a low battery consuming GPS logger that I would like to be able to periodically query over the air using bluetooth, I have most of the kit already and have ordered the GPS unit shown in the tutorials. I want the unit to be as small as possible but I am initially planning to use an Espruino 1.4.

However I have a couple of nagging queries about my approach.

I calculated that to log for 100 days I would need to log 15.5k of data, timestamp and gps coords every 6 hours. e.g.

2016-05-01 12:00:00,1.234567,-1.234567
2016-05-01 18:00:00,1.234567,-1.234567
2016-05-01 24:00:00,1.234567,-1.234567
2016-05-02 04:00:00,1.234567,-1.234567

I initially thought of logging to SD card, but after some reading I think for the sake of conserving battery, and reliability I think using eeprom could be better.

Q1. Is that a reasonable approach?

To access the data when nearby with BT I wanted to use the modules I have, HC-05
Q2. As that link shows, its a simple matter of soldering that to the prototype area of the Espruino, but how/where would I then attach an eeprom? This discussions I have seen mention soldering the eeprom to the prototype area too, you see?

Q3. Assuming that is all physically do-able, could I then command, via BT the reading of the eeprom, and if successful, the deletion of the eeprom to empty it? (I am guessing these would be js functions/classes I'd call over BT)

Oh, and being able to understand remaining battery life would be a bonus too...

I haven't used BT or eeprom ever before, but I look forward to tackling these issues one by one myself, honestly I just wanted a heads-up on my general approach, and maybe a couple of potholes that I'd face.

Thanks.

@Dennis made a nice Module for Winbond W25Q SPI flash memory implementation. @DrAzzy has created AT25 module - SPI EEPROMS (LIKE AT25256) - that became available already with release 1v72, see overview page. There you find also a link to the option to use the (PICO) on-chip flash for that (with ready available module and sample code).

Hi - yes, it's definitely the right place for completed or in-progress projects :)

Q1. Is that a reasonable approach?

EEPROMS are good but often aren't that big, but as @allObjects says there's external flash chips, or even on-chip flash on the Pico or original Espruino.

or I believe that some of the SD cards don't draw much power at all. It'd be a matter of testing, but I imagine that if you found a small capacity card (64MB, if they still make them?) power consumption would be pretty good.

To access the data when nearby with BT I wanted to use the modules I have, HC-05

You may need to change some settings on the module itself, as (at least when connected) it can end up drawing quite a lot of power. If you google HC-05 SNIFF mode you should find some info on this.

its a simple matter of soldering that to the prototype area of the Espruino, but how/where would I then attach an eeprom?

The bluetooth goes on the opposite side of the board, leaving the prototype area clear :)

Q3. Assuming that is all physically do-able, could I then command, via BT the reading of the eeprom, and if successful, the deletion of the eeprom to empty it? (I am guessing these would be js functions/classes I'd call over BT)

Yes - actually by default, when USB is disconnected Espruino puts the JS console onto Serial1 (which is connected to bluetooth), so you can actually just interact with it as normal. For instance issueing myFunction()\n will call a function of that name.

Oh, and being able to understand remaining battery life would be a bonus too...

For this, you'd probably just need to do some tests to figure out how much power the board was drawing and just guess based on that.

However you could attempt to measure the battery voltage, but the depends a bit on the battery (and also the temperature I think)

Thanks both for the encouraging replies. I was thinking of only waking up the BT once a day, after one of those 6 hour logging periods probably - for about 5 minutes - if I make contact then do the necessary and then let everything go to sleep again.

I believe that some of the SD cards don't draw much power at all. It'd
be a matter of testing, but I imagine that if you found a small
capacity card (64MB, if they still make them?) power consumption would
be pretty good.

Right, so using a smaller SD card would result in less complexity but possibly slightly more power usage, but heck, at four writes per day this could well be negligible. I will try this first, I think I jumped at the idea of eeprom because it is something I know little about.

I was wondering why you made that comment about smaller SD cards and found this discussion (Arduino forum ftw). New knowledge, thanks.

I know Espruino is great for this kind of extended battery project, so I am looking forward to extending my skills and knowledge.

OK, I have returned to this project finally.

The GPS unit (ublox Neo-6m-0-001) works fine, takes about a minute before it gets a "fix".

Got BT working, so I can read the SD card remotely.

The problem I am having now is understanding how to turn off the GPS unit, I mean it needs to be powered off for 4 hours until its next wake up call. I am guessing that cold starting the GPS will consume far less power than keeping it powered on (warm?).

This is inside a setInterval() loop - I was thinking of setting a flag to break myself out of the setInterval() loop, but now am doubting that is the correct way to think about this.

bGotFix = 0;
  
  var gps = require("GPS").connect(Serial4, function(data){
    
    if(data.fix == 1) {
// todo this will be logged to sd card
       console.log(data.time, data,lat, data.lon);
       bGotFix = 1;
    } else {
// debug
       console.log('no fix yet');
    }
    
  });

Traditionally I'd check data.fix is true, stop the interval code, but how to turn off the GPS? Or do I need to?

It looks to me that you have several levels / scopes of what is awake and powered... Several (nested) intervals - or better: timeouts (made to escape-able intervals with self invocation) - switch on and of different areas of your logger. A state-machine could be used to control the walking through a cycle.

In an earlier post, @Gordon pointed out that Espruino pins hold their state even when on sleep - don't know about the deep sleep though... but anyway. Therefore, you could give your GPS a heads-up - I man power - and then go to sleep - with a timeout - for another few minutes until actually reading the data. If something is not ready yet, 'snooze' until it is ready with - of course - some retry (snooze) limiting algorithm. After getting a satisfactorily set of data of satisfactorily data quality, you switch the GPS off and do the rest of the work.

Since you have the last recent GPS data, use it when restarting GPS the next time. A GPS gets much faster on the road when you can tell it something, and the closer you input is to the actual location, the quicker the GPS is catching up.

Regarding code in your post, data is just a (particular) sentence that the GPS delivered (in object form, and sometimes some of the properties are missing). Checkout the GPS Module, Extensions for handling other sentences, and u-blox NEO-6M GPS receiver conversation about getting out of the GPS you may need to. You can also configure the GPS to do better what you want and let alone what you are not interested in.

Thanks, I never tried a state machine in JS (knowingly) I will break the code out into doing that if I can. I've used FSMs before, and can lead to much cleaner code. The more I think about this the more exceptions I will have to cater for.

you switch the GPS off and do the rest of the work.

This is my immediate stumbling block, do I do that by somehow disconnecting Serial4, by turning a control pin to 0, or ... tell 'gps' it is null? What is the correct method to power it down?

A GPS gets much faster on the road when you can tell it something

I had not thought of that at all, nice.

I quickly read through the NMEA spec previously, so I realise I could just extract the things I actually need for this project, but I'm happy enough the existing GPS.js spews out figures. I mean I am still (maybe stuck?) in that ridiculous/happy/delirious stage of "**** me, it works!".

I've combed my way up and down the docs, but cannot for the life of me see the correct way to turn a component off.

"**** me, it works!".

there are many of these **** stages... I'm glad you enjoy this.

According to the u-blox NEO 6M datasheet - p 13..15, you need min. 2.7V and max 67 mA... Power saving mode still 'sucks' in more than one way: 11 mA... That means you have to go for a switch... A MOSFET would for sure do. You may even go for a low side switch and still have enough low in GPS' low signal to be detected as low. Worst case, you have to add a voltage divider... but will increase noise sensitivity... I looked into just paralleling CMOS gates to get enough power... but that's not go-n-a happen. Paralleling of Espruino pins could work though... just make sure you do not overdraw the total of the STM32 chip, because all other sourcing pins count into the total as well. 3 pins may be able to do it, better 4. I'll give it a shot...

several hours later: see proof of concept at GPS powered by Espruino pin(s).

Update on this. After many distractions, hw fails and quite a bit of effort my long life GPS logger is largely working as I wanted. Thanks for the help.

I ended up using a MOSFET to switch power to the GPS, new knowledge and a new ability for me (and some more ugly soldering, sigh). I'm keeping it simple and logging to SD. I stuck with the HC-05 and this is working decently. The learning curve concerning the switching from USB to Serial1 console was steeper than I thought, but have now finally grokked that. I'm using Blueterm to query the unit at set times. (Blueterm+ does not have an output save option).

I am doing some more tests now and I will post back how long I expect it to last on which sized battery, pseudo code :

wake up every hour, on the hour
if h hour is a match, turn on gps, log data,
if h hour is a match, turn on Serial1 and listen for instructions for m minutes
go back to deep sleep

However, as I work though this project it has become clear to me (as I am horizon watching all the time) that instead of me having to physically be next to the device to download the captured data over BT at a very exact set time which may not be convenient, I could use a beacon to detect my phone is in range, and they wake up the device and switch Serial1 on for m minutes.

Now I've ordered some Pucks like a good-un but I think they'd be overkill for this . I wondered if anyone could give me a pointer on whether there are any basic cheap beacons I could use for this, and if they've had any luck getting a beacon to send enough power to signal to Espruino to wake out of Deep Sleep? Is this even doable?

This would make things far more convenient.

That's a thought... I imagine that any BLE beacon with an LED on it that's controllable via BLE would be usable - then you can just wire on to the LED. Espruino doesn't need much power to wake it up.

Might the HC-05 have a 'connected' LED you could use for Wakeup? Although unless you tweak the settings on it a lot, the HC-05 tends to use quite a lot of power.

The other option is something like an Adafruit Bluetooth LE module. These have a UART mode on them. I'm not sure about RTS/CTS, but it might be possible to get those out of it and then you can use them to control deep sleep.

So you could then ditch the standard Bluetooth module and could do everything (including Wakeup) through Bluetooth LE.

Thanks for your considered thoughts Gordon.

Yeah, finally worked out for myself that the HC-05s get through a lot of current, and the general lack of quality documentation (and discussion on StackOverflow) concerning the whole myriad of settings around their SNIFF settings left me flummoxed. Plus, classic BT is not really getting me the transmission distance I'd like.

Anyhow, for anyone in the same boat I figured my options at that point included:

• de-soldering the HC-05 from that awfully useful Serial1 "pad" on the Espruino and maybe wiring the power through a MOSFET too (I'm still in "Wow MOSFETs are cool" mode).

• Ordering some HM-10s, but essentially that would still need the same ability to turn on/off

• Using the beacon idea

n00b101 moment : A major light bulb (well, LED I suppose) moment for me came when I finally understood DeepSleep. Just because the setSleepIndicator LED occasionally flickers does not mean the sum of all the kit welded to your Espruino is only using 0.04mah when asleep! Wire your multimeter in line with your battery early on, and assume nothing.

As it happens I had some old Xbee units from a few years ago when I first started tinkering, so have spent the last few days in Xbee Javascript Hex data-packet hell, but now ready to put all this back together and test if I can power that up/down at will.

Learning about Xbees might be a dead end, I realise, but it reminds me very much of s/w dev when I was learning Design Patterns. Reading about concepts is one thing, putting them into practice is entirely different - and is the only way (at least for myself) I can hammer the facts/issues into my brain so they stay learned.

Xbees make the whole solution rather expensive, but if I have something that works it will be good, I can then start swapping components and ideas.

Ultimately, BTLE and beacons is the way to for now. Anyone else thinking of going to Nordics BTLE dev day in Copenhagen?

Wire your multimeter in line with your battery early on, and assume nothing.

Yeah, I can try and get Espruino's sleep power down, but so much other stuff draws a lot of power (especially the breakout boards that tend to have high power voltage regulators)

Xbee

Well, it might be 'old' but it's used in enough stuff that I doubt XBee is going anywhere any time soon. It's just a shame the price is so high.

Nordic dev day

I did one in the UK... If it's anything like that, there's loads of nRF52-based info, and you might even get a free dev board. It may not deal with programming languages, but if it does, it'll all be C though.

It'll give you a good idea what the chip is capable of. It's actually really clever inside - you can wire peripherals together without getting the CPU involved.

You just have to promise not to come back here and ask why Puck.js doesn't use feature X - or if you do want it you'll have to implement it :)