lowpowerlab.com Open in urlscan Pro
143.95.252.252  Public Scan

Form analysis
1 forms found in the DOM

GET https://lowpowerlab.com/

<form method="get" id="searchform" action="https://lowpowerlab.com/">
  <label for="s" class="assistive-text">Search</label>
  <input type="text" class="field" name="s" id="s" placeholder="Search">
  <input type="submit" class="submit" name="submit" id="searchsubmit" value="Search">
</form>

Text Content

MAIN MENU

Skip to primary content
Skip to secondary content
 * Shop
 * Forum
 * Guide
 * Blog
   * RFM69 library intro
   * Wireless programming (OTA) posts
   * DualOptiboot bootloader intro
   * RFM12B library (obsolete)
   * Coin cell battery tests
 * Projects
   * 
   * User Projects
     * Motorized blinds with Moteino
     * Automatic gate control
     * Wireless sensor network
     * Plant Friends Environmental Monitor
     * Moteino Sprinkler Controller
     * Moteino CuPID HAT
     * Model airplane Pylon Judging System
     * Workshop Dust Collector Controller
     * GPS tracker with RF link
     * Joystick controlled gimball
     * Temperature monitor with DS18B20
     * RaspberryPi Media Streamer with ATXRaspi
     * Nin10do game console
     * Autonomous filming of RC moving objects (GPS+Moteino)
     * Compost Sensor Network with GPRS relay
     * Coffee maker automation
     * Cycling Sweeper Bike Detectors
     * Kitchen scale automation
     * More plant automation
   * LowPowerLab Projects
     * IoT Gateway Project
     * MightyHat!
     * ATXRaspi
     * MightyBoost!
     * SwitchMote
     * GarageMote
     * MotionMote
     * Mailbox Mail Notifier
     * SonarMote
     * Sump pump SMS alert
     * Door Bell Monitor/Control
     * PowerShield
     * Water Meter
     * Watt Meter
 * GitHub
 * Videos
 * About
   * About LowPowerLab
   * Safety
   * Contact


POST NAVIGATION

← Older posts



RF RANGE & PERFORMANCE TESTING IN A CONCRETE BUILDING

Posted on December 15, 2021 by Felix
Reply


I needed a quick and easy (and slightly more professional) way to measure RF
performance of the typical RFM69/RFM95 low power transmitters, at a remote
location where a prospect RF sensor network would be installed. Here’s a video
explaining the devices and what’s involved, the rest of the blog has more
details, the code and links you might be interested in.



In the past I ran range and performance tests of RFM69 radios in various types
of applications to gauge how it might perform. I know it does great in
medium/large residential homes with many walls and gateway in a corner of a
concrete basement, while nodes are transmitting from inside and outside the
building 100-200ft away. It also works great in typical industrial buildings
(usually metal) with lots of equipment and obstacles. Of course in practice we
follow some basic RF principles to ensure our small antennas are oriented
decently and signal not degraded by incorrectly crammed or wound inside
enclosures.

At this location we had an unusual multi level heavily reinforced concrete
building. I did not know what to expect – would all the concrete and rebar act
as a faraday cage and totally block signal from an outside sensor to an inside
gateway? Or would performance just be poor?



I assembled a MotionMote – which runs on a CR123A 3V lithium, sipping ~2uA.
These batteries are great for temperature extremes, yielding a stable and
deterministic discharge curve, and they can last for many years on an ultra low
power node such as the MotionMote.

RFGateway is my go to board for setting up a RaspberryPi as an RF gateway. It
plugs straight into a Pi’s USB port and I would normally use an SMA dipole
antenna at the gateway end of such an RF network. The video shows how I soldered
a helical to an SMA male connector to mate it to the RFGateway’s SMA-female
connector.

The RFGateway’s SAMD51 processor clocks at 120mhz, plenty fast for handling
packets from a very large RF network, while doing floating point and other
memory operations. It has a small header convenient for an I2C OLED. Also for
this evaluation I just used a LiPo battery plugged into the power header, only
connected when USB is not plugged in.

Any compatible transceivers can be tested, but for this application RFM69HCW was
used as I prefer it for all my RFM69 based applications.

To run the test I placed the small transmitting node (MotionMote) in a fixed
position and walked away around the property and inside the building in the
areas of interest with the RFGateway which displays the captured packets on the
OLED. The transmitter sends a packet and waits for an ACK back from the
RFGateway, that way we have 2-way communication for each transmission. Every few
transmissions the RFGateway sends a packet to the node and waits for an ACK back
(same as the normal transmissions but backwards).

The sample sketches are posted in the RFM69 library (RangeTest_Gateway &
RangeTest_Transmitter). The video explains in more detail what the packets
contain and how to evaluate the RF performance.

But essentially as signal gets weaker the RSSI will start to drop. The RFM69
library will automatically ramp up transmit power (that X metric) when signal
drops too low.
So as I walk away from the NODE the RSSI will drop and the X will start to
increase at some point. This helps determine any dead spots or areas with weak
signal.

In my test the MotionMote was placed outside about 150ft away, and to my
surprise there were no dead spots in the building either on above floors or
below ground. The signal was weak as expected when I was below grade, but the
RFM69_ATC auto-power was able to ramp up power and still reach the gateway.
Below is one of the weakest signal spots with most grade and obstacles in the
way, with signal still getting through, at the expense of higher transmission
power at the node.

Have you built something similar? Let me know!

Posted in Radio/RF, RFM69, Tools | Leave a reply


RFM69 TX POWER TESTING & LIBRARY FIX

Posted on August 31, 2021 by Felix
Reply

The RFM69 library has been very robust and stable over the years. It is widely
used in many hobby and home automation projects as well as research and
commercial products. But that doesn’t mean we can’t find occasional things to
fix and improve!


IS THERE A PROBLEM?

Recently, after renewed attention to a long time issue relating to power levels
being incorrectly set, I took measurements and found the setPowerLevel()
function was behaving somewhat unexpected. Instead of a smooth  Namely it as
making available the lowest possible transmit power levels on the HW/HCW (aka
high power) variants of RFM69. Since a commit in 2015 the 32 power levels were
actually made into 16 steps and only using PA1+PA2 in high power mode. Not so
much a loss except for those hoping to maximize battery life by running at the
lowest power levels on the HCW – in which case they’d be better off using the CW
instead. But this is enough to find a fix and take full benefit anyway of what
the HCW has to offer.


BASIC TX POWER TESTING

To produce power profile I put together a set of Transmitter and Receiver
examples. To measure power output you can just use the transmitter sketch – it
toggles TX mode and you can navigate the power levels from min to max. Below is
a simple hardware test setup that can be used to take some power measurements: a
CurrentRanger reads the current going into a Moteino+RFM69HCW that radiates an
unmodulated carrier signal into a dipole. Idle MCU current (TX off) is read and
then subtracted from total current with TX enabled:



To also measure RSSI (poor man’s power meter) we can just use another Moteino
with the receiver sketch mentioned above, which will simply sample RSSI
continuously (in RX mode), at a max AGC setting of -48dB to simulate a long
“distance” since we’re doing all this in close proximity (the same room!). Open
the transmitter sketch in a serial terminal and toggle TX mode with t and
increase power with + & - in steps or < & > in dB – there is a new function
setPowerDBm() in RFM69 library v1.5.0, in addition to setPowerLevel(). The
CurrentRanger will show the current drained by the Moteino when transmitting at
different levels and the RSSI on the receiver will also reflect different output
power levels.

This setup produced the following power profile on the W/CW radio, nothing
unexpected since there’s only PA0 to be used with no other registers to set,
power levels being set in RegPaLevel.OutputPower. The only thing to notice is
the ‘step’ in TX current and RSSI which indicates something’s definitely being
switched inside the transceiver itself as _powerLevel crosses the middle of the
RegPaLevel.OutputPower register, even if PA settings remain unchanged (only PA0
is used).

On the HW/HCW, in v1.4.3 (prior to the fix this blog is about) the power profile
looked like this:



As it turns out the startup power is correctly set to a valid level 31, but
calling setPowerLevel() even once results in values being set from 0-16 (all
“forbidden” – see tables below) and never back to the original 31. This results
in a ‘step ladder’ of transmit power levels vs. current. I know this sounds
confusing, because it is.


THE THEORY – DATASHEETS AND REGISTERS

To better understand what’s really going on, first we need to clear some
confusion and understand that RFM69 radios have several possible transmitter PA
(power amplifier) combinations for different output power profiles as outlined
in the datasheet:



For W/CW radios things are very simple – only PA0 is wired to RFIO output pin
and it can produce from -18 to 13dBm, corresponding to 32 possible power levels
that can be set in RegPaLevel, as clearly reflected in the W/CW graph above.

For RFM69 HW/HCW radios things get more complicated, there are two possible PAs 
and a power boost mode to be enabled to reach the highest output of 18 to 20dBm,
according to section 3.3.7:



I know of only one other good article that outlines all this in detail, a blog
by Andre Hessling, I found it accurate and so my focus is not to replicate that
here, but rather use it as reference and complement for those wanting to get a
full picture, so check it out if you want to get more in depth.

So!  The RFM69 library v1.4.3 and prior, has been only using PA1+PA1 in boost
mode, at power levels 0-16, except at startup where _powerLevel was initialized
and set to 31 and never divided by 2 like in setPowerLevel() – bug!.  In
addition, the datasheet says levels below 16 are off limits for the PA1+PA2
combination, but because this works it went unnoticed for a long time, at least
in my library (semi bug?). If you’ve read Andre’s article, you will notice PA1
alone can be used and he proposes using the following PA combinations for HCW:

 * PA1 (and PA1 only!) from -2 to 13 dBm output
 * PA1+PA2 from 14 to 17dBm output
 * PA1+PA1+HighPower for 18 to 20dBm

If we revisit the datasheet, we realize there is actually a power profile
overlap between these 3 combinations:



Notice for instance we can achieve -13dBm in 3 different ways on the HW/HCW:

 * using PA1 only with RegPaLevel.OutputPower=31
 * using PA1+PA2 with RegPaLevel.OutputPower=27
 * using PA1+PA2 with RegPaLevel.OutputPower=24


ENOUGH ALREADY, WHAT’S THE CONCLUSION?

Since theoretically the output is the same, it would be interesting to see the
current profile against each of these as well. To cut this (really) short, I
will link the spreadsheet with my tests and graphs and just mention the final
conclusions. It matters which PA combination you pick, as a general rule, using
more than one PA will result in higher current for the same effective
transmitted output, at first this seemed counter intuitive but that’s what the
meter and RSSI shows. I determined the best combination for HW/HCW to be the
following:



If you notice, there are now only 24 _powerLevel‘s with slight overlaps between
steps 14,15 and 16,17. The light orange band PA1+PA2 combination is sandwiched
between PA1 and PA1+PA2+HighPower and helps optimize current used at those
theoretical dBm outputs. This is similar but a little different than Andre’s
proposed bands – I suspect he may have looked at RSSI but not at current used.
Overall this produced the smoothest output power vs. RSSI vs. current curves
that I could determine – with minimal ‘step’ jumps on the current and RSSI, and
this is what we’d expect to properly use the power levels, especially in the
RFM69_ATC extension which automatically regulates the power level based on a
desired RSSI. And here are the measurements in a graph:



For the W/CW nothing really changes since there was no real issue, the graph
will be the same as the first one included in this article.


UPDATE THE LIBRARY AND TEST ON YOUR OWN!

I made a new release v.1.5.0 which should address all these issues and includes
the TX power testing examples which can be used by anyone with perhaps
different/better test setups to verify these findings. Please update  and try
this out. I may update this blog with further info if need be in the future
since it’s more of a reference for RFM69 PA modes.

Posted in Code/Library, RFM69, Updates | Leave a reply


CURRENTRANGER UPDATES

Posted on September 19, 2020 by Felix

Thanks to MGX3D there are now some nice improvements to the CurrentRanger:

 * Firmware updates and optimizations, battery icon instead of text (faster
   drawing)
 * Improved sampling speed
 * Smarter Auto-Off – avoids turning off when sampling via USB
 * more menu items and options
 * Fusion360 models now available, see this page for links



There is also a new improved OLED enclosure model designed by MGX3D as well.
This is also available to pick up in the webshop or you can print your own –
models available here and here.



There is now also a python based graphic visualization GUI designed by MGX3D and
available here on Github, check out its features and specs on Github, mainly it
brings the ability to view serial data from the CR in logarithmic scale and also
in autoranging mode, w00t! Here’s a preview of that GUI available for
Windows/Linux (and MacOS planned):




A WORD ON USING THE CURRENTRANGER

It seems some folks are too excited to try it out and miss reading some of the
guidelines on proper usage, this is really important not to overlook. I have
seen a few strange cases of abused units that were returned. It turns out it’s
never a DOA condition or anything related to a real fault. All units are tested,
calibrated, turned ON/OFF etc, to ensure they are functional. Faults are usually
a case of improper use, improper soldering or attaching of headers and terminals
which cause damage to SMD components, the OLED, etc. Here’s an example of how to
not solder the OLED header, or at least not how to leave the board after a
solder job, this will cause all kinds of problems (corrosion, possible leaks and
faults on the board):



 

Finally, I would like to express my gratitude for the feedback and positive
response and interest into CurrentRanger. When used properly with love and care,
it is an amazingly versatile and ultra-portable tool that will work for many
years without any trouble. There are plans to make it even better and
constructive feedback is always welcome and encouraged. Don’t forget that
WELECTRON Germany is now our official distributor in Europe and carries the
CurrentRanger as well as many other products.

Posted in CurrentRanger, Updates


DDM NOVASTAR L-BF-12 FEEDER UPGRADE

Posted on June 23, 2020 by Felix
10

Over the past year or so I spent a lot of time designing and iterating over a
new upgrade for my pick & place. The result is an upgrade kit that can be
installed without modifying the original feeder. It enables the bank feeders in
my DDM Novastar LE40-V to no longer have to peel back the cover tapes. That
alone is a huge benefit. Watch this video of this upgrade in action, and see
what other benefits this new concept brings to the L-BF-12 bank feeder.


Posted in New products, pick and place | 10 Replies


MOTEINOM0 R2 RELEASED

Posted on June 12, 2020 by Felix

MoteinoM0 is now at revision R2. Here’s a summary of changes:

 * removed castellations for the short side header, to allow better panelization
   and better routed side finish on the long sides. The castellations remain on
   the long sides.
 * the micro USB connector is slightly recessed, the front being about flush
   with the board edge
 * changed top silkscreen “VUSB” header pin to “Vin”
 * “Serial” changed to “Serial0” which corresponds to the board definition
   Serial0. Note: the main Serial is the USB serial and SerialUSB has been
   deprecated.
 * added “VBat” header hole on the upper header, next to “Vin”, this was a
   popular demand to allow connecting a battery through a header or feed the JST
   connected battery to external devices. More details in this forum thread.
 * minor other layout optimizations and trace thickness adjustments

Available now in the shop. Note that MoteinoM0 along with other Moteinos and
boards are now also available from Welectron Germany, check it out if you’re in
the EU, it’s a good time to shop from there rather than wait for months for the
crippled regular mail service.



Posted in Moteino, MoteinoM0, Updates


NEW OTA GUI V2.0 RELEASED

Posted on June 5, 2020 by Felix
2

If you’ve been using Wirelessly Programming, a unique feature that comes with
all Moteinos, you will love this new update to the OTA GUI. The main requirement
for this release was the ability to change the Programmer Moteino settings right
from the GUI without reprogramming through the Arduino IDE. Here is the summary
of changes:

 * A few UI changes and improvements and a new settings section:



 * support for on-the-fly change of Programmer RF
   settings: networkID, nodeID, frequency (in Hz), EncryptionKey (either blank
   for no encryption, or 16-character key), BitRate (either default or 300KBPS).
   Existing RF Settings can also be read from the OTA Programmer.
   Note: for the settings feature to work, the latest OTA Programmer sketch is
   required
 * UI no longer locks during transfer!  The GUI window can be moved/minimized,
   log can be cleared at any time
 * ability to CANCEL a transfer
   
 * ability to refresh the COM ports dropdown
 * updated instructions
 * backward compatible with older programmer/target code
 * various bugs fixes and improvements

When you change settings on the Programmer, for the OTA transfer to work, those
same settings need to match on the Target (sample starter Target code here), or
the target has no way to intercept any packets from the Programmer.

If you’d like to change the RF settings on the Target, then first compile the
sketch with the new settings into a HEX file, transfer it as you’d normally do,
then change the settings on the Programmer via this new GUI, and you’re ready to
do more OTA transfers once settings match.

The ability to change to 300KBPS instantly is very useful. That makes transfers
significantly faster:

As always, if you run into any issues, have suggestions or bugs to report,
please don’t hesitate reach out or start a discussion in the forum.

Happy Moteino OTA-ing!

Posted in Moteino, Updates, Wireless programming | 2 Replies


MOTEINOMEGA BASED DATA LOGGER

Posted on May 19, 2020 by Felix

Ed Mallon runs the Cave Pearl Project which is all about “developing a data
logging platform from inexpensive pre-made breakout boards, and are using this
at the heart of new environmental sensors that anyone can build.” Ed is also a
contributor in the forum, and has posted a great in-depth tutorial that steps
through making a submersible data logger. From the blog’s own summary:

> In this tutorial, a logger is built using a 3.3v Moteino MEGA with a 1284p CPU
> @ 16Mhz, w 4K eeprom,16K SRAM for variables & 128K program space. Considerably
> more than the 328’s 1K eeprom, 2K ram & 32K progmem. Also has a spare serial
> port for GPS/NEMA sensors.

MoteinoMEGA based Cave Pearl in ‘Prototyping Trim’ with I2C OLED screen &
ADS1115 ADC. INT1 & Aref jumpered. The built also includes an RTC backed up by a
coin cell.

 

It’s great to see Moteinos being put to serious work in such interesting and
niche projects. While a custom PCB could be built to reduce the amount of wiring
and make for a more compact logger/breakout solution, this tutorial is targeted
and perfect for those who want to learn the skill of building data loggers or
similar projects using off the shelf components. Thanks Ed and the Cave Pearl
Project!

Posted in DIY, MoteinoMEGA, User projects


GATEWAY V9.1 RELEASE

Posted on April 19, 2020 by Felix
6

The Pi Gateway software package is continuing to be improved and the latest
release is v9.1.0 (see GitHub releases). It contains some breaking changes, new
features, and bug fixes. This blog entry serves as a feature review, change log
and update guide.


BREAKING & POTENTIALLY BREAKING CHANGES

 * the NGINX site configuration file is now renamed to gateway instead of
   default and so are the references to its log files (gateway.access.log and
   gateway.error.log located in /var/log/nxinx)
 * settings: there is a new interface section that contains a new responsive
   setting. The uiTitle setting is moved to this section. See below for
   responsive details.
 * metrics completely reorganized as detailed below


METRICS MODULES RESTRUCTURED

The metrics.js file is now renamed to core.js and moved into a new metrics
folder. Also, all the prior default mote definitions are removed from this file
and broken into individual metrics files that contain all the functionality
pertaining to that particular mote. They are now called metric modules. You will
see a new metrics/_LowPowerLab folder containing all these default metrics
modules which used to be all bundled in the former metrics.js file. The
userMetrics folder is removed and any examples or other sample metrics modules
are moved under the new metrics folder.


METRICS MODULES LOADING ORDER

In addition to the metrics reorganization into modules, the main app will load
everything in the metrics folder in a specific order as follows:

 * core.js module first – required
 * any other metrics module files in the metrics folder in alphabetical order
   (case insensitive)
 * any metric modules in metrics/subfolders (1 level deep only) in alphabetical
   order (both folder and file order – case insensitive)


GLOBALIZED METRIC MODULES FUNCTIONS & VARIABLES

Given the powerful modularity of nodeJS, we can share functions and (string,
numeric) variables between metric modules. To define a global variable or
function you simply have to define it with the exports prefix, example from
core.js:

exports.ONEDAY = 86400000;

exports.isNumeric =  function(n) {
  return !isNaN(parseFloat(n)) && isFinite(n); //http://stackoverflow.com/questions/18082/validate-decimal-numbers-in-javascript-isnumeric/1830844#1830844
}Copy

So now ONEDAY and isNumeric() can be called across the entire application,
anywhere. If you wish to make a function local (available only to that metric
module) then omit the exports prefix – examples can be seen in the
RadioThermostat_CT50.js  module.

Here is a sample of how the app loading the metric modules, along with their
globalized members.

The loading order affects overriding of any definitions/variables/functions
defined with the same names.

[04-16-20 09:39:31.274] [INFO]   *********************************************************************
[04-16-20 09:39:31.293] [INFO]   ************************* GATEWAY APP START *************************
[04-16-20 09:39:31.296] [INFO]   *********************************************************************
[04-16-20 09:39:31.302] [INFO]   LOADING METRICS MODULE [./metrics/core.js]
[04-16-20 09:39:31.307] [LOG]    |- GLOBALIZING ONEDAY
[04-16-20 09:39:31.308] [LOG]    |- GLOBALIZING isNumeric()
[04-16-20 09:39:31.309] [LOG]    |- GLOBALIZING isValidIP()
[04-16-20 09:39:31.310] [LOG]    |- GLOBALIZING isValidNodeId()
[04-16-20 09:39:31.311] [LOG]    |- GLOBALIZING determineValue()
[04-16-20 09:39:31.312] [LOG]    |- GLOBALIZING determineGraphValue()
[04-16-20 09:39:31.313] [LOG]    |- GLOBALIZING timeoutOffset()
[04-16-20 09:39:31.313] [LOG]    |- GLOBALIZING millisToFutureDate()
[04-16-20 09:39:31.314] [LOG]    |- GLOBALIZING nextSunriseOrSunset()
[04-16-20 09:39:31.330] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/doorbellmote.js]
[04-16-20 09:39:31.340] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/garagemote.js]
[04-16-20 09:39:31.351] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/motionmote.js]
[04-16-20 09:39:31.363] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/RadioThermostat_CT50.js]
[04-16-20 09:39:31.386] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/sonarmote.js]
[04-16-20 09:39:31.396] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/sprinklers.js]
[04-16-20 09:39:31.412] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/switchmote.js]
[04-16-20 09:39:31.446] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/watermeter.js]
[04-16-20 09:39:31.455] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/_LowPowerLab/weathershield.js]
[04-16-20 09:39:31.466] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/examples/_example.js]
[04-16-20 09:39:31.478] [LOG]    |- GLOBALIZING ONEDAYHOURS
[04-16-20 09:39:31.478] [LOG]    |- GLOBALIZING ONEDAY (WARNING:OVERRIDING PREVIOUS VALUE!)
[04-16-20 09:39:31.479] [LOG]    |- GLOBALIZING secondsInOneDay()
[04-16-20 09:39:31.483] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/examples/_garage-auto-close.js]
[04-16-20 09:39:31.492] [INFO]   LOADING METRICS MODULE [/home/pi/gateway/metrics/examples/_InternetSpeedTest.js]Copy

Given these major changes, you should rewrite/break any custom metrics in their
own definition files following the patterns shown in the default LowPowerLab
metrics.


UI CHANGES


NEW MENU BUTTONS & APP INFO

You can now do a Pi reboot and shutdown straight from the app menu. There is a
bunch of additional information shown – versioning, RF gateway information such
as frequency and uptime (if available). The main page node list header is
removed, and the Show Hidden button now shows how many nodes are hidden in that
list (the button toggles their visibility as before).




METRIC PINNING AFFECTS ORDER ON DASHBOARD

As requested in this forum thread, the metrics will appear in the node bubble in
the order they were pinned. If you unpin+pin a metric, it will become the first
in the node’s info bubble.


RESPONSIVE UI

The new interface.responsive setting (boolean) determines if the UI becomes a
responsive grid when it is viewed on large screens (thresholds are 768px,
1020px).




LOG/TERMINAL & DEBUG MESSAGES

A few significant changes happened on the terminal page to make this UI more
useful and readable:

 * there is a new “Simulation” set of fields that allows simulating a node
   message just as if it came from the actual node (through the RF gateway’s
   serial port)
 * the terminal button is removed on the terminal and settings page – the
   terminal input fields are now always visible
 * instead of serialized JSON, serial messages from the RF gateway are now
   pasted in plain text and prepended with the serial port’s name
 * simulated serial messages (such as from this UI or from non-RF nodes like the
   CT50-Thermostat), the logs are marked as such with (simulated)
 * pressing ENTER in these fields will trigger the Send or Simulate
 * if you want to log debug messages from your RF gateway in this UI, you can
   simply prefix those messages with DEBUG: and all such messages are sent to
   all client UI terminal logs as well as in the permanent
   ~/gateway/logs/gateway.sys.log file (metric matching is skipped on these
   special DEBUG:something to log  messages). There is also a
   debug:heyNodeLogThisValue metric (in core.js among other special metrics)
   which allows you to send a debugging value from an end node, this is treated
   just like any other metric and is stored along with the other node’s metrics.
 * some special gateway requests can be made to the RF gateway (if it is coded
   to respond to them like the new PiGateway and MightyHat examples): BEEP,
   UPTIME, SYSFREQ, FREERAM, ENCRYPTIONKEY




NODE REQUESTS

A new experimental feature allowing you to send pending requests to nodes is
available. This is a key:value pair that can be sent to a node to ask it to do
something – like change a variable like transmission period, change behavior
etc. There is a new button [+REQUEST] on the node details page. You can queue
requests and the gateway will send them back to nodes in ACKs as they contact
the gateway. This feature will require the new PiGateway or MightyHat examples
which were updated and also improved with serial buffering. Your node then needs
the ability to process all such requests and ACK them back to the RF gateway
which in turn will ACK them to the app itself and mark that request as complete.
Node requests can also fail, expire, be edited (ie updated with some new value),
and repeated.

There are some special commands that the new sketches will process WRT the new
node requests feature. You can see the request queue by typing REQUESTQUEUE in
the terminal, the new sketches will respond with their content (or VOID if
empty). You may also do things like manually VOID a certain request to a certain
node (ex. 123:VOID:REQUEST), or void all requests to that node (ex. 123:VOID).


MISCELLANEOUS OTHER CHANGES

 * license is now CC-BY-NC-SA-4.0
 * latest NGINX, PHP7, nodeJS/npm packages, along with app node modules updated
 * settings page Save and Cancel buttons removed – changes are now applied upon
   leaving the settings page
 * graphs show 1 day of graph data (vs. 8 hours previously)
 * changing the serial port baud setting automatically switches the port to the
   new baud without the need of restarting the application
 * npm-request replaced with native node http module – this is to handle any
   http requests (like for the CT50 Thermostat)
 * Fail2ban optionally installed during setup. There is a guide page that goes
   into some detail about adding this post install or on prior versions.
 * various setup script fixes & updates as well as:
   * ability to install last stable version or latest unreleased code
   * added symlinks to webserver access/error logs in the ~/gateway/logs
     directory
 * new default icons are generated at 300px to make them look better on the
   larger responsive grid, the icons_template.cdr is also updated
 * dashboard MENU button hidden if there is no socket connection
 * dropped PiBakery


UPDATING FROM AN OLDER VERSION

Before you plan to try the upgrade make sure to:

 * copy-backup existing database, settings, any uploaded images and metrics
   files
 * backup your entire existing SD card

While it’s possible to do an in-place update, the changes are so extensive that
it will take a long time to document everything and every file/script/permission
that changed, and it’s very likely I or you will miss something. I recommend
doing a clean install, on a new (good time to upgrade to a newer faster) SD
card, then copy your old data. To do this, follow the setup guide on this page.
Once everything is running and you see the gateway app run, you will need to
sudo systemctl stop gateway to stop the app from running. Then copy over all
your data files, images, merge old settings into the new settings.json5 file,
and add any custom metrics you may have had into the new metrics folder – ensure
they are formatted after the same pattern of other default files.

Posted in Home automation, IoT Gateway, Updates | 6 Replies


CURRENT RANGER R3MK4 – NEW FIRMWARE & OPTIMIZATIONS

Posted on March 20, 2020 by Felix
3

The CurrentRanger continues to be improved especially on the firmware side, and
in some hardware aspects as well. This blog is to summarize the most important
changes and bug fixes with this new release:

 * UF2 bootloader – allows easy backing up of existing firmware and swapping
   with new firmware via a simple drag-drop action (like copying to/from a flash
   drive). More details and links to new firmware are given in the guide
   firmware page.
 * faster boot time!
 * faster ADC sampling (for auto-ranging and for USB/serial logging)
 * more linear and improved resolution ADC readings with secondary mid-range ADC
   reference (when this reference is active a ½ symbol is shown in the upper
   left corner. This reference is automatically switched for upper-range
   readings or when switching ranges
 * calibration information no longer printed on the product label, instead it is
   briefly displayed on the OLED after power-on and also output on the USB
   serial port. Unfortunately the EEPROM in the SAMD21 is not persistent between
   firmware updates, and hence you should always save this calibration
   information in case you plan to update the firmware.
 * Auto-off warning is now blinked on the OLED in addition to the buzzer sound.
   Also, the Auto-Off function timer is reset either by manual touching any
   pads, or by range switched when auto-ranging is enabled (previously reset
   only by manual touch of any pad)
 * There is now a set of commands available through the USB serial port. This
   allows to easily change parameters such as the calibration values, toggle
   logging via USB, toggle Auto-Off function. You could basically add more
   commands if you customize the firmware. Here are the defaults and examples of
   executed commands and their output:
 * Some limited number of CR3mk4 units have shipped with firmware that will
   always show 4.95Vbat. Use the latest firmware to correct that.
 * Better 3D printed enclosures – thanks to a brand new Prusa MK3S printer
 * Silkscreen changes: The previous “Load-” label at the input black terminal
   changed to “DUT+” to make it more obvious that this is not a “negative”
   terminal but is the positive side of the DUT. See header photo.

There are 2 essential calibration parameters: gain and LDO voltage. The LDO
voltage can always be measured on any GND and 3V exposed headers. The gain has
to be adjusted either with the recommended value or during measurement of a
known accurate load (ex: apply the a fixed load and increase/decrease gain until
the OLED reading reflects the given load). Note that the LDO voltage can
slightly change based on factors such as temperature, load (ex: with/without
OLED), whether charging is taking place, battery voltage. Each LDO is unique,
has its own output voltage and will respond differently. If the LDO voltage
swings a lot then you might need to adjust the values before a measurement to
obtain the most accurate OLED/logged ADC readings.


A FEW CONTINUED CHALLENGES IN MANUFACTURING…

Some components like the thumb terminal (Phoenix Contact, made in Slovakia) and
banana terminals (chinese) have long lead times. Right now the thumb terminal
was on backorder for a month from Mouser and they just updated the lead time to
an additional month. A simple component can disrupt the supply chain,  thanks to
the chinese virus putting a pause to everything.

As you might have noted, PCBs and components have been hard and slow to source
due to the world apocalypse we’re living through. It takes much longer to
manufacture PCBs with all the pledges from the chinese makers that everything is
back to “full production”.

One of the most painfully inconsistent features of chinese PCBs is the
silkscreen, like most other things chinese it sucks. Look at OSHPark silkscreen,
next to a chinese made PCB, any. There is no measure of comparison (and not just
silkscreen). With the large graphic features on the front side of the PCB, any
silkscreen quality glitches become obvious. Thankfully functionality is not
affected by silkscreen, and unfortunately the magnitudes in cost difference
forces PCB manufacturing to be done mostly in china. I doubt anyone else would
pay $5 extra for perfect silkscreen, I certainly would only because I am quite
OCD about things I use and look at on a regular basis.

The power button is hand soldered to each unit, and liquid flux is used in the
process. Flux residue is removed with flux cleaner. Sometimes traces of
dissolved flux may be  absorbed inside the button. At first, while this
dissolved flux is still liquid, this is not a problem and the button works fine.
When the flux solidifies, it can act as a film on the button internal dome,
causing intermittent contact or in rare cases an apparent complete loss of
contact. The most effective fix is to add a drop of flux cleaner or IPA to the
button, press the button multiple times, in an effort to dissolve and loosen up
any flux traces inside the button, and also absorb this solution back with a
q-tip.

That’s it for now, any other minor changes will be documented in the CR guide.

Posted in CurrentRanger, Updates | 3 Replies


MIGHTYHAT R4

Posted on March 6, 2020 by Felix

I ran out of MightyHat stocks a few months ago and was debating whether it is
time for a complete remake with a SAMD chip. While that feature set slowly baked
in and out of my brain people kept bugging me to make more. Ok, it’s finally
back in stock and basically a miracle I even managed to get PCBs delivered after
several weeks of delays.

Although functionally and firmware wise R4 works the same as the previous
revision, I made some changes, the most noticeable:

 * circuit layout optimizations especially for power distribution and the
   booster
 * removed dual HCW/HW radio layout, only HCW is now supported
 * charger is set for 500mA



The R4 schematic is in the MightyHat guide. Sorry but I will not stock any more
Nokia5110 LCDs, too many quality issues to worth the hassle. You can find them
cheap on the web if you’d like one on your MightyHat. A future revision will
support OLEDs or some other nicer screens. There are actually Nokia5110 pin
equivalent TFTs if you look around you might find some. Also, the SD1306 OLEDs
can also be found in SPI variants so you could use those instead of the
Nokia5110 with the MightyHat R4.

PS. Dear corona virus, maybe US made PCBs and affordable don’t go in the same
sentence but, wouldn’t it be a great time for someone to come up with a US based
PCB service that is high quality to compete with china’s hits and misses? Or
maybe since you’re made in china you won’t last long anyway and the question
will be forgotten once again. Oh well!

Posted in MightyHat


POST NAVIGATION

← Older posts

Search



CATEGORIES

 * 3d Printer Tools
 * 3D Printing
 * Arduino
 * ATXRaspi
 * Code/Library
 * CurrentRanger
 * DIY
 * DoorBellMote
 * EagleCAD
 * Etching
 * From china: with love
 * Home automation
 * Home Improvement
 * IoT Gateway
 * Laser Cutter
 * Manufacturing
 * MightyBoost
 * MightyHat
 * Moteino
 * MoteinoM0
 * MoteinoMEGA
 * New products
 * pick and place
 * Python
 * Radio/RF
 * RaspberryPi
 * RFM12B
 * RFM69
 * SMD stencils
 * Solder paste
 * SonarMote
 * SwitchMote
 * Teardown
 * Tools
 * Uncategorized
 * Updates
 * User projects
 * WeatherShield
 * Wireless programming


TAGS

 * Arduino
 * atxraspi
 * CNC
 * DIY
 * FTDI
 * GarageMote
 * home automation
 * HTTPS
 * Kill-A-Watt
 * Library/Code
 * lithium batteries
 * mailbox
 * mailbox notifier
 * Moteino
 * MoteinoLeo
 * Moteino Power Shield
 * OSHPark
 * PCB makers
 * PowerShield
 * python
 * RaspberryPi
 * reflow
 * RFM12B
 * RFM69HW
 * RFM69W
 * rolling code
 * smart meters
 * SMD
 * solder paste
 * Sprinklers
 * SSL
 * stencil
 * SwitchMote
 * teardown
 * temperature monitor
 * The Hackaday Prize
 * tornado
 * Tweet-A-Watt
 * Upgrade
 * WattMote
 * WeatherShield
 * websockets
 * Wireless
 * wireless programming
 * wireless security


ARCHIVES

Archives Select Month December 2021 August 2021 September 2020 June 2020 May
2020 April 2020 March 2020 May 2019 December 2018 November 2018 September 2018
July 2018 June 2018 May 2018 April 2018 March 2018 October 2017 September 2017
August 2017 July 2017 May 2017 April 2017 January 2017 December 2016 November
2016 September 2016 August 2016 July 2016 May 2016 March 2016 February 2016
January 2016 December 2015 November 2015 October 2015 September 2015 August 2015
July 2015 June 2015 May 2015 April 2015 March 2015 February 2015 January 2015
December 2014 November 2014 October 2014 September 2014 August 2014 July 2014
June 2014 May 2014 April 2014 March 2014 February 2014 January 2014 December
2013 November 2013 October 2013 September 2013 August 2013 July 2013 June 2013
May 2013 April 2013 March 2013 February 2013 January 2013 December 2012