[UniquePete]

Yes, I have actually set up a GitHub account (see here), I just haven’t managed to get the code over there yet…

As far as running LoRa on the Pi goes, what I have done is described here, with links to the software that I have used. I currently run my Pi configuration in ‘monitoring mode’, i.e. it receives everything that’s being broadcast on my network, but apart from printing out the contents of all the packets in a terminal window, it does little more. I’ve configured Node-RED/Influx/Grafana on the Pi also, but only as a proof of concept at this point.

[UniquePete]

Once again, I’m happy to have been able to help. As you seem to have discovered, documentation on the Heltec products, for example, is pretty scarce. But there are people out there who can help, if you can just work out the right questions to ask… 🤔

[UniquePete]

Note that the HopeRF RFM95W and pre-V3 Heltec modules use the Semtech SX1276 LoRa Node chip while the Heltec V3 modules use the newer Semtech SX1262 LoRa Node chip. Most libraries seem to support the older SX1276, but only a few support the newer SX1262. The Sandeep Mistry (LoRa.h) library, for example, does not include SX1262 support. So check that any library you do use with Heltec V3 modules explicitly notes that it supports the Semtech SX1262 LoRa Node chip.

[UniquePete]

I’ve just run several tests using a Heltec WiFi LoRa 32 V3 receiver, which uses the Heltec Radio library (LoRaWan_APP.h) with both a Heltec WiFi LoRa 32 V2 and ESP32 + HopeRF RFM95W (my A4a LoRa ESP32-WROOM-32 board) senders, which each use the Sandeep Mistry (LoRa.h) library, and they seem fine with Spreading Factors of 7, 8 & 10 (just a sample of the available Spreading Factors).

If you haven’t already, maybe check my page on LoRa configuration for compatibility between the two libraries.

[UniquePete]

I’ve not actually tried to vary the spreading factor. In the early days, there was a problem with the sync word, but that was all that had to be changed so that’s where I left things.

I’ll have a little play around this evening any let you know if I come up with anything.

[UniquePete]

The library contains a lot of junk, and is not very pretty, but send me a message at info[at]digitalconcepts[dot]net[dot]au and I’ll send it to you.

Pete

[UniquePete]

I think I noted in the text that I don’t do any debouncing. I originally had a test setup with a push-button switch that used to bounce like crazy, but when I hooked up the actual [Davis 6410] anemometer I simply couldn’t get it to bounce, no matter what I did. The Davis 6466 rain collector was the same. They both use a reed switch, so I don’t know if that’s just much ‘cleaner’ in its switching, or maybe I’m just blissfully unaware of all the bouncing… But the rain collector is pretty much matching my old analogue gauge that sits right beside it—it’s certainly not over reading—so I figure things must be OK.

And yes, I tested a whole range of solar panels, getting smaller and smaller until I found one (40mA) that couldn’t keep up. The 70mA (5.5V, 0.38W) panel is doing fine at the moment (I currently have similar configurations running with CubeCell, CubeCell Plus, ESP32 and Arduino Pro Mini processors). It’ll be interesting to see how things go through winter, although, where I live, we rarely get more than three or four overcast days in a row at any time of the year and the batteries last much longer than that without a charge.

I also give a little sigh when I see other people’s nicely presented output… I’m not there yet on that front… Soon…

[UniquePete]

I just rediscovered this post. I now have a fully operational Davis 6410 anemometer configuration, using a CubeCell Dev-Board Plus—see here.

[UniquePete]

The part available on this website has now been updated to correct this issue.

[UniquePete]

I’ve posted this query on the Fritzing forum. This will be sure to catch someone who knows what’s going on here.

[UniquePete]

I could probably modify the part OK, although I’ve never produced a part that would generate surface mount pads on both sides of a PCB. But do you really want ‘pads’ on both sides of your PCB? It is a ‘through hole part’, so if you are using header pins (they will go through your PCB OK) you shouldn’t need the pads at all. I included the pads to provide the option to simply solder the part directly to a parent PCB, as I do myself with the TP4056 module.

The FritzingCheckPart script does issue a warning when I run it over this part, telling me that:

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line <nn>

indicating that there are actually two layers, but that I might not want the second layer.

I must confess, however, that I use Fritzing only to produce illustrations for documentation. I’ve never used it to produce a PCB so I don’t really know why the DRC is reporting the error (I’m just guessing why it might be).

If you like, one of us could post a quesiton on the Fritzing forum. I’d be interested to know why the DRC is complaining. If this is a problem with the part, as distinct from the Fritzing DRC, I’d be happy to do whatever needs to be done to the part. I’ve a few others that might need to be modified in a similar way.

• This reply was modified 2 years, 10 months ago by UniquePete.

[UniquePete]

I’m glad to hear that I was able to help. I am still in the process of testing a range of MCUs but the CubeCell is certainly a very nice little unit. I have not been able to match its solar panel/battery management capabilities with anything else I’ve done so far. The immaturity of its supporting software, however, is still a bit of a challenge. But it is improving…

[UniquePete]

Hi Gregg,

As far as the anemometer goes, no, I haven’t hooked one up yet. I have a friend who’s hooked up a similar arrangement to a set of Misol sensors, and that always seemed like the easiest way to go because all of those sensors are readily available. The other one I liked the look of was the Davis unit—a little more expensive, but it seems to have a good reputation.

The weather sensors were actually the last on my list of things to do because there were already stacks of examples out there, so I figured that would be the ‘easy’ part of the exercise.

I have another [open source, but commercial] 8266-based system that currently controls my watering system, so I always figured I’d ultimately use an IOS-based [iPad/iPhone] solution for the monitoring function.

But all of these things take time. At the moment, I’m still sorting out my PCB design. When I have a stable hardware base, I’ll come back to adding the remaining sensors and fixing up the software&mdahs;creating a library for the common function calls so that I can more easily flip between processors, although I agree that the CubeCell is looking pretty good at the moment. The only problem I have there is that I set myself a[n arbitrary] goal, when I began, to build a complete sensor module for under A$25. The CubeSell is really nice, but it costs twice as much as the arduino/RFM95W solution, so I am continuing to work with a range of processors to see if I can come up with a solution that both fits that arbitrary budget of mine and has an acceptable life on a standard Li-Ion battery, with solar panel ‘support’.

[UniquePete]

Sure, see MT3608 Module. I haven’t actually used this part yet, but it loads and seems to check out OK.

[UniquePete]

The NEO-7M module is now also available, see NEO-7M part

[Author]

Posts