UPDATE: A sample RFM69 sketch for WeatherShield R2 is posted here.
WeatherShield is now at R2 and although the PCB is very similar to R1 there are some significant differences. The R1 used to have a BMP180 until Bosch decided to stop making it. So R2 came about partly because of that reason, and is now shipped with a BME280 which includes all Temperature/Humidity/Pressure readings all in 1 sensor. This sensor is pretty popular it seems so hopefully the supply will be plenty for a long time.
Here’s a look at R2:
And the schematic:
Notice a few changes:
The voltage monitor circuit is now without a mosfet – this was removed and a resistor was added (the angled resistor) to tie the circuit permanently to A7. The old pads are still there so including the mosfet as on R1 is an option if someone really wants it.
there is now a solder jumper to allow disconnecting the battery monitor from A7
The Si7021 pads are still there if you’d like to add that sensor yourself
The board will idle at around 3.5uA when the sensor is put to sleep because of the voltage monitor. That’s still very low power but if you want 100nA instead and don’t care for battery monitoring, cut the jumper to A7. Bring your feedback in the forums!
The MotionMote is now available with optional BME280 sensors and Panasonic PIR ultra low power sensors (the EKMB1201111: 5m 2uA, white). When you opt for the Panasonic PIR you get that instead of the chinese HC-SR501 with the appropriate enclosure front cover and required acrylic standoff. The guide explains how to use the standoff and switch the PIR input voltage from battery to regulated 3.3v from the Moteino:
The MotionMote sample sketch was updated to include BME280 code support, but it’s commented out (will require a 3rd party library to read the sensor). If you get the BME280, make sure to uncomment the BME280 related code lines.
Although expensive, this PIR allows running on less than 10uA of idle current draw. Who thought that less power costs more huh! When assembled these will look like this:
The OLED variant of the kit might be available soon as well, I will update the product page with that option when/if it does. That allows using this kit as a battery operated Moteino with a nifty OLED display for any general purpose use on your wireless IoT network. Here is that at a glance next to the regular HC-SR501 PIR based MotionMote.
I had previously released a MoteinoMEGA with trace antenna, and there is now a regular Moteino with trace antenna. Everything is the same as the MEGA variant, except of course this is the atmega328p based Moteino, the most popular variant. The antenna is tuned to work in the 868-915 bands and should deliver very decent performance, close to the wire monopole. Here it is next to it’s MEGA sister board:
A new revision of MightyHat has started to ship out. Most everything is the same. Here is a rundown of the most significant changes:
the slide switch that cuts off the battery is replaced with a more robust hooded switch that also has a longer slider which can reach out of a 1/8″ thick acrylic case
The RST pin of the LCD is now connected to the RST of the atmega328, (previously wired to A1). This saves the A1 pin and resets the LCD whenever the atmega is reset. This is the only change posted in the RFM69 MightyHat sample sketch and I added a directive setting to make it easy to switch between R2 and R3.
enlarged the slot in front of the battery connector for easier wrapping of the battery wiring
added a capacitor footprint on the 5V* output rail. This makes it easier to add more capacitance to the boosted voltage when needed.
The Wireless Programming GUI app that I introduced in an earlier post is now at version 1.2 (get exe here). It features the ability to bundle up to 3 HEX file lines per RF packet (instead of the default 1), which yields a significant transfer speed increase. Let’s just do the TL;DR first and gaze at the results of transferring a compiled sketch of 13,858 bytes:
running with 1 line per packet (the same as before) yields 866 packets and ~43s OTA time:
running with 3 lines per packet yields 290 packets and ~18s OTA time:
That’s an average 58% speed gain, not too bad! By comparison, the same sketch uploaded directly via FTDI/serial takes about 13s, so much closer to that figure than before. I think a few other techniques could be used to squeeze yet more speed (increasing RF bitrate!) but that’s for another day.
Note that the same exact data is transferred, except in fewer longer packets. I had to make some changes to the WirelessHEX69 library to support these longer packets. Also I fixed some bugs that emerged during this development, see the github commit for all the changes.
To support the new GUI v1.2 speed increase you only need to update your WP programmer Moteino with a new version of the WirelessProgramming_gateway sketch (to refresh the WirelessHEX69 code) to make it support the faster WP speed (ie also update the WirelessHEX69 lib!). Everything else is completely backwards compatible, and you can use the new GUI v1.2 with an older WP programmer Moteino if need be (1 line per packet only), and also all old target nodes that are OTA/WP programmable are not affected at all and can be updated at the new speed. FWIW you can actually use 1 or 2 (not sure why you would) or 3 lines per packet (the new default going forward). Experiment and see what your own speed gains are! Please report any bugs or issues in this forum!
There is a new gateway release, “V8”. The sources are at Github. The download link to the latest image is posted here. It contains several updates and new features, bug fixes etc. Most notably:
there is a new settings page accessible from the main dashboard. This allows you to edit your settings directly from the GUI instead of manually in the settings.json5 file. I also added a button on the settings page that allows restarting the gateway app, for such cases where this is useful (ie some settings require this, like changing the serial port). There is not a lot of validation done on the settings page, so edit these mindfully of that. The assumption is that you are not trying to break your own server. Also some settings are not exposed, so they will not show up in the GUI, and some are not editable – these will show but you are not supposed to change them. if you still need to, you can manually change the settings.json5 file any way you want on disk, but keep the formatting/nesting of the objects since that format is assumed in the new gateway app release. Here’s a peek at the new UI:
I added a new setting called genNodeIfNoMatch (boolean) which can disable new node creation when data is received from a node but no metric is matched to the metrics definition in metrics.js. If you set it to true, a node is added even if no data can be matched to a meaningful metric (node would show in the UI).
some new metrics/events were added/improved
logs generated by the gateway app are now rotated and archived with logrotate in a new logs subdirectory (if you manually upgrade you need to mkdir /home/pi/gateway/logs). To facilitate this there is a new /etc/logrotate.d/gateway config file that controls this feature. This means the log is kept under a size and history limit to avoid it growing indefinitely.
avrdude is now installed on the image so it would support programming MightyHat with a new HEX sketch. Instructions for doing this are on the MightyHat page.
Essentially 4 files have changed: gateway.js, metrics.js, settings.json5, index.html; one file was added: /etc/logrotate.d/gateway. I also posted a MightyHat blueprint DXF case for 1/8″/3mm acrylic (the green areas need to be etched rather than cut).
As always, the image contains pi:raspberry default credentials (change it with passwd) for the main pi login and for the http authentication (make your own .httpasswd file). If you got an ATXRaspi or MightyHat you need to uncomment the line running the shutdowncheck script in /etc/rc.local, to enable power button control. You may also want to create your own secure certificate and setup your wifi. Please let me know if there are any issues or bugs with this release.
Revision R2 of MightyHat is now available. Since the changes are not very significant I debated whether this should be really a R1.1 but I don’t like minor revision numbers so I went with R2. Basically it just adds the following main features:
Battery power switch – this is a slide switch that can cutoff the battery. During my many hours of testing, it occurred it would be useful to just have an onboard battery switch instead of pulling it in and out. Also if you have the battery tucked tight underneath the board it’s not always really easy to pull the JST connector. Or say if you want to ship a complete Pi+MightyHat+Battery inside an enclosure and don’t want to have it powered up. A side switch is convenient for this purpose: If you don’t want the switch then there is a solder jumper behind it which you will need to solder-bridge if you are using a backup battery.
Two momentary tactile buttons tied to the remaining available I2C pins which were previously unused (A4 and A5). These will be general purpose buttons to do whatever you like. If you want you can build some menu interaction for the LCD or whatever else. They connect GND to A4 and A5 and the pins should be declared as INPUT_PULLUP. The provided kit buttons have long actuators that rise just above the main power button (to allow pressing them when enclosed), but you could otherwise solder any standard 6mm tactile buttons here.
A few power path optimizations and tweaks.
I sourced RP-SMA connectors which seem to be a lot more popular than SMA (shown in photo below – note male pin in the center).
Besides the new positions/cutouts of the buttons and switch all other physical features remain at the same positions as R1.
I have an enclosure close to finalizing so maybe I will post that when it’s ready for those who’d like to lasercut their own case. I played around with 1/8″ and 1/16″ acrylic and finally settled on 1/8″ because it’s more dimensionally stable and makes for a sturdier case. The thin 1/16″ was light but it was prone to breaking where holes were very close to the edge or between USB/Ethernet connectors. Here are a few snapshots of R2:
Wondering what it takes to put together a kit with all the necessary parts to make a completely functional piece of hardware like this? Consider these facts:
The PCB board has some 62 SMD parts on it after picking and placing.
Some 13 more through hole parts (and the SMD transceiver) are required to be sourced and soldered separately (some optional like the LCD, buzzer or SMA connector).
To make a nice tight fit while avoiding any shorts or touching ontop of the Pi, an optimal height of 17mm is required between the Pi and MightyHat. Standoff combinations were sourced to achieve this height since 17mm is not standard or easy to find stanoff height.
Add a 1-cell 3.7v Lithium Polymer battery (optional) to act as a UPS and you are golden. I recommend this 2Ah battery from Adafruit which has decent capacity and attaches nicely with velcro under the Hat.
Total height of the Pi+MightyHat with all options installed is just 32mm (about 40mm when enclosed with 1/8″/3mm acrylic).
Finally I need to mention I have made numerous tweaks and improvements to the RFM69 gateway sample sketch for the MightyHat. I added a bunch of defines that make it easy to disable the LCD, wireless programming, or Automatic Transmission Control. Besides making the sketch a lot smaller (LCD has the largest footprint because of fonts and graphics), it allows running your gateway without an LCD:
The Moteino Framework Gateway software stack was updated to V7 and new sources are available at their Github repo, and also a new debian-wheezy image with the changes is released (for the image link see the Gateway image page). This release addresses some bugs and adds some significant refactoring and moving of directories. Most importantly the gateway application is now residing in /home/pi/gateway along with the public www directory for ease and more consistency (previously in /home/pi/moteino). Here are the other changes that go with this:
the www directory is moved from /var/www/default to /home/pi/gateway/www
the .htpasswd file and ssl certificate files are now in /home/pi/gateway/data/secure
the database files and log data are now kept in /home/pi/gateway/data/db
nconf is used to manage the settings file (previously known as settings.js, it was using straight nodejs exports to import the settings) which is now named settings.json5 and is a JSON5 based (via json5 package) settings file which can be manually edited as well as maintained through the app (in a future release)
there is a new package.json file which includes all the node dependencies. If you’re inclined to manually install the software stack, now all you have to do is cd /home/pi/gateway and npm install to get all these dependencies installed