Look at this project can solve your problem https://github.com/Brewskey/spark-server
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.
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.
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
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.
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.
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’.
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.
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.
With my mesh device (is that gen 2? not sure) I can use the Particle Workbench to write code and compile it all locally, without having it sent to the cloud, then program it via DFU mode. I only activated this device once, but because I had issues with the setup process (apparently the OnePlus 5 has known issues with setup), I couldn’t actually create a new mesh with it, so I just unclaimed it and started to try and do this all locally (so I haven’t really used the Particle Cloud stuff, including it’s mesh capabilities, but the requirements for this project mean I can’t use it anyway).
Gen 2 is Photon/Electron/P0/P1/ESeries/etc. Gen 3 is mesh Argon/Boron/Xenon. Gen 2 activation is a bit different because you don’t have to create a mesh network at the same time.
On Gen 3 you don’t need to create a mesh at the same time either - it prompts you for that when you are adding the device.