To make the experience fit your profile, pick a username and tell us what interests you.
Adobe Portable Document Format - 131.58 kB - 05/08/2017 at 18:33
license - 1.05 kB - 05/01/2017 at 18:35
This project has been officially scraped. It was unlikely to ever be cost effective enough to produce in mass do to the overly complex LoRa module. Ongoing work will be done on the #ESP32 LoRa Gateway project.
hat dream is that I will one day soon click the magic button on @oshpark and have the first revision of LoRaNet32 merrily sent down the fab chain. But that dream cannot be realized without a few good stompings first.
There's been designs and redesigns of redesigns, mostly around the power system. I followed through with the change over to the CP2102N, that looks all fine. Where I fell short was in my hope to be able to have USB and Solar coexist and be happy and just work while charging the battery. I kept falling down a slippery slope of Ideal Diodes and Power Path management chips that cost a small fortune so I decided to dead simple. I put a switch between the solar input and VUSB.
'm at the point where I really need more experience eyes looking at this. I'm sure there are piles of amateur mistakes that will stand out. A PDF of the schematics is in the project and there's a link to the KiCAD project.
There's still money left and there is still more people following than liking! Please help get those dollars for the prototype! Any Colored Button could also use some too!
That's how that line goes, right?
as a followup to yesterdays post I ditched the FT2232 in favor of the CP2102. It's like 10,000% easier to implement as it requires very minimal external components. Just a couple caps for power smoothing and some pull resistors. I like that, because I can understand it better.
It also appears to have features to integrate itself into a power management system by notifying a charge circuit of power available (0.5A, 1A, 1.5A). The early bits of research I was doing last night, it appears I should be able to hook this into the SENSE pin on the LT3652.
This change also brings about a significant part count reduction. No longer need a crystal or external EEPROM and needs fewer discrete components to operate. Between these and the price difference between the 2232 and the 2102 it's looking like a price reduction around $5+. Not too shabby.
But I still need help there! Presently I have more people following the project than have 'Skull Liked' it, so if you're reading this right now, and have not already, please give it a Skull and consider checking out my other entries!
I'm in that antsy space where I want to send this off to OSHPark but I know this circuit isn't up to snuff. A couple of obvious changes I'm working on right now..
Initially I picked the FT2232 because of it's dual UART capabilities. I'd thought I would be communicating with both devices a lot more during development but reading up on using the RN2903 this probably won't be the case. I won't be doing any firmware development for the LoRa radio, instead focusing on the ESP32 which will in turn talk to the RN2903. So I'm going to switch to a less expensive USB->UART device for the ESP32 and provide a breakout header on the RN2903 UART1 pins. What's your go to USB > UART chip?
All in all this is the weakest part of my circuit. I'm straight confused by parts of the USB +5V system. I'm not sure I have a good implementation of the LT3652*. And I'm fairly certain the two systems are not tied together correctly. So next up will be a ton of reading up on implementing a solar > Li-ion charge controller that will also accept USB. Suggestions welcome and appreciated!
*after a lot of reading, I'm confident the LT3652 is the right choice.
LoRaNet32 is gaining some traction! WoooO! This is particularly nice because as unlike my other entry the Any Colored Button, this one is quite serious and will cost a couple dollars to make. So far rough cost estimates put it at around $50 a board at prototype volumes. So! If you're following and haven't given it a Skull yet please do!
The hope is to run the nodes with as little power as possible. Meaning BLE is strongly desired instead of WiFi. For devices that support Web Bluetooth, once the web app is downloaded and cached with Service Workers the user will be compelled to disconnect from the WiFi allowing it to enter a lower power state where it is simply broadcasting beacons.
Service Workers will take care of reloading the application from a local browser database on future visits to the now unavailable Captive Portal. Future updates can even be provided over BLE.
Or... How do we compel the user to not reconnect to WiFi?
I've bootstrapped the project with my last weeks work on the first iteration of the board. Initially I'd designed around the ESP32-WROOM module but the need of an external antenna mount called for a redesign of that section of the board.
The board consists of 4 major components.
This is the user facing portion of the network. It will provide a captive portal allowing users to send message across the mesh network.
This is the backbone of the network, providing long distance, low bandwidth communication.
Charges a LiPo battery from a solar panel for unattended nodes. Can accept external power to run without panel or battery*.
*without a battery it wont be able to act as a redundant disaster node.
Two port FTDI provides direct UART access to the ESP32 and RN2483. This is primarily for development purposes and might be reconsidered in later designs as these parts are quite expensive.
Become a member to follow this project and never miss any updates