Is it possible to use the mesh capabilities without needing to create networks or anything on the Particle cloud? I have a project I’m working on that will use a bunch of these devices with no internet access at all, not even for initial configuration, and I’m wondering if it’s possible to use these together in a mesh without having to configure it through the initial setup (ie. create a new network on one device, scan for it from another and join it).
2 Likes
At this time, no. I’m not sure if that’s on the mesh road map at all. How would Particle know that a mesh network exists and track billing of it without a conection to the cloud? You can use the mesh devices as stand-alone devices but the mesh functionality is essentially useless then.
2 Likes
Why would billing be needed for a network that isn’t pushing any events/data to the cloud? I’m thinking that I can somehow scan for meshes nearby then prompt the end user which network they want the device on, like many IoT devices do with WiFi network. After all, the mesh network is just based on the Thread mesh networking stuff so I should be able to use that to accomplish something like what I want, the question is how do I access all of that from a Particle board.
1 Like
Look at this project can solve your problem https://github.com/Brewskey/spark-server
2 Likes
I was looking at that, however that still requires there to be a device running that on the network, which some people may not want to do. Basically, the goal is to use these boards in a network with only these boards acting as sensors in it, and use a WiFi-enabled one as an access point, running a web interface to see data from the sensors. The places we are looking at using these have no way we can deploy a spark server that can be on the same network as a device on the mesh, and there is no way we can get access to the internet there (at least, we can’t get access to an unrestricted internet connection, it’s basically HTTP only and even then only certain sites are allowed, and we are not able to get anything whitelisted)
As was mentioned earlier, it’s not possible to create a mesh network without an Internet-connected gateway (Argon, Boron, or Xenon with Ethernet).
While a mesh network can sort of run once set up in completely isolated way, you won’t be able to add devices, flash code, or easily get any data off the devices, except by USB.
That use-case is not high on the list of priorities, and is unlikely to be implemented any time soon. It may never be implemented.
Also the SparkServer does not support UDP transport, so it can’t be used with mesh devices (even the Argon).
Is there a way to use the underlying OpenThread implementation in an application’s code? If so, I could implement this use case myself.
1 Like
Normal firmware is modular. There’s the system part, an abstraction barrier, and the user part. This allows for small (6K - 128K) user applications and eliminates the need to update the system part all the time.
Monolithic firmware is supported, however. You’ll need to use the gcc-arm local build chain or Particle Workbench (VS code) with a settings file change. With monolithic firmware, there is just one big binary, with no abstraction barrier. This provides access to all of the underlying open thread features from user firmware. And you can modify the system part as well.
It may still be a bit difficult to set up your mesh network, and it’s not a trivial task to make such a modification, but it should be possible.
1 Like
My current strategy is having all of the OpenThread header files included in my project in Workbench as a library, as well as ot_api.h. So far, I can build with that, but I can’t seem to get any debug support working. I’m trying to get VSCode to use arm-none-eabi-gdb.exe with OpenOCD and the Particle debugger to flash my code and test it, but I’m not having any luck so far. From what I’ve seen, nobody’s gotten this working, so if I do manage to do it I’ll post something on a new thread about it
@wolfmitchell had you seen this?
Yeah, I’ve tried that, but when I tried to use it, the Xenon I’m using this with didn’t even seem to run my code at all (using just a simple RGB LED blink thing). I’m going to try it again though, to see if it just magically starts working now.
I just tried it again, my breakpoints never get hit in my code and the RGB LED is just breathing white, instead of just going on then off once per second. I do get this from OpenOCD, however: undefined debug reason 7 - target needs reset. The same thing happens after I reset both the Xenon and the debugger itself, though.
Edit: Also, about half the time I get a new null::_start.cdasm tab in VSCode, but it’s just stuck with a loading thing going across the top of the screen! This is what it looks like for me:
Looks like we are working from different directions but to the same goal. I wish to use my 30 Particle Devices on a pure OpenThread Mesh Network (Like what I thought I was purchasing). I have a Border Router working on a Ubuntu laptop, but can't get an NCP device connected to the Border Router. (I am close and have ordered 3 types of Nordic USB Dongles. Only have the Fanstel Dongle yet but it uses a secure DFU bootloader that is messing me up)
Would be great to be able to flash NCP code to the Argon, but not sure if that will ever be possible.
See the thread at:
You can flash NCP firmware to an Argon that’s running 0.8.0-rc.25 or later using a command like:
particle flash --serial argon-ncp-firmware-0.0.5-ota.bin
in listening mode (blinking dark blue).
From a fresh from the factory Argon, you need to update the system firmware first (with a hybrid build), then you can update the NCP.
1 Like
OpenThread does not provide the entire stack so I'm not sure why you thought Particle devices would be "pure OpenThread". If you want "pure" OpenThread then you need to look at Nordic nRF52840 devices with the SoftDevice stack which supports OpenThread or BLE 5 mesh. The fact that you have so many hassles with the Fanstel dongles speaks to how Particle has simplified meshing and made it accessible to lay persons!
Don't get me wrong @peekay123 I love the Particle Web IDE. How it massively simplifies what I do in the classroom.
I just want to be able to mess around with BOTH OpenThread and Particle Mesh Networks using the Particle Mesh Devices. For my students it would be better to learn how to use a fully Open Source Mesh networking Protocol, but for actually making a Proof of Concept working product Particle is the way to go.
1 Like
The reason we’re taking slightly different directions is probably because our goals are similar, but different. My goal is to use only OpenThread for a mesh network between many Particle boards, while you’re trying to just communicate from an OpenThread device to a particle mesh (although it does use openthread)… I’m trying to completely bypass the need for the Particle cloud in creating new mesh networks and adding devices to a mesh, I just don’t think it’s necessary to have to have a separate server just to tell a device ‘oh, go create a new network’.
1 Like
You're right, not neccessary... but in this case the server is saying "thanks for reporting the existence of the network and adding another device.We will bill you accordingly."
It's all about Particle's method of monetizing this platform. You aren't the first to want an open, available, anything goes type of mesh. So maybe down the road they will create a "no security" mesh network if it's even feasible.
1 Like
I mean, there is still the open source spark-server for using these devices without their server (although I’m not sure how well it works honestly), so I’m not sure if the argument for them requiring a server for it is monitization.
I’ve never tried to take a brand-new Gen 2 device out of the box, program it, and use it without ever connecting to the cloud. Don’t you have to claim those devices to your account to use them? Which would contact the Particle cloud to say “Here I am and I’m attached to this guy’s account. Bill him accordingly.” Can you use the spark-server without first claiming and activating the device? These are things I’ve never tried but would want to understand before backing or refuting your argument. I just don’t have enough information on that.