I really wish Thread mesh networking would become standard on new Wi-Fi routers. Google Nest has hardware support for it, but not sure if it's enabled yet.
I think Thread is a much better fit for IP connectivity for IoT devices. Nordic Semiconductor nRF SoCs can do Bluetooth LE and Thread on the same radio at the same time, so should be very cost effective.
I'd gladly replace all my Zigbee devices with Thread ones if they were available. It'd be really nice with something that's easier to troubleshoot with standard IP tools, and to not have to have a separate hub for that network.
Nordic Semiconductor recently bought Imagination Technologies WiFi assets, so there should be some nice SoCs from them in the near future too.
Is Thread still happening? Last time I checked the only hub available was Nest, although Apple hardware has support but it's not enabled in software. Other than a couple of niche home automation products, nothing supports it. When will I be able to buy smart light bulbs for $10 that use Thread?
> although Apple hardware has support but it's not enabled in software.
Nope - HomePod mini has thread enabled. That’s the only thread device I’ve seen from apple so far, but I expect that all future ‘home hub’ capable device would support it as well.
I couldn't agree more. I picked up a dozen Particle Xenon board (nRF52840) for around the house and as a mesh they work amazingly. I was very sad when Particle dropped support for them to focus on cell boards.
Where the mesh is IP-based it was straightforward to have nodes anywhere in the mesh send data out to my influxdb.
Glad to see Espressif making RISC-V products, I love what they put out but the xtensa architecture made it hard to work with languages that targets LLVM like Rust and Zig.
Why didn't they pack more ram on this? 400K is a bit tight, we often hit the ceiling with the ESP32's 512K of internal RAM. Does anyone know if they support SPI-connected external RAM on this? It has been a lifesaver on the ESP32, especially since WROVER-E fixed most of the long standing bugs that were plaguing the earlier revisions. It is slow as hell, but having 4MB (+4MB high memory) of connected RAM on a microcontroller has been a real game changer.
> ESP32 has the ability to also use up to 4 MB of external SPI RAM memory.
> The external memory is incorporated in the memory map and, with certain restrictions, is usable in the same way as internal data RAM.
> While ESP32 is capable of supporting several types of RAM chips, ESP-IDF currently only supports Espressif branded PSRAM chips (ESP-PSRAM32, ESP-PSRAM64, etc).
Have you seen the die images of the ESP32? Basically the entire die area is SRAM. SRAM eats a ton of space, and with a bigger die area you have a much higher likelihood per part that you will have a defect and have to scrap the entire chip.
Sure, if you add extra remapping hardware, nonvolatile storage, and eat the performance penalties. Makes sense for massive quantities of crappy cheap flash, not so much for this.
> Sure, if you add extra remapping hardware, nonvolatile storage, and eat the performance penalties.
Nothing a few fuses can't solve.
> Makes sense for massive quantities of crappy cheap flash, not so much for this.
Coming from the x86 world, they use plenty of fuses for everything. I can't imagine a reason why they would not absorb production variation with this for esp32 dies.
Especially since the multi-thread OS means wasting space for multiple stacks. 400k is a lot for an MCU, but for the ESP32 its really not that much. A 1MB Sram version would be great, with two cores.
I don't understand why they used a wasteful threaded model instead of an event reactor. It makes no sense to me on a constrained embedded platform. The right way to do it is Japaric's "Real-Time Interrupt-driven Concurrency". Only works for ARM cores though...
What about botnet operators? This would give them a hard time if they have to hack each device specifically instead of recycling old linux vulnerabilities wholesale. The whole IoT industry is strongly committed to make devices available to botnet operators, indeed this looks like the main function, the function on the packaging usually works poorly and is likely just there to convince punters to install the botnet relays and pay for the hardware and power.
Well unlike the Atmel chips, it is -- like it's predecessor the ESP8266 -- a totally internet focused MCU. So with TLS and HTTP requests, and receiving streams and WebSockets and whatever else, it's not hard to imagine what to do with it. More is better. For example I have one ESP32 setup with 8 megs of PSRAM that does a full scan of a currency exchange every 15 seconds. Loads all the data into RAM, which I can subsequently process. Run LED displays on after, trigger other events etc. It's pretty cool!
It's certainly alot more direct to implement than booting up Armbian on a PI, and then starting Node, and then....
(I get no money if you click that btw -- it's just for reference)
The watch has some "trading features" even. If I see an interesting trade I can let it take the trade and finish it to "take profit", while I go and do something else. It has a touch UI and a 240x240 16bit colour screen -- so lots of possibilities there.
Most of my ESP32s are driving stepper controller boards for custom microscopes, telescopes, or my CNC. It's nice because the ESP32 has a wifi connection so I can just connect directly to it to control it via g-code.
When i looked at previous Espressif chips, their mesh networking implementation for Bluetooth was proprietary.
The Bluetooth standard contains a mesh networking standard. Is there any affordable SoC that lets me build a standard Bluetooth mesh application without having to start from scratch?
When I played around with ESP32 when it just came out, the problem was that the toolchains and software just weren't done yet. There were a lot of features that existed on hardware, but without toolchain support, docs, or sample code it was close to impossible to use them.
I'm not sure how it works now, but especially for newer stuff I wouldn't rely on the fact that the hardware claims to support something -- if the software isn't there, it just doesn't really mean much.
I'm not familiar with other microcontrollers, but ESP-IDF seems to be very actively developed. I bought a wESP32 a few months ago and initially couldn't figure out how to enable ethernet... came back after some ESP-IDF updates and had it working in 10 minutes.
But you are probably correct about the latest chips.
ESP-IDF is super friendly, I was amazed how easy it was to get it set up and configured compared to my experience with some other embedded toolchains I've used before.
The Bluetooth Mesh standard actually is based on a Bluetooth 4.0 feature set (basic advertising and scanning), so really any BLE device can support it. The problem is that the software is complicated, so typically only newer devices have software support.
Many chip vendors have BT mesh implementations, including Nordic, TI, SiLabs, Cypress, Dialog, and ST.
It’s a little bit better than that, in that only some nodes rebroadcast everything while you can have lower-power nodes be primarily in transmit mode. But yes, I think the spec could use a lot of improvement.
It does seem like there’s a lot of momentum in the BT-SIG to grow the standard over a long period of time, and there also are a lot of active contributors, so I do expect it to mature in the future.
Kind of interesting that the only thing in the part number that denotes that is the "C6" part. Apparently "C3" is another ESP32 with a RISC-V cpu. I'd have gone with "ESPR" since it fits "EspressIf" but denotes RISC-V clearly.
Does the packet processing for WiFi and bluetooth take cycles from the CPU, or is the CPU 100% available to the application code? I read the blurb but it didn't address this question.
I was recently looking into using some ESP32s to use on a BLE hardware project I am working on at the moment.
Although I do wonder whether wifi would be a better technology to use sometimes. The only thing I remember seeing is that wifi technology uses much more power.
From TFA it looks like WiFi 6 uses less power, is this true?
Anyone experienced have any suggestions whether BLE or WiFi would be better for streaming serial data from a device onto many platforms? (I currently have a BLE demo working, but working with Bluetooth stacks on mobile and desktop are a royal pain, network requests are very straightforward at this point)
ESP-NOW might be suitable, as it requires less power than regular wifi.
From the docs:
“ESP-NOW is a kind of connectionless Wi-Fi communication protocol that is defined by Espressif. In ESP-NOW, application data is encapsulated in a vendor-specific action frame and then transmitted from one Wi-Fi device to another without connection.”
One downside of using wifi if that devices like phones really don't like network connections that don't route to the internet. You sometimes have to fight them to stop the phone "helpfully" falling back to 4G or popping up all sorts of warnings about degraded networking to the user.
[edit]: This is assuming you are connecting directly to the device of course. Connecting the ESP32 to your existing wifi is well supported and much more reliable.
I have tried fighting this a couple of times but lost every time. Do you know a solution to make my Android phone keep the connection to a wifi without internet connection?
What about setting up some honeypot open-with-no-IP wifi hotspots near google HQ and near places where googlers are known to congregate (or in residential areas with high density of googlers working from home). Once it's their problem, they'll fix it pronto.
I lack a solution but would like to commiserate. We had some config errors on one of our VLANs, where DNS want reachable. The phones helpfully would just say no internet access and then bounce to 4g without any other sorry of error. What I would give to be able to just SSH into all these consumer services and just grep through the logs.
If you could return valid internal DNS entries for these domains, and serve up a 204 to the right requests, you should be able to stay online.
You need to ensure you don't do it for every possible domain - I believe Chrome also tests random non-existent domains too, to ensure it gets back the expected error.
I have a "captive" or "promiscuous" dns server (it responds with its own IP for all requests) for my esp projects so this info is exactly what I need. Thanks a lot!
In my experience, I had no network until I answered "no internet connection, disconnect?" dialog that pops up in that case. Maybe you could also say "don't ask again". Then it was working fine.
What is not working fine though, is that I cannot access the internet through the mobile network at the same time. But this seems to really depend on the phone: it works on iPhones and on my previous Android phone, but not on a Pixel 5. I would like to download updates for the esp32 firmware through the mobile network, but this prevents it.
Yes, phones request a particular (plain http) URL from Google or Apple, which returns a 204 response. If they don't get a response, the network is assumed to have a connectivity issue. If they get redirected due to captive portal, they detect that and can prompt the user to log in.
Sometimes as straightforward as pinging a server, sometimes elaborate as trying lists of random domains that some must respond and some must not resolve.
For equal target transfer rate and range, I don't think there would be a mode that any WiFi tech beats BLE in terms of using less power.
If power is your concern, have you considered nRF5 devices?
Nordic has a proprietary profile for sending serial data over BLE (NUART) but AFAIK, you could only connect to one device at a time (not many).
Power isn't a huge concern, although it's a battery powered device, so having a longer battery life is a plus without needing to include a larger capacity battery.
I'll look into the nRF5. I've been using some of Nordic's code to test and build my prototypes already, although I feel like adding a proprietary profile on top will just make it harder to interface. Once I make the connection currently, all I need to do is enable notify on the specific characteristic which isn't too complicated (just a lot of code to actually get the characteristic)
I wonder what Risc-V would bring them, other than some de-risking vs potential trade blockages for ARM as Huawei experienced. Would not having to pay royalties to ARM give this chip a cost advantage? By how much?
For a new project we've been looking at the ESP32 range - great functionality - but we're more than a little concerned about being reliant on a single company (Expressif) and manufacturer (TSMC).
Are there other SoC solutions with multiple companies and manufacturers with similar functionality?
From what I've seen the Qualcomm chips are really great but impossible to buy if you're a normal human, the ST chips are pretty solid and have a configuration tool that works well in Linux and their -WB versions support wireless and bluetooth but use more power than the Qualcomm chips. Then there's microchip (owner of atmel) which has a wifi integrated chip, but it was really hard to get to work.
ESP32 was also super easy to get to work, and I prefer it to the microchip series, see it as a budget version of the ST chips (uses a lot more power but that's fine if it's not on a power limit), and much easier to source than the chips that are meaningfully better.
So yeah, plenty of vendors of equivalent functionality, just different ecosystems for the firmware, of course RISC-V isn't the same as ARM (which the older ESP32 used) so that introduces some quirks into the toolchain, and of course the vendors chips aren't pin-compatible.
You're definitely making a new board if you swap the microcontroller because it's out of stock, that's nearly impossible to avoid -- your best hope is to pick a vendor with a good track record or just buy all your inventory up front, and if you're super lucky the vendor will sell different versions with the same footprint and basic design with different amounts of RAM and such with different availability so that you can swap chips based on supply chain stuff for short term issues.
But a lot of these chips are still made by TSMC I'm sure, so I'm not sure it really addresses the root of how few companies are at the root of the supply chain.
I don’t understand why this is downvoted gray. “We’d like to dual source a Wi-Fi SoC product” — fine, just build two completely different hardware and software to go with, with matching aesthetics and features.
There’s no way around it, there’s usually no pin-compatible alternatives in embedded like there are for Core i7 and Core i3. That only works in consumer PC.
I said that the old ESP32 was using ARM which as the other reply comment notes was inaccurate? Not that the mistake I made on the architecture of an older chip reduces the responsiveness to the actual question, of course, but it was an error.
This site has gotten extremely aggressive about downvoting for "disagreement" which seems to include minor errors (like with mine, despite paragraphs of correct information in direct response to a clear question) or often even questions. I don't really see how downvoting posts with minor errors encourages learning and hacking, but it definitely makes me reconsider answering questions.
Nordics tools and documentation are generally considered relatively high quality. Not perfect, but the competition is usually worse. That's one of the main reasons they are dominating the Bluetooth LE peripheral market.
Just write your code with a decent seperation between your logic and vendor specific things.
Then if expressif can't deliver, it won't be too much work to switch platforms, especially if you're switching to a more capable platform.
Sure, you'll probably have to respin the PCB and spend a week of late nights porting software, but that's probably still comes out cheaper considering the low probability of expressif chips being unavailable.
Super great to see new designs with RISC-V keeping up with tech, the BL602 and ESP32-C3 are currently available though, and I've been working with the Pinenut for a side project. I hope more RPi-like BL702 boards become more widely available for RISC-V too.
I'm wondering if there's any point at all in Espressif going to production with these chips- going from wifi4 to wifi6 seems to be the main change, and it should make a huge difference for how well behaved a network citizen the chip is.
like you I was elated to see some iot wifi hardware with modern connectivity standards. fantastic to see iot not have to lag by multiple years. very important upgrades, having ofdma, allowing multiple devices to share the ap.
Realtek RTL8720DN and RTL8721DM claim 5GHz wifi as well as 2.4GHz and BLE 5. Finding a decent dev-board for them is not easy. Seeedstudio's Wio Terminal is one of the few.
Why would 40 MHz wide channels be /better/ if the spectrum is congested? Smaller channels would be beneficial. Let’s say 5 MHz, and with OFDMA that is what you get. This is why Wifi6 is crucial for the long term viability of 2.4 GHz WiFi.
All the new features seem to be things one could implement in firmware... The things not easily implentable in firmware (new frequency bands) aren't supported.
Ideally useless piece of hardware.
100500+ ESP2866 useless designs are the best confirmation of this harsh statement.
You can turn on a LED with it. Nobody knows for what, but everybody knows how, because it's simple - just use the MQTT and ... (list of protocols).
RISC V will be the beautiful addon to it cause the True Way To True Uselessness should be hard.
^_^
I think Thread is a much better fit for IP connectivity for IoT devices. Nordic Semiconductor nRF SoCs can do Bluetooth LE and Thread on the same radio at the same time, so should be very cost effective.
I'd gladly replace all my Zigbee devices with Thread ones if they were available. It'd be really nice with something that's easier to troubleshoot with standard IP tools, and to not have to have a separate hub for that network.
Nordic Semiconductor recently bought Imagination Technologies WiFi assets, so there should be some nice SoCs from them in the near future too.