Hardware options

1

At this point, I’m aware of 3 different ESP32 + LoRa mesh projects.

Likely through some unfortunate non-magic of non-coincidence, all three projects have selected different primary development boards.

I do have 2 Pycom LoPy4 boards, and got a mesh going in a couple minites. But that project is kind of outside the scope of my question because they’re more or less developing the software to run on their hardware – ostensibly to sell more of their own hardware.

What I’m wondering is what might be the best medium-term purchase options for those of us wanting to experiment with as many projects as possible. The SX127x chipsets most of the LoRa boards run are already fairly dated (circa 2013?). The new chipsets don’t appear to be in many boards yet. But since the instruction sets are different, there will likely be some compatibility issues at some point.

The new chipsets are in the newer Heltec CubeCell ($11.90 at the time of writing w/o oled or SMA).

I also see that the manufacturer of the Meshtastic supported T-Beam, LilyGo, is officially supporting the disaster.radio hardware on their v2.1 1.6 board (w/o oled)

At this point, the main question in my vague rambling is something along the lines of… what are your future plans for board support? Have you tested the Heltec CubeCell boards?

My other question is whether there is a board that others have successfully tested on disaster.radio and Meshtastic.

An ideal future scenario might be for LilyGo to work with Meshtastic and disaster.rario to release an updated T-Beam based on the newer SX126x chipsets. The LilyGo AliExpress listings advertise that they are open to that kind of partnership.

It’s great that we have several options at this point, but I’d rather buy 4 of the same boards I can use flexibly than a bunch of semi-inter-operable EOL randoms.

5 Likes
2

Alas, this board doesn’t have bluetooth (which is a big deal for this usecase) and no gps. Though the Heltec folks tell me they are working on something and they will send me a note as soon as they can.

re: disaster radio
I’ve been talking with them and we might be sharing our mesh layer work. Their main usecase “disaster” and ours “a useful extendable tool for hikers/skiers/gliders” are slightly different but we both need a mesh library. Also, we’ve focused on “starting with what users can buy right now for $30 what can we make work” as opposed to custom or semi-custom boards.

re: ttgo
yes, they totally might be up for such things and we’ve been talking to them. Alas, they are still totally hammered because of Covid, but should be out of it soon (just in time for we in San Francisco to get hammered :grinning: )

Does that provide some useful context?

5 Likes
3

It’s great that we have several options at this point, but I’d rather buy 4 of the same boards I can use flexibly than a bunch of semi-inter-operable EOL randoms.

Very much this. I have been looking to get involved and I have added boards to my shopping cart on a few occasions, just to leave them sitting there with second thoughts similar to these.

Another project using similar equipment is Project OwL, which has the backing of IBM/Red Hat and has been deployed in places like Puerto Rico as a disaster management network solution to connect first-responders with people on the ground. They use Heltec ESP32 WiFi + LoRa board.

4

On the subject of Project Owl, their “How to Make a Duck” (PDF) document is a really great starting point for people. I’d be willing to help work on something similar for Meshtastic (which is a project that is much closer to my anticipated use-case than the others).

5

I suspect this would run on that heltec board fine.

And porting to new boards is not super painful (def less than a day work) as long as the radio is RF95 compatible. And supporting a completely different radio would probably take someone less than a week.

But at least until 1.0 I (and the current kind folks who have been contributing PRs) have a big enough work queue I want to focus on getting this “useful thing for users right now with no soldering required (including an android and hopefully-soon an ios app)” deliverable done and in the bag. Then after 1.0 (a couple of months from now?) there’s all sorts of cool extensions.

2 Likes
6

Missed that. I could accept no GPS, but yeah, no BT is a non-starter.

Good to hear there’s some collab going. Their disaster bias (and resultant focus on group messaging) is what nudged me toward Pycom originally. I live in an area with no cell coverage when there isn’t a disaster, so the Meshtastic use-case mostly matches my own. Though I probably have a more prescient need for a couple base station relay nodes.

All great to hear, aside from the unfortunate viral impact, of course. Thank you.

7

I had been questioning why they added duck nodes into an owl network, but when I saw the “clusterduck” protocol branding all was forgiven.

2 Likes
8

speaking of getting hammered in San Francisco because of covid: I’m not programming tonight because I just got back from a two hour line at the grocery store and I’m now drinking a beer.

9

I saw in that thread that they’re working on LoPy4 compatibility. That’s interesting news. While lacking GPS, one thing Pycom devices have in their favor is fast delivery from distributors like Mouser.

Respecting the goal of wanting to get v1.0 nailed down, I’m curious whether you’ve looked at openthread.io for the mesh side of things. Since it’s meant to be platform agnostic, I wonder whether implementation of something like that would aid adoption by projects like Signal (since I initially found your project through the Signal forums).

Just thinking out loud.

It was also encouraging to see that beegee-tokyo has done some work on the SX126x end of things.

1 Like
10

Excited about the disaster radio news! I’ve been loosely keeping an eye on that.

I’ve watched other projects in the past like cjdns, but couldn’t afford the recommended kit at the time, and no-one would want to spend that much either around me even if I could, ha.

Working with these boards I could eventually hand out a couple to folks that stay nearby.

2 Likes
11

yes, the cheapness and the “no need to solder, just slap in a battery and go” aspect of these boards I really liked.

12

I’ve been wanting to design a PCB for an ESP32 + LoRa dev module for about a year, but got distracted by other things.

If a dream board was conjured into existence, what features would it have?

I’d consider the following table-stakes:

  • ESP32 (unlike ARM-based Heltec CubeCell which lacks Bluetooth, etc.)
  • SX126x (newest LoRa)
  • On-board battery charging (but which chemistry?)
  • SMA antenna connector
  • Display (OLED?)

Would USB-C, perhaps with QC, be desirable? The reason I ask is that I’m at a high latitude, and sometimes sun is available in short bursts rather than sustained exposure. When I lived near the equator, many days were mostly cloudy with short bursts of sun as well. One limitation with most USB-based charging circuits is that they aren’t capable of harvesting a lot of sun if it’s available in short bursts. I live completely off the power grid, and it’s not uncommon to have 2 weeks of cloud-diffused sunlight. It seems to be very common for BOE solar/battery calculations to fall apart in reality if up-time is a priority.

Granted, my use-case also includes “normal” use which would be charging the device by plugging it in, then roaming around for a few days. But the network becomes significantly more useful if some users also had base nodes (e.g., at remote cabins) which would be a permanent part of the mesh.

So as I’m composing this it becomes apparent that perhaps that custom charging functionality could be offloaded to a separate component. Then there could be one board which acts as a normal mesh node or a base mesh node, but with a different power/battery/charging module.

In any case, that’s just one example of possibilities to perhaps get the ball rolling.

1 Like
13

I’m new here, but IMHO, I’d love to see one board that’s suitable for both a pocket-portable enclosure and a mountable base-station/repeater sort of thing.

For the pocket, the edges will likely want to be rounded, and antenna placement somewhat limited. It might be desirable to integrate the 915MHz antenna into the case design, and mate it to the board via u.FL or something. (Look at the old Ricochet modems!) Also in this use, I think most users would be content with a low-gain PIFA or something on the 2400MHz, since their bluetooth link will never be more than a few feet.

For the base-station, I think SMA is indicated for everything. (And in the case where there’s plenty of power available, I suspect wifi functionality may emerge in a future build, so 2400MHz antennas may be of interest.) And there’s no display needed in this use, though they’re cheap enough it might be sensible to have one for initial config anyway. Or, provide a 4-pin header for the ubiquitous OLED modules?

It’s easy enough to dual-footprint a u.FL with an end-launch SMA, and then pick your use case when you populate the board. Place a cap in one location to bridge the radio to the connector, or place it differently to bridge the radio to the PIFA.

In some base-station uses, the radio might get warmer (direct sunlight) than the battery wants to be, so the board needs enough capacitance to support the transmit power even when fed over a long wire from a remote power source with no local battery as a buffer. (Or, instruct the user to solder a big cap right over here in that situation…) I’d love to see test points or an actual footprint for screw terminals or something, because chopping up USB cables to use inside a weatherproof NEMA enclosure is all kinds of awkward.

In all cases, it would be lovely to know the battery voltage and unit temperature… Jeelabs has some great posts on how to minimize parasitic drain caused by a voltage divider but still get accurate measurement of Vbatt on the other side of the regulator. In base-station uses, Vbatt might be like 14v or something, so choice of scaling resistors gets tricky. I don’t have a good sense of what a proper wide-input SMPS would cost, so that may or may not be practical to include…

2 Likes
14

Are you envisioning it literally being carried in a pocket? I seem to recall the Gotenna Mesh units perform significantly better when externally clipped to a backpack, jacket, et cetera. GTM isn’t LoRa, but I believe it operates in the same ISM band.

What I’d love to be able to do is unsubscribe from InReach. The basic use-case of Meshtastic is pretty similar. While it’s a satellite device, and therefore when more different than the GTM, it has the same recommendation for external placement.

While I’d love to be able to stash the LoRa device in a pocket (bag, etc.), is that practical while maintaining useful effective distances between nodes?

15

Or tucked into a backpack pouch or whatever. Either way, a naked dev board won’t survive long out in the real world, and an antenna that can be snapped off will be snapped off, and at the worst possible moment.

But yes, if you’re not pushing the limits of range, 915MHz with the antenna folded down alongside the unit, does just fine in pockets. Some users might travel in a fairly close pack and enjoy the convenience. Others of us might set up a truly ridiculous base-station antenna in order to not worry so much about gain on the portable side. (I have some old hirschmann 902-928 sectors the size of your leg…)

The question is, when mesh mode comes back into Meshtastic, how persistently do messages retry? Could one member of the party have a good externally-placed unit, and the others nearby have dismal antenna conditions but still get out by relaying through the good one?

16

Yes, I live an hour or two off the road system. Winter travel here is by snowmachine, foot, or fatbike (until I get a sled dog team) with temps reaching -60°F. Summer travel is by open boat. A problem I tend to run into is that I’m an edge case requiring specs which are overkill for 99.3% of people. My baseline would be something IP67 or better, and preferably floating.

The Garmin InReach Mini might be a good form factor to work backwards from (i.e., shrink).

garmin-inreach-mini-4
garmin-inreach-mini-4750×500 254 KB

2 Likes
17

Now that disaster.radio officially supports the T-Beam, that’s probably the best answer to my original question. No SX126x option, but basically ticks all the other boxes.

1 Like
18

Just stumbled across Radacat. They sorts look like Gotenna Mesh units, but actually use LoRa. Of course, another closed system. They didn’t quite meet crowdfunding goals for their v2 hardware, but it sounds like they’re building them anyway. Their v1 has a few Amazon reviews.

In addition to the main device, they have a tracker-only device, and seemingly also a base station. I couldn’t find any details on the latter, and the image links in their expired campaign are mostly broken.

h4tkfblx3rmv7htidpwn
h4tkfblx3rmv7htidpwn695×413 41.8 KB

I bring them up because when pricing components for a build like this, it got expensive pretty quickly. I can see why Gotenna and Radacat are in the $80-$200 range. What’s more surprising is how the T-Beam isn’t more expensive.

19

POE for base node? I’m pretty sure some mainstream drones could lift an ESP32 to the tallest tree in my yard. Wouldn’t have to worry about solar and batteries with on-board POE. And hey, don’t want it in the tree anymore? Well your CatX cable just became a tether. :musical_note: …in a world of OSHA violations. :musical_note:

These don’t have LoRa, but both are Open Source Hardware projects with varying degrees of documentation (schematic-only to Eagle/BOM).

wESP32

Olimex ESP-POE-ISO

20

I’m trying to use Radacat as a LORA device for ATAK communication.
Currently we are looking at RADACAT, for being a rugged, compact and portable LORA radio, however they have released no SDK yet.
As other commented, a development board is exciting but not really practical for move around. If an open source project would create an equivalent of that I would be glad to port our software to that.

1 Like