Project Logs

Collapse

• Captive portal goes live

  AlexanderN • 05/16/2019 at 13:11 • 0 comments

  It was a while since I put the previous project entry. Nevertheless it is better late than never, isn't it?

  ---

  TL;DR

  In order to operate the device using the previous version of the firmware, one needed to connect to the access point IuT_voltemeter (no password required) with their smartphone/tablet/laptop, and entering the IP address of the web server, namely 192.168.4.1, in a web browser. The new revision allows enetering any valid web address , e.g. a.uk. (Please be warned that typing any word will probably not do the trick as the browser will try to ask non-accesible search engine for entries).

  ---

  The starting point for the captive portal was the CaptiveIntraWeb project developed by Andy Reischle 4 years ago. Since then the NodeMCU Lua firmware evolved to the point that this older code did not work at all, and required fixing.

  Fortunately the required amends were not too difficult to debug. The amended firmware makes use of newer net.udpsocket Lua module. There is a sure possibility to take advantage of the net.dns Lua module but I decided to amend a working code rather than try to develop a new one from scratch not to getting too deep into the DNS protocol (I lightly used the following two sources that worked very well for my needs: DNS Query Message Format and DNS Response Message Format).

  It was necessary to amend the Lua code that was placed into the file dns-liar.lua, and call this code from the IuT_00.lua as follows (I put this call at the very end of the file)
  

  dofile("dns-liar1.lua")
  

   In turn, the dns-liar1.lua contained the following code where I left all the acknowledgements
  

  -- dns-liar1.lua
  --Thanks to Thomas Shaddack for optimizations - 20150707 ARe
  dns_ip=wifi.ap.getip()
  local i1,i2,i3,i4=dns_ip:match("(%d+)%.(%d+)%.(%d+)%.(%d+)")
  x00=string.char(0)
  x01=string.char(1)
  -- constants required for a proper DNS reply
  dns_str1=string.char(128)..x00..x00..x01..x00..x01..x00..x00..x00..x00
  dns_str2=x00..x01..x00..x01..string.char(192)..string.char(12)..x00..x01..x00..x01..x00..x00..string.char(3)..x00..x00..string.char(4)
  dns_strIP=string.char(i1)..string.char(i2)..string.char(i3)..string.char(i4)
  --% code in this section was modified to amend the deprecated APIs
  --% see for details https://nodemcu.readthedocs.io/en/master/modules/net/#netudpsocket-module 
  udpSocket=net.createUDPSocket()
  udpSocket:on("receive", function(s, data, port, ip)
      --print(string.format("received '%s' from %s:%d", data, ip, port)) -- DEBUG
      --s:send(port, ip, "echo: " .. data) -- from the docs example replaced below
      decodedns(data)
      s:send(port, ip, dns_tr..dns_str1..dns_q..dns_str2..dns_strIP)    
      collectgarbage("collect")    
  end)
  -------------------------------------
  --old callback code - deprecated
  --svr:on("receive",function(svr,dns_pl)
  --  print(dns_pl)
  --  print(dns_tr..dns_str1..dns_q..dns_str2..dns_strIP)
  --  svr:send(dns_tr..dns_str1..dns_q..dns_str2..dns_strIP)
  --  collectgarbage("collect")
  --end)
  -------------------------------------
  udpSocket:listen(53) -- DNS requests are sent to the gateway IP : 53
  --%
  function decodedns(dns_pl)
    local a=string.len(dns_pl)
    dns_tr = string.sub(dns_pl, 1, 2) -- get the first 2B of the request -> request ID
    local bte=""
    dns_q=""
    local i=13
    local bte2=""
    while bte2 ~= "0" do
      bte = string.byte(dns_pl,i)
      bte2 = string.format("%x", bte )
      dns_q = dns_q .. string.char(bte)
      i=i+1
    end
    --print(string.format("DNS request: '%s' for %s",dns_tr,dns_q)) -- DEBUG
  end
  print("DNS Server is now listening. Free Heap:", node.heap())
  

  .
  

  Bonus youtube link: ESP32 NodeMCU Lua Firmware - Config, build and flash | How to from Alija Bobija

