WiFi LoRa 32 and Wireless Tracker Hardware Update Opinion Collection

#1

We released WiFi LoRa 32 as early as 2017. Over the past eight years, many customers have deeply loved it. It has been made into various products and is widely used in multiple scenarios. Based on the user feedback collected over the years, we plan to launch WiFi LoRa 32 V4 and Wireless Tracker V2!

We would like to hear your opinions on this upgrade. Welcome to discuss actively!

  1. Will add an external PSRAM.

2. Use an FPC antenna instead of the pogo antenna.

The FPC antenna is glued to the plastic bracket of the PCB, which helps make the overall look simpler and can also provide better RF performance than the current spring antenna.

3. LoRa output power reaches 30 dBm.

4. The 0.96-inch OLED driven by the SSD1315.

The 1315 version has a smaller outer size but the same display area. It can save a lot of space, so that the display screen can be placed inside the plastic clip to better protect it.

image
image.jpg812Ɨ528 207 KB

Unfortunately, the drivers of 1315 and 1306 are not fully compatible, which means that the firmware of LoRa 32 V3 can light up the display screen of the V4 version, but it cannot display perfectly. The edge will appear jagged as shown in the figure below
image
image.jpg618Ɨ760 98.3 KB

And another solution, the display screen address of LoRa 32 V3 is 0x3C. We can set the IIC address of the display screen driven by 1315 to 0x3D in hardware as a distinction, and update the driver code to automatically identify the display screen version.

5. Leave the LoRa antenna options of IPEX or SMA, allowing users to choose freely?

The SMA interface increases the volume but has less attenuation on the RF signal.

6. Have a TF card slot?
How do you think about a TF card?

7. Keep the current LoRa 32 V3ā€™s size and profile?

Keeping the original size will allow for compatibility with the shell that customers may make for the LoRa 32 V3, but our hardware engineers have assessed that this is almost impossible due to added some new features. Is it acceptable to increase the size appropriately but keep the pin order and position unchanged?

8. Added support for solar panel, and a shell that can hold batteries and solar panel.

9. Wireless Tracker will use the AG3352 chip, which is a single-mode GNSS chip that only supports L1 and supports GPS, GLONASS, Galileo, BeiDou

Do you have some other needs or ideas? We will select some of the guys who participated in the discussion on this topic and send new test samples.

Thanks in advance :pray:

#2
#3

Hi Aaron, Iā€™m very happy to see this customer-oriented question!
Note that I am an avid user of the Wireless Tracker (almost 100 out in the field); I donā€™t have the LoRa32 myself (the WSL v3 is serving me perfectly fine).

  1. PSRAM: personally, Iā€™ve disliked the rather large external chips more than I found a use for PSRAM. My preference would be to leave this out.
  2. 2.4G antenna: I have a couple of units that have their spring antenna broken off. I havenā€™t had problems really with performance, but a solid FPC antenna is much more sturdy, which would be a welcome change :smiley:
  3. 30dBm radio: please no, I think that many people use LoRaWAN which doesnā€™t benefit from this; for those using plain LoRa, Iā€™d rather have they are a friendly neighbour than overpowering everyone else with 30dBm transmissions :slight_smile:
  4. SSD1315: I donā€™t know in what universe this wouldnā€™t be an upgrade :wink: especially with the IĀ²C address change! Unless it makes the product costs ā‚¬5 moreā€¦
  5. A plain (non-populated) SMA connector would be nice, but only if the ā€˜selector resistorā€™ is actually usable. The 0Ohm resistors that you have on some of your products are frankly completely unusable.
  6. TF card: I never found myself using this in an actual product, as a case or whatever always means that the location/layout makes it pretty hard to use. Unless you want your customers to open up your product. Besides that, implementations that I have seen make it so that the TF card uses a set of otherwise useful pins, rather than combining it with the existing SPI interface for e.g. the radio (I guess for safety/clarity, but it limits the number of free pins).
  7. Size/profile: for myself, an identical layout with e.g. an extension of the PCB on one side wouldnā€™t be much of a problem. A redesign of the layout would mean a complete redesign of the case which sucks and costs a lot of time. But a few mm extra on one side with pins otherwise identical is easy enough.
  8. Solar & shell: sweet, good, great! :sun_behind_small_cloud:
  9. The UC6580 is such a sweet chip, why the change? I really love it and its performance. I canā€™t find much info about the AG3352. If it has a significantly lower power consumption, sure, that would be nice. But otherwise Iā€™d very much appreciate keeping the UC6580!

Other ideas:
10. For the Tracker: bringing back the separation of Vext and Vgnss from the Tracker v1.0 would be very welcome. There are multiple opportunities where I would like to use the display but keep the rather power-hungry GNSS chip in sleep mode.
11. For the LoRa32: please(!!) use a broken out IĀ²C bus for the display. The current set of GPIO 8/9 only being internal causes so many support problems. I would much rather have the radio pins being internal only, as SPI is much less common.
12. Please, always use native USB host! No serial chip, just straight D+/D-.

