My Dream Hardware

You know what would be amazing? If there was a sort of unified Photon + Electron. More specifically, my dream would be to have a Photon that you could extend the network connectivity with additional hardware modules and then have a firmware method where you can prioritize the network connections. Wifi (built into Photon), cellular and ethernet modules would be amazing.

Working on Photon/Electron based projects, I keep finding myself wishing the Photon could optionally do cellular in some cases, the Electron could optionally do wifi in some cases and other cases where the photon is perfect except there’s no wifi or cellular available at the install location (but there’s Ethernet, which could also be used for PoE).

Maybe just a pipe dream, but in my perfect little world, everything would be unified to have a Photon as a base with some sort of expansion connector on it to add a cellular module and/or Ethernet module (I believe internally the microcontroller that the Photon uses already supports Ethernet up to 100Mbit).

It would also allow situations where if one network type wasn’t available temporarily for whatever reason, the device could fallback to whatever was next in priority list (say wifi is normally available, but it’s not right now, then it could have network connectivity fallback to cellular).

2 Likes

I appreciate the feedback, and you’re not the only one who wants affordable Wi-Fi + Cellular hardware. There are definitely use cases that justify it, especially consumer products intended for deployment outside the home where:

  1. It’s far enough from the house that you need to use cellular -OR-
  2. It might be deployed in remote places (lakehouse, etc.) where cellular connectivity may not exist

What are the use cases where a Wi-Fi + Cellular device would come in handy?

3 Likes

Some specific use cases I’ve run into are this:

  1. Building a product that could be deployed where there is wifi (but not always). Let’s say for example something one would deploy within a city (let’s say something like traffic monitoring stations). Some areas in the city might have wifi, most probably don’t. As I mentioned in my original post, the ideal situation would be to design one piece of hardware with an expansion option to add cellular connectivity to a normal Photon. This would also apply to stuff being deployed on school campuses or corporate environments (say 95% of the area has decent wifi coverage, but for a couple places that might not, you could add a customer installable cellular module after the fact once the customer knows wifi won’t work in the desired location).

  2. A product that is deployed in a data center, inside a metal rack (something like environmental monitoring), where there isn’t wifi and the cellular signal inside the sealed metal box (the rack) is non-existent. But there’s a whole lot of Ethernet ports in there.

  3. A product deployed in a secure corporate environment where wifi isn’t allowed but again… lots of Ethernet ports.

  4. A data collection system where you want redundancy if whatever it’s primary connectivity falls out (wifi could fall back to cellular if wifi connectivity wasn’t working for whatever reason).

For the stuff I’m doing, I don’t necessarily want to force wifi and cellular concurrency to end users (and the added cost), but for those that want it, a cellular addon module for a Photon really would be ideal. I feel like a cellular addon module for a Photon would be far more useful than a stand alone Electron.

If a something is currently being deployed with an Electron, a few extra dollars for a Photon + cellular addon (and slightly bigger footprint) seems like a no-brainer in most cases. I can’t think of many industrial applications out there where you are using an Electron and small size of the device being deployed is an issue where it couldn’t fit a Photon plus the ublox cellular module separately. The stuff that is going to be size constrained are going to tend to be the stuff that lives in a house and doesn’t need cellular options to begin with.

There could be numerous use cases in mobile situations such as trailers and RVs(caravan/roulotte). The usage I foresee most likely is security and temperature/humidity monitoring. When the trailer is parked at home, it would use WiFi. On a job-site or camp site where I am present, it could use WiFi to link to my cell phone. When left unattended in a remote location, or if someone steals the trailer, it could automatically switch to Cellular.

Then again, a race car inside the trailer could have a Photon or a compound with BLE. In that case, the trailer unit could use co-existence to link to the race car by WiFi as well as link externally by Cellular.

A third case is in my house, which is in a rural location. I frequently get power outages, which means WiFi is unavailable. A cellular option could be used for basic monitoring for security and critical functions like water level in the sump or septic pumps.

1 Like

I forgot about another use case where I couldn’t use a Particle device. We wanted to control devices on a VLAN with no Internet access (was a non-routable private network just for controllable devices via socket connections to their Ethernet ports.

Now if the Photon had an Ethernet module, great… do the control over Ethernet and control the Photon via wifi.

Now that last one at least should be fairly simple, now that other people are using the Particle stack someone can make a POE ethernet version if they see the market…

Would a dual core version also be anyone’s idea of a ‘dream’ device. Once core to handle all the cloudy stuff and the other for your app so that one will never interfere with the other. Downsides presumably being complexity for beginners in working with threaded workloads and whatever the necessary FreeRTOS customization is.

1 Like

I have an application that requires interfacing with an instrument via Ethernet (actually, it’s Modbus over Ethernet). I need to push that data to the cloud, but without using the customer’s very unstable LAN. I was planning on using a Photon (with a WiFi to Ethernet "bridge) and then tying the Photon to an Electron serially. This approach works fine.

Once the Raspberry Pi platform was adopted by the Particle clan, I realized I can simplify things by using a Pi in lieu of a Photon and bridge. Regardless, the only downside other than extra parts (and $$$) is the fact that the Pi/Photon will not be remotely accessible for firmware updates over the cloud. This is why I would like to see an Electron-Photon-Pi combo device.

One theme that I’m hearing come up a lot is Ethernet connectivity – if you weren’t already aware, we released a software package called the particle-agent that can be used to connect Raspberry Pi’s to the Particle Cloud. For the moment, this is the easiest way to get Cloud connectivity, encryption, and OTA updates for an Ethernet connected device.

Some helpful links:

3 Likes

@will Yes, I already have a R Pi 3 in the open beta for particle-agent. I am seeing many great possibilities for using it to integrate other particle devices and perform higher-level functions (like the command and control function of an army of particle devices). :+1:

For me, the Ethernet stuff is like 10% of my wish. 90% is a Photon with an optional cellular addon module.

I’ll check out the Pi stuff, although we have no use for the Particle Cloud, so not sure what the benefit would be vs just using a standard Pi. Maybe if it did OTA operating system updates of the Pi (and not just the Particle firmware), that would be useful.

2 Likes

Well in theory you could with Process Control, which allows you to run shell commands from Particle Firmware on Raspberry Pi.