EspWifiTracker - Revision history

Bertrik Sikken: /* Server backend */

2024-12-01T10:54:37Z

Server backend

← Older revision		Revision as of 10:54, 1 December 2024
Line 159:		Line 159:
	* [https://developers.google.com/maps/documentation/geolocation/intro Google maps geolocation API]		* [https://developers.google.com/maps/documentation/geolocation/intro Google maps geolocation API]
	* [https://location.services.mozilla.com/ Mozilla Location Service]		* [https://location.services.mozilla.com/ Mozilla Location Service]
	* [http://www.openwlanmap.org OpenWLANmap.org~~] / [http://openwifi.su OpenWifi.su~~]		* [http://www.openwlanmap.org OpenWLANmap.org]
	* see also this [https://en.wikipedia.org/wiki/Wi-Fi_positioning_system WiFi positioning page] on Wikipedia.		* see also this [https://en.wikipedia.org/wiki/Wi-Fi_positioning_system WiFi positioning page] on Wikipedia.

Bertrik Sikken at 07:51, 2 September 2018

2018-09-02T07:51:57Z

← Older revision		Revision as of 07:51, 2 September 2018
Line 3:		Line 3:
	\|Picture=EspWifiTracker2.jpg		\|Picture=EspWifiTracker2.jpg
	\|Omschrijving=Location-tracker based on WiFi station ids		\|Omschrijving=Location-tracker based on WiFi station ids
	\|Status=~~In progress~~		\|Status=Stalled
	\|Contact=bertrik		\|Contact=bertrik
	}}		}}

Bertrik Sikken: /* Software */

2018-05-26T12:40:50Z

Software

← Older revision		Revision as of 12:40, 26 May 2018
Line 90:		Line 90:

	Other libraries used:		Other libraries used:
	* [https://github.com/Makuna/Rtc Makuna RTC] which can be installed into the Arduino environment by going to menu Sketch/Include Library/Manage libraries..., then searching for 'Makuna rtc' and installing it.		* [https://github.com/Makuna/Rtc Makuna RTC] (by "Makuna" - Michael Miller) which can be installed into the Arduino environment by going to menu Sketch/Include Library/Manage libraries..., then searching for 'Makuna rtc' and installing it.

	My prototype software can be found at:		My prototype software can be found at:

Bertrik Sikken at 06:49, 15 August 2016

2016-08-15T06:49:25Z

← Older revision		Revision as of 06:49, 15 August 2016
Line 105:		Line 105:

	==== AP selection ====		==== AP selection ====
			TODO: check out https://wiki.bitlair.nl/Pages/Projects/KPN_Hotspots_Autologin and see if I can run it inside an ESP.

	I'm thinking of a kind of whitelist/blacklist mechanism to select an AP for uploading data.		I'm thinking of a kind of whitelist/blacklist mechanism to select an AP for uploading data.
	The plan is to score each scanned AP against this list and then select the one with the highest score, excluding APs which have a negative score. The first match in the list determines the score, so the list is ordered from most specific to least specific.		The plan is to score each scanned AP against this list and then select the one with the highest score, excluding APs which have a negative score. The first match in the list determines the score, so the list is ordered from most specific to least specific.

Bertrik Sikken: Add link to server code

2016-07-12T22:47:43Z

Add link to server code

← Older revision		Revision as of 22:47, 12 July 2016
Line 11:		Line 11:

	News:		News:
			* 2016-07-13 Published some ugly Java code for the server side of this project, see https://github.com/bertrik/wifitrackerserver
	* 2016-06-12 Measured power consumption of an alternative ESP8266 board, the Wemos D1, it does indeed draw a lot less power in sleep mode than the NodeMCU (about 0.16 mA, should last about 180 days on a 700 mAh battery)		* 2016-06-12 Measured power consumption of an alternative ESP8266 board, the Wemos D1, it does indeed draw a lot less power in sleep mode than the NodeMCU (about 0.16 mA, should last about 180 days on a 700 mAh battery)
	* 2016-06-12 Figured out how the DS3231 RTC alarm works: the RTC alarm sets an internal alarm flag and makes the RTC SQW pin low, however the SQW pin stays low until the alarm is cleared in software.		* 2016-06-12 Figured out how the DS3231 RTC alarm works: the RTC alarm sets an internal alarm flag and makes the RTC SQW pin low, however the SQW pin stays low until the alarm is cleared in software.
Line 150:		Line 151:

	== Server backend ==		== Server backend ==

			Initial code for the server code receiving uploads from the trackers: https://github.com/bertrik/wifitrackerserver

	The server backend receives uploads from the tracker and resolves the WiFi station ids into locations by using a location service, for example:		The server backend receives uploads from the tracker and resolves the WiFi station ids into locations by using a location service, for example:
	* [https://developers.google.com/maps/documentation/geolocation/intro Google maps geolocation API]		* [https://developers.google.com/maps/documentation/geolocation/intro Google maps geolocation API]

Bertrik Sikken at 21:13, 12 June 2016

2016-06-12T21:13:32Z

← Older revision		Revision as of 21:13, 12 June 2016
Line 173:		Line 173:

	== Results ==		== Results ==
	=== Power consumption ===		=== NodeMCU Power consumption ===
	I've measured the current drawn from the battery under different circumstances.		I've measured the current drawn by an NodeMCU board from the battery under different circumstances.

	Results:		Results:
Line 181:		Line 181:
	* in deep sleep mode: 3.9 mA		* in deep sleep mode: 3.9 mA

	The deep sleep mode current is a very disappointing, I was expecting a lot lower.		The NodeMCU deep sleep mode current is a very disappointing, I was expecting a lot lower.
	Just this current will drain a 700 mA battery in about a week.		Just this current will drain a 700 mAh battery in about a week.
	Disconnecting the RTC gives a current of 3.3 mA, so most of the deep sleep current appears to be consumed somewhere on the nodemcu board.		Disconnecting the RTC gives a current of 3.3 mA, so most of the deep sleep current appears to be consumed somewhere on the nodemcu board.

			=== Wemos D1 mini power consumption ===
			This board seems to draw about 0.16 mA in deep sleep mode.
			Draining a 700 mAh battery would take about 180 days, quite acceptable.

	=== 2016-04-23 ===		=== 2016-04-23 ===

Bertrik Sikken at 21:09, 12 June 2016

2016-06-12T21:09:18Z

← Older revision		Revision as of 21:09, 12 June 2016
Line 80:		Line 80:
	==== Wake up from sleep ====		==== Wake up from sleep ====
	Basically I know of two practical mechanisms to save power by going into deep sleep and waking up again:		Basically I know of two practical mechanisms to save power by going into deep sleep and waking up again:
	1) Connect pin D0 (GPIO16/WAKEn) to the RST pin and use the ESP.deepSleep(x) command. This ~~put~~ the ESP into a low-power deep sleep mode for x microseconds. After these x microseconds, pin D0 pulses low causing a reset of the entire ESP8266. I think this can ~~only~~ keep the ESP in sleep mode for about ~~1h11m35 seconds~~ (2**32 microseconds).		# Connect pin D0 (GPIO16/WAKEn) to the RST pin and use the ESP.deepSleep(x) command. This puts the ESP into a low-power deep sleep mode for x microseconds. After these x microseconds, pin D0 pulses low causing a reset of the entire ESP8266. I think this can keep the ESP in sleep mode for a maximum time of about 1h11m35s (2**32 microseconds).
	2) Put the ESP to sleep using the ESP.deepSleep(0) command and use an external RTC to generate a reset pulse on a specific wake-up time. The DS3231 RTC ~~allows to~~ generate a signal on an arbitrary date and time, but it outputs a level-like signal (low if the alarm has triggered). You cannot tie this signal to the ESP reset pin because it would keep the ESP in reset indefinitely. The trick is to connect a 1 microfarad ~~capacitor~~ between the RTC alarm output and the ESP reset input. The capacitor turns the low-going edge into a negative pulse, causing only a short reset pulse after which the ESP can clear the alarm in the RTC.		# Put the ESP to sleep using the ESP.deepSleep(0) command and use an external RTC to generate a reset pulse on a specific wake-up time. The DS3231 RTC can generate an alarm signal on an arbitrary date and time, but it outputs a level-like signal (low if the alarm has triggered). You cannot tie this signal to the ESP reset pin because it would keep the ESP in reset indefinitely. The trick is to connect a capacitor (about 1 microfarad) between the RTC alarm output and the ESP reset input. The capacitor turns the low-going edge into a negative pulse, causing only a short reset pulse after which the ESP can clear the alarm in the RTC.

	=== Software ===		=== Software ===

Bertrik Sikken at 20:49, 12 June 2016

2016-06-12T20:49:27Z

← Older revision		Revision as of 20:49, 12 June 2016
Line 11:		Line 11:

	News:		News:
	* 2016-06-12 ~~The~~ Wemos D1 does indeed draw a lot less power in sleep mode than the NodeMCU ~~does~~ (~~I measured~~ 0.16 mA, should last about 180 days on a 700 mAh battery)		* 2016-06-12 Measured power consumption of an alternative ESP8266 board, the Wemos D1, it does indeed draw a lot less power in sleep mode than the NodeMCU (about 0.16 mA, should last about 180 days on a 700 mAh battery)
	* 2016-06-12 Figured out how the DS3231 RTC alarm works: the RTC alarm sets an internal alarm flag and makes the RTC SQW pin low, however the SQW pin stays low until the alarm is cleared in software~~, this a bit impractical. Perhaps I'll use a capacitor to convert the level based alarm signal into a reset-pulse~~.		* 2016-06-12 Figured out how the DS3231 RTC alarm works: the RTC alarm sets an internal alarm flag and makes the RTC SQW pin low, however the SQW pin stays low until the alarm is cleared in software.
	* 2016-04-25 Measured power consumption of the NodeMCU board. The consumption in deep-sleep is a rather disappointing 3.3 mA (expected something < 1 mA). I might need to go to a different ESP8266 platform than the NodeMCU.		* 2016-04-25 Measured power consumption of the NodeMCU board. The consumption in deep-sleep is a rather disappointing 3.3 mA (expected something < 1 mA). I might need to go to a different ESP8266 platform than the NodeMCU.
	* 2016-04-19 Connected a LiFePO4 battery and made a scan of the trip from RevSpace to Gouda, one point every 20 seconds. Using this kind of battery to power the ESP8266 directly seems to work fine!		* 2016-04-19 Connected a LiFePO4 battery and made a scan of the trip from RevSpace to Gouda, one point every 20 seconds. Using this kind of battery to power the ESP8266 directly seems to work fine!
Line 26:		Line 26:

	Open challenges:		Open challenges:
	* first of all make a working prototype, not necessarily optimized yet for size / appearance / battery usage / etc
	* make it lower power: so we can use a smaller battery or get longer tracking time. First of all, I should get an idea of the power consumption in its current state.
	* make it smaller and lighter: so it can be attached to smaller items (e.g. a migrating bat)		* make it smaller and lighter: so it can be attached to smaller items (e.g. a migrating bat)

	Decisions:		Decisions:
	* Forget about trying to access the web using unsecured access points. ~~Access~~ points ~~like this~~ are highly likely to be run with a captive portal, which are non-trivial to bypass automatically.		* Forget about trying to access the web using unsecured access points. Open access points are highly likely to be run with a captive portal, which are non-trivial to bypass automatically.

	== Introduction ==		== Introduction ==
Line 46:		Line 44:
	* the tracker is in deep-sleep most of the time, keeping only a low-power real-time-clock running.		* the tracker is in deep-sleep most of the time, keeping only a low-power real-time-clock running.
	* every once in a while (say once a day) it wakes up, takes a reading of all WiFi stations in range and their signal strength. It stores these in internal memory.		* every once in a while (say once a day) it wakes up, takes a reading of all WiFi stations in range and their signal strength. It stores these in internal memory.
	* if the tracker wakes up to find an ~~open~~ WiFi station ~~(or one~~ that it ~~knows~~ the ~~WiFi password of)~~, it tries to upload all previous readings to a server.		* if the tracker wakes up to find an WiFi station that it can use to access the internet, it tries to upload all previous readings to a server.
	* the server resolves the uploaded data into geographical locations using a service like Google or the Mozilla Location Service.		* the server resolves the uploaded data into geographical locations using a service like Google or the Mozilla Location Service.

	== Tracker prototype ==		== Tracker prototype ==
	~~I'm working on a prototype of this.~~

	=== Hardware ===		=== Hardware ===
Line 56:		Line 53:
	I'm basing this on an [http://www.wemos.cc/Products/d1_mini.html Wemos D1 mini].		I'm basing this on an [http://www.wemos.cc/Products/d1_mini.html Wemos D1 mini].
	This board is basically an ESP8266-module on a break-out board with an USB-serial converter and a proper 3.3V power supply.		This board is basically an ESP8266-module on a break-out board with an USB-serial converter and a proper 3.3V power supply.
	The ESP8266 is a WiFi-capable microcontroller, capable of running at 80 MHz, ~~it has 1~~ MB ~~(or more)~~ of flash onboard ~~which~~ enough spare flash sectors to hold a file system.		The ESP8266 is a WiFi-capable microcontroller, capable of running at 80 MHz, most versions commonly sold have 4 MB of flash onboard with enough spare flash sectors to hold a file system.

	<strike>		<strike>
Line 66:		Line 63:
	This module is attached to the NodeMCU through the I2C-bus on pins D1 (GPIO5/SCL) and D2 (GPIO4/SDA).		This module is attached to the NodeMCU through the I2C-bus on pins D1 (GPIO5/SCL) and D2 (GPIO4/SDA).
	I removed the power LED on board the ZS-042 module, since one of my reasons for using an RTC is to save current by keeping the electronics mostly in low-power sleep mode and the power LED wastes current unnecessarily.		I removed the power LED on board the ZS-042 module, since one of my reasons for using an RTC is to save current by keeping the electronics mostly in low-power sleep mode and the power LED wastes current unnecessarily.
	~~<strike>~~
	~~It would be very nice if the RTC could wake up the ESP8266 using the alarm wake-up feature, but I cannot get this to work: the alarm output always seems to be low, keeping the ESP8266 in reset.~~
	~~</strike>~~

	Pin D5 (GPIO14) is used to distinguish between run mode and debug mode during reset/wake-up.		Pin D5 (GPIO14) is used to distinguish between run mode and debug mode during reset/wake-up.
Line 83:		Line 77:

	Possibly the high power consumption during sleep mode can be fixed like [https://github.com/esp8266/Arduino/issues/719#issuecomment-134392743 discussed here].		Possibly the high power consumption during sleep mode can be fixed like [https://github.com/esp8266/Arduino/issues/719#issuecomment-134392743 discussed here].

			==== Wake up from sleep ====
			Basically I know of two practical mechanisms to save power by going into deep sleep and waking up again:
			1) Connect pin D0 (GPIO16/WAKEn) to the RST pin and use the ESP.deepSleep(x) command. This put the ESP into a low-power deep sleep mode for x microseconds. After these x microseconds, pin D0 pulses low causing a reset of the entire ESP8266. I think this can only keep the ESP in sleep mode for about 1h11m35 seconds (2**32 microseconds).
			2) Put the ESP to sleep using the ESP.deepSleep(0) command and use an external RTC to generate a reset pulse on a specific wake-up time. The DS3231 RTC allows to generate a signal on an arbitrary date and time, but it outputs a level-like signal (low if the alarm has triggered). You cannot tie this signal to the ESP reset pin because it would keep the ESP in reset indefinitely. The trick is to connect a 1 microfarad capacitor between the RTC alarm output and the ESP reset input. The capacitor turns the low-going edge into a negative pulse, causing only a short reset pulse after which the ESP can clear the alarm in the RTC.

	=== Software ===		=== Software ===