• Function, procedure, interrupt sevice routine, callback function - which is better to use?

  AlexanderN • 07/16/2017 at 11:28 • 0 comments

  Some time ago I came accross the term REST (ReST) and how important it was. I tried reading a lot of articles (starting from Wikipedia and ending with the likes of "How did I explain REST [and some other little things] to my wife") to get the idea. Some of the sources cited a long list of references which included PhD theses, books and internet archives going a few years back. Unfortunately I am not a diamond to be around forever and work through these lists. (Most importantly, there is no known diamond of my weight as of yet.) Therefore, when I figured out that, if I folow the table below, I comply with REST/ReST/RESTful/you_name_it

  Action on resource	HTTP	SQL (for comparison)
  Create new	POST	CREATE
  Access existing	GET	SELECT
  Update existing	PUT	UPDATE
  Delete existing	DELETE	DROP

  I have got my rest despite some people would rightly say that I missed a lot of important points. This log entry is used to clarify a few points that I think are important before describing recent amendments to the firmware.

  Read more »

• Made for each other: B0505 and Wemos mini

  AlexanderN • 07/07/2017 at 14:00 • 0 comments

  The original intention was to equip the IuT voltemter with a LiPo battery and a battery shield with the view to have an isolated instrument like any digital multimeter (DMM). I found that using the shield with a quite beefy 720 mAh battery lasted for the 4 hours I specified for the design. Unfortunately this combination wasted more power than I could tolerate, and pushed the cost of the instrument up too high to my liking. I decided to look for an alternative solution.

  First I would like to discuss why did I want to have an isolated instrument. I am sure for most breadboard prototyping needs it is perfectly fine to have the voltemeter powered from a power bank or even a mains adaptor. However some measurements (e.g. high side current measurements) do require isolation of the device-under-test (DUT) and IuT voltmeter's grounds. There are some inexpensive isolation DC/DC convereters available, and this log entry describes how the voltmeter performed when it was powered from the B0505 1W converter.

  Read more »

• To pull or not to pull - that is the question

  AlexanderN • 06/19/2017 at 23:15 • 0 comments

  ... which turned to have the following short answer - to pull down with a 680 kOhm resistor. For a detailed answer

  Read more »

• Project tracker

  AlexanderN • 06/17/2017 at 20:51 • 0 comments

  I found out that too many things need to be properly noted even for this well defined little project.

  These are

  - features and options (completed)

  - features and options under development and development alternatives

  - to do later list (essential and non-essential features, options, refinements, cool things)

  - things to revisit if time permits

  - anything else

  Read more »

• Test 2: performance

  AlexanderN • 06/17/2017 at 17:51 • 0 comments

  Some observations and test results

  - protection

  - consistency of measurements

  - operation of the access point

  - dynamically serving the web page

  - operating the design from a single battery charge
  

  - at last but not at least - how did the voltmeter measured voltages

  The outcome - this is a voltmeter that underreports the measured voltages by 6 mV in the worst case at full scale measurement (below 0.5%).

  Read more »

• Functionality test 1: passed

  AlexanderN • 06/09/2017 at 15:35 • 0 comments

  Here is the video of IuT voltmeter serving a tablet with the reload interval of 300 ms

  and the stress test - serving two clients simultaneously

• Firmware 2 & web page : enabling basic functionality

  AlexanderN • 06/08/2017 at 21:08 • 0 comments

  This log is about configuring the ESP for operating as WiFi access point (straightforward), enabling TCP server and programming relevant callback to serve dynamic web pages (learned a few new to me useful things), adding JavaScript code to reload the web page from the server automatically every 300 ms (my first practical use of JavaScript) and adding a script to start all the things on power up (init.lua).

  Read more »

• Hardware - revision 2

  AlexanderN • 06/08/2017 at 20:27 • 0 comments

  This revision was planned to have a trippler baseboard, a mini lite and a battery shield from Wemos, an ADC module (attached to the third base) all soldered to the baseboard in order to reduce the height of the device. However, following the experience with oldered battery shield for the revision 1, I decided to socket all these modules. As it turned out later, this was a wise provision to make.

  Read more »

• Firmware 1: how to stop worrying and reinvent the wheel

  AlexanderN • 06/04/2017 at 20:07 • 0 comments

  I was not afraid of writing driver code for the ADC module, and I did. When I later built the NodeMCU firmware, I found that this driver was already written and available for inclusion. Nevertheless using such a driver would be difficult without reviwing the ADC datasheet, and I did not worry too much for reinvenbting the wheel. Hence the title of this log.

  Read more »

View all 12 project logs