In Part-1 of this post I explored my attempt to get a LoRa gateway (RAK Wireless 2247) and end node (Heltec LoRa CubeCell) connected to TheThingsNetwork (TTN). After two days of deep ‘funstration’ , I was about to give up. But ‘Ole Sopwith NEVER gives up. Up, over, or around – this experiment was going to work.
Many Makers at this point would strongly believe they were sold bum hardware. You know the drill, “When in doubt – blame the hardware.” I do not subscribe to this theory. In all my years of Making, I cannot recall the last time I was shipped a Maker device that was DOA. Yes, it happens, but it is very, very, very rare. The QC in modern factories is excellent, and if something does not work out of the box, I blame the hardware last.
My problem was how to tell if the CubeCell connection problem was the CubeCell or the gateway – or both.
I spent a lot of time messing around with the devEui, appEui, and appKey arrays. Lots of documentation and videos suggest if your device does not connect, you should reverse the array entries to account for endian differences in the transport layer.
In fact, the TTN configuration page has a handy reversing capability that makes copying the entries in either order. Changing the endian order did not fix the issue.
As i continued to review the source code of the Heltec SendReceive.ino example app, I saw this code in the Setup() function:
I have recently been researching and doing some Making with LoRa devices. My main interest in this technology is for home automation and remote weather information. LoRa is an ideal solution here for three reasons:
- The devices are relatively cheap, but they have doubled in price in the last year.
- The range of the devices is incredible – miles not feet.
- They are super low-power, meaning a battery can last for months or even years.
The first thing I did was build a LoRaWan gateway. I used a Rak2247 Gateway Concentrator with the matching Pi Hat.
RAK Pi Hat
After mounting the rig atop a Pi3B+, I was able to get the device connected to TheThingsNetwork (TTN) without any trouble. The RAKWireless documentation is very good for this device.
There are a log of Gmail users getting an unexpected surprise from Google if they use their Gmail password in other applications (Outlook, Thunderbird, etc.) These apps no longer work.
This is due to a security change Google is rolling out. Google now requires 2-Step Verification is activated and all ‘less secure’ apps must use an App password instead of a Gmail password.
Despite the surprise, this is a good security practice. I am all for it.
If you have your SkyWeather2 systems’ Email notification service configured with your Gmail password, these emails will be rejected by the Gmail servers. To fix this, you need to configure an App password for your SkyWeather2 system.
Fear not! I wrote up a ‘How-To’ document that walks through the process. It is pretty painless and only takes a few minutes.
You can find the document here.
As noted in previous posts, the latest version of SwitchDoc Labs SkyWeather2 software release (May 7, 2022 – Version 027.6) broke my installation script. The problem involved updates to the MySQL database schemas.
New releases of the SkyWeather2 software are updates. This means there is an assumption that you have a working installation of a previous version. My installation script starts from a clean Pi OS and installs all software and dependencies from scratch.
This has not been a problem historically, but the latest SkyWeather2 update makes changes to the existing database schemas, and assumes the databases exist. To correct this problem, I need to be able to create the databases before running the update scripts.
SwitchDoc Labs support has been terrific in helping me fix this issue. I was provided access to all of the information (e.g detailed database schemas) I needed to get my install script working again.
You can find the latest version of the install script here. It is recommended you install SkyWeather2 software on a Pi running the 32-bit Buster version of Pi OS.
It is interesting to note, my install script runs fine on the 32-bit Bullseye version of Pi OS with legacy camera support enabled. This is not officially supported but those of you that like to live on the edge can hack around and report any issues.
Thanks again to the great folks at SwichDoc Labs for supporting me in getting this issue resolved.
On May 7, 2022, SwitchDocLabs released Version 27.6 of their SkyWeather2 software suite. A few days later, I was notified by a user that my SkyWeather2 install script failed.
pi@skyweather2:~/SDL_Pi_Skyweather2 $ sudo mysql -u root -p < WeatherSenseWireless.sql
ERROR 1046 (3D000) at line 5: No database selected
This error was not caused by my script. It is caused by an error in the SkyWeather2 SQL scripts.
A couple of years ago, I bought a SkyWeather2 system but did not purchase the software SDCard. I was not willing to pay an additional $35 on top of the cost of the system. I soon discovered downloading the SkyWeather2 software on Github and running the main Python script does not work.
Several folks have brought to my attention my SkyWeather2 automated installation script fails to complete. The problem has been corrected and a new version of the script is available here.
The latest script has been tested with SkyWeather2 Version 027.1 and Raspberry PiOS dated October 30, 2021.
In a previous post, I raved about the SwitchDoc Labs SkyWeather2 KickStarter project. When you purchase the kit, there is an option to buy an SD Card with all the required software installed. I passed on it, and cloned the SkyWeather2 software from Github.
To get it all working, I had to sort through all of the dependencies. This took time.
As far as I know, there is no documentation anywhere that describes how to get the SkyWeather2 system up and running from scratch. So – Ol’ Sopwith decided to do something about it.
I created a bash script that installs all of the required application and Python module dependencies. In addition, I wrote a detailed 18 page “How-To” guide.
Hopefully, this makes it easier to get your SkyWeather2 up and running if you choose the DIY route.
Anyone who has ever messed with a Raspberry Pi knows the drill. You download the latest Pi OS release image and burn it to an SD Card. Then you slide the card into the Pi and power it up. The Pi boots, you login with the default credentials, and you run ‘sudo rasp-config’.
You configure your WiFi access point, locale, keyboard, and timezone. You enable SSH, I2C, Camera, and whatever else you need for IO. Next, you run ‘sudo apt update’, ‘sudo apt upgrade’, and reboot. Finally, you log back in and install all your favorite software that is not installed on the base image (p7zip, pip, i2ctools, midnight commander, etc.)
For casual Pi users, this is a one-time or rare task. For experienced Makers who have gone through this drill dozens, if not hundreds of times – it is a real pain. For Makers who write lots of code and/or software installation scripts, this process is beyond irritating.
Greetings smoke-eaters. It has been a while since ol’ Sopwith published a blog post. That is because I have been working hard on another clock project.
For those of you who do not want to read the rest of this post, here is the datasheet.
A while ago, I came across a very cool Thingiverse project by a French Maker comrade named jeje95. He created a replica of the time-circuit in the Delorean filmed in the classic movie Back to the Future. Certainly one of the best movies ever produced, with a near cult-like following to this day.
jeje95 also produced a pretty funny video of his creation, that I highly recommend you watch.
I produced one of these clocks, and as all Makers are obligated to do, I decided to make it better. I ditched the Arduino for a Raspberry Pi Zero, added a much better real-time hardware clock (RTC), and a whole lot more.
Way back in June 2019, I posted an article about the revival of the DOTKLOK project.
I worked hard and made some changes to the design. Unfortunately, I could not find the same LED displays that were used in the original project. The Chinese company SURE no longer makes these displays. I literally hounded them to find me some new-old-stock (NOS) and came up empty.
This means I have to find a different source of LED displays. I did find some alternatives, but they are a different size and use a completely different API specification. To get this to work, I have to redesign the case and rewrite the source code that drives the clock.
I have not given up on the idea, but there is a lot of work here. Stay tuned.