Bertrik Sikken at 16:54, 12 June 2016

2016-06-12T16:54:07Z

← Older revision		Revision as of 16:54, 12 June 2016
Line 22:		Line 22:

	Next steps:		Next steps:
	* Experiment with this [http://www.wemos.cc/Products/d1_mini.html Wemos D1 mini] ESP board, and see how much current it draws in sleep mode compared to a NodeMCU.
	* Make some nice Java service to accept the JSON data, store/convert the data to coordinates and host it somewhere		* Make some nice Java service to accept the JSON data, store/convert the data to coordinates and host it somewhere
	* create a kind of blacklist/whitelist mechanism that scores each scanned AP for suitability to connect to the internet, based on AP name / security type / whether we know the password / etc. A negative score could mean that it should definitely NOT try to connect using a specific AP. The AP with the highest score is tried first		* create a kind of blacklist/whitelist mechanism that scores each scanned AP for suitability to connect to the internet, based on AP name / security type / whether we know the password / etc. A negative score could mean that it should definitely NOT try to connect using a specific AP. The AP with the highest score is tried first
Line 55:		Line 54:
	=== Hardware ===		=== Hardware ===
	[[File:EspWifiTracker.jpg\|right\|thumb]]		[[File:EspWifiTracker.jpg\|right\|thumb]]
	I'm basing this ~~off~~ an ~~inexpensive~~ [http://~~nodemcu~~.~~com~~/~~index_en~~.html ~~NodeMCU~~] ~~clone~~.		I'm basing this on an [http://www.wemos.cc/Products/d1_mini.html Wemos D1 mini].
	~~The NodeMCU~~ is basically an ESP8266-module on a break-out board with an USB-serial converter and a proper 3.3V power supply.		This board is basically an ESP8266-module on a break-out board with an USB-serial converter and a proper 3.3V power supply.
	The ESP8266 is a WiFi-capable microcontroller, capable of running at 80 MHz, it has 1 MB (or more) of flash onboard which enough spare flash sectors to hold a file system.		The ESP8266 is a WiFi-capable microcontroller, capable of running at 80 MHz, it has 1 MB (or more) of flash onboard which enough spare flash sectors to hold a file system.

			<strike>
	Pin D0 (GPIO16/WAKEn) is connected to RST to support wake-up-by-reset with the ESP internal deep sleep mode.		Pin D0 (GPIO16/WAKEn) is connected to RST to support wake-up-by-reset with the ESP internal deep sleep mode.
			</strike>

	To keep time, I'm using a ZS-042 clock module, containing a Maxim DS3231 RTC chip		To keep time, I'm using a ZS-042 clock module, containing a Maxim DS3231 RTC chip
	[https://datasheets.maximintegrated.com/en/ds/DS3231.pdf (datasheet)].		[https://datasheets.maximintegrated.com/en/ds/DS3231.pdf (datasheet)].
	This module is attached to the NodeMCU through the I2C-bus on pins D1 (GPIO5/SCL) and D2 (GPIO4/SDA).		This module is attached to the NodeMCU through the I2C-bus on pins D1 (GPIO5/SCL) and D2 (GPIO4/SDA).
	I removed the power LED on board the ZS-042 module, since one of ~~the~~ reasons ~~to have~~ an RTC is to save current and the power LED wastes current unnecessarily.		I removed the power LED on board the ZS-042 module, since one of my reasons for using an RTC is to save current by keeping the electronics mostly in low-power sleep mode and the power LED wastes current unnecessarily.
			<strike>
	It would be very nice if the RTC could wake up the ESP8266 using the alarm wake-up feature, but I cannot get this to work: the alarm output always seems to be low, keeping the ESP8266 in reset.		It would be very nice if the RTC could wake up the ESP8266 using the alarm wake-up feature, but I cannot get this to work: the alarm output always seems to be low, keeping the ESP8266 in reset.
			</strike>

	Pin D5 (GPIO14) is used to distinguish between run mode and debug mode during reset/wake-up.		Pin D5 (GPIO14) is used to distinguish between run mode and debug mode during reset/wake-up.
Line 76:		Line 79:

	[https://raw.githubusercontent.com/nodemcu/nodemcu-devkit/master/Documents/NODEMCU_DEVKIT_SCH.png NodeMCU schematic]		[https://raw.githubusercontent.com/nodemcu/nodemcu-devkit/master/Documents/NODEMCU_DEVKIT_SCH.png NodeMCU schematic]

			[http://www.wemos.cc/Products/images/d1_mini.pdf Wemos D1 mini schematic]

	Possibly the high power consumption during sleep mode can be fixed like [https://github.com/esp8266/Arduino/issues/719#issuecomment-134392743 discussed here].		Possibly the high power consumption during sleep mode can be fixed like [https://github.com/esp8266/Arduino/issues/719#issuecomment-134392743 discussed here].

	=== Software ===		=== Software ===
	The ~~NodeMCU~~ can be conveniently programmed from the "Arduino" development environment using the [https://github.com/esp8266/Arduino Arduino core for ESP8266 WiFi chip]		The ESP board can be conveniently programmed from the "Arduino" development environment using the [https://github.com/esp8266/Arduino Arduino core for ESP8266 WiFi chip]

	This already comes with a library for WiFi that allows you to scan for WiFi stations		This already comes with a library for WiFi that allows you to scan for WiFi stations

Bertrik Sikken at 16:48, 12 June 2016

2016-06-12T16:48:51Z

← Older revision		Revision as of 16:48, 12 June 2016
Line 11:		Line 11:

	News:		News:
	* 2016-06-12 Figured out how the DS3231 RTC alarm works: the RTC alarm sets an internal alarm flag and makes the RTC SQW pin low, however the SQW pin stays low until the alarm is cleared in software.		* 2016-06-12 The Wemos D1 does indeed draw a lot less power in sleep mode than the NodeMCU does (I measured 0.16 mA, should last about 180 days on a 700 mAh battery)
			* 2016-06-12 Figured out how the DS3231 RTC alarm works: the RTC alarm sets an internal alarm flag and makes the RTC SQW pin low, however the SQW pin stays low until the alarm is cleared in software, this a bit impractical. Perhaps I'll use a capacitor to convert the level based alarm signal into a reset-pulse.
	* 2016-04-25 Measured power consumption of the NodeMCU board. The consumption in deep-sleep is a rather disappointing 3.3 mA (expected something < 1 mA). I might need to go to a different ESP8266 platform than the NodeMCU.		* 2016-04-25 Measured power consumption of the NodeMCU board. The consumption in deep-sleep is a rather disappointing 3.3 mA (expected something < 1 mA). I might need to go to a different ESP8266 platform than the NodeMCU.
	* 2016-04-19 Connected a LiFePO4 battery and made a scan of the trip from RevSpace to Gouda, one point every 20 seconds. Using this kind of battery to power the ESP8266 directly seems to work fine!		* 2016-04-19 Connected a LiFePO4 battery and made a scan of the trip from RevSpace to Gouda, one point every 20 seconds. Using this kind of battery to power the ESP8266 directly seems to work fine!