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.