ā€¦ maybe I will come up with something else over the coming few days. Either way, as before, happy that youā€™re asking for feedback like this!

1 Like
#4

My thoughts:

  1. PSRAM: For holding more data without wearing out flash, this is a good thing, but I suspect you are going to have to make choices on size of PCB and end cost.
  2. 2.4G antenna: If the performance will increase without impacting on cost, then yes please.
  3. 30dBm radio: This can only end in a royal mess of people trashing their local regulations. However thatā€™s not your problem and for those that need it, you could offer a variant that can go all out, but mostly shipping 22dBm for most-of-world and, if you could stretch to it, a 14dBm version for EU. This makes a dramatic difference to power use on Tx.
  4. SSD1315: If itā€™s OK on price, all good, yes to a change of I2C to help detection.
  5. I have a footprint that allows for SMA or uFl to be put on. This would be good, but as @bns says, make the 0ā„¦ resistor at least 0603 - or go rogue and have a three way solder jumper ā€¦
  6. TF card: Again, space permitting - the LilyGo TT range has a compact one that works nicely.
  7. Size/profile: If there is a change of size, please give it a new very different name, just to help reinforce the difference.
  8. Solar & shell: charging from any & all sources is always welcome
  9. The AG3352 is used in the Quectel L76G who say it has the same accuracy as the UC chip despite only having L1. If you are using the AB (low power) version which is about quarter power requirement, that makes sense for a battery driven device. Maybe @bns could get one to do a compare & contrast?

As above, separate power control for various power hungry items is always good. Doubling up the I2C seems make work - if the docs are clear it already has the display on it with whatever address, no reason to make the developer define a new I2C setup - which is a frequent issue on the forum.

Last but as important as the hardware, getting the libraries and docs well exercised will make any upgrade or transitions as smooth as possible. Sharing a prototype schematic so we can fiddle around with the changes in advance would be useful.

1 Like
#5

Just one addition to @bnsā€™s commentsā€¦

  1. If youā€™re going to ā€˜hideā€™ any common bus connections, in any module, could you please also give serious consideration to the fact that most users/applications will assume that the first/primary/default bus of any flavour, where there is such an option, will be available for general use, for exactly the reason that @bns states.

And, with regard to @nmccā€™s comments, please note, with a degree of emphasis, his point 7. If the WiFi LoRa 32 V4 module has a different footprint, is not pin compatible with the V3 module, or uses components that require significant software changes, please come up with a new name and simply phase out the WiFi LoRa 32 name.

1 Like
#6

Regarding @nmcc on the AG3352: I indeed found the corresponding document from Quectel now, and the LC76G(PA) has a 10mA power consumption. That would be very great, if the performance isnā€™t too lackluster. I canā€™t seem to find it available for purchase around here, so if this change is serious, receiving a couple to compare would be very very welcome indeed. The other Quectel versions donā€™t appear to be much different, in which case sticking to the same would be preferable, from my perspective.

#7

Thank you for your feedback.

Can you share some more information about your projects? What are they used for?

#8

This would really help - inside the libraries, using I2C2 or SPI3 or whatever is well hidden from the users who will mostly by default assume that codes samples littered over the internet that they see for other platforms should just work.

This includes internal definitions for pins - like SDA & SCL - that are preferably set as defaults for the initialisers. And as an extra bonus, some starter templates for I2C and SPI plus worked examples for the trickier extras like SD Card.

#9

60 of them are in sensor boxes that we use at school for our students for measuring CO2, temperature, UV, PM etc.:

PXL_20250424_064841631
PXL_20250424_064841631.jpg3269Ɨ2455 2.81 MB

The Wireless Tracker functionality is perfect for us, yielding e.g. maps like these:
image
image.jpg938Ɨ1207 827 KB

Then I have a bunch of coverage testers/trackers, of which over 10 out in the field and another 20 at home that Iā€™m going to market again soon:

PXL_20250113_090610406
PXL_20250113_090610406.jpg3269Ɨ2455 2.54 MB

Together, they have already seen some places:
image
image.jpg1143Ɨ899 537 KB

1 Like
#10

The only word of praise I can think of with my poor English is ā€œhandsome!ā€ !!!:+1:

1 Like
#11

Thank you very much! :smile:

#12

You havenā€™t met him face to face then!

But I understand what you mean - Iā€™ve one of the trackers and the Wireless Tracker hardware is oh so perfect for such applications.

#13

I live in the desert area of Southern California USA where we have set up high elevation meshtastic routers in an effort cover the less populated areas with nodes. Having nodes with 30dBm is essential for this low population area.

#14

Please! send out a few boards to beta-testers first so that the final product has a fixed design. Not a v3.1, v3.2, v1.1 and what-not. I designed a case for a VME213 based on a board I have myself, only to find out that the 30 we ordered last week have their USB-C connector shifted by one millimeterā€¦ (even though the newer one is labelled 1.0.)
I implore you, please settle on released products :pray: